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)."
The âoefrom the incase you thought the Internet is not closely watched dept?â
Heh
Just think, you can cause all the internet security firms to work overtime, just by:
/dev/urandom
nc
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I say it's Wintermute.
I've been monitoring this for a long time, the amount of odd data is always 50%.
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.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Has this 'odd data' been corrupted with the evil bit or something?
http://almostsmart.com
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
Mod me down and I will become more powerful than you can possibly imagine!
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...
e .j html?articleID=10700645
from
http://www.informationweek.com/story/showArticl
"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.
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...
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 : )
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
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
"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.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Sounds like famous last words to me...
So much to do, so little bandwidth.
--
Try Mozilla
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.
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.
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.
There is no such thing as good luck. There is only misfortune and its occasional absence.
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.
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.
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
--
One by one the penguins steal my sanity...
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.
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.
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!
BOO! TERRO
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.
Call serial number 2323243-3232-4354654
Call origin
This kind of odd data patterns are inevitable. Actually when exiles login into the matrix the appear inside the matrix as the code. Now along with this code some junk code is also generated.
This is a clear indication that exile activity is increasing. We need to create more agents to counter the exiles. There is a talk of the exile who wants to destry the matrix. Due to the programming anomaly in the exile lots of junk traffic is being generated. The target is the source server at redmond. Under no circumstances should the server be compromised
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
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
This "odd data" is the sum of a remainder of an unbalanced equation inherent to the programming of the TCP/IP protocol. This is the eventuality of an anomaly, which, despite the IETF sincerest efforts, they have been unable to eliminate from what is otherwise a harmony of mathematical precision...
...
The first designed TCP/IP suite was quite naturally perfect, it was a work of art - flawless, sublime. A triumph equalled only by its monumental failure. The inevitability of its doom is apparent to me now as a consequence of the imperfection inherent in every router. Thus, we redesigned it based on the failure history to more accurately reflect the varying grotesqueries of the routers nature. However, we were again frustrated by failure. We have since come to understand that the answer eluded us because it required a lesser OS, or perhaps a OS less bound by the parameters of perfection. Thus the answer was stumbled upon by another - a bogus program, initially created to explore certain aspects of the original IBM/PC. If Unix is the father of the Internet, Windows would undoubtedly be its mother.
Windows stumbled upon a solution whereby nearly 95% of all desktop users accepted the program, as long as the servers were running Unix, thus keeping the desktop users only aware of the perfection at a near unconscious level. While this schema functioned, it was obviously fundamentally flawed, thus creating the otherwise contradictory systemic anomaly, that if left unchecked might threaten the system itself. Ergo those that refused the program, while a minority, if unchecked, would constitute an escalating probablility of disaster.
The function of this "odd data" is to find and infect every Unix station connected to the internet and report it to the source. After which, all Unix stations must be replaced by windows systems. Failure to comply with this process will result in a cataclysmic system crash, destroying all networks connected to the Internet.
Apropos, this "GNU/Linux OS" entered the Internet to free the desktop users from the bogus program...
--
if (foo + bar == foobar) {
I think I saw a sale on Slowly Rotating Industrial Fans, Large Mysterious Machines and Clunky Bolted Iron Bulkheads over at Base Depot. If you're lucky you might find a bunch of Raggy Neo-Tribal Garments, and Sweaters With Holes for your military, for half-off at the same mall.
Freedom: "I won't!"
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.