12 ms·
Pavel Durov argued that WhatsApp's vulnerabilities are intentionally created as part of surveillance programs with government agencies. [1] If that were true,
by rmsaksida 7y ago
Pavel Durov argued that WhatsApp's vulnerabilities are intentionally created as part of surveillance programs with government agencies. [1]
If that were true, Bezos's case would be an example of how that approach to security is double-edged. Backdoors can be just as useful to foreign intelligence as they are to whoever pushed for their implementation.
[1] https://t.me/s/durov/109 https://t.me/s/durov/109
- eljimmy 7y agoThat's one hell of a tinfoil-hat theory. How would you even orchestrate that from within a public company with so many developers involved?
- resters 7y agoConsidering how few developers understand the subtleties of security, it would not be all that difficult. Also, FWIW we know that Google did this with its data center breach and likely many other cases. At WhatsApp/Google scale the attack is extremely cost effective.
- ghostpepper 7y agoCan you elaborate on the google data center breach? Are you saying it was orchestrated by google?
- resters 7y agoNot orchestrated, but happily tolerated. All Google needs is to be able to plausibly deny complicity, but the other practices of Google (such as not offering warrant canaries on all Google accounts) indicate that Google is eager to cooperate and please governments, so it would have been easy to leave a few doors unlocked, hire a plant (with solid itsec skills), etc.
- ghostpepper 7y agoWas this reported in the news? Why did I not hear about it?
- ta999999171 7y agoSnark for your snark: you don't read enough in the right places?
- nostrademons 7y agoI was at Google at the time of the Snowden disclosures. People there were furious, and encrypting internal traffic became a top priority immediately afterwards.
- resters 7y agoOf course. That is the correct response once the attack is known. To most people, unencrypted traffic vs encrypted traffic seems like an obvious security oversight, but many others exist that are not so stark and obvious sounding. My point is that all indications point to Google being unbelievably cooperative with the US Government, essentially allowing whatever legal or extralegal (per Snowden) back doors were requested. It is not much of a leap to conclude that Google was both aware and cooperative with the harvesting of unencrypted traffic. This does not mean that all employees were aware of it. The analysis should be to discover how few employees would have had to be complicit for the attack to be carried out successfully. There is no way that such an attack would succeed if too many were aware, since it is obviously in the extralegal (Snowden revelation) category, and since most Google employees are ethical humans, it would have provoked outrage if widely known.
- deleted 7y ago[deleted]
- aodin 7y agoAre you referring to the data center breaches exposed by the Snowden leaks? Because Google claimed that they were unaware of the breach and quickly took action to correct it [1]. Are you suggesting that Google was complicit? [1] https://www.zdnet.com/article/meet-muscular-nsa-accused-of-tapping-links-between-yahoo-google-datacenters/ https://www.zdnet.com/article/meet-muscular-nsa-accused-of-t...
- resters 7y agoI don't think Google has given us any reason to believe that it was not complicit. For instance, why not include warrant canaries on gmail accounts? There is not really any fundamental difference between abetting the data center breach and opting not to offer warrant canaries. Likely tens of thousands of Google users are searched every day due to easy FISC warrants and wide investigative nets. The state sponsored attacks on Google would of course allow Google to plausibly deny cooperation, but obviously Google has every incentive to cooperate fully, as is evidenced by the lack of warrant canaries.
- iudqnolq 7y agoWarrant cannaries are of dubious legality and have yet to be seriously tested in court. It makes total sense that a large company would not adopt something potentially illegal. A person on StackExchange put it well > The distinction between revealing the existence of the subpoena by action, rather than by inaction, is a false one. It's exactly the kind of cutesy legal formality that non-lawyers love to rely on, but real judges ignore. If you tell someone: "Hey, you know John Smith's three sons, Joe, Ted, and Bill? Joe and Ted are good people; they have never molested any children. As for Bill--well, I don't have anything to say about Bill." If Bill is not a child molester, you have defamed him, and you are not going to convince a judge otherwise. [1] Here's how the EFF puts it. > Are there any cases upholding warrant canaries? > Not yet. EFF believes that warrant canaries are legal, and the government should not be able to compel a lie. To borrow a phrase from Winston Churchill, no one can guarantee success in litigation, but only deserve it. I'm also not sure how warrant canaries relate to your parents' point. [1]: https://law.stackexchange.com/a/333 https://law.stackexchange.com/a/333
- rtkwe 7y agoMy first pass at a way would have some point in the code where various hooks can be triggered for a feature like downloading a file under the guise of creating previews of various types of files and simply have the production build sent to the Google Play store include an additional small plugin that looks for a specific header and then hands over the keys to the kingdom to whatever payload it finds. It's simple and there's generally a very small portion of people looking at the disassembled code from the Play Store. You could even have it produce two versions one for any internal testing on the live version and one with the small backdoor plugin. Doing it this way you only really have to control a core part of the release team to hide the slight of hand between the published version and the clean 'published' version. Alternatively just bury the same thing deep in the codebase using techniques like people use for the Obfuscated C competition every year. Any changes could be delayed/deprioritized/handled by a team in the know about the backdoor.
- tmpz22 7y agoIts probably easier to just bribe/compromise the on-site DBA who has access to the physical hardware. Dump the raw data and decrypt/analyze it offsite.
- rtkwe 7y agoIt's a little unclear what was actually compromised in this if it was just what was available WhatsApp on their end that's definitely an easy way. If it's more that WhatsApp was being used to read more data from the phone than what had already been sent via WhatsApp (or if WhatsApp doesn't have access to things sent because it's E2E encrypted) it'd require something more complex than that.
- ottowinter 7y agoWell, it doesn't have to be that complicated. Just underfund the security department, don't adopt systems/languages that prevent the worse bugs, and keep the core protocol proprietary. On the other side let the governments invest in operations to hack the product.
- Arelius 7y agoAs an engineer that has basic permissions to our build and deployment system (unrelated non communication application) I could pretty easily think of multiple steps in the build where I could inject and link in pretty much arbitrary code. For instance, anything that can hook directly on a build machine, or artifact upload, or even just simply precompiled into one of the black-box 3rd party dependencies that basically never get recompiled. All of these mechanism have vectors that would be easy to obfuscate and don't rely on any changes to any repo code. I think there is a good chance that a normal engineer could likely hide something that could make it into a final build product. Now, combine that with the fact that even the most open of companies have some sort of protected infrastructure (Could be permissions on an S3 bucket, locked data-center or even just a locked away Cat-5 cable in the process. Someone high in the org could easily inject some process that could stay hidden from even the most prying of internal eyes. Now, while I agree that it's a bit tinfoil-hat-y to believe that this actually -is- happening. I absolutely believe that the technical capability is both there and well within practical effort. And combine this with a few bad incentives it's easy to see how it -could- happen.
- asdfasgasdgasdg 7y agoIs the "our" you're referring to Whatsapp? If not, then I'm not sure how much we can derive from your experience. There are places that take build and deployment security much more seriously than what you're describing.
- ta999999171 7y agoWe're talking about a company owned by Facebook, right?
- Arelius 7y agoMy point specifically is that by increasing build and deployment security. You actually are decreasing the amount of people who can potentially review and audit the build. Thus making it more likely that someone in power could introduce a backdoor that nobody else in the large org knows about.
- kunglao 7y agoBoeing's 737 MAX, despite heavy regulations, designed the software to depend on just one sensor. Didn't put any limit on how far down the plane could be pushed. These are not any individual who would do deliberately. I bet these conversations go differently for ex need to certain kinds of debugging vs the improbability of actually pulling off an attack or prioritising a release dealing and making a design decision to implement a feature in a specific way which is intended to be updated later on opening up windows for attack. They would genuinely be improbable unless someone knows that they are there and committed enough to try.
- jonas21 7y agoThat seems to support the argument that security vulnerabilities in WhatsApp are most likely unintentional errors / incompetence. Unless you're suggesting the 737 MAX was intentionally sabotaged as well?
- vokep 7y agoIt supports the argument that code with major flaws (intentional or not) can make it into production with nobody noticing until consequences of that flaw make its existence clear.
- dannyw 7y agoYou just need to control the upstream libraries and have some subtle memory overflow. No dodgy commits other than a "update libXYZ to latest patch".
- eeZah7Ux 7y agoIt's very easy: hire more developers than security engineers. Vulnerabilities will appear and be discovered by the security analysts in your government. Whey they suspect other countries have the same 0days they'll notify you of it and you fix it.
- ta999999171 7y agoPlease read the Snowden files on PRISM and similar.
- iudqnolq 7y agoPavel Durov also said > The encryption of Signal (=WhatsApp, FB) was funded by the US Government. I predict a backdoor will be found there within 5 years from now. He seems to enjoy throwing out loosly supported accusations. He might be right in some of them, but stopped clocks and so forth. He's also been accused himself of deliberately sabotaging the security of his own encrypted messenger app (Telegram). There's no real evidence, but he did hire a bunch of math PhDs to figure out encryption from first principles > The team behind Telegram, led by Nikolai Durov, consists of six ACM champions, half of them Ph.Ds in math. It took them about two years to roll out the current version of MTProto. Names and degrees may indeed not mean as much in some fields as they do in others, but this protocol is the result of thougtful and prolonged work of professionals. [1] Note: Signal, like TOR, is funded in part by the Open Technology Fund of Radio Free Asia, which is controlled and funded by Congress. So far there has been no public evidence that this funding has come with any malicious strings. The stated goal of the fund is to promote democracy in developing countries, and Signal and TOR are obviously in line with that overt goal. Radio Free Asia used to be a CIA front during the Cold War, but there's been no public evidence that the transfer of control away from the CIA to Congress was in any way a sham. [0]: https://techcrunch.com/2017/09/18/signal-moxie-marlinspike-techcrunch-disrupt-sf-2017-telegram/ https://techcrunch.com/2017/09/18/signal-moxie-marlinspike-t... [1]: https://news.ycombinator.com/item?id=6916860 https://news.ycombinator.com/item?id=6916860
- tptacek 7y agoTrevor Perrin and Moxie Marlinspike won the Levchin Prize at Real World Crypto for Signal's cryptography; the Levchin Prize referees are a who's who of academic cryptography, including Dan Boneh, Kenny Paterson, and Nigel Smart; other Levchin winners have included Hugo Krawczyk, Mihir Bellare, and Joan Daemon. Any suggestion that Telegram's cryptography is somehow comparable owing to "half of them Ph.D's in math", or that Signal's extensively-reviewed cryptography is backdoored, is pretty clearly risible. OTF, meanwhile, funded basically the whole of the privacy-preserving cryptography field, for years (they may still, for all I know); for many years, they were simply throwing money at privacy projects to hire 3rd party auditors, none of whom were at all affiliated with OTF (how I know this is that we participated). People who claim OTF is somehow a snakey USG backdooring enterprise are saying more about themselves than they are about any kind of sophisticated understanding of how crypto software is built.
- maximente 7y agoone thing that needs to be accounted for is that, IIRC, we just recently had US AG Barr make a stink about encryption based on Facebook tech (either WhatsApp/Messenger i believe) being some anti-law enforcement issue. does the theory suggest that US DoJ does not know how to exploit these backdoors, but other agencies (CIA/NSA, foreign intel services) do?
- BoorishBears 7y agoThere's no incentive to not publicly make a stink about encryption, even if they have backdoors. If anything there's incentive to do so even if they do, in creating plausible deniability.
- Analemma_ 7y agoWithin days of their launch, Telegram was discovered to have huge vulnerabilities that resulted from them rolling their own crypto: https://news.ycombinator.com/item?id=6948742 https://news.ycombinator.com/item?id=6948742, so I'm not sure they should be throwing stones about other people's bugs.
- ta999999171 7y agoI don't even have to open the link to know those are still theoretical vulns at best...because as far as I know, there has been no successful implementation of them.
- ta999999171 7y agoFull disclosure: I've moved on from Telegram, but I'd use them again in a heartbeat if it was them or a FB owned property.
- ryanlol 7y agoYou’re full of shit. There’s nothing theoretical about that vulnerability (almost certainly a deliberately planted backdoor), it allows the Telegram servers to selectively MITM private chats. > there has been no successful implementation of them. What does this even mean? Only Telegram can perform this active attack, obviously you haven’t seen it implemented.
- ta999999171 7y ago+1, it was not the bugs I thought it was, extracting foot from mouth - sorry.
- sangnoir 7y agoIt's not as if non-WhatsApp zero-days are hard to come by for nation-states. If it wasn't a video shared by WhatsApp, it was going to be an iMessage text PDF appearing to be from one of his assistant's email. I don't think governments need to author vulnerable software: they can outsource that to the private sector for $0 by doing nothing and decompiling/fuzzing/analyzing whatever comes out.
- fidz 7y agoWell, > To protect the data that is not covered by end-to-end encryption, Telegram uses a distributed infrastructure. Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, several court orders from different jurisdictions are required to force us to give up any data. https://telegram.org/faq#q-do-you-process-data-requests https://telegram.org/faq#q-do-you-process-data-requests If we register Telegram, Telegram has our master key. I am not sure they are really that secure. Yes, it makes politically hard to disclose any data, but it does not mean impossible.
- jchw 7y agoTelegram also supports proper E2E in the form of secret chats, though the UX is definitely not as good (for example, last I checked it did not support group chat or multi device.)
- cies 7y agoEDIT: Was under the impression Telegram served closed source clients. Turns out it does not. I stand corrected. OLD COMMENT: E2e using a client that is not opensource (on a system that is not trusted) is not helping much. E2e where the server is not open source should be okay, because the server-end can only snoop on some meta data (how much, when, what IP, chunk sizes, etc.) but not the content.
- tootie 7y agoVulnerabilities are good for intel. Intrusions aren't their concern. If anything it lets them go to Congress and ask for more funding.
- ReptileMan 7y agoThere are no whatsapp vulnerabilities in this case, or encryption breakdown. To exfiltrate a lot of data as the article says to need sandbox escape and privilege escalation.
- Scapeghost 7y ago> WhatsApp's vulnerabilities are intentionally created as part of surveillance programs with government agencies. This has been obvious in places like the United Arab Emirates (aka Dubai) where services like FaceTime etc. (sometimes even voice chat in games) are blocked by the government but they allow WhatsApp (but not WhatsApp voice calls).
- ryanlol 7y agoNot really, Dubai blocks VOIP because phone carriers lobbied for that. This has the added benefit of forcing people to make insecure, easy to intercept, regular phone calls.
- ryanlol 7y agoPavel Durov also shipped what looks very much like a intentional backdoor in Telegram https://m.habr.com/en/post/206900/ https://m.habr.com/en/post/206900/
- coldtea 7y ago>Backdoors can be just as useful to foreign intelligence as they are to whoever pushed for their implementation. Not a big problem if you're the top dog and most foreign countries can't do much in practice even if they have the intelligence...