 Ac mae'n gwybod am gwirio i mi wneud hwnth gweithio a'i wneud f rakwch ei ddechrau sefyddech chi'n dweud yn y tarloedd i ffurbidio'r seden. Rydyn yn ysgriff eich hollu'r un i gyd. O'r inchon wrth i fan ddechrau arweithio yr hyn y gwbl yna, ac mae'n gweithio'n ddweud a'i â chyflwyd i'r rydyn ni, rydyn ar fawr. Ac rydyn ni'n gweithio'r hyn o'n gweithio i chi'r hyn o'r gweithio'r hawn. 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 sales terminals. Mobile point of sales 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 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 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 end point of payment infrastructure. So for these reasons they're very attractive to 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 Blackhats in which they discussed findings around the mirror shuttle reader. So at this time this was being white labelled 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 overlap with traditional point of sales terminals. Then in 2015 three undergraduate students from the Boston University presented their findings on the Square Magstripe Reader at Blackhats. 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 the 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 regions. We chose to assess the most popular devices both in Europe and in the US. We've chosen to focus on PayPal, Square, Isettle and SumUp. 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 enrolment 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 sales 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 interact directly with the terminal or you'll 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 your issuing bank is so they'll ask the car brand such as Visa and Mastercard to determine this information. Once it's been passed to your issuing bank they'll check that you have the necessary funds to complete the process and then they'll carry out some fraud 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 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 they 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 sales terminal is around taking card payments. But it's just worth 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 depending on the issuer, the card brand and also the geographic location. But generally speaking we can understand that certain types of 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 that the card holder 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 MagStripe. You can also forge a signature relatively easily as well. And there's no signing of the transactions 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 US 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 that's even worse so less than a quarter of all transactions are made using a chip. And if we look at the overall growth of mobile point of sales terminals you can see that only within a couple of years almost 50% of all transactions will be made by a mobile point of sales 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 sales terminal provider via a network connection or over wifi. 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 vector 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 SWITE. Then we'll talk about how for some of the terminals we looked at we were able to modify the amount so the cardholder thinks that they're actually authorising a much lower value. We're also going to talk about how we obtained remote code execution in 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 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 of this but I'm going to assume that not everyone in the room does so let's continue. So Bluetooth can be roughly divided into two parts the host and controller layers. So the Bluetooth profiles and GAT and AT they deal with the actual transfer of information. L2CAP 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 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 protocols 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 RFCOM. 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 it's quite different. So with this you have a much smaller packet size and it produces a hierarchical structure under which certain 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 address is. So its address consists of three main parts. We have the upper address part sorry the non-significant address part 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 part and upper address part 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 front line 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 CC 2540 kit or an Ubertooth 1 and both of those cost less than $150. 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 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 reconnaissance scan using something like HTI tool which is natively available in Linux and this is going to list EDR 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 Ubertooth and this is going to display headers only so you're not going to see any data payloads in this. So in that way you can confirm that a device is using 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 payment, you could get it to display some text or you might be able to turn it off or 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 for developers that Bluetooth as a protocol doesn't actually feature any user authentication or any input sanitisation so you 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 HCI 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 HCI log from the phone and we can import it into something like Wireshark to analyse the output. So here you can see the sending of the message Inserts or 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 what 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 value is actually made up of five parts. The first is a leading part and this contains a command ID, a counter and an intended payload size for the message. Then we have the message itself, so please remove card. Then we have a trailing part and we have a checksum which is an X modem and then an end value. So now that we know this information for this 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 IZETL, SUMUP and the Mura M010 reader which was 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 please swipe now and get the card holder to sort of downgrade the method that they're using to authorise a payment for. Or we can send a message where it 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 card holder to carry out a transaction using the 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 parts 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 x or value. So again now that we know this information we can calculate anything we want to send to 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 a message which says payment cancelled but you're going to see in fact that the payment has been authorised. 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 it's actually been authorised 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. We're going to use the information that we've learnt in the first process and apply this to the next process. So let's try to affect payment comments. So there are actually many ways to intercept payment comments reverse engineer them understand the structure and of course tamper them. So first of all all comments surprisingly are readers getting from the server side which means you can intercept them via HTTPS main and middle which purpose you need to bypass SSL pin-in somehow and obviously there are a lot of ways to do this. Next was already mentioned is just to enable HCI login and then get access via Wireshark to the log 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 as number 2s 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 buys which are responsible for this value are sent in hex so 0 to EE and in second case we also so in first case we used Android Debug Bridge and also get access via HCI tool. And for second case we enabled Android Debug Bridge messages and also get access to traffic via HTTPS main in the middle and in that case amount was sent in plain text so 0100 and as you can imagine in both cases just to send any amount on a reader you want you just need to change those bytes and then recalcul check sum. So what actually will happen if fraudulent merchant will change amount between reader and the phone so he can force customer to make higher value amount by sending lower value on a 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 sent to the service provider 1 pound 23 pence but we actually show only 1 pound to the customer he make a payment and then he's signing so we don't even need to forge signature which is pretty good so this fraudulent payment will pass at least for max stripe why? Well simply because during the max stripe transactions reader will send only track to data when for example for envy 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 of a 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 max stripe are completely insane for like up to $50,000 which means they rely only on an issue or acquiring bank in terms of stopping off suspicious transactions so let's imagine ourselves we can open account merchant account in less than 5 minutes then we can force customer to use less secure form of payment like max stripe instead of chip and pin then we are going to show him completely arbitrary amount like $1 on a screen, over reader and on a phone but actually it will be possible to carry out transaction for up to $50,000 a time and the last problem is that this fraudulent transactions can be made for example 10 minutes after customer has already swiped card and has already left the building it is pretty good for fraudulent merchant what we will recommend to vendors obviously even if you as a service provider can't affect firmware 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 ecosystem and should not allow to use router devices because router devices is a way to get access to traffic make reverse engineer reverse engineer in work and basically we did for customers recommendations are much easier just do not use max stripe what we also found is that sometimes it's much easier to compromise mobile point of sale terminal than traditional terminals so all you need for this is just to get a good reverse engineer guy and obtain him unencrypted firmware so let's talk about obtaining firmware and how firmware process works so normally firmware is stored on the server side which means will be sent to the phone via HTTPS and then to reader via bluetooth which means you can basically get access to firmware exactly the same way as to every other comments like HTTPS main in the middle so sometimes firmware 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 it will be possible to obtain some out of date 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 firmware 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 on the reader and some other 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, downgraded it on the reader and got a full access 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 getting a 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 which stole track 2 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 those cars didn't even have chip on board that's how basically bank understood that that was a fraud next of course you can just start to collect track 2 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 2 as well as unencrypted pin codes because mobile point of sale terminals work pretty much the same way as traditional point of sale terminals or ATMs so k-pad has 2 modes encrypted mode and plain text mode and if you'll get access over a binary file which is responsible for switching between those 2 modes you can basically force a customer to enter pin code unencrypted and finally just to understand how payment ecosystem works, how payment research works this small piece of device is very useful that's basically what we did and why we did it and the 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 sale checked the integrity of their own file system via digital signatures we bypassed this check but the last problem was that mobile application also has to check out of date firmware on a reader and should not be allowed to use out of date firmware on a reader 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 took like couple seconds and came up to you by saying ah I don't care what firmware version is I'm ready to work which means you can use disinfected devices in merchant's hands for a long long time to collect two data for example so let's imagine, yeah you as a fraudulent customer get a physical access to reader for couple seconds during a payment switching on the pairing mode connect your own malicious device downgrade the firmware on a reader and then send an exploit to get a full access to a reader then you bypass updating process and keep persistence on a device and just basically collect track to data on merchant's hands so this in this case our 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 firmware on their own devices we also found very interesting practice for one particular vendor which were checking potentially infected devices potentially infected entities and when one entity was connected with another entity such as for example reader with mobile phone mobile phone with account all these sets of entities appeared to be potentially infected and blocked in the end so it's very unusual practice that we found on the market and just obviously as soon as we get a full access to mobile phone of cell 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 $50 the hardware security was pretty good for example very good protection normally very good protection against antitampering such as antitampering foil which protects against opening really sometimes even pressure sensors and the last problem is that even if you'll get access to internals without alerting antitampering mechanisms all you'll see is just a set of proprietary protocols sometimes no GTAC which means that without developer certificates without developers manuals you hardly will get anything so this brings us on to our secondary factors 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 enrolment process whereas others focused on the transaction monitoring so as Tim mentioned one of the vendors we looked at carried out quite complicated correlation between different devices different accounts 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 geographic 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 regard 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 biggest approach of course is that it's the very thing that allows us to gain access to much of the knowledge that 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 enrolment 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 uncensored version of our presentation go ahead and access that on the media server today you're welcome to do that 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 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 enrol with an account within five minutes so you don't have to be a business for example in Europe you can be a soul 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 sales terminals so what does this actually mean for businesses in a setting 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 a magstripe can be cloned a signature can be forged and of course there's no signing of the transaction so every time a merchant accepts a card that's swiped 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 project 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 Mura M010 reader the Izettle reader the SumUp reader and for this reason it allows us to socially engineer the card holder so we can get them to carry out a swiped payment or we can send a message which says payment cancelled or payment declined and force them to carry out additional payments we also found that for three of the readers, so the same readers it's also possible to modify the amount for magnetic stripe 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 Mura M010 reader we could 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 the pin pad so we can start to collect pins in plain text 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 the entire ecosystem is relatively weak so this brings us on to 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 firmware versions so encrypt and control firmware so you can prevent it from interception by 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 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 incentivising fraudulent merchants we also recommend that vendors implement really strong enrolment 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 have mentioned in some way or other involves 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 café that just has one reader but there are larger businesses which have many more units for cardholders 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 Alexi and Mark who helped us look at the physical devices to assess their physical security mechanisms so thank you very much