Last Updated: 2009-09-16 21:15:36 UTC
by Bojan Zdrnja (Version: 1)
Last week Guy posted a diary (http://isc.sans.org/diary.html?storyid=7093) about a 0-day vulnerability in SMB2 on Windows Vista and Server 2008 operating systems. Back then the exploit only crashed affected systems.
This is already bad enough; however, it just got worse. Yesterday a well known security company added a module for their exploitation product. The module contains the remote exploit for this vulnerability – in other words, any user running this tool can get full access to affected machines.
If the exploit is stable enough, it can _very easily_ be used in a worm, so it can potentially be devastating.
So, if you are running a Windows Vista or Server 2008 machine (Windows 7 RTM is not affected, RC *is*), be sure you apply one of workarounds listed by Microsoft (they are not perfect, but they can help), available here:
- Run a host based firewall which will block access to ports 139 and 445. Please note that the builtin firewall in Windows Vista will automatically block this traffic if your location is set to Public. In other words, if you connect to a wireless network at Starbucks and set this you will be fine, but if you are inside your organization you are probably vulnerable, unless your administrators went one step further and used group policies to properly configure your firewall.
- Disable SMB2. This has some performance impacts, but it's nothing one can't live without until the patch is out. However, it requires modifying the registry.
We will keep an eye on the development and will update the diary as necessary.
Last Updated: 2009-09-16 19:07:04 UTC
by Raul Siles (Version: 3)
A new IETF draft document focused on how ISP's may detect botnet infections by their subscribers, how to notify customers, and end-user recommendations to remediate the infection, has been published today:
- "Recommendations for the Remediation of Bots in ISP Networks"
The document sets the current state-of-the-art, best practices for botnet detection, threat communications between parties, and specially notifications to Internet users via multiple methods: mail, phone, web portals, IM, SMS, etc.
The authors are looking for feedback from the community, so if you belong to an ISP or are interested in the topic, contact Nirmal Mody (one of the authors) by e-mail. The contact details are at the end of the IETF draft document.
UPDATE: Fellow handler Donald (Thanks!) shared a similar ISP initiative by the IIA (Internet Industry Association). It is also in draft state and open for comments. The IIA guide file is available at http://iia.net.au/index.php/initiatives/isps-guide.html. Time for the ISP's to contribute! :)
Last Updated: 2009-09-16 13:01:30 UTC
by Raul Siles (Version: 1)
Are you applying consistent security controls to all the input vectors of your Web Applications? Attackers are finding these inconsistencies and flaws... and exploiting them!
Robert (Thanks!) sent us a link to a blog post by Ryan Barnett (WASC & OWASP), "Distributed Brute Force Attacks Against Yahoo" . It is an awesome educational example of how important it is to apply consistent security controls to all the input vectors of your Web Applications, and specially, when new functionality is added. Are you applying the same controls to the access through your standard web page, and the access through your brand new Web Services API? The best way of setting up this is through a common security library that implements all your security controls and it is invoked from all the web entry points. If your development team doesn't know how to start implementing this, a good community reference is the OWASP Enterprise Security API (ESAPI) library.
In this incident, the problem lies in the lack of strict controls in the authentication mechanism to Yahoo's infrastructure when the access is performed through the Web Services API. They failed to implement security 101 on the Web Services input, as not only the CAPTCHA control to avoid brute forcing is not available, but the error messages disclose what portion of the credentials is wrong, username or password :( Attackers found it.
Another good example I like to use when teaching Web-App security and pen-testing is the inconsistent XSS filtering MySpace established when their mobile functionality was added back in early 2008. Let's learn from the big web players and avoid the same mistakes in our web environments!
Consistency and thoroughness are key elements to keep the security level of your complex web infrastructure in shape!
Shameless plug: I will be teaching the "Web App Penetration Testing and Ethical Hacking" (SEC542) class in London at the end of November, 2009. Hope to see some of our ISC readers there!
Last Updated: 2009-09-16 06:48:01 UTC
by Raul Siles (Version: 1)
The Wireshark team has released a new version of the famous graphical traffic sniffer and protocol analyzer, 1.2.2 (and 1.0.9 for those still running the old stable branch), due to multiple security vulnerabilities affecting the GSM, OpcUa, and TLS dissectors (the latter is specially relevant), plus fixes for other memory leaks. An attacker might force Wireshark to crash remotely during live captures or by convincing someone to read a malformed packet trace file.
More information in the official advisory page and release notes. Time to update Wireshark! If for any reason you cannot update, please, disable these three dissectors following the steps in the advisory.