This is a guest post from Vladimir Wolstencroft from our friends of aura information security
==================================================================
Mobile messaging applications have been occupying people’s attention and it seems to be all the latest news. Perhaps I should have called my presentation the 19 Billion dollar app but at the time of writing and research I thought the proposed 3 Billion dollar amount for SnapChat was a little ludicrous, who could have known that would have been just a drop in the ocean.
Upon starting, I decided to compare two mobile messaging applications that shared a relatively unique capability, self-destructing messaging. However the applications execute this in two very different ways. Looking at SnapChat with it’s millions of users and supposedly secure ephemeral messaging seemed like a good start. I also wanted something a little more secure, we have all heard and seen “snaps” leaked and displayed online so I had inkling that there might have been some serious holes within the application.
So I decided to choose an application which touted security as one of its selling points, which claimed “military grade” encryption and was so secure that the FBI requested a backdoor be put in because they couldn’t break it. This application is called Wickr.
Like SnapChat, Wickr shared the same service ideals; A self-destructing secure messaging service. However unlike SnapChat they promised the highest standards of encryption and user data protection. Perfect, the research stage was set, two applications, one business model and a lot of reverse engineering!
So I wanted to understand both applications, beginning at a high level and moving as far down as necessary to find holes and vulnerabilities.
My methodology was pretty standard for both applications:
1) Acquire the APK from the android store.
2) Examine the application’s communication.
3) Decompile and reverse the APK to (hopefully) readable Java code.
4) Examine the source.
5) ???
6) Exploit
Taking each application at a time I wanted to test the hypothesis of sending unsolicited messages to unknown users. This I assumed was the driving force behind the ridiculously high offers that these messaging apps receive (basically push advertising to users).
SnapChat was first inline, simply by examining the app’s communications, a few hypothesis formed, so after reversing the APK I could put these hypothesis to the test. Some very interesting information was stored on the client and a very well labeled structure allowed me to re-construct parts of the application that I was actually interested in. One of the first challenges to over-come before even sending messages was actually encrypting and decrypting the image data. Luckily a lot of the functions that handled that data were pretty isolated and rebuilding and weaponising them, proved to be not too difficult.
After that I needed a list of users to test my isolated messaging service on, so employing a few different user enumeration techniques I set about collecting such a list.
All the pieces were in place, all that was required was a delivery mechanism to push the data, and through a little more searching (and a belief that all the previously discovered mistakes would mean there were more to find) I found a delivery mechanism that would allow just such a thing, fully automated, unsolicited message pushing! However a few further surprises and challenges were in store that needed to be solved (at 2am in the middle of the exploit testing and delivery phase).
So what about Wickr? Well following a similar methodology quickly lead down a rabbit hole that required quite a bit of digging to escape from (and a lot of use of hex editors and staring at opcodes).
Wickr definitely raised the bar in terms of security and challenge but why not do a little digging?
Firstly Wickr encrypted all of its communication with the server, claimed to store no user identifying data and “secured” the actual device before use.
Decompiling the APK only further revealed more obfuscation. All the information around encryption, authentication and message generation was stored within a binary (written in C and then compiled into a shared object file).
Delving further down the rabbit hole meant using IDA to examine the binaries and look at what was actually been done under the hood.
However since I controlled the client and had access to all the functions (just in a very convoluted way) meant that I could employ similar techniques in rebuilding the application and generating my own data.
This allowed me to follow similar methods I employed in SnapChat (at a much lower level) and test my hypothesis.
So how secure did they make the application? Well they definitely raised the bar to entry to actually exploit the system, but like all good reverse engineering stories all that is required is a thread. Once you start pulling things tend to unravel, not always in the way you expect.
Interested in more details? Then join me for my talk on mobile messaging security and my story about some very late nights, some highs and lows and more luck than I care to mention.
cheers
Vladimir