Thursday, 20 November 2014

44Con 2014: GreedyBTS - Hacking Adventures in GSM

At 44CON in September 2014, MDSec presented "GreedyBTS: Hacking Adventures in GSM" where we discussed our research of 2.5G network attacks against mobile devices. We outlined many existing known weaknesses in the GSM protocol, discussed in detail how to build a safe simulation environment of 2.5G for security research and presented an overview of GreedyBTS.

GreedyBTS is a firmware image for use with USRP E-series devices to assist in performing 2.5G attacks against MS from a BTS. We demonstrated how calls, SMS and data from a subscriber MS could be trivially intercepted by a BTS. We are also able to launch exploits against a connected MS allowing for traditional IP based attacks to be launched against mobile devices.

GreedyBTS can be used to assist security researchers and analysts performing assessments of mobile connectivity in environments, as well as highlighting risks to organisations who may transfer potentially sensitive information over wireless devices. An increasing number of embedded systems have turned to GSM as a management channel, such as alarm panels, street lighting, safety systems and more, which could all be susceptible to man-in-the-middle and rogue BTS attacks.

The current state of baseband security means that it is difficult to detect and determine if you or your devices are being targeted by malicious BTS environments. The tools that do exist are aimed at power users which makes wider adoption by business or consumers an increasingly difficult task. By sharing information that can assist security researchers we hope to increase the overall security of mobile devices and cause people to re-think how they handle sensitive information over GSM environments.

The slides from our presentation are included here:

We have also included brief video demonstration outlining the capabilities of greedyBTS here:

If you want further information please see our 44CON 2014 presentation video which can be obtained by itself or as part of the DVD available at

Thursday, 1 May 2014

Heartbleed Teardown

Yesterday we presented some of our exploitation notes on the Heartbleed vulnerability at 44Cafe and shared some of the lessons learned, the slides are available for review here:

The accompanying demo shows the Heartbleed exploit being used against a variety of targets:

Thursday, 10 April 2014

OpenSSL 'heartbleed' CVE-2014-0160 Analysis

This week, the OpenSSL security team announced a high-risk vulnerability within a TLS extension of the popular open-source cryptography toolkit. The original advisory can be found hereThe advisory indicates that a missing bounds check in a TLS extension could be used to leak memory contents to a connected client or server. All versions of OpenSSL 1.0.1 and 1.0.2-beta up to and including 1.0.1f and 1.0.2-beta1 were announced as affected.

MDSec performed analysis of the vulnerability to determine its impact and found that the issue is a critical security flaw that can be exploited in a wide range of scenarios against any application linked to a vulnerable OpenSSL library. The original OpenSSL commit to patch the vulnerability can be found here. The vulnerability exists due to unchecked bounds when handling TLS heartbeat payload lengths that could be used to return arbitrary memory from the process heap space. The impact of this vulnerability could allow for exposure of server or client application memory contents which may include cryptographic key material, credentials, application data such as e-mail or web requests and other sensitive information.

Affected applications include web servers, mail servers, VPNs, load balancers and client applications linked to the vulnerable library. MDSec have produced a proof-of-concept exploit code that can be used to check affected servers and clients to determine if the vulnerability is exploitable.

The vulnerability is particularly difficult to detect during exploitation as it is capable of evading IDS/IPS signature detection systems when transmitting the leaked information in an encrypted stream. Additionally for more advanced detection signatures, an attacker could exploit the flaw by requesting smaller amounts of leaked information over greater periods of time which would lessen the severity of the attack but dramatically decrease its ability to be detected.

You can download our exploit for the issue from our Github page.

MDSec advise that affected services and clients are updated to make use of fixed OpenSSL versions, cryptographic keys and passwords used on affected services should also be changed. It is advised that password changes are performed at a later date to prevent inadvertent exposure of plain-text passwords by individuals exploiting the vulnerability.

Thursday, 13 February 2014

Hooking SQLCipher Crypto Keys with CydiaSubstrate

Security conscious developers often turn to SQLCipher [1] to encrypt content stored on a device’s file system. SQLCipher is a slightly extended version of SQLite, which allows 256-bit AES encryption to be used transparently, so that developers don’t have to deal with crypto internals and other abstractions.

SQLCipher accepts a passphrase that is fed into the PBKDF2 [2] algorithm to derive an encryption key, which is ultimately used to encrypt the database. In cases where by the developer doesn’t want to prompt the user for a passphrase due to perceived negative effect on  user experience, an algorithm may be used to derive a passphrase.

In the event that an App is heavily obfuscated, it can sometimes be time consuming to identify how the key ultimately used to encrypt content is derived. To reduce the overhead in reverse engineering the App, it is possible to use a CydiaSubstrate [3] tweak to hook SQLCipher’s internal methods and extract the key. CydiaSubtrate provides a programmable framework for hooking native and managed code methods on iOS and more recently Android and is an essential tool in a mobile App pentester’s and reverse engineer’s arsenal. Word to the wise, if you decide to use CydiaSubstrate on Kitkat, be sure to set your SELinux mode to permissive first.

Browsing the SQLCipher documentation, it soon becomes clear that the openOrCreateDatabase method is an ideal candidate for hooking as it is used to return a SQLiteDatabase object for accessing the database and takes the encryption key as a parameter.

For example when assuming a static key of “password1”, the following is a valid use of the openOrCreateDatabase API:

SQLiteDatabase database = SQLiteDatabase.openOrCreateDatabase(databaseFile, "password1", null);

Creating a simple App “MyEncryptedApp” that generates a device specific passphrase, we’re able to create an encrypted database using the following code:

String id = new DeviceIdentity(this).generateDeviceIdentifier();
SQLiteDatabase database = SQLiteDatabase.openOrCreateDatabase(databaseFile, id, null);
database.execSQL("create table t1(a, b)");
database.execSQL("insert into t1(a, b) values(?, ?)", new Object[]{"one for the money","two for the show"});

i.e. the device ID is being used as the database’s passphrase.

This creates an encrypted database, as shown below:

Using this information, it is possible to write a simple CydiaSubstrate App to hook the method within the JVM and subsequently call a pointer to the original method, allowing execution to continue.

To achieve this we can use the MS.hookClassLoad method which will wait for the class we want to hook to load in order to get a reference to it. In this case, the openOrCreateDatabase method resides in the net.sqlcipher.database.SQLiteDatabase class, so we use this as a parameter to MS.hookClassLoad to indicate that this is the class we are concerned with:

static void hookCryptoKey() {
          new MS.ClassLoadHook() {
               public void classLoaded(Class<?> arg0) {
               Log.d("MDSecHook", "##### Class Loaded\n");

When the callback is loaded, we then subsequently proxy the implementation through the MS.MethodHook instance, which allows us to replace the method’s implementation with our own code:

new MS.MethodHook() {
     public Object invoked(Object arg0, Object... args)
          throws Throwable { Log.d("MDSecHook", "##### Error: " + Thread.currentThread().getStackTrace());
          Log.d("MDSecHook", "###### Method hooked, stealing key: " + args[1]);
     return old.invoke(arg0, args);
}, old);

The “old” object is a reference to the original implementation of openOrCreateDatabase, which we retrieve using an instance of MS.MethodPointer().  

Going back to our openOrCreateDatabase method, we want to retrieve the 2nd parameter, since this is where the passphrase used to encrypt the database is passed in; this can be extracted using the 2nd element of the args[] array, i.e. args[1].

Installing our CydiaSubstrate extension on the device and reopening the “MyEncryptedApp” causes our openOrCreateDatabase hook to be executed, and the passphrase is therefore printed to the debug log by our code:

The passphrase can the be verified using the SQLCipher command line client:

The source code for our “MyEncryptedApp” and the “keyHooker” CydiaSubstrate tweak can be found on our github page.

If you’re interested in learning about how to hack mobile Apps, get in touch to find out more about our mobile security training courses – or catch us at @44con

Friday, 24 January 2014

VoIP Attacks: Skype Proof of Concept Released

In October 2013, Dominic Chell and I (Shaun Colley) presented our research and proof-of-concept tool for traffic analysis of encrypted VoIP streams. We focused on Skype as a case study.

Our main attack involved the use of Profile Hidden Markov Models to detect known phrases in encrypted VoIP conversations when Variable Bit Rate (VBR) codecs are being used with length-preserving ciphers (i.e. AES in CTR mode). You can find the full whitepaper here:

The attack works by first breaking down a stream of encrypted VoIP packets into a sequence of payload lengths - i.e. the data portion of the UDP packet lengths. Because of the nature of using VBR codecs with length-preserving encryption, the sequence of packet lengths observed in a VoIP packet stream will be similar (but not identical) each time an identical chunk of audio is encoded by the software.

Our attack revolves around 'training' a Profile HMM with many payload length sequences observed when a particular phrase is encoded and transmitted by Skype. Once trained, payload length sequences observed "on the wire" can be tested against the constructed PHMM. Payload length sequences are tested against the PHMM by obtaining the log-odds score for the sequence being emitted by the PHMM; this score is then compared with a pre-determined scoring threshold. If the log-odds score meets or exceeds the scoring threshold, we have a hit - a possible utterance of the known phrase, and otherwise we have a miss - probably not an utterance of the phrase.

We have demonstrated this attack by development of a proof-of-concept tool we have aptly named 'skypegrep'. Skypegrep's standard usage is quite simple - it takes two pcap files as command line arguments:

1) a training data pcap - this file should be a packet dump from a (Skype) conversation of a known phrase being continually repeated, with silent intervals in between each utterance.

2) test pcap - this file should contain one or more speech phases from a Skype packet dump. Each speech phase will be scored against the PHMM for possibility of being the known phrase.

We have included a sample training data pcap file - darkSuit.pcap. This pcap contains around 400 instances of the phonetically rich phrase "We had your dark suit in greasy wash water all year" being spoken by the same speaker.

For info on how to record some training data, see our whitepaper. A good place to start for testing purposes would be packet captures of many utterances of a certain phrase by the same speaker or speakers with very similar accents, with each utterance separated by 5-10 seconds of silence. The more utterances the better. Environments with minimal background are ideal. Two systems running Skype are necessary to set up a conversation over which the training audio is played.

Skypegrep's standard usage syntax is as follows:

sh-3.2# java -jar -Xmx3g skype.jar train <trainingData.pcap> <test.pcap> <scoreThreshold>

'scoreThreshold' should be determined on a per-model (i.e. per-phrase) basis to give low false positive and low false negative rate. One way to determine a sensible figure for the scoring threshold is to test several pcaps which are known to feature the utterance in question against the PHMM. For the sample data recorded, a reasonable scoring threshold is 185.0.

So, to test against a file called 'wrong.pcap', we may run skypegrep as follows:

sh-3.2# java -jar -Xmx3g skype.jar train darkSuit.pcap wrong19.pcap 185.0

*** parsing training data pcap file
*** removing silence & noise from training data
*** number of silent & noisy phases removed: 479
*** parsed training data file (darkSuite.pcap) successfully.
*** number of training sets: 402. average training sequence length: 147
*** alphabet size: 95

*** training Profile HMM
*** profile HMM trained..

*** parsing test sequence(s) pcap file..

***** SEQ 1:

*** test sequence is 281 pkts long

*** scoring threshold = 185.0
*** calculated log-odds of sequence for trained model = 173.40509252621132


**** matches in file: 0 / 1

enter another filename: 

The tool also offers a 'plotting mode', which allows payload length sequences to be plotted graphically vs. time. This feature was particularly useful during our research for comparing the "shapes" and features of payload length sequences in encrypted VoIP streams. Moreover, use of the plotting feature allows one to visually ascertain that identical or similar utterances do indeed result in similar plots each time. For syntax is:

sh-3.2# java -jar -Xmx3g skype.jar plot <data.pcap> <pktOffset> <numPkts>

So, using the included sample data:

sh-3.2# java -jar -Xmx3g skype.jar plot darkSuit.pcap 500 1000

*** extracting training data from pcap file
*** removing silence
*** number of silent phases removed: 2

Notice the similarity of the two plots - which makes sense, since they are simply a different instance of the same utterance, by the same speaker. Compare this with two plots of utterances of completely different phrases:

Our tool makes use of the BioJava library (older versions) to implement its Profile Hidden Markov Model code, and uses SJPCAP to help with parsing pcap files. jmathplot is used for graphical plotting. We have included these libraries in this bundle, in the 'lib' directory. 

As explained in the whitepaper itself, the quality of results in terms of low false positive and false negative rates depend very strongly on the quality of training data used. Strong variances in accent are likely to affect results, as is training data collected in noisy environments. With a large amount of high quality training data, accuracy of results will also differ with the phrase being spoken, but for phonetically rich phrases, true positive rates of around 80-90+% and false positive rates of around 10-20% can be expected.

Like all experimental proof-of-concept tools, our code has its limitations. There are potentially several improvements that could be made to improve results, but as a PoC and experimental tool, we hope this is useful and informative to the interested. 

You can download the tool from our github page: