Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: mobile

DEEPSEC: SMS Fuzzing – SIM Toolkit Attack

SMS Fuzzing – SIM Toolkit Attack

Bogdan Alecu

SMS is a unique mobile attack vector as it is an always on service. Regardless of wether or not you’re using another application, an SMS can be received by the phone. As SMS is enabled by default on all phones it provides many interesting possibilities.

Tools Used

  • PDUSpy
    • Used to decode the binary message
  • Nokia 3300
    • Used for capturing
    • F-BUS cable
  • dct3tap
  • Wireshark
    • GSMTAP and SIMCARD patches
  • Gemalto GemPC SIM Card reader

SIM Application Toolkit

Provides value added services for the mobile operators.
Basically a set of commands written on the SIM card which helps the card to communicate with the mobile device.
We are particularly interested in the following data on the SIM Card
  • Data download via SMS Point to Point

When this service is enabled, it instructs the mobile device to respond to short message with varying protocol identifiers. This allows an attacker to send a message that goes straight to the SIM and is not shown to the user (the screen may light up on set phones).

By setting the second byte it is possible to trigger a delivery report. Setting the acknowledgement receipt via DELIVERY REPORT can result in any further messages being queued up until after the initial message expires (time out dependent on provider).

The person receiving the call is charged for the Acknowledgement at the standard rate of the provider. This is involuntary as the person receiving the message receives no warning.

Problem reported as cve-2010-3612 (currently reserved)

Vulnerability tested on multiple phones incl Nokia, Samsung Galaxy S, ….


  • Works independently of the phone or GSM network
  • When sending the message between different networks or the same network it doesn’t have such a great financial impact
  • There are providers that allow you to spoof source numbers –> Think premium rate numbers

By spoofing the source address you can set a premium rate source (attacker owned) and have the credit stolen from a victims phone without notification.


  • Most protects require operator assistance.
  • Some mobile devices have the ability to ask the user about SIM actions (other than Nokia ?)
  • Use a SIM Card that has the service “data download via SMS Point to Point” deactivated or one without any Toolkit Application

Links :

  • SMS Fuzzing – SIM Toolkit Attack –> Overview
  • SMS Fuzzing – SIM Toolkit Attack Slides –> Link

Shmoocon 2011: Attacking 3G and 4G mobile telecommunications networks

Attacking 3G and 4G mobile telecommunications networks

Enno Rey, Rene Graf & Daniel Mende


No demos today due to shipping materials and the like. TSA don’t like big electronic devices being shipped after all.

Still, that doesn’t mean there was no practical research.



In mobile telco world everything is standardized by 3GPP

  • 3GPP: collaboration between groups of telco standards orgs
  • 3GPP: standard structured as/bundled in releases
    • 1992: Phase 1
    • 2000: Release 99 (incl first spec of 3G UMTS)
    • 2008: Release 8

2 Elements. 1 facing the internet and the other facing the mobile network

4G Network

4G networks change the names and functions of some devices.

Transport Layer: UDP or SCTP (mostly)

There could be some TCP elements, but none that have been seen in this research.

Generic Packed Tunneling: GTP

All types of signaling:

  • S1AP
  • X2AP
  • GTP-C

Authentication: DIAMETER


  • L2TP
  • DSMIPv6

SCTP Overview

Stream Control Transmission Protocol

General purpose layer 4 protocol

Specified by the IETF

Uses elements from TCP and UDP to cover all required functionality of both.

SCTP – 4 way handshake


Several different RFCs covering SCTP (starting with RFC2960).

Current tools don’t work very well due to SCTP rewrites in RFC5206 and RFC4960

  • NMAP SCTP doesn’t work “in a satisfactory manner”
  • SCTPscan no long work

Attacks from within the mobile telco networks

  • Attacks from the backhaul networks
  • Attacks from the Core network
  • Attacks from Management networks

Backhaul networks

Mobile backhaul

Carries data from the RAN to the management network and back

4G specific requirement laid out by 3GPP


  • eNodeB
  • MME
  • SGW

Can be implemented with different technologies

Originally ATM (in the early years of GSM), PDH/SDH, IP/MPLS, “Hybrid Approach” offloading to DSL, Carrier Ethernet

4G Assumes gigabit connections between elements to give sufficient bandwidth (mainly ethernet based)

How to get into backhaul

Physical intrusion to some cage located “in the somewhere”

Get Access to the network segment

  • Microwave
  • DSL
  • Carrier Ethernet

4G Aggregates “dumb” BTS and BSC/RNC functions on the one device –> eNB is not dumb anymore!

Once your in, what to do!

Attacking components

  • 3G: SGSNm RNC, NodeB
  • 4G: MME, eNB, SAE.GW
  • Routers/Switches


  • Pretty much everything is unencrypted
  • 3GPP insists on using IPsec Gateways
    • Which operators implement this?
  • Some countries argue against this standard

ARP spoofing still works smoothly

  • Apparently not on the security radar!

4G ALL-IP approach comes in handy

Let’s get practical

These notes are from in lab testing (i.e no firewalls, IPsec, etc…)

Real world attacks may be different due to this!

“Standard attack approach” did not yield anything interesting

SCTP Scanning via nmap or SCTPscan showed nothing

Using custom SCTP scanning tool showed some open ports

  • some of those “obscure signaling protocols”

Fuzzing the protocols

After starting the fuzzing, things got really slow.

When checking the server was sending SCTP ABORT leading us to believe something had crashed!

The main function of the device was no longer available

It recovered after a few minutes

Changed scripts and continued to fuzz

Final result…. system went down!

Business impact?


The first field of the protocol was causing the device crash!

Targeted code was running in the kernel

All that glitters is not gold however!

This isn’t old code! It’s newly developed for 4G! Make your own conclusions…


Continued testing is planned to really find the impact of this and other issues.


Attacks from the internet

Public space might mean the terminal (not covered) or the internet

Some interfaces must be made available to entities outside the network

  • e.g. S8 on PDN-GW for roaming
  • 3G: SGSNs must be able to connect to GGSNs of other countries
  • Standards say: Use NDS (IPsec of equiv. security) for these cases
  • So GTP should never be visible from the internet

Reality check!


Used to carry IP-based data traffic between network elements. There is also some other elements

Variants: GTP-C, GTP-U, and GTP’


Tunnel Endpoint IDentifier

Not very random

Not protected

Reality is that scanning for GTP in the wild does find results.

GTP Echo mechanism (port 2123) can be used to discover real GTP speakers in the internet waiting for communications

GTP-scan.py will be released soon to show this!

Many of the systems listening on GTP ports are also listening on other ports (21, 22, 23, 80) !

Various countries, many in Europe.

Whois information points to major mobile operators in these countries.

So why would they do this?

Sometimes having a working network is more important than following the standards to the letter!


From what the research shows, it looks like many attacks are coming against these networks.

Walled telco gardens are disappearing

All IP in the future

Terminals are getting more and more powerful

Misconception that people don’t understand these complex IP landscapes


Shmoocon 2011: TEAM JOCH vs. Android: The Ultimate Showdown

TEAM JOCH vs. Android: The Ultimate Showdown

Jon Oberheide and Zach Lanier

Android Security Overview

Base platform :

  • ARM Core
  • Linux Kernel 2.6.3x
  • Native Libraries
  • Dalvik VM
  • ….

TrustZone Security Foundation by ARM

  • ARM11 TrustZone –> Unused!
  • ARM11 Jazelle JVM –> Unused!
  • ARMv6 eXecute-Never (XN)? –> Unused!

Mobile ASLR sucks!

Exploiting like it’s 1990

  • Executable stack/heap
  • Non-randomization of mmap/brk

Permissions based models

Applications explicitly request pre-defined permissions. All or nothing (ACCEPT or don’t install)

App Sandboxing

standard uid/gid – generating a unique account per app to prevent overwriting of files

Application signing


Kernel Security

Linux kernel = Swiss cheese

Jailbreaks, aka local privesc


Dalvik VM != sandbox

  • Not limited to execute dex bytecode
  • Can pop out of VM to execute native code
  • Any 3rd party app can root your phone by exploiting a kernel vuln

Native code packaged within APKs

  • No code signing

How to build a mobile botnet

  • Build some fun looking game/app
    • including RootStrap functionality
    • Periodically phone home to check for new payloads
  • As soon as a new kernel vuln is discovered, push out exploit payload
  • Rootkit a bunch of phones

PoC –> Eclipse Preview

200+ downloads in under 24 hours

Not very good reviews… 1*

Google pulled the software from the store

Google used the REMOVE_ASSET function to uninstall the app from the phones

Google can not only remove software, but use INSTALL_ASSET to install things!

Platform Security

There’s a lot of “platform goo” in the middle between applications and kernels

What to attack?

  • Not kernel, not apps!
  • How about the permissions framework

Permissions approval process is designed to warn users of what an application needs to access

  • Browse
  • Install
  • Approve?
  • Installed!

Google is a sneaky panda!

You don’t actually download/install the app through the market

When you click install in market, Google sends the INSTALL_ASSET command to your phone to begin the install using the GTalkService persistent data connection used to connect your phone to Google.

This is one of the few closed-source parts in Android.

Connections are SSL… but SSL isn’t everything.

If you can pop the GTalkService Servers at Google, you could push out apps to every Android phone!

Gap in responsibility

Market app performs the perceived install process and acceptance of permissions

The GTalkService then takes it from there

The communications use Google’s Protobuf format which has been at least partially documented by the Android Market API project on googlecode.

Elements of an install request

Needs to be populated with

  • Misc fields
  • App ID
    • Can be derived from dissecting market requests
  • Auth Token
    • Turns out this can be stolen from the Android AccountManager

Bypassing permissions approval

  • Steal the “android” service token used by the market from the AccountManager
  • Construct ProtoBuf request to market servers
  • Bypass the permissions approval process by directly requesting the software from the GTalkService using INSTALL_ASSET

When people viewed the install page in the market, the user wasn’t prompted and in the background other applications were installed

Platform Security Write-up

Vulnerability Status

  • Donut: Fixed
  • Foyo: Fixed
  • Eclair: no confirmation yet, may be vulnerable

Solution adds a process where the marketplace flags an app as accepted which the GTalkService checks before installing.

Platform complexity leads to vulns

  • Round-about marketplace and GTalkService procedure
  • “server-initiated” flag fix worth investigation

Application Security

Broad Observations

The web pushed a lot of content to the browser

Now instead of data, functionality is being pushed to the web.

Mobile brought about an app for everything. Most could be achieved through the browser

XKCD viewer??


Carriers: “We trust you because you’re on our network”

Client-side data trust issues… admin=1 is live again!



Whitebox source-code review

  • Sometimes it’s trivial to get app source code


  • Acquiring Application binaries
  • Reverse Engineering (Disass/Decomp)
  • Network Analysis (Fuzzing, Protocol Analysis)
  • MITM

Testing Tools and Techniques

  • DextoJar
  • JDgui / JAD
  • Undex
  • APKtool (wrapper around smaller tools)

Case Studies


Originally written in Java, like most Android apps

Source available under Apache 2.0 license

FourSquare API supports Basic Auth and OAuth

  • OAuth Includes signatures for transactions to prevent replay attacks etc…
  • So naturally FourSquare used Basic Auth over HTTP

FourSquared app does have OAuth support, but it’s not actually used

Fixed since, as FourSquare API now forces HTTPS (at least it’s one step in the right direction)

Storage Application

Simple crash in storage quota viewer

  • Divide by zero error leads to Dos
  • Attacker mus successfully intercept and modify the server response

More of an annoyance than a real problem… app crashes!

This app also supported some DRM protections however

  • App supports sharing video, audio, image content
  • This is set by an XML manifest that says what is and isn’t possible
  • DRM enforced on the handheld….
  • intercept, change read only to share and DRM bypassed

App Framework

Runs on multiple platforms

Custom permissions restricts us from sending messages (intents) to the runtime

This app implements a custom intent service which can be spoken to as long as you have the right key!

But other malicious apps can clobber widget content! (CWE-276: Incorrect Default Permissions)

The configuration and store on the filesystem is world writable, allowing for clobbering the app content (modify widget anybody)

Lookout mobile

Lookout mobile security app

> 4 million users

Performs scanning, backup, lost device recovery.

Installs with world writeable configuration file (/data/data/com.lookout)

Has a code execution flaw due to its call to liblookout.so from a shared location.

By overwriting the lib (or changing the read path in the world writeable config) you can get code exec

Security app != Secure phone


  • No real guidance, standards, best practices
  • Bone-headed unix mistakes from 1995 are appearing in mobile now


  • Shmoocon Schedule –> HERE
  • Talk Synopsis –> HERE
  • Market API –> HERE

[BruCON] The Monkey Steals the Berries

The Monkey Steals the Berries (Tyler Shields)

Why would an attacker target a phone

PC’s are becoming smaller and smaller as more data is moved to the mobile platform. Mobile devices are also commonly less protected than desktop systems (like going back in time in some cases). It also allows for very targeted attacks.

The mobile arena is currently growing more than any other operating system. This makes it the target of the future. Once the various mobile platforms settle and the 2 or 3 major players are defined, things will become more targeted (as it was with Windows).

Mobile applications are another constant growth area giving another great chance to attack users.

Flexispy (http://www.flexispy.com)

  • Features everything needed for attackers.
    • Yearly costs involved
    • Closed source
    • Exfiltrates data to the software provider where you can view it through a web interface.
  • This makes it a hard sell for attackers.

Mobile Spy (www.mobile-spy.com)

  • Less features, but covers a wider range of platforms.
    • Yearly costs involved (cheaper than flexispy)
    • Closed source
    • Exfiltrates data to the software provider where you can view it through a web interface.
  • Same issues as flexispy, including closed source and no direct control of the exfiltrated data.

Etisalat (SS8)

  • As rolled out in the UAE to Blackberry systems.
  • Used Blackberry PIN messaging as the C&C channel. Captured outbound SMS and Emails with complete control given to the provider.
  • Was discovered due to issues users reported with battery life


  • Creator of games like iMobster and Vampires Live for the iPhone
  • Gathered phone numbers of users. Company claimed it was coded in error

Symbian Sexy Space

  • Exfiltrates data to a website of the hackers choice.
  • Binary was signed as safe by Symbian!

Symbian MergoSMS

  • Came in the form of games and themes
  • Binary signed as safe!


  • Created banking applications for the Android platform
  • Did nothing more than pass calls through to the bank
  • No malicious code found… Could easily have happened however!

3D Anti-Terrorist, …

  • Dialed premium rate numbers (8 per month)
  • Waited 3 days before starting to avoid easy detection
  • Slow win instead of a fast big pay-off
  • Repackaged legitimate game to be malicious

Mobile Security Mechanisms

Only 23% of smartphone owners use the security software installed on a device

13% of organisations currently protect from mobile devices

A balancing act between usability and security.

Corporate Level security Policies

  • Applied at the corporate IT Level
  • Can’t be modified by the end-users

End-User Level security Policies

  • Could be assigned from a provider
  • Can be overridden by end-user
  • Not as common as Corporate protections
  • Not as strict as Corporate protections

Mobile Anti-Virus

  • Implemented at the handset itself
  • Fails due to the same reason PC antivirus is failing today

Checks code

  • How are people like Apple checking apps in the app store?
  • Not all checked code is secure!

Code Signing

  • Subset of Blackberry API considered “controlled”
  • Use of controlled package, class, … needs signature
  • Can be yours for only $20
  • Hash of code sent to RIM (Not full code)
  • No barrier to entry
  • Signature can’t be revoked for existing apps (only to stop future apps)

Blackberry IT Policies

  • Blackberry Enterprise Server (BES)
  • Supersedes lower level security controls
  • Complex and very in-depth
  • Lots of fine-grained controls
  • So many that mod are set to “Default Allow All” as a result

Blackberry Application Policies

  • Can be controlled at the BES
  • Also mostly Allow
    • Gives an app many permissions by default
  • If you say “don’t trust” app still gets access to email, contact data by default!
    • Can be tweaked on a per-app basis (yeah right!)

Blackberry Spyware (TXSBBSpy)

Many ways to install on systems

Extensive logging and data exfiltration features (including SMS, EMail, HTTP, TCP/UDP sockets, DNS requests)

Technical Methods

  • Data Dumpers
  • Listeners
  • Exfiltration Methods
  • Command & Control


  • AV fails to detect due to the same issues we see on the desktop
  • Resource usage and whitelisting
  • Sandboxed based execution
  • Code Analysis (possible, but tricky/expensive)

Best solution is to use a Defense in Depth strategy and implement any and all protections possible.


A lot of trust lies with vendor application checks –> This is unwarrented

The only real solution is analysis of code