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