10 ms·

As pointed out here, the huge assumption in this article is is: > If someone installs malware on here - just insert a usb stick or use the recovery mode - then

As pointed out here, the huge assumption in this article is is: > If someone installs malware on here - just insert a usb stick or use the recovery mode - then tada we have the next generation of atm skimming. Which is just not how these payment devices work- they are entirely separate, they are sent a request to make a transaction, that transaction (and also likely the transaction request itself) occur entirely in a secure connection between someone like Verifone, and the device itself. The PC has has no way to get those card details, only request a transaction and confirm a payment status as successful or failed.

walterlb 4y ago
> Today at another McDonald's I observed the entire bootstrap process and can confirm that the kiosk indeed is responsible for installing “custom firmware” on the card reader If this part is correct, it seems like an attacker could compromise the reader itself.
- charles_kaw 4y ago
  Considering the article writer already expresses some clear misunderstandings, I don't think it's correct. Maybe they witnessed it, but that would be a bigger deal than some shitty windows box being popped. Certainly, that would not pass compliance.
- MBCook 4y ago
  I work with POS hardware at my job. The “custom firmware” is likely just some settings, screens for the POS to display (so they’re McD branded instead of the POS maker), and some per payment-processor configuration so the terminals are using the expected encryption (differs per processor and customer). Even if it was real firmware (I doubt it), it’s likely the firmware for the POS device interface. I don’t believe that firmware has any control over the actual payment processing bits of hardware, just the software intermediary. Since that intermediary only has access to EMV tags (which anyone in the payment path has) there is no point. The secret encryption stuff that secures passwords is not controlled from any layer an attacker could touch, outside of documented configuration parameters.
  - judge2020 4y ago
    Even if it does handle delivering firmware updates to the device, I would be wholly surprised if the terminal doesn't at least do basic checks to make sure the firmware is signed (although, whether or not there are exploits to get around this is another thing).
    - MBCook 4y ago
      The devices I’ve seen all have signed firmware.
      - avianlyric 4y ago
        Yeah the firmware should be signed and have an EMV certification. It’s a total pain in the arse to develop and deploy new software for these devices.
- AnotherGoodName 4y ago
  Signed firmware though. Those card readers also typically have photodiodes in them and numerous tamper switches pressed to the case to wipe their internal memory if tampered. Just to be clear I'm not talking about EPROM - they have actual photodiodes inside along with physical switches and a coin battery that will wipe the ROM if tampered. It's common to have the tamper switches trigger if you drop the terminal. They'll need to be re-flashed from scratch when that happens. eg. https://stackoverflow.com/questions/33872627/how-to-fix-tamper-error-in-verifone-vx520 https://stackoverflow.com/questions/33872627/how-to-fix-tamp... Anyway the TLDR is that the Card Reader part of any POS system is reasonably secure.
  - galangalalgol 4y ago
    Fascinating! Is there more detail somewhere on this stuff? Its like a bomb squad drama, making a dam for liquid nitrogen to cool the coin cell below the voltage it can detonate the.. I mean clear the rom, opening the case in a dark tent around the device etc.
atwood22 4y ago
Also chip cards don’t ever leak the CC number as part of the transaction. However, it seems like you could request a transaction for a different merchant?
- charles_kaw 4y ago
  In a correctly configured system, the terminal itself would have to be reconfigured. That can sort of be be done via the POS, but also requires credentials from the group that configured the terminal. The terminals really don't trust the POS systems.
  - AmericanChopper 4y ago
    I used to work with those payment gateways, and I always wondered about that attack vector. The terminal config (where you’d put your merchant ID, etc…) is protected by a PIN code, but suppliers typically just use the same PIN for their entire fleet. It’s not really a secret PIN either, because the terminal tech support will usually end up getting merchants to type it in if there‘s some remote support/debugging needed. You could reprogram a terminal in a bar in a few seconds on a Friday night. Wait for the weekends takings to clear into your merchant account, and then take off with the money. The way that it falls down though, is that you need a merchant account, and there’s a lot of KYC and due diligence to get through if you want to set one of those up (there are a lot of merchant initiated scams, and your bank doesn’t want to be on the hook for them).
    - PeterisP 4y ago
      > Wait for the weekends takings to clear into your merchant account, and then take off with the money. That's the difficult part - since the acquiring bank is fully financially responsible if you do so (they'll compensate everyone else involved for the fraud chargebacks, no matter if they can recover it from you), they generally take quite stringent steps to fight merchant-initiated scams, and the simplest step is simply freezing the money for some time; 30 days is not uncommon but I have even seen 90 days if the merchant's profile is risky or if the incoming payment volume suddenly increases significantly - the bank is effectively treating any payments to the merchant as a line of credit or letter of guarantee until it's clear that those payments won't be fraudulent or charged back. So a merchant can quite realistically do some shenanigans with a reprogrammed terminal, but they won't be permitted to take off with a large amount of money from the merchant account until a sufficient amount of time will have passed for the first chargebacks or complaints of fraud to show up.
charles_kaw 4y ago
btw if anyone has ever taken a look at a POS setup, it's a bit misleading to the uninformed In some solutions, the readers are in fact hooked up directly to the POS system. However, the card terminal does not see unencrypted payment data. The POS is acting as a network bridge or switch, while getting limited information over network from the terminal. In fact, I'm not sure that's even something that's allowed in large scale installations today.
- MBCook 4y ago
  You only get unencrypted stuff when doing mag-stripe, and that’s mostly just card number and name. Same with tap-to-pay may-stripe emulation (the old way which no one is supposed to use anymore, even in the US per credit card rules). That’s why everyone has/is moving off mag-stripe (depending on country) and to EMV. With EMV and EMV contactless the terminal never gets the full card number, among many other significant security improvements.
  - charles_kaw 4y ago
    >You only get unencrypted stuff when doing mag-stripe The terminal encrypts it before sending it over the wire
- closewith 4y ago
  Do you have a source for this? The EMV spec doesn’t include encryption of any data sent to the terminal from the card. The transaction cryptogram is signed, however.
  - charles_kaw 4y ago
    The terminals themselves use mtls to communicate and wrap the payload , wasn't referring to the payload itself.
    - closewith 4y ago
      That seems like a walkback? You said: > However, the card terminal does not see unencrypted payment data. The card terminal does see unencrypted payment data. Hard to see your comment as ambiguous?
Cyberdog 4y ago
So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm…
- irjustin 4y ago
  This is like a 2005 hack. I'm sure you could come up with at least one good solution to this problem.
- tmpz22 4y ago
  If we say average transaction size is $10 and that you’ll save 1.000 customers (generous) before you’re caught. You just committed a felony to provide $10.000 in free food. Might as well get a day job and make that contribution annually and skip federal prison.
- lelanthran 4y ago
  > So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm… Almost certainly not on EMV certified card acquirers, unless there is a bug in the firmware. These things are so locked down that, even as an authorised developer for the payment terminal, we had no access to the hardware, no way to view the cards encrypted payload, etc.
  - deleted 4y ago
    [deleted]
  - lupire 4y ago
    Parent meant to ignore the EMV and have the kiosk just claim that all orders are paid, so the user gets food.
- avianlyric 4y ago
  Or you could tweak the ordering software to completely ignore the terminal, and not bother charging at all.
btown 4y ago
But if an attacker owns the touchscreen, they can do nefarious things like adding a "Please re-enter your PIN on the touchscreen to confirm your purchase" dialog, then match that PIN against a separate leaked database of card numbers and user identities. It's not just whether the card reader can be pivoted to; it's the entire notion that the kiosk itself carries the trust of the overall brand.
- Gigachad 4y ago
  It would be a huge amount of work to pull this off and it's something that would be detected within the day because its so odd and not at all how normal payment flows work. Not clear how you would match the pin either without having some personal info on the user which you don't have.
  - alonsonic 4y ago
    Exactly. The kiosk app that communicates to the terminal only gets a "transaction approved" response. There is no personal identifiable information provided to the kiosk app so there would be no way to link the pin they typed in the kiosk back to the customer identity or card number. In short, for the kiosk this is a anonymous transaction that was confirmed paid. The most you could do is ask for more details in the kiosk app which would be clunky and very suspicious.
- BoorishBears 4y ago
  You could also tape a piece of paper up with a fake (tech support/tax help/credit help/reverse mortgage) line with a fake McDonald's endorsement in the early hours of the morning and make off with plenty of victims as the senior crowd rolls in for a grand time investment of 60 seconds. If you want to get creative with attacks you can, but sometimes comparing a creative attack to a "boring" attack can help frame the conversation. I've written kiosk apps that landed across the US and while there was a ton of hand wringing about security, and in an informal setting I brought up a simple question: If you reverse engineer the update process to have it show a penis, or you just carve a penis into the public display with a pocket knife, what's the difference and which is more likely to happen?
wowokay 4y ago
I know from experience that similar setups tend to have the workstation load the verifone updates, so a package could be inserted, it would take some more insider knowledge.
- Too 4y ago
  Do these payment terminals have secure boot or other forms of update payload verification? In that case the risk of accepting malicious updates from insecure touch screen would be much less.
t_mann 4y ago
But the transaction info has to be transmitted by the touch terminal - unless the recipient is set to a fixed value in the card machine, that should at least make it possible to re-route all of McDonald's revenue to some arbitrary recipient.
- jon-wood 4y ago
  The recipient is set to a fixed value in the card machine.
vishnugupta 4y ago
+1. To add, the modern EMV chip enabled transactions are not at all like magnetic stripe transactions. The chip in the card is not a passive storage but is also a computation device that signs a transaction, generates one time keys etc., Of course it is still possible to skim the card number off of magnetic strip and sell it in the darknet. However, the static card number is becoming less and less of a relevant thing now a days as more sites/processors are migrating to dynamic auth such as Apple Pay etc., A good overview + detail : https://www.youtube.com/watch?v=Zv1DjtBwADg https://www.youtube.com/watch?v=Zv1DjtBwADg
- tjoff 4y ago
  NFC cards dominate here though, which effectively negates the many benefits of chip cards.
  - notatoad 4y ago
    NFC transactions are powered by the EMV chip, and include all the same signing ond one-time-key exchange as a chip-insertion but without the potential for skimming the mag strip
    - tjoff 4y ago
      Encrypted in the same sense that https is encrypted. Doesn't do jack if you have control over the "server". And in this case the server can have a large antenna and not require physical contact. So in essence, orders of magnitude worse than the magnetic strip.
      - aerostable_slug 4y ago
        This is fundamentally incorrect. Sniffing the NFC traffic gives the attacker nothing useful, just as skimming an EMV contact transaction gives the attacker nothing useful. >The contactless EMV chip transaction path leverages the cryptographic functions normally associated with a contact EMV chip transaction and uses the same authorization and settlement fields as a contact chip transaction. [0] [1] [0]: https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC-WP-Final-Nov-2015.pdf https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC... [1]: See EMV specifications, “Book 2 – Security and Key Management,” Version 4.3, November, 2011, http://www.emvco.com/specifications.aspx?id=223 http://www.emvco.com/specifications.aspx?id=223.
avianlyric 4y ago
You might not be able skim card details, but you could probably get the terminal to issue unexpected transactions. The most interesting transaction would be a very large refund. I’ve seen organised crime groups target restaurants in the past to issue themselves £1k+ refunds. They pretend to pay for meal, and while they have the EMV terminal in their hand, they cancel the original transaction, put the device into management mode (using default passwords) and issue themselves a nice large refund. It’s a complete pain in the arse for the banks receiving these refunds to catch and deal with properly. It’s surprisingly hard to return the money to the restaurant.
- honkdaddy 4y ago
  That’s pretty funny. Not that the restaurants deserve to be stolen from, but using the default password on an EMV is about as foolish as a restaurant leaving their registers open. I’m surprised the terminals don’t force you to at least set your own passcode.
lifeisstillgood 4y ago
In the article he points out the PC is responsible for updating firmware in the card reader. So while it's a more sophisticated hack, change the firmware to record the pin and send it back to the PC etc etc.
- Goz3rr 4y ago
  I'm assuming the firmware is cryptographically signed, because they have to upgrade from untrusted devices. That negates this entire attack vector.
  - lifeisstillgood 4y ago
    I think our best reaction to that is ... hmmmm. But yes I think this is more a "hey there is so much insecure tech out there - here is another example" as opposed to "we are all dead and our bank accounts emptied"

walterlb 4y ago

> Today at another McDonald's I observed the entire bootstrap process and can confirm that the kiosk indeed is responsible for installing “custom firmware” on the card reader If this part is correct, it seems like an attacker could compromise the reader itself.

charles_kaw 4y ago
Considering the article writer already expresses some clear misunderstandings, I don't think it's correct. Maybe they witnessed it, but that would be a bigger deal than some shitty windows box being popped. Certainly, that would not pass compliance.
MBCook 4y ago
I work with POS hardware at my job. The “custom firmware” is likely just some settings, screens for the POS to display (so they’re McD branded instead of the POS maker), and some per payment-processor configuration so the terminals are using the expected encryption (differs per processor and customer). Even if it was real firmware (I doubt it), it’s likely the firmware for the POS device interface. I don’t believe that firmware has any control over the actual payment processing bits of hardware, just the software intermediary. Since that intermediary only has access to EMV tags (which anyone in the payment path has) there is no point. The secret encryption stuff that secures passwords is not controlled from any layer an attacker could touch, outside of documented configuration parameters.
- judge2020 4y ago
  Even if it does handle delivering firmware updates to the device, I would be wholly surprised if the terminal doesn't at least do basic checks to make sure the firmware is signed (although, whether or not there are exploits to get around this is another thing).
  - MBCook 4y ago
    The devices I’ve seen all have signed firmware.
    - avianlyric 4y ago
      Yeah the firmware should be signed and have an EMV certification. It’s a total pain in the arse to develop and deploy new software for these devices.
AnotherGoodName 4y ago
Signed firmware though. Those card readers also typically have photodiodes in them and numerous tamper switches pressed to the case to wipe their internal memory if tampered. Just to be clear I'm not talking about EPROM - they have actual photodiodes inside along with physical switches and a coin battery that will wipe the ROM if tampered. It's common to have the tamper switches trigger if you drop the terminal. They'll need to be re-flashed from scratch when that happens. eg. https://stackoverflow.com/questions/33872627/how-to-fix-tamper-error-in-verifone-vx520 https://stackoverflow.com/questions/33872627/how-to-fix-tamp... Anyway the TLDR is that the Card Reader part of any POS system is reasonably secure.
- galangalalgol 4y ago
  Fascinating! Is there more detail somewhere on this stuff? Its like a bomb squad drama, making a dam for liquid nitrogen to cool the coin cell below the voltage it can detonate the.. I mean clear the rom, opening the case in a dark tent around the device etc.

atwood22 4y ago

Also chip cards don’t ever leak the CC number as part of the transaction. However, it seems like you could request a transaction for a different merchant?

charles_kaw 4y ago
In a correctly configured system, the terminal itself would have to be reconfigured. That can sort of be be done via the POS, but also requires credentials from the group that configured the terminal. The terminals really don't trust the POS systems.
- AmericanChopper 4y ago
  I used to work with those payment gateways, and I always wondered about that attack vector. The terminal config (where you’d put your merchant ID, etc…) is protected by a PIN code, but suppliers typically just use the same PIN for their entire fleet. It’s not really a secret PIN either, because the terminal tech support will usually end up getting merchants to type it in if there‘s some remote support/debugging needed. You could reprogram a terminal in a bar in a few seconds on a Friday night. Wait for the weekends takings to clear into your merchant account, and then take off with the money. The way that it falls down though, is that you need a merchant account, and there’s a lot of KYC and due diligence to get through if you want to set one of those up (there are a lot of merchant initiated scams, and your bank doesn’t want to be on the hook for them).
  - PeterisP 4y ago
    > Wait for the weekends takings to clear into your merchant account, and then take off with the money. That's the difficult part - since the acquiring bank is fully financially responsible if you do so (they'll compensate everyone else involved for the fraud chargebacks, no matter if they can recover it from you), they generally take quite stringent steps to fight merchant-initiated scams, and the simplest step is simply freezing the money for some time; 30 days is not uncommon but I have even seen 90 days if the merchant's profile is risky or if the incoming payment volume suddenly increases significantly - the bank is effectively treating any payments to the merchant as a line of credit or letter of guarantee until it's clear that those payments won't be fraudulent or charged back. So a merchant can quite realistically do some shenanigans with a reprogrammed terminal, but they won't be permitted to take off with a large amount of money from the merchant account until a sufficient amount of time will have passed for the first chargebacks or complaints of fraud to show up.

charles_kaw 4y ago

btw if anyone has ever taken a look at a POS setup, it's a bit misleading to the uninformed In some solutions, the readers are in fact hooked up directly to the POS system. However, the card terminal does not see unencrypted payment data. The POS is acting as a network bridge or switch, while getting limited information over network from the terminal. In fact, I'm not sure that's even something that's allowed in large scale installations today.

MBCook 4y ago
You only get unencrypted stuff when doing mag-stripe, and that’s mostly just card number and name. Same with tap-to-pay may-stripe emulation (the old way which no one is supposed to use anymore, even in the US per credit card rules). That’s why everyone has/is moving off mag-stripe (depending on country) and to EMV. With EMV and EMV contactless the terminal never gets the full card number, among many other significant security improvements.
- charles_kaw 4y ago
  >You only get unencrypted stuff when doing mag-stripe The terminal encrypts it before sending it over the wire
closewith 4y ago
Do you have a source for this? The EMV spec doesn’t include encryption of any data sent to the terminal from the card. The transaction cryptogram is signed, however.
- charles_kaw 4y ago
  The terminals themselves use mtls to communicate and wrap the payload , wasn't referring to the payload itself.
  - closewith 4y ago
    That seems like a walkback? You said: > However, the card terminal does not see unencrypted payment data. The card terminal does see unencrypted payment data. Hard to see your comment as ambiguous?

Cyberdog 4y ago

So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm…

irjustin 4y ago
This is like a 2005 hack. I'm sure you could come up with at least one good solution to this problem.
tmpz22 4y ago
If we say average transaction size is $10 and that you’ll save 1.000 customers (generous) before you’re caught. You just committed a felony to provide $10.000 in free food. Might as well get a day job and make that contribution annually and skip federal prison.
lelanthran 4y ago
> So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm… Almost certainly not on EMV certified card acquirers, unless there is a bug in the firmware. These things are so locked down that, even as an authorised developer for the payment terminal, we had no access to the hardware, no way to view the cards encrypted payload, etc.
- deleted 4y ago
  [deleted]
- lupire 4y ago
  Parent meant to ignore the EMV and have the kiosk just claim that all orders are paid, so the user gets food.
avianlyric 4y ago
Or you could tweak the ordering software to completely ignore the terminal, and not bother charging at all.

btown 4y ago

But if an attacker owns the touchscreen, they can do nefarious things like adding a "Please re-enter your PIN on the touchscreen to confirm your purchase" dialog, then match that PIN against a separate leaked database of card numbers and user identities. It's not just whether the card reader can be pivoted to; it's the entire notion that the kiosk itself carries the trust of the overall brand.

Gigachad 4y ago
It would be a huge amount of work to pull this off and it's something that would be detected within the day because its so odd and not at all how normal payment flows work. Not clear how you would match the pin either without having some personal info on the user which you don't have.
- alonsonic 4y ago
  Exactly. The kiosk app that communicates to the terminal only gets a "transaction approved" response. There is no personal identifiable information provided to the kiosk app so there would be no way to link the pin they typed in the kiosk back to the customer identity or card number. In short, for the kiosk this is a anonymous transaction that was confirmed paid. The most you could do is ask for more details in the kiosk app which would be clunky and very suspicious.
BoorishBears 4y ago
You could also tape a piece of paper up with a fake (tech support/tax help/credit help/reverse mortgage) line with a fake McDonald's endorsement in the early hours of the morning and make off with plenty of victims as the senior crowd rolls in for a grand time investment of 60 seconds. If you want to get creative with attacks you can, but sometimes comparing a creative attack to a "boring" attack can help frame the conversation. I've written kiosk apps that landed across the US and while there was a ton of hand wringing about security, and in an informal setting I brought up a simple question: If you reverse engineer the update process to have it show a penis, or you just carve a penis into the public display with a pocket knife, what's the difference and which is more likely to happen?

wowokay 4y ago

I know from experience that similar setups tend to have the workstation load the verifone updates, so a package could be inserted, it would take some more insider knowledge.

Too 4y ago
Do these payment terminals have secure boot or other forms of update payload verification? In that case the risk of accepting malicious updates from insecure touch screen would be much less.

t_mann 4y ago

But the transaction info has to be transmitted by the touch terminal - unless the recipient is set to a fixed value in the card machine, that should at least make it possible to re-route all of McDonald's revenue to some arbitrary recipient.

jon-wood 4y ago
The recipient is set to a fixed value in the card machine.

vishnugupta 4y ago

+1. To add, the modern EMV chip enabled transactions are not at all like magnetic stripe transactions. The chip in the card is not a passive storage but is also a computation device that signs a transaction, generates one time keys etc., Of course it is still possible to skim the card number off of magnetic strip and sell it in the darknet. However, the static card number is becoming less and less of a relevant thing now a days as more sites/processors are migrating to dynamic auth such as Apple Pay etc., A good overview + detail : https://www.youtube.com/watch?v=Zv1DjtBwADg https://www.youtube.com/watch?v=Zv1DjtBwADg

tjoff 4y ago
NFC cards dominate here though, which effectively negates the many benefits of chip cards.
- notatoad 4y ago
  NFC transactions are powered by the EMV chip, and include all the same signing ond one-time-key exchange as a chip-insertion but without the potential for skimming the mag strip
  - tjoff 4y ago
    Encrypted in the same sense that https is encrypted. Doesn't do jack if you have control over the "server". And in this case the server can have a large antenna and not require physical contact. So in essence, orders of magnitude worse than the magnetic strip.
    - aerostable_slug 4y ago
      This is fundamentally incorrect. Sniffing the NFC traffic gives the attacker nothing useful, just as skimming an EMV contact transaction gives the attacker nothing useful. >The contactless EMV chip transaction path leverages the cryptographic functions normally associated with a contact EMV chip transaction and uses the same authorization and settlement fields as a contact chip transaction. [0] [1] [0]: https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC-WP-Final-Nov-2015.pdf https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC... [1]: See EMV specifications, “Book 2 – Security and Key Management,” Version 4.3, November, 2011, http://www.emvco.com/specifications.aspx?id=223 http://www.emvco.com/specifications.aspx?id=223.

avianlyric 4y ago

You might not be able skim card details, but you could probably get the terminal to issue unexpected transactions. The most interesting transaction would be a very large refund. I’ve seen organised crime groups target restaurants in the past to issue themselves £1k+ refunds. They pretend to pay for meal, and while they have the EMV terminal in their hand, they cancel the original transaction, put the device into management mode (using default passwords) and issue themselves a nice large refund. It’s a complete pain in the arse for the banks receiving these refunds to catch and deal with properly. It’s surprisingly hard to return the money to the restaurant.

honkdaddy 4y ago
That’s pretty funny. Not that the restaurants deserve to be stolen from, but using the default password on an EMV is about as foolish as a restaurant leaving their registers open. I’m surprised the terminals don’t force you to at least set your own passcode.

lifeisstillgood 4y ago

In the article he points out the PC is responsible for updating firmware in the card reader. So while it's a more sophisticated hack, change the firmware to record the pin and send it back to the PC etc etc.

Goz3rr 4y ago
I'm assuming the firmware is cryptographically signed, because they have to upgrade from untrusted devices. That negates this entire attack vector.
- lifeisstillgood 4y ago
  I think our best reaction to that is ... hmmmm. But yes I think this is more a "hey there is so much insecure tech out there - here is another example" as opposed to "we are all dead and our bank accounts emptied"