In the "Security Patching" comparison between Ubuntu LTS and Ubuntu Pro for the 23,000 Ubuntu Universe packages, they say "Best effort" for Ubuntu LTS v/s "10 years for Ubuntu Pro". This would lead a reasonable person to think "Okay, maybe it's 2-3 years at least for LTS?"
But in the graphic below for Universe, there is no orange section (unlike the 5 year line for Ubuntu Main). Which I think that Ubuntu LTS will now never guarantee any security patches for Universe, even if the distro came out yesterday.
Am I reading this wrong? I hope I am, but it seems to match people's experience.
You're correct. Packages in universe were never marked as supported, and never got any updates. The LTS definition has always been "main"+"restricted".
This feels like somewhere that GPT could actually prove helpful- I don't love GitHub CoPilot all that much, but a linter that could warn and suggest where comments aren't matching the code could be helpful to keep 'comment rot' at bay
If they can do that, why ever have those comments in the first place? Just have CoPilot write the comments for you! It should be easier than having it read the poorly-written comments laden with shitty attempts at dry humor and mistyped abbreviations that most programmers leave around. Just ask CoPilot to explain the code to you. Have it hold your hand and walk you through what a for loop does, if you must. It'll be perfect for those programmers who used Chat GPT to get passing grades in their classes!
As pointed out here, the huge assumption in this article is is:
> If someone installs malware on here - just insert a usb stick or use the recovery mode - then tada we have the next generation of atm skimming.
Which is just not how these payment devices work- they are entirely separate, they are sent a request to make a transaction, that transaction (and also likely the transaction request itself) occur entirely in a secure connection between someone like Verifone, and the device itself.
The PC has has no way to get those card details, only request a transaction and confirm a payment status as successful or failed.
You might not be able skim card details, but you could probably get the terminal to issue unexpected transactions.
The most interesting transaction would be a very large refund. I’ve seen organised crime groups target restaurants in the past to issue themselves £1k+ refunds. They pretend to pay for meal, and while they have the EMV terminal in their hand, they cancel the original transaction, put the device into management mode (using default passwords) and issue themselves a nice large refund.
It’s a complete pain in the arse for the banks receiving these refunds to catch and deal with properly. It’s surprisingly hard to return the money to the restaurant.
That’s pretty funny. Not that the restaurants deserve to be stolen from, but using the default password on an EMV is about as foolish as a restaurant leaving their registers open. I’m surprised the terminals don’t force you to at least set your own passcode.
+1. To add, the modern EMV chip enabled transactions are not at all like magnetic stripe transactions. The chip in the card is not a passive storage but is also a computation device that signs a transaction, generates one time keys etc.,
Of course it is still possible to skim the card number off of magnetic strip and sell it in the darknet. However, the static card number is becoming less and less of a relevant thing now a days as more sites/processors are migrating to dynamic auth such as Apple Pay etc.,
NFC transactions are powered by the EMV chip, and include all the same signing ond one-time-key exchange as a chip-insertion but without the potential for skimming the mag strip
Sniffing the NFC traffic gives the attacker nothing useful, just as skimming an EMV contact transaction gives the attacker nothing useful.
>The contactless EMV chip transaction path leverages the cryptographic functions normally associated with a contact EMV chip transaction and uses the same authorization and settlement fields as a contact chip transaction. [0] [1]
the "server" in this case provides a one-time key to sign the transaction with, which is only valid for that transaction and that merchant. if you have a large antenna that can provide valid transaction keys for a trusted merchant, then yes, you have a significant exploit.
to my knowledge, nobody has ever successfully demonstrated an exploit of this nature.
But if an attacker owns the touchscreen, they can do nefarious things like adding a "Please re-enter your PIN on the touchscreen to confirm your purchase" dialog, then match that PIN against a separate leaked database of card numbers and user identities. It's not just whether the card reader can be pivoted to; it's the entire notion that the kiosk itself carries the trust of the overall brand.
You joke, but if we talk about web applications, one dangerous attack is not to guess the user password, but instead to match the most common passwords to a list of inventoried users...
In 2009 my card had a 6-digit PIN and I went on holiday to Argentina. The card readers there only accepted 4 digits and they validated my card with the first 4 digits of my PIN.
On that subject, I (a European) went to the US last week. It was time to pay at a restaurant in their needlessly complicated way where they hand you the bill, you return them the bill with your card and then they return once more for you to fill out the tip. Shortly after the second step the waiter returned apologizing, saying they could not bypass the PIN on the card like they normally could (which was slightly startling to me) and asked if I could come with them to enter it on the payment terminal myself.
Must have been a debit card that flat out refused anything but Chip & PIN.
Most cards aren't like this.
With my UK issued AmEx & Visa cards (both Charge/Credit), at certain places terminal didn't even ask me for a PIN, and the transaction just went through as "Chip & Signature"
Same experience (card came with default 6-digit pin that I didn't change), never have longer-than-4 pin when traveling outside of western democracies. The fact that it worked made me doubt that it was actually verified, but didn't have balls to play with this too far away from easily obtainable money
Don't be so sure of that.
If your PIN just happens to start with 00, it is fairly trivial to jury-rig a common 4-digit hacking device to crack your 6-digit PIN.
Aren't card PINs only 4 numbers long? That's almost 10k possible combinations I believe, pretty trivial to put together.
Checking which corresponds to what card is the hard step because you need access to an acquirer to my knowledge, and you'll lose that access quiet quickly if you attempt too many incorrect combinations.
I have been wanting to try a 4< digit pin, but I expect payment terminals to go bonkers because they don’t accept it. Have any of you a card pin longer than 4?
It would be a huge amount of work to pull this off and it's something that would be detected within the day because its so odd and not at all how normal payment flows work.
Not clear how you would match the pin either without having some personal info on the user which you don't have.
Exactly. The kiosk app that communicates to the terminal only gets a "transaction approved" response. There is no personal identifiable information provided to the kiosk app so there would be no way to link the pin they typed in the kiosk back to the customer identity or card number.
In short, for the kiosk this is a anonymous transaction that was confirmed paid.
The most you could do is ask for more details in the kiosk app which would be clunky and very suspicious.
You could also tape a piece of paper up with a fake (tech support/tax help/credit help/reverse mortgage) line with a fake McDonald's endorsement in the early hours of the morning and make off with plenty of victims as the senior crowd rolls in for a grand time investment of 60 seconds.
If you want to get creative with attacks you can, but sometimes comparing a creative attack to a "boring" attack can help frame the conversation.
I've written kiosk apps that landed across the US and while there was a ton of hand wringing about security, and in an informal setting I brought up a simple question:
If you reverse engineer the update process to have it show a penis, or you just carve a penis into the public display with a pocket knife, what's the difference and which is more likely to happen?
If an attacker can take control of the update process, they can push a penis-showing (or actually dangerous) update to all the machines in the network. That could be hundreds or thousands! Good luck doing that with a pocket knife.
Also, vandalism is about the least interesting reason to hack kiosks. It can get you into an otherwise inaccessible network, which often contains all sorts of internal services with loose or no authentication (POS software often uses default creds because "it's on an internal netwok anyways"). Hacked kiosks are also often used as proxy servers for illegal activity and bots in DDoS botnets.
Did you read the article? This is about security on-device
The update process can be backed on the kiosk side, hacking the remote side of the update process is a completely different story.
I mean in some cases that was a simple signed package hosted on an S3 bucket... how are you going to leverage that to vandalize a network of devices?
And the kiosks are never on an interesting network (if they were there's dozens of ethernet ports scattered about the place you can use to get access anyways)
Hacked kiosks being used as proxy servers when you need physical access to hack is also a very uninteresting problem. Why risk tying your physical self to a bot for nefarious usage when there are a million and one other "IoT" devices you can pwn instead?
So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm…
> So would it be possible to install software or hardware which always returns a "success" from the card reader hardware without it actually doing the transaction and give everyone who uses that machine free food until someone figures it out? Hmm…
Almost certainly not on EMV certified card acquirers, unless there is a bug in the firmware. These things are so locked down that, even as an authorised developer for the payment terminal, we had no access to the hardware, no way to view the cards encrypted payload, etc.
> Today at another McDonald's I observed the entire bootstrap process and can confirm that the kiosk indeed is responsible for installing “custom firmware” on the card reader
If this part is correct, it seems like an attacker could compromise the reader itself.
I work with POS hardware at my job. The “custom firmware” is likely just some settings, screens for the POS to display (so they’re McD branded instead of the POS maker), and some per payment-processor configuration so the terminals are using the expected encryption (differs per processor and customer).
Even if it was real firmware (I doubt it), it’s likely the firmware for the POS device interface. I don’t believe that firmware has any control over the actual payment processing bits of hardware, just the software intermediary.
Since that intermediary only has access to EMV tags (which anyone in the payment path has) there is no point. The secret encryption stuff that secures passwords is not controlled from any layer an attacker could touch, outside of documented configuration parameters.
Even if it does handle delivering firmware updates to the device, I would be wholly surprised if the terminal doesn't at least do basic checks to make sure the firmware is signed (although, whether or not there are exploits to get around this is another thing).
Those card readers also typically have photodiodes in them and numerous tamper switches pressed to the case to wipe their internal memory if tampered. Just to be clear I'm not talking about EPROM - they have actual photodiodes inside along with physical switches and a coin battery that will wipe the ROM if tampered.
Fascinating! Is there more detail somewhere on this stuff? Its like a bomb squad drama, making a dam for liquid nitrogen to cool the coin cell below the voltage it can detonate the.. I mean clear the rom, opening the case in a dark tent around the device etc.
I know from experience that similar setups tend to have the workstation load the verifone updates, so a package could be inserted, it would take some more insider knowledge.
Also chip cards don’t ever leak the CC number as part of the transaction. However, it seems like you could request a transaction for a different merchant?
Chip cards do send the card number as part of the transaction. They just also send other information that makes it easier to tell if the original card is physically present, meaning you don’t have to worry as much about someone stealing the details and spoofing your card.
You may be thinking of tokenization, which is a feature of some services such as Apple/Google Pay. This is where a “fake” account number—really a number that is scoped to eg a specific device or a specific merchant—is sent with the transaction. That then gets resolved to the real number somewhere down the processing pipeline closer to the card issuer. The benefit being if someone snoops this tokenized account number they won’t be able to use it thanks to the tight scoping.
Are you sure? I thought chip cards worked using certificates signed by the card issuer. And transactions involved sending a nonce to be signed. Everything can be verified by the public key. I could totally be wrong though.
Maybe that's how IC cards work in some places, but that's definitely not the normal EMV standard. I've worked on the implementation of EMV chip card processing through basically all the major networks and can tell you that we necessarily have access to—and have to store after—the raw card number to facilitate the transaction. There's a lot of encryption involved to prevent bad actors from getting access but it's far from end-to-end.
In a correctly configured system, the terminal itself would have to be reconfigured. That can sort of be be done via the POS, but also requires credentials from the group that configured the terminal.
I used to work with those payment gateways, and I always wondered about that attack vector. The terminal config (where you’d put your merchant ID, etc…) is protected by a PIN code, but suppliers typically just use the same PIN for their entire fleet. It’s not really a secret PIN either, because the terminal tech support will usually end up getting merchants to type it in if there‘s some remote support/debugging needed.
You could reprogram a terminal in a bar in a few seconds on a Friday night. Wait for the weekends takings to clear into your merchant account, and then take off with the money. The way that it falls down though, is that you need a merchant account, and there’s a lot of KYC and due diligence to get through if you want to set one of those up (there are a lot of merchant initiated scams, and your bank doesn’t want to be on the hook for them).
> Wait for the weekends takings to clear into your merchant account, and then take off with the money.
That's the difficult part - since the acquiring bank is fully financially responsible if you do so (they'll compensate everyone else involved for the fraud chargebacks, no matter if they can recover it from you), they generally take quite stringent steps to fight merchant-initiated scams, and the simplest step is simply freezing the money for some time; 30 days is not uncommon but I have even seen 90 days if the merchant's profile is risky or if the incoming payment volume suddenly increases significantly - the bank is effectively treating any payments to the merchant as a line of credit or letter of guarantee until it's clear that those payments won't be fraudulent or charged back. So a merchant can quite realistically do some shenanigans with a reprogrammed terminal, but they won't be permitted to take off with a large amount of money from the merchant account until a sufficient amount of time will have passed for the first chargebacks or complaints of fraud to show up.
I don’t know about every jurisdiction, but every place that I’ve ever been involved with payment terminals, the money clears to the merchant account in a couple of business days. So your weekend’s takings would usually be cleared by Tuesday. I can’t imagine any retail or hospitality business would be able to extend a 90 day line of credit to their payment processor on all payment card revenue.
I think the main reason this never happens is because there’s a lot of easier and more profitable scams you can operate as a fraud-oriented merchant.
I would expect there to be a difference between a first time and a repeat thing. If you do out-of-normal-operation things, the bank will treat you more suspiciously, if you do your normal business, it can release your money immediately
I built the first online payment system for my university' frosh week in the early 2000's (before that they only accepted cash). This is pre-shopify/etc, and if you were doing any moderate volume it was worthwhile to use a gateway that went direct to your own merchant account.
They started accepting signups a couple weeks before school started, and on the second day it was running, after several hundred signups (of ~$200 each iirc), apparently some security people from the bank showed up at the orientation office at the school basically just to confirm it was legit. (I don't remember if they suspended the account first or not)
I had built a few online store sites using merchant accounts by then, but nothing that went from zero to that volume so quickly; it was fascinating to see that check in action.
I wonder what volume it would take to trigger such scrutiny today, and what it would look like..
Different merchant underwriters have different processes. Visiting merchant locations was pretty common, usually just to check if it looks like a real operating business though.
> they'll compensate everyone else involved for the fraud chargebacks,
But in this hypothetical would there be chargebacks? People went to a bar. They consumed, and paid for it. As far as the costumers know it went all good.
The one who is harmed would be the pub. And presumably they would complain and soon.
I don’t doubt that the whole scheme would come to light quick, i’m just questioning the exact mechanism.
Presuming the attack wasn’t initially detected, which is entirely plausible imo, it would be noticed by the merchant when the funds didn’t settle into their account. So if you do it on Friday, the merchant should notice by Tuesday at the latest. If they don’t pay close attention to their accounts, it might take a little longer.
Don’t payment gateway request an initialization procedure that registers the POS with the remote gateway ?
During that procedure the terminal unique ID is sent, and depending on your environment, if you have a stable outgoing IP the connection might be filtered on that as well (assuming you do that on site, not at a POS provider). Jumping through a bunch of hoops you might still be able to hook a POS on another merchant account, but once the issue is detected there would be enough info to reverse the transactions (doing that after capture could cost fees, but it’s still better than nothing).
Looking at the delays between the transactions being cleared and the money appearing in your bank account, even with the best timing you might not see a penny of all of that.
1. You need to register yourself as a merchant at an acquirer bank. Either directly or through intermediaries such as Stripe/Square etc.,
2. Go through reasonably stringent KYB (Know Your Business) process.
3. Do a few legitimate transactions so that everyone in the payment processing chain (acquiring bank, payment gateway etc., issuing bank, network (Visa/MasterCard)) begins to trust you.
4. Reconfigure the kiosk to use the above merchant account.
5. Pull out money from the acquiring bank before enough customers raise a charge-back and your your account is marked as fraudulent by someone/everyone in the payment processing chain.
These fly-by-night merchants are indeed created; especially at marketplaces such as EBay, Amazon. But to do it at a physical kiosk such as McDonalds' seems like a low ROI to me.
I doubt that'd work. My client is set up as multiple merchants (different companies from a legal pov) but with the same payment provider, going over the same pipes, etc. Even so, the way the payment servers were set up, they could only mix up the merchant config if the "wrong" one also happened to be on the same server.
They have dedicated servers, so I'd expect McDonald's and other big chains to have them, too, which means that you couldn't send payments no anyone outside the mother company.
But the transaction info has to be transmitted by the touch terminal - unless the recipient is set to a fixed value in the card machine, that should at least make it possible to re-route all of McDonald's revenue to some arbitrary recipient.
In the article he points out the PC is responsible for updating firmware in the card reader. So while it's a more sophisticated hack, change the firmware to record the pin and send it back to the PC etc etc.
But yes I think this is more a "hey there is so much insecure tech out there - here is another example" as opposed to "we are all dead and our bank accounts emptied"
btw if anyone has ever taken a look at a POS setup, it's a bit misleading to the uninformed
In some solutions, the readers are in fact hooked up directly to the POS system. However, the card terminal does not see unencrypted payment data. The POS is acting as a network bridge or switch, while getting limited information over network from the terminal.
In fact, I'm not sure that's even something that's allowed in large scale installations today.
You only get unencrypted stuff when doing mag-stripe, and that’s mostly just card number and name. Same with tap-to-pay may-stripe emulation (the old way which no one is supposed to use anymore, even in the US per credit card rules).
That’s why everyone has/is moving off mag-stripe (depending on country) and to EMV. With EMV and EMV contactless the terminal never gets the full card number, among many other significant security improvements.
So, i was confused about this- the snippet that comes back, is it direct from another site or is it generated from the results?
I searched for "how to set up preact with vite", and I got a passage that sounded incredibly condescending, and half-way through it ignored the p in preact and started talking about react instead- but I was impressed that I couldn't work out if it was directly lifted from a stackoverflow reply, or it was generated in the style of one.
