[HN Gopher] Root shell on a credit card terminal
___________________________________________________________________
Root shell on a credit card terminal
Author : stgl
Score : 469 points
Date : 2025-06-01 13:42 UTC (9 hours ago)
(HTM) web link (stefan-gloor.ch)
(TXT) w3m dump (stefan-gloor.ch)
| Liftyee wrote:
| Bravo!
|
| I love thinking of ways to exploit and circumvent hardware
| restrictions like the extensive tamper protection here, but it
| seems I'd assumed that once they were triggered it was game over.
| Apparently not so - still plenty of interesting bits left over to
| poke around with. Makes sense that the secure part gets properly
| disabled though, otherwise I'd lose all confidence in their
| designers.
| lxgr wrote:
| That's possibly still true for the hardened processor: As TFA
| notes, that's not what was compromised here.
|
| > [...] only text strings seem to be passed to a binary
| (display_tool), that issues some inter-processor messages. The
| same goes for the key pad or the card reader itself. I could
| not find any evidence that these peripherals could be accessed
| directly from Linux.
|
| > Instead, there is an entirely separate processor, refered to
| as mp1, that seems to handle all the "secure" stuff, like
| handling the card, getting the pin and showing information on
| the screen. The "insecure" Linux, running on the second
| processor, mp2, only handles the networking, the updating, and
| the business logic.
| fredthestair wrote:
| From the description it sounded like the linux side may play
| some role in tamper event handling, but hopefully it can just
| also see it has occurred, otherwise getting a root shell first
| may lead to an opportunity to prevent the tamper event from
| clearing security keys.
| mrbluecoat wrote:
| For those easily excited:
|
| > the exposed root shell does not seem to be as big of a risk as
| initially feared. ... I could not find any evidence that
| sensitive data, such as card details, could become compromised
| this way
|
| A good read for security designers, though.
| LunaSea wrote:
| I highly doubt that having root a physical access to a terminal
| doesn't let you read credit card numbers.
|
| In security, physical access and to a lesser extent root access
| are equivalent to a guaranteed hack.
| kbolino wrote:
| Which is why modern card technologies like chip cards and
| tap-to-pay don't expose the sensitive numbers at all. The
| card reader can't steal a number that doesn't exist. Only
| magnetic stripe cards are so insecure, but the card reader
| exploited here doesn't even have a magnetic stripe reader.
|
| That having been said, this isn't perfect security. While a
| chip/tap card is in contact with the reader, it can still be
| used for fraudulent purposes. And physical access can open
| the door to other exploits, like trying to break the card's
| own security or installing a camera to capture images of the
| card.
| zahlman wrote:
| > Which is why modern card technologies like chip cards and
| tap-to-pay don't expose the sensitive numbers at all.
|
| How can they verify the transaction details without those
| numbers?
| ElectricalUnion wrote:
| Your bank holds the public key of the "a certain credit
| card".
|
| Your thing in the shape of a credit card is a HSM that
| holds the private key of the "a certain credit card".
|
| A public key (your bank) can verify if a given digital
| signature generated by a private key (yor card) is valid
| or not.
|
| The "CC Terminal" is a device that given the inputs
| (timestamp+value_of_transaction+password), asks the "CC
| HSM" to generate the signature of said values. "CC HSM"
| is smart and will ON PURPOSE refuse to generate valid
| signatures if you're being funny and inputing wrong
| passwords. Bank can further check if the signature makes
| sense or not.
|
| Merchant doesn't need to know the public key, the private
| key, or your password.
| Tijdreiziger wrote:
| > [...] the card reader exploited here doesn't even have a
| magnetic stripe reader.
|
| It does, it's on the right side of the terminal.
|
| https://worldline.com/content/dam/worldline/local/sl-
| si/docu...
| kbolino wrote:
| Good catch, I didn't see it (nor the usual symbol that
| accompanies it) when I looked at the pictures in the
| article.
|
| Ideally, the use of these stripes should be completely
| eliminated, as they can't possibly be secured.
| ChocolateGod wrote:
| I've seen stores still have a magnetic readers on their
| machines, but it's used for vouchers, loyalty cards etc
| or to scan card numbers to issue refunds. But not for
| payments.
| IshKebab wrote:
| Read the article. The actual work is done by another
| processor that only runs signed images.
| pelorat wrote:
| These are all over the Netherlands, this particular model.
| They don't accept any credit cards, only debit.
| zoobab wrote:
| And Belgium. I paid this afternoon in a supermarket with
| this model.
| Ambroos wrote:
| That depends on how they're set up. There is no real
| protocol difference between MasterCard and Visa debit vs
| credit. Delhaize in Belgium also uses them and you can
| definitely use all types of credit cards with them (at
| least Visa/MC and even AmEx).
| __MatrixMan__ wrote:
| If this terminal is anything like the ones I've worked with,
| the device he had a root shell on was only the "same device"
| as whatever handles the card details in the sense that it
| lives in the same housing and on the same PCB. They are
| otherwise two separate computers.
|
| In my case, the "outer" system was Android, so we could use
| ADB to control it however we liked--with relatively lax
| security. The "secure board" only took over for the part
| where it had to handle payment details. In order to test the
| payment flows we ended up revamping a bunch of 3D printers to
| hold a stylus instead because the inbuilt android tools
| couldn't see or touch anything that secure board was doing
| except for a relatively narrow set of actions like "start
| payment flow for $X" and "user canceled" and "payment for $X
| complete".
| zzzeek wrote:
| is the rooted mp2 subsystem responsible for acquiring the tamper
| state from the hardware that's passed off to the mp1 system? the
| diagram seems to indicate this is the case. Why not then try to
| disable the tamper signal and get mp1 to boot up with the device
| opened?
| stgl wrote:
| No, I don't think so. I think the tamper logic is implemented
| in hardware and cannot be easily fooled. It seems like both mp1
| and mp2 access memory-mapped registers of the tamper subsystem
| to check its status (and other hardware system stuff like reset
| reason etc.)
|
| However, I am assuming that there is a way to gain write access
| to the hardware registers from Linux. After all, the
| manufacturer has the ability to "un-tamper" devices and there
| is this nor_update tool in Linux that might be able to do it.
| But my guess would be that first a key has to be loaded through
| some authenticated interface in order to unlock that
| functionality.
| tomsonj wrote:
| Reminds me of "Every 10-ft wall can be defeated with an 11-ft
| ladder"
| qmarchi wrote:
| Disc: Former Visa Employee
|
| Generally, these devices will use the mp1 to do all of the
| cryptographic operations around the devices.
|
| The biggest part of this is the keys defined between the
| terminal and the acceptance gateway (something like
| CyberSource or Authorize.net).
|
| When the temper protection is tripped the keys that are used
| are immediately dropped from RAM and you can't recover them,
| they have to manually be input into the device again to reset
| the tamper protection.
|
| (Side Note: keys are specific to a merchant. If you're able
| to extract them, it limits the blowback.)
| dedicate wrote:
| I'm curious: with that level of access, even if you can't
| directly grab PANs, what are the practical limitations? Could
| they, say, intercept user input before encryption, or cause
| targeted denials of service?
| stgl wrote:
| I cannot tell for sure. I didn't have time to really look at
| the Linux applications and what they do exactly. My guess is
| that most of the sensitive stuff is done on mp1 (reading the
| card, verifying the pin etc.) and the Linux just acts as
| untrusted relay to the network. Denial of service should be
| possible in the sense that it could just put the system in a
| boot loop.
| robocat wrote:
| > Denial of service should be possible
|
| That's sounds like an overcomplicatedengineer solution.
|
| The 10x engineer uses a hammer to deny service.
|
| Aside: I'm an artist-engineer. I like the performance art of
| using an oversized hammer to solve a problem that isn't
| obviously solved using a hammer - and I love the discovery
| process when my aims fail.
| Hilift wrote:
| Devices such as this are cloned and used for fraud. It can be
| done without triggering any of the sensors. Secret service
| confiscated multiple cloned devices in an enforcement operation
| recently in NYC.
|
| "Recent incidents in the U.S. include criminals committing
| fraud through processing fraudulent return transactions. As
| part of the fraud scheme, criminals obtain Point-of-Sale (POS)
| devices--either from an acquirer or agent while posing as a
| merchant, from online resellers or auctions, or through theft--
| and program the POS devices with the credentials of a
| legitimate merchant, thus effectively cloning the unsuspecting
| merchant's actual POS device. Criminals use the cloned POS
| devices to..."
|
| https://cardsystems.com/point-of-sale-clone-fraud-activity/
| halpow wrote:
| If you want to try easy mode, check out those newfangled android-
| based credit card terminal. I bet they're much more rewarding,
| especially since you tap your pin on the screen. Juicy.
| jeroenhd wrote:
| That'd get you the PIN quite easily, but if they're designed
| the same way (with all the important bits being handed off to a
| secure secondary processor) you still wouldn't be able to do
| much with the card as modern cards do a whole load of
| cryptography on-card to prevent stuff like this.
|
| The attack would only work on terminals where every payment
| option but the magnetic card reader is broken, but those should
| give off skimmer alert alarm bells before you ever see a PIN
| prompt.
| user_7832 wrote:
| I'm not sure which type of android terminals you have where you
| are, but in India they seem to be running Android Oreo (support
| ended in Jan '21). Yummy!
| user_7832 wrote:
| Also, it _is_ possible to open other apps and the
| notification centre. And unsurprisingly the entire device is
| terribly laggy.
| _djo_ wrote:
| The PIN data is still encrypted even when displayed on a touch
| pad, using user interfaces controlled by firmware running in
| the trusted zone.
|
| So the applications in between, that would be accessible in an
| attack like this, can't view the PIN.
| bmurray7jhu wrote:
| The touch controller is generally connected to a MUX controlled
| by the security processor. When entering sensitive data
| (PIN/PANs), the touch controller output is routed directly to
| the security processor, bypassing any Android-derived OS
| responsible for the GUI.
| thenthenthen wrote:
| These are everywhere in Europe. Not sure about Switzerland, but
| credit cards are not really owned or used in much of the Europe I
| know. I would call it a POS, point of sale (system), these things
| can read all kinda of cards. Nevertheless, nice write up!
| jajko wrote:
| Oh yes they are. I detest having to juggle all those cards in
| my wallet, already have tons for various reasons (not just
| payment stuff), so no room for ie debit ones.
|
| Dont see the appeal of putting even more stuff into phone or
| ewatches (prefer good mechanical ones), losing it would be
| catastrophe enough as it is for privacy. But thats me.
| pjerem wrote:
| Actually, putting your card on your phone is a better
| protection against theft : they cannot be used without
| biometric identification, can be remotely revoked and you can
| still keep your plastic cards as backup.
|
| I could easily live without it and I wouldn't even consider
| it to be an important gesture for my next phone but it's
| pretty useful when you have it.
|
| Also, idk for Android but on iPhone it's faster than plastic
| cards and more secure.
|
| But I hope plastic cards are there to stay because that's yet
| another thing locking us into the iOS/Android duopoly.
| ComputerGuru wrote:
| The (compromised) Linux decides whether to load the "compromised
| mode" code or the mp1 secure system? Sounds like an avenue to
| explore. It says the bootloader itself is secure, but that
| doesn't mean much if it's being loaded into a compromised
| environment, depending on where it is actually being executed. I
| guess the coprocessor could be considered a Secure Enclave of
| Sorts, but the fact that Linux could load a separate bootloader
| and run that (somehow) is of concern.
| stgl wrote:
| No, it cannot load a separate bootloader. I tried to tamper
| with the loadercode (the "secure" bootloader), but it wouldn't
| boot. So I am guessing there is some third party (boot ROM)
| that verifies it.
|
| Also, I think Linux always loads loadercode + mp1.img,
| regardless of the tamper state. The different code paths
| depending on tamper state are taken within the (integrity
| protected) loadercode.
| ComputerGuru wrote:
| Keep in mind that no tamper mode will be set if you use the
| external debug interface. If Linux is used for networking
| then maybe you could MITM payments.
| _djo_ wrote:
| The card details and payment are encrypted and then signed
| by the firmware running in the secure/trusted zone, using
| public keys provided by the acquirer.
| londons_explore wrote:
| It's also possible that the root shell is opened up _when_ the
| tamper seal is triggered.
|
| Ie. The system is either in secure mode (with all necessary
| crypto keys for operation), or it is in insecure mode with a root
| shell open for debugging and failure analysis, but that
| transition also deleted the critical private keys.
| fp64 wrote:
| Was my guess as well, maybe it's even possible to use it to
| flash new keys so the device can be used again?
|
| Now I am curious if I can find a terminal myself, if they are
| actually getting phased out it might not be too difficult to
| find a used one...
| stgl wrote:
| I had the same idea, but no, I tried with a second,
| untampered one and I also got a working shell. So it does not
| seem to be dependent on the tamper state.
| lelanthran wrote:
| > Was my guess as well, maybe it's even possible to use it to
| flash new keys so the device can be used again?
|
| What keys would you flash them with? Anything encrypted with
| your "new" keys can't be decrypted on the other end of the
| transaction anyway, so what would be the point?
| avipars wrote:
| Can it run doom?
| blooalien wrote:
| > Can it run doom?
|
| _Almost certainly_ yes.
| joshstrange wrote:
| Aside from the fact that I wouldn't know what I was looking at,
| I've been tempted to crack open one of the Stripe M2 readers I
| have and look inside.
|
| Unfortunately, out of 36 readers that I bought, 7 have "died" (2
| won't hold a charge, 1 won't scan NFC, and 4 report "tampered").
| That attrition rate is pretty bad on the surface but it doesn't
| tell the whole story of course, how often were they used? How old
| are they?
|
| The answer to those questions is much more damning. The devices
| are 1-3 years old (I bought them over time) and have been used a
| max of 9 days total [0]. Yes, 9 days _total_ of use and 7 of 36
| readers failed in some fashion. Oh, and the readers are all kept
| in hardshell cases with foam inserts (1 slot per reader) whenever
| they are moved.
|
| Needless to say, I'm not a huge fan of the M2 readers but they
| are still the best option for me :/
|
| [0] Some background, my company handles festival payments. We
| travel to events and handle the in-person payments (most happens
| on web/app) with iPads+M2 Readers. That's why there are so few
| "days of use" over 3 years.
| mrbuttons454 wrote:
| I'd be sure to charge them before storing them for the next
| show. Most batteries don't like being stored for long periods
| in a low SoC state. And I'm sure the tamper requires a
| functional battery.
| joshstrange wrote:
| All readers are charged for a day minimum after a festival
| before I pull the power. I then normally power them up at
| least a week before the next event so I can update them all
| and check that no more have randomly died on me. I keep a
| healthy buffer of devices so that I can replace them without
| paying for express shipping from Stripe which saved me for
| the last event I did where I had 6 of them die (before that
| pre-event check I only had the 1 bad NFC reader from the
| previous year).
|
| I have to assume that one of the hard-shell cases got thrown
| around a little too much which caused 4 readers to go into
| tamper mode. 3 of the tamper mode readers were in the same
| case but the other was in my nicest case and still had the
| issue ("nicest" = custom made case vs pick-and-pluck-style).
|
| The tampers I can somewhat understand (still just so odd to
| have 4 die "at once"), maybe they did get banged up, but the
| failed NFC and not holding a charge issues are less
| acceptable to me given the time/use.
| VladVladikoff wrote:
| Just curious if you have experienced equipment issues with
| stripe equipment that is not battery powered. I am about to
| pull the trigger on a POS decision and strip is a contender
| in my choices, but this is for wired devices not wireless.
| joshstrange wrote:
| The only Stripe hardware I've used is the M2 reader so I
| can't speak to any wired options. I don't think there are
| any wired readers that you can use you with an iPad
| (which I needed).
| absurdo wrote:
| For the young players: this is what hacker in "Hacker News"
| stands for. This is 101 and it's very simply explained which
| makes it a great step by step example of a typical journey. Hack-
| a-day is full of these if you want more.
|
| The author is clearly curious and leads in knowing a lot to begin
| with.
|
| The work-behind-the-work is looking up data sheets for the chips
| involved, desoldering them without damaging them, in the case of
| memory resoldering with hookup wire and hopefully its access is
| slow enough that it can work fine over the length of the wire,
| following hunches, trying things, and knowing (for next time) the
| possibility of using a pinhole camera or something of the sort
| when drilling shallow holes and looking through for tamper traces
| to avoid in further drills, if so desired be.
|
| As others have mentioned, it would be interesting if the author
| stuck in and got past the tamper checks to see if it would work
| as normal. Oh well!
| zidoo wrote:
| Amen for the first sentence. One more LLM wrapper today, and I
| would die.
| account-5 wrote:
| It's so tiresome and is slowly ruining HN for me personally.
| lucianbr wrote:
| Hear hear.
| paulddraper wrote:
| Or UI pontifications
| belter wrote:
| Yeah, this has been _LLM News_ for a while...
| ronsor wrote:
| 50% people shilling LLM products, 50% people complaining
| about LLMs (or indirectly by complaining about crawlers)
|
| However, this place used to be JS framework news not too
| long ago
| herval wrote:
| and "Crypto News" for a long time too
| uoaei wrote:
| There's more finance and VC here than anyone wants to
| acknowledge. But it's not unexpected given that Y
| Combinator is a VC firm.
|
| However these folks aren't known for their technical
| expertise so there's a lot of unnecessary noise feeding
| into the AI hype cycle of late.
| airstrike wrote:
| It does feels like a good use of AI (ML, really) would be to
| write a "disaggregator" for HN that tags submissions by
| category and lets users browse the bits they care about. Wish
| I had time to do it....
| miki123211 wrote:
| And a TL;DR, both for the articles themselves as well as
| the discussions.
|
| I don't think a TL;DR can replace most articles that appear
| on HN, but it can certainly tell me whether the article is
| interesting, much better than any headline ever could.
| Especially so if the TL;DR is written by a neutral AI with
| no interest in making me click anything, and hence no
| qualms about surfacing the most important information to
| the top.
|
| I actually tried to do this, but it was with GPT-3.5, and I
| didn't exactly like how it worked. I should look at this
| again, I wouldn't be surprised if the code I used back then
| could just be ported over to 2.5 Flash and produce much
| better results.
| ajsnigrutin wrote:
| It's either LLM or "<existing software> written in <languge
| of the week>"
| suobset wrote:
| Thank you so much. Been a long time lurker, only recently got
| an account to start commenting. Posts like this make my entire
| day: concise, well thought/researched/executed, and they put
| the "hacker" in HN.
| AaronAPU wrote:
| I think this might have been the first post I actually upvoted.
| I do upvote comments often, but this post itself is actually ..
| about hacking!
| Disposal8433 wrote:
| You can make fake debit/credit card transactions on a $2 USB card
| reader. All the specs are here and the protocol is public and
| documented (IIRC 5000 pages in a lot of PDF, it's a pain in the
| ass to read).
|
| But to validate those transactions, you must send them to the
| bank over the internet, and you'll get a visit from the
| feds/FBI/whatever if you do it.
|
| There is no real protection on card readers (most use Linux with
| a small shitty password). The protection comes from the contracts
| and regulations between the shops and the banks.
| csinode wrote:
| 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 wrote:
| There are much easier ways to skim cards than hacking the
| terminal.
| rockbruno wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| thwarted wrote:
| Credit card companies eat the cost of fraudulent charges
| that they can not pass on to/blame the merchant for.
| Aurornis wrote:
| Which is why they won't have a public API that allows
| running transactions that send money to arbitrary
| accounts.
|
| If someone altered the terminal to charge more (a
| hypothetical suggestion above), they could recoup that
| money from the merchant's account because they have an
| agreement in place.
|
| You can't run arbitrary transactions to arbitrary
| accounts (the other proposed attack above) because there
| isn't an agreement in place.
| Arrowmaster wrote:
| You should read up on the wonderful system they call ACH.
| kortilla wrote:
| That's precisely why credit card readers aren't attached
| to it
| nine_k wrote:
| Arbitrary account, no. An arbitrary merchant, yes.
| lelanthran wrote:
| > Kind of, but if you control the card reader you could
| charge more for the transaction without showing the
| amount, for instance.
|
| Not supposed to be possible on a certified terminal. The
| certification tests this particular case (the transaction
| is a hash of the keys, amount and a few other things. The
| display of the swipe/tap/insert screen and the pin-entry
| are under control of the certified kernel, so the
| userspacve application has no control of the amount that
| is displayed).
|
| > And maybe even send the money to a different account.
|
| Not from the card reader.
| cesarb wrote:
| I've heard of it happening here in Brazil. In the
| simplest variant, something is glued on top of the screen
| to hide the higher digits, making the value appear to be
| lower; supposedly, some more advanced variants of the
| scam have a damaged or tampered screen.
| weaksauce wrote:
| unless it's changed recently that only applies to tap and
| chip payments (which you should always prefer to avoid card
| skimmers) and not the old slide the ~~barcode~~ magnetic
| strip kinda payment.
| cesarb wrote:
| Does anyone still use the magnetic strip? I think it's
| been over a decade since I've seen a credit card without
| the chip, and terminals have been able to read the chip
| since forever. I think the last few times a store tried
| to use the magnetic strip on my card (because the chip
| failed to read due to a bad contact), the transaction was
| simply rejected due to not using the chip.
| bdangubic wrote:
| 2 times just this week I was asked to swipe, "issues with
| the chip reader" (CVS and Wegmans)
| girvo wrote:
| That's wild to me, the last time I had to swipe my card
| here in Australia was sometime in the early 2010s!
|
| Heck a lot of the terminals here _can 't_ swipe a card at
| all
| pornel wrote:
| > unless it's changed recently
|
| In Europe it's changed 15-20 years ago, when EMV-capable
| terminals became required, and acceptance of magnetic
| stripe cards got phased out soon after.
|
| Since Apple Pay became a thing a _decade_ ago, we don 't
| even get US tourists confused by inability to swipe their
| cards anymore.
| cwillu wrote:
| "which you should always prefer to avoid card skimmers"
| could use a disambiguation comma between "prefer" and
| "to"; I misread it several times before the intended
| meaning clicked.
| reaperducer wrote:
| _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 wrote:
| > 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.
| adolph wrote:
| 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://news.ycombinator.com/item?id=36788831
| nine_k wrote:
| 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.
| Toritori12 wrote:
| I thought most POS devices stop accepting "offline" payments.
| sgjohnson wrote:
| Maybe today, when the line between a Credit and a Debit card
| has gotten significantly blurrier (except in the US).
|
| I definitely remember making an _offline_ payment with an
| AMEX card at a restaurant in the UK some 10 years ago.
|
| Also, most airlines that take payments on board also run the
| terminals in offline mode.
|
| There must be some mapping of BIN codes and whether to allow
| an offline transaction.
| glitchc wrote:
| It's up to the merchant to decide if they want to support
| offline payments and to what limit. The terminals certainly
| allow it. Your transaction will be stored in a secure way
| (either encrypted or in a secure element) until the
| terminal reconnects.
|
| The way the rules are set up though, the risk of a failed
| offline transaction is almost entirely borne by the
| merchant. In most cases the merchant is unwilling to accept
| this risk and disables the feature.
| sgjohnson wrote:
| I guess for a restaurant it basically always makes sense
| to accept offline payments. I wasn't aware that they
| might not be able to process card payments when I
| ordered.
|
| I don't typically carry any cash on me, and, well, if
| their terminals go down before I've closed my tab, they
| assume all of the risk anyway.
| tough wrote:
| I remember doing offline debit card payments 10y ago in a
| flight
|
| they would pass the card with one of those old engraving
| things lol
| pjerem wrote:
| I think it's still pretty frequent even nowadays. I have
| payment cards with systematic authorization and and
| others without and I can totally see the difference.
|
| Transactions with the cards requiring authorization will
| take several seconds while with my other cards it will be
| instant most of the time.
|
| It depends on the configuration of the terminal : most
| merchant will allow offline (or asynchronous)
| transactions up to a certain amount when there is an
| important flux of customers waiting to pay.
|
| I'm also pretty sure (that's speculation at that point
| but I felt it in my experience) that some cards have more
| chances to have instant (offline) transactions than
| others. The more << premium >> the cards the less I saw
| the "waiting for authorization" screen. Especially for
| small amounts.
| Delk wrote:
| I remember paying at a bike repair shop that used a
| physical card imprinter [1], some, I don't know, 15 years
| ago?
|
| [1] https://en.wikipedia.org/wiki/Credit_card_imprinter
| Nextgrid wrote:
| It also depends on the card. The card can decide and even
| stores a running counter of how much has been processed
| offline, after which it will want to go online to check
| and reset its counter.
| glitchc wrote:
| > There is no real protection on card readers (most use Linux
| with a small shitty password). The protection comes from the
| contracts and regulations between the shops and the banks.
|
| I'm afraid that's not true. Merchant terminals have secure
| hardware embedded inside to store the bank and interchange
| keys. If those keys leaked, someone could spoof legitimate
| transactions.
| kuschku wrote:
| > If those keys leaked, someone could spoof legitimate
| transactions.
|
| You mean, whenever those keys leak. It's not that hard to do,
| see e.g. https://media.ccc.de/v/32c3-7368-shopshifting#t=2207
| stef25 wrote:
| > You can make fake debit/credit card transactions on a $2 USB
| card reader
|
| Not asking "teach me how to do this" but could you explain in a
| little more detail ?
| charcircuit wrote:
| >and you'll get a visit from the feds/FBI/whatever if you do it
|
| Is there any proof to this statement or are you just trying to
| scare people? I think it's possible there are bigger groups
| that would have their attention and a single fraudulent
| transaction would just be noise.
| Nextgrid wrote:
| In his scenario I don't understand _where_ he 'd send the
| transaction to begin with?
|
| In a typical scenario my understanding is that you get the
| terminal from your acquirer - this is your broker to the card
| networks. When the terminal makes a transaction, it does some
| crypto magic using its own keys (that identify it to the
| acquirer), sends that to the card which does more crypto
| magic using its own keys, and finally the result of that is
| sent to the acquirer.
|
| If you do this flow yourself with fake keys you'd get the
| card to sign a transaction for your fake terminal's key
| (assuming you know the card's PIN of course - unless you're
| happy to forego any CVM), but you have no acquirer that would
| accept said transaction, so I don't see how you could commit
| a crime here even if you wanted to? You just got some
| meaningless bytes back.
|
| And of course, if you have an actually valid terminal key
| that is trusted by an acquirer and do all this, you've
| effectively just made a normal payment - if the person was
| willingly paying you then no crime either, and otherwise it's
| no different than using a legit terminal to bill someone
| without their knowledge.
| lelanthran wrote:
| > There is no real protection on card readers (most use Linux
| with a small shitty password).
|
| Sure there is: only signed binaries can run, executable
| filesystem is read-only, data filesystem has noexec bit set,
| root login is disabled, crippled busybox misses a lot of
| functionality, keys are loaded from a secure area on bootup,
| master key injection only available when loading at the
| factory, bootup itself is more or less secure, tamper detection
| blanks the chip, etc.
|
| Sure, if you have a cheap non-EMV certified Android terminal
| imported from Asia it'll probably use a standard Linux, with a
| rw root filesystem, with root login enabled *and* sudo enabled
| for the username used to execute applications, tamper-detection
| is non-existent, screen-casting not locked down, ports are all
| openable and busybox is more or less complete.
|
| Source: Me. I developed (and still sometimes do) EMV
| applications for card acquisition for a few years. Even in dev
| mode (which requires the vendor to provide IDs of the
| developers), these things are very much locked down solidly.
| timewizard wrote:
| > Sure there is: only signed binaries can run, executable
| filesystem is read-only, data filesystem has noexec bit set,
| root login is disabled, crippled busybox misses a lot of
| functionality, keys are loaded from a secure area on bootup,
| master key injection only available when loading at the
| factory, bootup itself is more or less secure, tamper
| detection blanks the chip, etc.
|
| Sounds good. Has anyone been hired to attempt to attack the
| device and find vulnerabilities?
| lelanthran wrote:
| > Sounds good. Has anyone been hired to attempt to attack
| the device and find vulnerabilities?
|
| In the company I work with, yup. I'm not sure about the
| rest of the industry, but the security in place ensures
| that even the _developers_ of the EMV applications are
| treated as hostile actors.
|
| The certification process itself does do a little bit of
| malicious attempts too (try to get the terminal to do
| something out of spec, like during pin-entry, etc).
| dijit wrote:
| How does the binary signing work?
|
| I'm not looking to hack anything, but it sounds cool to
| have signed binaries only on linux!!
| _djo_ wrote:
| Varies from manufacturer to manufacturer. This is
| Ingenico's approach, for instance:
| https://ingenico.com/en/products-
| services/services/security-...
| shakna wrote:
| Whilst I'm sure they use something else, Linux does have
| an experimental extension, "Integrity Measurement
| Architecture" extension that allows you to sign and
| verify RSA keys against every binary.
| cluckindan wrote:
| The OP device tried to mount a USB volume and would have
| started dropbear if it had been found (presumably in PATH).
| Maybe maybe maybe...
| pabs3 wrote:
| Have you considered using dm-verity instead of signed
| binaries?
| bogantech wrote:
| > But to validate those transactions, you must send them to the
| bank over the internet
|
| Not how it works at all, banks don't have some open API on the
| internet for processing card transactions
| nine_k wrote:
| It's over the Internet, because you're not going to run a
| dedicated fiber to every card reader. But it's not over the
| _unprotected_ internet; your card reader will establish a VPN
| connection of sorts, or at least talk via an encrypted
| channel (think TLS) is you use e.g. a Square terminal.
|
| Not that a random person can hit these endpoints,
| unauthenticated, and try to run a transaction.
| tialaramex wrote:
| I agree that this isn't how it works.
|
| The first thing to understand at an even higher level about
| payment cards is that they have _always_ had two separate and
| barely related components, Authorisation and Settlement.
|
| Authorisation is concerned with whether this specific
| transaction has been approved in some sense by a card issuer.
| Authorization today is relatively high tech, there's somewhat
| decent cryptography, tamper resistance, uniqueness = they
| really care - and that's because when Authorization problems
| occur the banks might lose money, which they hate.
|
| Settlement is "just" moving the money from one customer to
| another. $123.45 from Jim Smith to Terrible Goose Inc, done.
| This is very mid-late-20th century technology, we're not
| talking pieces of paper and scribbly hand writing, but fixed
| width ASCII fields on magnetic tape is fine - it's the
| customer's money so the banks don't care more than legally
| required.
|
| Settlement replays are how you get "accidents" where a big
| store's customers all get charged twice for a whole day - the
| associated Authorizations can't be replayed, that's the banks
| money at risk - but the settlements aren't protected.
|
| Merchants can, and some do, choose not to care about
| Authorization. In a huge business it could make sense to eat
| say 2% of sales as undetected fraud (ie you never receive
| payment) rather than have any transactions fail. If you
| operate a food truck using a terminal to take $1000 per day
| on your iPhone the people who supply your terminal may not
| let you opt out because that's risk they don't want. But if
| Jeff Bezos or Doug McMillon makes more without Auth he's
| turning it off.
| miki123211 wrote:
| > The protection comes from the contracts and regulations
| between the shops and the banks.
|
| While the comment is not quite true (see sibling replies), this
| part is spot on.
|
| This is also why crackpot theories about people walking around
| with portable card readers and stealing money from contactless
| cards are false. Yes you can walk around and make those
| transactions, what comes after (and the setup you had to do
| before) is the problem. I'm not even sure whether you could get
| the money out before being caught and shut down. With how many
| people these days have push notifications for their
| transactions, I highly doubt that.
| girvo wrote:
| > Yes you can walk around and make those transactions, what
| comes after (and the setup you had to do before) is the
| problem
|
| I mean with the amount of stolen card details routinely
| traded and used successfully (at least for a while) and with
| how little crime like that is investigated or punished in
| some jurisdictions, I dunno...
|
| Still it's not quite as simple as "taking the money from your
| card" like said crackpots think.
| ofjcihen wrote:
| The look into these is neat but...why immediately open it up and
| trigger the tamper state? Did they not know most readers would
| have one?
|
| Any real testing happening in the tamper state might be
| meaningless. Perhaps the shell is available after the tamper
| state triggers for resetting purposes.
|
| It just seems like opening it would be the last thing you would
| try.
| stgl wrote:
| Well, I felt like I first had to get a feeling for what I am
| working with. Hardware, what SoC, interfaces, flash etc...
| Otherwise I am too much in the dark. But sure, in hindsight I
| could've just tapped the debug connector and could have been
| done with it.
|
| No, I got a shell on second, untampered one, as well.
| allenrb wrote:
| Specifics of this hack aside, I wish I could solder like
| that!
| _trampeltier wrote:
| I know they run Linux, once a such terminal updated and rebooted
| when I would pay. It was in the evening rush hour on in a shop.
| The other person before me paid, then the salesperon scanded my
| things and suddenly an update was on the screen.
| bill_mcgonigle wrote:
| What a nice writeup! Just curious - what kind of wire do you use
| to solder on the pins - enameled?
|
| I wonder if they offer their customers source to keep the Busybox
| folks happy?
| stgl wrote:
| Yes, 0.1 mm diameter enameled copper wire. Chasing GPL
| violations sounds like a fun hobby :)
| jdefr89 wrote:
| UART always the first place I look...
| Lord_Zero wrote:
| Any way to reset the tamper protection from software?
| reliablereason wrote:
| Hopefully the important private keys that is used to identify
| the terminal are erased when the tamper is activated.
| SamuelAdams wrote:
| Alright sorry if this is dumb but how does the OP know about all
| this?
| tialaramex wrote:
| Light Blue Touchpaper https://www.lightbluetouchpaper.org/ might
| well be interested in this work, the card payment tech is
| something they spent lots of time looking at and they tend to
| have a more realistic assessment of where the weaknesses might be
| that the industry which tends to see itself as infallible.
___________________________________________________________________
(page generated 2025-06-01 23:00 UTC)