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: DECT (part II)

Last years talk on DECT (in)security was one of the highlights of my
conference. It also prompted me to grab one of the com-on-air cards and
start playing with DECT a little more. Hopefully this talk gives me
some more fun things to play with in 2010.

What has changed in DECT security after one year

“This talk will provide an update on the security of encrypted DECT
calls (using the DSC cipher), which can currently not be broken by
passive eavesdropping. We will also show what has been done so far to
improve DECT security and what you can do to get a secure DECT system”

GSM cellphones have a lot in common with in-house cordless telephones. The security of both devices were designed by the same group of people, with only a few years between them. They share a number of the same issues as a result.

Communication within the industry has been a lot better with DECT insecurities however, and plans are being discussed on how to make things more secure. The same cannot  be said however for GSM issues.

DECT overview

  • Standard for short range portable phones
  • Frequency 1,9 Ghz
  • Range up to 300 meters
  • invented in 1992
  • more than 670,000,000 devices

Standard of security – 1 year ago

DECT uses two proprietary protocols

  • DSAA: DECT Standard Authentication Algorithm
  • DSC: DECT Standard cipher
  • Both are OPTIONAL!

There are devices in the market the do not use authentication or encrypt.

Project deDECTed.org in 2007/8 jointly worked on disclosing DECT security

  • Reversing DSAA
  • Partial Reversing of DSC
  • Attacks on DSAA, PRNGs and DECT itself
  • Open-source sniffer for DECT PCMCIA card

This culminated in the talk at 25C3 to disclose the vulnerabilities and raise awareness. This talk invoked public interest, resulting in extensive media coverage, and the implementation of a DECT stack for Linux (Patrick McHardy). DECT vendors, BSI and other security companies started engaging with deDECTed.org. The first consumer phones with improves security appear in early 2009 (shortly after the 25C3 talk). These looked to fix some of the more serious issues. Some firmware upgradable phones were also provided with upgrades.

Open implementation of DECT

  • PCMCIA Type III card now supported
  • Additional support for audio codecs
  • Better audio quality

New research

DSC was reverse engineered

  • Similar to A5/1
  • 4 LFSRs, 3 irregularly clocked
  • Output combiner with 1 bit memory
  • 40 Blank rounds – Largest weakness found

DSC can be accessed from the SC14421’s firmware

The level of access granted by the D_WRS state allowed for complete control and debugging of the encryption process. This meant that, like the Legic prime talk, a reverse engineering was possible without the need to look at the silicon. However, they still did, as it was fun.

A5/1 is stronger tan DSC in only one dimension –> in A5/1 there are 100 pre-cipher rounds, compared in only 40 in DSC.

This appears to be a tweak implemented by engineers to improve speed. However this 1 flaw causes serious issues with the encryption and makes it significantly weaker than A5/1. Without this change, the encryption would be significantly better than A5/1 in every way (see slides for a full breakdown)

DSC Cryptanalysis

  • Imagine all the registers would be regularly clocked
  • The internal state would be a linear combination of IV and key bits
  • Two consecutive bits of output cut down the key space by half
  • You can repeat that !
  • However, LFSR’s are clocked irregularly

The use of irregular clocking makes it a lot more secure. However…

You can guess the number of clocks correctly (for 1 register, chances are 12%, for all 3 registers, the chances are 0,2%, which may seem low, but is significant). Access to 500,000 different keystreams reveals the key in 1 day on a PC  using a fast GPU. Full details of this attack will be released mid-January at a Cryptographic conference.

Using the C-Channel (A-Field) (to gather keystream data)

A-Field is ony encrypted when C-Channel data is present

The base station is responsible for updating the handset through C-Channel data. The C-Channel transports :

  • Dial Strings
  • Display updates
  • Keys pressed on the numpad
  • RSS newsfeeds

This provides lots of guessable plaintext, and can provide the 500,000 required keystreams with in 24h.

Using the B-Field (to gather keystream data)

B-Field transports voice data

  • Very hard to guess, except if there is silence or the B-Field is unused
  • Mute one end of the communication !

3 hours silence is enough to generate the required data.

Other Problems

  • DSC key only depends on random numbers sent by the FP
  • Phones create guessable B-fields

Countermeasures

For the user :

  • Restrict to short calls
  • Avoid silence

For the manufacturer :

  • change the key during the call
  • Avoid guessable content in C-Channel
  • Replace the algorithm

Next Generation of the DECT standard

  • ETSI and the DECT forum are now working on a new standard
  • deDECTed helped where possible
  • Changes will be made in two stages – Short-Term fixes, Longer-Term redesign
  • The new standards DSAA2, DSC2 will be openly published and use established algorithms

Where possible, firmware updates will be made available to fix some issues (such as re-keying, forced encryption, …)

A set of security requirements will be standardized in spring 2010. Phones implementing this will be certified.

More information can we found :

Some publications released in 2009 in regards to DECT security :

  • “Security of Digital Enhanced Cordless Telecommunications” by Alexandra Mengele (PDF)
  • “An efficient FPGA Implementation for an DECT Brute-Force Attack Scenario” by Kei Ogata (Article)

26C3: SCCP Hacking – Attacking SS7 & SIGTRAN applications

One step further and mapping the phone system

SS7 is no longer the walled garden where people cannot inject traffic. SS7 was designed for reliability, with multiple systems  designed to take the load of failed servers. Access to the SS7 network was originally restricted to peering partners. It is now the target for fraudsters (SMS fraud), and government agencies.

Why do we have SS7 ?

Blame Steve Jobs / Steve Wozniak and the creation of the bluebox. With inband signalling, hackers took advantage of the telephone system. Seizing a trunk without tracing was a big problem. SS7 was designed to move the signalling away from the voice network. However this is all history.

One part of the SS7 system is the LIG (Legal Interception Gateway ?) –> usually not owned by the telco. Installed by 3rd parties to give access to the system for law enforcement.

OpenBTS and OpnBSC are making research into this area possible.

Using External APIs to HLR, it has been demonstrated how it’s possible to locate IMSI within the SS7 network.

The underlying technology is moving towards IP based solutions –> This is good for us, we know IP already

Important SS7 protocols :

  • MTP (Message Transfer Protocol) Layers 1-3
  • ISUP (Integrated Servics Digital Network)
  • SCCP (Signaling Control Connection Part)
  • TCAP (Transaction Capabilities Application Part)
  • MAP (Mobile Application Part)
  • INAP (Intelligent Network Application Part)

Entry points in an SS7 network :

  • Peer relationship between operators
  • STP connectivity
  • SIGTRAN protocols
  • VAS systems e.g. SMSC, IN
  • Signaling Gateways, MGW
  • SS7 Service providers (GRX, IPX)
  • GTT translation
  • ISDN terminals
  • GSM phones
  • LIG (Legal Interception Gateway)
  • 3G Femtocell
  • SIP encapsulation

These entries points offer a range of access posibilities, and limitations. Without access directly into the core SS7 network, attacks will be limited depending on the provider.

SIGTRAN protocol: M3UA Protocol Adaptation Layer

SIGTRAN gives us the opportunity to work with something more familiar.

Like TCP/IP, but with slight differences, including spoofing and DoS protections –> RFC4960

By adapting typical scanning methods used in TCP/IP environments, you can scan for services. The tools SCTPscan tool is now included in many Linux distributions, including Backtrack. When sending SCTP init packets, no answer usually means a peering port has been found. Usually an ABORT reply is sent. By scanning addresses, close to the official SMSC, you can often find test systems that may not be correctly connected to systems such as billing systems !

Protections are less about filtering, and more that a valid route isn’t know. Once you have a route, you can connect to other systems.

In order to get a valid list of SPC codes, you can scan, or buy the full list from the ITU for under €30

When dealing with SPC formats, there are a variety of differing formats.

  • ss7calc –> open-source tool available from p1sec.com

Attack examples :

  • IAM attack: Capacity DoS –> Similar to SIP flooding
  • REL attack: Targeted Call release –> Terminate a users conversation
  • SRI attack: Tracking of users
  • HLR attack: Fake location update –> redirect calls to another country, until phone reboot
  • ….

FemtoCell

  • Node B in users home. Establishes an IPsec tunnel, SIGTRAN
  • Hardware based on Linux
  • ARM hardware
  • Very insecure
  • > Unaudited software
  • > Global settings for IPsec tunnel
  • > Injection of RANAP and SS7 traffic into the core network

Tools and things to help

  • SCTPscan – Bridging support, instream scanning
  • ss7calc
  • 7Bone – Open Research SS7 Backbone
  • P1sec SIGTRANalyzer (SS7 and SIGTRAN vuln scanning, Commercial pruduct)

SS7 is not closed anymore !

For more information, check the following links :

26C3: Legic Prime – Obscurity in Depth

LEGIC Prime is the older (1992) of the two high security RFID solutions offered by the Legic company (the other being Advant – released in 2004).

The Legic Prime is primarily used for high security access systems, but is also used in some payment situations, such as company cafeteria payments.

  • Shrouded in a cloud of closed-ness and exclusivity
  • Compared to MiFare: much harder to get cards and readers
  • This secrecy is marketed as a security feature

Token structure is hierarchical: a token can only create objects with higher nesting level than its own. This allowed Legic to have resellers each permitted to write a nesting level for each customer and so forth.

Attacks were implemented using the Proxmark 3.

* Note: I’m not even going to try and take notes on the reverse engineering of the Legic protocol. Again, the slides and video are a good idea if you want more information.

When reverse engineering the protocol there were a lot of instances where things appeared to be returned in a strange order. This could possibly be used as an obfuscation to hinder decoding of the protocol.

By simply sending commands it is possible to read all segments, even the read protected areas. This code is now in the Proxmark SVN and should allow reading of data from the LEGIC Prime cards. It was also possible to overwrite data by simple brute-forcing the CRC for that data location, until the correct value was found (or calculated from previously held data – i.e. the UID).

This was all achieved without even looking at the silicon to reverse engineer the crypto functions.

“We did find something crypto looking, but too small to be cryptographically secure” – the state was found to be only 15bits, easily reversible, but not needed (brute-force). No key input –> not technically an encryption

A number of additional, and easier, attacks on the CRC functions where also discovered allowing you to spoof any card, including the master card (the card permitted to write other cards for a company).

The write command is also susceptible to the same CRC issue previously seen. This allows write to the card as desired.

By sniffing the communication between a card and reader it is possible to recreate the card in an emulated environment. When playing with the emulated card was found that Bytes 5 and 6 could only be decremented to prevent a user raising privileges. However with a blank card, this value is set to maximum and is possible to decrement it to the desired value.

  • Byte 5 controls the token type (IAM, SAM, GAM)
  • Byte 6 controls the stamp length (along with Byte 7)

Data on the card is further obfuscated. The data is XORd with a secret value. This value turns out to be the CRC of the UID (which is stored on the card!).

Root problems

  • No Keys (no key management, no card authentication, no reader authentication
    • Spoofing, skimming
    • Segments can be created out of thin air
    • Master token can be created out of thin air
  • No authorisation necessary for master token use, master token not inherently necessary for segment creation
    • cloneable

Software released: Reader emulation
Not released: Card emulation, full protocol –> however reverse engineering is not hard, so upgrade ASAP

Please upgrade, but not to HID!

For more information :

26C3: Defending the poor

Not sure how I managed to miss this on the first look at the schedule, but I almost missed this one. FX usually talks about IOS, but this time he’s turning his focus on Flash applications, and how to defend them. Certainly a turn-up for the books 😉 Fx’s first talk concentrating on pure defense. Nick Farr pulled off a pretty passable standup comedy act before the talk. There’s a career in show biz for him somewhere I’m sure 😉

Defending the poor: Countering Flash Exploits

Research was motivated by the BSI project (in late 2008) that reviewed the current state of Rich Internet Applications. Flash was shown to be lagging behind in regards to security, and no easy solution could be found. So how do we solve the problems ?

Who cares about flash security ?

  • People who don’t want to get owned when surfing pr0n
  • Apple user running PowerPc (no more updates)
  • Website operators (Flash adverts, …)

The common link between RIA environments (Flash, Silverlight/moonlight, JavaFX) is the plug-in based implementation. The majority of systems run flash, with Siverlight a long long long distant second.

The Flash security model

Primarily relies on the virtual machine runtime environment for sealing off access from the RIA code to the native machine. Permission decisions are based on so-called sandboxes. Generally Flash code can access local or remote resources, but should be restricted to one or the other.

Security Focus lists about 40 Flash vulnerabilities for the Flash player.

Attacks using Flash

Other than memory corruption and client-side attacks, Flash is used for a range of other attacks :

  • Flash has been used to perform DNS rebinding
  • targeting exploits by using Flash to perform client-side enumeration
  • Clickjacking style attacks
  • Sending additional HTTP headers (UPNP, CSRF Attacks)
  • Appending HTML/JavaScript to Flash files
  • Forwarding users / redirection (most commonly seen)

Flash Malware examples

  • SWF .AdJack/Gnida
  • CVE 2007-0071 Exploit
  • SWF/TrojanDownloader
  • ….

AV scanners appear to have issues detecting these threats if the malware is uncompressed. This could mean that AV scanners are not detecting the actual malware, but only packed strings or the packer itself.

Adobe Virtual Machines

The flash player actually contains 2 virtual machines
AVM1 is a historically grown weakly typed stack machine with support for object orientated code
AVM2 is a ECMA-262 (JavaScript) stack machine with a couple of modifications to increase strangeness. Programmed in ActionScript 3.

History of AVM1

  • First Scripting appears in SWF 3
  • SWF 4 introduces the AVM
  • SWF 5 introduces typed variables on the stack
  • SWF 6 fixes SWF 5
  • SWF 7 brings more OOP – Finally introduced exception handling !
  • SWF 8 never happened
  • SWF 9 already brings the AVM2 into the format
  • SWF 10 current

The whole thing is backwards compatible. Many security tools do not check ALL the code, and concentrate on the DoAction tags.

Desgin Weaknesses in AVM1
The byte offset in branch instructions allow for:

  • jumps into the middle of other instructions
  • jumping outside of code blocks

The order of code execution appears to be non-deterministic

  • Depends on a number of variables including how far an object it on the y axis !

Comparison to AVM2

  • Designed to make everything better
  • Spec not been updated since 2007
  • The “reference implementation” called Tamarin is not open-source
  • Format specification uses 30bit length fields to prevent integer overflows

Considerations for the defense approach

There are two main attack types to defend against

  • Malformed SWF files that cause memory corruption
  • Well formed SWF files that use the player API for evilness

Instrumentation of the player is bound to fail
Nobody wants to write a new flash player from the ground up

Solution – Normalization through Recreation

  • Safely parsing the complete SWF file, strictly checking the standards
  • ….

A Flash File Parser (coded in c# to allow for .Net and mono support) –> Blitzableiter

This will protect against possible malformed attacks, but not against SWF files performing simple redirections. In order to protect against this, you can use emulation to interpret the actions. This however is flawed, as the Flash player isn’t easy to predict, and the emulation could take a different direction to the player.

By performing runtime analysis, you can (for example) ensure that the same origin checks are imposed on functions that could result in the browser being forwarded (i.e ActionGetURL2). By patching the code, you can then open the SWF in the player without worrying about the user being forwarded to another site without warning.

This solution is trivial, but needs to be done as the Flash player doesn’t do these checks.

Blitzableiter

  • Features a full AVM1 assembler
  • Supports all 100 documented AVM1 instructions
  • Support for variable name
  • AVM2 not yet supported

In testing 82% of the test set ran correctly once being run through the engine. However the code inflation is currently at 224% of the original, which needs to get fixed. Timings are roughly 1 second additional wait for the whole process.

There is still work to be done to fix issues with some Flash compilers output (youtube is an example).

The tool can’t do anything about (yet) :

  • Heap Spraying
  • Flash API overflows

The Blitzableiter tool is open-source allowing others to check the code and find bugs. It will also allow others to integrate the features (into web browser extensions, Proxy filters, or file upload filters). Also so that Flash developers can test their own code. The code has been released under the GPLv3.

* Note: These are my notes from the talk. As always, it’s not possible to get every piece of fine detail. I’d suggest catching the video as soon as it’s made available.