Skip navigation
All Places > Metasploit > Blog > 2006 > June

Originally Posted by hdm



The next Black Hat Briefings is scheduled for August 2nd and 3rd in Las Vegas and is immediately followed by Defcon 14. I will be presenting on the next version of the Metasploit Framework, hybrid web-to-native code, and IDS evasion. There are dozens of great talks lined up for Defcon 14, but make sure to catch Valsmith and Chamuco's (of OffensiveComputing fame) talk on attacking malware. These guys do for malware analysis what Metasploit tries to do for exploits.


Metasploit Reloaded (H D Moore)


Metasploit Reloaded
Over the last three years, the Metasploit Framework has evolved from a klunky exploit toolkit to a sleek EIP-popping machine. The latest version of the Framework is the result of nearly two years of development effort and has become a solid platform for security tool development and automation. In this talk, we will demonstrate how to use the new Framework to automate vulnerability assessments, perform penetration testing, and build new security tools that interact with complex network protocols.


Thermoptic Camouflauge: Total IDS Evasion (Brian Caswell and H D Moore)


Thermoptic Camouflauge:
Intrusion detection systems have come a long way since Ptacek and Newsham released their paper on eluding IDS, but the gap between the attackers and the defenders has never been wider. This presentation focuses on the two weakest links in the current generation of intrusion detection solutions: application protocols and resource limitations. Complex protocols often have the most dangerous flaws, yet these protocols are barely supported by most intrusion detection engines. Like any other networking component, intrusion detection gear often has a "fast path" for normal traffic, and a "slow path" for handling exceptions. By seeking out and finding the "slow path", an attacker can control the resource usage of the system and bypass nearly any state engine or signature. This presentation will dive into practical attacks on the current generation of IDS and IPS solutions and demonstrate just how evil a few extra packets can be.


Six Degrees of XSSploitation (Dan Moniz and H D Moore)
Social networking sites such as MySpace have recently been the target of XSS attacks, most notably the "samy is my hero" incident in late 2005. XSS affects a wide variety of sites and back end web technologies, but there are perhaps no more interesting targets than massively popular sites with viral user acquisition growth curves, which allow for exponential XSS worm propagation, as seen in samy's hack. Combine the power of reaching a wide and ever-widening audience with browser exploits (based on the most common browsers with such a broad "normal person" user base) that can affect more than just the browser as we saw with WMF, a insertion and infection method based on transparent XSS, and payloads which can themselves round-trip the exploit code back into the same or other vulnerable sites, and you have a self-healing distributed worm propagation platform with extremely accelerated infection vectors.


Hacking Malware: Offense Is the New Defense (Valsmith and  Danny Quist)
The proliferation of malware is a serious problem, which grows in sophistication and complexity every day, but with this growth, comes a price. The price that malware pays for advanced features and sophistication is increased vulnerability to attack. Malware is a system, just like an OS or application. Systems employ security mechanisms to defend themselves and also suffer from vulnerabilities which can be exploited. Malware is no different. Malware authors are employing constantly evolving techniques including binary obfuscation, anti-debugging and anti-analysis, and built in attacks against protection systems such as anti-virus software and firewalls. This presentation will dig into these techniques and explain the basics. The idea of an open source malware analysis and research community will be explored. All the things the Anti-Virus vendors don't want you to know will be discussed. Methods for bypassing malware's security systems will be presented. These methods include detecting and defeating packers/encoders, hiding the debugger from the malware, and protecting analysis virtual machines. We will hack the malware.

Originally Posted by hdm



Update: It looks like the press wars are starting. Network World and
Information Week have published mostly one-sided articles about our exploit release, while The Channel Insider/PC Mag/eWeek/TechWorld articles cover both sides and even link back to this blog. A few of the articles are so wrong as to be funny, such as TechSpot (they fixed it), which claims that Microsoft released the exploit code. If you have worked with the MSRC in the past and would like to share your experiences, please post a comment!


On June 22nd, we released three new modules for the Metasploit Framework, one of which covered the recent Remote Routing and Access service vulnerability (MS06-025). Today, I received two email messages. One from a Microsoft Security Response Center (MSRC) team member and another from the primary author of the module we released.


The email from MSRC reads: "I recently saw your addition to the framework concerning MS06-025. In talking to REDACTED he mentioned that you may have also identified some addition issues with RRAS that were not addressed by this months release. I just thought I would check in with you and see if it would be possible to get additional details so we investigate and address them accordingly. I hope all is well and appreciate any insight you may be willing to share."


No problem there, a friend of mine relayed that there were some unfixed issues in RRAS, and the MSRC team member is doing their job and following up. I was starting to enjoy getting email from MSRC that didn't end in a vague threat. I replied back with some information about a still-present vulnerability in this service.


Then I read the next email. Nicolas points me to a new Microsoft security advisory and specifically mentions the third paragraph:


Microsoft Security Advisory (921923)


"Microsoft is disappointed that certain security researchers have breached the commonly accepted industry practice of withholding vulnerability data so close to update release and have published exploit code, potentially harming computer users. We continue to urge security researchers to disclose vulnerability information responsibly and allow customers time to deploy updates so they do not aid criminals in their attempt to take advantage of software vulnerabilities."

This sounds familiar...


Lets take a closer look at this paragraph:


"Microsoft is disappointed that certain security researchers..."


This is easy enough, there is only one publicly available exploit, it was written by Nicolas and myself. Lets assume they are referring to us.


"...have breached the commonly accepted industry practice of withholding vulnerability data..."

Microsoft claims that there is a  "commonly accepted industry practice", but my own experience contradicts this. To support this statement, lets review the business services of a few companies in the security industry:


Verisign pays for exclusive rights to new vulnerabilties and sells a limited version of this data to their subscribers. Digital Armaments pays for exclusive rights to new vulnerabilities and then shares the data with its members. Immunity sells access to exploits and vulnerability information, often before the vendor is notified.

This covers the direct sale of information, but what about product vendors that include detailed vulnerability information with their subscription services? A vulnerability scanner can disclose vulnerability details through the act of checking for the flaw. IDS vendors that provide user-visible signatures disclose the exploit vector through the structure and content of their signatures. The vendors behind the two most popular products in each of these categories (Snort and Nessus) both charge for timely access to the most recent plugins and signatures.

A large portion of all vulnerabilities are discovered by "security researchers". How many of these researchers publish detailed vulnerability information on the same day that the vendor releases a patch? A quick review of the last 50 OSVDB entries shows that in almost every case, complete vulnerability details were available on or before the day that a vendor solution was released. The exceptions? Large proprietary software vendors.

We have identified three primary sources of vulnerability information; information brokers, security software vendors, and security researchers. The defacto standard seems to be quite different from what the MSRC is calling the "industry standard". Could it be that they are referring to the commercial software industry and not the security industry? Microsoft has coerced a handful of software vendors to join their Organization for Internet Safety (OIS). The OIS initially consisted of 12 companies, but this has dwindled down since the software vendors began aquiring the security service companies. The result is a group of vendors that actively suppress vulnerability disclosure within their organizations. Jericho (of Attrition/OSVDB) published an excellent description of how the OIS was formed, before the official name of the organization was even known.

so close to update release and have published exploit code, potentially harming computer users."

The vulnerability was disclosed on June 13th and the Metasploit exploit was released on June 22nd. This nine day period is a significant delay in the security world and nine days longer than nearly all of the recent vulnerabilties added to the OSVDB. Even dial-up users can complete an automated update in nine days.


To make things interesting, the exploit we released was actually for a different bug than the one mentioned in the advisory. Nicolas discovered this flaw while trying to figure out the vector for the "official" vulnerability. This is a  common occurrence with proprietary software vendors, since the process of looking for one bug often turns up a dozen more that were never mentioned in any public documents.


Microsoft never mentioned this specific vulnerability in the advisory or to the Microsoft 0-Day Club (Microsoft Security Support Alliance), which meant that no intrusion detection systems were able to detect the Metasploit module at the time of this writing.


The mitigating factors for the RRAS vulnerabilties prevent an anonymous user from exploiting any version of Windows 2000 and all versions of Windows XP that have been upgraded to Service Pack 2. The anonymous cracker risk is limited to Windows XP users that have not upgraded to Service Pack 2 and were unable to install the latest updates during a nine day period.


"We continue to urge security researchers to disclose vulnerability information responsibly and allow customers time to deploy updates so they do not aid criminals in their attempt to take advantage of software vulnerabilities."

Totally irrelevant. We didn't report this bug and nine days is a longer grace period than most vendors receive.


The point of this rant is that Microsoft is doing themselves a disservice by asking for vulnerability information on one hand and then condemning the folks who provide it with the other. The MSRC obviously has some communication issues to resolve and we should take any commentary in their advisories with a large grain of salt.



A few quick updates

Posted by rapid7-admin Jun 8, 2006

Originally Posted by skape



It's been a little while since we've updated, but that doesn't mean that we haven't been busy.  Right now we're working on some changes to alpha release 4.  The most important changes will include major enhancements to some of the core protocol libraries.  We're also planning on rolling out a Windows installer this time around so that people who use Windows can begin to try out the 3.0 version of the framework.  Aside from these things, we've also broken ground on a completely revamped interface for msfweb.  This new interface won't be included in r4.  We've also been busy working on a few other projects.  Here are a few noteworthy items:


Uninformed just published the fourth volume of the Uninformed Journal.


I've updated the system call table on the Metasploit website to include system call numbers for Vista Beta 2.  The good news is that NtAccessCheckAndAuditAlarm hasn't changed system call numbers!  This means that the system call based egghunt for Windows will still work fine. 


Other random interesting news includes the fact Vista Beta 2 now has an implementation of ASLR.  This is a great step forward in terms of security, as ASLR is a good complement to NX.  While Microsoft's implementation is limited to 8 bits of entropy in the 3rd octet, it's enough to shift the odds of a successful attack.  One limitation of the ASLR implementation included in Vista is that it does not have a mechanism that allows it to help prevent against local privilege escalations, such as by randomizing images to different locations based on privilege separations.  There is a good reason for not doing this, though, and it's centered around the memory overhead associated with having to apply relocations once per-randomization. 


From what I've analyzed of Vista's implementation, relocations are applied to the physical pages that are associated with the section object that is created for an image file mapping during a call to nt!MmCreateSection.  In this manner, relocations are applied prior to the first time the image is mapped.  Subsequent mappings of the image will share the same section object and, as such, will share the same set of physical pages that the relocations have been applied to.  These mappings will all attempt to use the new base address that has been assigned to the image.  Overall, the approach taken is very good, but it would indeed incur a non-trivial memory overhead if the operation were to be performed multiple times per-image, such as by randomizing ntdll.dll to a different location between LocalSystem vs. JoeBob.  The benefits, however, may out weigh the memory overhead concerns, especially as we move toward the future.


Also, keep in mind that in order to implement randomizing along privilege separations, Microsoft may only need to randomize a smaller subset of images to another base address.  The reason only a subset would need to be randomized is due to the fact that system processes will tend to rely on fewer DLLs when compared to user processes.  However, as an exception to that point, processes like svchost, which may also run as LocalSystem, are likely to indirectly depend on a larger set of images.  There are also some other technical problems surrounding the randomization certain images, like ntdll.dll.  These few DLLs (ntdll, kernel32, and user32) are assumed by the kernel (and user-mode) to be at the same address in every process for different reasons.  There are trivial solutions to these problems, however, and Microsoft is best fit to implement them given their source-level perspective.


Anyway, that's a bit more about ASLR than I intended to get into.  As for Metasploit, we should be posting some more updates here in the near future about the r4 release.  Stay tuned.

Filter Blog

By date: By tag: