PinPadPwn
Presenters: Nils, Rafael Dominguez Vega
This presentation demonstrated malware executing on three different pinpads. The malware can be loaded via the pinpads' public-facing interfaces (smart card reader or online comms) clandestinely while the pinpads are deployed live in the field.
A pinpad is a high-security device into which a card-holder enters their PIN. Pinpads are expressly designed to defend against rogue software being loaded onto them, in accordance with PCI PTS POI Modular Security Requirements v3.1 requirement L2:
The certified firmware is protected and stored in such a manner as to preclude unauthorized modificationNote the uncompromising word "preclude" as opposed to something more nuanced such as "resist".
The presenters Nils and Rafael demonstrated attacks on three different POS pinpads. I believe that each of these pinpads was from the same manufacturer, but Nils and Rafael stated that they did not wish to "name and shame" the manufacturer, and covered the devices' branding identification, so I shall respect the manufacturer's anonymity herein. But the devices were easily recognizable, indeed one of them displayed the manufacturer's logo on its startup splash screen.
They did not disclose specific details of the pinpad's vulnerabilities because the patches were not yet implemented/deployed, but they did show some of their methodology and their results. So please excuse any errors/omissions/vagueness in the descriptions below – I would welcome any corrections/clarifications.
Cases #1 and #3
I assume there were significant differences between cases #1 and #3, but the attacks appeared to be similar. The details below were mostly given for case #1.
In their lab, Nils and Rafael pumped large data into the pinpad's Ethernet interface, creating a stack overflow. Upon such errors, this pinpad provides a window into the consequences of the overflow, displaying the values of several of the microprocessor's registers soon after the overflow occurred. This is a deliberate feature to assist with debugging, the pinpad's user manual says that it:
helps developers interpret the cause of the most recent unrecoverable software error that occurred on the terminalHere's an example of what the pinpad displays, as given in the pinpad's user manual:
TYPE 1Nils and Rafael used techniques such as including a small infinite loop in their data which overflows the stack, and noting the values displayed for the program counter and fault address when the infinite loop occurs (I assume when a watchdog timer expires), so by gradually adjusting the size of their attack payload they could locate the top of the stack, which ultimately allowed useful code execution. They then sought to dump memory, first displaying it on the pinpad's screen, and once they'd gained a foothold then sending it out the Ethernet port. I believe they also mentioned that they employed ROP techniques. Thus they ran rogue code on the pinpad to assist with their investigations, and examined the pinpad's existing code, observing hard-coded passwords and discovering vulnerabilities in areas including the smart card software.
TASK 2
TIME 060302201212
CPSR 40000010
PC 00000004
LR 70448B23
ADDR 27FFFFEF9
• CPSR (Current Program Status Register): contains the processor and state condition code.
• PC (Program Counter): holds the execution address.
• LR (Link Register): holds the return address of the function call.
• ADDR (fault address): contains the illegal address that the application was trying to access.
They used BasicCard to develop a malicious smart card which logs commands sent from the pinpad to the smart card and which executes a script to send (sometimes malicious) responses from the smart card back to the pinpad.
They setup a control environment to understand the system's behavior. They would insert their rogue smart card into the subject pinpad and progress through a transaction, and then insert their smart card into a PC which would extract the captured commands and then replay these commands to a legitimate smart card. Thus they examined how the pinpad and the smart card handle various cases.
They then created a malicious smart card which could be used in the field, outside their lab. When inserted into one of these pinpads, this malicious smart card provides responses which direct the session into a specific vulnerable state, and which then overflow a buffer, thereby injecting their rogue code.
For case #1, their rogue code was a car racing game. For case #3, their rogue code was a serious malicious attack – their app captures account numbers and PINs and later dumps them onto the attacker's smart card, and their app also appears to approve transactions but in fact does not communicate with the host.
Case #2
Through the pinpad's local administrative functions, the user instructs the pinpad to contact its remote management server after its next restart. The remote management server then downloads new software to the pinpad.
Usually the pinpad verifies any new software's cryptographic signature before installation, but in this specific case of receiving new software from its remote management server after a restart, this pinpad does not verify the signature.
For what it's worth, this is a breach of PCI PTS POI Modular Security Requirements v3.1 requirement B4:
If the device allows updates of firmware, the device cryptographically authenticates the firmware and if the authenticity is not confirmed, the firmware update is rejected and deletedSo by impersonating the remote management server, unsigned rogue software may be downloaded to the pinpad.
Conclusion
It appears that the following vulnerabilities in the pinpads were exploited:
Cases #1 and #3
• Inadequate handling of boundary cases, allowing buffer overflows on both the Ethernet and smart card interfaces.
• Displaying register values upon exceptions, providing crucial internal info to the attackers.
Case #2
• Not verifying the downloaded software's signature.
• Inadequate authentication of the remote management server, allowing spoofing.
These pinpads may serve as full payment terminals, and include printers, Ethernet ports, etc., as opposed to more simple PIN entry devices which serve as peripherals to ATMs and POS terminals. I suspect that these pinpads sandbox the POS functionality from the cyptographic material, which perhaps may limit the potential damage of these attacks.
I must note that the results of these pinpad attacks are functionally very similar to Barnaby Jack's attack on my employer's ATM at Black Hat in 2010, arguably even more dramatic because this malware was loaded onto an actual high-security pinpad, while Barnaby loaded his malware onto our ATM's mainboard not its pinpad. Perhaps it's partly just my perception because this time I don't have skin in the game, but this presentation was attended by about 200 people and was received with tepid applause and relatively low-key media coverage, which to me is a strong contrast to the wild hysteria surrounding Barnaby's attack. Go figure.
Don't Stand So Close to Me: An Analysis of the NFC Attack Surface
Presenter: Charlie Miller
This presentation studied potential attacks on cell phones using NFC.
NFC (Near Field Communication) is a short-range (a few inches) wireless communications technology. NFC is the next generation after RFID. There are a vast number of applications for NFC, such as payments, transit tickets, hotel room keys, etc. ATMs and EFT-POS terminals may include NFC hardware so they may transact with cell phones and other NFC-enabled devices/tokens.
Link to the presenter Charlie's NFC attack toolkit.
Fuzzing
Charlie fuzz tested the NFC software on two phones, an Android 2.3.3 Nexus S and a MeeGo Nokia N9.
He simulated an NFC tag using the SCL3711 and ACR122U card emulators. He automatically detected crashes by using ADB logcat on Android, and by using GDB to compare process IDs of the NFCD daemon on MeeGo. He automatically recovered from crashes by power-cycling the hardware with a DUB-H7 USB hub. He simulated the physical presentation (bringing together) of the two entities by effectively stopping and then restarting the NFC services on the phones.
He fuzzed various layers of the NFC protocol:
• Application layer – NDEF messages.
• Tag types layer – tag types 2 and 4. Modified libnfc's nfc-emulate-forum-tag2.c and nfc-emulate-forum-tag4.c.
• Protocol layer – LLCP. CONNECT and I packets. Modified nfcpy's npp-test-client.py on Android and snep-test-client.py on MeeGo.
He produced tens of thousands of test cases, some manually generated, and some created using the Sulley utility.
The fuzzing induced various crashes on the Android phones, primarily within the "Tags" default NFC app, sometimes within Nfc Service, and elsewhere. Most crashes were low-risk Java exceptions, but others may be more expolitable.
The MeeGo did not crash at all. Perhaps MeeGo handles all these test cases perfectly, but Charlie suspects that there was most likely an error in his methodology.
Application attacks
NFC is generally only active when a phone's display screen is on, but Charlie showed that sending a text message to a phone turned on its screen thereby activating NFC. (I didn't observe which model phone.)
Android Ice Cream Sandwich and Jelly Bean include the Android Beam NFC software. An NFC tag can send data to Android Beam which instructs the Android's browser to visit whatever URL the NFC tag specifies, making the browser open a web page or run a script or display an image etc. This opens a vast attack surface. I believe Charlie used this vulnerability to obtain a remote command-line shell.
MeeGo 1.2 includes the Content Sharing NFC software. An NFC tag can send data to Content Sharing which instructs the phone to open whatever file the NFC tag specifies, such as a PDF or Word DOC or image etc. This will occur without user interaction, regardless of the phone's "confirm sharing and connecting" setting. This too opens a vast attack surface.
MeeGo 1.2 will attempt an NFC Bluetooth Pairing without user interaction by default. (A confirmation prompt is given if "confirm sharing and connecting" is set.) Thus an NFC tag can silently take control of the phone – download files off the phone, send text messages, make calls – using tools such as OBEX, gsmsendsms, and gnokii. Furthermore, even if Bluetooth is disabled, the NFC Bluetooth Pairing will enable it.
The following presentations are also relevant to ATMs and EFT-POS, but perhaps not as directly as the above:
Advanced ARM Exploitation
Presenters: Stephen Ridley, Stephen Lawler
On embedded devices which use ARM microprocessors, exploit software bugs to allow an attacker to execute rogue code. Link to presenters' website.
How the Analysis of Electrical Current Consumption of Embedded Systems Could Lead to Code Reversing
Presenters: Yann Allain, Julien Moinard
An attempt to obtain code and data by analyzing DC power consumption of an embedded device. Interesting progress with a dumbed-down system, but certain technical obstacles may be impossible to overcome, particularly with a more sophisticated microprocessor. Link to presenters' website.
Torturing OpenSSL
Presenter: Valeria Bertacco
By subjecting a microprocessor to hostile conditions such as extreme temperatures or voltages, cause hardware malfunctions which result in OpenSSL generating incorrect signatures which contain information about the private key. Significant volumes of these incorrect signatures may be processed on a large pool of computers to obtain the private key. Link to article. (Unfortunately I couldn't attend this presentation because it clashed with the above NFC presentation.) Note that modern pinpads defend against this class of attack by including sensors to detect out-of-range temperatures and voltages in accordance with PCI PTS POI Modular Security Requirements v3.1 requirement A3:
The security of the device is not compromised by altering:
• Environmental conditions
• Operational conditions
(An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.)