Actually, to further the theory of coinciding dates, now that I look at my notes, the logic in the worm is more specifically "start spreading after 68 days after October 29". October 29 is the birth date of Joseph Goebbels, Reich Minister of Propaganda.
Given his use of the worm to spread neo-nazi-type propaganda in the past, it's likely that he is indeed a neo-nazi or sympathetic to the cause. However, one thing I've determined from my analysis of the worm is that the download date isn't scheduled to occur until Friday, January 6. The logic in the code is actually "check if date > Jan 5", not "check if date == Jan 5". So then there might not even be a correlation OR a coincidence.
iDefense is hardly a vaporous dot-bomb company - they actually put out very good intelligence, although most of it is stuff you're not likely ever to see unless you are a paying customer. And they've contributed a substantial number of their internal tools for malware analysis to the community. I have a great deal of respect for the analysts working there - maybe you should look into some of the research they've done over the years before you discount them as yet-another snake-oil security company.
As to the number of keystroke loggers increasing, I'd say from my experience in malware analysis they are about right on the numbers - it is becoming a more and more popular method of phishing account data from unsuspecting users, and people aren't often aware of just how much of it is going on. These are real trends that people who are watching the constant flood of malware can see. Now, how would you prefer they get that message out?
This is probably going to re-occur now that a precedent is set. Prepare for every new PHP exploit that comes out to be bundled with Slapper like this. It will probably become the Rbot of the Linux world.
Even more sad, the AV companies couldn't even detect that this was 95% Slapper code! C'mon, the kiddie who released this didn't even strip the debug symbols much less pack it in any way.
Botzor.exe is Zotob.a. Although the name botzor.exe could have existed prior for other IRC bots. The problem here is there are now over a dozen bots of at least there are 5 unique variant families, which all spread via MS05-039. And the media is just calling them all Zotob.
The original Zotob is just Mytob with the MS05-039 component added and the SMTP component removed. Thats all.
Yep, I cringed when I saw it too. The other posters' comments about reporters is right on - you can talk for 15 minutes and give them a clear picture of the issue, but they'll pick the most impacting statements instead of the ones that explain it. And if you happen to say something that sounds fucktarded out-of-context, you can rest assured you'll see that quote in the article:)
Yes, funny funny. In context, though, you have to know the question the reporter asked me, which was, "Do you think this software was a test, or do you think it was malicious?"
It's not a command in the trojan that decrypts the files, it's a program the trojan author sends you after you send him $200. However, the encryption is trivial and just about any reverse-engineer could write a decryptor for you.
I replied to this in the newer thread you posted in, but I thought it would be worthwhile to mention here so as to prevent this from becoming a widespread rumor.
This morning I reproduced the cache poisoning scenario on a Win2K SP4 box and the "prevent cache poisoning" checkbox did stop the attack from working (I can provide you with packet captures and dig results from the tests I did with and without the protection enabled).
At this point it falls on you to obtain further evidence to back up your assertion that SP3 and SP4 are vulnerable, because all indications in my test suggest that they are not.
Well, I spent the morning painstakingly simulating the cache poisoning attack on a Win2K SP4 machine. When the "prevent cache pollution" option is checked in the DNS server properties, it does indeed stop the attack from working.
So, unless you can provide a packet capture or reproducible scenario, I have to assume that your DNS settings are somehow configured to forward to a vulnerable server, or that the manual registry key edit reversed the checkbox setting on your properties tab. If you'd like to confirm your settings and follow up I'd be willing to look at it further. But as it stands, I have to agree with Microsoft's assertion that SP3 and SP4 are secured against this attack by default.
You probably would have been better off sending your findings to handlers@sans.org - you're the first person I've heard say that the fix doesn't work, and since SANS hasn't updated the information, I presume they haven't heard about it yet either.
Despite the fact that your experience contradicts MS and CERT-CC, I'm willing to accept the possibility that because the.com label in the Authority section is technically a subdomain of any.com domain they may be querying, the SecureResponses key doesn't reject it. This would be a fairly big deal (not too big, you realize, since most of the world doesn't use MS DNS servers) that would require some independent testing in order to convince MS to change their stance (and fix the problem for real).
Any chance you captured some of the traffic as it was occuring on your would-be immune servers? Because the poisoning attack from abx4.com is over now, so it will take a bit of work to recreate it in the lab without those servers to conveniently supply the test packets.
The problem is, by hijacking high-traffic sites, they get noticed fairly quickly. Plus the servers they hacked to host their fake search engine could barely keep up with the load, making all the extra traffic futile.
If they had kept a lower profile they probably could have gotten away with the hijacking indefinitely - but these guys don't think long-term (fortunately for us). And it looks like they've stopped the hijacking for now, probably only due to the attention they've gotten in the press in the last week.
I wrote this article about the source and motivations of the attack (also mentioned by the Washington Post blog), so SANS is not the only security organization talking about it. But there's a reason you're not hearing alarm bells all over.
Basically it comes down to this - the attack was used to hijack searches for pay-per-click engines. It was done in the most obvious way and got a lot of attention. If they had been smarter, they would only have redirected defunct sites instead of cnn.com and the rest of the.com TLD.
Now that the cat is out of the bag, people are watching for the traffic, so a second, more malicious attack probably won't see nearly as much success. So there's no reason to panic - it's a 4-year-old vulnerability as it is, and fixed by a simple registry edit. Most people will be unaffected by it.
Yahoo, Earthlink and Ebay are not spreading the trojan; they are just the targets for the phishing the trojan performs. Sites like Kelly Blue Book and BuyMicro were actually spreading the trojan through compromised IIS servers.
My writeup of the trojan and the incident is here:
Re:Ugh...
on
A Worm's Worm
·
· Score: 4, Informative
This is already happening. Agobot is a GPLed malware project. Although it's not quite a worm, it can spread unattended once given the command to do so. Plenty of people are contributing to it (although some of them have been arrested in the past few days) and the feature list is quickly growing.
Who told you that? I've analyzed both, and there is no relation between them at all in terms of code. The source code to Phatbot is public, and the compiled binary is around 250-300K as opposed to Sasser's 15K. Maybe you're thinking about Phatbot being a derivative of Agobot.
The randomness of the TCP ISN generator doesn't matter. The fact is, you don't need to guess the current sequence number in the connection. If you guess *any* sequence number in the window ahead of the current sequence number, it's just as good. So all you need to do is count from 0x0-0xffffffff by increments of just under the TCP window size. You can hit the right number within a few minutes if you already know the source and destination ports and you have sufficient bandwidth. Longer if you have to guess the source port.
Watson has apparently found a way to guess a valid sequence number if as little as four tries
I don't see that in the article. That would be a cool trick, but I don't see how it would be possible. It's still pretty easy though, since you only have to guess in increments just under the window size. I just wrote a perl script in about 5 minutes to send spoofed RSTs through the entire range of sequence numbers stepping by a window size of 8000, and was able to kill a test connection in less time than it took to write the script. Given, I already knew the source and destination ports, but for long-lasting connections it's not impossible even if you have to guess the source port. It's going to be a boon for the IRC war kiddies. On the positive side, they can now knock people off IRC without the need to DDoS them and their ISP to death.
Apparently this has been known about for a while. Here's an excerpt from
an IETF draft on BGP vulnerabilities from June 2003. Section 3.2.1.4 specifically
mentions the attack described by Watson:
From http://mirrors.sunsite.dk/drafts/draft-ietf-idr-bg p-vuln-00.txt
3.2.1.4. TCP RST/FIN/FIN-ACK
Event 18: If an attacker were able to spoof a RST, the BGP speaker would bring down the connection, release all associated BGP resources, delete all associated routes and run its decision process. If an attacker were able to spoof a FIN, then data could still be transmitted, but any attempt to receive would receive a notification that the connection is closing. In most cases, this results in the connection being placed in an Idle state, but if the connection is in the OpenSent state at the time, the connection returns to an Active state. Spoofing a RST in this situation requires an attacker to guess a sequence number that is in the proper half of the sending window, generally an easier task than guessing the exact sequence number so as to spoof a FIN. The use of [5] will counter this attack.
But, I have to ask, why aren't existing RBLs like Spamhaus effective. They should be far more effective than the ~40% that I am experiencing.
The answer is simple - many spammers are now querying the RBLs themselves and using the results to pick which proxies to send their spam through.
If you run an RBL, I think that with some analysis you could determine when a spammer is querying your RBL by their traffic pattern - for instance, if a given source is consistently the first to query for a given IP address shortly before a flurry of queries from different sources. Once you can detect the spammers' RBL queries, you could invert the results for the spammers - report all blacklisted hosts as unblacklisted and vice-versa - effectively blocking 100% of their mail at RBL-using sites.
It's not. I spent several hours analyzing it. You can connect to the Gnutella cache servers and see Phatbot clients registered using port 4387. You can portscan the infected hosts, find the mini-ftp server it runs and download the code yourself if you need tangible proof.
The list of *features* as one poster put it is indeed staggering.
Most of these features are part of Agobot. Yet no one disputes its existence.
That, coupled with the silence coming from Symantec, McAfee et al. makes it look fishy.
They're not silent - to them this is just another Agobot variant, one of dozens released in the last few months. And they are not making a big deal about it because it really isn't that much of a threat. If you're running Windows with the latest patches and aren't infected with MyDoom or a Dameware backdoor and aren't using weakly passworded shares, you have nothing to worry about from this trojan.
So that leaves me with 3 questions:
1 - Is it real
Yes.
2 - How do we detect it
With just about any AntiVirus solution.
3 - How do we kill it.
In terms of killing it from one machine: disinfect manually or use a tool from the AV companies. In terms of killing the entire network, you would need to reprogram the Gnutella cache servers it uses to detect and refuse connections from the Phatbots.
Slashdot Mirror
I call dibs on the fortuitous misspelling of "Mob Metality", as a name for a band I may or may not start in the future.
Is there a long history with this virus writer/group?
Two years now and no end in sight.
-Joe
--
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
Actually, to further the theory of coinciding dates, now that I look at my notes, the logic in the worm is more specifically "start spreading after 68 days after October 29". October 29 is the birth date of Joseph Goebbels, Reich Minister of Propaganda.
-Joe
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
Given his use of the worm to spread neo-nazi-type propaganda in the past, it's likely that he is indeed a neo-nazi or sympathetic to the cause. However, one thing I've determined from my analysis of the worm is that the download date isn't scheduled to occur until Friday, January 6. The logic in the code is actually "check if date > Jan 5", not "check if date == Jan 5". So then there might not even be a correlation OR a coincidence.
-Joe
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
iDefense is hardly a vaporous dot-bomb company - they actually put out very good intelligence, although most of it is stuff you're not likely ever to see unless you are a paying customer. And they've contributed a substantial number of their internal tools for malware analysis to the community. I have a great deal of respect for the analysts working there - maybe you should look into some of the research they've done over the years before you discount them as yet-another snake-oil security company.
As to the number of keystroke loggers increasing, I'd say from my experience in malware analysis they are about right on the numbers - it is becoming a more and more popular method of phishing account data from unsuspecting users, and people aren't often aware of just how much of it is going on. These are real trends that people who are watching the constant flood of malware can see. Now, how would you prefer they get that message out?
Even more sad, the AV companies couldn't even detect that this was 95% Slapper code! C'mon, the kiddie who released this didn't even strip the debug symbols much less pack it in any way.
With that said, my writeup of the worm is here:
http://www.lurhq.com/slapperv2.html
Includes some previously unreleased facts about who wrote most of the code recycled in Slapper and in Lupper.
Botzor.exe is Zotob.a. Although the name botzor.exe could have existed prior for other IRC bots. The problem here is there are now over a dozen bots of at least there are 5 unique variant families, which all spread via MS05-039. And the media is just calling them all Zotob.
The original Zotob is just Mytob with the MS05-039 component added and the SMTP component removed. Thats all.
Yep, I cringed when I saw it too. The other posters' comments about reporters is right on - you can talk for 15 minutes and give them a clear picture of the issue, but they'll pick the most impacting statements instead of the ones that explain it. And if you happen to say something that sounds fucktarded out-of-context, you can rest assured you'll see that quote in the article :)
-Joe
--
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
Yes, simple steps as in reverse-engineer and write a decryptor for it. I've already done this, in fact.
-Joe
--
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
Yes, funny funny. In context, though, you have to know the question the reporter asked me, which was, "Do you think this software was a test, or do you think it was malicious?"
-Joe
--
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
It's not a command in the trojan that decrypts the files, it's a program the trojan author sends you after you send him $200. However, the encryption is trivial and just about any reverse-engineer could write a decryptor for you.
-Joe
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
I replied to this in the newer thread you posted in, but I thought it would be worthwhile to mention here so as to prevent this from becoming a widespread rumor.
This morning I reproduced the cache poisoning scenario on a Win2K SP4 box and the "prevent cache poisoning" checkbox did stop the attack from working (I can provide you with packet captures and dig results from the tests I did with and without the protection enabled).
At this point it falls on you to obtain further evidence to back up your assertion that SP3 and SP4 are vulnerable, because all indications in my test suggest that they are not.
Well, I spent the morning painstakingly simulating the cache poisoning attack on a Win2K SP4 machine. When the "prevent cache pollution" option is checked in the DNS server properties, it does indeed stop the attack from working.
So, unless you can provide a packet capture or reproducible scenario, I have to assume that your DNS settings are somehow configured to forward to a vulnerable server, or that the manual registry key edit reversed the checkbox setting on your properties tab. If you'd like to confirm your settings and follow up I'd be willing to look at it further. But as it stands, I have to agree with Microsoft's assertion that SP3 and SP4 are secured against this attack by default.
You probably would have been better off sending your findings to handlers@sans.org - you're the first person I've heard say that the fix doesn't work, and since SANS hasn't updated the information, I presume they haven't heard about it yet either.
.com label in the Authority section is technically a subdomain of any .com domain they may be querying, the SecureResponses key doesn't reject it. This would be a fairly big deal (not too big, you realize, since most of the world doesn't use MS DNS servers) that would require some independent testing in order to convince MS to change their stance (and fix the problem for real).
Despite the fact that your experience contradicts MS and CERT-CC, I'm willing to accept the possibility that because the
Any chance you captured some of the traffic as it was occuring on your would-be immune servers? Because the poisoning attack from abx4.com is over now, so it will take a bit of work to recreate it in the lab without those servers to conveniently supply the test packets.
The problem is, by hijacking high-traffic sites, they get noticed fairly quickly. Plus the servers they hacked to host their fake search engine could barely keep up with the load, making all the extra traffic futile.
If they had kept a lower profile they probably could have gotten away with the hijacking indefinitely - but these guys don't think long-term (fortunately for us). And it looks like they've stopped the hijacking for now, probably only due to the attention they've gotten in the press in the last week.
Basically it comes down to this - the attack was used to hijack searches for pay-per-click engines. It was done in the most obvious way and got a lot of attention. If they had been smarter, they would only have redirected defunct sites instead of cnn.com and the rest of the .com TLD.
Now that the cat is out of the bag, people are watching for the traffic, so a second, more malicious attack probably won't see nearly as much success. So there's no reason to panic - it's a 4-year-old vulnerability as it is, and fixed by a simple registry edit. Most people will be unaffected by it.
-Joe
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
My writeup of the trojan and the incident is here:
http://www.lurhq.com/berbew.html
This is already happening. Agobot is a GPLed malware project. Although it's not quite a worm, it can spread unattended once given the command to do so. Plenty of people are contributing to it (although some of them have been arrested in the past few days) and the feature list is quickly growing.
Who told you that? I've analyzed both, and there is no relation between them at all in terms of code. The source code to Phatbot is public, and the compiled binary is around 250-300K as opposed to Sasser's 15K. Maybe you're thinking about Phatbot being a derivative of Agobot.
My writeups of both can be found here:
http://www.lurhq.com/phatbot.html
http://www.lurhq.com/sasser.html
Heh. Reporters. I'm going to assume that quote from Yahoo is just plain incorrect and go by what the advisory content says.
The randomness of the TCP ISN generator doesn't matter. The fact is, you don't need to guess the current sequence number in the connection. If you guess *any* sequence number in the window ahead of the current sequence number, it's just as good. So all you need to do is count from 0x0-0xffffffff by increments of just under the TCP window size. You can hit the right number within a few minutes if you already know the source and destination ports and you have sufficient bandwidth. Longer if you have to guess the source port.
I don't see that in the article. That would be a cool trick, but I don't see how it would be possible. It's still pretty easy though, since you only have to guess in increments just under the window size. I just wrote a perl script in about 5 minutes to send spoofed RSTs through the entire range of sequence numbers stepping by a window size of 8000, and was able to kill a test connection in less time than it took to write the script. Given, I already knew the source and destination ports, but for long-lasting connections it's not impossible even if you have to guess the source port. It's going to be a boon for the IRC war kiddies. On the positive side, they can now knock people off IRC without the need to DDoS them and their ISP to death.
3.2.1.4. TCP RST/FIN/FIN-ACK
The answer is simple - many spammers are now querying the RBLs themselves and using the results to pick which proxies to send their spam through.
If you run an RBL, I think that with some analysis you could determine when a spammer is querying your RBL by their traffic pattern - for instance, if a given source is consistently the first to query for a given IP address shortly before a flurry of queries from different sources. Once you can detect the spammers' RBL queries, you could invert the results for the spammers - report all blacklisted hosts as unblacklisted and vice-versa - effectively blocking 100% of their mail at RBL-using sites.
It's not. I spent several hours analyzing it. You can connect to the Gnutella cache servers and see Phatbot clients registered using port 4387. You can portscan the infected hosts, find the mini-ftp server it runs and download the code yourself if you need tangible proof.
The list of *features* as one poster put it is indeed staggering.
Most of these features are part of Agobot. Yet no one disputes its existence.
That, coupled with the silence coming from Symantec, McAfee et al. makes it look fishy.
They're not silent - to them this is just another Agobot variant, one of dozens released in the last few months. And they are not making a big deal about it because it really isn't that much of a threat. If you're running Windows with the latest patches and aren't infected with MyDoom or a Dameware backdoor and aren't using weakly passworded shares, you have nothing to worry about from this trojan.
So that leaves me with 3 questions:
1 - Is it real
Yes.
2 - How do we detect it
With just about any AntiVirus solution.
3 - How do we kill it.
In terms of killing it from one machine: disinfect manually or use a tool from the AV companies. In terms of killing the entire network, you would need to reprogram the Gnutella cache servers it uses to detect and refuse connections from the Phatbots.
-Joe