Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What's Behind The Odd Data?

timothy posted more than 10 years ago | from the to-ask-your-advice dept.

Security 264

citking writes "CNet is reporting that 'network administrators and security experts continue to search for the cause of an increasing amount of odd data that has been detected on the Internet.' While this has been going on now for a few days and some experts have already declared victory against the 'trojan', others aren't so sure that the real culprit has been identified yet. Other stories can be found here(1) and here(2)."

cancel ×

264 comments

Sorry! There are no comments related to the filter you selected.

LUNIX IS BEST 4EVAr (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#6266233)

you have to speill MICRO$OFT witht the money sign OR UR A FAG

mod parent up! (0)

Anonymous Coward | more than 10 years ago | (#6266291)

It really pisses me off when people do that. You look like a dumbass. It isn't clever. I don't even get what statement is being made. Microsoft is greedy? MIcrosoft has lots of money? Microsoft wants money? What? Microsoft is a business dumbasses. Spelling it with a dollar sign doesn't say anything. If you are trying to say something about them being a monopoly, or anti-competitive, think of something clever, and say it once. Don't take someone else's unfunny dig at Microsoft and reuse it yourself a thousand times.

sux (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#6266235)

sux

w00t (-1, Troll)

Anonymous Coward | more than 10 years ago | (#6266236)

3Y3 am teh 1337 ghey luniX suX0R!!
w00t

increasing amount of odd data that has... (-1, Redundant)

PS-SCUD (601089) | more than 10 years ago | (#6266237)

been detected on the internet.

Simple...it's just encrypted pr0n. Hehe.

Re:increasing amount of odd data that has... (1, Funny)

richy freeway (623503) | more than 10 years ago | (#6266245)

Or Slashdotters posting comments...

zapro logs show BAU (0)

Anonymous Coward | more than 10 years ago | (#6266354)

About a scan every 4 minutes. Port 137 mostly. See a 1434 (think that's slammer) a few minutes ago. Along with

445
6588
1080
1026
6588
17300

Most ly 137, as usual.

Re:increasing amount of odd data that has... (0)

Anonymous Coward | more than 10 years ago | (#6266439)

Who the fuck is the crack head who modded one of the first comments down as redundant?
Jesus mods think first then mod....

Re:increasing amount of odd data that has... (1)

kfg (145172) | more than 10 years ago | (#6266450)

I guess they're thinking globally and acting locally.

KFG

Shouldn't this be the.... (5, Insightful)

ReTay (164994) | more than 10 years ago | (#6266244)

The âoefrom the incase you thought the Internet is not closely watched dept?â
Heh

Interesting how ISS works... (5, Funny)

evilviper (135110) | more than 10 years ago | (#6266246)

Just think, you can cause all the internet security firms to work overtime, just by:

nc /dev/urandom

Wintermute (4, Funny)

Anonymous Coward | more than 10 years ago | (#6266248)

I say it's Wintermute.

Re:Wintermute (0)

Old Man Trouble (674594) | more than 10 years ago | (#6266265)

Yep, someone get Case on the case (absolutely horrendous pun intended).

Re:Wintermute (1)

gacp (601462) | more than 10 years ago | (#6266403)

Actually, it's Tux.

anyone remember.... (0)

Anonymous Coward | more than 10 years ago | (#6266249)

...whatever happened to the Magic Lantern? could this be it?

"...I don't think it is a serious threat because it's not self-replicating," Meltzer said. "And it hasn't caused serious disruptions to anyone."

Same amount as always (4, Funny)

Anonymous Coward | more than 10 years ago | (#6266250)

I've been monitoring this for a long time, the amount of odd data is always 50%.

For those too lazy to read the article : ) (5, Informative)

arete (170676) | more than 10 years ago | (#6266251)

Basically, there's a new trojan, sortof.

It apparently requires being installed by hand by the originator (or someone else, I suppose) But then it makes the machine into an effective zombie for the originator.

It does a good job of hiding the infection - sending out 1000 spoofed addresses for each real one.

It targets linux only, at least so far.

It is apparently trying to map internet connected networks.

Re:For those too lazy to read the article : ) (3, Insightful)

DoktorTomoe (643004) | more than 10 years ago | (#6266261)

Hm, that's a theory. May I ask humbly if there is any proof for it?

It is a theory - and I don't have proof (SCO?) (5, Informative)

arete (170676) | more than 10 years ago | (#6266279)

But it isn't _my_ theory, it's a theory present in both the cited articles.

The following is my theory, and it is also without proof, but I'll provide some logic at least.

My supposition is that it tries to talk to lots of IPs, spoofed from lots of IPs. And that since it's not self-propagating, it's either 1) wasting time or 2) mapping. 3) doing something we haven't managed to detect.

People don't usually like to give answer 3, answer 1 seems like a silly reason for the author to put in so much work, so we're left with answer 2.

Now, does this mean this mapping is nefarious? Not itself, except that it's being done by someone ok with hacking and apparently skillful. To blatantly rip off another poster, maybe it's SCO trying to find all the linux boxen : )

Re:It is a theory - and I don't have proof (SCO?) (-1, Offtopic)

Surak (18578) | more than 10 years ago | (#6266311)

I'm posting this from a Linux box, SCO! Find me! Sue me! I'd love to rip you a new asshole in court! Please!

Re:It is a theory - and I don't have proof (SCO?) (4, Interesting)

Anonymous Coward | more than 10 years ago | (#6266322)

Heh, SCO doesn't need to do that. All of a sudden my boss at my work (I work for an ISP that has all redhat boxes) has gotten many phone calls for survey asking about what kind of servers we run, what OS they use, what they're used for, blah blah bla. That thought crossed my mind that SCO is just getting ready for their 'Big Win' over the Linux community and want a nice list of companies to go after.

jeremy

Re:It is a theory - and I don't have proof (SCO?) (2, Funny)

LinuxGeek8 (184023) | more than 10 years ago | (#6266411)

it's either
1) wasting time or
2) mapping.
3) doing something we haven't managed to detect.

I'd go for
4) to confuse the Russians.

Who and why? (1)

Bombula (670389) | more than 10 years ago | (#6266473)

If you want to figure out who would would want to do this mapping and why, the first thing to do is figure out who would derrive benefit from it.

So, who benefits from mapping IPs of linux systems? M$ would be on the shortlist, along with the government and a few other undesirables like advertising firms, major telcos/ISPs, and perhaps major entities with a Linux interest. Anyone care to provide a more thorough list?

Re:For those too lazy to read the article : ) (5, Interesting)

Anonymous Coward | more than 10 years ago | (#6266319)

Something's wrong with this theory. I have several thousands of these packets in my logs, but they started to appear back in october. They are directed at many ports (which are closed on my system), but each originator tries several times. Many attempts look like an Edonkey client trying to deliver a message, which is not unusual on a dynamic IP connection where the previous user of an IP apparently used filesharing programs. Either the window-size 55808 isn't that unusual or the "infection" has been around much longer. Another system on a static IP has yet to see even one packet with that window-size. If it's a mapping system, it certainly isn't random. <speculation>It could be that ??AA-serving companies are looking for "tainted" filesharing clients which they could then ask to reveal more information about the system and their owners by using strange packets for hidden communication with the client. If this is true, the trojan which randomly sends out strange packets is merely a decoy.</speculation>

lol.. (5, Funny)

ewithrow (409712) | more than 10 years ago | (#6266253)

Has this 'odd data' been corrupted with the evil bit or something?

What does odd data look like? (5, Funny)

fireboy1919 (257783) | more than 10 years ago | (#6266256)

prompt> ping www.google.com
PING www.google.com (216.239.33.101): 56 octets data
64 octets from 216.239.33.101: icmp_seq=0 ttl=44 time=90.3 ms
64 octets from 216.239.33.101: icmp_seq=1 ttl=44 time=91.2 ms
64 octets from 216.239.33.101: icmp_seq=2 ttl=44 time=97.4 ms - odd data message "HELP ME! I'M TRAPPED IN THE INTERNET"
64 octets from 216.239.33.101: icmp_seq=2 ttl=44 time=92.8 ms
--- www.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
May be possessed by lost soul
round-trip min/avg/max = 90.3/90.7/91.2 ms

Re:What does odd data look like? (1, Funny)

Anonymous Coward | more than 10 years ago | (#6266283)

Its "INTARWEB" you insensitive clod.

Re:What does odd data look like? (-1)

Yr0 (224662) | more than 10 years ago | (#6266338)

Its The Sentient ATM!

http://slashdot.org/~BankofAmerica_ATM/

Re:What does odd data look like? (0)

Anonymous Coward | more than 10 years ago | (#6266341)

Yeah, it's pretty odd how the ICMP sequence number repeated like that. I wonder what could have been responsible.

Re:What does odd data look like? (0)

Anonymous Coward | more than 10 years ago | (#6266344)

I think it looks more like

GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+ c:\\ HTTP/1.1

Re:What does odd data look like? (5, Funny)

8tim8 (623968) | more than 10 years ago | (#6266391)

>odd data message "HELP ME! I'M TRAPPED IN THE INTERNET"

Good lord. Isn't this the sort of thing the Internet Task Force was put together to help? I've never actually seen the task force but with a name like that I imagine they're like a geek version of the Justice League. In fact right now I bet they're sitting around a table at the Hall of TCP/IP, debating what to do next before flying off to rescue that poor, brave soul who is "trapped in the internet."

I sleep better at night knowing we have heroes like that on our side.

Re:What does odd data look like? (0)

Anonymous Coward | more than 10 years ago | (#6266464)

I serch serial to LEGO SOCCER MANIA

Please Can you help me?

Leon (email reply leonzawodowiec7@poczta.onet.pl)

Hmmmm.... (3, Funny)

Millbuddah (677912) | more than 10 years ago | (#6266257)

Could it be the beginnings of Senator Hatche's p2p Destroying scheme? Even though the ip's being queried belong to non-existent sites, I can't help but picture the following paraphrased scene (Note all lines are terribly penned and from year old memory): Darth Hatch: Tell me where the rebels are located your highness. Princess ISP: I've already given you 5 names. I'll never tell you the rest!! Darth Hatch: Then perhaps you'd like a demonstration of the full capabilities of our Pirate Death Star. Princess ISP: Alright, they're at 66.432.2322 And so on and so forth

Dark data (3, Funny)

Anonymous Coward | more than 10 years ago | (#6266259)

We all know that the universe is made up of dark matter, so of course the internet is made up of dark data. It all makes sense!

Odd data? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#6266260)

I blame the Muslims, and their backwards, sexist, repressive beared fuckwittery.

It is SCO (0, Funny)

Usagi_yo (648836) | more than 10 years ago | (#6266263)

Probing all the linux systems to get the name and address of everybody running linux. Expect a letter from their lawyers asking for the new Sco/Linux License fee.

magic lantern? (5, Informative)

Anonymous Coward | more than 10 years ago | (#6266264)

so it doesn't propagate and relies on that attacker to plant it on a system. once again - could this be the Magic Lantern we heard all about a while ago...

from

http://www.informationweek.com/story/showArticle .j html?articleID=10700645

"One thing is clear: Trojan 55808 is sneakier than previous Trojan horses. It doesn't self-propagate, like a virus or a worm, and requires the attacker to plant it on systems. But it does transmit a lot of network noise designed to throw off cybersleuths attempting to find the IP addresses of infected systems, as well as the address of the Trojan's writer or controller.

"For each machine that is infected, it will throw off 1,000 fake or spoofed IP addresses," Ingevaldson says.

Re:magic lantern? (1)

kemikalzen (173455) | more than 10 years ago | (#6266318)

url is not working

Re:magic lantern? (3, Informative)

moonbender (547943) | more than 10 years ago | (#6266337)

Working URL [informationweek.com]

Actually the original URL is fine, there's just a whitespace character added by ever helpful Slashcode. :)

Maybe we are searching into the wrong thing... (5, Interesting)

selfsealingstembolt (590231) | more than 10 years ago | (#6266269)

Maybe that are residues of testing? Some people writing networking-software maybe just made some debugging runs using data sent over the net and sent out erroneous packets.

Maybe it is some rare case with a seldom occuring situation where the TCP/IP protocol runs mad? I mean, when designing such flexible and autonomous systems sometimes there are things you can't foresee. After decades of online time and rewrites of TCP/IP core parts in combination with the unpredictability of such huge systems it would not surprise me, if that are just packets which emerge every now and then.

Another explanation: the net has gotten critical mass and is becoming conscious....

Just my two cents.....

Re:Maybe we are searching into the wrong thing... (5, Funny)

Ice_Balrog (612682) | more than 10 years ago | (#6266364)

>Another explanation: the net has gotten critical mass and is becoming conscious....

Thats it... I'm starting construction on Zion.
Who's with me?

Re:Maybe we are searching into the wrong thing... (4, Funny)

Eric Ass Raymond (662593) | more than 10 years ago | (#6266385)

Nah... I like the Terminator scenario better.

"Internet begins to learn at a geometric rate. It becomes self-aware at 2:14am Eastern time, August 29th. In a panic, they try to pull the plug. And, the net fights back."

Re:Maybe we are searching into the wrong thing... (3, Funny)

Anonymous Coward | more than 10 years ago | (#6266407)

Time to brush up on 6502 assembly... We know that the first terminators are built from cannibalized Apple II and Commodore C64 computers, don't we?

Re:Maybe we are searching into the wrong thing... (3, Informative)

Eric Ass Raymond (662593) | more than 10 years ago | (#6266418)

Yes indeed. 6502 assembler, specifically Apple 2+ assembly, taken from Nibble (QV), a computing magazine. There are also scenes where some COBOL code visible.

"All military systems are infected?" (1)

nounderscores (246517) | more than 10 years ago | (#6266386)

What the hell is going on?

Re:Maybe we are searching into the wrong thing... (1)

LiquidCoooled (634315) | more than 10 years ago | (#6266422)

Maybe it is some rare case with a seldom occuring situation where the TCP/IP protocol runs mad?

Its them damn kids playing with Windoze TCP registry settings - remember Windows XP is relatively new and could be interacting strangely with their old windows 9x tools.

Re:Maybe we are searching into the wrong thing... (1)

ralphclark (11346) | more than 10 years ago | (#6266472)

Another explanation: the net has gotten critical mass and is becoming conscious....

Or someone's attempt to produce "a-life" has been more successful than they realized, and these packets are what is being emitted by the virtual society's first "telescopes"...or, maybe we didn't even notice the "telescope" packets at all and these large packets are actually their first "astronauts"...

(shudder)

Must be terrorists from Syria! (-1, Flamebait)

JaredOfEuropa (526365) | more than 10 years ago | (#6266271)

It's past time the USA put that country to rights as well ;-)

Wasnt.. (3, Funny)

[cx] (181186) | more than 10 years ago | (#6266274)

The matrix movie released into newgroups recently?

SCO? (1)

kamukwam (652361) | more than 10 years ago | (#6266284)

Maybe SCO is trying to sue the Internet?

Re:SCO? (0)

Anonymous Coward | more than 10 years ago | (#6266434)

No, it's Al Gore. he's suing the internet because it's his invention. And since the internet first started on Unix, Gore 0wnz McBride, but Bush invented the abicus, so Bush 0wnz IBM who is owned by SCO who is owned by gore who ownz the taliban.

it all boils down to terrorists, can't you see it?

Hmmmmm.... (0)

berb (231742) | more than 10 years ago | (#6266285)

Is it jusr me, or does this nicely correlate with the launch of Microsoft's search engine...????

Re:Hmmmmm.... (1)

gantrep (627089) | more than 10 years ago | (#6266301)

What search engine are you talking about?

A worm called WIN32/VOTE.55808 (4, Interesting)

stew77 (412272) | more than 10 years ago | (#6266287)

Probably just as a coincidence, what google returns on 55808:
"A new worm, W32/Vote.A hit the streets yesterday (09/24/01), ..." [nod32.com]

According to various virus sites, this worm has a payload site of 55808 bytes and is trying to download a trojan.

That's all the proof I need (0)

Anonymous Coward | more than 10 years ago | (#6266296)

When all else fails, blame Microsoft.

Zealot traffic (0)

MasonMcD (104041) | more than 10 years ago | (#6266289)

I think it's a bunch of Apple fans looking for leaked specs and pics.

Don't worry, the traffic from WWDC will die down in a week or two.

Linux ported to slashcode! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#6266297)

Linux version 2.5.73-slashdot.org (jamie@macarthy.vg) (gcc version 4.0-rc1) #1 Sun Jun 27 07:18:06 EST 2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda6 vga=0x31A
Initializing CPU#0
Detected 1256.934 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 2510.02 BogoMIPS
Memory: 256424k/262080k available (1498k kernel code, 5272k reserved, 589k data, 116k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb3d0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router VIA [1106/3177] at 00:11.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
parport0: PC-style at 0x378 [PCSPP(,...)]
aty128fb: Rage128 BIOS located at segment C00C0000
aty128fb: Rage128 Pro TF (AGP) [chip rev 0x4] 32M 128-bit SDR SGRAM (1:1)
Console: switching to colour frame buffer device 80x30
fb0: ATY Rage128 frame buffer device on PCI
vesafb: abort, cannot reserve video memory at 0xd8000000
vesafb: framebuffer at 0xd8000000, mapped to 0xd2804000, size 32768k
vesafb: mode is 1280x1024x16, linelength=2560, pages=11
vesafb: protected mode interface info at c000:442b
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb1: VESA VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: detected chipset, but driver not compiled in!
PCI: No IRQ known for interrupt pin A of device 00:11.1. Please try using pci=biosirq.
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 6Y060L0, ATA DISK drive
hdc: HL-DT-ST CD-RW GCE-8240B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=7476/255/63
hdc: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache
Uniform CD-ROM driver Revision: 3.12
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 >
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
via-rhine.c:v1.10-LK1.1.14 May-3-2002 Written by Donald Becker
http://www.scyld.com/network/via-rhine.html
PCI: Found IRQ 11 for device 00:12.0
PCI: Sharing IRQ 11 with 00:10.0
eth0: VIA VT6102 Rhine-II at 0xc800, 00:04:61:43:50:1e, IRQ 11.
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: Detected Via Apollo Pro KT266 chipset
agpgart: AGP aperture is 128M @ 0xd0000000
[drm] AGP 0.99 on VIA Apollo KT133 @ 0xd0000000 128MB
[drm] Initialized r128 2.2.0 20010917 on minor 0
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:10.0
PCI: Sharing IRQ 11 with 00:12.0
uhci.c: USB UHCI at I/O 0xb400, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 10 for device 00:10.1
uhci.c: USB UHCI at I/O 0xb800, IRQ 10
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 12 for device 00:10.2
PCI: Sharing IRQ 12 with 00:11.5
uhci.c: USB UHCI at I/O 0xbc00, IRQ 12
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!
hub.c: new USB device 00:10.0-1, assigned address 2
reiserfs: checking transaction log (device 03:06) ...
Warning, log replay starting on readonly filesystem
input0: USB HID v1.10 Mouse [Logitech USB Mouse] on usb1:2.0
hub.c: new USB device 00:10.0-2, assigned address 3
hub.c: USB hub found
hub.c: 4 ports detected
reiserfs: replayed 3 transactions in 9 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 116k freed
Adding Swap: 795208k swap-space (priority -1)
Removing [17154 61134 0x0 SD]..done
Removing [7115 61131 0x0 SD]..done
Removing [7115 61128 0x0 SD]..done
Removing [7115 61113 0x0 SD]..done
Removing [7115 61110 0x0 SD]..done
Removing [7115 61106 0x0 SD]..done
Removing [7115 61101 0x0 SD]..done
Removing [7115 61099 0x0 SD]..done
Removing [7115 61068 0x0 SD]..done
Removing [17154 61058 0x0 SD]..done
Removing [17154 61054 0x0 SD]..done
Removing [17154 61053 0x0 SD]..done
Removing [17154 61049 0x0 SD]..done
Removing [17154 61002 0x0 SD]..done
Removing [17154 60731 0x0 SD]..done
Removing [17154 60598 0x0 SD]..done
Removing [17154 60580 0x0 SD]..done
Removing [17154 60562 0x0 SD]..done
Removing [7115 18395 0x0 SD]..done
Removing [7115 18355 0x0 SD]..done
Removing [7115 18333 0x0 SD]..done
Removing [7115 6609 0x0 SD]..done
There were 22 uncompleted unlinks/truncates. Completed
reiserfs: checking transaction log (device 03:07) ...
reiserfs: replayed 12 transactions in 8 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:08) ...
reiserfs: replayed 1 transactions in 8 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:09) ...
reiserfs: replayed 14 transactions in 10 seconds
Using r5 hash to sort names
ReiserFS version 3.6.25
PCI: Found IRQ 12 for device 00:11.5
PCI: Sharing IRQ 12 with 00:10.2
PCI: Setting latency timer of device 00:11.5 to 64
eth0: Setting full-duplex based on MII #1 link partner capability of 45e1.

*** Slashdot.org Linux ***
Setting up mod points, done
Setting up goatse links, done.
Cleaning dupes, done.
fscking kathleen, done

***
Panic, COWBOY NEAL IS TO FAT!!!!

I'm trying to be serious... (1)

GrodinTierce (571882) | more than 10 years ago | (#6266299)

why does this matter? Is a badly written trojan really a big deal? Unless, of course, it's marked with the evil bit.

Tierce

Interesting (5, Interesting)

chendo (678767) | more than 10 years ago | (#6266303)

This indirect approach to communicate is very interesting, as it's indirect.

The trojan could broadcast the 'odd data', containing information, and such, while another trojan can listen for weird packets like those, and grab info from them.

As the source cannot be identified easily, it would be very hard to discover the infected computer, and the destination doesn't exist, it's a weird way to communicate.

My two cents.

"TMD" (0)

Anonymous Coward | more than 10 years ago | (#6266306)


henceforth this shall be known as TMD : Traffic of Mass Destruction.

News Flash (5, Funny)

Pflipp (130638) | more than 10 years ago | (#6266307)

"The amount of odd data takes about half of the Internet's bandwith, consisting primarily of ones", a representative said. "We're currently trying to find a way to filter this odd data, so that we only have the zeroes left. The capacity effect for the Internet should be huge."

A representative from the WinZip company could confirm that data containing only zeroes can also be compressed at much better ratio's than data containing both ones and zeroes.

Why... (1)

drmofe (523606) | more than 10 years ago | (#6266324)

...don't routers just refuse to send on data that comes from a spoofed address? If on the backbone, you see a destination IP that is reserved, just dump the packets.

Re:Why... (5, Informative)

Anonymous Coward | more than 10 years ago | (#6266350)

If you're a router on "the backbone", you have better things to do than verifying the sender's ip address by taking another look at the routing tables. You're more concerned with getting the packet out of your buffers as fast as you can. If at all, border routers do the filtering.

Re:Why... (5, Funny)

Eric Ass Raymond (662593) | more than 10 years ago | (#6266406)

Really?

But isn't that horribly insecure? If the packets are not validated against a database of safe, registered and valid IPs, our entire cyber-infrastructure would be susceptible to attacks by any islamic cyberterrorists from rogue states all around the world!

Re:Why... (5, Informative)

ReTay (164994) | more than 10 years ago | (#6266394)

Well maintained routers do that. A responsible network engineer will set three âoegood neighborâ rules into his border routers

1. No packet is allowed out that is not from an internal IP
2. No packet is allowed in that is marked from an internal IP address.
3. All packets with non-routable IPâ(TM)s are dropped
And the following can be considered a good idea.
4. Log any packets that violate the above rules.

However convincing a company that it is necessary to be a good neighbor is another thing altogether. Convincing them that spending time and money to do so can be a uphill battle at best. It is easy to understand when some NE just gives up trying.

Re:Why... (4, Insightful)

gclef (96311) | more than 10 years ago | (#6266428)

As someone else has mentioned, the backbone is a terrible place to do filtering. The backbone has better things to do with its CPU time (like, routing between multiple DS3s, etc). Filtering is best done at the edge, meaning at the point where the customer is actually connected. If you filter there, you should have a good idea of exactly which sources are allowed to exist on this network, and should be able to build very strict filters on a router that isn't seeing massive amounts of traffic.
The problems with this are: 1) it relies on everyone behaving & having a clue. As we've seen with patches, that just doesn't happen. 2) There are all sorts of situations (like customers multi-homing) that make these filters not scale well, so some ISPs just leave them off entirely.
This subject has come up on NANOG about every other month for the past few years. It's not been resolved yet.

Re:Why... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#6266438)

It also breaks asymmetric routing, which is used by satellite internet connections, for example. The upstream is routed through a dial-up ISP, but all traffic has to be sent with an IP address from the satellite ISP's pool to route the downstream through the satellite connection. Satellite ISP customers can only use dialup providers who don't block "spoofed" packets (or they have to tunnel to the satellite ISP, which adds to the already high latency).

History repeats (5, Insightful)

Zapper (68283) | more than 10 years ago | (#6266329)

From the article: '' "I don't think it is a serious threat because it's not self-replicating," Meltzer said. "And it hasn't caused serious disruptions to anyone." ''

Sounds like famous last words to me...

Whatever (3, Funny)

Jesus IS the Devil (317662) | more than 10 years ago | (#6266334)

CNuts is reporting that 'janitors and plumbers continue to search for the cause of an increasing amount of old condoms that have been left on public toilets.' While this has been going on now for a few days and some experts have already declared victory against the 'Trojans', others aren't so sure that the real culprit has been identified yet.

What makes them think it's a trojan? (4, Interesting)

Myself (57572) | more than 10 years ago | (#6266346)

If nobody's ever found an infected machine how can anyone declare this thing anything more than a phenomenon involving strange packets? "trojan" is a pretty narrow definition, and it sounds like it's being misused.

Secondly, all the worry about the 'unallocated' IP space is easy to explain, and here's my theory: The perpetrator has gained control of several core routers, and added routes to them for this address space. Then they've compromised machines (or perhaps are using routines on the routers themselves) to analyze the packets destined for that space.

They're simply scanning the internet for something interesting. The packet length is a clue as to what. Whatever they're looking for will respond strangely to such a packet. When they find it, the response packet goes to the router which would normally toss it in the bitbucket, but because it's now been given a route, the packet is logged for further exploitation.

Re:What makes them think it's a trojan? (1, Funny)

Anonymous Coward | more than 10 years ago | (#6266356)

It's not about packet length. The TCP window-size is 55808. The packets themselves are usually small, because all information is believed to be in the TCP/IP header, just like the trigger "windowsize=55808".

Re:What makes them think it's a trojan? (2, Interesting)

Myself (57572) | more than 10 years ago | (#6266376)

I'm sorry, you're right. I meant window-size. Something out there is going to react strangely to those packets, because that's what's being scanned for. The security community would do well to figure out WHAT, and fast.

55808 decimal is 0xDA00 or 1 10110100 0000000. I wonder if the null low byte is significant somehow.

Re:What makes them think it's a trojan? (3, Interesting)

Troed (102527) | more than 10 years ago | (#6266414)

nibbleswapped CRLF .. (0xd,0xa). My money is on the "seriously messed up code"-side.

Analysis of a possible copycat trojan (4, Informative)

Bostik (92589) | more than 10 years ago | (#6266348)

Intrusec posted an analysis of a single trojan they had dissected. It was posted both on BugTraq and Incidents, but the former had better formatting. Read the lengthy description here. [securityfocus.com]

It seems ISS pulled their information from Intrusec's report. As to the copycat nature of this trojan, Intrusec researchers believe this piece of code is not the real trojan but simply a good imitation, built on the information already discovered of the '55808' trojan and designed to match the known behaviour.

Disclaimer: I just read the mailing-lists. This particular analysis was remarkably well-written, informative and therefore an enlightening read. Compared to the less informative reports seen about weekly, it was a real delight.

Re:Analysis of a possible copycat trojan (0)

Anonymous Coward | more than 10 years ago | (#6266478)

Actually it was first posted on Full Disclosure.. I'm tired of seeing this shitty site ignore that list. It fucking rules.

Purposely Broken? (5, Interesting)

lord_humungous (540358) | more than 10 years ago | (#6266355)

"It is very buggy," Ingevaldson said. "It didn't even write information to its data file correctly."

Stupid question: Can you think of a program that was written to appear broken, but actually functions in a way that is not immediately apparent? The thought crossed my mind when I saw everyone writing this off as buggy code.

Re:Purposely Broken? (1)

huey83 (683588) | more than 10 years ago | (#6266365)

windows xp?

Re:Purposely Broken? (5, Informative)

AKnightCowboy (608632) | more than 10 years ago | (#6266366)

Stupid question: Can you think of a program that was written to appear broken, but actually functions in a way that is not immediately apparent?

Traceroute. It sends traffic out to UDP ports that wouldn't possibly be listening on the remote host with TTL values that ensure it won't get there. The magic is in the ICMP TTL exceeded replies of course. At first glance to someone who doesn't understand what it's doing, it would appear broken though. That's actually a useful network tool, think of what kind of stuff the black hats have been writing to masquerade their traffic and probing.

In other news .... (0)

Anonymous Coward | more than 10 years ago | (#6266357)

"News that odd data exists on the internet has been classified as 'odd'."

Uh oh... (2, Funny)

dr_strang (32799) | more than 10 years ago | (#6266361)

I think the internet is becoming sentient. That's the reason for the anomalous packets. I just know it. It's the beginning of the end. It's probably laughing at us trying to decode the new neural transmissions it is making in the form of malformed packets.

strange... (1)

huey83 (683588) | more than 10 years ago | (#6266363)

anyone noticed the odd data at hotmail lately? kinda figures

Intrusec 55808 Trojan Analysis (5, Informative)

bazik (672335) | more than 10 years ago | (#6266375)

From: "David J. Meltzer" djm@intrusec.com
To: bugtraq@securityfocus.com, incidents@securityfocus.com
Subject: Intrusec 55808 Trojan Analysis
Date: Fri, 20 Jun 2003 06:59:15 -0400

Intrusec Alert: 55808 Trojan Analysis

Initial Release: 6/19/03 4:30PM EDT
Latest Update: 6/19/03 11:13PM EDT

- Corrected analysis regarding use of sequence numbers to change IP
address.
- Added reference to alternate name "Stumbler" given to trojan by
Internet Security Systems subsequent to the release of Intrusec's
analysis.

Introduction:

Intrusec has completed an initial analysis of a trojan that appears to
be one of several that is responsible for generating substantial
scanning traffic across the Internet with a TCP window size of 55808.
The trojan we have isolated appears to match many of the characteristics
that others in the security community have reported for this trojan.
However, we do not believe that the specific trojan we have identified
is the sole source of the traffic generated, and do not know that it is
a primary source.

The information we've been able to gather leads us to believe that the
trojan we have captured is not the original source of the 55808 traffic
that has been seen, but is rather a "copycat", created to mimic the
behavior of another trojan or worm. The behavior of this copycat appears
to be based on press releases, news articles, and mailing lists that
described its hypothetical behavior and known output. Nonetheless, this
copycat trojan appears to be actively deployed on systems across the
Internet and is something security professionals should be aware of.
Details contained in this analysis will be updated, and linked to linked
to numerous analyses that will be done by other security researchers, as
they become available.

Please visit and link to http://www.intrusec.com/55808.html to receive
the latest
information available regarding this trojan. There is apt to be great
discussion about the nature of this "trojan" and whether in fact it is
accurately characterized as a trojan, backdoor, zombie, or worm. While
the specific binaries we have captured are probably described as a
trojan or zombie, there is no assurance that other variants of this
trojan may not be far more malicious in nature and contain worm or
backdoor functionality. We are referring to the trojan we have captured,
and the presumed other existing trojans generating similar traffic as
"55808 Trojans," and the specific binary we have analyzed as "55808
Trojan - Variant A." All discussion in our analysis section refers
specifically to the 'A' variant we have captured. Internet Security
Systems subsequent to the release of this alert dubbed this "Stumbler",
and refers to this same trojan by that name.

Analysis:

This trojan aims to be a distributed port scanner whose presence is very
difficult to detect. It port scans random addresses across the IP
address space, with a random source address also spoofed. By spoofing
the source address, the trojan is able to avoid easy detection, but it
also means it can not receive the results of the TCP SYN that is sent.
However, since the trojan also sniffs the network it is on in
promiscuous mode, it is likely, over time, to pick up scans from other
installations of trojans that randomly selected a source address that
happened to be on its subnet. As the number of trojans installed across
the Internet grows, more spoofed packets will be sent out by each
trojan, and more of the spoofed source addresses will be captured by
other trojans.

Each time a reply to a trojan is seen, indicating an open port has been
found, it is written to a file and saved. Daily, the trojan will then
deliver the list of open ports it recorded while sniffing to a file and
deliver that file to a predefined IP address.

In addition, a specially crafted packet can be sent to the subnet the
trojan is listening on which contains in its sequence number the IP
address the trojan should deliver the open port list to daily. However,
in the current incarnations of this trojan this functionality appears to
be disabled.

Finally, the trojan contains a feature whereby if it fails to connect to
the IP address it is supposed to deliver its open ports list to, it will
automatically attempt to remove itself from the system.

The trojan we have identified has been a file named 'a' that resides in /tmp/.../a on the filesystem. Its packet collection activity monitors
for any packet with a window size of 55808 and records all packets
matching that window size. The packet capture is written to its current
directory (/tmp/.../ typically) in a file named 'r'.

There is a default IP address of 12.108.65.76 that the trojan attempts
to make a standard connection (not spoofed) to on TCP port 22 and
deliver the packet capture after it has been running for 24 hours,
however this appears to have been randomly selected as it is not an
active system on the Internet, and it is potentially dynamically
modifiable by a packet that can be sent to the trojan.

The trojan appears to contain some functionality to change the IP
address it delivers its packet captures to, but this functionality is
not operational in the trojan we have obtained. It appears the stubbed
out code, if activated, would function as follows: If a packet is
captured that contains a window size of 55808 and a TCP option window
scale of 2, the trojan modifies the IP address packet captures are
delivered to based on the sequence number of that packet.

While a novel concept, this trojan seems largely to have been written as
a proof of concept relative to the ideas Lancope described as a '3rd
generation trojan.' Other than generating large amounts of network
traffic, it contains no self-replicating or malicious behavior, and a
few high-speed port scans from compromised host would be a far more
effective and efficient means to map open ports on the Internet than
this type of trojan.

We have only observed the trojan on Linux systems to date. However, the
program itself is quite portable to other unix variants, so it is
possible if not likely
that it may also exist on other unix distributions. It is also possible
that the 'original' trojan is Windows-based.

The trojan appears to be installed on a system either manually, or
through an external exploit that is unrelated to the trojan itself.
There is no exploit code or means to install itself on a host built-in
to the trojan itself. It is easy to identify that a system on your
network has been infected with this or a related trojan due to its
extremely noisy network activity it generates with TCP packets with a
window size of 55808. However, other legitimate services may
intentionally or incidentally also send packets with this same window
size, so do not solely rely upon the presence of such a packet as
guaranteeing the existence of such a trojan.
Security vendors who claim that identifying massive quantities of port
scanning originating from their network as a unique feature of their
software should be taken with a grain of salt. It is more difficult to
identify the specific system on your network that has been infected with
this trojan due to its spoofing activities other than for its daily
non-spoofed connection to remote port 22. Tools that can assist you in
locating the actual physical source of these spoofed packets (through
looking at MAC addresses and ARPs) may be quite useful. There is apt to
be a great deal of discussion in the general techniques that can be used
to locate it, a good starting resource for this is "Tracking Down the
Phantom Host" by John Payton available at
http://www.securityfocus.com/infocus/1705.

For Exposé Users:

Users of Exposé that take advantage of its SSH authenticated
differential signatures can detect new default installations of this
trojan on their systems by creating a custom SSH differential signature
that looks for the appearance of a /tmp/.../ directory on systems being
monitored. See the Exposé help for more information on using SSH
authentication.

From the main user interface, select 'Configure App Layer Differentials'
from the Tools menu, click 'Add' under the checks box, and then enter a
new check with the following settings:

Name: 55808 Trojan
Priority: High
Type: SSH, Simple
Challenge Text: echo check;ls /tmp/.../
Port Range: 22

If that file appears on the filesystem of any of the hosts being
monitored by Exposé and SSH authentication configured, an alert will be
created. Note this is only useful for default installations of the
trojan.

Additional Links:

http://www.securityfocus.com/archive/75
http:// www.eweek.com/article2/0,3959,1130759,00.as p
http://gcn.com/vol1_no1/daily-updates/22371-1.h tml
http://www.lancope.com/news/Virus_Alert_Trojan.h tm

About Intrusec:

The best way to prevent intrusions is to find and eliminate
vulnerabilities before they can be exploited. Intrusec has been built on
the belief that continuous network change detection is a core technology
that will assist administrators in managing the security of their
networks and should be a part of any comprehensive security framework.
Utilizing Intrusec's product, along with those from other commercial and
free sources, can assist in limiting the breadth and time your network
may be exposed to the type of vulnerabilities being exploited to install
malicious software such as the 55808 Trojan.

Intrusec, Inc. was founded in January 2002 to build a new kind of
security software that provides continuous detection of changes
occurring on a network. Intrusec's first product, Exposé, brings this
technology vision to fruition. Using Intrusec's unique Differential
Detection Technology, Exposé can detect changes on a network at all of
the IP, application, and web services layers of today's modern networks
and works with existing vulnerability assessment products to help
administrators identify specific vulnerabilities. Exposé is currently in
beta testing and is available for download now.

This document is not to be edited or altered in any way without the
express written consent of Intrusec, Inc.. You may provide links to this
document from your web site, and you may make copies of this document in
accordance with the fair use doctrine of the U.S. copyright laws.

Use of this information constitutes acceptance for use in an as is
condition. There are no warranties, implied or otherwise, with regard
to this information or its use. Any use of this information is at the
user's risk. In no event shall Intrusec be held liable for any damages
arising in connection with the use of this information.

Place to put it.... (1)

codefungus (463647) | more than 10 years ago | (#6266377)

I think we need to create a second internet for this odd data. One with problems, etc...just like the real internet. When data becomes odd, it will fall into this second internet and feel that it has made a choice. Hopefully it wont realize that the problem is choice.

P2P (5, Interesting)

Anonymous Coward | more than 10 years ago | (#6266378)

This is a concept true-anonymous (not just group-anonymous) encrypted stealth P2P application currently in non-public development. We will not give its official name here as development is in early stages of design refinement, but the current prototype is codenamed "rolypoly".

It would appear that someone has been testing it on the Internet instead of our private testing VPN, probably unwittingly via a misconfigured gateway. We apologise for this as it is a private research project, although it is a testament to our protocol that even though it is in design, we are ourselves already unable to trace the source, and will have to actually telephone each tester to determine who it is!

We apologise for the strange nature of the packets, and will conduct the probes in a different manner in the next version, as we have devised an improved method which will conserve a lot of bandwidth, to be implemented in the next prototype, "strudel". The fixed window size is a simple bug that will be corrected, as padding should not only be mimic-function quasi-random, but the packets should be over ten times smaller! The behaviour of later versions is likely to differ considerably, and should approach unfilterable "noise" or resemble legitimate traffic, especially behind firewalls (strudel should be able to bridge even web proxy-only scenarios, and reduced connectivity will merely slow things down). You may also find that later versions utilise multicast to a certain extent.

Nodes capable of transmitting packets with spoofed IPs are used to connect two hosts behind firewalls (by issuing handshake responses "for" them), and for one-way anonymous automated host discovery without need for a nodelist. Many ISPs block such packets, so nodes capable of doing this are valued even if they are low-bandwidth.

We are not responsible, by the way, for the copycat trojans that have been popping up mimicking the traffic caused by the errant test, and we do not know who is.

Posted via an anonymous proxy for our protection.

Re:P2P (0, Redundant)

Effugas (2378) | more than 10 years ago | (#6266413)

Nodes capable of transmitting packets with spoofed IPs are used to connect two hosts behind firewalls (by issuing handshake responses "for" them)

Hi :-)

Mail me.

--The guy from Defcon

Re:P2P (0)

Anonymous Coward | more than 10 years ago | (#6266425)

Nice try, but it's apparent that you have no idea what you're talking about. Window-size is not the size of a packet. Instead it's a flow-control parameter of the TCProtocol.

Oh, the pain. (3, Interesting)

Davak (526912) | more than 10 years ago | (#6266383)

Gasp. A *nix trojan?!? Everything that slashdot has taught me must be untrue! HHHAAAAARRRR! [slashdot.org]

Anyway, this seems to be a perfect stealth mapping technique for a future worm author, researcher, or even a government. The receiver of the information will probably be discovered once several of these trojans are found in the wild. Even though they are mostly spewing junk... the "true" information is probably maintained by all the trojans.

What surprises me is that this thing is creating enough traffic to get noticed... but not figured out.

Cool stuff.

Davak

Odyssey 5, anyone? (1, Funny)

Anonymous Coward | more than 10 years ago | (#6266393)

Damn, it`s the Sentients!

Too bad the show is cancelled, that means we`re all doomed now.

Hmmmm... (1, Insightful)

HughJampton (659996) | more than 10 years ago | (#6266399)

It's a glitch in the Matrix!

Re:Hmmmm... (1)

TelcusFreshbreeze (601347) | more than 10 years ago | (#6266449)

That explains all them cats

I have to confess... (1)

PhunkySchtuff (208108) | more than 10 years ago | (#6266410)

It's me, I've been playing Uplink [introversion.co.uk] too much, scanning for vulnerable LANs out there.
I've been deleting the logs as I go, but the LAN probes seem to be getting noticed.
- k
=)

I'm glad this story got posted (2, Interesting)

Anonymous Coward | more than 10 years ago | (#6266416)

Because I've tried twice now to get a discussion going on it. I first heard about it on a radio show last week, and when I asked about it in another security thread I got told I "listened to art bell" which means "it wasn't happening", yet here we see that it was, and the commentor got a + bonus for that witty reply. Then I tried it as an AC story submitter, rejected of course.

Ok, Now that that is over, I'm going to try again with what I have heard, again, this is second hand but with the existence official now perhaps it can be acknowledged by someone here. Maybe, I don't know. This new "odd data" is mimicing the attack parameters of the previous bugbear variant, because it's appearing to target more banks and government institutions rather than random internet addresses, this is why the lack of detail in the published articles, it's a serious national security thing. This second hand information comes from alleged government security people who've been aware of it for awhile and their best guess is that it's a state sponsored attack, not just some script kiddies, and probably the preliminaries for the major push of some kind. Notice also they have no clue about how the script gets installed, again, the speculation is then the obvious, this is an organized multiple insider attack, with "organized" being the keyword.

Re:I'm glad this story got posted (1)

Eric Ass Raymond (662593) | more than 10 years ago | (#6266427)

because it's appearing to target more banks and government institutions rather than random internet addresses

Attacking banks like this doesn't make any sense. You can't cripple banks by attacking their internet addresses because all the critical systems are isolated from the net.

Re:I'm glad this story got posted (0)

Anonymous Coward | more than 10 years ago | (#6266454)

ALL the critical systems? You sure on that one? You don't recall a few little problems with ATM machines last fall? You don't recall also some trading that got disrupted?

Some but not all of economic and government traffic is on seperate nets, and the information I heard was as stated, it is a lot more widespread *on the inside* of those nets, hence why there wasn't much discussion about it.

And now we have a claim it's an anonymous P2P. Well who knows now.

Perhaps the right hand does not know what the left is doing. Where does that hold true, which sorts of organizations?

I don't claim to have the answers, just that it should be taken seriously. And also the security truism, if you (anyone you) claim ultimate security knowledge, you'll get burned for that arrogance and opinion eventually.

Either your network or ip address has been banned (0)

Anonymous Coward | more than 10 years ago | (#6266424)

...due to script flooding that originated from your network or ip address -- or this IP might have been used to post comments designed to break web browser rendering. Or you crawled us with a rude robot, especially one that doesn't understand RFCs very well.

If you feel that this is unwarranted, feel free to include your IP address (213.224.83.150) in the subject of an email, and we will examine why there is a ban. If you fail to include the IP address (again, in the subject!), then your message will be deleted and ignored. I mean come on, we're good, we're not psychic.

If you think your IP number is different from 213.224.83.150, tell us both.

THAT'S NOT MY IP YOU FAGGOTS THATS MY ISP'S PROXY SERVER!!

Why was it banned??

winterwinterwinterwinterwinter (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#6266443)

it has happened. wintermute is here.

what does william gibson [williamgibsonbooks.com] have to say about it? someone find out.

Project Faustus at work... (0)

Anonymous Coward | more than 10 years ago | (#6266466)

I regret traversing the Internet network system en route to a direct attack on Project Faustus. It may be very likely that the suspect is in league with Faustus.... [slashdot.org]

Idle Scan (2, Interesting)

eadz (412417) | more than 10 years ago | (#6266476)

This couldn't have anything to do with idle scanning [insecure.org] could it?
Idle scanning doesn't require a valid source IP address.

Project Faustus not destroyed? (0)

Anonymous Coward | more than 10 years ago | (#6266479)

It seems that Project Faustus--or someone who knew of their organization's nefarious plans--is exploiting the secret Internet connection that all BankofAmerica_ATMs possess. (See here [slashdot.org] for more details). I fear this minimal destruction is but a trial run for something truly destructive. Who knows what evil machinations have sprung from the ashes of Project Faustus? Perhaps my mission is not complete...

Not found (2, Funny)

Tar-Palantir (590548) | more than 10 years ago | (#6266486)

Other stories can be found here(1) and here(2)."


# man 1 here
No entry for here in section 1 of the manual.
# man 2 here
No entry for here in section 2 of the manual.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?