All Posts

33 posts

IIS FTP 0-day Exploit Released – Updated

This Monday proof of concept exploit code for a Microsoft IIS FTP vulnerability was posted to the milw0rm site. The code allows the attacker to take control of the machine that runs the vulnerable FTP server and can easily be automated and turned into a mass attack tool by combining it with a scanning tool. In order to be exploitable, the vulnerable FTP server need to allow write access and the creation of directories. Unfortunately, even anonymous write access is good enough to make the server vulnerable, but nevertheless this cuts down on the number of potential targets.

Microsoft acknowledged the vulnerability and published an advisory 975191 this afternoon and list 5.0, 5.1, 6.0 and also 7.0 as affected. The advisory suggests as work-arounds to either disable FTP altogether, limit access to only authorized and named users or use NTFS capabilities to prohibit the creation of directories on the server. The NTFS solution seems to be the way to go for users that cannot make a bigger change to their FTP services and has minimal impact, so it is a good interim solution until a real patch comes out. We don’t expect this problem to be addressed in next week’s Patch Tuesday release as the Development and QA time are too long; it makes sense to prepare for a longer period without a real solution. An alternate way of dealing with the problem is to evaluate whether a robust FTP server with more granular management capabilities can be deployed instead of the one built-in within IIS.

HD Moore ported the exploit code to his Metasploit project yesterday. This makes it even simpler for IT administrators to demonstrate the existence of the exploit and argue for the deployment of an alternative FTP server.

Updated to include IIS 7.0 as Microsoft amended their advisory on 9/3/2009

Why Companies Need to Expedite Patching

My interview with discussing Laws 2.0 findings presented at Black Hat 2009.

Laws of Vulnerabilites Panel at Black Hat USA 2009


I am delighted to present the Laws 2.0 research at Black Hat and with new data that compares the progress of patching across multiple critical industries. The focus on this talk will be on zero-days vulnerabilities and how organizations deal with them. I will discuss this topic with a panel of leading CISOs and security experts that includes Richard Bejtlich from General Electric, Ed Bellis from Orbitz, Paul Griffiths from Goldman Sachs, Kris Herrin from Heartland Payment Systems and Mark Weatherford from the State of CA. Please join us if you are attending Black Hat USA 2009. I am personally looking forward to the event and participating in all the Black Hat discussions and festivities. More details about this talk here.

Laws 2.0 Declared

Today we declared at the RSA Conference the new Laws of Vulnerabilities 2.0 with focus on 5 critical industry segments. The findings are very interesting and the research shows that most industries are still slow in their patching and remediation efforts. Summary of the new Laws:

Half-Life–The half-life of critical vulnerabilities remained at 30 days across all industries. Comparing individual industries, the Service industry has the shortest half-life of 21 days, Finance ranked second with 23 days, Retail ranked third with 24 days and Manufacturing ranked last with a vulnerability half-life of 51 days.

Prevalence–Sixty percent of the most prevalent and critical vulnerabilities are being replaced by new vulnerabilities on an annual basis.

Persistence–The Laws 2.0 declared that the lifespan of most, if not all vulnerabilities is unlimited and a large percentage of vulnerabilities are never fully fixed.

Exploitation–Eighty percent of vulnerability exploits are now available within single digit days after the vulnerability’s public release.

Full findings are included in the PDF on the side.
Link to Press Release.

Conficker Statistics post April 1st

This weekend we found an interesting pattern when we polled our system-wide QualysGuard statistics around the Conficker vulnerabilities.

Since early February MS08-067, the critical Windows vulnerability that Conficker initially used to infect machines, has been oscillating between the 20 % and 40 % mark, but in general hovering around the 35 % barrier. Then on March 30th, driven by the media coverage around the April 1st wake-up date for the Conficker.C variant and the availability of the QualysGuard remote detection for Conficker, which we released that day, our scanning numbers went through the roof as customers scanned their networks for the presence of the worm.

It is encouraging that the overall numbers for Conficker infections within enterprise networks are in the low single digit percent range – we are assuming that protection by corporate firewalls kept the initial attack vector in check until patching could be performed and other secondary defense mechanisms such as anti-virus and anti-malware were updated.

The interesting pattern however is the drop in the detection rate of the MS08-067 vulnerability starting April 4th. It seems that all the media attention made IT admins either look closer or start looking at all at the underlying problem and apply the fix, as we see a reduction of 25 % in detections which is only comparable to the drop when MS08-067 was first announced.

Conficker Analysis with QualysGuard IDs (QIDs)

Here is a quick breakdown of cases that you might see when you run a QualysGuard scan against your targets:

  1. You have NOT patched MS08-067 and you do NOT have Conficker
    • we will post QID 90464
    • you need to patch as quickly as possible
  2. You have patched MS08-067 and you do NOT have Conficker
    • you are good
    • disable autorun.inf on all machines as this is the secondary vector for Conficker
      there is a QualysGuard Policy Compliance control for this – 1183
  3. You have patched MS08-067 and you have Conficker
    • this is possible, even common as of Conficker B the worm spreads through USB and Network shares through autorun.inf and the infection numbers have gone up quite a bit with the B variant showing that this strategy works. That is why our demo default policy in Policy Compliance recommends disabling autorun.inf on all drives (autorun.inf is very convenient – it is the feature that loads the installer when you insert a CD, but it is also great for Viruses…)
    • we will post QID 1227 because Conficker undoes the MS08-67 patch and puts its own in place (to be able to re-infect the machine through that channel if needed)
  4. You have NOT patched MS08-067 and you have Conficker
    • we will now post QID 1227
    • before yesterday we would:
      • not post anything in the unauthenticated case, as Conficker "patches" for all (but its) intents and purposes MS08-067 and our (and everybody else’s) remote detection is satisfied
      • post QID 1225, if you are running authenticated scans – note however that QID 1225 is an evolving detection, Conficker is extremely smart and does not want to be found, each new variant introduces different behavior and QID 1225 might have to be adapted to it.

More from the Trenches on Developing the Remote Check for Conficker

Here is a bit more information and links on how the detection was implemented and QA’ed at Qualys and other vendors.

  • – all true but skimps over details as to the team involved from Qualys’ side – on Sunday we had 5 people involved until midnight when automatic regression started. On Monday (largely QA at that time), at least at team of 10, reaching out to their individual contacts in the industry to gather as many Conficker samples (A,B,C, D and some other weird ones…) as possible. QA was crucial here as we did not want a false positive, i.e. Qualys ID 1227 fires on hosts that are healthy. We knew that we were OK after the analysis of the nightly regression run (against 100s of machines) showed that we had no unexpected Confickers in our test network. More details here on how to setup a QualysGuard scan for Conficker.
  • – Dan Kaminsky’s blog – the reference, so to speak. It was Dan who pinged Rich Mogull ( to start working on alerting all vendors to the existence of the remote detection (look at Rich’s blog to see that the German researchers have worked for month on determining the behavioral differences between MS08-067 patched and Conficker patched….). He orchestrated the diffusion of the information and coordinated also the first press release on early Monday, where he pointed out that a public, open source tool exists (the python script by Felix and Tillman in Germany) and that well-known scanner vendors will follow up during the day. Dan also posted on Slashdot the same information, but there is very little updated info in the post – as so often in Slashdot the discussion wanders.
  • – this is the site of the German researchers on Conficker – has the link to their paper on the subject, to their scanner and other very useful research tools, including a “vaxcination” which puts an empty dll plus registry entries that fake the real virus into thinking that it its already on the machine.
  • NMAP has some information on their nmap development list the posts at the end give some insight into their rollout process, at some point on Monday code was in their development repository and people could download that, patch the BETA4 release and scan, later Monday 1 PM, they released the BETA5 and declared that the recommended scanner to use…see their release announcement here.
  • nCircle had their announcement linked on Dan’s page – here and here. nCircle’s Twitter post indicates they released around 3 PM on Monday.
  • Tenable published their plug-in for Conficker detection yesterday as well.

Let me know what you see and hear out there – Qualys will monitor statistics for our detections in the next couple of days and once we have relevant data will update you. We are especially interested what the impact will be on patching activity for the MS08-067 vulnerability.

Taming of the Shrew aka Conficker…

Yesterday started great, the weather was excellent, looked like a continuation of a calm weekend – then Dan Kaminsky called…

Researchers in Germany had come up with a way to remotely detect the Conficker worm. His idea was to get that knowledge out to as many scanner vendors as possible and see if we could implement the check ASAP. This new detection method allows IT administrators to remotely detect the Conficker virus directly on the infected machines without needing credentials or an agent installed. For many large enterprises, this represents an opportunity to perform a quick and non-intrusive audit of their patching efforts. We quickly assembled a team to take a look at the code that Felix Leder and Tillman Werner from the University of Bonn had made available in Python and saw no problem in implementing the detection in the QualysGuard scanner. After finishing the development proof-of-concept, we started formalizing the project, creating the necessary branches in our source code system, checking in the new code and started a new build and acceptance testing cycle. Late on Sunday QA had a production grade package that could be used for basic functional testing and then put it through our nightly regression testing cycle. After reviewing the regression results earlier today we released the code to our production systems around 3PM PDT. Qualys press release.

Thanks to Rich Mogull and Dan Kaminsky for bringing this to us. Many Thanks also to Felix and Tillman, excellent work, looking forward to reading your paper on the subject when I regain my breath. Also, special thanks for David Watson and Jose Nasario who helped us by providing Conficker samples for testing.

Reference URLs:

Should JavaScript be Disabled in Adobe Acrobat by Default?

Last week Thursday, February 19 Adobe released an advisory notifying its users of a critical vulnerability in Adobe Reader and Adobe Acrobat version 9 and earlier. The vulnerability can be used by an attacker to take control of the affected system.  Targeted exploits have been reported by a number of security companies (Symantec, McAfee) and the US-CERT has covered the vulnerability in Security Alert TA09-051A. In our QualysGuard product we detect the flaw as a zero day vulnerability – Id: 116234 Adobe Acrobat and Adobe Reader Buffer Overflow (APSA09-01).
Adobe expects to release a patch by March, 11th. In the interim, one can disable JavaScript within Adobe Reader as a work-around.
This is not the first time that the JavaScript component of Adobe Acrobat has been the subject of a vulnerability advisory. In fact there were multiple occurrences in 2008,  in November  Acrobat 8 had a JavaScript vulnerability, as well as in June and in May of 2008.
I have been running without JavaScript in my Adobe Reader for months and I have not noticed any adverse effects in my typical office oriented usage. Should this be the default behavior for Acrobat? In my opinion this is now becoming a best practice security setting, that should only be relaxed based on end-user needs.

To help IT administrators in verifying this configuration setting,  we are providing a check within our Policy Compliance product – "Adobe Reader JavaScript shall be disabled"