Hey I Hacked Your Skimmer: Lessons Learned in Embedded Device Security

hi my name is caleb and i'm here today to present to on our topic titled hey i hacked your skimmer uh lessons learned in embedded device security by observing what not to do if you're here to learn how to make a skimmer uh for yourselves you're in the wrong virtual room as i mentioned my name is caleb davis and zane zane hussein will also be presenting with me so a little bit about me i joined productivity in june of 2019 specifically the emerging technologies group where we worked on penetration testing of iot devices uh cloud infrastructure aiml and quantum computing i have a degree in electrical engineering from the university of texas at tyler where i began my career as an

embedded software developer at a residential hvac company as a software developer i primarily focused on embedded c code on armcore microcontrollers for hvac controls being a developer also required me to focus on how to securely design embedded devices which eventually led me to the much more enjoyable task of actually breaking things now i work as an embedded penetration tester where i focus on things like hardware firmware rf testing apis uh web and application mobile application testing so hi everyone my name is zane hussain i also work as a security consultant at protivity alongside caleb i'm a bit newer to the team i joined around four months ago so i studied software engineering at the university of texas at dallas

with a focus in information assurance i like to work with my hands and so i jumped at the opportunity to work on hardware for the emerging technologies group i'm passionate about cars and use my skills to hack them so let's take a look at our agenda in this presentation we'll first get an overview of the case then we'll dive into the card skimming device itself after that we'll talk about the process of data exfiltration and analysis then we'll go over the next steps and finally give examples of mitigations that can be taken and at the end we'll have some time for questions all right so what happened the client found a skimmer on a pos system at a

grocery store removed it and brought it to us they wanted to understand what if any data was compromised our objective was to analyze the methodology used to skim and store credit card information as well as recover any compromised data associated with the credit card skimmer so what did we do well we reviewed the card skimmer architecture and interfaces we extracted the internal flash excuse me the external flash memory from the onboard flash chip we extracted the internal flash memory from the microcontroller unit the mcu we analyzed the extracted data for any sequences that could potentially be credit card numbers we identified the bluetooth interface pin from internal memory and what was the result well we were

able to identify 95 potential credit card numbers for the client to validate with their records and we were able to expose the bluetooth pin allowing us to connect through what is likely the intended interface used by the skimmers so let's talk for a minute about the rise in credit card skimming um 47 of americans have been victim to credit card fraud in the past five years uh card skimming fraud has increased at a rate of around 10 percent per year which has enabled this next statistic and the fact that 35.4 of all credit card fraud in the us is related to counterfeit cards and in 2016 losses topped 22.8 billion dollars worldwide so even if it doesn't seem like you

might care about something like this it's definitely affecting your life in one way or another all right so let's break down the actual card skimmer so here's a look at the actual skimmer that the client presented to us next to the kind of pos system that it was found on in their stores so this would be laid on top of the pos in that grocery store immediately we can see a few things at the bottom you can see the pcb with its colored wiring in the middle we can see the keypad and its black wiring and at the top we can see a small battery we'll take a closer look at the pcb in a

minute but immediately it appears that it was manufactured somewhere else and then obtained by this group our forensics team also noted the state of the dust and adhesive on the device indicated that the skimmer had not been deployed for a long period of time so i'll pass it back to caleb to break down exactly what we found on the pcb sure thanks zane so the first step to analyzing a pcb is to review the board's major components most components have legible part numbers which allow us to research data sheets and user manuals that contain in-depth information on the device and how it is intended to operate once we fully understand the primary function of each component we can then begin to

analyze how these components start to interact with each other in this case we identified the odesto 16 megabit external flash memory part um in the the lower left hand corner which communicates over a spy bus to the silicon labs pearl gecko 32-bit microcontroller the mcu also interfaces with the nuc029z bluetooth module likely via a serial interface which we will find a little bit later on as well as the magtec ic which is used to read the electromagnetic field which is created when a card is swiped we also identified a depopulated header that we assumed to be a jtag interface which is used primarily for programming and debugging the mcu we'll discuss that in future slides but

we really had that hypothesis due to the proximity to the mcu after we understood the major components the the next step was to try to prioritize where the sensitive data would reside our first path was obviously external flash memory considering storage is the primary function of the device and then the next step was to look into internal flash memory in the event that they were storing credit card numbers locally or if we wanted to start to decompile and reverse engineer the firmware on the mcu itself lastly if we were unable to access either flash memory we're going to attempt to brute force the bluetooth classic pin using a raspberry pi and a usb bluetooth module

as i mentioned previously the first step in understanding a component is to determine the model number via the markings on the component in this case as you can see in the picture the part was the edesto at45db 161e which happens to be a 16-bit flash memory device and according to our calculations it is capable of storing approximately 250 000 credit card numbers um a common protocol for interfacing with external flash memory is over a serial peripheral interface or spy bus this protocol is commonly used in pcbs due to its high data rate and the ability to have several devices connected to the same data lines the data sheet also contained critical information on the pin out

which helped us in soldering uh to the appropriate pins as you can see on the left side picture and lastly i will also mention that soldering small electronics like this is relatively difficult however it could be made a lot easier with the proper ic clips which allow you to avoid soldering altogether so the next step was figuring out how we actually want to interface with the external flash memory device um so what you can see in the the far left is the pin out for a raspberry pi 4 specifically so it has a spy interface on board that we can utilize and then the the picture in the center just demonstrates uh how we were able to

pin out the raspberry pi 4 and utilize a breadboard to connect directly to the odesto part that we had previously soldered to the the key part here is we had to understand how to disable the mcu from communicating with the spy device the nature of spy we cannot read from two different devices at one time so if the mcu is trying to interact with the odesto part it could corrupt the data that we're receiving from that device so there are a few different ways to go about disabling the mcu the first probably most common way is to desolder the odesto flash memory part however this introduces some complexities with potentially destroying the device whether you get the device uh

too hot uh while desoldering it or if you uh pry it open and and crack um some of the internals of the device um it introduces a lot of complexity and danger especially with this application um where if we lose uh the component we potentially lose all of the information that was exfiltrated from the actual skimming exercise so we wanted to stay away from that another option is to cut the traces directly to the mcu and the way that that's done is we identify the traces either on the top or bottom layers of the board and can use something like an exacto knife to electrically disconnect um by just uh just cutting the traces on the pcb however this is

brings up another issue where sometimes the traces aren't uh readily accessible uh as well as if you ever need to reconnect it um it is not trivial to reconnect uh traces uh it takes a very high level of skill and soldering to do that so our our method for holding the mcu and reset was to identify the pin as you see in the picture to the right this happens to be the reset pin of the mcu and if we hold this pin to ground we are actually able to keep the mcu from booting as intended and therefore able to interface to the odesto part with the raspberry pi without any external interaction for many additional

components on the device and once everything has been electrically connected appropriately and then the mcu has been held in reset it's as easy as running a flash rom command to use the raspberry pi spy interface and then write directly to a file and this flash rom interface is just a it's a common uh tool that's used for reading external memory devices it has the specifics for interfacing with different external flash memory parts over spy so it really removes a lot of the the complexity in reading from these external devices so the next step was to try to understand what was in internal flash um as i mentioned previously our primary threat vector there was through the jtag

interface um that we assumed to be directly connected to the efm32 by that depopulated header um so what we wanted to do first was once again understand the actual specifics of the pearl gecko part that's being used um in in this case we were able to find the data sheet uh and identify the actual jtag pins as you can see on the picture to the left um so tck tms swo tdi and tdo were all used to interface with the device and then as you can see in the the pin out to the right um we can find where these actual pins were on on the board and then it's as simple as running a continuity test

um with a standard multimeter and we can determine uh which header points are connected to which uh debug interface and from there we can simply just solder additional wire directly to that header and pin it out to a breadboard as you saw earlier earlier after we were connected to the mcu on the skimmer itself we wanted to set up our debugger to connect to the mcu from that end as well so what we had to do here was to understand a the jtag pin out for a 20 pin in this case a sega j-link so it's very straightforward simply connect uh the same uh jtag pins to the mcu um and then from there it's as

simple as running in this case the say your jmem tool and you can connect directly to the mcu and read all the contents of the internal flash memory so after that we were analyzing the the text entries specific specifically in the internal flash memory we noticed um distinct entries where things were being stored as text and based on the notation in which they were stored we assumed that there were at commands which are likely used to interface with the bluetooth module over a serial interface like i mentioned um this is uh very common with modules specifically there's a simplified interface where the mcu simply has to write these payloads over uh uart or i squared c or something along those

lines uh to interface with the bluetooth module and the module contains its own stack for the actual bluetooth so as you can see here we're able to identify the uh the bluetooth broadcasting name as las vegas which we could confirm um by sniffing the the bluetooth traffic um and then we were also able to confirm that the 1357 pin was in fact the the true pin and then allowed us to bypass the uh the brute forcing of the bluetooth interface because we went to internal flash first all right so now that we had the data we really wanted to understand um what was out there and uh what we were really looking for so the

first thing i'll mention is with external flash memory it looks like the data had not been written to it was effectively empty um with basically just the formatting at the top of the external flash our theory that we like to think is that it was too difficult for the controllers of the mcu firmware to actually interface with spy flash it's not incredibly trivial um so somebody that doesn't have a history of embedded software development uh may not be able to figure out how to interface with spyflash in that sense um so our next step was to understand uh if things were stored in internal flash memory which is significantly easier if you're already writing code um

on the efm32 for instance uh it's very easy to identify some sort of region to start storing credit card numbers um so in order to do this we wanted to create an algorithm to identify when we think a credit card number is being stored so to do this we we wrote an algorithm to understand if cards were being stored in 8-bit fashion 16-bit or 32-bit as well as determining if they were big or little indian so once we had those checks we would run through and determine sequences um and if we had a sequence that matched a valid credit card number uh at least in the the proper range um that was flagged and then ran through a

lund algorithm which is a mathematical operation for determining if a card is valid um that's pretty easy to program into our script and from there we were able to determine that there were 95 valid credit card numbers and it was pretty evenly distributed throughout internal flash and the distribution of these valid credit card numbers is very important um we we feel strongly that the these instances are anomalies or random as part of the uh mcu flash memory just because of the nature where they're stored so in the picture to the left you can see the the valid credit card number that was obviously redacted and then you can see the address in which it was found um

so this is somewhat telling if it's distributed across the uh the flash memory the developers of the mcu firmware have to understand where these credit card numbers reside in flash memory um if they were to operate on a credit card number accidentally they could effectively break their their operation and cause the mcu to go into a hard fault condition so they would either have to determine a very specific region or write a very complex memory algorithm to understand when they can execute in memory and when they can't um so as you can see in the entropy analysis of the firmware image um the the data was uh pretty consistent in the firmware image uh up until the uh the end of

the firmware from from what we can gather um and we don't see any other instances of entropy being stored on the device so from that we inferred that there's no dedicated region to storing credit card numbers so those credit card numbers would have to reside in that application firmware space as well if they were there at all all right so let's take a look at the next steps we would like to have kept going but the client was satisfied with the extent to which we had tested unfortunately that meant we could not continue had we been able to these would have been the next steps so first we would have attempted to decompile the firmware

this would allow us to get a better understanding and determine if the credit card numbers are being stored in some novel way we would like to identify if there was a kill switch type function in place to delete the data after some amount of idle time we would also like to see if any encryption methods were used in storing of the credit card numbers so next we would further analyze the bluetooth interface uh with the bluetooth pin used for connecting to the skimmer we could hopefully determine the intended method for exfiltrating that skimmed credit card data finally we would have liked to analyze the skimmer in a live environment this would help us determine where

credit card info is intended to be stored and if there are any controls in place to secure that data and that test would require the skimmer to be connected to a live pos system so why should you care well we were easily able to access the data on this device that doesn't bode well for anyone hardware and embedded devices are increasingly a part of our daily lives devices like medical equipment for example are a target for hackers that's bad for patients that can lead to a disruption of potentially life-saving treatment or disclosure of personal or health information and that's bad for companies for example those operating under gdpr the data privacy regulations in europe and those fines can be

hundreds of millions of dollars we were happy to be able to access the data on this skimming device but we'd like to help well-intentioned devices not suffer from these same vulnerabilities again we are not going to help you build a better skimmer but i'll pass it back to caleb to go over some of these mitigations in in further detail sure thanks zane so the first obvious uh idea for a mitigation would be to use encryption so the the recommendation for encryption is is pretty standard here um you can rely on aes 128 192 or 256 and then you must use a secure mode of encryption such as cbc um do not use ecb and then also maintaining a secure key

distribution model is imperative to rolling out encryption on embedded devices however uh encryption uh can be tricky on hardware devices just because it is still prone to what's known as side channel attacks um so i'll go over a few different side channel attacks and a possible mitigation um and and what that means to your devices and and the business as a whole so the the first attack that i'll discuss is power analysis both differential power analysis and correlated power analysis um so an example of differential power analysis is looking at um cycles and being able to infer operation based on um the the power consumption with two different uh cycles right so a very simplistic

example of differential power analysis would be uh in the event of like a password-protected bootloader um if we were able to determine uh the the power transient of a correct character versus an incorrect character based on uh how the mcu handles that data what we can do is brute force the attack and connect directly to the uh mcu that's hosting the the bootloader um and we can brute force uh that password pretty quickly by simply analyzing um the power analysis of each of those characters and the another example of power analysis is known as correlated power analysis where um the the correlation between what's known as hamming weight values to um aes guesses in this case um can be used

to to crack encryption um within approximately five minutes um so to to take a step back um when when data lines are driven high as you can see in the figure to the top left uh it requires power so the theory behind this is that when a data line is high it requires a level of power and then if multiple data lines are high or if multiple bits right are are high or one um it would require more power than uh a bit level that is lower and that's referred to as hamming weight the number of bits that are that are high um so the theory is if we can correlate hamming weight value to

power measurement then we can start to make some assumptions based on what we see um from a power measurement perspective typically uh in terms of aes so as you can see in the the middle graph there um this correlation is linear um so as you go up in hamming weight value you also go up in power consumption um so then what that enables us to do is target uh aes so in this case um we can target uh aes the encryption cycles the first round of encryption um if we're able to capture the the plain text before it gets encrypted as well as the power consumption um what we can do is compute the guess

of the sub key by running it through the the substitution byte uh process and then we can use that substitution byte and convert it to a hemming weight value and then correlate that data set with a with the power consumption and then determine uh using what's known as the a pearson correlation coefficient we can determine uh the highest correlation between two data sets and then once we can confirm the highest correlation between the data sets we can do that for each sub key and then essentially brute force and guess the aes key using completely side channel attacks and as i mentioned we can do this pretty effectively with as little as 50 power traces um so

as long as getting the configuration set up um and understanding when encryption's happening um this can be done pretty quickly from an execution perspective and this is all done uh using at least we use the the chip whisperer pro and it's shown in the bottom left picture there uh connected to a target board for for testing purposes i will also mention that um these the cpa type attacks can be used for decryption um so in the event that we can capture ciphertext and analyze the decryption cycles of aes we can backwards calculate the last round aes key and then it's easy to compute the the first round ads key from there and also the the fault attacks as i

mentioned uh vcc and clock glitching can be used to skip security checks entirely by causing the mcu to operate or to load the next instruction prior to executing the previous um and cold boot attacks are nothing new as well where you can use something like a free spray to cool down memory and extract the contents before they've dissipated so the mitigation to this is a secure element so various secure elements have different capabilities a significant amount of them are able to perform random operations that can draw power uh to mitigate against power analysis type of attacks um they can detect abnormalities and voltage rails and clock signals to prevent faulted attacks and then some secure elements can also observe

sudden changes in environmental conditions to mitigate against cold boot type attacks these devices also are implement significant tamper mechanisms um to prevent access to the authentication keys that are typically flashed onto the device itself the only caveat to these secure elements is that they do cost money so if you're talking about a very low-cost iot device um the cost of implementing a secure element may not be prudent um but we wanted to make sure and communicate to you uh the implications of simply relying on aes encryption in your embedded devices so another category of mitigations are hardware mitigations um and none of these are the end-all be-all mitigation by any means i think these need to be coupled with

several mitigations to just add extra layers of security to your device um the first one i'll mention here is pin obfuscation um essentially what we saw in the the skimmer was a depopulated header where the vias were uh in a line directly connected next to the mcu um so we we kind of knew just looking at it exactly what that was um so in uh production applications you can obfuscate the pins by uh having different vias spread throughout the board for uh jtag uart spy i squared c um anything along those lines uh that can obscure um what that looks like to just increase the the level of entry um for connecting to those interfaces

however there are tools such as the jtagulator which allows you to brute force unknown pins by running boundary scans by sending data to understand rx and tx lines with a pretty easy to use interface we're also to able able to read over the jtag interface pretty easily so most mcus support reprotection where you can simply disable that capability in production which in in production revisions of your devices reprotection should always be disabled bga packages is another good step as you saw with the odesto part we were able to connect directly to the component similarly um mcus often use what's known as a qfp package as seen on the right um these pins are very easy to connect to

pry up or bridge uh if necessary whereas the bga on the left the the pads are all underneath and it is very difficult to remove or modify without specialized tools and any skill and then lastly don't tell us exactly where the jtag interface is uh that makes it very easy um as you can see in the bottom right we can see the tdo tms tck all in line there and lastly the the bluetooth mitigations um they were using bluetooth classic uh so in in modern bluetooth versions you can increase their uh four-digit pin to an eight-digit pin um as i mentioned with bluetooth classic if you're using anything less than or equal to 2.0 um

you should use be using secure mode three if you're using anything greater than 2.1 you can use the aes 128 encryption that's on the link layer we would recommend using ble if it's possible specifically with out of band pairing uh or pass key or numeric comparison um in terms of out of band pairing either something like nfc or a qr code is usually sufficient for exchanging those keys in a in a more secure manner if you're using ble less than 4.2 you can use the legacy pairing methods anything greater than or equal to 4.2 we can rely on the secure pairing methods and then blue dot fi bluetooth 5 is relatively new we haven't seen a ton of exposure to it yet

however they do have a seemingly more robust methodology of key exchange however the best mitigation to bluetooth is to not use it um so the the nsa has uh discussed the uh how insecure bluetooth is as a protocol um so we would recommend using if possible wi-fi direct uh nfc and fmi uh or lte specifically nb iot uh when at all possible and that's all that we had today um so if you have any questions uh we'd be happy to discuss on the uh the forum thanks thank you