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
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.
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).
This couldn't have anything to do with idle scanning could it?
Idle scanning doesn't require a valid source IP address.
From the article:
team leader for Internet Security Systems' X-Force R&D unit, says researchers are studying the Trojan--currently dubbed 55808 for its Windows size
Why can't we have savvy journalists ? Why why why!? (*starts tearing what's left of his hair*)
Something in the articles caught me. In InformationWeek, the "trojan" is said to be linux based. Internet Week said it was Unix. However, the news.com story claims no knowledge about it's afflicted platforms, then links to a Network Assoc. page - claiming it to be windows based?
/* Lobster Stick To Magnet!*/
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.