The rise of mass protests over the past year—in Hong Kong, India, Iran, Lebanon, Zimbabwe, and the US—has presented activists with a major challenge. How do you communicate with one another when Internet connections are severely congested or completely shut down and at the same time keep your identity and conversations private?
One heavily promoted solution has been Bridgefy, a messaging app that has the financial and marketing backing of Twitter cofounder Biz Stone and boasts having more than 1.7 million installations. By using Bluetooth and mesh network routing, Bridgefy lets users within a few hundred meters—and much further as long as there are intermediary nodes—to send and receive both direct and group texts with no reliance on the Internet at all.
Bridgefy cofounder and CEO Jorge Ríos has said he originally envisioned the app as a way for people to communicate in rural areas or other places where Internet connections were scarce. And with the past year’s upswell of large protests around the world—often in places with hostile or authoritarian governments—company representatives began telling journalists that the app’s use of end-to-end encryption (reiterated here, here, and here) protected activists against governments and counter protesters trying to intercept texts or shut down communications.
Over the past few months, the company has continued to hold out the app as a safe and reliable way for activists to communicate in large gatherings. Bridgefy's tweets embrace protestors in Belarus, India, and Zimbabwe, not to mention the Black Lives Matter protests throughout the US. The company has also said its software developer kit can be used to build COVID-19 contact tracing apps.
Just this month, on August 10, this article quoted Bridgefy cofounder and CEO Jorge Ríos saying: “Last year, we became the protest app.” Up until last week, Bridgefy told Android users via the Google Play Store, “Don’t worry! Your messages are safe and can’t be read by those people in the middle.” The company continues to encourage iOS users to “have secure and private conversations” using the app.
But now, researchers are revealing a litany of recently uncovered flaws and weaknesses that show that just about every claim of anonymity, privacy, and reliability is outright false.
Unsafe at any speed
In a paper published on Monday, researchers said that the app’s design for use at concerts, sports events, or during natural disasters makes it woefully unsuitable for more threatening settings such as mass protests. They wrote:
Though it is advertised as “safe” and “private” and its creators claimed it was secured by end-to-end encryption, none of aforementioned use cases can be considered as taking place in adversarial environments such as situations of civil unrest where attempts to subvert the application’s security are not merely possible, but to be expected, and where such attacks can have harsh consequences for its users. Despite this, the Bridgefy developers advertise the app for such scenarios and media reports suggest the application is indeed relied upon.
The researchers are: Martin R. Albrecht, Jorge Blasco, Rikke Bjerg Jensen, and Lenka Marekova from Royal Holloway, University of London. After reverse engineering the app, they devised a series of devastating attacks that allow hackers—in many cases with only modest resources and moderate skill levels—to take a host of nefarious actions against users. The attacks allow for:
- deanonymizing users
- building social graphs of users’ interactions, both in real time and after the fact
- decrypting and reading direct messages
- impersonating users to anyone else on the network
- completely shutting down the network
- performing active man-in-the-middle attacks, which allow an adversary not only to read messages, but to tamper with them as well
Impersonation, MitMs, and more
A key shortcoming that makes many of these attacks possible is that Bridgefy offers no means of cryptographic authentication, which one person uses to prove she’s who she claims to be. Instead, the app relies on a user ID that’s transmitted in plaintext to identify each person. Attackers can exploit this by sniffing the ID over the air and using it to spoof another user.
With no effective way to authenticate, any user can impersonate any other user, as long as an attacker has come into contact with that user (either one-on-one or in network-wide broadcast messages) at least once. With that, the attacker can pose as a trusted contact and trick a person into revealing personal names or other confidential information, or take harmful actions. The lack of authentication can also give rise to eavesdropping or tampering of messages.
Here’s how: When hypothetical Bridgefy user Ursula messages Ivan, she uses Ivan’s public key to encrypt the message. Ivan then uses his private key to decrypt the message. With no cryptographic means to verify a user’s identity, an attacker—say, one named Eve—can impersonate Ivan and present her own public key to Ursula. From then on, Eve can intercept and read all messages Ursula sends to Ivan. To tamper with the messages Ursula or Ivan send, Eve impersonates both parties to the other. With that, Eve can intercept the messages each sends and change the contents or add malicious attachments before sending it on to the other party.
There’s a separate way to read encrypted messages, thanks to another major Bridgefy flaw: its use of PKCS #1, an outdated way of encoding and formatting messages so that they can be encrypted with the RSA cryptographic algorithm. This encoding method, which was deprecated in 1998, allows attackers to perform what's known as a padding oracle attack to derive contents of an encrypted message.
Bleichenbacher strikes again
By carefully modifying the ciphertext, sending it to a targeted phone, and monitoring the phone's reaction, an attacker can learn the underlying plaintext contained in the ciphertext. In this particular attack, the padding oracle can be built on compression that Bridgefy uses to reduce the load on mesh networks. This is a variant of the so-called Bleichenbacher attack—named after its discoverer Swiss cryptographer Daniel Bleichenbacher—which has been the source of other crippling encryption flaws, including the HTTPs attacks known as DROWN and ROBOT.The utility of the Bleichenbacher attack devised against Bridgefy is limited because it takes about 14 hours to complete. Still, it could be useful in the event police obtain a phone following the arrest of its owner. The attack may also be feasible in protests where targeted activists stay holed up in protest camps for extended periods of time.
It’s not a vulnerability... it’s a feature
Two other attacks don’t exploit Bridgefy vulnerabilities, rather these attacks target features developers intentionally designed to add app capabilities. One attack allows police or counterdemonstrators to build detailed social graphs of users connected to a network.
It works because all one-to-one messages contain the sender and receiver IDs in plaintext. The result is that anyone with physical presence can build a social graph of which IDs are communicating with every other ID over a given mesh network. The adversary can then use publicly available programming interfaces to query Bridgefy’s Internet server for the usernames that correspond to the IDs.
In many cases, users—whether individual or those who are included in a social graph—can be tied to real-world identities thanks to another design feature that lets users find friends who are also using the app. When users verify their accounts, they’re required to provide their phone numbers. Other users, whether verified or not, can then use a Bridgefy API to identify anyone in their contact list who has a verified account.
By using a phone that has every local or even national number in its contacts database, police or counter protestors can use this feature to obtain the phone number of any verified user. Until last December, Bridgefy required verification for every account. Since then, verification is an option.
An adversary can also track individual users’ movements in a crowd by building a rough topology of the network as it evolves in real time. This attack is possible because Bridgefy sends three receipts when a message is received: a “mesh reach” in cleartext, an encrypted “delivery” receipt, and an encrypted “viewed” receipt. The technique works because users who are further away from each other will experience a longer delay between a message and its receipts.
Another attack that results from design decisions, and a lack of defensive programming, is a “zip bomb” that completely shuts down a network. As the name suggests, it works by sending a compressed zip file in a broadcast message that’s beamed to all connected users. When carefully crafted, the attachment is about 10 kilobytes when decrypted, but it balloons into more than 10 megabytes as soon as it’s unzipped.
The massive size causes the Bridgefy app to crash. Each time a user restarts the app, it will once again unzip the file and experience the same crashing error again. With all apps connected to the network repeatedly crashing, the network completely shuts down. The only way to recover is to reinstall the app, but there’s nothing stopping an attacker from repeating the attack again and again.
Back to the drawing board
The researchers notified Bridgefy of their findings in late April. The app maker has yet to fix any of the vulnerabilities but said it is in the process of completely overhauling the messaging internals to use the Signal protocol, the widely trusted open-source cryptographic engine that drives both the Signal and WhatsApp apps.
In a statement, company officials wrote:
After we received the Royal Holloway University of London research team’s findings, our original approach was to work quickly to fix the current Bridgefy SDK so we could release a security update to the app stores. Once we started digging deep into how we would do this, however, we realized that the SDK’s current security model was based on a design that was appropriate for when Bridgefy was a small startup, but not for the scale it has today and the growth we want to achieve in the future. Fixing the reported issues would be hard to do and the solutions would not guarantee a healthy security position for our product.
Because of this, we decided to think outside the box and consider the possibility of rewriting our entire model from scratch, designing a new one that would get rid of all the reported issues right off the bat. Trying not to reinvent the wheel, we searched for an existing solution that we could use that was already validated by the industry and security experts and this is when we found the Signal Protocol.
By using this open-source protocol we are going to add a very robust end-to-end encryption mechanism to our SDK, making our users feel more confident to use our product given that this solution is already used by millions of people around the world through messaging apps like WhatsApp and Signal. Most importantly, we will be delegating all the security heavy lifting to the real experts and focusing more on the actual peer-to-peer mesh technology that makes our company and our SDK unique.
In terms of engineering progress, we have already begun testing a version of our SDK internally that lacks the previous outdated security layer and now encrypts messages between devices using the Signal protocol, thus fixing all of the most severe security issues reported. We are also adding another security layer that will encrypt all the SDK control messages on a per-app basis so only users from the same app can understand the messages sent through the app’s mesh.
The statement went on to thank the research team.
In June, the app maker began issuing tweets like the ones here, here, and here that correct earlier statements and acknowledge the app, in fact, doesn’t provide end-to-end encryption and shouldn’t be relied for sensitive communications.
But the company continues to send mixed messages. The App Store and Play Store promotions mentioned earlier give the impression Bridgefy can be trusted to keep messages private, even though it has been clear to the company since April that they can’t. Tweets that continue to refer to mass protests and welcome activists using the app are another example.
It’s unclear how widely used the app is, despite the company touting the 1.7 million installs the messenger has, with more than 1 million in the Google Play Store alone. A fair number of comments there reported that the app doesn’t work well or at all. It’s also hard to find evidence of large grass-roots embrace of the app from protestors. It’s possible that the majority of people who downloaded the app don’t actually use it.
Even if that’s the case, the rise of Bridgefy is a cautionary tale about putting trust in apps that promise security, privacy, and resiliency in adverse settings. That’s particularly true for messaging apps that—unlike Signal, WhatsApp, and Telegram—are designed to work when there’s no Internet service available.
“Our work ... draws attention to this problem space,” the researchers wrote. “While it is difficult to assess the actual reliance of protesters on mesh communication, the idea of resilient communication in the face of a government-mandated Internet shutdown is present throughout protests across the globe. Yet, these users are not well served by the existing solutions they rely on. Thus, it is a pressing topic for future work to design communication protocols and tools that cater to these needs.”
"that" - Google News
August 24, 2020 at 07:00PM
https://ift.tt/2YrI7iw
“Protest app” Bridgefy is full of flaws that threaten users everywhere - Ars Technica
"that" - Google News
https://ift.tt/3d8Dlvv
Tidak ada komentar:
Posting Komentar