BrainOverfl0w

DNS Wildcards & GitHub Pages

Thu, 11 Apr 2024 11:30:00 +0200

TLDR: Don’t setup DNS wildcards for GitHub Pages. Spammers are paying to use GitHub Pages infrastructure and squatting those subdomains to deliver SEO spam.

When I set up my blog a few years back, I wanted something that had the lowest maintenance possible. I didn’t want to have to worry about updating servers, dealing with deployments and load balancing. GitHub Pages seemed like the solution I was looking for.

Anticipating that I might have wanted to deploy to subdomains in the future, I setup a DNS wildcard A entry for GitHub Pages. While there’s now a warning against doing that, that wasn’t the case in 2016 when I set this up.

Warning: We strongly recommend that you do not use wildcard DNS records, such as *.example.com. These records put you at an immediate risk of domain takeovers, even if you verify the domain. For example, if you verify example.com this prevents someone from using a.example.com but they could still take over b.a.example.com (which is covered by the wildcard DNS record). For more information, see “Verifying your custom domain for GitHub Pages.”

To this day, there’s nothing that prevents this to be setup either.

Earlier this week, I noticed strange URLs (eg. tasteful.fredericjacobs.com) being indexed by Google on my subdomains, that caused me to investigate and quickly linked it back to this DNS wildcard entry, that was allowing attackers to generate GitHub Pages on my subdomains.

I searched for the repositories for these GitHub Pages but they seem to be using paid GitHub accounts since it allows them to use GitHub Pages without having to open-source the repositories.

After reporting this to GitHub, they responded this is an intentional design decision, and is working as expected.

I have since removed the wildcard DNS entry, addressing the issue for my domain. But as far as I can tell, the accounts of the attackers are still paying GitHub for delivering spam pages on many other domains. It would be nice to see GitHub take action and notify users who setup wildcards for GitHub Pages, and prevent these from being setup in the future.

iMessage PQ3

Mon, 08 Apr 2024 09:30:00 +0200

Earlier this year, we announced iMessage PQ3, Apple’s formally-verified protocol for end-to-end encryption that amongst other updates provides post-quantum protections against “Harvest Now, Decrypt Later” attackers.

In a previous blog entry, I talked about the Double Ratchet & the Quantum Computers, concluding that Double Ratchet was ‘Quantum Annoying’ and required an attacker to record almost every message to be able to continue decrypt a conversation due to the key continuity property of the public-key ratchet. Post-quantum ratcheting; however, still required some tricks to be practical in order to not trade post-compromise security for quantum-resistance.

In the Real World Crypto 2024 Invited Talk: Designing iMessage PQ3: Quantum-Secure Messaging at Scale, we cover the design of the iMessage PQ3 protocol, including the delicate balancing act between crytographic overhead from larger post-quantum parameters and tightness of security properties.

RFC-9474: RSA Blind Signatures

Wed, 11 Oct 2023 11:00:00 +0200

Along with Chris Wood and Frank Denis, we have an RFC for RSA Blind Signatures for adoption in schemes like Privacy Pass.

A security analysis of the scheme was also done by Anna Lysyanskaya.

Real World Crypto 2022 - Exposure Notifications Private Analytics

Wed, 13 Apr 2022 01:00:00 +0200

I was delighted to be presenting at the Real World Crypto 2022 conference in Amsterdam on Exposure Notifications Private Analytics. It’s exciting to see large scale deployments of multi-party computation and that such systems are on-track to be standardized.

#realworldcrypto and now we have @FredericJacobs on stage telling us about exposure notification and privacy! pic.twitter.com/zl3uxr0wxY
— Yolan Romailler (@AnomalRoil) April 13, 2022

Really nice to see such Apple <~> Google collaboration with such a focus on user privacy 🙏 Great talk, and it's even cooler to have public whitepapers and all around it.
— Yolan Romailler (@AnomalRoil) April 13, 2022

The approach of #Apple and #Google, “Exposure Notifications Private Analytics” is neat, simple and elegant.

and the deployment insights regarding MPC was so valuable (see pictures).

So many challenges were introduced, startup ideas?#realworldcrypto pic.twitter.com/3dU0mA1smL
— Emad Heydari Beni (@heydari_be) April 13, 2022

Presenting at WWDC - Introducing CryptoKit

Thu, 01 Aug 2019 01:00:00 +0200

I was happy to present at WWDC this year. You can find the video on developer.apple.com, or in the WWDC app. It was a pleasure to introduce a fast, easy-to-use and secure cryptographic (as in cryptography!) library for Swift.

On the "WhatsApp backdoor", Trade-Offs and Opportunistic Authentication

Fri, 20 Jan 2017 14:00:00 +0100

A week ago, The Guardian broke an “exclusive” story titled “WhatsApp backdoor allows snooping on encrypted messages”.

The Reporting

My first reaction when I skimmed through the story is that this was nothing new . The Guardian’s source had already blogged about it on the 16th of April and given a lightning talk at CCC explaining the issue. Other people in the security community had already looked into this behavior too. Running the story as “exclusive” and sending a push notification to all subscribers as if it were breaking time-sensitive news, while this was known in the security community for months, seems disingenuous.

The other issue I had with the reporting of this story was the framing that this was a backdoor. This claim has been debunked by now, not matching the technical definition of a backdoor. The Guardian ended up rephrasing their headline to reflect that this was not a backdoor. While they did change that important categorization, they left the reaction and analysis from the people who commented on the story, largely unchanged.

Original:

Professor Kirstie Ball, co-director and founder of the Centre for Research into Information, Surveillance and Privacy, called the existence of a backdoor within WhatsApp’s encryption “a gold mine for security agencies” and “a huge betrayal of user trust”

After adjusting headline:

Professor Kirstie Ball, co-director and founder of the Centre for Research into Information, Surveillance and Privacy, called the existence of a vulnerability within WhatsApp’s encryption “a gold mine for security agencies” and “a huge betrayal of user trust”.

While I do agree that a backdoor would have been a huge betrayal of user trust, I do not agree that this particular issue was a betrayal of user trust. Unlike with a backdoor, subvert purposes are improbable and the edited story should have reflected that.

The Trade-Off

Message encryption is maturing as a field and has some pretty elegant solutions deployed in “the real world”, “usable authentication” is still an open problem.

WhatsApp is known for being very reliable and their users love them for that. They decided that unread messages, should be retransmitted upon a change of phone number, matching the behavior they had before adopting end-to-end encryption or any “cloud-based” messenger. Instead of losing the messages that were sent and never read, WhatsApp will automatically retransmit them to the recipient’s new phone, without letting the sender verify the new “security code” first. Since phone networks, that are used for authentication by mobile messaging apps, are insecure or WhatsApp servers could get hacked, this leads to some practical attacks that would lead to the compromise of a streak of unread messages upon retransmission.

You can agree that this was a reasonable trade-off to make in the name of reliability. But such security trade-offs are nothing new, and they are important. When Signal came around, many praised it for adopting a TOFU (Trust On First Use) model. Most “secure messaging” clients up to then, the biggest one being OTR, had been bugging users about fingerprint verification, significantly hurting the adoption of end-to-end encryption. With Signal’s TOFU model, keys are implicitly trusted on the first use. Peers may then confirm that trust by verify their keys through an out-of-band channel. That’s a potential security risk. Does that make Signal backdoored or inherently insecure? No. It was a trade-off that made people actually use end-to-end encryption.

You can definitely discuss the merits of such trade-offs but dismissing them as backdoors will just drive people away to unencrypted or opportunistically encrypted solutions.

WhatsApp transitioned from plaintext to opportunistic encryption to all the messages, from over a billion people, being encrypted by default. Then, once that was complete, enabled the phase we are currently in of “opportunistic authentication” until we find a scalable solution to the authentication problem.

Organizations like SimplySecure, or mailing lists such as Trevor Perrin’s Secure Messaging mailing lists, promote great ideas for tackling these issues. Let’s keep things moving forward to a place where we can all confidently say that we have “encrypted and authenticated communications” by default.

check.torproject.org & IPv6

Thu, 18 Aug 2016 07:30:00 +0200

TLDR: Exit nodes with IPv6 addresses connect to check.torproject.org over IPv6, causing the IP not to be recognised as being one of an exit node. This triggers a scary “Sorry. You are not using Tor.” warning.

When firing up Tor Browser today and checking if the browser was properly using Tor, I got the following scary message.

What I assume happened

Confused, I quickly checked if that was my IPv6 address. Thankfully it wasn’t. Tor browser was correctly proxying traffic over the Tor network but the exit node resolved check.torproject.org over IPv6. A DNS lookup for check.torproject.org gives:

~ ❯❯❯ host check.torproject.org
check.torproject.org is an alias for chiwui.torproject.org.
chiwui.torproject.org has address 138.201.14.212
chiwui.torproject.org has IPv6 address 2a01:4f8:172:1b46::abba:20:1
chiwui.torproject.org mail is handled by 10 eugeni.torproject.org.

What likely happened is that the exit node connected to check.torproject.org over IPv6. Since Tor doesn’t have full support for IPv6 yet, the exit node appeared as unknown, hence triggering this warning.

Quick fix

I think the warnings are scary and we shouldn’t be telling users to just ignore them. A quick easy fix would be to simply not have any IPv6 DNS records in check.torproject.org as long as IPv6 isn’t fully supported.

Any thoughts or suggestions? Discuss on Tor-Dev.

Update (24th of August): The AAAA record was removed, waiting for a more broader IPv6 support in Tor.

On SMS Logins II : an example from Telegram in Russia

Sat, 30 Apr 2016 08:30:00 +0200

A few months ago, I wrote a post on SMS logins following a wave of attacks attempting to take over Iranian Telegram accounts. Recently, there have been new confirmed cases of attacks in both Iran and Russia.

Oleg Kozlovsky is an opposition activist and the director of Vision of Tomorrow Center in Moscow.

In a Facebook post written in Russian, he explains how his Telegram account got hacked.

At 2:25 AM MSK on Friday April 29th, MTS (Russia’s largest mobile operator), disables SMS service on his phone number. After 15 minutes of disconnection, someone tries to log into Oleg’s Telegram account. The process for authorizing a new device to a Telegram accounts simply consists of entering a verification code received by SMS when 2-step authentication is not enabled. At 3:08AM the attacker enters the authorization code and gets access to Oleg’s account. The Telegram login notification reveals that the attacker is using a Telegram command-line interface with an IP of a Tor exit node.

Four minutes later, the same Tor exit node IP address, logs into George Alburov’s Telegram account. It is currently unknown if other accounts were breached that night. Messages logs (excluding Telegram Secret Chats) and contacts information were likely the information seeked by the attacker.

Because Oleg was sleeping during the attack, he only noticed the notification in the morning. He called MTS Customer Support, after consulting with the “expert department”, they told him that the security service was involved and that SMS was indeed disabled from 2:25 AM to 4:55 AM. Oleg’s request for talking to the security service was denied.

SORM, Russia’s CALEA

Given the political activities of both targets, the most probable theory is that the attacker was a Russian governmental agency working in collaboration with MTS under the SORM law.

SORM, standing for Система Оперативно-Розыскных Мероприятий which translates to System for Operative Investigative Activities, is Russia’s CALEA. SORM has been around since 1996 to enable wiretaps of telephone communications. It evolved over the years to allow broader access to electronic communications.

If SMS interception capabilities exist, why would they go through the hassle of disconnecting the SMS service? One possible theory is that they hoped the intrusion would be unnoticed if the targets didn’t receive the text message. This would allow them to proceed to data exfiltration from the Telegram account without the risk of being shut down halfway through. The issue with this theory is that Telegram notifies you on your primary device when a new device is logged in. So despite not having seen the new activation SMS at the time, Oleg could have detected it instantly because of the Telegram notification. Additionally, attackers didn’t log themselves out, remaining visible after Oleg woke up in Telegram’s active sessions. So it remains unclear to me what the advantage was over a regular interception. If they hoped to be undetected, this was really sloppy and unprepared.

Phone numbers for authentication

Most messaging apps and some 2-step authentication providers rely on phone numbers as an authentication factor. Why are so may services using identifiers that are assigned by mostly state-owned companies and that are subject to CALEA-like laws and awfully insecure (IMSI catchers/SS7) against nation state adversaries?

Using phone number identifiers is a significant usability and growth advantage. You can leverage the social graph that people already have on their phone. After signup, they can instantly see who uses the service.

It also enables service providers to not have to store a buddy list unencrypted on servers since the social graphs are in the phone’s address book. (Note: Some applications like Telegram store a copy of your address book unencrypted on their servers, not using that property.)

But it also turns out that it’s really convenient to rely on someone else key management infrastructure since usable authentication is a hard problem to solve. Most telcos have (insecure) processes to re-assign you your number when you lose your phone or if someone steals your SIM card keys. Those processes rely on providing some proof-of-identity. But that can be spoofed too. Last year, two investigative journalists at Novaya Gazeta were told that their SIM cards were reissued by unknown people.

Those processes clearly fall short. As we cannot solely rely on phone numbers to authenticate, Pavel Durov recommended users from troubled countries to enable 2-step authentication.

Users from troubled countries: make sure you have 2-step verification enabled – in Telegram and other services https://t.co/w81h4PjFv4
— Pavel Durov (@durov) April 29, 2016

I believe that mitigation is a good first step, but insufficient, especially for people in troubled countries. An attacker might also suspect a user to have enabled 2-step authentication and therefore target some of his contacts to access the chat logs.

Such an attack is significantly mitigated, and deterred, by the adoption of end-to-end encryption. The detection of new devices can be cryptographically enforced and previous message history not accessible to an attacker capable of intercepting an SMS.

I think the lesson from this might be something like:

Always use end-to-end encryption. As the underlying authentication layer can be spoofed, verify fingerprints for important communications.

Double Ratchet & the Quantum Computers

Thu, 07 Apr 2016 15:00:00 +0200

The double ratchet was previously known as the Axolotl ratchet.

With recent developments in quantum information processing and computation, there has been a lot of chatter about moving to post-quantum cryptography. The NSA and NIST have already called for the standardization of post-quantum crypto and its swift adoption.

Replacing some primitives is easier than others. Doubling symmetric key sizes suffices to counter the key space search speedup provided by Grover search which requires work proportional to the square root of the size of the key space.

Replacing public-key systems appears to be a more challenging, requiring to move to new primitives who derive their hardness from entirely different problems. Most of those problems have been around for some time and the hardness from the general problem is reasonably well understood. But when it comes to instantiating specific instances and working on side-channel resistant implementations, we’re still in infancy.

Other factors such as significantly longer key sizes are hindering adoption. Whether a trade-off is acceptable or not depends on the context. Hash-based signatures are a very elegant construction that could already be used when signature sizes are negligible compared to the size of the signed content such as software updates. Adam Langley wrote a brilliant post explaining how they work.

Algorithm	Public key size (bits)	Private key size (bits)
Ring-LWE	6595	14000
NTRU	6130	6743
Hash signature	36,000	36,000
Goppa-based McEliece	8,373,911	92,027

Some mobile messaging apps are experimenting with post-quantum primitives such as PQChat that is using McEliece for message encryption. While McEliece is a nice primitive, the PQChat message encryption protocol has not been independently studied and documented. End-to-end encryption protocols such as OTR or the double ratchet use ephemeral keys extensively to provide strong perfect forward secrecy. 8Mb public keys are making it hard to engineer any kind of protocol with similar forward secrecy features that would work well on mobile, knowing that the double ratchet sends a new ephemeral DH key with every message.

This led me to think about what protection the double ratchet actually provides against an adversary who can use a quantum computer to break the ratchet’s DH primitive.

If you’re not familiar with the double ratchet, the Open Whisper Systems blog has a very good post about it. As its name suggests, it combines two kinds of ratchets, namely a Diffie-Hellman ratchet and a hash-iterated one.

The ratchet is initialized with a RootKey that is derived from a key exchange, in the case of Signal or WhatsApp, that is the 3DH key exchange.

MK      CK      RK      CK      MK
--      --      --      --      --
                |
                |
      PRF(RK, ECDH(A1,B0))
               /|
              / |
             /  - PRF(RK, ECDH(A1,B1))
     CK-A1-B0   |\
         |      | \
MK-0 ----+      |  \
         |      |   CK-A1-B1
MK-1 ----+      |       |
         |      |       +---- MK-0
MK-2 ----+      |       |
                |       +---- MK-1

An important fact is that each new RootKey is derived through a PRF from a previous RootKey and the output of DH key agreement. The fact that it is derived, not only from a DH agreement, but also from a previous value is a valuable mitigation when we think about the threat posed by quantum computers. If the PRF used for the derivation is secure, then even if the adversary can break the ephemeral DH part, he won’t be able to recover the new RootKey without the previous one.

A consequence of that design, is that an adversary has to record every single message since the session initialization or he loses his capability to decrypt any subsequent messages for future messages, even if he can continue to break the ephemeral DH. If the adversary didn’t intercept the 3DH key agreement, he would not be able to decrypt any subsequent messages.

That’s a really cool property of the protocol. ZRTP has similar property if key continuity is implemented (not the case in Signal) but most other protocols (MTProto, SSH, Threema …) do not have that feature.

While I do think it’s important to move to new primitives soon, cryptographic protocols can be used to mitigate the risk of anyone being able to break your public-key primitives by relying on well-proven symmetric key systems. Most people compare products solely on the primitives or key sizes, making abstractions of protocols and implementations, which are the global picture that truly matters.

My TEDx Talk

Wed, 16 Mar 2016 23:00:00 +0100

I gave a TEDx talk in Brussels on the 14th of March on the topic of master keys. Giving a TEDx talk is a very challenging and intimidating experience for anyone who is not an english native speaker since the bar is so high and most speakers have extensive public speaking experience.

Transcript

Last August, I was getting ready for a trip to the United States. After packing my luggage, I thought it would be useful to have a lock to protect some valuables in my luggage both while traveling and when I was hiking, leaving luggage behind. After a little bit of searching, I found my lock in the closet. It seemed the lock could be unlocked either by entering a digits combination or by opening it with a key. But I couldn’t remember where I left the key.

Well, it turned out, I didn’t have the key.

It wasn’t even given to me when I bought the lock.

After 9/11, the Travel Security Agency was created in the US to “protect the nation’s transportation system”. The TSA made two partnerships to develop locks that they could open to inspect luggage without having to break the locks. They would do this by adding a key slot that could only be opened by the TSA keys. These locks became mandatory when traveling to the United States and any other lock would just have to be destroyed.

While the measure was of good faith after a horrendous act of terrorism, the results were really disappointing.

TSA agents cut these locks off despite having the keys in more than 3500 cases in 2011 alone. A report concluded that there was a lot of uncertainty about the efficiency of the measures after observing increased luggage theft of both valuable goods as well as dangerous ones such as guns. Such thefts have raised concerns by national security officials that the same access might allow bombs to be placed aboard aircraft. And things got worse.

As I was traveling, someone on the Internet figured out that the Washington Post had posted pictures of the locks online, almost a year before.

From there, a range of events unravelled really quickly. Within 10 days, a group of lock-picking enthusiasts had modeled the keys in high resolution and used 3D printers to reproduce the set of keys. The model can now be downloaded from the code-sharing website GitHub and reproduced by anyone with a 3D printer, in minutes.

Whatever security I could have had from my lock was at that point completely gone. Of course, these locks aren’t very safe to begin with, but now not even lock picking skills are required to unlock them. Anyone can.

While these locks were meant to make us safer, they turned into a security nightmare. Let me give you another example.

This key, known to firefighters as the Yale 1620, gives you full access to any elevator in New York City. That means you can lock down any elevator in any skyscraper in NYC. But it also unlocks all the subway emergency exits and entries to any construction site in the city. Firefighters and national security officials have been describing the key as the ultimate terrorism tool if it ends up in the wrong hands.

Last September, a reporter from the New York Post revealed that the key could be acquired online for $8. I’m really not sure how people of New York City feel about realizing that they could be trapped at the top of a skyscraper or bombs could be placed in the subway tunnels by anyone willing to spend $8 on this key.

While both of these measures were trying to address very important issues, the way they were implemented ended up considerably weakening the security of these systems in general, instead of making them safer. The fundamental issue is the destruction of diversity which gives natural strength to the system.

Where previously a bad guy needed 300 million different keys to break into those locks, he now only needs to 3D print this set of keys. The TSA isn’t going to replace all 300 million locks that are unlockable with the keys that are available online. And New York City won’t be able to change hundreds of thousands of elevator locks overnight. While the city of New York is going to try and outlaw the ownership of those keys, about 50 people have already been arrested, thousands more will get a copy distributed as a file. The scale of these weaknesses make it so expensive and time-consuming to replace that about a decade will be needed to move away from those broken locks. And that is, if we get them to care enough.

In a recent piece in the Intercept, a TSA spokesperson reveals they don’t really care about the locks being compromised, citing them as being “peace of mind” devices, admitting that they never intended them to be safe anyways. Well, that’s reassuring.

There has to be a solution, there has to. As the quote says:

“For every complex problem there is an answer that is clear, simple,”

and wrong …

This universal key, sometimes referred as golden key is a perfect example of this. On paper, a master key that would allow the TSA to unlock luggage in the search for bombs sounds completely reasonable, but in practice the key will leak and everybody will end up being less safe.

I can give you a lot of other examples. I’m not a lock picker, but I do work with locks, digital ones.

If I were to ask to anyone in the audience if I could take their smartphone and post the content of it online, I doubt anyone would take me up on that offer. Whereas your luggage lock may only protect a few valuables, your phone’s passcode protects your thoughts, memories and most personal moments and information. Compromise of phone backups have been ruining careers and lives. Our phones have become an extension of our brains, an extension of the mind. They remind us about what we forget. They illustrate our memories with the pictures we take. They keep our most personal secrets. Realizing that the mental process can occur somewhere else than in the brain is something we need to start accepting as we’re increasingly connected and dependent on technology to make decisions on a daily basis.

Our phones are also our gateway to the Internet. It is often said that the Internet was not designed for the scale it has today since it was primarily designed to meet the needs of the ARPANET network that was connecting labs across the US. But, in the context of the ARPANET, thousands of miles of Internet cables were considered trusted. The Internet was not designed with security in mind. While many of the assumptions were reasonable for the ARPANET, the threat model has changed quite a lot. The Internet has been militarized and bad guys are running all sorts of hacking and sniffing operations on the Internet backbone.

When email was invented, it was not designed with an adversarial threat model. In the email protocol, it’s trivial to send an email as someone else. Just google it, it will take you 5 minutes, or less.

Email was not designed to be private either. A few weeks ago, I had to get paperwork filed with the Belgian Embassy. It turns out, that the email server of the diplomatic services worldwide doesn’t accept any mail over an encrypted connection. This means that anyone with network access between my email server and the Belgian Embassy email server can read my mail. This has to be fixed. Think about the consequences of this for a journalist or human rights worker in China or Iran.

We need to go the full distance. We can design messaging services that work the way users would expect, where messages are only readable by the sender and the receiver, and not by the creepy postman who has been reading your mail.

The security community has been working on making a lot of these tools safer. And we’re getting there.

The debate about backdoors is often framed in the press as being a debate between privacy and security. This is a false dichotomy. Privacy is the power of being able to selectively disclose your identity to others. You can’t have privacy without security. You can’t have privacy if you can’t technically enforce ownership on your data. Backdoors won’t make us safer either : introducing a master key in the system, as we’ve seen, weakens the security for everyone. Making us more vulnerable to theft and espionage, at scale.

As companies and nations have been been failing to protect human rights such as privacy, we have been developing tools that protects those rights relying on the laws of nature, rather than the laws of nations. As these tools are making it into the mainstream, there is some push back against these technological advances from regulators and spying agencies who are unhappy about their job becoming harder. Now that the technology is mature, it is our duty to make sure that we can keep on using it to protect our rights.

Thank you.

Video

Special thanks to Romain Ruetschi, Jessica Jacobs, Dylan Bourgeois, Nadim Kobeissi, Xavier Damman and Arnaud Benard for reading and providing feedback on previous versions of this transcript.

Update (10th June 2016) : Added video of the talk.