Slashdot Mirror
What's Behind The Odd Data?
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)."
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.....
Keep open minded - but not that open your brain falls out...
Probably just as a coincidence, what google returns on 55808: ..."
"A new worm, W32/Vote.A hit the streets yesterday (09/24/01),
According to various virus sites, this worm has a payload site of 55808 bytes and is trying to download a trojan.
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.
Founder of Mirror Moon - Tsukihime Game Trans
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. 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.
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
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.
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.
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.
Gasp. A *nix trojan?!? Everything that slashdot has taught me must be untrue! HHHAAAAARRRR!
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
Anybody decoding the secret message in the initial sequence numbers ;-?
worm #1 works quietly, propagating slowly and with little fanfare, works its way around hiding its signal in the network noise of a popular operating system that's fraught with security holes. if discovered, considered harmless, no payload, no harm done. low priority.
waits. listens.
worm #2 barges around making lots of noise, none of it intelligible. targets servers running a particular server OS, routers, places where network traffic converges, is distributed. propagates to only a few choice locations, distribution points. sends out floods of gibberish to nobody in particular, not necessarily needing a reply.
considered buggy, bothersome but harmless.
worm #1 picks up on the gibber, each of the messages from different distribution points somehow encoded with their point of origin, instructions, parts of a payload. when enough of the message has been reassembled, enough of the network space mapped, worm #1 rebuilds itself. takes action.
a worm with no payload, and a payload with no worm. collaboration. cross-pollenation.
fantasy?
- Entertaining Bits from the Ancient Kernel Tree
Here's my theory. Some clever Zombie author has reasoned that a packet addressed to the actual address of the Zombie or its controller might help security people track it down. So, the real source 'return address' is either hidden inside the actual data packet (encrypted of course) or established in a config file or Registry entry and only changed when an appropriate message is received. And the destination address is deliberately non-existent, but on the same subnet as the actual destination (or there is a compromised router upstream from that subnet that's part of the scheme), which is sniffing for these packets and responding in kind.
The large window size is probably a red herring - the real protocol being used is probably more like UDP than TCP. Or it's been thrown in to befuddle stateful packet filters. Or perhaps the window size is the signal to the sniffer that this protocol is involved - any packet without that window size need not be further examined.
It's a scheme that would also work quite nicely for people living under repressive regimes that want to be able to communicate with human-rights orgs without leaving a trail of bread crumbs back to themselves or their correspondents.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.