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.
> 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.
> 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?
> 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).
Varies from vendor to vendor; signed-binaries-only is part of the certification process but the exact mechanism itself is not (or maybe that has changed, not sure).
The way it worked in 2003 (when I first wrote EMV applications) was, when we have a binary that we are ready to deploy, we ship that binary to the manufacturer (Schlumbeger(sp?), at that time), if it passes cert-testing, they sign it and ship it back and that's what we would program the terminals with.
The way it works now is pretty much the same - we build an APK bundle, send it to the manufacturer (Verifone, Pax, etc) and after signing they make it available on their appstore which their terminal can access.
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.
> Have you considered using dm-verity instead of signed binaries?
Why? I don't see any benefits.
In any case, the developers don't get a say in what is used to secure the terminal. The manufacturer decides that, then they get the hardware+firmware certified.
The terminals the developers get are already certified and locked down.
> 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.
I did somehow have two different cards (an Amex and a Visa) compromised at the same time about two months ago, and I do wonder if it was some kind of skimmer setup - if it was just one of them then I'd assume it was just some online store I'd used it at that had been hacked, but I've not used both those cards on the same sites.
I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!
Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.
The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.
But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...
The hotel refunded the pending transaction, so they are the party that suffered the financial loss. If they hadn't done that, then the credit card company would have done a charge-back on the disputed transaction and made me whole, and I wouldn't have suffered a loss in that case either. The first question the police forms for reporting fraud or cybercrime are "how much have you lost" - they don't care if it's 'nothing'.
It's the hotel that has to clean the room, has lost consumables, and has lost revenue from it not being available to be booked...
Well, the issue is that you need a merchant account to send the money to, and it's quite hard to get one without identifying yourself, and it takes a bit of time after the transaction to actually get the money because of chargebacks and the like. So you can't just pull the money out directly. But that's true of basically any credit card fraud: what you do instead is buy something from someone who takes credit cards. Which is entirely possible with contactless, you can e.g. proxy a connection from a reader to a victim card, it's just that the limits and difficulty of lining up the time of the transaction with someone walking past make it not particularly useful (compared to just stealing or skimming the card details).
Didn't people manage to present a remote card (i.e. in a mark's pocket) to a legitimate terminal through an NFC tunnel of sorts? Limited to no pin required amounts, but still.
I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.
At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.
> 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.
> 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...
There's a huge difference between me using your credit card to buy stuff off Amazon (chance of success: somewhere between "doubtful" and "near-definite" depending mostly on geographical factors and your particular bank), and me walking around with a hacked card reader and stealing money out of your account by dialing in phony transactions directed to my account (chance of success: somewhere between "zero" and "also zero, but with a decimal point followed by more zeroes").
Aren't the contracts and regulations holding back the honest people only? But not those who violate contracts and regulations, like the dishonest ones?
> 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.
Yeah it's definitely an arms race. Interestingly, technology in the States lags behind the rest of the world. Every other country has moved on to chip and PIN, 2FA, obe time tokens and asymmetric cryptography. Whereas in the US, one can still find 3DES signatures and unencrypted authorization codes usable for a time duration (read: multiple transactions).
It seems that the banks here are okay with a certain percentage of shrinkage as long as merchants don't have to upgrade and consumers are not inconvenienced. The banks prefer to eat the cost to maintain large fraud and dispute resolution departments. Whereas elsewhere in the world they're much smaller and mainly focused on correspondent banking. It's really interesting to see that the "customer is always right" policy has such a strong influence on the financial sector.
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.)
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.
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.
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.
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.
> 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.
> 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.
> 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.
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.
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.
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.
Yes, occasionally when refueling a shared car owned by a company that distributes those cars all over The Netherlands. It's common here in leased car fleets as well, where the user gets a magstripe card to refuel (and needs to provide details about current mileage and if the car was a replacement car).
I used it recently because my bank denied the contactless and chip payments I tried before that. Surprisingly the mag stripe worked - and this is with card issues from a EU bank where mag stripes have been an historical artifact much longer than in the US.
USA was very late to adopt chip/tap terminals, even relative to Canada. I could be wrong but IIRC it was only when Apple Pay came along that tap-enabled terminals began to hit critical mass.
It's always incredible to see few people in the US uses the tech that's available until Apple makes it a thing, and seeing that play out over and over.
This is the same everywhere though. See, e.g. incredibly late fibre rollout in many well off EU countries because they already had copper in the ground everywhere vs. developing countries that never had that legacy infrastructure inertia.
What I'm talking about is a lot of those terminals supported tap to pay well before Apple Pay became a thing. The infrastructure was there, the technology was there, you could use it if you cared to do so. Most people just didn't know it was even an option. Google Wallet supported tap to pay years before Apple Pay was even announced. Tap to pay credit cards existed years before then. Nobody gave a shit about the technology until Apple announced Apple Pay and suddenly it became a big deal for vendors to actually check if their POS systems had it enabled or not.
I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.
Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.
“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.
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.
> 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.
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.
> 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.
How exactly are you going to get the diversified IPEK to generate the necessary keys to create the HMAC for the transaction that will be authorized by your merchant acquirer?
The BDK for your merchant acquirer is held by them in an HSM or equivalent. The IPEK is device specific, derived from the BDK based on the terminal ID.
The individual keys for the HMAC are generated for each transaction and are cryptographically linked to a transaction ID and the IPEK, so that the acquirer can determine whether there are missing messages.
Card readers that comply with the latest EMV chip/contactless standards require a secure element that maintains the crypto information and only allows specific requests from the non-secure element and only provides encrypted blobs for transmission between the acquirer backend and the secure element.
You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.
Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.
But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).
These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.
I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.
The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.
Wouldn't the concern being redirecting the money to a different merchant account? Of course that would mean you are easily tracked down when found out but I'm sure you can find a way that some schmuck who doesn't actually know anything about you ends up with that role.
Then again, changing the merchant account is usually only protected by a numerical PIN so you wouldn't need root access. Maybe it would be to send the original requested amount to the expected merchant account but also do a separate smaller transaction to your own account?
The configuration of the settlement bank account happens at the processor. If you want to change it, you need to talk to customer service and fill out a PDF form, with signatures and other human verification processes.
If it were possible to change the settlement account via an online portal or similar, then you'd need the user login credentials for that portal. In which case, compromising the card reader has no additional value.
this is all true, but if you've compromised a merchant deeply, it doesn't seems impossible to run a $1 charge as a (bad) customer and then give that customer (you) a, say, $1,000 refund.
You can only void existing transactions, so the money would be returned to the same card, and the amount would be limited to the originally captured amount.
It is possible to create a "push" transaction too of course. Visa Direct, Mastercard MoneySend, etc. But that requires a separate merchant account, and should not be possible from the card reader or POS.
If you've compromised deeply enough to be in the AP system, you can create arbitrary payments, but that's well out of scope for this thread.
Then you could just complete a normal transaction on their website and introduce your account in to their system that way, no real need for a compromised terminal?
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.
This terminology is not quite right for the US. I'm assuming you're from elsewhere due to the "s" in authorization. :)
In the US, the two steps for the merchant are Authorize (optional) and Capture. If both steps are performed, it's a dual-message transaction. If you skip Auth, it's a single-message transaction.
Settlement of funds is a multiparty bank-bank-bank operation, in which merchants are not directly involved.
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.
Correct. In point of fact, payment cards/merchant networks are quite literally just that. You get a credential, and that credential can be revoked if you get up to something sufficiently heinous to warrant the ostracizing.
People would be surprised if they really took the time to learn how much of life is just operating on good graces.
I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.
I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.
>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.
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.
> 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
You can charge more than the displayed value. But that's pretty much it.
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.
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.
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.
About 15 years ago I remember paying for fast food delivery where the delivery guy put your card under the carbon paper bill and just rubbed a pen sideways back and forth over it a few times
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.
> Also, most airlines that take payments on board also run the terminals in offline mode.
Anecdotal, but most airliners I have recently flown with seem to have switched to online POS terminals, though they do still seem retain offline payment functionality as a fallback. I've seen payments being made, only for the flight attendant to return back to the passenger a few minutes later to inform that the payment was declined. This was over the ocean, so definitely no ground communication.
Airplanes for commercial flight all have VHF/HF or satellite connectivity, the've had that for a long time already. It's used for functionality like ACARS, voice connectivity, remote monitoring / diagnosis, etc. I can imagine this can also be used for payments and other low-bandwidth functionality.
Most airplanes also have WiFi access points on board, even when not offered to passengers. Typically these use hidden SSIDs. Speaking to an airplane tech once I know these are used for flight-crew handheld devices such as the POS terminals and iPads.
I happen to have a few friends that are pilots (all working for the same company) and they told me that their entire fleet already has Starlink terminals retrofitted, though they aren't offering that to passengers yet.
I guess what I'm trying to convey here is: the era of airplanes being 'offline' is already behind us.
> 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.
Wait wait wait... Aren't these EMV cards smart cards using the Java smart card technology? I thought these were heavily using encryption, including PKCS.
They're using challenge/response protected by the PIN no!? If I am not mistaken if you insert a card in a totally compromised reader you cannot clone the card: that alone is already quite an amazing feature compared to where we're coming from with the magnetic stripes ones (and the date to sunset for good magnetic stripes in the EU has already been set IIRC).
A fully compromised reader could trick you in stealing your PIN (so that an accomplice could then later on steal the card physically) and a compromised reader could also trick you into signing a 2 EUR transaction while it's actually wiring 2 000 EUR out of your account but I think that's about it!?
It comes to this: either the card can be cloned from a compromised reader or it cannot. I don't think that someone inserting it's card and getting its PIN intercepted means: "Bad guy can do countless transactions for days on until the account is empty".
If I'm right, that's a very far cry from "protection comes from the contracts and regulations between the shops and the bank".
AIUI a compromised reader can fake one big transaction or maybe a few transaction in quick succession but as soon as the owner pulls its card, they cannot do anything anymore?
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.
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.
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.
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.
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).
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.
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.
> 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?
> 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
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.
It does look like the EMV contact standard allows for falling back to SDA operation, which involves the card just handing over the static application data, which doesn't ever change and can be cloned fairly easily onto a fake card. I don't know if it's the same data as is encoded in the magnetic stripe, but it's not much better. A hacked card reader might be able to exploit this by pretending to only support SDA. On the other hand, cards can mitigate this by not supporting SDA.
Banks can mitigate most of the effect of this by putting all risk on the merchant if they accept SDA transactions, and then letting the merchant make the choice.
Someone gets their static data skimmed and the card misused? The issuer profits from the chargeback fees...
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.
I've never seen vouchers or loyalty cards handled on payment terminals here in the Netherlands, they always just have a regular bar code that the cashier scans (or that you scan yourself, at a self-checkout).
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.
> 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.
Which makes a hacked terminal problematic since it can display $1.00 as the amount and actually request the CC HSM to sign a $500 transaction.
In a more safe world, the CC HSM would have it's own display and pin entry, to avoid this exact issue. You really can't validate if the terminal is honest.
Because as you rightly pointed out, who said the evil merchant or MitM thief are either MitM'ing the display system, or even have total control of the display system?
Importantly, though, the credit card system is based around more than just the cryptography involved. By removing the ability to obtain portable payment credentials, the scammer is forced to perform the transaction right then and there. This allows the network to pinpoint the source of the compromise.
A scummy merchant can be banned, a hacked terminal can be removed and examined, etc. And, unlike say a blockchain, a fraudulent transaction can be reversed.
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".
If you take a look at the binary that decides whether to boot the secure firmware or the tamper screen, it's probably trivial to patch to get the secure firmware running for more inspection. If the point of the linux system is networking and updates, that implies a method for updating the firmware of the secure portion which isn't ideal. If their check for whether it's tampered or not is in the linux userland, I'd be awfully suspect of their firmware update.
If the integrity protection is like any of the TPM implementations I've seen, it often doesn't apply once the thing is already in memory, just that when it first loads that it (and everything before it) was attested. This matters a lot once you get into the userland, esp with an older system, since any random off the shelf exploit can be chained into modifying kernel memory with the intention of modifying the binfmt loader for loadercode (or anything else). Of course, if the loadercode is just a thin shim to prod the secure firmware and that's what has the tamper mode rather than being two separate firmwares for controlling the display, you probably can't progress very far.
I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.
Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are.
The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.
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).
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.
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.
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.
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.
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.
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.
And as a user, I have absolutely no way of distinguishing this from a device that had all secure features removed, and is running a random Android that proxies the NFC or chip data to a real reader, siphoning off what they can, while my PIN gets proxied by a human typing it into the real reader in real time. All I'd notice is a second or so of latency.
Do you have a way do make sure that a terminal with physical buttons is secure? To me, the touchscreen doesn't make the whole device inherently less secure.
As far as I understand, the whole system is designed to make replay attacks useless. PIN on its own doesn't allow you to make a transaction, neither does it in combination with a recorded conversation between the reader and the card during a successful transaction. There's some asymmetric cryptography involved with the private key stored in the chip on your card and every signed payload containing a random nonce.
The PIN and magstripe data alone (which I think can be replicated from a one-time read-only interaction with the chip) are enough to make payments in some cases.
If there are sufficiently few legitimate terminal types in circulation and the user is aware of it, anyone presenting a different terminal would be looked at with suspicion. With the status quo, I as the cardholder essentially have to assume that anything presented to me is likely legit, even if it looks like someone's homemade skimmer.
However, this still leaves the merchant. If they (the person handing me the terminal) aren't in on the scam, any tampering has to be non-obvious to them. AFAIK some places go as far as weighing the devices and regularly checking seals and serial numbers. VISA recommends checking twice daily https://busfin.colostate.edu/Forms/Merchant_Svcs/Visa_Securi...
Trying to tamper with a terminal with physical buttons would almost certainly require rewiring it physically, triggering tamper detection and rendering the terminal useless. So it would have to be swapped with a unit that looks identical despite being tampered, and functions well enough to not raise suspicion. I guess an attacker could hollow out a case and insert completely custom electronics, in theory, but that's quite a high bar (especially if it requires forging serialized seals).
On the touch-screen-with-insecure-Android, a software-only change on the insecure side (never actually initiating PIN entry mode, or only initiating it after the first attempt and "pin incorrect" message) should be enough to get the PIN, and an added NFC skimmer not connected to the other electronics could do the rest.
The devices also look cheaply made, distributed in small numbers, and I have my doubts about them having as many anti-tamper features as the most common terminals, although I might be wrong. If they have strong physical anti-tamper measures, and the software is hardened against software-based tampering, I think that they could, in theory, be comparably secure.
Magnetic stripes seem to only still be popular in the US. It always blows my mind just how insecure card payments are there. For small payments, like several dollars, they'll swipe your card in a reader attached to the POS system and that's it. No pin code, no nothing, you just get an SMS that your card was charged several seconds later. For larger payments they'll rely on entirely human-based confirmation methods like "sign the receipt" or "show your ID". I didn't even know this was a thing before I visited the US.
In Russia, where I'm from, I haven't swiped my card for at least a decade. Lately many places also started getting those square Android-based Sberbank terminals that don't even have the magstripe reader, only NFC and chip. Granted, our banking system has been effectively disconnected from most of the world since 2022, but I would be surprised if these aren't designed to accommodate MasterCard and Visa requirements for when they return. And skimmers are simply not a thing here any more. People get scammed through social engineering instead.
I also remember reading that magstripe transactions cost merchants more or something like that, precisely because they carry more risk because they only need static, easily copyable data.
Anyway, the point I'm making is that the threat model changes, and becomes much simpler at that, when transactions can't be made with static data. Because no matter what the scammer captures, even if that's the PIN and the complete data exchange with the card through NFC or the chip reader, they can't use that to make transactions. Obtaining the number, the expiration date, and the CVC is also unlikely to allow them to make online transactions because those need a second factor now. Except on Amazon. Amazon somehow manages to charge my card with just the number and the date, no CVC needed, and no 2fa code either.
Thinking about it a bit more, no, your argument about touchscreens doesn't make sense. The terminal OP looked at runs Linux on the "insecure" side, but the keypad is still passed through to that the same way the touchscreen would be passed through to the Android SoC, because it's used to navigate menus and enter the purchase amount. The Linux side would still send some sort of command to the CPU core that runs the "secure" OS to initiate PIN entry, and it could still just do what you describe.
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.
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!
Reading about all the tamper detection on the device makes me wonder what would be the easiest way to trigger the tamper mode. After all, being able to do that on just a handful of devices would be an efficient denial of service attack on a retail location when the majority - and sometimes all - of payments go through these things.
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.
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.
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.
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.
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.
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!
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.
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.
These are (were?) popular in Finland and confused me a lot every time I visited. The NFC reader in them is on the side, which is very unusual compared to the kinds of terminals I'm used to, which have it in the screen so you just tap your card/phone on the screen.
"17 apr 2004 — GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom."
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?
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.
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.)
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.
1. Under the current EMV standards for terminals, the NFC and/or chip connection is via a secure element that protects the data in the transaction both in transit and at rest.
2. The transaction is protected in transmission not only by TLS encryption, but with an individual HMAC generated using a key that is derived from a base key that is unique to the terminal and merchant.
The interaction with the card is relatively read-only. There is a "dynamic CVV" that is generated on the card in chip/contactless transactions that adds some security, however, the data on the card is mostly open (PAN, expiry date, CC name etc).
The CHI (cardholder information) has to be maintained in an encrypted state at all times.
The business processes (where this article found the root shell) is not involved in the actual card or transaction security. It communicates with the secure element via a protocol that allows it to specify the amount and other details for a transaction, but the authorization (PIN or otherwise) and encrypted messages are entirely within the secure element.
I used to work with set-top-boxes for a big media corporation, those also had the debug serial port. I remember it being fiddly but also absolutely vital to be able to do any useful work with the STB's. It's quite eye opening now reading this to see that they're also a huge potential security hole (in the right hands), unless everything is locked down with the second secure processor like in this setup.
Excellent article. Reminds me of a CCC talk in the early 2000s where an enthusiast checked ATMs of different banks across Germany and most where running unpatched Windows 98 (I think). If my memory is correct it was also very easy to get physical access. I believe removing a couple of normal screws got you to an ethernet port or something similar.
Once he got the root shell on "insecure" processor, that could have been used as an attack point for the secure processor. It would be much more interesting to pwn the secure processor from insecure Linux OS.
Very interesting. These terminals are super common in the Netherlands also. The exact same ones. Kudos to the author, rigging up a BGA chip is no small feat. I love this kind of curiosity (one of the reasons I like HN)
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.
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?
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..."
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.
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.
I once had the (dis)pleasure of working with these Yomani terminals. I got a development unit (with red text "DO NOT PAY" on the side). I plugged it in my home internet which has a public ip with dhcp just to get it quickly online and keep it out of my internal home network. The next day I got a call from my ISP saying I had a compromised machine in my network with malware. I was like WTF?! and they gave me the mac address and it was the Yomani terminal! I promptply unplugged it from the network and started investigating. Indeed, this development unit had a telnet(!) port open and root login without password was possible. So, having a wide open telnet port on a public ip and it's just a matter of minutes until someone uploads a generic arm malware onto it. I returned the terminal to the vendor with explanation but never got a followup. Lesson learned: never attach anything to public internet, even if it looks secure.
I guess Atos Worldline really doesn't like root passwords.
I don’t know much about those terminals, but the screenshot hints at that (key=zeroes part), and then according to the diagram it waits for USB to flash new secure firmware and keys in case the terminal had to be serviced.
This root shell is probably not a security issue - and maybe even meaningfully user-accessible (for some fancier network configurations or diagnostics) - as, I suspect, it’s nothing more than a glorious modem for a stream of encrypted and authenticated data, plus a firmware updater (likely useless without a valid signature) - it could be potentially pretty much the same as hacking the upstream router. Sensitive (so there’s probably a sticker intended) but not something that breaks device’s security.
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!
The term "hacker," even in the computer field, originally had a larger scope than computer security. It had a more philosophical definition, too. I host a copy of the Jargon File[1], compiled by Guy Steele et al., on my web site. It defined "hacker" as[2]:
HACKER [originally, someone who makes furniture with an
axe] n. 1. A person who enjoys learning the details of
programming systems and how to stretch their capabilities,
as opposed to most users who prefer to learn only the
minimum necessary. 2. One who programs enthusiastically,
or who enjoys programming rather than just theorizing
about programming. 3. A person capable of appreciating
hack value (q.v.). 4. A person who is good at programming
quickly. Not everything a hacker produces is a hack. 5. An
expert at a particular program, or one who frequently does
work using it or on it; example: "A SAIL
hacker". (Definitions 1 to 5 are correlated, and people
who fit them congregate.) 6. A malicious or inquisitive
meddler who tries to discover information by poking
around. Hence "password hacker", "network hacker".
I'm guessing that PG had this broader definition in mind when Hacker News was started.
No history of the term "hacker," however brief, would be complete with a reference to The UNIX-HATERS Handbook[3].
> The term "hacker," even in the computer field, originally had a larger scope than computer security.
I've been helping run a Hackspace for a few years; I can't tell you how many times (sometimes per week or even day depending on what I'm doing) I have to have this conversation.
I've gotten quite used to going through the patter with non-tech people - try dealing with the local council, or applying for insurance or even personal jobs when it's on your CV. Thankfully a lot of the older people remember the term "hack" meaning "amateur" which eases explanations in a workshop context.
I always assumed IT people would realise the non-negative connotations, but that really isn't the case.
In the late 80s/early 90s hacker became much less someone doing coding stuff for fun and much more someone trying to break into systems. The main mailing list for TeX related stuff, for example was called TeXHaX and no one assumed people were trying to use TeX to break into the NSA. Similarly, the online space for Perl folks was Perl Hackers (although I see that putting “Perl Hackers” into Google mostly gives results about using Perl as a hacking in the sense of breaking into systems sense and less the programming for the joy of it).
Another word whose change in meaning over the years has resulted in its original sense being effectively erased.
Knowing of the non-negative case does not necessarily mean that we refuse to acknowledge that languages evolve and terms gain new meanings and lose old ones.
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....
Thanks for the reply! The extension seems great at first but it doesn't let me filter out tags and basically just redirects me to your domain, so it's not really how I expect an extension to behave.
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.
Because the language of the week changes often, and learning can be done by solving the problems of today instead of rewriting software into a version that will never be used. I mean... who still uses all the rewrites to ruby?
Even emacs was rewritten to rust ( https://github.com/remacs/remacs ), many hours were spent, and the last actual code commit was 5 years ago.... why not spend that time by making the "normal" emacs better? Or make something new in rust?
Well, it's actually just a hardcoded slideshow of E1M1 while something vaguely approximating the main riff of At Doom's Gate plays inconsistently in the background, but you'll have to watch all 15 excruciating minutes of this poorly-narrated Youtube video I'm linking to figure that out.
I ported DOOM to it. In 100 LOC. BTW it's just a a line shooting a ball of zero width, at another line. And there's some movement left and right. But not forward, nor backwards. So there's no real strafing. And the other line doesn't shoot a ball of zero width back.
I started reading hackernews from very old posts to new ones, so i'm still rewriting stuff to ruby, because that will definitely be the universal programming language for the future!
Given that this website comes from a VC startup incubator I highly doubt it’s meant to refer to hacking security.
I think it’s meant to mean the “move fast and break things” style hacking. Which basically means churning out code fast and pushing through problems quickly instead of getting stuck on perfectionism.
> 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!
That's the kind of thing a lot of guys in suits would take very seriously. After all you have to connect it to the banking network to see if it works as normal. Not advised.
It could also lead to lowlife types putting pressure on you to help them do that. Not the kind of thing to brag about.
> For the young players: this is what hacker in “Hacker News” stands for.
No, it is not, though there is a connection. As it happens, the founder of Hacker News wrote a very inspiring essay shortly before setting up the site on what the word "hacker" means to him, and it's not breaking into computers: https://www.paulgraham.com/gba.html
> To the popular press, "hacker" means someone who breaks into computers. Among programmers it means a good programmer. But the two meanings are connected. To programmers, "hacker" connotes mastery in the most literal sense: someone who can make a computer do what he wants—whether the computer wants to or not.
> To add to the confusion, the noun "hack" also has two senses. It can be either a compliment or an insult. It's called a hack when you do something in an ugly way. But when you do something so clever that you somehow beat the system, that's also called a hack. The word is used more often in the former than the latter sense, probably because ugly solutions are more common than brilliant ones.
...
He goes on to explain in detail how he thinks about the connections between the different senses of the word.
Because it requires no mastery or indeed any special level of ability, finding a passwordless root shell on an exposed serial port does not rise to the level of being a hack in this sense, only in the popular-press sense.
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.
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.
> 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.
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…
> 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?
> 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).
How does the binary signing work?
I’m not looking to hack anything, but it sounds cool to have signed binaries only on linux!!
Varies from vendor to vendor; signed-binaries-only is part of the certification process but the exact mechanism itself is not (or maybe that has changed, not sure).
The way it worked in 2003 (when I first wrote EMV applications) was, when we have a binary that we are ready to deploy, we ship that binary to the manufacturer (Schlumbeger(sp?), at that time), if it passes cert-testing, they sign it and ship it back and that's what we would program the terminals with.
The way it works now is pretty much the same - we build an APK bundle, send it to the manufacturer (Verifone, Pax, etc) and after signing they make it available on their appstore which their terminal can access.
Varies from manufacturer to manufacturer. This is Ingenico's approach, for instance: https://ingenico.com/en/products-services/services/security-...
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.
ah good to know, I wanted that feature back in 2018 :-)
> Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.
Probably different vendors but this has not been my experience.
Have you considered using dm-verity instead of signed binaries?
> Have you considered using dm-verity instead of signed binaries?
Why? I don't see any benefits.
In any case, the developers don't get a say in what is used to secure the terminal. The manufacturer decides that, then they get the hardware+firmware certified.
The terminals the developers get are already certified and locked down.
Authenticating the block device before it reaches the Linux kernel filesystem code.
If I buy a device it sure as shit better give me root.
If a payment system is relying on my local privilige on some random-ass device to authenticate a payment it deserves every garbage request it gets.
In many cases you are not buying these devices, you are only renting them.
> If a payment system is relying on my local privilige on some random-ass device to authenticate a payment
What makes you think it does?
> If I buy a device it sure as shit better give me root
how's that been working out in practice? change the ring tone on your washing machine, dryer, and microwave already?
Those are all mechanical. I could if I fancied, but they're inoffensive and I have more pressing calls for my attention.
I didn't even know there were mechanical microwaves.
Never seen the ones with a mechanical egg timer as the time control? Those usually even have a mechanical bell.
Of course the microwave generator itself is not mechanical :)
> 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.
I did somehow have two different cards (an Amex and a Visa) compromised at the same time about two months ago, and I do wonder if it was some kind of skimmer setup - if it was just one of them then I'd assume it was just some online store I'd used it at that had been hacked, but I've not used both those cards on the same sites.
I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!
Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.
The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.
But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...
Depending on how reputable the hotel was, it's possible they were in on it and the guests weren't real.
Maybe they wanted you to call the police, because the money was taken from your account fraudulently.
The hotel refunded the pending transaction, so they are the party that suffered the financial loss. If they hadn't done that, then the credit card company would have done a charge-back on the disputed transaction and made me whole, and I wouldn't have suffered a loss in that case either. The first question the police forms for reporting fraud or cybercrime are "how much have you lost" - they don't care if it's 'nothing'.
It's the hotel that has to clean the room, has lost consumables, and has lost revenue from it not being available to be booked...
Well, the issue is that you need a merchant account to send the money to, and it's quite hard to get one without identifying yourself, and it takes a bit of time after the transaction to actually get the money because of chargebacks and the like. So you can't just pull the money out directly. But that's true of basically any credit card fraud: what you do instead is buy something from someone who takes credit cards. Which is entirely possible with contactless, you can e.g. proxy a connection from a reader to a victim card, it's just that the limits and difficulty of lining up the time of the transaction with someone walking past make it not particularly useful (compared to just stealing or skimming the card details).
Didn't people manage to present a remote card (i.e. in a mark's pocket) to a legitimate terminal through an NFC tunnel of sorts? Limited to no pin required amounts, but still.
I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.
At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.
> 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.
> 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...
There's a huge difference between me using your credit card to buy stuff off Amazon (chance of success: somewhere between "doubtful" and "near-definite" depending mostly on geographical factors and your particular bank), and me walking around with a hacked card reader and stealing money out of your account by dialing in phony transactions directed to my account (chance of success: somewhere between "zero" and "also zero, but with a decimal point followed by more zeroes").
Aren't the contracts and regulations holding back the honest people only? But not those who violate contracts and regulations, like the dishonest ones?
> 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.
> 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
Yeah it's definitely an arms race. Interestingly, technology in the States lags behind the rest of the world. Every other country has moved on to chip and PIN, 2FA, obe time tokens and asymmetric cryptography. Whereas in the US, one can still find 3DES signatures and unencrypted authorization codes usable for a time duration (read: multiple transactions).
It seems that the banks here are okay with a certain percentage of shrinkage as long as merchants don't have to upgrade and consumers are not inconvenienced. The banks prefer to eat the cost to maintain large fraud and dispute resolution departments. Whereas elsewhere in the world they're much smaller and mainly focused on correspondent banking. It's really interesting to see that the "customer is always right" policy has such a strong influence on the financial sector.
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.)
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.
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.
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.
Credit card companies eat the cost of fraudulent charges that they can not pass on to/blame the merchant for.
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.
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.
> 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.
Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.
> 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.
Yeah, ideally you'd need a valid merchant id, pos id and a way to siphon from the other merchant.
Probably not worth the small amounts you could make before caught
Arbitrary account, no. An arbitrary merchant, yes.
That typically doesn't even need root access though but only a numeric PIN. Of course rout access might let you conceal what you are doing better.
You should read up on the wonderful system they call ACH.
That’s precisely why credit card readers aren’t attached to it
> 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.
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.
I was victim on this attack in Argentina. Paid a taxi with my card, and got charged 50x the amount shown on the display.
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.
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.
Yes, occasionally when refueling a shared car owned by a company that distributes those cars all over The Netherlands. It's common here in leased car fleets as well, where the user gets a magstripe card to refuel (and needs to provide details about current mileage and if the car was a replacement car).
I used it recently because my bank denied the contactless and chip payments I tried before that. Surprisingly the mag stripe worked - and this is with card issues from a EU bank where mag stripes have been an historical artifact much longer than in the US.
2 times just this week I was asked to swipe, “issues with the chip reader” (CVS and Wegmans)
USA was very late to adopt chip/tap terminals, even relative to Canada. I could be wrong but IIRC it was only when Apple Pay came along that tap-enabled terminals began to hit critical mass.
It's always incredible to see few people in the US uses the tech that's available until Apple makes it a thing, and seeing that play out over and over.
This is the same everywhere though. See, e.g. incredibly late fibre rollout in many well off EU countries because they already had copper in the ground everywhere vs. developing countries that never had that legacy infrastructure inertia.
What I'm talking about is a lot of those terminals supported tap to pay well before Apple Pay became a thing. The infrastructure was there, the technology was there, you could use it if you cared to do so. Most people just didn't know it was even an option. Google Wallet supported tap to pay years before Apple Pay was even announced. Tap to pay credit cards existed years before then. Nobody gave a shit about the technology until Apple announced Apple Pay and suddenly it became a big deal for vendors to actually check if their POS systems had it enabled or not.
I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.
Nobody cared until Apple did it.
Seems surprising to me. I've not swiped a UK card in many years. Honestly can't remember the last time.
It's curious you're seeing so many stripe fallback incidents. Is this a USA issue?
possibly, can’t recall having any issues in europe where I reside over the summer.
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
In the USA, gas station pay-at-the-pump were the last major holdouts, but it’s been a while since I saw a pump that didn’t use chip or tap to pay.
My HSA debit card, issued last year, still doesn’t have a chip.
Old automatic vending machines and old municipal parking meters still require swipes.
In some regions, credit/debit cards no longer have magnetic strips.
If I travel to the USA I'll be unable to use these old vending machines and parking meters.
> 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.
Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).
And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.
Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.
... such as this one: https://www.paxtechnology.com/a77
“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.
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.
> 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.
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.
> 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.
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
There are much easier ways to skim cards than hacking the terminal.
Not without leaving physical evidence.
How exactly are you going to get the diversified IPEK to generate the necessary keys to create the HMAC for the transaction that will be authorized by your merchant acquirer?
The BDK for your merchant acquirer is held by them in an HSM or equivalent. The IPEK is device specific, derived from the BDK based on the terminal ID.
The individual keys for the HMAC are generated for each transaction and are cryptographically linked to a transaction ID and the IPEK, so that the acquirer can determine whether there are missing messages.
Card readers that comply with the latest EMV chip/contactless standards require a secure element that maintains the crypto information and only allows specific requests from the non-secure element and only provides encrypted blobs for transmission between the acquirer backend and the secure element.
https://en.wikipedia.org/wiki/Derived_unique_key_per_transac...
> 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 ?
I believe GP is confused.
You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.
Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.
But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).
These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.
I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.
The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.
Wouldn't the concern being redirecting the money to a different merchant account? Of course that would mean you are easily tracked down when found out but I'm sure you can find a way that some schmuck who doesn't actually know anything about you ends up with that role.
Then again, changing the merchant account is usually only protected by a numerical PIN so you wouldn't need root access. Maybe it would be to send the original requested amount to the expected merchant account but also do a separate smaller transaction to your own account?
The configuration of the settlement bank account happens at the processor. If you want to change it, you need to talk to customer service and fill out a PDF form, with signatures and other human verification processes.
If it were possible to change the settlement account via an online portal or similar, then you'd need the user login credentials for that portal. In which case, compromising the card reader has no additional value.
this is all true, but if you've compromised a merchant deeply, it doesn't seems impossible to run a $1 charge as a (bad) customer and then give that customer (you) a, say, $1,000 refund.
You can only void existing transactions, so the money would be returned to the same card, and the amount would be limited to the originally captured amount.
It is possible to create a "push" transaction too of course. Visa Direct, Mastercard MoneySend, etc. But that requires a separate merchant account, and should not be possible from the card reader or POS.
If you've compromised deeply enough to be in the AP system, you can create arbitrary payments, but that's well out of scope for this thread.
> if you've compromised a merchant deeply
Then you could just complete a normal transaction on their website and introduce your account in to their system that way, no real need for a compromised terminal?
> 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
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.
This terminology is not quite right for the US. I'm assuming you're from elsewhere due to the "s" in authorization. :)
In the US, the two steps for the merchant are Authorize (optional) and Capture. If both steps are performed, it's a dual-message transaction. If you skip Auth, it's a single-message transaction.
Settlement of funds is a multiparty bank-bank-bank operation, in which merchants are not directly involved.
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.
Correct. In point of fact, payment cards/merchant networks are quite literally just that. You get a credential, and that credential can be revoked if you get up to something sufficiently heinous to warrant the ostracizing.
People would be surprised if they really took the time to learn how much of life is just operating on good graces.
I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.
I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.
>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.
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.
> 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
You can charge more than the displayed value. But that's pretty much it.
What if you live in a country where Visa/Mastercard works but is way out of the jurisdiction of the feds?
I thought most POS devices stop accepting "offline" payments.
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.
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.
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.
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
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.
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
About 15 years ago I remember paying for fast food delivery where the delivery guy put your card under the carbon paper bill and just rubbed a pen sideways back and forth over it a few times
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.
> Also, most airlines that take payments on board also run the terminals in offline mode.
Anecdotal, but most airliners I have recently flown with seem to have switched to online POS terminals, though they do still seem retain offline payment functionality as a fallback. I've seen payments being made, only for the flight attendant to return back to the passenger a few minutes later to inform that the payment was declined. This was over the ocean, so definitely no ground communication.
Airplanes for commercial flight all have VHF/HF or satellite connectivity, the've had that for a long time already. It's used for functionality like ACARS, voice connectivity, remote monitoring / diagnosis, etc. I can imagine this can also be used for payments and other low-bandwidth functionality.
Most airplanes also have WiFi access points on board, even when not offered to passengers. Typically these use hidden SSIDs. Speaking to an airplane tech once I know these are used for flight-crew handheld devices such as the POS terminals and iPads.
I happen to have a few friends that are pilots (all working for the same company) and they told me that their entire fleet already has Starlink terminals retrofitted, though they aren't offering that to passengers yet.
I guess what I'm trying to convey here is: the era of airplanes being 'offline' is already behind us.
United Airlines requires credit cards to be linked to their app before takeoff. I assume this lets them run an authorization test charge to identify bad cards. https://www.united.com/en/us/fly/travel/inflight/save-a-form...
Passenger WiFi is already not that rare, all that is missing now is for prices to come down to reasonable levels.
> 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.
Wait wait wait... Aren't these EMV cards smart cards using the Java smart card technology? I thought these were heavily using encryption, including PKCS.
They're using challenge/response protected by the PIN no!? If I am not mistaken if you insert a card in a totally compromised reader you cannot clone the card: that alone is already quite an amazing feature compared to where we're coming from with the magnetic stripes ones (and the date to sunset for good magnetic stripes in the EU has already been set IIRC).
A fully compromised reader could trick you in stealing your PIN (so that an accomplice could then later on steal the card physically) and a compromised reader could also trick you into signing a 2 EUR transaction while it's actually wiring 2 000 EUR out of your account but I think that's about it!?
It comes to this: either the card can be cloned from a compromised reader or it cannot. I don't think that someone inserting it's card and getting its PIN intercepted means: "Bad guy can do countless transactions for days on until the account is empty".
If I'm right, that's a very far cry from "protection comes from the contracts and regulations between the shops and the bank".
AIUI a compromised reader can fake one big transaction or maybe a few transaction in quick succession but as soon as the owner pulls its card, they cannot do anything anymore?
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.
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.
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.
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.
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).
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.
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...
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.
wtf? are you saying the shell can be hypothetically drilled for root access without triggering the tamper detection? that'll be ACTUALLY bad...
I think in the article it was even stated that the port is even accessible without drilling!
> 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?
Pretend that I have to pay to watch TV at home? I don't know, sounded fun to me in my head
Plus I meant for the manufacturer to "repair" it. Maybe tamperproof gets triggered if you accidentally drop the device in an unfortunate way
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.
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.
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.
> […] 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...
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.
Magstripes will start going away in 2027 and should be gone by 2029.
I got impression that the chips used to contain the magstripe info, but I hope they removed that when rollout got going.
Already, merchants take on liability for magstripe transactions.
It does look like the EMV contact standard allows for falling back to SDA operation, which involves the card just handing over the static application data, which doesn't ever change and can be cloned fairly easily onto a fake card. I don't know if it's the same data as is encoded in the magnetic stripe, but it's not much better. A hacked card reader might be able to exploit this by pretending to only support SDA. On the other hand, cards can mitigate this by not supporting SDA.
Banks can mitigate most of the effect of this by putting all risk on the merchant if they accept SDA transactions, and then letting the merchant make the choice.
Someone gets their static data skimmed and the card misused? The issuer profits from the chargeback fees...
It was 2006 in the UK when chip and pin came in. Amazing these things are still in the wild.
It was introduced in 2004, and made mandatory in 2006.
France was using chip cards since 1992, although with the previous standard.
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.
I've never seen vouchers or loyalty cards handled on payment terminals here in the Netherlands, they always just have a regular bar code that the cashier scans (or that you scan yourself, at a self-checkout).
Refunds work with chip insertion or contactless.
> 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?
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.
> 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.
Which makes a hacked terminal problematic since it can display $1.00 as the amount and actually request the CC HSM to sign a $500 transaction.
In a more safe world, the CC HSM would have it's own display and pin entry, to avoid this exact issue. You really can't validate if the terminal is honest.
Because as you rightly pointed out, who said the evil merchant or MitM thief are either MitM'ing the display system, or even have total control of the display system?
Importantly, though, the credit card system is based around more than just the cryptography involved. By removing the ability to obtain portable payment credentials, the scammer is forced to perform the transaction right then and there. This allows the network to pinpoint the source of the compromise.
A scummy merchant can be banned, a hacked terminal can be removed and examined, etc. And, unlike say a blockchain, a fraudulent transaction can be reversed.
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".
If you take a look at the binary that decides whether to boot the secure firmware or the tamper screen, it's probably trivial to patch to get the secure firmware running for more inspection. If the point of the linux system is networking and updates, that implies a method for updating the firmware of the secure portion which isn't ideal. If their check for whether it's tampered or not is in the linux userland, I'd be awfully suspect of their firmware update.
The binary that decides whether to boot or go into tamper mode is the "loadercode", which is integrity-protected (I think by a Boot ROM or similar).
The secure firmware can be updated, but it is signed as well.
If the integrity protection is like any of the TPM implementations I've seen, it often doesn't apply once the thing is already in memory, just that when it first loads that it (and everything before it) was attested. This matters a lot once you get into the userland, esp with an older system, since any random off the shelf exploit can be chained into modifying kernel memory with the intention of modifying the binfmt loader for loadercode (or anything else). Of course, if the loadercode is just a thin shim to prod the secure firmware and that's what has the tamper mode rather than being two separate firmwares for controlling the display, you probably can't progress very far.
I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.
Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are. The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.
These are all over the Netherlands, this particular model. They don't accept any credit cards, only debit.
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).
And Belgium. I paid this afternoon in a supermarket with this model.
Read the article. The actual work is done by another processor that only runs signed images.
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.
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.
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.
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.
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.
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.
And as a user, I have absolutely no way of distinguishing this from a device that had all secure features removed, and is running a random Android that proxies the NFC or chip data to a real reader, siphoning off what they can, while my PIN gets proxied by a human typing it into the real reader in real time. All I'd notice is a second or so of latency.
Do you have a way do make sure that a terminal with physical buttons is secure? To me, the touchscreen doesn't make the whole device inherently less secure.
As far as I understand, the whole system is designed to make replay attacks useless. PIN on its own doesn't allow you to make a transaction, neither does it in combination with a recorded conversation between the reader and the card during a successful transaction. There's some asymmetric cryptography involved with the private key stored in the chip on your card and every signed payload containing a random nonce.
The PIN and magstripe data alone (which I think can be replicated from a one-time read-only interaction with the chip) are enough to make payments in some cases.
If there are sufficiently few legitimate terminal types in circulation and the user is aware of it, anyone presenting a different terminal would be looked at with suspicion. With the status quo, I as the cardholder essentially have to assume that anything presented to me is likely legit, even if it looks like someone's homemade skimmer.
However, this still leaves the merchant. If they (the person handing me the terminal) aren't in on the scam, any tampering has to be non-obvious to them. AFAIK some places go as far as weighing the devices and regularly checking seals and serial numbers. VISA recommends checking twice daily https://busfin.colostate.edu/Forms/Merchant_Svcs/Visa_Securi...
Trying to tamper with a terminal with physical buttons would almost certainly require rewiring it physically, triggering tamper detection and rendering the terminal useless. So it would have to be swapped with a unit that looks identical despite being tampered, and functions well enough to not raise suspicion. I guess an attacker could hollow out a case and insert completely custom electronics, in theory, but that's quite a high bar (especially if it requires forging serialized seals).
On the touch-screen-with-insecure-Android, a software-only change on the insecure side (never actually initiating PIN entry mode, or only initiating it after the first attempt and "pin incorrect" message) should be enough to get the PIN, and an added NFC skimmer not connected to the other electronics could do the rest.
The devices also look cheaply made, distributed in small numbers, and I have my doubts about them having as many anti-tamper features as the most common terminals, although I might be wrong. If they have strong physical anti-tamper measures, and the software is hardened against software-based tampering, I think that they could, in theory, be comparably secure.
Magnetic stripes seem to only still be popular in the US. It always blows my mind just how insecure card payments are there. For small payments, like several dollars, they'll swipe your card in a reader attached to the POS system and that's it. No pin code, no nothing, you just get an SMS that your card was charged several seconds later. For larger payments they'll rely on entirely human-based confirmation methods like "sign the receipt" or "show your ID". I didn't even know this was a thing before I visited the US.
In Russia, where I'm from, I haven't swiped my card for at least a decade. Lately many places also started getting those square Android-based Sberbank terminals that don't even have the magstripe reader, only NFC and chip. Granted, our banking system has been effectively disconnected from most of the world since 2022, but I would be surprised if these aren't designed to accommodate MasterCard and Visa requirements for when they return. And skimmers are simply not a thing here any more. People get scammed through social engineering instead.
I also remember reading that magstripe transactions cost merchants more or something like that, precisely because they carry more risk because they only need static, easily copyable data.
Anyway, the point I'm making is that the threat model changes, and becomes much simpler at that, when transactions can't be made with static data. Because no matter what the scammer captures, even if that's the PIN and the complete data exchange with the card through NFC or the chip reader, they can't use that to make transactions. Obtaining the number, the expiration date, and the CVC is also unlikely to allow them to make online transactions because those need a second factor now. Except on Amazon. Amazon somehow manages to charge my card with just the number and the date, no CVC needed, and no 2fa code either.
Thinking about it a bit more, no, your argument about touchscreens doesn't make sense. The terminal OP looked at runs Linux on the "insecure" side, but the keypad is still passed through to that the same way the touchscreen would be passed through to the Android SoC, because it's used to navigate menus and enter the purchase amount. The Linux side would still send some sort of command to the CPU core that runs the "secure" OS to initiate PIN entry, and it could still just do what you describe.
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.
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.
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!
Also, it is possible to open other apps and the notification centre. And unsurprisingly the entire device is terribly laggy.
Reading about all the tamper detection on the device makes me wonder what would be the easiest way to trigger the tamper mode. After all, being able to do that on just a handful of devices would be an efficient denial of service attack on a retail location when the majority - and sometimes all - of payments go through these things.
Dropping it on the floor or pouring water on it.
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.
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.
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.
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.
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.
Specifics of this hack aside, I wish I could solder like that!
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!
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.
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.
These are (were?) popular in Finland and confused me a lot every time I visited. The NFC reader in them is on the side, which is very unusual compared to the kinds of terminals I'm used to, which have it in the screen so you just tap your card/phone on the screen.
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?
Yes, 0.1 mm diameter enameled copper wire. Chasing GPL violations sounds like a fun hobby :)
I think US based SFLC has budgets if you request it to enforce the GPL.
Pre-OpenWRT days I was maintained a Linux distro ISL3893 that ended up in court in Germany, the first GPL enforcement:
http://isl3893.wikidot.com/
"17 apr 2004 — GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom."
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?
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.
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.)
Reminds me of "Every 10-ft wall can be defeated with an 11-ft ladder"
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.
So a few things:
1. Under the current EMV standards for terminals, the NFC and/or chip connection is via a secure element that protects the data in the transaction both in transit and at rest.
2. The transaction is protected in transmission not only by TLS encryption, but with an individual HMAC generated using a key that is derived from a base key that is unique to the terminal and merchant.
The interaction with the card is relatively read-only. There is a "dynamic CVV" that is generated on the card in chip/contactless transactions that adds some security, however, the data on the card is mostly open (PAN, expiry date, CC name etc).
The CHI (cardholder information) has to be maintained in an encrypted state at all times.
The business processes (where this article found the root shell) is not involved in the actual card or transaction security. It communicates with the secure element via a protocol that allows it to specify the amount and other details for a transaction, but the authorization (PIN or otherwise) and encrypted messages are entirely within the secure element.
I used to work with set-top-boxes for a big media corporation, those also had the debug serial port. I remember it being fiddly but also absolutely vital to be able to do any useful work with the STB's. It's quite eye opening now reading this to see that they're also a huge potential security hole (in the right hands), unless everything is locked down with the second secure processor like in this setup.
Excellent article. Reminds me of a CCC talk in the early 2000s where an enthusiast checked ATMs of different banks across Germany and most where running unpatched Windows 98 (I think). If my memory is correct it was also very easy to get physical access. I believe removing a couple of normal screws got you to an ethernet port or something similar.
Once he got the root shell on "insecure" processor, that could have been used as an attack point for the secure processor. It would be much more interesting to pwn the secure processor from insecure Linux OS.
Very interesting. These terminals are super common in the Netherlands also. The exact same ones. Kudos to the author, rigging up a BGA chip is no small feat. I love this kind of curiosity (one of the reasons I like HN)
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.
Great story, how long did this take you?
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?
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/
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.
> 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.
Can it run doom?
> Can it run doom?
Almost certainly yes.
I expect an updated post with it running doom as the author is not strange to it: https://stefan-gloor.ch/voip-phone-hack
It sounds like the Linux system he got access to doesn't control the screen though so this might not be that easy.
I once had the (dis)pleasure of working with these Yomani terminals. I got a development unit (with red text "DO NOT PAY" on the side). I plugged it in my home internet which has a public ip with dhcp just to get it quickly online and keep it out of my internal home network. The next day I got a call from my ISP saying I had a compromised machine in my network with malware. I was like WTF?! and they gave me the mac address and it was the Yomani terminal! I promptply unplugged it from the network and started investigating. Indeed, this development unit had a telnet(!) port open and root login without password was possible. So, having a wide open telnet port on a public ip and it's just a matter of minutes until someone uploads a generic arm malware onto it. I returned the terminal to the vendor with explanation but never got a followup. Lesson learned: never attach anything to public internet, even if it looks secure.
I guess Atos Worldline really doesn't like root passwords.
Very interesting!
UART always the first place I look…
My thoughts exactly. Why desolder the flash chip before probing for UART? Still, impressive work.
Thanks! Yep, I feel foolish. I just could not imagine it would be that easy on a locked-down terminal. But I learned for next time :)
Alright sorry if this is dumb but how does the OP know about all this?
Any way to reset the tamper protection from software?
Hopefully the important private keys that is used to identify the terminal are erased when the tamper is activated.
I don’t know much about those terminals, but the screenshot hints at that (key=zeroes part), and then according to the diagram it waits for USB to flash new secure firmware and keys in case the terminal had to be serviced.
This root shell is probably not a security issue - and maybe even meaningfully user-accessible (for some fancier network configurations or diagnostics) - as, I suspect, it’s nothing more than a glorious modem for a stream of encrypted and authenticated data, plus a firmware updater (likely useless without a valid signature) - it could be potentially pretty much the same as hacking the upstream router. Sensitive (so there’s probably a sticker intended) but not something that breaks device’s security.
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!
The term "hacker," even in the computer field, originally had a larger scope than computer security. It had a more philosophical definition, too. I host a copy of the Jargon File[1], compiled by Guy Steele et al., on my web site. It defined "hacker" as[2]:
I'm guessing that PG had this broader definition in mind when Hacker News was started.No history of the term "hacker," however brief, would be complete with a reference to The UNIX-HATERS Handbook[3].
[1] https://speechcode.com/jargon/
[2] https://speechcode.com/jargon/jargon.info.Hacker.html
[3] https://web.mit.edu/~simsong/www/ugh.pdf
> The term "hacker," even in the computer field, originally had a larger scope than computer security.
I've been helping run a Hackspace for a few years; I can't tell you how many times (sometimes per week or even day depending on what I'm doing) I have to have this conversation.
I've gotten quite used to going through the patter with non-tech people - try dealing with the local council, or applying for insurance or even personal jobs when it's on your CV. Thankfully a lot of the older people remember the term "hack" meaning "amateur" which eases explanations in a workshop context.
I always assumed IT people would realise the non-negative connotations, but that really isn't the case.
In the late 80s/early 90s hacker became much less someone doing coding stuff for fun and much more someone trying to break into systems. The main mailing list for TeX related stuff, for example was called TeXHaX and no one assumed people were trying to use TeX to break into the NSA. Similarly, the online space for Perl folks was Perl Hackers (although I see that putting “Perl Hackers” into Google mostly gives results about using Perl as a hacking in the sense of breaking into systems sense and less the programming for the joy of it).
Another word whose change in meaning over the years has resulted in its original sense being effectively erased.
Knowing of the non-negative case does not necessarily mean that we refuse to acknowledge that languages evolve and terms gain new meanings and lose old ones.
Or as RMS defines it, playful cleverness.
> would be complete with a reference
's/with/without/'
Amen for the first sentence. One more LLM wrapper today, and I would die.
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....
Here it is ;)
https://histre.com/hn/
Oh that's great! I wish it kept the HN style, the contrast and density is too low for me
Thanks. I'll create a HN-like theme.
In the meantime, if you install the browser extension, you can get the tags directly in HN itself. Would that address the ui issue?
Source: https://gitlab.com/histre/hn-tags
Chrome: https://chrome.google.com/webstore/detail/hacker-news-tags/i...
Firefox: https://addons.mozilla.org/en-US/firefox/addon/hacker-news-t...
Thanks for the reply! The extension seems great at first but it doesn't let me filter out tags and basically just redirects me to your domain, so it's not really how I expect an extension to behave.
I see, thanks for the feedback. I'll improve that.
That's awesome! I second the other comment re: density and contrast
Thanks, will do. Please see my cousin comment for a potential workaround.
The HN UI is good because in 20 seconds I can assess the full top page.
If you can figure out how to add the tags while keeping down the visual bloat I would consider a switch.
Thanks, I'll create an HN theme for that page. BTW here's more discussion about this, back when I did a "Show HN" : https://news.ycombinator.com/item?id=35904988
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.
It's either LLM or "<existing software> written in <languge of the week>"
Do you know why people started doing rewrites in other languages?
It's usually to help teach them the other language.
The rewrite part makes it easier for observers to learn and compare/contrast techniques in different environments for themselves.
Why this would ever be criticised, I can't imagine.
Because the language of the week changes often, and learning can be done by solving the problems of today instead of rewriting software into a version that will never be used. I mean... who still uses all the rewrites to ruby?
Even emacs was rewritten to rust ( https://github.com/remacs/remacs ), many hours were spent, and the last actual code commit was 5 years ago.... why not spend that time by making the "normal" emacs better? Or make something new in rust?
I rewrote J in C, or D in F#, or Whogivesafuck in Rust and it's 8% better but don't ask me for my benchmark because it's secret sauce.
And I ported DOOM to it.
Well, it's actually just a hardcoded slideshow of E1M1 while something vaguely approximating the main riff of At Doom's Gate plays inconsistently in the background, but you'll have to watch all 15 excruciating minutes of this poorly-narrated Youtube video I'm linking to figure that out.
I ported DOOM to it. In 100 LOC. BTW it's just a a line shooting a ball of zero width, at another line. And there's some movement left and right. But not forward, nor backwards. So there's no real strafing. And the other line doesn't shoot a ball of zero width back.
But it's the spirit of DOOM!!!
/s
I started reading hackernews from very old posts to new ones, so i'm still rewriting stuff to ruby, because that will definitely be the universal programming language for the future!
"Prompt Kiddie" should be the new "Script Kiddie"
Yeah, this has been LLM News for a while...
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
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.
Almost all YC companies this batch are LLM wrappers
and "Crypto News" for a long time too
And "Why I Left Google" News before that.
Or UI pontifications
It's so tiresome and is slowly ruining HN for me personally.
Hear hear.
Given that this website comes from a VC startup incubator I highly doubt it’s meant to refer to hacking security.
I think it’s meant to mean the “move fast and break things” style hacking. Which basically means churning out code fast and pushing through problems quickly instead of getting stuck on perfectionism.
> 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!
That's the kind of thing a lot of guys in suits would take very seriously. After all you have to connect it to the banking network to see if it works as normal. Not advised.
It could also lead to lowlife types putting pressure on you to help them do that. Not the kind of thing to brag about.
Ps: like the screenshot says the private keys are already gone so there's no way to get it reactivated on the same account.
> For the young players: this is what hacker in “Hacker News” stands for.
No, it is not, though there is a connection. As it happens, the founder of Hacker News wrote a very inspiring essay shortly before setting up the site on what the word "hacker" means to him, and it's not breaking into computers: https://www.paulgraham.com/gba.html
> To the popular press, "hacker" means someone who breaks into computers. Among programmers it means a good programmer. But the two meanings are connected. To programmers, "hacker" connotes mastery in the most literal sense: someone who can make a computer do what he wants—whether the computer wants to or not.
> To add to the confusion, the noun "hack" also has two senses. It can be either a compliment or an insult. It's called a hack when you do something in an ugly way. But when you do something so clever that you somehow beat the system, that's also called a hack. The word is used more often in the former than the latter sense, probably because ugly solutions are more common than brilliant ones.
...
He goes on to explain in detail how he thinks about the connections between the different senses of the word.
Because it requires no mastery or indeed any special level of ability, finding a passwordless root shell on an exposed serial port does not rise to the level of being a hack in this sense, only in the popular-press sense.
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.
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!
"Hacker" news was never about that tho. It came out from SV...