7 ms·

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting mal

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. (That does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)

christina97 1y ago
There are much easier ways to skim cards than hacking the terminal.
- account42 1y ago
  Not without leaving physical evidence.
reaperducer 1y ago
I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. That's happened at least several times already. I believe breached PoS terminals were what happened in the big Target hack.
- lelanthran 1y ago
  > I believe breached PoS terminals were what happened in the big Target hack. The problem is that PoS terminals are not EMV terminals. EMV terminals have been through a certification process, and the hardware part of that certification ensures that the vendor only runs signed-binaries. Honestly, even if you could write and sideload (or even replace) the applications on the EMV terminal, I do not see a way to get them to a) run, and then b) send money elsewhere.
rockbruno 1y ago
Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.
- literalAardvark 1y ago
  Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.
  - Aurornis 1y ago
    Sending money to an arbitrary different account isn’t going to happen from the terminal reader itself. Banks don’t have wide open protocols where anyone can submit a credit card transaction and have it go to arbitrary accounts. Remember that credit card companies eat the cost of the fraudulent charges. They’re not going to make it easy for those to occur.
    - literalAardvark 1y ago
      Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
      - lelanthran 1y ago
        > Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one. I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.
        literalAardvark 1y ago
        Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.
        lelanthran 1y ago
        > Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account. That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend. In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know: a) Where your terminals are deployed b) Your real details c) The terminal's ID and the terminal's serial that maps to that specific merchant ID. So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24. Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have: 1. Their bank account number 2. Their physical address 3. The company registration number 4. Verified ID copies of the owner, directors, managers, etc. 5. Their money (from their transactions). So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree. 3.
adolph 1y ago
This story about a physical card reader checker to detect skimmer devices was interesting and posted here a couple years back. https://tech.target.com/blog/cybersecurity-easysweep https://tech.target.com/blog/cybersecurity-easysweep https://news.ycombinator.com/item?id=36788831 https://news.ycombinator.com/item?id=36788831
nine_k 1y ago
Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.
- jhugo 1y ago
  > could just make it collect CC details with every transaction Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it. And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.

christina97 1y ago

There are much easier ways to skim cards than hacking the terminal.

account42 1y ago
Not without leaving physical evidence.

reaperducer 1y ago

I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. That's happened at least several times already. I believe breached PoS terminals were what happened in the big Target hack.

lelanthran 1y ago
> I believe breached PoS terminals were what happened in the big Target hack. The problem is that PoS terminals are not EMV terminals. EMV terminals have been through a certification process, and the hardware part of that certification ensures that the vendor only runs signed-binaries. Honestly, even if you could write and sideload (or even replace) the applications on the EMV terminal, I do not see a way to get them to a) run, and then b) send money elsewhere.

rockbruno 1y ago

Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.

literalAardvark 1y ago
Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.
- Aurornis 1y ago
  Sending money to an arbitrary different account isn’t going to happen from the terminal reader itself. Banks don’t have wide open protocols where anyone can submit a credit card transaction and have it go to arbitrary accounts. Remember that credit card companies eat the cost of the fraudulent charges. They’re not going to make it easy for those to occur.
  - literalAardvark 1y ago
    Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.
    - lelanthran 1y ago
      > Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one. I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.
      - literalAardvark 1y ago
        Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.
        lelanthran 1y ago
        > Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account. That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend. In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know: a) Where your terminals are deployed b) Your real details c) The terminal's ID and the terminal's serial that maps to that specific merchant ID. So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24. Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have: 1. Their bank account number 2. Their physical address 3. The company registration number 4. Verified ID copies of the owner, directors, managers, etc. 5. Their money (from their transactions). So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree. 3.

adolph 1y ago

This story about a physical card reader checker to detect skimmer devices was interesting and posted here a couple years back. https://tech.target.com/blog/cybersecurity-easysweep https://tech.target.com/blog/cybersecurity-easysweep https://news.ycombinator.com/item?id=36788831 https://news.ycombinator.com/item?id=36788831

nine_k 1y ago

Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.

jhugo 1y ago
> could just make it collect CC details with every transaction Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it. And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.