Big Honkin' Botnet - 1.5 Million!
A diligent reader from the Netherlands requesting anonymity (lots of folks doing that today) pointed us to this article about a recent botnet bust in the Netherlands. The article is in Dutch, but our reader translates it thusly:
"The botnet in the spotlight by the Dutch National Criminal Investigation unit in the Netherlands, about two weeks ago was found to comprise approximately 1.5 million hacked computers (instead of 100k reported earlier) . This has been discovered by GovCert.nl, the Dutch Computer Emercency Response Team, while dismantling the network of computers infected with a Trojan Horse. Of the total number of infected computers, it was estimated that only 30,000 were located in the Netherlands.
The court of Breda has decided to keep the 19-year old suspect as well as a companion, in custody. This companion is suspected of being responsible for a so-called Denial of Service (DoS) attack after an extortion attempt of a US-based company. Earlier on in the investigation both of them were suspected of being involved in another DoS attack of a US based company.
More arrests related to this investigation are anticipated."
Woohoo! Bad guys in jail. You gotta love that.
From a trend perspective, I've been noting two things, which I've also heard fellow handler that I call Ekim Roop mention. We're seeing some smaller botnets, which are more highly differentiated (that is, a single bad guy might have three or four botnets, each doing one element of a given crime. One set of bots for spamming, another for a distributed web site for phishing, and another to obscure surfing through proxying.) At the same time, we're also seeing some very vast botnets, this time over a million. We may even go higher than that in the future.
Scary stuff. Keep fighting the good fight, dear readers. We must.
Over and out--
--Ed Skoudis
Intelguardians
"The botnet in the spotlight by the Dutch National Criminal Investigation unit in the Netherlands, about two weeks ago was found to comprise approximately 1.5 million hacked computers (instead of 100k reported earlier) . This has been discovered by GovCert.nl, the Dutch Computer Emercency Response Team, while dismantling the network of computers infected with a Trojan Horse. Of the total number of infected computers, it was estimated that only 30,000 were located in the Netherlands.
The court of Breda has decided to keep the 19-year old suspect as well as a companion, in custody. This companion is suspected of being responsible for a so-called Denial of Service (DoS) attack after an extortion attempt of a US-based company. Earlier on in the investigation both of them were suspected of being involved in another DoS attack of a US based company.
More arrests related to this investigation are anticipated."
Woohoo! Bad guys in jail. You gotta love that.
From a trend perspective, I've been noting two things, which I've also heard fellow handler that I call Ekim Roop mention. We're seeing some smaller botnets, which are more highly differentiated (that is, a single bad guy might have three or four botnets, each doing one element of a given crime. One set of bots for spamming, another for a distributed web site for phishing, and another to obscure surfing through proxying.) At the same time, we're also seeing some very vast botnets, this time over a million. We may even go higher than that in the future.
Scary stuff. Keep fighting the good fight, dear readers. We must.
Over and out--
--Ed Skoudis
Intelguardians
Keywords:
0 comment(s)
Sploits Du Jour: Veritas NetBackup & Ethereal. Watch Oracle and Snort!
Lots of new exploits today in the wild, so patch away, patch away, patch away all.
In particular, patch Veritas NetBackup (more info here). Working exploits have been released.
Also, patch Ethereal (more info here). Again, working exploits are available.
Also, as we said the other day, don't forget to check out the crucial Oracle patches.
And, for goodness sakes, patch Snort or shut off the Back Orifice preprocessor! A fully working exploit is likely very near.
Also, a kind reader emphasized the importance of hardening systems today, in light of this Snort vulnerability, mentioning the great Grsecurity package for Linux, as well as the importance of chroot environments. Also, this reader requesting anonymity points out that the Stack-Smash-Protector (SSP) extensions for gcc from IBM makes it harder to exploit buffer overflows, and can be compiled into various executables. It's essentially an update of the venerable StackGuard tool, but more carefully integrated with the compiler itself. As we say in Jersey... "Noice".
In particular, patch Veritas NetBackup (more info here). Working exploits have been released.
Also, patch Ethereal (more info here). Again, working exploits are available.
Also, as we said the other day, don't forget to check out the crucial Oracle patches.
And, for goodness sakes, patch Snort or shut off the Back Orifice preprocessor! A fully working exploit is likely very near.
Also, a kind reader emphasized the importance of hardening systems today, in light of this Snort vulnerability, mentioning the great Grsecurity package for Linux, as well as the importance of chroot environments. Also, this reader requesting anonymity points out that the Stack-Smash-Protector (SSP) extensions for gcc from IBM makes it harder to exploit buffer overflows, and can be compiled into various executables. It's essentially an update of the venerable StackGuard tool, but more carefully integrated with the compiler itself. As we say in Jersey... "Noice".
Keywords:
0 comment(s)
Fraud: Evil People Doing Evil Things
A diligent Internet Storm Center reader pointed us to this site which describes the Digital Age Fraud appearing on many credit cards. We've had a handful of reports of people seeing fraudulent charges on their credit cards for $24.99, and this site describes some of what's happening. We don't know the people who run this site, so be careful. Still, they link to the Secret Service and give some very solid advice for victims of credit card fraud.
Keywords:
0 comment(s)
Back to Green on the Snort BO Buffer Overflow
We've decided to go back to green on the Snort Back Orifice pre-processor buffer overflow vulnerability. The reason for ratcheting down to green is primarily this: if you haven't shut off the Back Orifice preprocessor by now or come up with another work around, you probably aren't going to in the near future. This is still a hugely important issue, but our infocon status is designed to reflect changes in the threat level. So, we're back at green, but reserve the right to go to Yellow or higher if a worm starts to spread using this vulnerability. From our internal deliberations, such a worm would be highly problematic. BTW, as Kyle Haugsness pointed out last night in this article, HD Moore has recently released some piece-parts of a sploit for this flaw in Metasploit. We're very close to full exploitation, so shut off that darn preprocessor ASAP. Also, check with your vendors if you suspect your commercial product may have Snort code in it. Several IDS and IPS tools do, so watch out!
Keywords:
0 comment(s)
Snort BO status update
Here is an update regarding the Snort Back Orifice pre-processor vulnerability...(Kyle Haugsness Oct. 20 05:30 UTC)
When this vulnerability was announced yesterday, I was curious to see how difficult this would be to exploit due to the widespread nature of Snort. After doing a little research on the encryption method in Back Orifice, I was able to develop working exploit code in 2 hours. Bad news!! Of course, we aren't in the business of releasing exploits, so this code is staying private. Now, it appears that HD Moore is very close to having exploit code working as a plugin to metasploit. If we haven't said it loudly enough already, PLEASE UPGRADE your Snort sensors or disable the BO pre-processor if running the vulnerable versions of Snort 2.4 series. I checked the 2.3.2 source tree today and it is not vulnerable.
How about defensive measures? If you are running Snort and are able to upgrade, then the new version should detect the exploit attempt. But I am working on two additional defensive tools. The first is a Snort signature that should catch the exploit attempt. This should be available real soon now (tm).
The second tool may prove to be much more valuable. This tool is necessary because of the fact that the exploit can be triggered on any UDP port (except 31337) and that all Back Orifice traffic is encrypted. I don't want to give away more information at this point, since it will help the exploit writers. The tool is a standalone program that utilizes libpcap to sniff traffic and decode UDP traffic looking for the exploit. It will be useful to folks that can't upgrade their Snort daemon to get the new detection it provides, but still want to see if they are being attacked. Secondly, this will be useful to people running a different IDS system that can't decode the Back Orifice encryption. Third, it will probably be very useful in identifying a global worm outbreak.
Since time is of the essence here, I am hoping to have this tool available very shortly. It will require libpcap and is being developed on Debian Linux. It will not require Snort to be running. Since code portability isn't my strong suit, we may be looking for people to test and port the code to FreeBSD, Solaris, etc. Please drop us an e-mail if you would be willing to help in this area. The source code is currently about 800 lines.
When this vulnerability was announced yesterday, I was curious to see how difficult this would be to exploit due to the widespread nature of Snort. After doing a little research on the encryption method in Back Orifice, I was able to develop working exploit code in 2 hours. Bad news!! Of course, we aren't in the business of releasing exploits, so this code is staying private. Now, it appears that HD Moore is very close to having exploit code working as a plugin to metasploit. If we haven't said it loudly enough already, PLEASE UPGRADE your Snort sensors or disable the BO pre-processor if running the vulnerable versions of Snort 2.4 series. I checked the 2.3.2 source tree today and it is not vulnerable.
How about defensive measures? If you are running Snort and are able to upgrade, then the new version should detect the exploit attempt. But I am working on two additional defensive tools. The first is a Snort signature that should catch the exploit attempt. This should be available real soon now (tm).
The second tool may prove to be much more valuable. This tool is necessary because of the fact that the exploit can be triggered on any UDP port (except 31337) and that all Back Orifice traffic is encrypted. I don't want to give away more information at this point, since it will help the exploit writers. The tool is a standalone program that utilizes libpcap to sniff traffic and decode UDP traffic looking for the exploit. It will be useful to folks that can't upgrade their Snort daemon to get the new detection it provides, but still want to see if they are being attacked. Secondly, this will be useful to people running a different IDS system that can't decode the Back Orifice encryption. Third, it will probably be very useful in identifying a global worm outbreak.
Since time is of the essence here, I am hoping to have this tool available very shortly. It will require libpcap and is being developed on Debian Linux. It will not require Snort to be running. Since code portability isn't my strong suit, we may be looking for people to test and port the code to FreeBSD, Solaris, etc. Please drop us an e-mail if you would be willing to help in this area. The source code is currently about 800 lines.
Keywords:
0 comment(s)
Infocon Yellow: Snort BO Vulnerability
After some deliberation, we feel that the Snort Back Orifice pre-processor vulnerability could become a big problem very fast. As a result, we turned the Infocon status to 'yellow'.
A number of exploits for this vulnerability has now been published ranging from denial of service to remote code execution exploits.
You have a problem if you run Snort Version 2.4 (other then 2.4.3), and if you have the 'bo' preprocessor enabled.
Why do we think this is a big deal:
Snort before version 2.4 is not vulnerable. Neither is any Snort install that does not have the bo preprocessor enabled.
Please let us know if you see exploits posted, or have other details to share. We expect to stay on 'yellow' for about 12-24 hrs unless there are any new developments.
A number of exploits for this vulnerability has now been published ranging from denial of service to remote code execution exploits.
You have a problem if you run Snort Version 2.4 (other then 2.4.3), and if you have the 'bo' preprocessor enabled.
Why do we think this is a big deal:
- The exploit is rather easy to write. Yes, its specific to a particular binary, but there are a number of common binaries deployed in large numbers.
- It uses a single UDP packet, which can lead to very fast spreading worms.
- The UDP packet can be spoofed, and can use any port combination.
- Snort is very popular. A fast spreading (noisy) UDP worm could lead to local slowdowns/outages.
Snort before version 2.4 is not vulnerable. Neither is any Snort install that does not have the bo preprocessor enabled.
Please let us know if you see exploits posted, or have other details to share. We expect to stay on 'yellow' for about 12-24 hrs unless there are any new developments.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments