3 ms·

This reminds me of when I was an intern at an InfoSec company 6 years ago. At the time, they were doing some research into mPOS devices (though I wasn't involve

This reminds me of when I was an intern at an InfoSec company 6 years ago. At the time, they were doing some research into mPOS devices (though I wasn't involved). They found and exploited a stack-based buffer overflow in the EMV parsing of a particular device, which allowed them to deliver a payload from the smart-card itself. To demo this attack, they wrote a flappy bird clone which was played using the number pad of the mPOS device. It weighed in at ~4k though, so positively heavyweight compared to this! There's more info here: https://labs.f-secure.com/assets/BlogFiles/MWRI-Labs-BHUS14-Mission-mpossible-2014-08-04-2.pdf https://labs.f-secure.com/assets/BlogFiles/MWRI-Labs-BHUS14-..., with a video demo here: https://vimeo.com/89924160 https://vimeo.com/89924160

antihero 6y ago
That was a good read! Would I be right in saying that given that the PoS is internet connected, you could create a payload that showed a fake pin screen in insecure mode, and just upload the card details and PIN every time someone used it? And deploy that payload simply by inserting the compromised card.
- JosephRedfern 6y ago
  I'm not entirely sure that this would be the case for mPOS devices, as they aren't necessarily directly connected to the internet (many talk to a tablet or mobile phone via bluetooth), so you might need further vulnerabilities in the accompanying app to be able to exfiltrate that way. MWR have done other work on standard EMV devices which probably ARE connected "directly" to the internet, so the situation you describe may be more likely. I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully. Sort of like an AMEX Black card, but without the repayments. Again, I wasn't involved with any of this, so take my comments with a pinch of salt.
  - lxgr 6y ago
    > I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully. Fortunately it's not that easy. Almost all chip card transactions are online only these days, i.e. the issuing bank's host system has the final say on whether a payment goes through or not.
    - JosephRedfern 6y ago
      I realise that, but perhaps wasn't clear in what I was trying to say. In the UK many businesses manually enter in the amount into the POS device. The customer will then insert their card and enter their pin, the transaction will take place (as you say, ultimately down to the issuing bank), and the device will indicate whether the transaction was successfully or not (printing a receipt as well as an indication on the screen). Some places have tighter integration with tills etc, but to my knowledge it's down to the POS device (which is assumed secure) to communicate the status of the transaction to the till. My suggestion is that given full control over the POS device (i.e. your card triggers buffer overflow in the POS and you get code execution), you could make it behave as if the transaction had been successfully processed (by showing the same message and issuing the same receipt) without actually debiting any accounts or making any actual transaction.
      - jaywalk 6y ago
        It really depends on the type of integration used between the terminal and the POS. Sometimes the terminal handles everything and just communicates the status to the POS, in which case your attack would be viable. But it's also possible for the terminal to just package up the info and pass it off to the POS to handle the communication. Source: I've built a custom integration with Verifone terminals.
ardy42 6y ago
> They found and exploited a stack-based buffer overflow in the EMV parsing of a particular device, which allowed them to deliver a payload from the smart-card itself. To demo this attack, they wrote a flappy bird clone which was played using the number pad of the mPOS device. It weighed in at ~4k though, so positively heavyweight compared to this! I wouldn't knock that achievement: this implementation is 228 byte of Javascript and I'm guessing that was 4k bytes of binary that only had access to a less-featureful standard library. You really should add the size of the JS runtime this implementation needs to make the comparison fair. Otherwise, I could blow you all out of the water with my 11 byte implementation: runFlappy() (...which runs in FlappyLang, which includes a Flappy Bird implementation in the standard library.)
- JosephRedfern 6y ago
  You're totally right, and I didn't mean to knock it -- they are very different beasts, and the mPOS flappy bird is insanely impressive (it's hardly open hardware!). I see your 11 byte implementation, and raise you my 6! flpy()

antihero 6y ago

That was a good read! Would I be right in saying that given that the PoS is internet connected, you could create a payload that showed a fake pin screen in insecure mode, and just upload the card details and PIN every time someone used it? And deploy that payload simply by inserting the compromised card.

JosephRedfern 6y ago
I'm not entirely sure that this would be the case for mPOS devices, as they aren't necessarily directly connected to the internet (many talk to a tablet or mobile phone via bluetooth), so you might need further vulnerabilities in the accompanying app to be able to exfiltrate that way. MWR have done other work on standard EMV devices which probably ARE connected "directly" to the internet, so the situation you describe may be more likely. I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully. Sort of like an AMEX Black card, but without the repayments. Again, I wasn't involved with any of this, so take my comments with a pinch of salt.
- lxgr 6y ago
  > I've always liked the idea of having a card that cause the device to behave as if the transaction had gone through successfully. Fortunately it's not that easy. Almost all chip card transactions are online only these days, i.e. the issuing bank's host system has the final say on whether a payment goes through or not.
  - JosephRedfern 6y ago
    I realise that, but perhaps wasn't clear in what I was trying to say. In the UK many businesses manually enter in the amount into the POS device. The customer will then insert their card and enter their pin, the transaction will take place (as you say, ultimately down to the issuing bank), and the device will indicate whether the transaction was successfully or not (printing a receipt as well as an indication on the screen). Some places have tighter integration with tills etc, but to my knowledge it's down to the POS device (which is assumed secure) to communicate the status of the transaction to the till. My suggestion is that given full control over the POS device (i.e. your card triggers buffer overflow in the POS and you get code execution), you could make it behave as if the transaction had been successfully processed (by showing the same message and issuing the same receipt) without actually debiting any accounts or making any actual transaction.
    - jaywalk 6y ago
      It really depends on the type of integration used between the terminal and the POS. Sometimes the terminal handles everything and just communicates the status to the POS, in which case your attack would be viable. But it's also possible for the terminal to just package up the info and pass it off to the POS to handle the communication. Source: I've built a custom integration with Verifone terminals.

ardy42 6y ago

> They found and exploited a stack-based buffer overflow in the EMV parsing of a particular device, which allowed them to deliver a payload from the smart-card itself. To demo this attack, they wrote a flappy bird clone which was played using the number pad of the mPOS device. It weighed in at ~4k though, so positively heavyweight compared to this! I wouldn't knock that achievement: this implementation is 228 byte of Javascript and I'm guessing that was 4k bytes of binary that only had access to a less-featureful standard library. You really should add the size of the JS runtime this implementation needs to make the comparison fair. Otherwise, I could blow you all out of the water with my 11 byte implementation: runFlappy() (...which runs in FlappyLang, which includes a Flappy Bird implementation in the standard library.)

JosephRedfern 6y ago
You're totally right, and I didn't mean to knock it -- they are very different beasts, and the mPOS flappy bird is insanely impressive (it's hardly open hardware!). I see your 11 byte implementation, and raise you my 6! flpy()