...stuff I do and things I like...

Tuesday, August 22 2017

Mobile Security News Update August 2017

Conferences
    toorcon san diego Aug 28th - Sep 3rd. Dig Deep into FlexiSpy for Android by Kai Lu(@k3vinlusec).

    HITB Singapore August 21-25. The Original Elevat0r - History of a Private Jailbreak by Stefan Esser. The Nightmare of Fragmentation: A Case Study of 200+ Vulnerabilities in Android Phones by BAI GUANGDONG and ZHANG QING.

    Tencent Security Conference, August 30-31. Pointer Authentication by Robert James Turner. Finding iOS vulnerabilities in an easy way by Tiefel Wang and Hao Xu. Bare-metal program tracing on ARM by Ralf-Philipp Weinmann.

    44con 13-15 September London, UK. Inside Android's SafetyNet Attestation: What it can and can't do lessons learned from a large scale deployment by Collin Mulliner.

    BalCCon2k17 Novi Sad, Vojvodina, Serbia. September 15-17. Mobile phone surveillance with BladeRF by Nikola Rasovic.

    T2 October 26-27 Helsinki, Finland. Breaking Tizen by Amihai Neiderman.

    DeepSec Vienna 13-17 November. Normal permissions in Android: An Audiovisual Deception by Constantinos Patsakis. How secure are your VoLTE and VoWiFi calls? by Sreepriya Chalakkal.
Quick Conference Review
    It was good to see everybody in Vegas, even better meeting new people. Especially some folks I wanted to meet for a long time. I had a good time at WOOT, meeting old friends was especially good. Maybe it helped that it was in the CanSecWest hotel. I link a few relevant papers below.

Stefan Esser is running a kickstarter for an iOS Kernel Exploitation Training Course for Development of a freely available online iOS kernel exploitation training course based on iOS 9.3.5 on 32 bit devices. If you are into iOS security you should support Stefan's project!


Ralf is on point as usual:
Pictures of the month:



Links

Saturday, August 05 2017

RE-Canary: Detecting Reverse Engineering with Canary Tokens

This blog post is to provide some more details about my idea that was mentioned on Risky Business #463 by Haroon Meer.

What are Canary Tokens (from Thinkst).
    You'll be familiar with web bugs, the transparent images which track when someone opens an email. They work by embedding a unique URL in a page's image tag, and monitoring incoming GET requests.

    Imagine doing that, but for file reads, database queries, process executions, patterns in log files, Bitcoin transactions or even Linkedin Profile views. Canarytokens does all this and more, letting you implant traps in your production systems rather than setting up separate honeypots.
    ...
    Canary tokens are a free, quick, painless way to help defenders discover they've been breached (by having attackers announce themselves.)


The idea: Embed Canary Tokens into binaries (or application data) to help identify reverse engineering of your software.

Every reverse engineer looks for unique information (often just strings) in the target binary to help understand it. The strings are thrown into Google (or other search engines) with the hope to get additional information. The returned information can be extremely helpful to determine what the software is, what other code is linked in, what versions, etc. Everybody who reverse engineers stuff does this! I personally don't reverse engineer for a living so I asked around to confirm that professionals actually do this (I already knew the answer anyway!).

The plan:
  • Embed unique looking strings into the binary
  • Stand-up web page that contains the string, log access to that page (alert on access)
  • Make Google crawl that page (various tools for that)
  • Ship software

This is pretty straight forward, right? But do you care about somebody who just ran strings on your binary? Likely not! So what's next?

Many applications protect their code and other assets that come with it through different kinds of methods (called obfuscation techniques for this article - even not all of it will be actual obfuscation). The next step for the RE-canaries is to generate canaries and embed them into each obfuscation layer. If someone accesses a more obfuscated canary you know that a certain level of effort was put into reversing your app. This part is really where the creativity of the RE-canary deployment comes into play. This will be highly depended on the specific software, on the protection mechanisms used, the language and framework that app is written in and so on. Mobile apps (I'm a mobile app guy, yeah!) contain API endpoints and URLs and maybe some hardcoded credentials (tokens of course). The URLs have the advantage that you wouldn't need to put up a website. You just make them accessible and add logging and alerting.

The final part of this is automation. You want to automate canary creation and embedding into your built process, so that you can generate unique canaries with each built or major release or whatever fits your software.

In the end it will likely happen that advanced REs are going to use an anonymization service such as TOR when searching for strings or trying out URLs (specifically for URLs!). In this case at least you will know that someone is looking at your stuff and passed a certain skill/time/effort threshold, which I guess in most cases is enough information.

That's it! This idea was inspired heavily by Haroon Meer's Canarytokens a great free service that I use once in awhile!

Comments and feedback is welcome via the usual channels.