Jayson was no bikini model, but he did his best

Unlike the snow in Washington, Shmoocon has come and gone. What an experience… People always said it was a one of the best conferences to attend, and now I know why. Everybody there was friendly, knowledgable and certainly up for a party. Just the right kind of environment to learn something new, meet new faces and catchup with others. Still, as I sit on a plane winging its way back to Austria, I can’t help but think about the total chaos caused by the Washington snow.

If you were anywhere near Washington the last few days you can’t fail but to have been effected by the snow storms and the resulting aftermath. As you can imagine, it was a source of much discussion at Shmoocon, especially for me and Benny (@security4all), as we were booked into a hotel 10 minutes walk from the conference. That’s 10 minutes without the snow

In among these discussions, an idea came up that intrigued me. If you think about it, the snow wasn’t the real problem. After all, lots of countries get this kind of snowfall on a regular basis. Personally, I deal with this kind of thing for ~4 months of the year back home in Austria. So what was the problem? what caused all this disruption? The problem was that Washington wasn’t prepared to deal with the issues that came up as a result of the snow. There was nobody to clear the streets, the airports couldn’t clear the runways, and the metro lines were blocked. This is all normal stuff, and if it snows regularly, you’ve got response plans in place. Everybody knows their roles, and does them well. In Washington, this kind of snow is such a rare occurence, that nobody knew what to do. At least that’s how it appeared from the point of view of an onlooker. There just wasn’t enough people ready to deal with things in a timely manner. Those that were ready didn’t have the resources or experience to deal with things quickly and well.

Gotta love regedit

You can’t fail but see the connection to many of issues we face in information security. Some companies have a incident handling plan in place, others don’t. Everybody gets hit by a security breach sooner of later. How fast your company recovers is all about doing the work now, and not hoping that you can just work it out when it hits. If you’re left scrambling around at 3am, like we saw in Washington, then you’ve already lost the battle. Without planning your resources are going to waste. I saw people on the streets of Washington at 3am, shoveling snow off the pathways. Normally I’d applaud that. After all it was a quick response and it was pro-active. Clear the streets before the morning. However, it was still snowing as hard as before, so for every inch that was cleared, another 2 inches of snow were still to come. Add to that the fact that 10 or even 20 people with shovels aren’t going to make a dent in the amount of snow. A typical case of having  the right tool for the right job… or in this case, not having the right tool.

This is typical knee-jerk reaction to an issue. Get out there as quick as you can and clear it up. Still, what can you achieve if the cause of the problem (in this case snow) still isn’t resolved. If an attacker got into your servers, you wouldn’t start rebuilding them before you’d plugged the hole used to exploit them. It’s a vicious circle, that won’t stop until you plan for what could, and eventually will happen. Worse still, in Washington, they knew it was coming before hand, an advantage you won’t often get when it comes to attacks. I could draw analogies here to an IDS warning you of attack attempts, but I think you get my point here. I don’t know who first said it, but “If you fail to plan, you plan to fail”.

Along with the usual conference stuff, I’ll also be taking part in the Podcasters meetup on Saturday night and taking part in the Core Security technical panel. If I can make some last-minute arrangements, I’ll have some Eurotrash Security stickers with me to give away. I will also be trying to do some quick on-site interviews for the podcast, but will have to do some sound checks to see if it’s possible.

I’ve been working on a list of new people to meet when at the conference, it’s by no means complete, but it’s a start. If you’re not on the list, don’t take offense, shoot me a message here or on Twitter and we’ll see what can be done.

• Mubix (Rob Fuller)
• Tkrabec (Tim Krabec)
• Andrewsmhay (Andrew Hay)
• WikidSystems (Nick Owen)
• Bug_Bear
• BIOSShadow (Jacob Kuehndorf)
• Geekgrrl (Melissa)
• grecs
• Masontech (Andrew Mason)
• Nathanhamiel (Nathan Hamiel)
• Gdead (Bruce Potter)
• Vincentkadmon (Georgia Weidman)
• HAK5 Crew
• ….

It’s always hard to pick what talks are must-see, but I’ve picked a couple out that I’ll be trying to attend.

Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals (Larry Pesce, Mick Douglas)

I saw Larry talk a little about this at Defcon, but I’m looking forward to the whole thing. I don’t think organisations think enough about this kind of data exposure, and people should be building this into the “data exposure” testing regime for their company  (if they’re doing it at all).

The New World of Smartphone Security – What Your iPhone Disclosed About You (Trevor Hawthorn)

I’ve been getting more and more interested in iPhone (in)security recently. So hopefully this talk will give me some motivation to finish my own research into iPhone profile security.

Social Zombies II: Your Friends Need More Brains (Tom Eston, Kevin Johnson, Robin Wood)

After the first version of the talk (at Defcon last year) this update should be fun. Plus Tom was the one who came to the rescue and got me a ticket, Kevin has to autograph my GWAPT certificate and Robin is just a great guy….

GSM: SRSLY? (Chris Paget, Karsten Nohl)

I missed this presentation at 26C3 as the room was full, so I hope that the rerun will be just as interesting. Plus, more information was forthcoming about A5/3 cipher… Oh, and Karten promised to come on Eurotrash, so I need to remind him

Exposed | More: Attacking the Extended Web (Nathan Hamiel)

Gotta love Web Application penetration testing !!!

The Friendly Traitor: Our Software Wants to Kill Us (Kevin Johnson, Mike Poor)

I haven’t seen Mike since a SANS conference in 2008 (Amsterdam) so it’ll be nice to say hi again…. Plus, anytime you can see Mike talk, it’s a WIN.

Anyway, I hope to see you there….

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 :

• Cryptographically Secure Paper (DE)
• Papers (SanDisk, Kingston) (DE)
• SanDisk Security bulletin (LINK)
• http://www.syss.de (DE)

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

Problem

• 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

Solution

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.

Overhead – 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 :

• http://events.ccc.de/congress/2009/Fahrplan/events/3515.en.html
• secuBT paper (PDF)
• secuBT project page (link)

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
criminals.

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)

• http://www.lightbluetouchpaper.org
• http://www.cronto.com/

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:

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)

OpenBTS

• 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

OpenBCS

• 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.

Airprobe

• 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

TSM30

• Spanish phone (about 6 years old)
• GSM, GPRS, WAP
• 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.

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 :

• http://events.ccc.de/congress/2009/Fahrplan/events/3648.en.html
• https://dedected.org
• http://www.dect.org/news.aspx?id=52 –> DECT Forum press statement

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)

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 :

• http://events.ccc.de/congress/2009/Fahrplan/events/3555.en.html
• http://www.p1sec.com/corp/wp-content/uploads/2009/10/Attacking-SS7-2009-Philipe-Langlois-P1security-h2hc-v8.pdf
• http://www.p1security.com
• http://www.blackhat.com/html/bh-europe-07/bh-eu-07-speakers.html#Langlois
• SCTPscan –> http://media.frnog.org/FRnOG_10/FRnOG_10-2.pdf
• SCTPscan Video –> http://www.dailymotion.com/video/x2nq3d_frnog-10-philippe-langlois-sctpscan_tech

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 :

• http://events.ccc.de/congress/2009/Fahrplan/events/3709.en.html
• http://www.legic.com/en/legic_prime.html

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.

• http://www.adobe.com/devnet/flashplayer/
• http://blitzableiter.recurity.com
• http://blitzableiter.recurity.com/projects/show/blitzableiter

* 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.