Live-capture forensics of a CIN injecting fake Chrome install | Hacker News Reader

Live-capture forensics of a CIN injecting fake Chrome install

cryptostorm.org

40 pointsepsylon15 comments

Open articleView on HN

I manage SSL operations at Google and, as far I can tell, this is all nonsense.

It's too long to deal with point-by-point, but I can do a few:

* It's not odd that a cert for * .google.com would be served for google.fr. Check the SANs.

* Google does not use EV certificates.

* Google's frontends have many IP addresses. Seeing differences at different times and places is normal.

* Our leaf certificates really are issued for only a few months.

* We will be off SHA-1 by the end of the year but, at the time the article was written, one certainly could have received a SHA-1 signed certificate from us.

* http://clients1.google.com/ocsp is our OCSP responder and, yes, you'll get 404 unless you send a correct OCSP request with a Host header.

I just came here to point out the same thing. This is just the ramblings of someone with a medium level of technical experience and a high level of paranoia drawing some very odd conclusions.

Excellent to hear from a confirmed source, this initially read very tiny print Dr. Bronner bottle to me as well, but I wasn't sure.

Lots of nonsense here. Google routinely generates new ssl certificates with low TTLs. Anycast DNS will yield changing IP addresses over time and also between networks. Netscape-remote sounds like something that hails back to the Netscape 4.x era where, I believe, there was a command line argument to open a web page in an existing browser session by specifying -remote and the URL. 1e100(.net) is the value for a "googol" and it's pretty well known to be used in google's reverse DNS. And I can totally see sha1 still in use to maximize browser support, especially for a web page that is likely set as browser homepage on millions of outdated computers and android 2.x era phones. Anyways, don't use reverse DNS to try to determine IP ownership - looking up the netblock owners in WHOIS is much better.

This appears to be a conspiracy theory. As far as I can tell, they have no evidence the Chrome install has been maliciously modified, no evidence that the certificate or IP address is fake, and are spouting nonsense about faking SHA1 hashes (which as far as we know no-one can do, and would be easy to detect and prove).

Hah. I knew it was too juicy to be true.

Very long article that is worded vaguely (a Corruptor-Injector Network? Wtf.)

From what I understand:

TL;DR: CDNs often have certificates that are valid for a lot of domain names[1]. Getting a valid certificate for any of these would allow you -- or an intelligence agency -- to hijack the https connection via MITM, and in this case, serve an altered binary (e.g. malware) instead of the real Google Chrome browser.

[1] More info: http://security.stackexchange.com/q/23042/10863

Ah, that's one way to handle the cert issue. I think the article alludes to kinda brute forcing another sha1. That's pricey, but potentially worthwhile, I suppose.

As for the routing: you have seen BGP issues crop up, right? I think Turkey took Youtube offline for a while, when they intended only to block it within their borders. I wish it took the resources of an intelligence agency to screw up routes.

That's a separate problem, the "Cloudflare MITM as a service" issue.

Seeing a multi-domain cert from Google is kind of strange. They certainly don't need to share IP addresses or certs.

Google has a lot of domains, most of which support SSL. If they didn't use SAN certificates, they'd have to allocate an IP address for every domain in each of their locations, which could get pretty complicated. Much simplier to just use one big certificate for everything!

A very long article that, in the end, says nothing. They're chasing at moonbeams. Here's my analysis:

1. The author gets confused by the fact that the SSL certificate used by Google uses the SAN (Subject Alternate Name) extension to allow it to be valid for multiple domain names.

2. The author expects Google's web site to have an EV certificate, which it does not, and assumes that this is a sign of malicious activity.

3. The author misinterprets some run-of-the-mill CSS warnings as malicious activity.

4. The author misinterprets SSL Labs' lack of an EV certificate as meaning that SSL is not operating on their site at all. (Even though it looks exactly the same in the browser as the Google site they saw earlier.)

5. The author gets confused by Google's use of multiple IP addresses.

6. The author is surprised that anybody can point a DNS record to a Google IP address, and gets confused by the fact that one particular indexing site (Robtex) lists some of these records first.

7. The author sees something unusual about the DNS for Google Tag Manager (http://www.google.com/tagmanager), but doesn't give enough details for us to figure out what it is.

8. The author is surprised that Google is still using SHA1 for a short-term certificate. (To be fair, I'm a little surprised by that too, but I'm sure they have their reasons.)

9. The author expects an OCSP responder endpoint to be viewable in a web browser, and is perturbed when it is not.

10. The author is surprised that not all of Google's short-term certificates are described online, and that there are a lot of them.

11. The author is surprised that Google has a variety of different IP addresses and SSL certificates, and that their visibility may change.

12. The author imagines this all to be part of some vast conspiracy.

13. The author examines the perfectly good Chrome package s/he downloaded, and is confused by its use of the standard "netscape-remote" protocol.

14. The author draws some parallels with a completely unrelated Gmail outage, and draws the whole thing to some strange sort of conclusion.

About all I can conclude is to stay far away from their VPN service. If they can get this confused by a perfectly normal situation, I'd hate to see them trying to investigate a real security threat.

Might I ask why the title on this was changed from "Live-Capture Forensics of Corrupt-Injector Network Injecting Fake Chrome" to "Live-Capture Forensics of Corrupt-Injector Network Installing Fake Chrome"? There's quite the difference between the two verbs in this context. The CIN doesn't perform any install on the user's machine. The original "... injecting fake chrome install" title from the thread makes most sense.

I've been trying to figure out that attack from the posting, which is months old. They have SSL certs for Google sites which they argue are bogus. They're both signed by "Google Internet Authority G2", using a certificate that expired on 04/04/2015.

Firefox has two pre-installed certs for "Google Internet Authority G2", one of which is still valid, and the other (serial 02:3A:69) has expired. The expired one may have been compromised, allowing the creation of sites which can impersonate Google sites. It's hard to tell from that article, though.

An expired cert in the cert chain will not validate.

The attack reported in the original posting happened when that cert was valid.

Reply on news.ycombinator.com