Hacker News Reader

Comment by eljimmy | Hacker News Reader

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?

View on HN

As 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.

Is 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.

We're talking about a company owned by Facebook, right?

My 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.

I don't think that's true? Increasing build security is about limited the number of folks who can modify the process. That's orthogonal to auditability.

Fair Point. It is orthogonal, but it is often correlated in practice. Quite often permission systems to prevent modification are also used to prevent visibility.

I'd also say it's not completely unrelated. Let's consider a hidden build machine process. Once you've hidden that, preventing modifications to the build process by people "not in the know" makes it much less likely that said process can be discovered (either on purpose or accident) If everyone can and does have full access to those build machines it increases the likelihood that someone making a modification could run into said process.

My 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.

Its 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.

It'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.

Boeing'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.

That 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?

It 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.

You just need to control the upstream libraries and have some subtle memory overflow. No dodgy commits other than a "update libXYZ to latest patch".

Well, 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.

It'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.

What if I hire 20 mediocre security engineers and 1 malicious product engineer? This argument can go both ways...

What argument? What's your point?

Please read the Snowden files on PRISM and similar.

Considering 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.

Are 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-t...

I 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.

Warrant 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

I would just point out there is a very clear legal distinction between action and inaction. Further, all of this only applies to the issuance and proper service of an order compelling silence. I think the EFF’s common statement that if the canary requires affirmative action to not deploy the court is in a tough spot to compel that action. Also, I can say with a large amount of certainty, that no judge blatantly ignores procedural or semantic formalities out of hand. The judge in question may way the relevant factors and disagree with an argument, although some judges built caseloads of precedent on just such minor quibbles, but it is literally the judges job to at least consider a technical argument on its merits.

Your comment reinforces my point. Google would be extremely reluctant to utilize warrant canaries because of the uncertain legal consequences of doing so.

The same applies to declining to cooperate with government surveillance operations. We don't really know how the government likes it when a big company obstructs its surveillance goals.

On HN today was a headline about Apple reversing course on a business decision voluntarily, simply to please government.

> I'm also not sure how warrant canaries relate to your parents' point.

The points above I believe link the two business decisions.

There were a bunch of Google engineers who worked through Christmas that year who sure we're pretty pissed off about the unexpected work and were furious at the NSA.

Of course. Most Google engineers would not be involved in it, and would of course be doing their best to keep Google's customers' data secure.

Yes, but security engineers know about "break ins". It's impossible to hide that kind of thing from the people who's job it is to investigate.

Can you elaborate on the google data center breach? Are you saying it was orchestrated by google?

Not 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.

I was at Google at the time of the Snowden disclosures. People there were furious, and encrypting internal traffic became a top priority immediately afterwards.

Of 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.

Was this reported in the news? Why did I not hear about it?

Reply on news.ycombinator.com