Why are McDonald’s Self Service Kiosks so hackable?(ghuntley.com)
ghuntley.com
Why are McDonald’s Self Service Kiosks so hackable?
https://ghuntley.com/mcdonalds/
257 comments
it's in the tradition of "posting the wrong answer to get the good one". within this genre the comment section ends up even more terrifying than the post itself!
josefresco(4)
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.
> 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.
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.,
A good overview + detail : https://www.youtube.com/watch?v=Zv1DjtBwADg
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.,
A good overview + detail : https://www.youtube.com/watch?v=Zv1DjtBwADg
NFC cards dominate here though, which effectively negates the many benefits of chip cards.
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
Encrypted in the same sense that https is encrypted. Doesn't do jack if you have control over the "server".
And in this case the server can have a large antenna and not require physical contact.
So in essence, orders of magnitude worse than the magnetic strip.
And in this case the server can have a large antenna and not require physical contact.
So in essence, orders of magnitude worse than the magnetic strip.
This is fundamentally incorrect.
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]
[0]: https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC...
[1]: See EMV specifications, “Book 2 – Security and Key Management,” Version 4.3, November, 2011, http://www.emvco.com/specifications.aspx?id=223.
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]
[0]: https://www.emv-connection.com/downloads/2015/12/EMV-and-NFC...
[1]: See EMV specifications, “Book 2 – Security and Key Management,” Version 4.3, November, 2011, http://www.emvco.com/specifications.aspx?id=223.
Why would you need to sniff anything?
Just ask for it yourself. That's what I meant with encryption not meaning jack if you are one of the participants.
Just ask for it yourself. That's what I meant with encryption not meaning jack if you are one of the participants.
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.
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.
If you can match a pin to a database of cards numbers, I can supply you with a database of all pins in existence
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...
Damn. How many bitcoins did you spend on that leak?
for (i = 0; i <= 9999; i++) {
...
}
Glad to see that my 6-digit pin is safe from hacking for at least a few more years.
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.
That was a bit disconcerting.
That was a bit disconcerting.
PIN is actually completely optional.
A rogue terminal can decide to authorize the transaction with a “signature” (there are legitimate uses for this)
Or even with no PIN at all (there are also legitimate uses for this)
It’s also possible to do either of these 2 things and then report back that the transaction what authorized with a PIN
A rogue terminal can decide to authorize the transaction with a “signature” (there are legitimate uses for this)
Or even with no PIN at all (there are also legitimate uses for this)
It’s also possible to do either of these 2 things and then report back that the transaction what authorized with a 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"
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"
Up in Lithuania they now starting to have a contactless tipping device where you scroll the wheel to select tip amount.
Which is kinda pointless since if you are paying and receiving service at the counter - you aren't really receiving a service to tip for.
Which is kinda pointless since if you are paying and receiving service at the counter - you aren't really receiving a service to tip for.
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
What the...?
Its crazy, but kinda reasonable
Its crazy, but kinda reasonable
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.
jerry-rig*
eggcorn, acorn, all the same, just a different name:
https://en.m.wiktionary.org/wiki/eggcorn
https://en.m.wiktionary.org/wiki/eggcorn
This is why my PIN is 9998.
I believe most banks stop sequence numbers such as "1234", "9876"
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.
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.
You can use more than 4 digits if you want a more secure PIN.
EMV (the card standard used by all modern chip/contactless cards) supports PINs between 4-12 digits in length.
EMV (the card standard used by all modern chip/contactless cards) supports PINs between 4-12 digits in length.
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?
Six-digit pin works well for me in European countries - Czechia, Germany, Austria, Spain, Italy.
My girlfriend used a 5-digit PIN for over 10 years in the UK and never had any issues that I can recall.
I’d change mine too except I use the PIN so infrequently (99% contactless now days) I’m worried I’d forget the new one!
I’d change mine too except I use the PIN so infrequently (99% contactless now days) I’m worried I’d forget the new one!
Mine is eight digits, never tried it outside Canada yet.
All pins in my country are 5 digits. Which can be annoying for four-d visitors (depends on the bank, and I've not heard of problems for a while).
Damned, with 5 digits, the cost of storage alone is a deterant for a rainbow table
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.
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.
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 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.
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?
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?
It’s the old joke of listening in on the McDrive intercom after putting up a sign saying ‘the microphone is acting up, please yell’
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.
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.
Parent meant to ignore the EMV and have the kiosk just claim that all orders are paid, so the user gets food.
[deleted]
If we say average transaction size is $10 and that you’ll save 1.000 customers (generous) before you’re caught.
You just committed a felony to provide $10.000 in free food.
Might as well get a day job and make that contribution annually and skip federal prison.
You just committed a felony to provide $10.000 in free food.
Might as well get a day job and make that contribution annually and skip federal prison.
This is like a 2005 hack. I'm sure you could come up with at least one good solution to this problem.
Or you could tweak the ordering software to completely ignore the terminal, and not bother charging at all.
That should be pretty easy to block with signing they should already be doing.
> 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.
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 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).
The devices I’ve seen all have signed firmware.
Yeah the firmware should be signed and have an EMV certification. It’s a total pain in the arse to develop and deploy new software for these devices.
Considering the article writer already expresses some clear misunderstandings, I don't think it's correct.
Maybe they witnessed it, but that would be a bigger deal than some shitty windows box being popped. Certainly, that would not pass compliance.
Maybe they witnessed it, but that would be a bigger deal than some shitty windows box being popped. Certainly, that would not pass compliance.
Signed firmware though.
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.
It's common to have the tamper switches trigger if you drop the terminal. They'll need to be re-flashed from scratch when that happens. eg. https://stackoverflow.com/questions/33872627/how-to-fix-tamp...
Anyway the TLDR is that the Card Reader part of any POS system is reasonably secure.
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.
It's common to have the tamper switches trigger if you drop the terminal. They'll need to be re-flashed from scratch when that happens. eg. https://stackoverflow.com/questions/33872627/how-to-fix-tamp...
Anyway the TLDR is that the Card Reader part of any POS system is reasonably secure.
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.
Do these payment terminals have secure boot or other forms of update payload verification?
In that case the risk of accepting malicious updates from insecure touch screen would be much less.
In that case the risk of accepting malicious updates from insecure touch screen would be much less.
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.
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.
The terminals really don't trust the POS systems.
The terminals really don't trust the POS systems.
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).
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.
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 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
Payments settle at whatever the interbank settlement timeframes are. Any type of payment escrow would be incredibly out of the ordinary.
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..
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.
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.
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.
> request a transaction for a different merchant?
To be able to pull this off:
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.
To be able to pull this off:
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.
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.
> Also chip cards don’t ever leak the CC number as part of the transaction
Yes they do. In fact, you can read the CC number from the chip without even knowing the PIN.
Yes they do. In fact, you can read the CC number from the chip without even knowing the PIN.
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.
The recipient is set to a fixed value in the card machine.
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.
I'm assuming the firmware is cryptographically signed, because they have to upgrade from untrusted devices. That negates this entire attack vector.
I think our best reaction to that is ... hmmmm.
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"
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.
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.
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.
>You only get unencrypted stuff when doing mag-stripe
The terminal encrypts it before sending it over the wire
The terminal encrypts it before sending it over the wire
Do you have a source for this?
The EMV spec doesn’t include encryption of any data sent to the terminal from the card.
The transaction cryptogram is signed, however.
The EMV spec doesn’t include encryption of any data sent to the terminal from the card.
The transaction cryptogram is signed, however.
The terminals themselves use mtls to communicate and wrap the payload , wasn't referring to the payload itself.
That seems like a walkback? You said:
> However, the card terminal does not see unencrypted payment data.
The card terminal does see unencrypted payment data. Hard to see your comment as ambiguous?
> However, the card terminal does not see unencrypted payment data.
The card terminal does see unencrypted payment data. Hard to see your comment as ambiguous?
[deleted]
I was involved with the card reader upgrades at McDonald’s in the US. Essentially the card readers were stripped out of the main network and all buildings were rewired With a physically segregated network for cashless transactions.
Registers placed orders to the main routing Server in the back which passed the information to each individual station for fulfillment. The only time the card reader is involved is when the register makes a request to the cashless processing appliance in the back office then it reaches out to the card reader on the segregated network.
Registers placed orders to the main routing Server in the back which passed the information to each individual station for fulfillment. The only time the card reader is involved is when the register makes a request to the cashless processing appliance in the back office then it reaches out to the card reader on the segregated network.
I worked at a POS vendor who did this kind of thing internal to the device. We had a bunch of robots (they looked like 3d printers with a stylus instead of a print head) testing the payment flows because none of the android test tools could interface with that part of the device.
It was kind of impressive, but also kind of funny because the secrets we were protecting are symmetric and printed on the card for anyone to see.
It was kind of impressive, but also kind of funny because the secrets we were protecting are symmetric and printed on the card for anyone to see.
> the secrets we were protecting are symmetric and printed on the card for anyone to see.
On the magstripe and plastic, yes, but that is very rarely used today in stores. A modern chip card doesn't really expose secrets.
On the magstripe and plastic, yes, but that is very rarely used today in stores. A modern chip card doesn't really expose secrets.
I'm surprised the stripe is still added to cards these days. The chip broke on my mums card around 10 years ago and although the card readers had strip readers, they would often refuse to use it. Seem to remember some requiring a few failed chip uses before allowing magnetic strip.
Depends in what part of the world you’re in. In Europe I wouldn’t really expect anyone to accept magstripe on card with a chip, but in the US it’s more common.
Additionally terminals can be configured to detect dodgy chips and automatically fall back magstripe, or a more basic form of processing. But your bank may block these transactions, because they can’t perform chargebacks on them, they’re considered as “secure/good as” Chip and PIN transactions by the card network for merchants in some parts of the worlds (e.g. the US). So if a fraudulent transaction was performed that way, the bank would have to eat the entire cost themselves.
Additionally terminals can be configured to detect dodgy chips and automatically fall back magstripe, or a more basic form of processing. But your bank may block these transactions, because they can’t perform chargebacks on them, they’re considered as “secure/good as” Chip and PIN transactions by the card network for merchants in some parts of the worlds (e.g. the US). So if a fraudulent transaction was performed that way, the bank would have to eat the entire cost themselves.
It's only a few years ago that we started seeing cards without embossed numbers for taking impressions by rubbing.
I think that actually made more sense. In a power outage the bumps were the only backup. I had seen it used once at a petrol station. While there is close to no situation where a chip payment or nfc couldn’t be used.
My UK bank card has a mag stripe on it but I have to explicitly activate it via their mobile app, and it will be disabled again after seven days.
Only for ATM transactions. It’ll still work for normal transactions at a POS device, but they’re lower risk for the bank as it’s easy to perform chargebacks and recover the money
That’s correct and stripes are mostly used as a fall back now a days, if at all. Merchants are reluctant to use stripe because in case of chargeback of a striped payment the liability shifts to the merchant, no question asked. That’s how the payment networks got merchants to migrate to use chip based authentication.
The biggest reason in the US is the cost of replacing gas station pump payment terminals. They held back going "full" EMV (no stripe at all) for many years.
But if a human can take a picture of the card and create online transactions based on that image, the necessary secrets are leaked anyhow. Secure the chip all you want, until we stop using shared symmetric secrets to authorize spend it won't really matter.
This matches something the startup I worked at discover when installing power monitoring equipment in restaurants. We initially weren’t PCI compliant but it didn’t matter because we always installed on the network that didn’t process credit card info. Just one potential customer asked us about this…
https://en.m.wikipedia.org/wiki/Payment_Card_Industry_Data_S...
I remember Target stores getting hacked a few years back and having a few million credit card numbers leaked..
https://money.cnn.com/2013/12/18/news/companies/target-credi...
https://en.m.wikipedia.org/wiki/Payment_Card_Industry_Data_S...
I remember Target stores getting hacked a few years back and having a few million credit card numbers leaked..
https://money.cnn.com/2013/12/18/news/companies/target-credi...
This is good right? It sounds like a secure design.
I’d say so. Also there was effectively no troubleshooting in the store you could do. Aside from unplugging and replugging the appliance and terminals it was all under a very strict service contract. Too many terminals down or the appliance that processes transaction and a tech had to be out in 8 hours regardless of time of day to service.
And really, the worst exploit I fathomed you could do would be... changing the IP address on two PEDs to swap what lanes they were on (so register 2's pad would be really being used for register 3 and vice versa).
(Former in-training OTP here.)
(Former in-training OTP here.)
What was your experience like and where did it lead you? For me it was part of the wake up call that showed me to the door. Being OTP for 14 Stores and GM for 1 was what pushed me over the edge.
If it’s anything like American McDonald’s those card readers should be hooked up over the network- not USB. There shouldn’t be a trivial way to use them as card skimmers, the software loaded on them, doesn’t just like hand out card numbers it processes the transaction.
Now, if they are hackable, and if they’re networked, or if you’re in America, your target is the Ethernet ports strategically hidden around the store. Look under and behind soda machines, inside cabinets in the lobby used to store napkins and stuff, randomly on the walls in the playplace etc
I don’t know about skimming cards from those ethernet ports, but you will have full access to the entire POS system which includes ordering and business data and the backend server.
Now, if they are hackable, and if they’re networked, or if you’re in America, your target is the Ethernet ports strategically hidden around the store. Look under and behind soda machines, inside cabinets in the lobby used to store napkins and stuff, randomly on the walls in the playplace etc
I don’t know about skimming cards from those ethernet ports, but you will have full access to the entire POS system which includes ordering and business data and the backend server.
Even if they completely screwed up all the security in a way that would never pass compliance testing broadcasting all card info for every transaction to the network in the clear, with EMV cards all you’d get are EMV tags that are useless for anything but taking that one payment on that one terminal at that one time for that one amount.
You couldn’t use anything you harvest to make a new transaction on the cards, or even replay the transactions you saw.
(Mag-stripe is different, don’t use that!)
You couldn’t use anything you harvest to make a new transaction on the cards, or even replay the transactions you saw.
(Mag-stripe is different, don’t use that!)
Yeah - I'm fairly certain payment terminals, USB or otherwise, do not provide credit card numbers in clear text. Any card information is encrypted on-device, then sent to the payment gateway - and the readers usually have some sort of anti-tamper stuff to at least prevent them from being opened up and the encryption key compromised or the hardware hijacked.
FiPay (which is one of the pieces of software you can run with Verifone terminals) can be configured to return a credit card number back, but, it's only for legacy point of sales applications that need to have a number for whatever reason.
Even after moving everything to our Verifone vault, we still had those fields in our point of sales database, even if all of the numbers were '4111 1111 1111 1111' and the expiration dates were 2099+. We would pass the "proper" things down for the receipt as text fields (AID/TID/etc) to be printed on the receipt and stored with the transaction log.
Even after moving everything to our Verifone vault, we still had those fields in our point of sales database, even if all of the numbers were '4111 1111 1111 1111' and the expiration dates were 2099+. We would pass the "proper" things down for the receipt as text fields (AID/TID/etc) to be printed on the receipt and stored with the transaction log.
EMV tags gives you parts of the card number (so you can tell the kind of card or put the last 4 on receipt) but you don’t get the full number anymore like with mag-stripe.
Why would you spend money on switch ports for patching unused outlets?
The card readers are processing transactions? Wouldn’t there be a giant mainframe doing that somewhere?
It's a bit tricky with different payment flows possible for all kinds of scenarios.
While at some point the transaction will get to "a giant mainframe somewhere" to get processed, it may or may not be during the process that a customer sees. It may be a "online" transaction where it's essentially that the terminal prepares a transaction message, the chipcard signs it, and then forwards it to issuing institution for authorization (including but not limited to checking availability of funds); or it may be permitted, within certain limits and depending on configuration, to have the chipcard sign the transaction and then deliver it for processing some time later (e.g. at end of day) so that either you can enable transactions in places which do not have internet access, or simply for processing speed for small amounts, taking on some limited risk for customer convenience.
While at some point the transaction will get to "a giant mainframe somewhere" to get processed, it may or may not be during the process that a customer sees. It may be a "online" transaction where it's essentially that the terminal prepares a transaction message, the chipcard signs it, and then forwards it to issuing institution for authorization (including but not limited to checking availability of funds); or it may be permitted, within certain limits and depending on configuration, to have the chipcard sign the transaction and then deliver it for processing some time later (e.g. at end of day) so that either you can enable transactions in places which do not have internet access, or simply for processing speed for small amounts, taking on some limited risk for customer convenience.
It’s a combination of both sides. It’s something like this:
For EMV the terminal and the card generate a request, and send it to the payment processor/bank.
They say yes/no and send back some stuff needed to complete the transaction. At this point there would be a hold on your card.
The terminal and card verify that and finish things, preparing proof of the final transaction.
That’s sent to the processor again who confirms the transaction took place. This is when the money is taken and the hold disappears.
Final proof from the processor is sent back to the terminal so the system knows everything went through. Now you get your receipt.
For EMV the terminal and the card generate a request, and send it to the payment processor/bank.
They say yes/no and send back some stuff needed to complete the transaction. At this point there would be a hold on your card.
The terminal and card verify that and finish things, preparing proof of the final transaction.
That’s sent to the processor again who confirms the transaction took place. This is when the money is taken and the hold disappears.
Final proof from the processor is sent back to the terminal so the system knows everything went through. Now you get your receipt.
The nitty gritty of everyday things like this can be so interesting sometimes
I learned a lot of neat stuff about this process and other things around it as a side benefit of some of the tasks I was given at a job.
It was fun to learn, and to see how they solved some of the problems that would come up that you might not think about.
Of course the side effect is you also learn just how insecure older CC tech was. I think almost everyone sort of notice that at this point, but once you start learning the details… it’s bad. Basically electronically writing down CC numbers like they might have in the ‘60s, assuming people are good and trustworthy.
It was fun to learn, and to see how they solved some of the problems that would come up that you might not think about.
Of course the side effect is you also learn just how insecure older CC tech was. I think almost everyone sort of notice that at this point, but once you start learning the details… it’s bad. Basically electronically writing down CC numbers like they might have in the ‘60s, assuming people are good and trustworthy.
I will take this opportunity to go off-topic and discuss the UX of the McD's terminals.
It's terrible.
I loathe it. I always go to a person if possible, whereas I go to the self-checkout at the grocer's. The technical performance and the menu navigation of those kiosks is unbearable, and I'm a 30s techie.
It's terrible.
I loathe it. I always go to a person if possible, whereas I go to the self-checkout at the grocer's. The technical performance and the menu navigation of those kiosks is unbearable, and I'm a 30s techie.
The self-checkout navigation is intentionally hobbled, probably because old people will 'press' a button about six times with shaking hands. Feels like they're putting button presses into a buffer for a half second or more.
Watch next time an employee has to "help" you with self checkout: they scan their badge and then can press buttons as quickly as they like.
I've noticed recent iterations of self-checkouts are much easier to use. Feels like they've relaxed the weight-on-tray requirements.
And at self checkouts with the option of a handheld scanner, use it. Often the handheld scanner seems to bypass the place-item-in-bagging-area thing.
Watch next time an employee has to "help" you with self checkout: they scan their badge and then can press buttons as quickly as they like.
I've noticed recent iterations of self-checkouts are much easier to use. Feels like they've relaxed the weight-on-tray requirements.
And at self checkouts with the option of a handheld scanner, use it. Often the handheld scanner seems to bypass the place-item-in-bagging-area thing.
> The self-checkout navigation is intentionally hobbled, probably because old people will 'press' a button about six times with shaking hands.
So that is why ... it makes sense since I distincly remember the kiosks working fine in the beginning.
They should add a "turbo button".
The kiosks infuriate me by the sluggish UI. Also the 3 or 4 sellup spam ads you get make it even slower.
So that is why ... it makes sense since I distincly remember the kiosks working fine in the beginning.
They should add a "turbo button".
The kiosks infuriate me by the sluggish UI. Also the 3 or 4 sellup spam ads you get make it even slower.
Given roughly equivalent line waits, I've found human checkers tend to be much faster if you have more than a handful of items - they know where the barcodes are on the items so they don't have to play the game where you try to figure out which side of the soda bottle or cereal box has the barcode on it, and they already have the codes for produce memorized. Sometimes you get an incompetent or new checker, or you get stuck behind the morbidly obese lady who has to pay for $5 worth of Gatorade and cookies with an EBT card and $60 worth of cigarettes and dog food with a credit card, oh that one didn't work let's try it again, yeah it didn't work again, well now let's try this card this one will work for sure NO TIMMY I DON'T CARE IF YOU'VE GOT TO USE THE BATHROOM YOU SIT YOUR ASS DOWN AND SHUT UP OR I SWEAR TO CHRIST I WILL GIVE YOU SOMETHING TO CRY ABOUT, but just on the average I find self check-out machines to take much longer because the person doing all the work has far more experience and competence at the task in question.
> whereas I go to the self-checkout at the grocer's
"Please place item in bagging area. Please place item in bagging area. Please place item in bagging area. Thank y... Please place item in bagging area. Please wait for assistance." Yeah, no thanks. I only use those crappy fail machines when I have no choice because there are no open checkout lanes with people manning them.
"Please place item in bagging area. Please place item in bagging area. Please place item in bagging area. Thank y... Please place item in bagging area. Please wait for assistance." Yeah, no thanks. I only use those crappy fail machines when I have no choice because there are no open checkout lanes with people manning them.
I used to agree. The store in which I use it the most, HEB in Texas, doesn't have issues often. The only design decision that is frustrating is that for certain items, it tries to insist I "bag" the item by putting it on the small bagging area, even if it's a 2.5 gallon jug of water. I have to wait 5 seconds for the prompt to time out and then I can say "skip bagging".
For a few small items, CVS and HEB do well.
For a few small items, CVS and HEB do well.
The people are removed from the ordering experience at all McDonalds in my local area (Sydney Australia-ish)
The registers are hidden behind a counter and there's no obvious place to order, unless you use the kiosk.
If you stand at the empty counter for ~5 minutes, a staff member will eventually appear for something else (e.g. to give out an order) and serve you reluctantly - it's awful.
The registers are hidden behind a counter and there's no obvious place to order, unless you use the kiosk.
If you stand at the empty counter for ~5 minutes, a staff member will eventually appear for something else (e.g. to give out an order) and serve you reluctantly - it's awful.
I can't stand any self checkouts anywhere. I always order with a person.
I love self checkouts. Home Depot has the best with the wireless scanners.
With few items, I can be in and out in a minute and never have to wait in line because there are so many self checkouts. If I have a lot of items, then I can wait in line for cashier because scanning all of them is more work than I care for.
I rarely have issues using them, at a variety of retailers.
With few items, I can be in and out in a minute and never have to wait in line because there are so many self checkouts. If I have a lot of items, then I can wait in line for cashier because scanning all of them is more work than I care for.
I rarely have issues using them, at a variety of retailers.
Here in Japan Uniqlo’s self checkout is awesome, you dump the clothes into a bin and then it wirelessly/barcodelessly scans everything and just tells you the total. Idk if they’re doing that in the USA yet.
It’s also available in the UK.
Easily, the best self checkout I’ve ever used.
Easily, the best self checkout I’ve ever used.
Decathlon does that in Romania.
Probably everywhere. It does mean that every single one of their items carries an RFID tag which is a privacy issue and an environment issue.
It can be an environmental issue, sure, but how would it be a privacy one? Items already have a unique number of some sort, I don't see how storing it on an RFID tag changes things.
I guess unless that tag is deactivated at checkout, you might now be wearing a unique collection of RFID tags?
The RFID is in the sales tag, so unless you're walking around with the tags still attached…
No, for clothing they are in the same label that tells you how to wash it and for other items they are in some easy to miss sticker.
One of the larger super market chains here have a phone app, which allows you to scan your items as you walk through the store. When you leave, you just scan a big QR code at checkout and that will charge the card stored in the app.
It's a really quick way of doing checkouts, i.e. you pretty much just walk out, unless you bought alcohol, in which case you'll need to wait for someone to check that you're 18.
My main issue with it is that it makes shopping terribly slow and mentally stressful. The whole process of scanning items as you pick them up is less convenient that you'd think. Some items, like vegetables don't have barcode... now what? I found myself constantly checking that I've scanned everything and focused more on the app than anything else. It's a great way to ensure that people only get what's on their shopping list.
Except for the fast checkout, which is really nice, I can't recommend it.
It's a really quick way of doing checkouts, i.e. you pretty much just walk out, unless you bought alcohol, in which case you'll need to wait for someone to check that you're 18.
My main issue with it is that it makes shopping terribly slow and mentally stressful. The whole process of scanning items as you pick them up is less convenient that you'd think. Some items, like vegetables don't have barcode... now what? I found myself constantly checking that I've scanned everything and focused more on the app than anything else. It's a great way to ensure that people only get what's on their shopping list.
Except for the fast checkout, which is really nice, I can't recommend it.
I am a huge fan as well. I usually feel like I am spending much less time during the checkout process than I used to.
Sometimes though, when all the checkout lanes are in use, I dream of a licensing scheme for use. So many people take _forever_ to checkout, you would think this technology was introduced in the last month.
When this happens I like to play a game where I race to check myself out before everyone else (that has already started since I am taking the latest emptied spot). I would say I win this game probably 80% of the time.
Sometimes though, when all the checkout lanes are in use, I dream of a licensing scheme for use. So many people take _forever_ to checkout, you would think this technology was introduced in the last month.
When this happens I like to play a game where I race to check myself out before everyone else (that has already started since I am taking the latest emptied spot). I would say I win this game probably 80% of the time.
I think Home Depot might be more usable because many of their items are too big to be removed from the cart and put on a scale, so they don't have that slowdown-inducing option for under-scanning prevention
In Australia, they call McDonald's, "Macca's"?
In Australia, we shorten the name for all sorts of things, so "maccas" is in line with the general theme. More examples (not sure if some of these are found everywhere or not):
* Australian: Aussie
* McDonalds: maccas
* Barbeque: barbie
* Ambulance: ambo (often used to refer to the ambulance staff -- I'm not even sure what they're called other than 'ambos'!)
* Breakfast: brekky
* Afternoon: arvo
* Cup of coffee: cuppa
* Registration for car: rego
* Woolworth's (supermarket): Woolies
* Service station: servo
* Australian: Aussie
* McDonalds: maccas
* Barbeque: barbie
* Ambulance: ambo (often used to refer to the ambulance staff -- I'm not even sure what they're called other than 'ambos'!)
* Breakfast: brekky
* Afternoon: arvo
* Cup of coffee: cuppa
* Registration for car: rego
* Woolworth's (supermarket): Woolies
* Service station: servo
Many years ago, I was surprised the first time a cashier told me:
Tah tah-tah.
I later discovered that it was the "short form" of "Thank you, goodbye"
I later discovered that it was the "short form" of "Thank you, goodbye"
How do you say "you're welcome"? "wah wah-wah"?
Yeah, I don't recall personally hearing those two strung together like that, but we definitely say them individually. I was surprised learning that not every English speaking country says 'ta' as a short version of 'thanks'.
This happened to me in Brisbane, as said many years ago, 1980, maybe it is (was) a regional (Queensland) thing, but definitely, while I remember perfectly the first time I heard it because it struck me, it wasn't the "only" time I experienced it.
Ambos are Paramedics
Sco-mo: Scott Morrison former prime minister
Avo: Avocado
Avo: Avocado
They even use http://macc.as
(And have done since at least 2013, according to whois.)
(And have done since at least 2013, according to whois.)
The domain seems to try to redirect to yourquestions.mcdonalds.com.au but it doesn't really work...
Back when macc.as was launched it linked to a campaign to debunk/side-step some common local ideas about the food quality of mcdonalds.
Back when McDonalds was still relevant there was a lot of press about the nutritional content, food preparation standards and so on. Food poisoning or undercooked food from mcdonalds was a common theme. My understanding is that they have largely addressed these issues.
Back when McDonalds was still relevant there was a lot of press about the nutritional content, food preparation standards and so on. Food poisoning or undercooked food from mcdonalds was a common theme. My understanding is that they have largely addressed these issues.
Thanks for the explanation!
The interesting part is that it's apparently embraced by the brand itself. Back when we had real McDonald's in Russia*, its colloquial name was "makdak" or simply "mak", but it was that — how people called it (and still do). Never recognized officially.
* the corporate pulled out of Russia several months ago and the business was sold to the biggest franchisee. The new owner reopened the stores under a different brand name but kept most of everything else.
* the corporate pulled out of Russia several months ago and the business was sold to the biggest franchisee. The new owner reopened the stores under a different brand name but kept most of everything else.
Funny, it's Macdo in France
It's 'mac' in Romania. Sometimes 'mek'. I always just use the real name.
Norwegian it's "Macern"
Supermarket chain "Woolworths" - commonly called "Woolies" - had a campaign using the Woolies name a while back. These short names are so ubiquitous in Australia that of course they'll eventually use them, if only tongue in cheek.
Safeway forever!
In Germany it's fairly common to call McDonalds "Mäckes", which sounds very similar to "maccas" when spoken. This is an unofficial designation with a slightly negative touch as well, as it's often preferred to the actual name when referring to McDonalds specifically as a provider of mostly unhealthy food.
I don't know, for me Meckes is neutral. The ones with more negative connotations are probably 'Zum Goldenen Adler' (due to the sarcastic undertone) und 'Amerikanische Delikatessen' (due to the perceived oxymoron)
Interesting, I don't know any of your synonyms from my personal experience. The especially negatively connotated variant I know is 'McDoof' (basically 'McDumb' when translated to English).
It is also common in Europe, or at least Germany, though more likely spelled Meckes. The term apparently used in the US (Mickey Ds) is unheard of here. There seems to be a trend in the US to dissociate from everything that sounds like it could have European history or influence (see also the renaming of french fries)
yep. "Maccies" is common in the UK
Also "Maccas" in New Zealand, and I was wondering if they'd be ok with our other names - "Micky D's" and "Smack Donalds".
Yes, and it’s embraced by the brand.
https://m.youtube.com/watch?v=GEhHkjB075M
https://m.youtube.com/watch?v=GEhHkjB075M
Also a thing in Denmark where’s it’s “Maccen”. They use it in commercials too.
“Den Gyldne Måge or “The Golden Seagull” is another common, but older, name here.
“Den Gyldne Måge or “The Golden Seagull” is another common, but older, name here.
How to Speak Australian: Abbreviate Everything!
https://youtu.be/yDb_WsAt_Z0
https://youtu.be/yDb_WsAt_Z0
I'd say its more common to call it by the official name but no one in Australia would be confused if you called it Macca's
Yep. At least since I was a kid in the 80s
Why is everyone so concerned about a malicious party compromising the card reader? Because that would be solely a McDonald's problem.
No credit card issuer would refuse chargebacks for fraud that occurred because of this, nd ultimately when they'd find the source, it'd me McDonalds picking up the tab.
The risk to the average person from this is 0. At most it's an inconvenient call to a bank and sorting out a card replacement. (And an extra inconvenience for people using debit cards).
I have plenty of cards, and I wouldn't care one bit if the details of some got leaked, as I'm getting a push notification for every transaction.
Anything unexpected? Call/fill in an online form, and it's resolved within 2 days, and by then you already have a new card in the mail.
No credit card issuer would refuse chargebacks for fraud that occurred because of this, nd ultimately when they'd find the source, it'd me McDonalds picking up the tab.
The risk to the average person from this is 0. At most it's an inconvenient call to a bank and sorting out a card replacement. (And an extra inconvenience for people using debit cards).
I have plenty of cards, and I wouldn't care one bit if the details of some got leaked, as I'm getting a push notification for every transaction.
Anything unexpected? Call/fill in an online form, and it's resolved within 2 days, and by then you already have a new card in the mail.
True hacking by some Australian innovators "in this space" (AMAZING SELF-SERVE KIOSK HACK THAT SCORES YOU FREE MACCAS):
https://www.youtube.com/watch?v=h7ttj41Fdig
https://www.youtube.com/watch?v=h7ttj41Fdig
The confident self-assured tone as this article gets everything but the very basics wrong is definitely something...
This is the same clown who had a post a few weeks ago about his speakers that don't go as loud. But yea, he pulls up at beaches in his van and starts playing loud music that no one asked for. He could be a member of that fantastic band "Tool"
Even if the kiosk loads the payment terminal firmware, that firmware will be signed.
It’s 2022, pretty much all developed nations use chip cards so you wouldn’t have anything to gain from this exercise anyway.
It’s 2022, pretty much all developed nations use chip cards so you wouldn’t have anything to gain from this exercise anyway.
I'm not sure I understand why you brought up chip cards so this may be irrelevant, but in the US cards still have magnetic strips, and I believe most terminals are configured to fail over to the strip reader after a few failed attempts to read the chip.
There’s a process to it.
Every card, as part of the mag-stripe, has a little bit of data on it called the Service Code. It’s three characters. Part of that tells the terminal if the card has an EMV chip.
The terminal is required (I believe, by the brands) to force you to use the chip. The chip has to fail a set number of times (I believe usually 3) before it will process a mag-stripe transaction.
Even then, the payment processor is informed this transaction was a failed chip transaction that fell back to msg-stripe. So the processor can determine if they want to take the risk.
(Of course this doesn’t apply to mag-stripe only devices like older gas pumps)
Every card, as part of the mag-stripe, has a little bit of data on it called the Service Code. It’s three characters. Part of that tells the terminal if the card has an EMV chip.
The terminal is required (I believe, by the brands) to force you to use the chip. The chip has to fail a set number of times (I believe usually 3) before it will process a mag-stripe transaction.
Even then, the payment processor is informed this transaction was a failed chip transaction that fell back to msg-stripe. So the processor can determine if they want to take the risk.
(Of course this doesn’t apply to mag-stripe only devices like older gas pumps)
It’s possible for a compromised payment terminal to record magnetic stripe card data. These kinds of payments essentially do not exist in developed countries.
It’s not possible for a compromised payment terminal to do anything interesting with other kinds of cards.
It’s not possible for a compromised payment terminal to do anything interesting with other kinds of cards.
In the US skimming of mag-stripe is still surprisingly/sadly common.
Most(?) store gift cards don’t have chips. I think some smaller banks may not have chips on debit cards. I don’t know about “food stamp” cards or gas station branded cards.
So as a thief you can collect what you can get. Plus you can screw up the EMV slot so people must swipe, making them vulnerable (if they don’t use contactless).
Most(?) store gift cards don’t have chips. I think some smaller banks may not have chips on debit cards. I don’t know about “food stamp” cards or gas station branded cards.
So as a thief you can collect what you can get. Plus you can screw up the EMV slot so people must swipe, making them vulnerable (if they don’t use contactless).
> you can screw up the EMV slot so people must swipe
I think that outside of USA most banks would configure their systems to automatically decline any transaction from a chip-capable terminal for a chip-capable card (to prevent cloned cards from being used with just the mag-stripe data), so swiping would be possible only on terminals that never had a EMV slot in the first place, and IIRC even that is limited to certain regions as in many countries it's expected that all terminals must be chip-capable; a damaged EMV slot should result in the bank returning an error code effectively saying 'broken terminal, repair or use another' instead of permitting to swipe.
Alternatively, I think I have seen contracts (for merchants who really wanted to keep swipes longer than the expected transition) that say that any fraudulent swiped transactions are fully paid for by the merchant.
I think that outside of USA most banks would configure their systems to automatically decline any transaction from a chip-capable terminal for a chip-capable card (to prevent cloned cards from being used with just the mag-stripe data), so swiping would be possible only on terminals that never had a EMV slot in the first place, and IIRC even that is limited to certain regions as in many countries it's expected that all terminals must be chip-capable; a damaged EMV slot should result in the bank returning an error code effectively saying 'broken terminal, repair or use another' instead of permitting to swipe.
Alternatively, I think I have seen contracts (for merchants who really wanted to keep swipes longer than the expected transition) that say that any fraudulent swiped transactions are fully paid for by the merchant.
That wouldn’t surprise me. Everything about the way we’re doing this in the US is going slow. I mean we’re only just starting to get it on gas pumps.
It wouldn’t surprise me if mag-stripe is just turned off in a few years.
It wouldn’t surprise me if mag-stripe is just turned off in a few years.
It definitely took the US a long time to get started, but I think once it got started it's nudged along at a reasonable pace. RFID pay at least is growing a lot faster than chip pay did previously.
I never understand how these terminals get past hygiene regs.
They’re touch screen and right next to toilets where the previous customer may …or may not have just washed their hands.
Then customers go right ahead and eat their food with their hands.
It’s like the perfect recipe for worms. Gross.
They’re touch screen and right next to toilets where the previous customer may …or may not have just washed their hands.
Then customers go right ahead and eat their food with their hands.
It’s like the perfect recipe for worms. Gross.
How is that different than any other surface in the restaurant, doors or card terminals where you sometimes have to type the pin code?
You have a good point and are probably correct, but still.
These days most McDonalds seem to have automatic doors and card payments are contactless via phone or card.
Assuming the kitchen staff keep their hands clean and the trays are washed the touchscreens are the most obvious thing too break the illusion of hygene.
The real problem I guess is eating food with your hands without immediately washing them first.
Historically before contactless payments and automatic doors the world didn't end so it probably is just a percived "yuck factor" on my part, I fully acknowledge that.
It's just... those screens and their suspicious smears... :-###..
These days most McDonalds seem to have automatic doors and card payments are contactless via phone or card.
Assuming the kitchen staff keep their hands clean and the trays are washed the touchscreens are the most obvious thing too break the illusion of hygene.
The real problem I guess is eating food with your hands without immediately washing them first.
Historically before contactless payments and automatic doors the world didn't end so it probably is just a percived "yuck factor" on my part, I fully acknowledge that.
It's just... those screens and their suspicious smears... :-###..
They are hackable in part because the stakes are low that not much thought is put into security. We're talking ordering food, not cryptocurrency or bank records.
> the stakes are low that not much thought is put into security.
What I don't get is that NO though was put in to security. Sure the card reader and the payment processing, I'm honestly sure that someone did a reasonable job at that part, because that comes as part of the payment terminal.
For a management perspective I can't see why you didn't think about the security for just a few minutes extra and came up with a much better product in general. There's certainly a point to being overly focused on security and never shipping, but it's also the case that thinking about security and misuse will help you to build better, more stable products.
These devices fail, and they fail constantly. I was a a Burger King two weeks ago, and again at the same restaurant two days ago. Two out of three kiosk where broken when I arrived two days ago, that all three where broken after I order two weeks ago. At the local McDonald's it often that three or four out of ten kiosks are broken. They aren't broken as in physically damaged, it's the software that's not working or stuck somehow.
As the article points out, they break so frequently that they are left unlocked, which in turn violates the idea that they are physically secured.
Three things I'd change is:
* Don't run as administrator, because hey, it's a quick thing to fix, so might as well.
* Read-only filesystems.
* PXE boot those things, so that they'll get fresh OS + application install on each boot.
If you ever see staff try to fix a kiosk, then you'll notice that they just open them and reboot the device. From what I've seen that frequently fails to fix the device, meaning that the system is in a broken state. Having the whole thing boot a known good image could help.
When the normal recovery plan for thousands of these kiosk is: "Reboot and hope it works. If not, wait for a technician to re-image, or reboot again." then you didn't spend enough time on systems design.
What I don't get is that NO though was put in to security. Sure the card reader and the payment processing, I'm honestly sure that someone did a reasonable job at that part, because that comes as part of the payment terminal.
For a management perspective I can't see why you didn't think about the security for just a few minutes extra and came up with a much better product in general. There's certainly a point to being overly focused on security and never shipping, but it's also the case that thinking about security and misuse will help you to build better, more stable products.
These devices fail, and they fail constantly. I was a a Burger King two weeks ago, and again at the same restaurant two days ago. Two out of three kiosk where broken when I arrived two days ago, that all three where broken after I order two weeks ago. At the local McDonald's it often that three or four out of ten kiosks are broken. They aren't broken as in physically damaged, it's the software that's not working or stuck somehow.
As the article points out, they break so frequently that they are left unlocked, which in turn violates the idea that they are physically secured.
Three things I'd change is:
* Don't run as administrator, because hey, it's a quick thing to fix, so might as well.
* Read-only filesystems.
* PXE boot those things, so that they'll get fresh OS + application install on each boot.
If you ever see staff try to fix a kiosk, then you'll notice that they just open them and reboot the device. From what I've seen that frequently fails to fix the device, meaning that the system is in a broken state. Having the whole thing boot a known good image could help.
When the normal recovery plan for thousands of these kiosk is: "Reboot and hope it works. If not, wait for a technician to re-image, or reboot again." then you didn't spend enough time on systems design.
Credit card readers are attached to these.
As pointed out multiple times, these are separate systems that are designed to be connected to insecure systems.
If anyone has a vulnerable card processing system it would be Lowes. They didn't support chip and pin over a year after the deadline. Suggesting a whole lot of broken system design that is probably still held together with bubblegum and duct tape.
I think many would be interested in what kind of surveillance hardware and software the kiosks have. It should also be easier to determine what is being sent over the net to some end point than getting encrypted payment details.
I wouldn't be surprised if there was a camera with video, microphone or at least photographs of customers. Indeed, grocery kiosks have these in the UK, some actually show you the video feed on the monitor in front of you to install fear to deter shoplifting.
Where this data goes and what the company uses the data for, we don't know.
I wouldn't be surprised if there was a camera with video, microphone or at least photographs of customers. Indeed, grocery kiosks have these in the UK, some actually show you the video feed on the monitor in front of you to install fear to deter shoplifting.
Where this data goes and what the company uses the data for, we don't know.
Im too high-inhib to stand there fucking with the kiosk while everyone in the restaurant is staring at me wondering if they should tell the employees.
I was expecting some fun UI exploits like getting a negative bill for removing all the ingredients on a burger, and adding that up to pay for an actual burger [0], sadly nothing like that.
[0] https://www.delish.com/food-news/a27091162/mcdonalds-kiosks-...
[0] https://www.delish.com/food-news/a27091162/mcdonalds-kiosks-...
If it's anything like the McDonald's in the United States, the card readers need to be connected through the network rather than through USB. Because the software that is installed onto them does more than simply send out card numbers, there should not be an easy way to exploit them as card skimmers. The software that is loaded on them handles the transaction.
I have seen legacy companies with security rules so tight they can’t ship anything cool. On the flip side are legacy companies that ship great user experiences, but apparently just totally ignore the security people. Does the security professions have a “human centric security design” capability? It’s something the non-tech Fortune 500s to desperately need.
Can confirm the usability problems - during the recent brief heatwave I popped into a local store to treat myself to a rare guilty pleasure of a McFlurry. After confirming, printer paper error pops up, giving the option to continue. Clicked ok, but no re-presentation of the order number. Could remember it anyway, but unimpressive for a mega corp
I wonder if these systems are airgapped (or perimeter around the local restaurant). If the menu doesn’t change very often, there’s a good chance that could be and the payment terminal does all the work itself. In which case it would not be much different to an ATM or POS running OS/2 Warp.
Hacking aside, they are still subject to good old programming errors. Back in November 2019 the kiosk showed a Bacon BBQ Quarter Pounder for $0. You could customize it and still check out for $0. I ordered as many as 6 at once, plus a drink and paid $1.04 total. This worked for about a month.
Wow… and I had felt nervous about the computers in my house and business still running Windows 10 (which will be EOL in 3 years, not a lot of time for a business). But McDonalds has no problem with Vista (EOL 5 years ago). Ouch.
If McDonalds ever gets hacked, this should come up for possible criminal liability.
If McDonalds ever gets hacked, this should come up for possible criminal liability.
He posted a correction (at the bottom) that they are running Windows 7, so it's a marginally better situation.
> If McDonalds ever gets hacked, this should come up for possible criminal liability.
Oh no, the criminals might find out about your disgusting eating habits! The horror!
Seriously though, what kind of damages might you as a customer expect to see from McDonalds kiosks getting hacked?
Oh no, the criminals might find out about your disgusting eating habits! The horror!
Seriously though, what kind of damages might you as a customer expect to see from McDonalds kiosks getting hacked?
The same damages you might expect from sticking your credit card into a hacked ATM.
There are some comments here claiming that their experience with McDonald’s order kiosks in the US makes them feel this is unlikely to be hackable, but “employees regularly leave them unlocked” sure sounds like an invitation for someone to find other hacks.
There are some comments here claiming that their experience with McDonald’s order kiosks in the US makes them feel this is unlikely to be hackable, but “employees regularly leave them unlocked” sure sounds like an invitation for someone to find other hacks.
e.g. none? at least in the US.
when the credit card issuer fraudulent credits the charges back to your account, you no longer have any (meaningful) damages.
when the credit card issuer fraudulent credits the charges back to your account, you no longer have any (meaningful) damages.
[deleted]
I have no problem with XP either.
The "EOL" carping is mostly from the corporate interests; and as the other comments here explain, the actual secret part of the card processing happens on a complete separate machine which is definitely far more secured.
The "EOL" carping is mostly from the corporate interests; and as the other comments here explain, the actual secret part of the card processing happens on a complete separate machine which is definitely far more secured.
[deleted]
I caught one of the self checkouts rebooting at my local grocery store and it was still running Windows XP.
Nothing wrong with that, IF it's on an isolated WAN, and not connected to the internet.
A fully patched copy of XP, with all the group/local policies set to lock it down, is very secure.
In a lot of cases, it may look like XP, but it's actually XP Embedded, which has a lot of stuff stripped out, which reduces the attack surface significantly.
It costs money to upgrade the checkout application for a new OS, and put it through rigorous testing - These things need to work almost 24/7 without crashing or needing admin intervention.
It's the old idiom: If it ain't broke, don't fix it.
A fully patched copy of XP, with all the group/local policies set to lock it down, is very secure.
In a lot of cases, it may look like XP, but it's actually XP Embedded, which has a lot of stuff stripped out, which reduces the attack surface significantly.
It costs money to upgrade the checkout application for a new OS, and put it through rigorous testing - These things need to work almost 24/7 without crashing or needing admin intervention.
It's the old idiom: If it ain't broke, don't fix it.
> Why are McDonald’s Self Service Kiosks so hackable?
> Underpaid staff who used to do ordering have been replaced with.... staff across Australia leaving the Kiosks unlocked to make it easier to replace the paper.
They pay the staff who replace paper less than the staff who served at the counter.
Case closed.
> Underpaid staff who used to do ordering have been replaced with.... staff across Australia leaving the Kiosks unlocked to make it easier to replace the paper.
They pay the staff who replace paper less than the staff who served at the counter.
Case closed.
In my experience, the people who replace the paper are the staff who serve at the counter. They don't just replace the paper, they'll also refeed it when the receipt printer inevitably gets jammed.
Counter service hasn't completely disappeared, but they seem to spend most of their time now bagging orders for Uber Eats / Doordash & taking drive-through orders. They're also there for customer enquiries, eg "why did the self service decline my card", "I didn't get any sauce with my McNuggets", "I got a medium fries instead of a large"
Counter service hasn't completely disappeared, but they seem to spend most of their time now bagging orders for Uber Eats / Doordash & taking drive-through orders. They're also there for customer enquiries, eg "why did the self service decline my card", "I didn't get any sauce with my McNuggets", "I got a medium fries instead of a large"
Understandably covering the technical details but the practical reason is some executive got a bigger kickback offer from one of the vendors regardless of their competence and there you go, screws over millions of people with high risk for an extra vacation home.
These kiosks arrived about 10 years too late anyway. All they need to do is make their phone app a bit more usable and no one would need the kiosks.
Regarding paper, 99 times out of 100, there’s no paper in the printer. People are used to having to remember their order number.
Regarding paper, 99 times out of 100, there’s no paper in the printer. People are used to having to remember their order number.
>All they need to do is make their phone app a bit more usable and no one would need the kiosks.
No, please. Assuming everyone can and will use apps is a terrible idea. Apps are terrible for accessibility
- People who don't have phones
- People who do have a phone, but it can't install your app
- People who didn't bring their phones
- People who brought their phone, but it's out of batteries
- People who brought their phone, but it can't connect to the internet
- People who are not tech savvy enough to install/use apps
- People who can't use your app for disability related reasons
- People who don't want to use your apps out of some principle
- People who might be able to use your app, but it is just so tedious that the extra friction makes them not want to
None of these are small groups. Relying on app usage is business suicide
No, please. Assuming everyone can and will use apps is a terrible idea. Apps are terrible for accessibility
- People who don't have phones
- People who do have a phone, but it can't install your app
- People who didn't bring their phones
- People who brought their phone, but it's out of batteries
- People who brought their phone, but it can't connect to the internet
- People who are not tech savvy enough to install/use apps
- People who can't use your app for disability related reasons
- People who don't want to use your apps out of some principle
- People who might be able to use your app, but it is just so tedious that the extra friction makes them not want to
None of these are small groups. Relying on app usage is business suicide
My local McDonald's (at least in the UK) almost always has a queue for the single human taking orders as they mostly use cash. Some of them don't even look at the kiosks as an option, even if prompted by staff. The most you get is a member of staff using the kiosk for them,
Apps, requires you to install them and they always require you to sign in.
Not something I’m willing to do just to grab a cheese burger. It’s not like I go to mcd on such regular basis.
Don’t say it’s possible to make one that doesn’t. First, kids would abuse it to anonymously order 200 Big Macs in another town, and secondly companies are always too greedy to look away from that stream of potential user data.
Not something I’m willing to do just to grab a cheese burger. It’s not like I go to mcd on such regular basis.
Don’t say it’s possible to make one that doesn’t. First, kids would abuse it to anonymously order 200 Big Macs in another town, and secondly companies are always too greedy to look away from that stream of potential user data.
> Apps, requires you to install them and they always require you to sign in.
A) app-less or install-free apps are a thing, on iOS they’re called app clips and work great.
B) the mcd’s app (and all of the other fast food apps I can think of) don’t require a login. You pay for your food when you order it, so the ‘anonymous order’ attack isn’t a thing.
Also they usually take ApplePay, which is an added security benefit.
A) app-less or install-free apps are a thing, on iOS they’re called app clips and work great.
B) the mcd’s app (and all of the other fast food apps I can think of) don’t require a login. You pay for your food when you order it, so the ‘anonymous order’ attack isn’t a thing.
Also they usually take ApplePay, which is an added security benefit.
I believe you're incorrect about point B there. The mymacca's app goes straight to a sign-in/up screen, and I can't figure out any way around it.
And now we're stuck requiring Android or iOS.
Or if there is paper, it doesn't print on it
Ordered a meal yesterday and the receipt came out blank. Person making orders asked for receipt and I showed them and they all laughed.
Ordered a meal yesterday and the receipt came out blank. Person making orders asked for receipt and I showed them and they all laughed.
The “sorry, there is no paper” error message popup obscures the order number. So if you missed it before the error message shows, you don’t know your number.
It’s easy because they had to be cheap and ready just in time of the next shareholder Meeting.
I have contacted McDonalds Australia (I am an Australian) and asked them for comment.
Why not just have the receipt paper door be separate from that containing ports?
> McDonalds in Australia do a decent cup of coffee. It’s not great but it’s consistently decent so I often start my day with a cup.
Ugh lost me on the first sentence
Ugh lost me on the first sentence
They really do though.
If your idea of coffee is Folger's or Maxwell House brewed in a drip machine, McDonald's serves decent coffee.
No. They do proper espresso style coffees with decent beans.
TLDR don’t listen to anyone with a stupid crypto ape profile picture.
nerds
Closer to Truth with Robert Lawrence Kuhn is great for Philosophy/Science content - a variety of episodes with great interviews from multiple perspectives and in digestible segments: https://www.youtube.com/c/CloserToTruthTV
[deleted]
- Snarky and talks down about people not "in the know" about potential security issues.
- Supreme confidence that they are super knowledgeable about how it "should" be done.
- Fails to provide any actual demonstrable impact, but doing the old "left to the reader" as to how it's clearly exploitable.
But when you drill into the details, they are just fundamentally wrong about how the product is even working, what is possible with the attack surface, and how components are interacting with each other.
There are plenty of vulnerabilities out there, and companies do make stupid mistakes with regards to security in lots of situations. That doesn't mean that every pie in the sky idea you have (oh look, I did a kiosk escape, dot dot dot, clearly I can credit card skim now) is possible.