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

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

Tag Archives: 26C3

26C3: Cryptographically Secure ? (lightning talk)

Cryptographically Secure ?
Cracking FIPS-Certified USB Flash Drives
Lightning talk – PoC – Matthias Deeg

Demo is performed using a SanDisk Cruzer Enterprise (FIPS Edition), however is possible on other devices.

  • Small mistakes often have a big impact, especially when it comes to complex devices.

USB FDU – (USB Flash Drive Unlocker)

The demo PoC tool was able to unlock the device (make it so that any arbitrary password works) within a few seconds. A number of vendors have already patched this issue and provided updates for their devices (see Links below).

Currently the PoC isn’t publicly available.

Links :

26C3: secuBT – Hacking the hackers with User-Space Virtualization

secuBT – Hacking the hackers with User-Space Virtualization

In the age of coordinated malware distribution and zero-day exploits security becomes ever more important. This paper presents secuBT, a safe execution framework for the execution of untrusted binary code based on the fastBT dynamic binary translator.

Aim: To visualize and encapsulate running programs to guard and protect the computer system


  • programs can execute any system call
  • Security vulnerabilities can be used to execute unintended system calls
  • Patches are a reactive form of dealing with the problem


User-space virtualization encapsulates a running program

  • Executed code is checked and validated
  • Code can be wrapped or modified
  • System calls can be controlled

User-space virtualization is implemented through Dynamic Binary Translation

  • secuBT implements a User-Space sandbox
  • Dynamic BT used for virtualization layer
  • System calls interposition framework – Checks and validates system calls, implements checks to avoid breakout

Static vs Dynamic translation

Static reads the binary, reassembles it into a new binary after processing – This is prone to issues, but is quicker
Dynamic translates all code as it gets executed – This is slightly slower, but improves compatibility

Dynamic Translation implements two levels of code execution:

  • ‘Privileged’ code of BT library
  • Translated and cached user code

When performing translation the following checks are made:

  • All instructions are checked
  • All (direct and indirect) jump targets are verified
  • All system calls are verified

Security hardening

  • Enforce NX-bit
  • Check ELF headers, regions, and rights
  • Protect internal data structures (mprotect)
  • Check and verify (valid) return addresses
  • Check and verify indirect control transfers

System Call Interposition Framework

Guards and rewrites all system calls through sysenter & INT 80 redirection to a validation function

The validation function can reimplement the syscall in user-space (allows fake responses or return a value as desired)

This allows a specific set of permitted syscalls to be defined, and unwanted syscalls can be blocked.

– 7% only using Binary Translation,  increasing to 9% with all security implementations in place

What does secuBT protect ?

  • Heap and stack based overflow
  • Return to libc style attacks
  • Overwriting the return instruction pointer (using shadow stack)

More information can be found at the following locations :

26C3: Optimised to fail – Card readers for online banking

Card readers for online banking

The Chip Authentication Programme (CAP) has been introduced by banks
in Europe to deal with the soaring losses due to online banking fraud.
A handheld reader is used together with the customer’s debit card to
generate one-time codes for both login and transaction authentication.
The CAP protocol is not public, and was rolled out without any public
scrutiny. We reverse engineered the UK variant of card readers and
smart cards and here provide the first public description of the
protocol. We found numerous design errors, which could be exploited by

Banks throughout Europe are now issuing hand-held smart card readers
to their customers. These are used, along with the customer’s bank
card, for performing online banking transactions. In this talk I will
describe how we reversed-engineered the cryptographic protocol used by
these readers, using some custom-designed smart card analysis hardware.
We discovered several flaws in this protocol, which could be exploited
by criminals (and some already are). This talk will explain what
vulnerabilities exist, and what the impact on customers could be.

Online banking fraud has increased 185% between 2007 and 2008.

Simple fraud techniques dominate due to poor overall security and awareness :

  • Phishing emails
  • Keyboard loggers

Some common security measures that UK banks have implemented :

  • On-Screen keyboards
  • Picture passwords
  • Device fingerprinting (using HTTP header information to track and block)
  • One-time-passwords/iTAN

All of these are bypassable in one way or another. Whether it’s through MitM style attacks, of faking headers. Commonly however Man in the Browser attacks are used, as it offers a complete control over the victim’s machine. What the victim sees, isn’t what they send/receive.

To combat this, the response must be bound to the transaction to be authorised. Various methods have been implemented, including several UK banks that are now using hardware based challenge/response for authorisation of transactions. These devices conform to the EMV specification v4.2

  • Customer enters PIN
  • Customer enters transaction details
  • Reader displays authorisation code
  • Customer enters code into the browser
  • Bank verifies the authorisation code in the background

How this protocol works is a closed box.

By building a smart card snooper (based on the Xilinx FPGA development board from Opal Kelly) it was possible to discover information about the underlying protocols.

  • Protocol very similar to EMV (used for smartcard payments in Europe)
  • Looks like a transaction but cancelled at the last stage
  • Contains 2 data items not listed in the EMV specification

Changing some data

By modifying specific pieces of data and leaving others the same, it was possible to observe the reaction of the device. By flipping 1 bit, sometimes the transaction failed, other times the resulting code was different.

  • The authentication code comes from the cryptogram generated by the card at the end of the transaction
  • The mysterious tag 9f56 was a ‘bit filter’ which selects which bits from the cryptogram are used for the response
  • The filtered cryptogram is then converted to decimal

It was found that there were no cryptographic secrets within the device itself. This means that a software implementation was easy to achieve (a number are available).

Useability failures aid fraudsters

The different banks use varied features of the devices. This leads to confusion where a fraudster can fool a user into using the device in a way that the input is what the fraudster wants and not what the bank expects.

Nonce is small or absent

  • No nonce in Barclays variant, so response stays valid
  • Only a 4 digit nonce with Natwest (weak 100 guesses = 63% success rate)

Fake point of sales devices can get responses in advance.

CAP readers help muggers – CAP readers can be used to check if the PIN number is correct or not.
Supply chain infiltration – In the past chip & pin terminals with GSM modules have already been found in the wild. The control of CAP readers is significantly less controlled.

What does this mean for customers

  • CAP is far better than existing UK systems
  • Authentication codes are dynamic
  • Authentication codes are bound to transaction

However, banks are now claiming that any transaction using this process must have been authorised by the user. This means that if you are a victim of fraud, the bank will probably deny your claims. Currently ~20% of claims are turned down.

Recent attempts to test this in court failed, with the Bank winning (Halifax). The evidence provided by the bank was simply a log file showing that the transaction was chip read (04 in the log).

HHD 1.3

Standard from ZKA, Germany

Stronger than UK CAP, but more user input required

  • Many more modes
  • Mode number alters meaningful prompts
  • Up to 7 digit nonce
  • Nonce, and mode number are included in MAC
  • PIN verification

Other solutions

  • Flicker TAN – Device reads information from a flickering animation (using sensors)
  • USB connected readers – Require drivers, so could be an issue without Admin permissions
  • Cronto PhotoTAN – Uses a 2D barcode read by a mobile phone application (uses a cryptographic key to prevent MitM)

More information can be found on the CCC wiki. Access to the slides (PDF)

26C3: Playing with the GSM RF interface

Doing tricks with a mobile phone

This talk will show what can be done by taking control of the GSM RF part of a mobile phone, for example performing a DoS attack to the GSM network or using the phone as a sniffing device.

If the RF hardware of a mobile phone can be controlled, lots of things are possible, for example:

  • Sending continuous Channel Request which can lead to a huge load for a GSM cell and could be considered as a DoS attack to the GSM network.
  • Use a mobile phone as a cheap GSM receiver for sniffing the air traffic somehow similar to what can be done with the USRP.

Motivation for playing with GSM

The GSM network has been in use in Germany since 1992 and hasn’t been well researched until recently. It was always the case that access to GSM equipment was restricted. Now the game has changed. Second hand GSM equipment is easily available, OpenBTS, OpenBCS, etc…. the documentation behind GSM is also now public (but is very extensive)


  • Hardware based on USRP
  • Air Interface (Um) is a software defined radio
  • Does not model classic GSM architecture, but uses a direct Um-to-SIP


  • Implements the Abis protocol plus MSC/MSC/HLR
  • Supports the Siemens BS11 microBTS
  • Supports ip.access nanoBTS
  • Used to run the 26C3 network using 4 nanoBTS units

The nanoBTS is much smaller and more modern than the 10 year old Siemens BS11 unit.


  • Passively sniff the GSM Air Interface
  • Based on USRP and GNU Radio
  • Analyze protocols with Wireshark

What about an “open” phone

  • Project Blacksphere for Nokia DCT3 phone – No longer active ?
  • TSM30, based on the TI Calypso GSM chipset – source code available on the internet
    • Can be used to sniff the air traffic
    • Could be used to perform DoS on the GSM network
  • Openmoko GTA01/02: GSM modem based on TI Calypso
    • The software is open-source, but the GSM modem is still closed
  • Future plans: Take a GSM RF-Transceiver and Baseband chip, connect it to a DSP/FPGA board
    • Truly open
    • Very long term


  • Spanish phone (about 6 years old)
  • TI Calypso chipset – leaked documents can be found
  • Firmware is written in C – no source code for the DSP

Sniffing the air traffic

The TSM30 provides the chance to extract digitally converted traffic, however issues of extracting the data (1 MByte per second) from the phone need to be worked out. As there is no fast data transfer this is currently an issue. Tests with 1 second of audio have been tested and work as expected.

DoS Attack

  • By sending continuous RASH requests you can use up available channels on the BTS
  • Makes it difficult for phones to access the cell
  • Phones might switch to another cell
  • Useful for specifically targeting a location, but not a general wide-spread DoS
  • No 100% guarantee
  • Theory known for sometime, but never demonstrated
  • Even a phone without a SIM can perform the attack
  • Hard to track
  • Protection against the attack would require a complete rewrite of how GSM functions

One useful purpose for the attack, is performing a DoS against the cell and implement a rogue point to capture user information when phones attempt to register to another available BTS.

A demonstration of the DoS using the 25C6 conference GSM network (nanoBTS and OpenBTS)

More information can be found on the CCC wiki.