Burger King, Data Breach, French Style

As some of you may be aware of, Burger King experienced another data breach , and it is slightly different from the 2019 event. As before, personal data was exposed due to misconfiguration of their website: specifically in the Jun 2023 incident the passwords for databases and other services were stored in a publicly accessible text file. This would not be that interesting if the incident took place in their US location, where personal data of children was also exposed (Like Panera, which uses palm scanning, Burger King nudged children to enter their info so it was more convenient to order their favourite items and parents to pay without needing to have to go to the cashier), having its customers mysteriously receive emails with blank receipts, or that one of these services whose authentication info was stored in that configuration file was also our old friend Google Analytics would be forgotten in a few weeks.

What makes the special sauce special is this is happened in France, which means it is under the jurisdiction of the GDPR. Data breach investigations under those regulations are rather different than those under US laws. If the American-based multinational cannot prove it has done due diligence regarding how it protects the personal data of its customers and current/future employees, they should at least expect heavy fines: according to GDPR Art. 83(5), severe violations can cost up to 4% of Burger Kings total global revenue, which in 2021 was US$ 1.81 billion. Given the authentication was stored in plain text and children data (which may have been collected in violation of GDPR Art 8, and falls under Recital 38) is at risk, the fast food giant should not expect the French Data Privacy Authority (Commission Nationale de l'Informatique et des Libertés, or CNIL) to be as lenient towards American companies as the Irish one.

This is a very new case -- announced today in the news -- and we have no idea when Burger King reported to the CNIL (per GDPR Art. 33 they must report within 72h of learning of the incident), so we will have to wait to see how it will develop; expect the case to take at least months before the CNIL deliberates and issues fines.

Bloatware/Spyware: TikTok & Meta preinstalled in Windows 11 devices

Have you heard of the term "promoted apps?" That is the euphemistic term for programs that were preinstalled in a new computer. People like me knew them by a different term, bloatware, they were popular in the old Microsoft Windows and MacOS installs; the idea was companies would give money to OS and/or computer/smart phone manufacturers to bundle the former software with the later's products. Think of it as a variation of paid advertising or infomercial. This junk was grouped into:

• Trialware
• Adware
• Spyware, like those bundled by cell phone carriers.
• And, on a rare occasion, something useful. Somewhere out there there is an example.

That trend has not diminished. If you check your brower, you may find it is ready to connect to offer a youtube search engine built-in. People have been reported Windows 11 coming with TikTok and Meta installed at least since 2022. No matter what people said, I do not mind TikTok/Meta/Twitter/youtube as long as I decide to install it. I mean, what is wrong with going to an app store and getting it? But, why should any of them be bundled into a new Windows 11 tablet? Yes, there are tricks and instructions online to remove them, but they should not be there to begin with.

Protest against Reddit API Changes and killing 3rd party APIs: Jun 12-14. Call today at 10:30AM PST

This may sound like a politicized post, but there is madness behind reason here: for a while there has been many third party applications used by Reddit users to post (include posting with a modicum of privacy (hey, we talk a lot about that here!) as sometimes said posts can be career-ending ones) and keep track of topics of interest. Even the moderators make use of such tools to keep spam down. All of these tools were possible using the API provided for free by Reddit. Many of these tools are open source, offered for free.

Fast forward to now, and Reddit is aiming for an IPO this year. Also, it has decided to start charging for the use of its API starting June 30. There are some who will claim the two events are related. This is expected to cause most of these 3rd party apps to be killed and force users to rely on the official app which is not know for its interface or features, besides its privacy issues.

As a result,

• More than 3000 communities (subreddits) will go dark from Jun 12 to Jun 14 in protest to this decision, including many that are associated with IT in general and cybersecurity specifically. Some of them will shut down permanently.
• There is a thread where you can get the most recently developments.
• People are flocking to Reddit alternatives including Mastodon, beehaw, and Discord.

Reddit said its CEO will be hosting a "Ask Me Anything" (AMA) event today at 10:30AM PST to talk about their plans regarding the API.

Is there another reason?

Well, what if Reddit realized the people behind large language models -- OpenAI, Google, etc -- are making money by scraping their website to get data for their AI models (since it is still a hot topic, here is the obligatory mention of ChatPT), and now Reddit wants to get a piece of the action?

Cackalacky Con This Week!

Did you miss the last 3-day weekend? Well, I think we have here a reason for you to make it happen!

If you live or are near the NC Triangle (Raleigh, Durham, Chapel Hill) this week, on Friday May 5th the Cackalacky Con conference begins at the DoubleTree by Hilton Hotel Raleigh-Durham Airport at Research Triangle Park. It goes on until May 7th and will contain lots of events (besides the talks) such as CTF, hardware stuff, lockpicking, and much more.

Videos from previous conferences such as this one
can found at the CackalackyCon youtube chanel.

I should warn you that I will be giving a talk. So, if you happen to land on it, please act terrified.

Still, lookie at the fancy badge I got!

Passwordless authentication and MFA

There is a push to stop using passwords to authenticate into systems. In 2020 Microsoft announced in its blog that it hopes to make its customers go passwordless in 2021. They plan on achieving it by using FIDO2 security keys such as Yubikey, (smart) phone-based sign-in tools such as the Microsoft and the Google Authenticators, and biometric tools such as fingeprint authentication. They are not alone; Apple and Google have also working on that not only to login to their devices but also websites and apps.

Here is the fun part: those solutions are being pushed as "you only need to pick one of them and you are secure!" Want to login to your phone? Just show your face! Get into your house? Stick your finger at it! How about your bank? Click on something in your phone! So, what it is doing is replacing one form of authentication -- passwords (boo! Hiss!) with a passwordless solution.

What is wrong with this picture?

Does anyone remember Multi Factor Authentication (MFA)? The idea is to use more than one form of authentication so if one is compromised your account is still not compromised. That was usually done by using one authentication from each of the following groups:

• Something you know. Like a password.
• Something you have. Like a badge or a Yubikey.
• Something you are. Like your Iris.

The so-called passwordless solutions being mentioned started their lives as a second factor in the MFA design, but now they are being pushed as the only form of authentication required. That implies those companies do think they are very strong against attacks to be used on their own.

When the FBI and the CISA announced MFA can be hacked, they are really talking about the secondary, passwordless, authentication of the MFA process, password being the primary (which has its own issues, but we are talking here about increasing the odds that the multiple authentications will not all be compromised at the same time). is not a panacea. Like everything else, passwordless authentication can be hacked;see the Uber data breach.

Bottom line

Passwords can be compromised. Passwordless authentication can also be compromised. There is no panacea. Both together should be a bit more secure than each of them. If you are bound not to have passwords at all, get two distinct MFA systems.

As the old say goes, Two is One, One is None.

Github updating its ssh keys

Today I learned that the Microsoft-owned Github decided to update its RSA SSH host host key but did not explain its reasoning. Why would it go through all of this trouble? Usually when a company does that, it is their way to cover that they were hacked or were compromised in some other way. That is not what is written in their blog, so we will have to wait for this to unfold.

"What does that mean to companies and developers depending on that?" Well,

• If you created a SSH RSA keypair to authenticate against github -- so you can git push and git pull your repos without entering your password -- you probably wants to consider creating a new pair, deleting the old one, and using the new one. Ideally, this may also be an excuse to switch to an ECDSA-derived key such as ed25519 if you are able to. Sometimes this is hard because you may be dealing with a host that does not support that... not that have ever happened to me.
• If you have received the github RSA pub host key, which was added to your .ssh/known_hosts (if you are using Linux, OSX, and some UNIX variation) file, you will need to delete that entry and get github feed you a new one. Of course, you want to ensure you are getting the proper github key, not one from someone impersonating it.
• If you use Windows, well, let me get back at you on that later.

Now some developers will argue that relying on known_hosts has caused more failures of working software than preventing faked host access since SSH was originally written. Their proposed way to deal with that is to tell ssh not to check the validity of the host key. In Linux, OSX, and other UNIX versions that would mean to disable that in ~/.ssh/config. If you want to disable the Key checking to all ssh connections, you could do something like (the boldface lines are the most important parameters)

    Host *
           UserKnownHostsFile /dev/null
           StrictHostKeyChecking no
           LogLevel error

While I understand that the above is a clever way of stopping suck pesky keys from hampering your style, disabling security for the sake of convenience is never a good solution. The more time-consuming solution is to remove the offending keys in ~/.ssh/known_hosts so you can ensure you are getting the right key, not a key impersonating the site you want to connect to, which in this case is github.

Fun fact: given that I saw the following message, I think they are not only changing the RSA key:

Warning: the ECDSA host key for 'github.com' differs 
from the key for the IP address '140.82.121.3'

TDIL Slack uses let's encrypt

This morning I was going to login to slack from the command line and saw the following message:

┌───────────────────────┤SSL Certificate Verification├────────────────────────┐
│Accept certificate for slack.com?                                            │
│                                                                             │
│The certificate for slack.com could not be validated.                        │
│                                                                             │
│The certificate is not trusted because no certificate that can verify it is  │
│currently trusted.                                                           │
│                                                                             │
│                ┌────────┐ ┌────────┐ ┌──────────────────────┐               │
│                │ Accept │ │ Reject │ │ _View Certificate... │               │
│                └────────┘ └────────┘ └──────────────────────┘               │
└─────────────────────────────────────────────────────────────────────────────┘

Let's probulate a bit:

┌──────────────────────────┤Certificate Information├──────────────────────────┐
│Certificate Information                                                      │
│                                                                             │
│Common name: slack.com                                                       │
│                                                                             │
│Issued By: CN=R3,O=Let's Encrypt,C=US                                        │
│                                                                             │
│Fingerprint (SHA1): 76:bc:49:94:88:fa:90:d6:59:3c:04:0d:81:81:67:58:35:ce:a0 │
│:d5                                                                          │
│                                                                             │
│Activation date: Thu Mar  2 07:32:27 2023                                    │
│                                                                             │
│Expiration date: Wed May 31 07:32:26 2023                                    │
│                                                                             │
│SHA256: 25:6f:90:6b:16:b5:1b:4a:27:27:55:19:9d:1a:76:61:11:b0:d2:7c:6b:b6:b6 │
│:36:48:ac:c5:5a:6c:92:8f:80                                                  │
│                                                                             │
│                     ┌─────────────────────────┐ ┌───────┐                   │
│                     │ View Issuer Certificate │ │ Close │                   │
│                     └─────────────────────────┘ └───────┘                   │
└─────────────────────────────────────────────────────────────────────────────┘

So,

• They are using Let's Encrypt
• The certificate is renewed every month
• The new certificate is not enabled yet (it is 7:20h right now)

What else can we find?

┌────┤Certificate Information├────┐icate Verification├────────────────────────┐
│                                 │                                           │
│Unable to find Issuer Certificate│                                           │
│              ┌────┐             │d not be validated.                        │
│              │ OK │             │                                           │
│              └────┘             │ause no certificate that can verify it is  │
└─────────────────────────────────┘                                           │
│                                                                             │
│                ┌────────┐ ┌────────┐ ┌──────────────────────┐               │
│                │ Accept │ │ Reject │ │ _View Certificate... │               │
│                └────────┘ └────────┘ └──────────────────────┘               │
└─────────────────────────────────────────────────────────────────────────────┘

Very interesting. How about from the command line?

user@desktop:~$ echo ''|openssl s_client -connect slack.com:443 | openssl \
x509 -noout -enddate -startdate
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = slack.com
verify return:1
DONE
notAfter=May 31 07:32:26 2023 GMT
notBefore=Mar  2 07:32:27 2023 GMT
user@desktop:~$ 

Now you too know!