hack your atm with friend's raspberry.py (black hat eu-2014)

Post on 14-Jun-2015

7.337 Views

Category:

Devices & Hardware

9 Downloads

Preview:

Click to see full reader

DESCRIPTION

At all times there have been bad guys, who tried to steal money. ATM machines containing vast amounts of money have always been attractive targets. Until recently, criminals were only using physical weaknesses. Skimmers and shimmers for stealing magstripe-tracking data, fake pin pads and cameras for stealing pin codes, and even fake ATMs were created. Time passed and ATM software started to unify. Where there is unification, there are viruses. Trojan.Skimmer.*, Ploutus and other named or unnamed trojans. And what did we see on the public scene? Vendors started discussing the skimmers problem only after they were detected in the wild. As you remember, Barnaby Jack presented "Jackpotting Automated Teller Machines" at Black Hat USA 2010. He used some vulnerabilities in ATM software. He showed that malware, was injected into the OS of the ATM via bootable flash drive or via remote management TCP port. Barnaby Jack's work was based on assumptions that most vulnerabilities were concentrated in the host machine and that we can and should reuse software made by ATM vendors. And that's quite true, but... antiviruses, locked firmware upgrades, blocked USB connectors, and encrypted hard drives can mitigate such risks. But, what about connecting not to the host machine, but to devices themselves? What countermeasures exist, when we will try to impersonate ourselves as an ATM host? Hacking ATMs with small computer like Raspberry Pi should be impossible, but it isn't. The point of our presentation is to draw attention to the problem, which has existed for quite a long time. The problem is usage of common interfaces (like RS232 or USB) and protocols of communication from host machine to such devices as card readers, pin pads and/or dispenser units.

TRANSCRIPT

Hack your ATM with friend's Raspberry.Py

Alexey OsipovOlga Kochetova

Who are we?

• Positive Hack Days Team

• Authors of multiple articles and researches

• White hats

• CLUB-MATE addicts

• Just cool folks

Agenda

• Intro (little bit about ATM history)

• Old physical stuff (Skimmers and pin sniffers)

• Host based attacks (XFS vulnerabilities/insecurities)

• Device-specific attacks

• Demos

INTRO (LITTLE BIT ABOUT ATM HISTORY)

The 1st idea: no ATM – no cry

• 1939 – the 1st idea of ATM

• The City Bank of New York rejected it

• If you don’t have ATM, it can’t be hacked

1967 – the world’s 1st ATM

Card&PIN&online&so on

Today we can use and investigate ATMs

WHY WE ARE DOING IT?

$#it happened

Banks are curious

We are curious

ATMs are hacked• Trojan.Skimers• Backdoor.Ploutus• Tyupkin• Another target attack• Undocumented

features• “Top secret” data is

online

ATM Jackpotting by Barnaby Jack

• Remote controlled ATM with admin tools

• Firmware updates

• Dispense money

OLD PHYSICAL STUFF (SKIMMERS AND PIN SNIFFERS)

• Encrypted PIN Pad

Motorized hybrid card reader

What is inside

Motorized hybrid card reader

Card reader

Track2 is enough for transaction

PAN = the 1st part of Track2

• Skimming• Shoulder-surfing, hidden camera, mirrors• Fake PIN pad• Fake ATM

I need your PIN, your card and your cash

Like valid slots

The most popular devices

Converted anti-skimming

3D printing skimming

via http://krebsonsecurity.com/

Fake ATM

Your money is not yours anymore

HOW HARD TO GET INSIDE OF ATM?

- Service zone- Plastic cover

- Single lock

- Safe for money- Steel + concrete

- Rotary code locks/electronic locks

- Two types of locks

ATM countermeasures

How to get in

How to get in

How to get in

ATM is locked

DEMO

HARDWARE AND PREPARATIONS

- Minimal price

- Small

- Capable of using multiple interfaces

Intent

- Raspberry Pi- 2 USB ports- Ethernet

- USB-COM converter- Facedancer (kudos to Travis Goodspeed)- Wifi dongle- Battery =)

Hardware

- PWN Pi

- Python

- pySerial

- pyHID

- pyUSB

- TTWE framework (thx rvantonder)

Software

Raspberry Pi + Python + WiFi = bingo!

Our “malware” devices

HOST BASED ATTACKS (XFS VULNERABILITIES)

XFS insecurity

Network communicationWindows-based application

Configuration information

Unit #1

Service provider #1

Unit #2 Unit #3

Service provider #2 Service provider #3

Unit #4

Service provider #4

Unit #5 Unit #n

Service provider #5 Service provider #n

XFS API

XFS SPI

XFS manager

COM USB

Customer/Service mode

XFS insecurity

Network communicationWindows-based application

Configuration information

Unit #1

Service provider #1

Unit #2 Unit #3

Service provider #2 Service provider #3

Unit #4

Service provider #4

Unit #5 Unit #n

Service provider #5 Service provider #n

XFS API

XFS SPI

XFS manager

COM USB

Customer/Service mode

XFS, PIN Keypad device

PIN device

– Open mode and

secure mode read

data

– Export of key is not

available

XFS, Identification Card Device

IDC device

– Read/write data

– Insert/eject/retain

cards

– EMV reader

Cash Dispenser Device– Cash withdrawal without authorization

– Cassette and cash control

– Software safe opening

XFS, Cash Dispenser Device

- Authentication?

- Hard to get specification?

- Exclusive access to XFS manager/service provider?

XFS authentication

- Authentication? What authentication?

- Hard to get specification? Freely available

- Exclusive access to XFS manager/service provider? Exists, but not intended to be used for security

XFS authentication

• Early 2014 – 95% of ATMs run on Windows XP

• Support killed off in April

• >9000 vulnerabilities

Windows XP still alive

So?

DEMO

DEVICE-SPECIFIC ATTACKS (PHYSICAL INTERFACES COM/USB)

RS232 insecurity

Network communicationWindows-based application

Configuration information

Unit #1

Service provider #1

Unit #2 Unit #3

Service provider #2 Service provider #3

Unit #4

Service provider #4

Unit #5 Unit #n

Service provider #5 Service provider #n

XFS API

XFS SPI

XFS manager

COM USB

Customer/Service mode

DinosauRS232

• Standard interface

• No specific drivers

• No authorization

• Insecure proprietary protocols (just sniff and replay)

• Direct device control– Command execution mitigating all host-based checks,

e.g. cash withdrawal without notes counter checks

– Execution of undocumented functions

– Intercept unmasked sensitive data

• Possibility of producing hardware sniffer, which can’t be detected by software means

Advantages

• Protocols bloat

• Specific method of integrity control

• Short timeouts

• Endless polling

• New firmware version = new protocol

Difficulties

DEVICE-SPECIFIC ATTACKS (COM-PROTOCOLS)

- No good tools for analysis

- No flow control

- No host loss detection

- Packets- Fixed size

- Start/stop bytes

- Length prefix + data

Typical serial protocol

Life without wireshark

Typical data

02 30 XX XX XX

01 0102 00 03 00 04 00 05 00 06 00

10 03 42

Typical serial protocol

02 30 XX XX XX

01 0102 00 03 00 04 00 05 00 06 00

10 03 42

- 02 30 / 10 03 – start-stop sentinels

- XX XX– op-code

- XX – Unknown

- 01 01 … – data

- 42 – CRC8

- Request insert card

- Acknowledge host about card inserted

- Issue 3 separate commands to read 3 tracks

- Issue additional commands for EMV communication

IDC device flow

- Sniff all Track data

- Send to host fake information about inserted card

- Abuse services existent on ATM that don’t involve cash withdrawal

- Card to card transactions

- Payments

IDC device attacks

PIN device flow

- If entering PIN/encryption keys- Authenticate host on currently used keys

- Send empty button press events

- Send PIN block to host

- If entering open string

- Send all button press events with button values to host

PIN device flow

PIN MITM attack

- Request open mode from PIN pad when user is going to insert PIN code

- Acknowledge host about button presses

- Send erroneous PIN block (we don’t know keys)

- Host refuses transaction, but attacker knows client PIN code

- Next transaction will be unmodified

PIN device MITM attacks

- Restart/check device

- Dispense X notes from Y cassettes

- Open shutter

- Present notes to user

Dispenser device flow

DEMO

- No more RS232 – no malicious control

- Any use of cryptography – is equal to good use of cryptography

- We regret informing you that we had decided to stop producing this model and warranties for our distributors been expired (c)

What big vendors think

What we think

HOW TO LIVE WITH ALL THIS?

- Service zone is important

- Current methods of protection is not enough

- Using execution prevention software without OS patches – is wrong

Conclusions

- Implement mutual authentication both for ATM computer and it’s devices

- Make peer review of XFS standard/communication protocols

- Service zone is as important as safe

- Trust environment is not about ATMs

Proposals

Alexander Tlyapov, @Rigmar

SCADAStrangeLove, @scadasl

And all other guys worth mentioning

Kudos

Alexey Osipov, @GiftsUngiven

Olga Kochetova, @_Endless_Quest_

Questions?

top related