5 ms·
That's one hell of a tinfoil-hat theory. How would you even orchestrate that from within a public company with so many developers involved?
by eljimmy 7y ago
That'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.