For the Love of Money Finding and Exploiting Vulns in mPOS Systems

Video thumbnail (Frame 0) Video thumbnail (Frame 1672) Video thumbnail (Frame 4330) Video thumbnail (Frame 5435) Video thumbnail (Frame 6617) Video thumbnail (Frame 7945) Video thumbnail (Frame 8870) Video thumbnail (Frame 10805) Video thumbnail (Frame 12236) Video thumbnail (Frame 13213) Video thumbnail (Frame 14795) Video thumbnail (Frame 16556) Video thumbnail (Frame 17777) Video thumbnail (Frame 19137) Video thumbnail (Frame 20145) Video thumbnail (Frame 21410) Video thumbnail (Frame 23012) Video thumbnail (Frame 24711) Video thumbnail (Frame 26632) Video thumbnail (Frame 27497) Video thumbnail (Frame 28420) Video thumbnail (Frame 29535) Video thumbnail (Frame 30494) Video thumbnail (Frame 31501) Video thumbnail (Frame 32742) Video thumbnail (Frame 33734) Video thumbnail (Frame 35258) Video thumbnail (Frame 36354) Video thumbnail (Frame 37891) Video thumbnail (Frame 39895) Video thumbnail (Frame 41925) Video thumbnail (Frame 42799) Video thumbnail (Frame 43918) Video thumbnail (Frame 45072) Video thumbnail (Frame 45942) Video thumbnail (Frame 47248) Video thumbnail (Frame 48134) Video thumbnail (Frame 49132) Video thumbnail (Frame 50243) Video thumbnail (Frame 51751) Video thumbnail (Frame 52894) Video thumbnail (Frame 55623) Video thumbnail (Frame 56735) Video thumbnail (Frame 58618) Video thumbnail (Frame 62562) Video thumbnail (Frame 63433)
Video in TIB AV-Portal: For the Love of Money Finding and Exploiting Vulns in mPOS Systems

Formal Metadata

For the Love of Money Finding and Exploiting Vulns in mPOS Systems
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
These days it's hard to find a business that doesn't accept faster payments. Mobile Point of Sales (mPOS) terminals have propelled this growth lowering the barriers for small and micro-sized businesses to accept non-cash payments. Older payment technologies like mag-stripe still account for the largest majority of all in-person transactions. This is complicated further by the introduction of new payment standards such as NFC. As with each new iteration in payment technology, inevitably weaknesses are introduced into this increasingly complex payment eco-system. In this talk, we ask, what are the security and fraud implications of removing the economic barriers to accepting card payments; and what are the risks associated with continued reliance on old card standards like mag-stripe? In the past, testing for payment attack vectors has been limited to the scope of individual projects and to those that have permanent access to POS and payment infrastructure. Not anymore! In what we believe to be the most comprehensive research conducted in this area, we consider four of the major mPOS providers spread across the US and Europe; Square, SumUp, iZettle and Paypal. We provide live demonstrations of new vulnerabilities that allow you to MitM transactions, send arbitrary code via Bluetooth and mobile application, modify payment values for mag-stripe transactions, and a vulnerability in firmware; DoS to RCE. Using this sampled geographic approach, we are able to show the current attack surface of mPOS and, to predict how this will evolve over the coming years. For audience members that are interested in integrating testing practices into their organization or research practices, we will show you how to use mPOS to identify weaknesses in payment technologies, and how to remain undetected in spite of anti-fraud and security mechanisms.
Mobile Web Revision control Radical (chemistry) Presentation of a group Server (computing) Hypermedia Hypermedia Different (Kate Ryan album) Square number Bit Number Spacetime
Mobile Web Area Presentation of a group Dialect Multiplication sign Point (geometry) Mobile Web Projective plane Plastikkarte Student's t-test Magnetic stripe card Number Product (business) Radical (chemistry) Moore's law Insertion loss Different (Kate Ryan album) Square number Software testing Square number Asynchronous Transfer Mode Vulnerability (computing)
Mobile Web Area Server (computing) Presentation of a group Mobile app Divisor Mobile Web Projective plane Physicalism Bit Cartesian coordinate system Uniform resource locator Mechanism design Process (computing) Different (Kate Ryan album) Computer hardware Telecommunication Computer hardware Square number Faktorenanalyse Information security Information security Associative property Square number
Point (geometry) Purchasing Mobile Web Dataflow Slide rule Dependent and independent variables Service (economics) Information Memory card Interactive television Internet service provider Plastikkarte Bit Database transaction Radical (chemistry) Goodness of fit Process (computing) Different (Kate Ryan album) Internet service provider Chain Energy level Endliche Modelltheorie
Functional (mathematics) Mobile app Personal identification number Memory card Online help Mereology Electronic signature Magnetic stripe card Number Sign (mathematics) Term (mathematics) Military operation Core dump Energy level Information security Data type Memory card Electronic mailing list Plastikkarte Database transaction Price index Electronic signature Radical (chemistry) Type theory Uniform resource locator Process (computing) Vector space Configuration space Personal area network
Mobile Web Mobile app Server (computing) Connectivity (graph theory) Database transaction Database transaction Connected space Component-based software engineering Radical (chemistry) Number Software Telecommunication Internet service provider Maß <Mathematik> Square number Physical system
Mobile Web Personal identification number State observer Trail Mobile app Divisor Information Code Code Physicalism Radical (chemistry) Mechanism design Process (computing) Computer hardware Telecommunication Computer hardware File system Faktorenanalyse Remote procedure call Information security Communications protocol Physical system Form (programming)
Torus Classical physics Game controller Serial port Link (knot theory) Characteristic polynomial Heat transfer Generic programming Mereology Number Spherical cap Profil (magazine) Hierarchy Software Encryption Energy level Communications protocol Information security Game controller Service (economics) Link (knot theory) Assembly language Information Characteristic polynomial Interface (computing) Attribute grammar Frame problem Radical (chemistry) Category of being Data management Process (computing) Telecommunication Order (biology) Communications protocol
Functional (mathematics) Identifiability Range (statistics) Amsterdam Ordnance Datum Port scanner Mereology Frame problem Type theory Frequency Telecommunication Telecommunication Uniqueness quantification Address space Vulnerability (computing)
Functional (mathematics) Information Characteristic polynomial Software developer Multiplication sign Instance (computer science) 2 (number) Connected space Type theory Process (computing) Software Vector space Bit rate Different (Kate Ryan album) Personal digital assistant Telecommunication Vector graphics Order (biology) Metropolitan area network
Radical (chemistry) Server (computing) Email Vector space Information Bit rate Electronic data interchange Electronic mailing list Software development kit Computer worm
Authentication Functional (mathematics) Software developer Characteristic polynomial Software developer Authentication Cartesian coordinate system Anwendungsschicht Function (mathematics) Operator (mathematics) Order (biology) output Energy level Quicksort Electronic visual display Communications protocol Communications protocol
Functional (mathematics) Mobile app User interface Insertion loss Function (mathematics) Plastikkarte Login Mereology Cyclic redundancy check Magnetic stripe card Peripheral Computer configuration Electronic visual display Message passing Modem Service (economics) Information Software developer Sampling (statistics) Plastikkarte Database transaction Mereology Radical (chemistry) Message passing Order (biology) Spectrum (functional analysis) Computer worm
Scripting language Addition Group action Database transaction Database transaction Magnetic stripe card Radical (chemistry) Message passing Vector graphics Square number Authorization Quicksort Electronic visual display Force
Classical physics Frame problem Email Insertion loss Plastikkarte Mereology Cyclic redundancy check Magnetic stripe card Exclusive or Different (Kate Ryan album) Electronic visual display Information Communications protocol Message passing Information Direction (geometry) Plastikkarte Mereology Control flow Radical (chemistry) Message passing Process (computing) Computer worm Address space Flag
Type theory Moment (mathematics)
Server (computing) Process (computing) Information Software developer Blog Database transaction Data structure Intercept theorem Database transaction Proxy server
Android (robot) Software developer Code Attribute grammar Login Cartesian coordinate system Database transaction Message passing Hexagon Cross-correlation Peripheral Blog Computer configuration Bridging (networking) Personal digital assistant Data structure Communications protocol
Purchasing Service (economics) Memory card Internet service provider Statement (computer science) Plastikkarte Database transaction Electronic signature
Addition Service (economics) Information Database transaction Maxima and minima Data storage device Limit (category theory) Open set Limit (category theory) Magnetic stripe card CAN bus Type theory Term (mathematics) Operator (mathematics) Internet service provider Asynchronous Transfer Mode
Personal identification number Mobile Web Service (economics) Building Touchscreen Service (economics) Multiplication sign Internet service provider Code Plastikkarte Database transaction Control flow Group action Magnetic stripe card Magnetic stripe card Radical (chemistry) Latent heat Root Internet service provider Telecommunication Form (programming) Reverse engineering Physical system
Email Server (computing) Link (knot theory) Computer file Set (mathematics) Electronic signature Revision control Advanced Encryption Standard Goodness of fit Process (computing) Personal digital assistant Enumerated type Repository (publishing) Configuration space Right angle Firmware Reverse engineering Firmware
Touchscreen Personal identification number Computer file Code Memory card Computer-generated imagery Set (mathematics) Plastikkarte Stack (abstract data type) Binary file Revision control Root Average Operator (mathematics) Process (computing) Computer file Cartesian coordinate system Type theory Message passing Root Buffer solution Interface (computing) Configuration space Remote procedure call Buffer overflow Firmware
Type theory Radical (chemistry) Trail Personal identification number Trail Information Hacker (term) Personal digital assistant Operator (mathematics) Whiteboard Mereology
Personal identification number Trail Radical (chemistry) Personal identification number Trail Encryption Binary file Asynchronous Transfer Mode
Mobile Web Point (geometry) Mobile app Server (computing) Dependent and independent variables Trail INTEGRAL Digitizing Cellular automaton 2 (number) Electronic signature Revision control Personal digital assistant File system Firmware Game theory Booting
Trail Process (computing) Personal digital assistant Multiplication sign Internet service provider Firmware 2 (number) Asynchronous Transfer Mode
Radical (chemistry) Internetworking Set (mathematics) Bit Determinism Computer-assisted translation
Airfoil State observer Goodness of fit Mechanism design Computer hardware Software developer Computer hardware Set (mathematics) Information security Public key certificate Communications protocol
Geometry Uniform resource locator Process (computing) Cross-correlation Different (Kate Ryan album) Mass storage Square number Faktorenanalyse Database transaction Process (computing) Database transaction
Area Presentation of a group Server (computing) Vapor barrier Memory card Maxima and minima Internet service provider Vector potential Product (business) Revision control Carry (arithmetic) Process (computing) Different (Kate Ryan album) Hypermedia Order (biology) Computer music Software testing Information Process (computing) Block (periodic table) Normal (geometry) Table (information) Information security
Memory card Multiplication sign Projective plane Plastikkarte Counting Database transaction Magnetic stripe card Electronic signature Product (business) Radical (chemistry) Sign (mathematics) Message passing Uniform resource locator Carry (arithmetic) Arithmetic mean Order (biology) Energy level Summierbarkeit Software testing Communications protocol Information security Vulnerability (computing) Physical system
Presentation of a group Code Execution unit Visual system Database transaction Magnetic stripe card Software bug Magnetic stripe card Sign (mathematics) Mechanism design File system Process (computing) Information security Vulnerability (computing) Area Personal identification number Software developer Physicalism Database transaction Control flow Electronic signature Radical (chemistry) Arithmetic mean Process (computing) Software testing Hill differential equation Remote procedure call Information security Asynchronous Transfer Mode Firmware Point (geometry) Asynchronous Transfer Mode Game controller Server (computing) Capillary action Mobile Web Authentication Distance Product (business) Revision control Cross-correlation Energy level output Implementation Communications protocol Firmware Traffic reporting Plastikkarte Basis <Mathematik> Wärmestrahlung Revision control Intercept theorem
Mechanism design Peripheral Code Computer hardware Moment (mathematics) Projective plane Physicalism Remote procedure call Information security Vulnerability (computing) Firmware
so we had a bit of an interesting morning and if you want to see the uncensored version of this presentation it's available on the media server so go ahead and pull that up while it lasts we had a few issues with some of the vendors that are affected by our presentation so like I said if you want to access the uncensored version go for it and we really appreciate you all coming out this morning I know last night was a big night for most of you so thank you very much we've not had breakfast yet and we hope that we can all wake up together with this presentation so let's talk about mobile point-of-sale terminals mobile point-of-sale terminals has seen a huge growth over the last few years we've moved from a single vendor which has dominated the marketplace so we've seen Square dominating this space for the last are eight years and now we have a number of different vendors in this space you can open an account in less than five minutes and typically these readers cost less than 50 so for these reasons they have grown really in their popularity over the last two years
you can find them pretty much everywhere so there's these are some of the pictures that we've taken so I've seen them in taxis in cafes that's my gym as well completely unattended and like traditional ATMs and like traditional point-of-sales terminals they sit at the endpoint of payment infrastructure for so for these reasons they're very attractive to criminal criminals both for the testing of cars and for the movement of money but of course we
weren't the first to investigate mobile point-of-sales terminals in 2014 MWR labs gave their presentation at black hats and in which they discussed findings around the Miura shuttle reader so at this time this was being white labeled and used by a number of different vendors and of course this kind of practice is still very common today so in their presentation they documented a number of vulnerabilities of which many had overlapped with traditional point-of-sales terminals then in 2015 three undergraduate students the Boston University presented their findings on the square mag stripe reader at black hats we felt that both of these research projects were really significant contributions in this area but they focus on single products and the market has matured considerably so for this reason we didn't feel that they dealt with a more contemporary broader issues associated with this marketplace at the beginning of this project we started with just two card readers and two vendors and very quickly this has grown into a project which encompasses seven card readers four vendors and two Geographic reason regions we chose to
assess the most popular devices both in Europe and in the US we've chosen to focus on PayPal square eyes Ethel and sum up now some of these vendors operate in both geographic locations and where possible we chose to obtain the accounts and the readers for both locations and this is because there are quite considerable differences between the processes and the applications and even the readers depending on the region now at the beginning of this project we had a pretty good idea of the kind of attack factors that these devices would be vulnerable to but we wanted to see how probable these were in practice still we
had a very simple question which is how much security can really be embedded in a device that's potentially free so we chose to assess five different areas of the payment ecosystem of these devices we chose to look at the communication between the phone and the payment server communication between the device and the phone physical security mechanisms within the hardware of these devices the mobile application and The Associated mobile ecosystem and finally secondary factors so secondary factors are things that affect the overall risk and security of the ecosystem such as the kind of checks that are being carried out during the enrollment process so before we progress a bit further into the presentation I'm just going to give
you a bit of background on how payments traditionally work for those of you that are not so familiar with that and then we'll talk about how mobile point-of-sale terminals fit into this process so normally when you go into a shop and you go to pay for services or goods you'll either interacts directly with the terminal or your hand your card over to the merchants once your information has been read by the terminal this will be passed to the acquiring bank for the merchant now at this point in the process they don't actually know who you're issuing bank is so they'll ask the car brands such as Visa and MasterCard to determine this information once it's been passed to your issuing bank they'll Jack check that you have the necessary funds to complete the process and then they'll carry out some flow checks if they're happy for you to go ahead and make the purchase they'll send the response along the chain and you can go ahead and make the transaction now if we compare this
process to the mobile point of sales terminal you can see that the key difference is that the mobile the merchant no longer has a direct relationship with the acquiring bank instead the mobile point of sales terminal provider acts as a payment aggregator so this means that there will or won't assess risk at the same level as a traditional acquiring bank they also may choose to mitigate some of the risk in other ways for example contractually but essentially what you end up with is two merchants in this model from there things are pretty similar to how I've described in the previous slide so we're going to be
focusing on card payments this is because the core functionality of a mobile point-of-sale terminal is around taking card payments but it's just worth the cerf noting that within the mobile application of all of these devices they do have features to account for things like cash transactions so when you go to make a payment what happens is there's a list which broadly describes in terms of priorities the types of payments that your card can make and this is confirmed with the configuration on a terminal this list will vary depend on depending on the issuer the the card brand and also the geographic location but generally speaking we can understand that certain payments are more secure than others so for example chip is commonly considered most secure and this is actually because there's a high level of assurance at that the cardholder was present during the transaction if you compare this to a swipe transaction this is considered low in its level of security and that's because most of us in this room know that if you take a magstripe you can clone the data off the mag stripe you can also forge a signature relatively easily as well and there's no signing of the transaction so there's no cryptogram next we need to understand
that whilst EMV has been incredibly successful in its adoption globally it's actually been much lower in the u.s. than compared to many other parts of the world and this is just primarily due to the number of parties that are involved in the rollout process but what's helpful in this scenario is that we can look to places like Europe and we can look at the kind of attack vectors that are happening in Europe and use them as a good indicator of what might take place in the US you can see that for credit cards adoption of EMV is actually quite high so 96% but less than 50% of all transactions are made using a chip so this is a really important fact that we need to keep in mind as we go through the process of presenting these findings if we look at the picture for debit cards it's actually even worse so less than a quarter of all transactions are made using a chip and if we look at
overall growth of mobile mobile point-of-sale terminals you can see that only within a couple of years almost 50% of all transactions will be made by a mobile point-of-sale terminal so how do
these devices work so this schematic overview represents quite simply how each of the components in the system work so we have the terminal which communicates via bluetooth to the mobile application and the phone this in turn communicates to the payment server of the mobile point-of-sale terminal provider via a network connection or over Wi-Fi so now that we
have a broad understanding of how payments traditionally work and how mobile point-of-sales terminals fit into this process we can begin to discuss our findings so we're going to be talking about the sending of arbitrary commands so with this attack factor what you can do is you can socially engineer a cardholder to carry out additional payments or to carry out a less secure payment such as swiped then we'll talk about how for some of the terminals we looked at we were able to modify the amounts so the cardholder thinks that they're actually authorizing a much lower value we're also going to talk about how we obtained remote code execution and one of the readers so this provides us with full access to the file system this means that we can capture track to information before it's encrypted and we can even collect pins then we'll discuss our Hardware observations so looking at the physical security mechanisms within the terminals themselves and finally we'll we will discuss the secondary factors which affect the overall risk and security of these systems so Bluetooth is the main
form of communication between the terminal and the phone and the mobile application so therefore it's important for us to have a good understanding of how this protocol works I'm sure many
people do have an understanding this but I'm going to assume that not everyone in the room does so let's continue so blue T's can be roughly divided into two parts the host and controller layers so the Bluetooth profiles and Gatz and apps they deal with the actual transfer of information l2 cap deals with segmentation and reassembly of packets the host controller interface now this is the lowest level that we can directly interact with it's commonly used for debugging the communication of Bluetooth but if you're a security researcher it's also super helpful to try and work out how the device works so this is something that we're going to look at during this process then the link manager protocol link manager protocol this deals with pairing negotiation and encryption and then baseband is the last layer of framing before we have Bluetooth radio itself when we talk about Bluetooth we're actually talking about two different
chuckles Bluetooth classic and Bluetooth Low Energy now how these communicate is quite different so Bluetooth classic uses something called Bluetooth profiles to communicate and all of the terminals that we looked at that use Bluetooth classic use RF comm so what this does is when you communicate from the terminal to the phone and vice versa what happens is it simulates a serial port which allows you to send large chunks of data if you look at the way that Bluetooth low-energy on the other hand communicates is so with this you have a much smaller packet size and it produces a hierarchical structure under which characteristics are defined so each characteristic has a value and it also has a number of properties such as read write and notify in order to attack a
Bluetooth device or even just to communicate with it we need to understand what its addresses so its address consists of three main parts we
have the upper address bar oh sorry the non-significant address bar which isn't significant for any functions then we have the upper address part and the
lower address part which is unique to each device and that's present in every frame of communication now the non significant address parts an upper address part is what is known as the organizationally unique identifier so if you know a range of organizationally unique identifiers it's possible to sit in a public place and identify a potentially vulnerable device for example you could go to a cafe you can use one of these Bluetooth scanners and you can identify both how close you are to the device based on the frequency and also the type of device it is there are
many different attack vectors for Bluetooth but we're going to be focusing on two so the first is man in the middle or eavesdropping and the second is malicious device manipulation so in the first instance what you're trying to do is you're trying to intercept the communication between the master and the slave in the network in the second instance we're going to try and connect directly to the device and get it to carry out some functions for us some of those functions might be intended by design but many times that isn't the case so we're going to try and get it to do some things that we want it to do but that the developers never intended to do so
in order to carry out a man-in-the-middle attack what you need to do is to follow the connection process between the master and the slave you're trying to collect enough information to actually decrypt the connection in order to carry out this attack it really depends on the type of Bluetooth that the device is using so if the device is using Bluetooth classic using an enhanced data rate you'll need something like this frontline BPA 600
which for all of us in the room is not really an affordable option but if you're looking at a device that communicates using Bluetooth low-energy you can use the Texas Instruments EC 25 40 kits or a new beneath one and both of those cost less than one hundred and fifty dollars but this kind of attack vector is actually not the easiest to carry out and we're looking at payment
terminals so when you think about payment terminals most of the pertinent information is going to be encrypted
from the payment terminal - from the payment terminal to the payment server so for this reason sniffing or man-in-the-middle isn't really a viable attack method for us so just a quick note on enhanced data rates so when we were carrying out this research there isn't a lot of information online talking about how you can determine what a device is using to communicate so the first thing you can do is you can carry out a risk reconnaissance scan using something like HDI tool which is natively available in Linux and this is going to learn a list edie are as a feature for the device the second thing that you can do is you can capture some of the packets using a tool such as uber tooth and this is going to just display headers only so you're not going to see any data payloads in this so that in that way you can confirm that a device is using an enhanced data rates and you know that it's not really viable for you to try and attack it using a man-in-the-middle attack so this brings
us on to our first finding which is the sending of arbitrary commands so what happens if you connect directly to a device well you can get it to initiate a function such as a payments
you could get it to display some text or you might be able to turn it off on on but we also need to keep in mind that the pairing process might actually introduce some obstacles we might need to physically interact with the device and it's worth noting tip for developers that Bluetooth as a protocol doesn't actually feature any user authentication or any input sanitization so you have to it have to implement this at the application level so in order to carry-out attack where we connect directly to the device and we use this device to carry out some sort of malicious operation the first thing that we need to do is we're going to have to carry out some prerequisite work to understand what features and functions are available on the device and how we can use them so what you need to do this is you're going to need access to a mobile phone or a cell phone which has
the ability to enable developers options so within that you want to enable HDI logging you'll need access to the mobile application for the device and you'll need access to the physical device itself the next thing that you want to do is you want to carry out a sample of transactions for the terminal now the reason for doing this is it's the best way to just get a broad spectrum of how the device works so once we've done that we can take the HDI log from the phone and we can import it into something like Wireshark to analyze the output so here you can see the sending of the message inserts for swipe card to the display so we can use the information within the HCI log and the mobile application to work out how all of the features and functions work so in this next example you can see that I've inserted my card incorrectly into this device and so it says please remove card so we're looking at two packets of information that's because this terminal communicates using Bluetooth Low Energy so here we can see the UUID value so this is really important we'll need to know this value is in order to send information to the terminal so if we
look at this in greater detail you can see that the values actually made up of five parts the first is a leading part and this contains a command ID a counter and a intended payload size for the message then we have the message itself which is an ASCII so please remove card then we have a trailing parts and we have a checksum which is an X modem and then an end value so now that we know this information for the specific terminal we can basically calculate anything we want to send to the display of this terminal so we found that three
of the terminals we looked at so I settle some up and the Miura m0 10 reader which is of what's available via Square and also PayPal are vulnerable to this kind of attack method so this means that we can send a message such as police wipe now and get the cardholder to sort of downgrade the method that they're using to authorise a payment for or we can send a message which says payment declined or payment cancelled and get them to carry out an additional transaction so let's have a look at this in action so I'm just using a simple
script here and we're going to force the cardholder to carry out a transaction using the mugs magstripe instead of the chip so if we have a look at this next
example this terminal is using Bluetooth classic so the data looks a little bit different from the previous example so we can see the sending of insert or swipe card to the display similar to the
previous example it's made up of three part so in the leading part we again we have an ID a command ID value a counter and the intended payload size and then we have the message which is insert or swipe card and then we have the checksum which is just a simple XOR value so again now that we know this information we can calculate anything we want to Center the display it doesn't have to be insert card it can be any kind of message we want to send so what we're going to do in the next example is I'm going to show you how we can actually interrupt the payment process and we're going to display a message which says payment cancelled but you want to see in
fact that the payment has been authorized so we can see payment cancelled but in just a moment we're going to see on the phone that we receive an SMS which shows that is actually an authorized for that value there we go so this brings us on
to our next finding which is how we can modify the amount for certain types of
transactions I'm going to use the information that we've learned in the first process and apply this to the next process yeah now let's try to affect
payment comments so there are actually many ways to intercept payment comments reverse-engineer them understand their structure and of course tamper them so first of all all comments surprisingly our readers getting from the server side which means you can intercept them by HTTP main in the middle and for this purpose you need to bypass SSL pinyin somehow and obviously there are a lot of ways to do this next was already
mentioned is just to enable Excel log in and then get access via wire shock to the lock and to see comments next you also can rebuild an application enable login messages and then get an access to them via Android debug bridge this method is also very useful just to understand the structure of comments finding code examples of other comments and for other purposes and finally if you also don't have any other options you can also use some external device such an uber teas such as nibble juice to get access to traffic so here are two
examples from two different readers and for both readers we used two channels just to see the correlation and there are payment comments and in first case we made a payment for we initialized payment for 750 and bytes which are responsible for this value are sent in hex so 0 to EE and then second case we also so in first case we used Android debug bridge and also got access via a chat to and for second case we rebuilt application enabled Android debug bridge messages and also get access to traffic by HTTP main in the middle and in that case amount was sent in plaintext so 0 1 0 0 and as you can imagine in both cases just to send any amount on the reader you want you just need to change these bytes and then recall to Tex um so what
actually will happen if fraudulent merchant will change in amount between reader and the phone so he can force customer to make higher value amount by sending lower value on the reader but in fact sending a higher value to a server-side to the merchant to the service provider side so that's exactly
what we did so we send to the service provider 1 pound 23 pounds but we actually show only 1 pound to the customer he make a payment and then he sign in so we don't even need to forge signature which is pretty good
so this fraudulent payment will pass at least for magstripe why well simply because during the max type transactions reader will send only track 2 data when for example 4 MV transactions reader will send inside of a payment cryptogram amount currency and all additional information for example for contactless transactions there are also certain modes legacy modes which allow to send less information and it will be no amount inside the cryptogram and all these operations also can be affected and the last problem is that surprisingly for all service providers limits for transactions such as mac stripe are completely insane for like up to 50,000 dollars which means they rely only on the Nisshin or acquiring Bank in terms of stepping off suspicious transactions so let's imagine ourself we
can open account merchant account in
less than five minutes then we can force customer to use less secure for form of payment like Mack stripe instead of chip and pin then we are going to show him completely arbitrary amount like one dollar on the screen over reader and on the phone but actually will be it will be possible to carry out transaction for up to fifty thousand dollars a time and last problem is that these fraudulent transactions can be made for example 10 minutes after customer has already swiped card and has already left the building which is pretty good for fraudulent merchants what we will recommend to vendors obviously even if you as a service provider can't affect film where you can't affect the specification of communication between reader and the phone you still can mitigate these risks first of all you should control your mobile local system and should not allow to use rooted devices because rooted devices is a way to get access to traffic and make reverse engineer reverse engineering work and basically we did for customers recommendations are much easier just do not use mac stripe what we also found is
that sometimes it's much easier to compromise mobile point-of-sale terminal than traditional terminals so all we
need for this is just to get a good reverse engineer guy and obtain him an encrypted firmware so let's talk about obtaining firmware and how in where process works so normally film where start on the server side which means will be sent to the phone by HTTP and then to read or by Bluetooth which means you can basically get access to film where exactly the same way as to every other comments like HTTP main in the middle right so sometimes film were and configuration files are stored and sent to reader as a set of encrypted comments sometimes they are stored as links to encrypted firmware such here and in this case you can try to enumerate versions of firmware and sometimes you will be it will be possible to obtain some out-of-date favorite versions and then you can try to downgrade them on the reader but sometimes you don't even need to do this and you don't even need to open a merchant account use a mobile phone so all you need for this is just to use
Google and find some github repositories which will contain out of dated film where what unencrypted firmware will
contain yeah first of all it is a whole set of configuration files which will send what messages should be shown in the reader what type of operations can be used which means that you can for example disable chip-and-pin on the reader and finally it is a whole set of binary files on the reader side where you can find some remote code execution by a buffer or Stack Overflow and that's exactly what our average
engineer did in the end so he found out of date version downgrade the date on the reader and got a full axis on the reader so we got root access in the end which is pretty good because initially we didn't expect anything like that
why it is so important why it is a holy grail of gara fully compromised mobile point-of-sale terminal one of my favorite cases when in 2014 it was very unusual type of fraud in Brazil when hackers star which star who steal who stolen check to data from cars used this information to make some payments on a
compromised mobile point-of-sale terminal so basically probably they compromised it pretty much the same way as we did and what they did is they used track 2 data but sent information to a bank by saying that operations were chip-and-pin and the most curious part was that these cars didn't even have cheap on board that's how basically Bank understood the debt was a fraud next of course you can
just start to collect track to data before it will be encrypted so if you'll get access over binary file which is responsible for encryption you can get access to unencrypted track too as well as unencrypted pin codes because well mobile point-of-sale terminals work
pretty much the same way as traditional point-of-sale terminals or ATMs so keypad has two modes encrypted mode and
plaintext mode and if you will get access over a binary file which is responsible for switching between these two modes you can basically force a customer to enter pin code and encrypt it and finally just to understand how payment ecosystem works how payment research works this small piece of
device is very useful it's basically what we did and why we did it and last problem is that how to
keep persistence on an infected device because for example in our case after rebooting after each rebooting mobile point of cell checked the integrity of their own file system via digital
signatures we bypass this check but the last problem was that mobile application also has to check out of date firmware on the reader and should not allow to use out-of-date firmware on the readers but surprisingly in our case all you had to do is just to drop a packet to a server with request or response about version of firmware mobile application to quite couple seconds and came up to you by saying ah I don't care what from where version ISM I'm ready to work which means you can use this infected devices in merchants hands for a long
long time to collect track to data for example so let's imagine yeah you as a fraudulent customer get a physical access to reader for couple seconds during the payment switching on the pairing mode connect your own malicious device downgrade the firmware on the reader and then send an exploit to get a full access to reader then you bypass some dating process and keep persistence on the device and basically collect track to data on merchants hands
so this in this case how recommendations obviously it is very important to check that your customers don't use out-of-date firmware as well as this is completely unnecessary to allow customers to downgrade film where on their own devices we also found very interesting practice for one particular
vendor which were checking potential infected devices potentially infected entities and when one entity was connected with another entity such as for example reader with mobile phone
mobile phone B's account all these sets of entities appeared to be potentially infected and blocked in them so it's very unusual practice that you found on the market and just obviously as soon as we get a full access to mobile point-of-sale terminal well it's really hard to launch doom there you know we just decided to put more cats on the Internet
and last about the hardware observations yes surprisingly in these devices which cost less than fifty dollars the hardware security was pretty good for example very good protection normally very good protection against anti tampering such as anti tampering foil which protects against opening in
sometimes even pressure sensors and the last problem is that even if you'll get access to internals without alerting and tampering mechanisms all you will see is just a set of proprietary protocols sometimes no G tak which means that without developer certificates without developers Manos you hardly will get anything so this brings us on to our
secondary fat so a lot of the vendors that we looked at tend to take very different approaches so some of the vendors we looked at tended to focus on the onboarding checks during the enrollment process where the whereas others focused on the transaction monitoring so as Tim mentioned one of the wonders we looked at carried out quite complicated correlation between different devices different accounts so we had quite a lot of difficulty during this assessment process trying to keep access
maintaining access to an account but this is a really sophisticated and effective way of identifying a fraudulent merchant as I mentioned at the start there are significant differences depending on the geographical location so generally speaking we noted that readers and accounts in Europe were far more restrictive than those in the US so for example square who operates in both locations they permit MSD transactions and offline processing in the US but this isn't possible in Europe and finally with regards to the mobile ecosystem we were pretty disappointed to notice that almost all of the vendors didn't protect the mobile ecosystem at all and the approach of course is that
it's the very thing that allows us to
gain access to much of the knowledge we needed in order to understand how these readers work so this table represents a broad overview of all the different readers vendors manufacturers and areas of assessment that we carried out obviously this marketplace places emphasis on user enrollment and onboarding so they want it to be easy for customers they want it to be simple but it doesn't take into account the fact that security should in fact be incredibly high in all areas to counteract the incredibly low barriers for entry so as I mentioned at the start if you want to see the Unversed uncensored version of our presentation go ahead and access that on the media server today you're welcome to do that because we spoke to all of the vendors that were affected by this process and most of them were very cooperative with us so during this process we noticed that these devices actually provide a really unique opportunity especially for security researchers so traditionally in order to carry out payment testing or payment research we have to engage with a customer or we have to work in a financial institution the interesting thing about these products is that anyone can enroll with annika within accounts within five minutes so you don't have to be a business for example in Europe you can be a sole trader which is very simple to do and you can just open an account so you can use these devices to actually carry out payment research you can just use them to carry out confirmation of someone else's research you can use them to understand how a payment works so for this reason we wanted to talk about this
because we think that everyone in this room can benefit from understanding how they can use mobile point-of-sale terminals so what does this actually mean for businesses and assessing risk it means that if you take card payments you shouldn't take swipe transactions we've mentioned that there is a vulnerability associated with some of these readers that we looked at but more specifically magstripe is actually a deprecated protocol so as I mentioned the magstripe can be cloned a signature can be forged and of course there's no signing of a transaction so every time a merchant accepts a card that's wiped they're actually accepting liability for the full value of that transaction more broadly I think all of
us in this room know that embedded systems have become incredibly popular over the last few years especially with consumers but also we're seeing they're being incorporated much more into business infrastructure but that means that all of us need to understand that there's not going to be a high level of security testing in products like this typically the vendors have only been around for a few years and many of these products cost less than 100 so it's just something that we all need to keep in mind so at the beginning of this project we started with just two card readers and two vendors and this quickly grew into a really ambitious Jex encompassing seven card readers and two geographic locations so we found that over 50% of the readers that we looked at were affected by our vulnerabilities and our findings and all of the vendors that we looked at were affected by our findings we found that you can send arbitrary commands to the mirror m0 ten reader the Eyes Ethel reader the sum up reader and for this reason it allows us to socially engineer the cardholder so we can get them to carry out asswipes payments or we can send a message which says payment counts order payment declined and force them to carry out additional payments we also
found that for three of the readers so the same readers is also possible to modify the amount for magnetics truck transactions so this means that we can display a much lower value on the card terminal itself and force the card holder to carry out a much higher value transaction we found that on the M mirror m0 ten reader we can gain a wicked gain access to the full file system using the remote code execution vulnerability so this means that we can do almost anything we can enable command mode on there on the pin pad so we can start to collect pins in plaintext surprisingly the security mechanisms in most of these products is quite sophisticated but overall security wasn't good it tends to be considered in isolation so it's high in the level of the physical security mechanisms but more broadly speaking in the entire ecosystem is relatively weak so this brings us onto our conclusions for manufacturers we recommend that security is implemented during the development process we could see really strong evidence of this in the physical security mechanisms but we can't see it in other areas of the ecosystem you should use a bluetooth pairing mode that visually allows the confirmation that the correct device and the correct terminal has been paired and of course you should control thermal worship versions so encrypting control firmware so you can prevent it from interception via sniffing and obviously modification for vendors we recommend that you do not allow the use of magstripe or you need to implement a solution which allows for the signing of the transaction or the checking of the transaction on the server side use preventative monitoring is backed best practice so this means looking for transaction anomalies but it also means using things like correlation because this is a really effective way of identifying fortunate merchants we also recommend that vendors implement really strong enrollment checks because this is the first point of entry into the ecosystem for merchants we recommend that you control physical access to the devices this is because many of the attacks that we've mentioned in some way or other involve some level of physical proximity to carry out the attack we recommend that merchants also if at all possible assess the ecosystem this isn't obviously viable for a small business like a cafe that just has one reader but there are larger business which businesses which have many more units for card holders we recommend that you don't actually carry out swipe
transactions but instead use chip and signature or chip and pin where possible and of course it's always good practice to just check your transactions on a monthly basis and report anything that you think is anomalous to your issuing bank so this concludes our presentation
and I just want to thank you all for listening to our findings at this early moment in the morning we also want to
thank a few of our colleagues and friends who assisted us with this project so we want to thank Artem because he carried out a huge amount of work to identify the remote code execution vulnerability and thanks to
Alexey and mark who helped us look at the physical devices to assess their physical security mechanisms so thank you very much [Applause]