Last Updated: 2005-10-19 11:17:22 UTC
by Johannes Ullrich (Version: 2)
ISS released an advisory regarding a vulnerability in Snort's Back-Orfice pre-processor. The vulnerability could be used to execute arbitrary code on the snort sensor. Also, see the advisory at snort.org for more details.
As an immediate step, disable the BO preprocessor, by commenting out this line:
# preprocessor bo
this should eliminate the issue, and these days, Back Orfice is not all that much of a threat compared to other trojan/bots. You should also consider upgrading to Snort 2.4.3, which will fix the issue.
This vulnerability is "nasty" for a number of reasons. First of all, it takes a single UDP packet to exploit, which isn't good. Secondly, the packet is not limited to a particular port, making detection more difficult. Its a simple buffer overflow, so the exploit should show up pretty soon.
The only saving part at this point is that it will unlikely be a "universal" exploit. But we may see some wide spread exploits for common architectures, in particular if pre-compiled binaries are used (Snort on Windows, Redhat, Suse).
How to protect Snort from this and future issues:
- Start by turning off unneeded components at compile time. Do you need all the database plugins? Sure, you can turn them off later. But if its not compiled, it can't be turned on by mistake.
- Review the snort.conf file. If you don't need a pre-processor or an output component, turn it off. The less "crap" you have turned on, the less likely you will get hit.
- Run snort as a non-root user. If you still get "hit", at least the damage is limited.
- Run snort in a chroot jail. This takes a couple minutes to setup, but its not terribly hard.
- Your sensor does not need an IP address. Sure, a single UDP packet will still launch an exploit. But the ability to follow up on a remote/reverse shell are restricted.
- Harden the system. On Linux, use things like grsecurity or SELinux to further harden the system.
- Use remote logging. This way, if the snort box gets 'whacked', you at least got all your logs up to that point.
- Monitor the sensor. Sounds like overkill... but for starters: If your snort box doesn't send any alerts for a day, either your network is down or your sensor is dead.
Last Updated: 2005-10-18 22:57:58 UTC
by Johannes Ullrich (Version: 1)
Last Updated: 2005-10-18 05:18:40 UTC
by Johannes Ullrich (Version: 4)
Later this evening Trend updated their webpage concerning the TROJ_SSPLOIT.A virus to show that it was not MS05-051, but was MS05-012 instead. Thanks Microsoft for updating us on this as well.
Trend Micro reports that they spotted a POC for MS05-051 in the wild. They found it included as a new exploit in other malware. We don't have any details yet beyond what can be found in at Trend Micro. If you find a copy of this malware, please forward it.
Trend Micro states that the malware was written in Visual Basic, which usually indicates some low skilled bot-kid. Kind of odd to see it surface this way, but having it included as a new warhead in existing malware matches past patterns.
Trend Micros virus statistics do not report any "captures" of this exploit in the wild. Not exactly sure if this is just a lab sample, or if it was actually seen in the "wild".
We will update this diary as we learn more.
Last Updated: 2005-10-18 00:09:45 UTC
by Scott Fendley (Version: 2)
In case you have missed the announcement, Tenable security has made the decision of commercializing the popular Nessus security scanner within the next month.
As a result, a project group has been formed to release a GPL fork of the Nessus security scanner in the future. This product will probably undergo a name change to prevent problems with support between the commercial scanner and the new GPL fork. In the meantime, it is located at http://www.gnessus.org/doku.php .
Additionally, Handler Kevin Liston noted that another GPL nessus project is located at http://porz-wahn.berlios.de/homepage/about.php .
Two more GPL projects to mention:
(Thanks Schneelocke for reporting these)
Handler on Duty