Although there have been numerous articles posted, I thought I would write about my recent presentation at the RSA Conference on the subject of touchlogging.
Since many people have asked, I got the term touchlogging from this paper. I do not know if it has been used before, but I decided it was a good name for my presentation.
The idea for the project came from a penetration testing engagement for which we compared financial malware on the Windows platform with (potential) malware on mobile platforms. The goal was to find the various components that allowed the malware to capture financial data and see whether it could be moved to the mobile platforms. It was quickly realized that the key component was the keylogging mechanism.
If you read my co-worker Neal Hindocha's recent post "Debugging Android Libraries using IDA" you notice he mentioned using a "custom library loader". We had used this on a recent mobile penetration test to have complete control over some home grown custom native libraries the target application was using.
The biggest problem we were facing with the test was that the library in question was being used for anit-rooting and anti-debug functionality to protect the app, and part of our job was to bypass this and patch it out. Of course, attaching directly to the running Android app to get at the code in this library was problematic, since most of the protections were likely loaded before we could attach.
During a recent test, I encountered a native JNI library used by an Android application. I needed to understand this library and what it did, so the first step was to load the library in IDA to see what it looked like. It did not take long until I realized I was looking at obfuscated code that was doing a lot of manipulation on the stack. Understanding the library through static analysis alone would take a long time, so the best way forward would be to combine static and dynamic analysis.
Having debugged a lot of iOS apps using GDB, I started looking at debugging Android apps with GDB. Until this point, DEX2JAR, Smali and some other tools had been sufficient for my Android reversing requirements.
Some research lead me to a discussion at xda-developers about Android debugging through the remote debugging functionality in IDA.
I purchased a Raspberry Pi a few weeks back. I found that I could power it, a WiFi card and a GPS from my 12000mah Li-Ion battery pack for about 12 hours. What a great way to explore with out having to have a huge laptop or giant battery in my bag.
From that I did a little bit of driving and biking with this tool kit, passively looking for and logging networks. I could have easily used my NinjaTel phone (and will attempt this in the future), but I wanted something that I didn't have to mess with to much and would have a long batter life to "power all the things".From this I found that out of 6,164 APs identified, that only %5 had WEP configured (which is flawed). That is a total of 327 APs that still had WEP enabled. Not to bad as a basic health check. Of course more data would always be better.
This guide should serve as an introduction for those wishing to get into iOS application security testing. It demonstrates grabbing low hanging fruit. This guide will not cover all aspects of iOS application security and therefore should not be used as a fully fledged methodology. The line between web application assessments and mobile assessments is blurred as both consist of client/server models and most apps (if not all) speak HTTP (and hopefully some HTTPS). Many of the vulnerabilities you find will therefore require an intelligent web application security specialist's brain behind that Burp proxy. Incidentally, we have tons of them here at SpiderLabs! :)
The android debug bridge (or ADB for short) is a valuable tool, it is what allows smart phone tinkerers unobstructed access to their device for customization. This said, the debug bridge has a major caveat of being too easily left on, and requiring no authentication before granting access. ADB can expose your phone to anyone who can gain physical access or is on the same network.
Some of the more powerful actions are:
If you’ve used ADB before, you know the standard approach is to access ADB via USB. Turn on USB debugging, plug in your phone to your computer and have fun! The caveat here is, when you unplug your phone, USB debugging is not always turned back off and it is not always apparent that it has been left on. The next time you plug your phone in to a USB port, if debugging was left on you have opened your phone up for attack.
A Blackberry oriented website in the UK was the first to notice an interesting new feature in the most recent developer release of the Blackberry 10 OS. They found what looks like a list of one hundred and six blacklisted passwords. The list would prevent you from using specific words to secure your device.
At first glance this seems like a great idea. People always choose crappy passwords like ‘password’ or ‘123456’ or ‘aaaaaa’. By preventing these words from being used as passwords in the first place you increase your security right? Not really, and actually you probably reduce it a little bit. This list of banned words won’t be a secret; anyone with access to the list can remove those words from a dictionary attack. Sure, one hundred and six words won’t make a huge difference but it will make figuring out the password just a little bit faster.
Luiz Eduardo ( @effffn ) and Rodrigo Montoro ( @spookerlabs ) have presented "Mobile Snitch - Devices telling the world about you" at conferences around the world. Today we share a bit about the mDNS protocol and how it impacts the security landscape.
From the talk abstract:
"In the past few years, we have not only seen a significant growth in use of mobile devices, but also it is not uncommon to see people using more than one mobile device at the same time. The combination of the nature of mobile WiFi device operations along with the lack of user awareness, could lead someone to know things about your life, where've you been, where you work, and even who you are.”
One protocol heavily investigated during testing was Multicast DNS (mDNS). This protocol works by creating a device-unique identifier to register as a hostname via a multicast service on local networks. Although Apple is not the only vendor using mDNS, by default all Apple devices (iPad, iPod, iPhone, Mac Book) have the protocol enabled for their applications.
A read through the IETF draft for mDNS reveals some protocol features that also act as attractive targets from a security perspective:
The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.
mDNS makes network configuration easier for home and small business users. Access to devices is intuitive, their hostnames based on identifiable information such as the user’s or computer’s name, device type, or some combination. While this ease of use is a competitive advantage in the market place, the result is identifiable information being broadcast on any network to which an mDNS enabled device attaches.
Ease of use is also popular in the corporate setting, as the rising interest in Bring Your Own Device (BYOD) policies demonstrates. It is also not uncommon to find consumer-grade devices for use in personal offices or branch locations, devices that may also be equipped with mDNS abilities. As users move from the internal corporate network and into the wider wireless world, they continue to broadcast this identifiable information, at coffee shops, airports, malls, or any other place they jump on a hotspot.
The use of identifiable information is not a strict part of the mDNS protocol, but is the consequence of generating easy-to-use hostnames; remembering random names would be no better than IP addresses. As can be seen in a packet capture of mDNS traffic, Apple devices are particularly open in their default hostname choice of the users’ first and last names.
Basic tshark (wireshark text version) command line
$ tshark -n -T fields -e dns.qry.name -r file.pcap udp.srcport == 5353
Alex Shuker?\x80\x99s MacBook._afpovertcp._tcp.local,Alex Shuker?\x80\x99s MacBook._smb._tcp.local,Alex Shuker?\x80\x99s MacBook._ssh._tcp.local,Alex Shuker?\x80\x99s MacBook._sftp-ssh._tcp.local,Bluetooth DUN @ Alex Shuker?\x80\x99s MacBook._ipp._tcp.local,Alex-Shukers-MacBook.local,Alex-Shukers-MacBook.local
Using users’ first and last names as the hostnames simplifies discovery of more information on them by making basic Internet searches. Plenty can be discovered from information posted at LinkedIn, Twitter, and Facebook. This cannot be overlooked as a valuable source of intelligence for penetration testers, especially for social engineering. Exposure is not limited to the corporate network, but extends to the coffee shop down the block, on to busses and trains, and into the users’ homes.
Also notice, in the above packet capture, the inclusion of service and protocol information, sent in the clear. That’s right; mDNS even provides Passive Port-scanning!
Hostname: Rodrigo.Lab.local with Port Listening: 22
Hostname: Rodrigo.Lab.local with Port Listening: 5900
Care must always be taken to maintain security when using mobile devices in the public spaces. The NSA Security Configurations Guide for OS X recommends disabling the mDNS protocol, and offers a command line method to do so. Apple offers an alterative method in their Knowledge Base. At a minimum, no matter the operating system, mDNS advertisement should be disabled.
Penetration testers may be interested in mDNS Tools, an open source set of tools for exploring Multicast DNS.
Research for Mobile Snitch continues, with a new focus on using mDNS to impersonating different types of information, services, and servers. Look forward to future updates, and provide your feedback on the security implications of mDNS.
Rodrigo "Sp0oKeR" Montoro & Luiz Eduardo
I do a lot of Mobile Application Penetration testing for some of our largest clients. Mobile is the new sexiness and everybody wants in. This means that there is a lot of misunderstanding of how some of the technology works and with misunderstanding, usually comes security flaws and vulnerabilities.
It was with this in mind that I was taken by surprised a few weeks ago by one of these clients, who, in a panicy phone call to me, asked if I had heard of this new iOS vulnerability floating around. It was horrible, they said, and could allow attackers to intercept and steal any data - ANY DATA - on or passing through any iOS device. Why, it could even be done via a drive by download.