SMB2 remote exploit released

Published: 2009-09-16
Last Updated: 2009-09-16 21:15:36 UTC
by Bojan Zdrnja (Version: 1)
2 comment(s)

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.

--
Bojan

2 comment(s)

IETF Draft for Remediation of Bots in ISP Networks

Published: 2009-09-16
Last Updated: 2009-09-16 19:07:04 UTC
by Raul Siles (Version: 3)
2 comment(s)

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:

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! :)

--
Raul Siles
www.raulsiles.com

Keywords: botnet IETF ISP
2 comment(s)

Review the security controls of your Web Applications... all them!

Published: 2009-09-16
Last Updated: 2009-09-16 13:01:30 UTC
by Raul Siles (Version: 1)
0 comment(s)

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!

--
Raul Siles
www.raulsiles.com

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!

 

0 comment(s)

Wireshark 1.2.2 (and 1.0.9) is out!

Published: 2009-09-16
Last Updated: 2009-09-16 06:48:01 UTC
by Raul Siles (Version: 1)
0 comment(s)

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.

--
Raul Siles
www.raulsiles.com

Keywords: wireshark
0 comment(s)

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives