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.

1. Hack your ATM with friend's Raspberry.Py
Alexey Osipov
Olga Kochetova

2. Who are we?
•Positive Hack Days Team
•Authors of multiple articles and researches
•White hats
•CLUB-MATE addicts
•Just cool folks

3. Agenda
•Intro (little bit about ATM history)
•Old physical stuff (Skimmers and pin sniffers)
•Host based attacks (XFS vulnerabilities/insecurities)
•Device-specific attacks
•Demos

4. INTRO (LITTLE BIT ABOUT ATM HISTORY)

5. The 1stidea: no ATM –no cry
•1939 –the 1stidea of ATM
•The City Bank of New York rejected it
•If you don’t have ATM, it can’t be hacked

6. 1967 –the world’s 1stATM

7. Card&PIN&online&soon

8. Today we can use and investigate ATMs

9. WHY WE ARE DOING IT?

10. $#it happened

11. Banks are curious

12. We are curious

13. ATMs are hacked
•Trojan.Skimers
•Backdoor.Ploutus
•Tyupkin
•Another target attack
•Undocumented features
•“Top secret” data is online

14. ATM Jackpotting by Barnaby Jack
•Remote controlled ATM with admin tools
•Firmware updates
•Dispense money

15. OLD PHYSICAL STUFF (SKIMMERS AND PIN SNIFFERS)

16. •Encrypted PIN Pad
Motorized hybrid card readerWhat is inside

17. •
Motorized hybrid card readerCard reader

18. Track2 is enough for transaction

19. PAN = the 1stpart of Track2

20. •Skimming
•Shoulder-surfing, hidden camera, mirrors
•Fake PIN pad
•Fake ATMI need your PIN, your card and your cash

21. Like valid slots

22. The most popular devices

23. Converted anti-skimming

24. 3D printing skimming

25. via http://krebsonsecurity.com/ Fake ATM

26. Your money is not yours anymore

27. HOW HARD TO GET INSIDE OF ATM?

28. -Service zone
-Plastic cover
-Single lock
-Safe for money
-Steel + concrete
-Rotary code locks/electronic locks
-Two types of locksATM countermeasures

29. How to get in

30. How to get in

31. How to get in

32. ATM is locked

33. DEMO

34. HARDWARE AND PREPARATIONS

35. -Minimal price
-Small
-Capable of using multiple interfacesIntent

36. -Raspberry Pi
-2 USB ports
-Ethernet
-USB-COM converter
-Facedancer(kudos to Travis Goodspeed)
-Wifidongle
-Battery =) Hardware

37. -PWN Pi
-Python
-pySerial
-pyHID
-pyUSB
-TTWE framework (thx rvantonder) Software

38. Raspberry Pi + Python + WiFi= bingo! Our “malware” devices

39. HOST BASED ATTACKS (XFS VULNERABILITIES)

40. XFS insecurity
Network communicationWindows-based application Configuration informationUnit #1Service provider #1Unit #2Unit #3Service provider #2Service provider #3Unit #4Service provider #4Unit #5Unit #nService provider #5Service provider #nXFS APIXFS SPIXFS managerCOMUSBCustomer/Service mode

41. XFS insecurity
Windows-based application Network communication
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

42. XFS, PIN Keypad device
PIN device
–Open mode and secure mode read data
–Export of key is not available

43. XFS,Identification Card Device
IDC device
–Read/write data
–Insert/eject/retain cards
–EMV reader

44. Cash Dispenser Device
–Cash withdrawal without authorization
–Cassette and cash control
–Software safe openingXFS, Cash Dispenser Device

45. -Authentication?
-Hard to get specification?
-Exclusive access to XFS manager/service provider? XFS authentication

46. -Authentication? What authentication?
-Hard to get specification? Freely available
-Exclusive access to XFS manager/service provider? Exists, but not intended to be used for securityXFS authentication

47. •Early 2014 –95% of ATMs run on Windows XP
•Support killed off in April
•>9000 vulnerabilitiesWindows XP still alive

48. So?

49. DEMO

50. DEVICE-SPECIFIC ATTACKS (PHYSICAL INTERFACES COM/USB)

51. RS232 insecurity
Network communicationWindows-based application Configuration informationUnit #1Service provider #1Unit #2Unit #3Service provider #2Service provider #3Unit #4Service provider #4Unit #5Unit #nService provider #5Service provider #nXFS APIXFS SPIXFS managerCOMUSBCustomer/Service mode

52. DinosauRS232
•Standard interface
•No specific drivers
•No authorization
•Insecure proprietary protocols (just sniff and replay)

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

54. •Protocols bloat
•Specific method of integrity control
•Short timeouts
•Endless polling
•New firmware version = new protocolDifficulties

55. DEVICE-SPECIFIC ATTACKS (COM-PROTOCOLS)

56. -No good tools for analysis
-No flow control
-No host loss detection
-Packets
-Fixed size
-Start/stop bytes
-Length prefix + dataTypical serial protocol

57. Life without wireshark

58. Typical data
0230
XX XX
XX
01 01
02 00
03 00
04 00
05 00
06 00
1003
42

59. Typical serial protocol
0230
XX XX
XX
01 01
02 00
03 00
04 00
05 00
06 00
1003
42
-02 30 / 10 03 –start-stop sentinels
-XX XX–op-code
-XX –Unknown
-01 01 … –data
-42 –CRC8

60. -Request insert card
-Acknowledge host about card inserted
-Issue 3 separate commands to read 3 tracks
-Issue additional commands for EMV communicationIDC device flow

61. -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
-PaymentsIDC device attacks

62. PIN device flow

63. -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 hostPIN device flow

64. PIN MITM attack

65. -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 unmodifiedPIN device MITM attacks

66. -Restart/check device
-Dispense X notes from Y cassettes
-Open shutter
-Present notes to userDispenser device flow

67. DEMO

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

69. What we think

70. HOW TO LIVE WITH ALL THIS?

71. -Service zone is important
-Current methods of protection is not enough
-Using execution prevention software without OS patches –is wrongConclusions

72. -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 ATMsProposals

73. Alexander Tlyapov, @Rigmar
SCADAStrangeLove, @scadasl
And all other guys worth mentioningKudos

74. Alexey Osipov, @GiftsUngiven
Olga Kochetova, @_Endless_Quest_ Questions?