Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

cryptostorm_team · Post by **cryptostorm_team** » Sun May 17, 2015 9:54 pm

{direct link: cryptostorm.ch/corruptors}

There are times when we, as a team, find it challenging to articulate the scope and danger of Corruptor-Injector Networks, or CINs. The traces of their activity are transient, and even realtime captures result in a complex snarl of routing snapshots, intertwined DNS records, nearly-impenetrable certificate analyis projects, and pcap files that spit out lots of information but little obvious insight. Then add in the fact that a CIN-level footprint on network activity is by definition going to look different depending on the perspective of the observer: someone in the "direct line" of the CIN injection will have one view, whereas someone on other routing pathways won't see anything untoward. Also add in that routing is by its nature fluid over time, and pinning these things down in a way that's compact enough to digest is, currently a big challenge.

In due time, of course, analytic tools and research protocols will develop and we'll look back on today's efforts as being set in the relative dark ages. Such is the nature of work exploring new frontiers in any field, and perhaps more so on a hyper-accelerated one such as emergent network security threats.

This weekend, we were fortunate enough to capture a CIN footprint at work, and we're documenting it here in this thread. Recognizing that some folks find our github repositories cluttered (true), impenetrable (also true, though we're working on it), and intimidating (really not true, but seen as such), we've chosen to post all underlying data here in this thread - it's a bit clunky, but it'll server as a test-case. If there's demand, we can cross-post these materials to our CIN repository, as well.

This isn't an analytic effort to pin down the specific 'session prions' being fed to the client-browser by this CIN attack; those analyses are separate but related to work such as this which documents the network-level evidence of a CIN at work. Together, those two analytic classes form a comprehensive snapshot. This half of the analysis by itself demonstrates that there's CIN-activity afoot in a given network session at a given point in time.

And this is not some minor CIN-inject. Rather, it represents a CIN system subverting https to a core google.com website - used for downloading Chrome browser installer files - via fraudulent certificates and exotic DNS-based hijacking of session transit. We at cryptostorm do not claim to have unwrapped the full details of how this route-hijacking is being accomplished here; rather, we are drawing attention the non-legitimate nature of the network session itself. That's the first step, and we undertake that step here.

These data were captured by a cryptostorm team member, whose network session had the following parameters during this capture:

1. routed securely through a cryptostorm exitnode in fully-functional, secure, and verified state during this capture.

2. using a newly-installed, hash-verfied (package installer as well as repository-validation of legitimacy of the package during initial pull) 'Icefox' Debian-build mozilla browser image (version 31.7.0:

3. running via a manually-configured network framework, as part of a newly-installed Debian kernel (8.0/jessie) with ip6 disabled at the NIC, the kernel (sysctl.conf), the local router, and via grub parameter inclusion pre-boot.

4. resolving domain names via cryptostorm's deepDNS resolver mesh via the node through which the connection was made.

5. transiting a local router with a newly-flashed OS image, manually configured to disable all known avenues for remote exploit

This is all to say that it is highly unlikely - bordering on impossible - that the mechanism for this attack is based solely or even marginally on malicious code or configuration settings found on the local computer that initated this session. Further, every possible network analytic tool was used to confirm the integrity and stability of the cryptostorm network session through which this session travelled (we will discuss the relevance of that at the end of this report).

The session is initiated by pointing a newly-opened icedove window manually at the following URL:

Code: Select all

https://google.com

This URL then redirects to the local google subsidiary for the exitnode cluster in question (Paris, France):

Code: Select all

https://google.fr

Immediately we notice that icedove is not happy with the certificate credentials... although the page still loads without any errors or overt warnings:

A closer look tells us that icedove is receiving both 'secure' and insecure elements in this particular page:

Needless to say, a legitimate page-load of a https-prefixed google page will not include calls to external, insecure resources on load. So already we are seeing problems with this 'secure' network session... problems not caused by google being inexperienced in providing solid https transport from their server facilities.

We capture the certiticate for this page-load, which is included here in PEM (pre-decoding) format. Later, we will look more closely at what the certificate tells us. For now, it is a stepping stone in our analysis. This certificate identifies itself (via CN field) as *.google.com despite being served during a putative session with google.fr (again, this kind of obvious certificate misconfiguration is all but impossible to imagine google doing in production systems):

Code: Select all

From there, a search query is entered for "chrome" with the following result:

Code: Select all

https://www.google.fr/#q=chrome

...from this page, the main link is chosen, which directs us to the following google.com https-served URL. It is important to note that we are now at the core of google's ecosystem - google.com - preparing to download and install their flagship software product - Chrome - directly from them.

Code: Select all

https://www.google.com/chrome/

This page appears as follows:

Note that icedove loads the page as https with no errors or warnings whatsoever. However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example:

If we look behind the scenes of this 'https' google.com page we just loaded, we see there's a cavalcade of render-errors being throw as the page loads from various resources...

When we ask for the certificate from that https-chrome URL (https://www.google.com/chrome/), we get the following PEM blob:

Code: Select all

Here is icedove's summary of the page's identifying information. Note, again, no warning or suggetion this is not a legitimate https session:

The summary of NSS's onboard unpacking of the PEM'd server-side certificate is as follows:

At this point we step back to see what others are seeing, in terms of certificates being provided by this URL (https://www.google.com/chrome/). We turn to @IvanRistic's standard-setting testing toolbox and find some most astonishing results...

Ivan's own website itself is presenting without robust ssl credentials - which we are absolutely sure is not any error on his part, but rather reflects a subversion of the https session between us and the test-results page we've generated (we have that cert captured and will post in the fishycerts repository for analysis).

Equally implausible is the result his page presents (or appears to present, from the perspective of this session-load): www.google.com gets a grade of "B" for https support. Let's look more closely at the results underneath that grade. There's two IP addresses shown as resolved from the two versions of "google.com"

www.google.com resolves to 216.58.192.36
google.com resolves to 216.58.192.46

The rDNS records for each are as follows:

www.google.com reverses to nuq04s30-in-f4.1e100.net
google.com reverses to nuq04s30-in-f14.1e100.net
(note the change from "4" to "14" between the two)

Let's look at the first of those two IP addresses, namely 216.58.192.36. We turn to Robtex for an authoritative snapshot & historical summary, which confirms serious questions are now impossible to ignore (Robtex's https page does load with green-lock EV cert status, at this point). First, we see 86 domain names currently resolving to this same IPv4 address. The full list is:

Code: Select all

    GOOGLEBASE.CH
    199DRESSES.COM
    ADSENSE.COM
    ANDROIDBASED.COM
    ANUPNEUPANE.COM
    C-SEARCH-SOLUTIONS.COM
    DAVERIECK.COM
    FRIIGLE.COM
    FROOGLESTORE.COM
    GEWGOL.COM
    GOOGEL.COM
    GOOGLE4DOODLE.COM
    GOOGLEMAPS.COM
    GPPGLR.COM
    JVAPXFREEGB.COM
    KABBALAH-PERU.COM
    MALUSZKI.COM
    PAGEADGOOGLESYNDICATION.COM
    RECAPTCHA.COM
    SHOWLOSER.COM
    GOOGLE.CV
    IGOOGLE.CV
    ADSENSE.FR
    GOOGLESUGGEST.FR
    GOOGLEWISHLIST.FR
    GWEB.FR
    GOOGLEMAPS.INFO
    GOOGLEAPI.IT
    GOOGLELOCAL.IT
    GOOGLEMOBILE.IT
    GOOGLESHOPPINGLIST.IT
    GDESKTOP.NO
    HENDRO.ORG
    RECAPTCHA.ORG
    TECHNOLOGYISPOWER.ORG
    GDESKTOP.RU
    DMAIL.TK
    BLOGSEARCH.GOOGLE.AT
    GOOGLESUGGEST.COM.BR
    WWW.ENDOXON.CH
    WWW.ANDROIDBASED.COM
    MX.AZERHOST.COM
    HOSTMASTER.E-HARVEY.COM
    WWW.FIBERFORCOMMUNITIES.COM
    ASIA.GOOGLE.COM
    *.MEASUREMAP.COM
    TRACKER.MEASUREMAP.COM
    MX.ROWLETTMTG.COM
    WWW.DARDALION.CZ
    PICASA.GOOGLE.EE
    SCHOLAR.GOOGLE.ES
    PICASA.GOOGLE.FI
    SCHOLAR.GOOGLE.FI
    PICASA.GOOGLE.IE
    PICASA.GOOGLE.IT
    GOOGLE.COM.JO
    BLOGSEARCH.GOOGLE.LT
    GOOGLEMAPS.COM.MX
    NUQ04S30-IN-F4.1E100.NET
    WWW.VBELTRAN.NET
    SCHOLAR.GOOGLE.NO
    WWW.JXHI.ORG
    SCHOLAR.GOOGLE.PT
    SCHOLAR.GOOGLE.SE
    GOOGLE.COM.VE
    WWW.BLOGSEARCH.GOOGLE.BG
    WWW.BLOGSEARCH.GOOGLE.CL
    TBN.L.GOOGLE.COM
    SCHOLAR.GOOGLE.COM.EG
    WWW.BLOGSEARCH.GOOGLE.ES
    WWW.BLOGSEARCH.GOOGLE.GR
    SCHOLAR.GOOGLE.CO.KR
    WWW.BLOGSEARCH.GOOGLE.PL
    SCHOLAR.GOOGLE.COM.PR
    WWW.BLOGSEARCH.GOOGLE.SK
    ALT1.TOOLBARQUERIES.L.GOOGLE.COM
    O-O.RESOLVER.MIKU.L.GOOGLE.COM
    114344.I1.DS.IPV6-EXP.L.GOOGLE.COM
    *.I2.DS.IPV6-EXP.L.GOOGLE.COM
    SFYPA5OQMGT5THB4.IF.V4.IPV6-EXP.L.GOOGLE.COM
    O-O.RESOLVER.HATSUNE.MIKU.L.GOOGLE.COM
    *.SFYPA5OQMGT5THB4.IF.V4.IPV6-EXP.L.GOOGLE.COM
    P4.DQAAGL4ZULND6.UOOA6EBBF3Z22ZQY.IF.V4.IPV6-EXP.L.GOOGLE.COM
    O-O.RESOLVER.84.74.89.184.0DF43816462EAC13.L.GOOGLE.COM
    O-O.RESOLVER.160.96.200.37.D7DYB4G5P7JF4J3W.L.GOOGLE.COM
    O-O.RESOLVER.160.96.200.37.HBWLL5A6A57XJPRQ.L.GOOGLE.COM

Are all of those domains/subdomains/sub-subdomains "legitimate" google properties? We leave it to readers to individually check each one... but we'll be surprised if they all pass muster, to put it mildly. Some certainly are, but a 100% legitimate result isn't to be found - and even having "only" 10% of those domains directed at this IP without being google-controlled is something of an inexplicable (albeit not impossible) result: who chooses to point their domain at an IP address they do not control and from which they cannot serve anything whatsoever? We are not aware of legitimate explanations for this behavoir, at scale.

In the event, we are not filled with confidence that this IP address is 'legitimately' and exclusively Google's to use. In saying so, we understand that we're over-generalising, and that there's potentially viable (if very tenuous) legitimate explantions possible for each indivudal data point in this analytic chain. Possibly, if we're very creative in how we brainstorm. For example, Google can't prevent outsite domain owners from directing their A Records or other DNS entries at an IP controlled by Google (as we mentioned previously), so having noise in those mappings is not demonstable proof ot anything overtyly untoward going on. However, we ask that consideration be given to how this chain of data compares to an IP address solidly within Google's control, and that the chasm between these two categories be kept in mind.

Finally, on the IP addresses, we ask that curious readers take a look at the Robtex records graph for 216.58.192.36. We'd love to screenshot it, in full, but have been stumped on how to present such an object in a way that is not utterly useless as a visual aide. Here's a tiny slice of the graph, for example:

If the full glory is called for, here's a .zip of the entire page, as-rendered:

shot-20150517-1988-1nb9xg3.jpeg.zip: (246.16 KiB) Downloaded 2956 times

Next, let us turn to the rDNS value for that IP address: 216.58.192.36. Again, the Robtex report provides ample data to shake any confidence we might otherwise have that this IP from which an https session claiming to be served by google.com is, in fact, mated to a server Google actually delivers session data from at this particular point in time. This 1e100.net subdomain (said domain being familar to anyone who has done much pcap analysis of browser sessions) appears to be comortably within Google's purview, at least by topline metrics.

However, even here there's some surprising near-term anomalies visible with only a cursory review of public data.

For this, we check "oldest DNS records matching" for incongruous results. We do not expect one of Google's main IP addresses to be, for example, recently controlled by some outside company - particularly not by anything shady. Google has contol of and administered with professional obsession large swaths of IP-space; they do not come into tidbits of IP addressing resources that were, for example, recently turned over to them by the datacenter in which they lease a server or two. Despite that, we see these records:

Code: Select all

The oldest DNS info involved in this analysis were:

dns	last checked
www.vbeltran.net	Thu Apr 2 03:01:33 2015
gdesktop.no	Thu Apr 2 16:03:49 2015
o-o.resolver.160.96.200.37.d7dyb4g5p7jf4j3w.l.google.com	Thu Apr 2 17:31:27 2015
gewgol.com	Sat Apr 4 13:30:36 2015
scholar.google.es	Sat Apr 4 15:27:23 2015
www.androidbased.com	Sat Apr 4 15:40:16 2015
www.blogsearch.google.gr	Sat Apr 4 16:27:36 2015
www.blogsearch.google.sk	Sat Apr 4 20:08:37 2015
showloser.com	Sun Apr 5 08:06:48 2015
o-o.resolver.160.96.200.37.hbwll5a6a57xjprq.l.google.com	Sun Apr 5 23:35:57 2015
picasa.google.ee	Mon Apr 6 08:36:31 2015

The oldest of these records is 2 April this year; the most recent dates to 6 April. Let's take a look t showloser.com's whois data:

Domain Name: SHOWLOSER.COM
Registry Domain ID: 1868185559_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.name.com
Registrar URL: http://www.name.com
Updated Date: 2014-07-24T08:15:55-06:00Z
Creation Date: 2014-07-24T08:15:55-06:00Z
Registrar Registration Expiration Date: 2015-07-24 T08:15:55-06:00Z
Registrar: Name.com, Inc.
Registrar IANA ID: 625
Registrar Abuse Contact Email: XXXXX@name.com
Registrar Abuse Contact Phone: +1.17203101849
Reseller:
Domain Status: clientTransferProhibited
Registry Registrant ID:
Registrant Name: Whois Agent
Registrant Organization: Whois Privacy Protection Service, Inc.
Registrant Street: PO Box 639
Registrant City: Kirkland
Registrant State/Province: WA
Registrant Postal Code: 98083
Registrant Country: US
Registrant Phone: +1.4252740657
Registrant Fax: +1.4259744730
Registrant Email: XXXXXXXXXXXXX@protecteddomainservices.com
Registry Admin ID:
Admin Name: Whois Agent
Admin Organization: Whois Privacy Protection Service, Inc.
Admin Street: PO Box 639
Admin City: Kirkland
Admin State/Province: WA
Admin Postal Code: 98083
Admin Country: US
Admin Phone: +1.4252740657
Admin Fax: +1.4259744730
Admin Email: XXXXXXXXXXXXX@protecteddomainservices.com
Registry Tech ID:
Tech Name: Whois Agent
Tech Organization: Whois Privacy Protection Service, Inc.
Tech Street: PO Box 639
Tech City: Kirkland
Tech State/Province: WA
Tech Postal Code: 98083
Tech Country: US
Tech Phone: +1.4252740657
Tech Fax: +1.4259744730
Tech Email: XXXXXXXXXXXXX@protecteddomainservices.com
Name Server: ns3cna.domain-resolution.net
Name Server: ns2dfg.domain-resolution.net
Name Server: ns4lrt.domain-resolution.net
Name Server: ns1cnb.domain-resolution.net
DNSSEC: Unsigned Delegation

...that doesn't look like a google domain name - but perhaps it's just a really... unusual one. A check with google's PR folks will confirm, but again we're leaning towards putting money on the answer being no. Then how about vbeltran.com? Well, here's the Robtex page... we feel it speaks for itself. (the downsream overlap with Black Lotus Communications IP-space is a fascinating lead... that name having come up both in forensic investigations involving leading-edge malware/rootkit exploitware, but also being quite closely associated with a particular "VPN service" in Texas whose installers have exhibited rather unexpected behaviors during intensive forensic analysis; obvious research opportunties present themselves here).

Incidentally, we see similar curious anomalies in DNS data for other Google domains, an example being googletagmanager.com. This domain, squarely google's by registration and use, has a strange clot of external DNS records showing up in roughtly the same window as the outside DNS traces we noted in both the 1e100.net subdomain and the 216.58.192.36 IP address. Such a correlation, of course, proves no causative link (either directly, or via hidden variable intercession), and could merely be coincidence. Add up enough unusual coincidences in one small area of the statistical possibility landscape, and the sigmas begin to pile up in any purely coincidental explananatory framework.

- - -

To conclude this short review of hostname/DNS/IP records, let us take a quick look at the server-provided ssl certificate for the domain www.google.com. Above, we provided it in PEM form. Here is the ASN.1-mediated unpacked data, in raw form:

Code: Select all

 Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6898384865036533650 (0x5fbbfc7c4c6eff92)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer:
            commonName                = Google Internet Authority G2
            organizationName          = Google Inc
            countryName               = US
        Validity
            Not Before: May  6 10:29:25 2015 GMT
            Not After : Aug  4 00:00:00 2015 GMT
        Subject:
            commonName                = www.google.com
            organizationName          = Google Inc
            localityName              = Mountain View
            stateOrProvinceName       = California
            countryName               = US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:db:41:80:aa:b8:c5:e3:68:d1:55:99:a8:24:36:
                    44:e8:56:c4:e5:36:93:f5:ec:7c:e9:b3:b9:c9:55:
                    3f:9c:35:cb:bf:6d:5e:26:44:41:06:f2:84:59:53:
                    52:84:44:73:f3:6b:78:1d:e0:f9:b3:22:76:71:70:
                    cc:e2:f7:4c:14:a1:92:10:87:23:02:74:2b:4b:0d:
                    cd:9c:4a:c8:49:dd:36:99:33:db:a7:8e:b3:33:81:
                    34:f9:56:10:e7:a1:36:fb:da:bf:16:ca:a7:58:bd:
                    8e:30:a7:67:2f:75:f9:1a:2e:95:22:ad:85:58:90:
                    ac:30:f1:b3:1e:9a:35:c7:33:30:58:1e:20:1d:0d:
                    32:d8:ea:c0:5e:9c:cd:3e:b7:bc:df:2d:14:e5:b7:
                    e2:53:64:4c:7f:6c:af:da:ee:51:24:1c:d1:6f:0a:
                    7d:88:5b:e3:18:b7:ee:ba:f3:15:58:c3:64:e7:06:
                    15:c8:26:5a:34:66:b3:f9:56:96:b8:de:a2:11:a3:
                    29:1d:e2:f5:15:52:4d:ec:70:7c:92:ed:78:67:0c:
                    45:3f:0f:b2:23:5b:a0:42:58:80:78:fc:6a:e0:08:
                    c7:b3:45:34:91:3d:85:ee:7d:4d:9a:40:1f:62:c0:
                    09:6d:a3:bc:83:1c:95:bb:d6:6d:c1:4d:4c:43:6b:
                    10:67
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                DNS:www.google.com
            Authority Information Access: 
                CA Issuers - URI:http://pki.google.com/GIAG2.crt
                OCSP - URI:http://clients1.google.com/ocsp

            X509v3 Subject Key Identifier: 
                8C:5D:92:8A:94:1D:8C:98:B2:32:7A:A4:D3:74:60:19:EF:2F:AF:46
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.11129.2.5.1

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://pki.google.com/GIAG2.crl

    Signature Algorithm: sha1WithRSAEncryption
         64:26:8e:34:dc:c4:75:19:07:a4:05:0e:73:24:20:00:73:01:
         2e:25:89:fa:a0:3a:24:4a:ab:d1:fb:a5:a1:e8:ee:cb:f6:60:
         4b:02:44:0e:92:0f:ee:a9:f1:99:f1:1e:4a:6d:44:83:6e:71:
         16:97:a3:9b:a0:97:ab:a3:c7:29:f5:d3:27:42:37:24:7d:96:
         ba:eb:5c:c3:3e:84:43:59:e8:05:9b:d6:99:31:02:dc:76:73:
         c1:8b:f4:c8:f5:a1:05:b9:43:90:2e:f0:a4:df:50:ab:1d:51:
         72:7d:2c:33:9c:16:14:67:e6:2d:e2:ac:6e:e3:8f:c0:c4:47:
         e6:2d:3e:e9:d0:21:77:63:f3:6f:70:0d:9f:19:16:dc:92:3d:
         be:de:d3:8d:23:e1:53:10:7f:d5:fd:22:30:46:6c:97:6a:0d:
         bf:19:b3:ed:46:16:a1:94:11:57:87:a5:68:6c:af:1d:6c:5b:
         6a:97:a3:f8:fb:1f:ff:ef:ec:de:d2:d5:da:31:1a:11:b0:e4:
         1f:8f:05:a6:0f:a4:9a:03:5d:c9:24:ea:3c:fe:80:50:69:46:
         1d:aa:75:3e:32:09:1f:ae:8e:c2:0e:91:23:3a:e7:01:cd:96:
         ec:49:eb:e6:f6:f3:d0:32:11:31:76:3b:ba:a4:a7:fe:9c:2d:
         1b:cf:ee:d3

Here are the same unpacked data, in a less tedious formatting that makes for easier human reading:

Valid To 04 Aug 2015 ( 78 days )
Weak-Key Does not use a key on our blacklist - this is good
Key-Size 2048 bits
Signature Algorithm (sha1WithRSAEncryption) SHA-1 is being phased out
Certificate Summary
Subject
RDN Value
Common Name (CN) http://www.google.com
Organization (O) Google Inc
Locality (L) Mountain View
State (ST) California
Country (C) US
Properties
Property Value
Issuer CN = Google Internet Authority G2,O = Google Inc,C = US
Subject CN = http://www.google.com,O = Google Inc,L = Mountain View,ST = California,C = US
Valid From 6 May 2015, 10:29 a.m.
Valid To 4 Aug 2015, midnight
Serial Number 5F:BB:FC:7C:4C:6E:FF:92 (6898384865036533650)
CA Cert No
Key Size 2048 bits
Fingerprint (SHA-1) 4B:9D:33:E6:4E:F6:10:4E:20:43:BF:1E:09:28:92:4F:6D:41:33:7A
Fingerprint (MD5) 3E:35:9B:E7:DB:85:D1:5B:98:06:B5:2E:E2:36:0E:68
SANS http://www.google.com

As this is a server-end ssl certificate - SHA1 fingerprint - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - there is no authoritative database against which we can check it to simply verify it is "legitimate" or not. One of the many frustrations and failures of CA-based certificates is the utterly imprecise nature of what a "fraudulent" certificate is, or is not. Rather than being a binary yes/no question, we're left with vast swaths of arguable gray-zone... for even professional researchers, debate over the legitimacy of particular certs can go on for weeks... or longer.

However, a few quick tests don't provide confidence-inspiring results:

First, the cert is signed SHA1 and Google has long since moved away from this as a suitable cert-signing algorithm. Nor is it perhaps some ancient root certificate signed as such decades ago: this one claims to have been issued 6 May 2015 - less than 10 days ago. Is someone at Google really issuing SHA1-signed certs in May of 2015? This seems highly unlikely.

Second, the cert-embedded "Authority Information - OCSP" URI (a nearly-vestifial form of not-CRL but also not-full-cert-pinning certificate recovation procedure that we will not bore you with explaining in further detail here) - http://clients1.google.com/ocsp 404s when loaded.This is not the sort of thing one will find in a legitimately Google-issued certificate, created less than 10 days ago. (the fact that CRL, OSCP, and other cert-embedded URIs routinely lead to 404s, endless redirects, dead air, and mysterious 'numbers-radio' style short strings of digits - quite often in the case of full root certificates - is one of those realities of CA-certificate existence that is rarely commented on, but remains surreal in its implications)...

Here's the URI that's supposed to represent the issuer's 'official' credentials, which in theory helps the benighted browser operator verify if the certificate matches this issuer's credentials (although the specifics of doing that match are both impressively complex, and even if done right do not yield valid/fraud clarity but only some degree of qualified 'maybe'): view-source:http://pki.google.com/GIAG2.crt. The certificate that gets provided at that URL is as follows (after a pre-conversion from .crt/DER to .PEM, of course):

Code: Select all

That, in turn unpacks to...

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 146038 (0x23a76)
Signature Algorithm: sha1WithRSAEncryption
Issuer:
commonName = GeoTrust Global CA
organizationName = GeoTrust Inc.
countryName = US
Validity
Not Before: Apr 5 15:15:55 2013 GMT
Not After : Dec 31 23:59:59 2016 GMT
Subject:
commonName = Google Internet Authority G2
organizationName = Google Inc
countryName = US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:
50:48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:
f1:89:ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:
0b:53:4f:55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:
05:80:12:c4:5e:94:3f:bc:5b:48:38:f4:53:f7:24:
e6:fb:91:e9:15:c4:cf:f4:53:0d:f4:4a:fc:9f:54:
de:7d:be:a0:6b:6f:87:c0:d0:50:1f:28:30:03:40:
da:08:73:51:6c:7f:ff:3a:3c:a7:37:06:8e:bd:4b:
11:04:eb:7d:24e6:f9:fc:31:71:fb:94:d5:60:
f3:2e:4a:af:42:d2:cb:ea:c4:6a:1a:b2:cc:53:dd:
15:4b:8b:1f:c8:19:61:1f9d:a8:3e:63:2b:84:
35:69:65:84:c8:19:c5:46:22:f8:53:95:be:e3:80:
4a:10:c6:2a:ec:ba:97:20:11:c7:39:99:10:04:a0:
f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08:ca:14:
fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0:b1:
de:7b:af:45:33:cf:ba:3e:71:b7f4:25:25:c2:
0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:
72:69
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E

X509v3 Subject Key Identifier:
4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 CRL Distribution Points:

Full Name:
URI:http://g.symcb.com/crls/gtglobal.crl

Authority Information Access:
OCSP - URI:http://g.symcd.com

X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.11129.2.5.1

Signature Algorithm: sha1WithRSAEncryption
27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d:90:e4:
77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e64:4e:1f:
c6:c8:20:5b:09:9fa9:e0:09:34:45:a2:65:25:37:3d:7f:
5a:6f:20:cc:f9:fa:f1:1d:8f:10:0c:02:3a:c4:c9:01:76:96:
be:9b:f9:15:d8:39:d1:c5:03:47:76:b8:8a:8c:31:d6:60:d5:
e4:8f:db:fa:3c:c6:d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:
7a:d1:fb:3a:20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:
0a:25:42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba:
ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea:86:5b:
f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19:17:54:13:60:
9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d:25:93:9c:82:a8:17:
7b:f1:85:b0:d3:0f:58:e1:fb:b1:fe:9c:a1:a3:e8:fd:c9:3f:
f4:d7:71:dc:bd:8c:a4:19:e0:21:23:23:55:13:8f:a4:16:02:
09:7e:b9:af:ee:db:53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:
54:e0:47:07

Full unpack here:

Code: Select all

0 1008: SEQUENCE {
   4  728:   SEQUENCE {
   8    3:     [0] {
  10    1:       INTEGER 2
         :       }
  13    3:     INTEGER 146038
  18   13:     SEQUENCE {
  20    9:       OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
  31    0:       NULL
         :       }
  33   66:     SEQUENCE {
  35   11:       SET {
  37    9:         SEQUENCE {
  39    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
  44    2:           PrintableString 'US'
         :           }
         :         }
  48   22:       SET {
  50   20:         SEQUENCE {
  52    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
  57   13:           PrintableString 'GeoTrust Inc.'
         :           }
         :         }
  72   27:       SET {
  74   25:         SEQUENCE {
  76    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
  81   18:           PrintableString 'GeoTrust Global CA'
         :           }
         :         }
         :       }
 101   30:     SEQUENCE {
 103   13:       UTCTime 05/04/2013 15:15:55 GMT
 118   13:       UTCTime 31/12/2016 23:59:59 GMT
         :       }
 133   73:     SEQUENCE {
 135   11:       SET {
 137    9:         SEQUENCE {
 139    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
 144    2:           PrintableString 'US'
         :           }
         :         }
 148   19:       SET {
 150   17:         SEQUENCE {
 152    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
 157   10:           PrintableString 'Google Inc'
         :           }
         :         }
 169   37:       SET {
 171   35:         SEQUENCE {
 173    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
 178   28:           PrintableString 'Google Internet Authority G2'
         :           }
         :         }
         :       }
 208  290:     SEQUENCE {
 212   13:       SEQUENCE {
 214    9:         OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
 225    0:         NULL
         :         }
 227  271:       BIT STRING
         :         30 82 01 0A 02 82 01 01 00 9C 2A 04 77 5C D8 50
         :         91 3A 06 A3 82 E0 D8 50 48 BC 89 3F F1 19 70 1A
         :         88 46 7E E0 8F C5 F1 89 CE 21 EE 5A FE 61 0D B7
         :         32 44 89 A0 74 0B 53 4F 55 A4 CE 82 62 95 EE EB
         :         59 5F C6 E1 05 80 12 C4 5E 94 3F BC 5B 48 38 F4
         :         53 F7 24 E6 FB 91 E9 15 C4 CF F4 53 0D F4 4A FC
         :         9F 54 DE 7D BE A0 6B 6F 87 C0 D0 50 1F 28 30 03
         :         40 DA 08 73 51 6C 7F FF 3A 3C A7 37 06 8E BD 4B
         :                 [ Another 142 bytes skipped ]
         :       }
 502  231:     [3] {
 505  228:       SEQUENCE {
 508   31:         SEQUENCE {
 510    3:           OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
 515   24:           OCTET STRING
         :             30 16 80 14 C0 7A 98 68 8D 89 FB AB 05 64 0C 11
         :             7D AA 7D 65 B8 CA CC 4E
         :           }
 541   29:         SEQUENCE {
 543    3:           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
 548   22:           OCTET STRING
         :             04 14 4A DD 06 16 1B BC F6 68 B5 76 F5 81 B6 BB
         :             62 1A BA 5A 81 2F
         :           }
 572   18:         SEQUENCE {
 574    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
 579    1:           BOOLEAN TRUE
 582    8:           OCTET STRING 30 06 01 01 FF 02 01 00
         :           }
 592   14:         SEQUENCE {
 594    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
 599    1:           BOOLEAN TRUE
 602    4:           OCTET STRING 03 02 01 06
         :           }
 608   53:         SEQUENCE {
 610    3:           OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
 615   46:           OCTET STRING
         :             30 2C 30 2A A0 28 A0 26 86 24 68 74 74 70 3A 2F
         :             2F 67 2E 73 79 6D 63 62 2E 63 6F 6D 2F 63 72 6C
         :             73 2F 67 74 67 6C 6F 62 61 6C 2E 63 72 6C
         :           }
 663   46:         SEQUENCE {
 665    8:           OBJECT IDENTIFIER authorityInfoAccess (1 3 6 1 5 5 7 1 1)
 675   34:           OCTET STRING
         :             30 20 30 1E 06 08 2B 06 01 05 05 07 30 01 86 12
         :             68 74 74 70 3A 2F 2F 67 2E 73 79 6D 63 64 2E 63
         :             6F 6D
         :           }
 711   23:         SEQUENCE {
 713    3:           OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
 718   16:           OCTET STRING 30 0E 30 0C 06 0A 2B 06 01 04 01 D6 79 02 05 01
         :           }
         :         }
         :       }
         :     }
 736   13:   SEQUENCE {
 738    9:     OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
 749    0:     NULL
         :     }
 751  257:   BIT STRING
         :     27 8C CF E9 C7 3B BE C0 6F E8 96 84 FB 9C 5C 5D
         :     90 E4 77 DB 8B 32 60 9B 65 D8 85 26 B5 BA 9F 1E
         :     DE 64 4E 1F C6 C8 20 5B 09 9F AB A9 E0 09 34 45
         :     A2 65 25 37 3D 7F 5A 6F 20 CC F9 FA F1 1D 8F 10
         :     0C 02 3A C4 C9 01 76 96 BE 9B F9 15 D8 39 D1 C5
         :     03 47 76 B8 8A 8C 31 D6 60 D5 E4 8F DB FA 3C C6
         :     D5 98 28 F8 1C 8F 17 91 34 CB CB 52 7A D1 FB 3A
         :     20 E4 E1 86 B1 D8 18 0F BE D6 87 64 8D C5 0A 25
         :             [ Another 128 bytes skipped ]
         :   }

It's SHA1 fingerprint is: BBDCE13E9D537A5229915CB123C7AAB0A855E798. This intermediate certificate appears to match up with the intermediate certificate provided by the questionable www.gooogle.com page-load, so we do a search on the SHA1 value of the cert's hash to see if it appears in conventional, common search results. Here it is, showing up at the invaluable ssl-tools.net site... although we also noted ourselves, in twitter recently, that this intermediate certificate pops up in some other google server-end of questionable veracity (here's the #fishycerts shapshot if it, for those curious):

Our conclusion on this server-end certificate being offered as credentials putatively backing this 'secure' https session to www.google.com (
4B9D33E64EF6104E2043BF1E0928924F6D41337A) is that it's illegitimate. The intermediate cert to which it chains (BBDCE13E9D537A5229915CB123C7AAB0A855E798) does appear legitimate... but also seems to be signing more than its fair share of questionable server-end 'Google' SSL certificates. What does that mean, and how does that correlation flesh out into possible theories for causative connection? We simply don't know, yet. Further research is required.

Our search on this server-end certificate's SHA1 hash value - 4B9D33E64EF6104E2043BF1E0928924F6D41337A - turns up no hits, anywhere online (nor for the lowercase-converted version, 4b9d33e64ef6104e2043bf1e0928924f6d41337a). Even if there are obscure mentions somewhere we could not find, the comparison between that and widely-distribued legitimate Google server-end certificates is, in a word, enormous.

- - -

This post, drafted and edited by the cryptostorm team during a 36 hour window stretching from Friday afternoon through Sunday morning GMT, in fact covers a time-window longer than the transient phenomenon it has documented. By the time final edits were being finished, a check at ssl-labs for IP and certificate results received when their testing suite looks at www.google.com now yeilds the following results. Gone entirely are the two 212.*.*.* IP addresses, and in their place are a string of 74.*.*.*'s that have a much longer history of correlation with Google services (if still some weird results in terms of ssl cert credibility):

In the place of cert 4B9D33E64EF6104E2043BF1E0928924F6D41337A, a server-end certificate SHA1 1219337d219d1684f785bbabe688cea429ac6ee1 is now being presented when ssl-labs asks for the site... that cert is signed as well by intermediate certificate BBDCE13E9D537A5229915CB123C7AAB0A855E798, making it something of a half-sibling to the questionable 4b9d one we saw earlier in this investigation (only a few hours ago).

{edited to add: the 4b9 and 1219 certificates appear to be overlapping each other in some ssl-labs test runs, and in browser session tests by some cryptostorm staff members - but not others - as this report has completed editing and is being published... which, as we have seen previous, is not in and in itself indicative of malfeasance but is another component of the suspiciously erratic & coincidence-laden pattern we have been observing}

- - -

We expect this kind of elliptical, somewhat tedious form of "forensics" to emerge as the norm in Corruptor-Injector Network attack analysis. Such attacks are transient, their 'session prion' payload is buried in otherwise-innocuous http/https traffic hitting the browser via routine, innocuous web browsing (that such attacks will be highly successful beyond the relatively well-defended confines of the browser DOM sandbox is both inevitable, and frightening - protocols like jabber, sftp, and all the weird Java-wrapped cryptographic 'secure' network procedures each carry its own risk of injected prion and collapse of the entire local endpoint security model).

A few points to reiterate:

1. This is a session to http://www.google.com, not an obscure website. It's 'secured' by https, backed by the fearsome expertise and professional focus of google's entire Chrome security team, and then some. It relates to a session during which visitors download an installer for chrome; if that installer is modified even marginally, and achieves uptake on the local machine, all security is gone.

2. Certificates involved in effectively spoofing https credentials from google appear to be signed by genuine Google intermediate SHA1-signed certificates. The mechanism for this is not clear yet, but there are dozens of PoC'd methods for a well-resourced attacked to complete this step.

3. It's not clear that blaming "the browsers" for this makes sense. It is not the job of browsers to enfore routing legitimacy, although whose job that actually is remains an open question. The browsers can run about cancelling server-end certificates left and right, but it does nothing to address the problem of the injection/hijack gambit itself.

4. A cursory review of DNS records suggests the vast space for temporary resource hijacking via cache poisoning and/or BGP borking forms a core element of these attacks as they exist in the wild today. While there are brilliant researchers out there able to diagnose such transient DNS anomalies, the fact is such anomalies are so common, and so fundamental to DNS as it has evolved, that we gain little in rehasing that well-explored ground.

5. We haven't even looked at IP6 in this analysis, despite some early evidence that it forms a crucial element of observed CIN methods. The same can be said for SPDY, QUIC, and other next-generation protocols: each designed and coded by brilliant women & men, but none having anything in the way of long track record in the wilds of CIN-infested routing landscapes.

6. This is one instance of this we've chosen to document here, in short form, as a test case and proof of (research) concept. We have files and forensics on dozens more, from obscure websites to serious resources used by hundreds of millions of internet citizens every day. Once we began keeping track o such things several months ago, the examples built up faster and faster... a "backlog of weirdness," as one staffer apologetically explained to a cryptostorm member who had seen data suggesting CIN activity, and hoped we'd be able to review it closely to confirm.

7. We see the consequences of this routinely in our member correspondence, globally, on a daily basis. Local computers that have strange network-connectivity problems. Difficulty installing routine packages like openssl or openvpn. Broken cryptographic deployments that cannot support our tightly-enforced standards for cryptostorm session authenticity... these weird goings-on have grown more and more common for us to see, month after month. They foreshadow a deluge of such functionality thefts by CINs from internet users worldwide.

"Total pwnage" - as the NSA glibly calls it. Sounds far-fetched? Here's what they have to say about their in-house CIN - #Balrog, we've named it - several years back:

How would such a system work, in practical terms? Well, here's how:

Moving to more tangible considerations, how would we know that SECONDDATE attacks were underway? Simple: we'd see network sessions inexplicably redirected to unexpected sites, and modified payloads arrive for those targeted individuals 'painted' by the CIN's selector logic.

An attacker would gain enormous advantage if capable of injecting Chrome package downloads, even transiently. This may seem paranoid, to imagine the sheer arrogance required to play such dangerous games with one of the most powerful companies in the tech industy (and giving Google the benefit of initial assumption they are neither actively aware of these attacks, nor even passively helpless to stop them yet unwiling to make them public via full disclosure).

And besides... packages are signed! ...right? Indeed. While it's beyond the scope of this report to go into the numerous proven methods for undermining such signing security, here's a partial list of links - for just one distro of Linux - showing what tends to happen when package-signing throws errors...

https://code.google.com/p/chromium/issu ... ?id=249188
http://askubuntu.com/questions/1877/wha ... gpg-errors
http://askubuntu.com/questions/410519/c ... pdate?rq=1
http://askubuntu.com/questions/552253/c ... grade?rq=1
http://askubuntu.com/questions/307563/w ... gle-chrome
http://askubuntu.com/questions/470699/u ... -following
http://askubuntu.com/questions/258435/s ... rking?rq=1
http://askubuntu.com/questions/555800/u ... ports?rq=1
http://askubuntu.com/questions/362327/u ... rrent?rq=1

There's more, hundreds and hundreds of posts of Linux users - a tiny percentage in the larger OS ocean - having these problems, leading back years. Of course, some - perhaps the majority or even nearly all, are simply the horrifically complex reality of package signing validation if done manually. For those curious, here's Google's Linux Chrome repo howto page with signing key and terse, if excellent, advice for users. That said, it's hosted on http://www.google.com itself... so is the key as-intended by Google? Is it always that way?

If even 5% of those desperate posts reporting failures of the Chrome packages to pass gpg signature-verification are malicious... that's many tens of thousands of Linux Chrome users whose local machines have been irrevocably rooted by an unknown, invisible attacker.

We captured the Chrome package as delivered from the suspect www.google.com page, this weekend. It's too early to say if it shows evidence of direct modification from legitimate parameters; several test-versions downloaded from other sources over the weekend appear to show the same size metrics, on the surface. However, SHA1 hashing is inconclusive: we have divergent hash values for our local copies, as compared to hashes posted elsewhere on the web by others recently for the same version and processor images... but that is far from conclusive, and more work is required.

Let's look at the package itself, meanwhile. For example, here's the --postinst script in the package captured by us this weekend:

Code: Select all

#!/bin/sh
#
# Copyright (c) 2009 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

set -e

# Add icons to the system icons
XDG_ICON_RESOURCE="`which xdg-icon-resource 2> /dev/null || true`"
if [ ! -x "$XDG_ICON_RESOURCE" ]; then
  echo "Error: Could not find xdg-icon-resource" >&2
  exit 1
fi
for icon in "/opt/google/chrome/product_logo_"*.png; do
  size="${icon##*/product_logo_}"
  "$XDG_ICON_RESOURCE" install --size "${size%.png}" "$icon" "google-chrome"
done

UPDATE_MENUS="`which update-menus 2> /dev/null || true`"
if [ -x "$UPDATE_MENUS" ]; then
  update-menus
fi

# Update cache of .desktop file MIME types. Non-fatal since it's just a cache.
update-desktop-database > /dev/null 2>&1 || true

# Updates defaults.list file if present.
update_defaults_list() {
  # $1: name of the .desktop file

  local DEFAULTS_FILE="/usr/share/applications/defaults.list"

  if [ ! -f "${DEFAULTS_FILE}" ]; then
    return
  fi

  # Split key-value pair out of MimeType= line from the .desktop file,
  # then split semicolon-separated list of mime types (they should not contain
  # spaces).
  mime_types="$(grep MimeType= /usr/share/applications/${1} |
                cut -d '=' -f 2- |
                tr ';' ' ')"
  for mime_type in ${mime_types}; do
    if egrep -q "^${mime_type}=" "${DEFAULTS_FILE}"; then
      if ! egrep -q "^${mime_type}=.*${1}" "${DEFAULTS_FILE}"; then
        default_apps="$(grep ${mime_type}= "${DEFAULTS_FILE}" |
                        cut -d '=' -f 2-)"
        egrep -v "^${mime_type}=" "${DEFAULTS_FILE}" > "${DEFAULTS_FILE}.new"
        echo "${mime_type}=${default_apps};${1}" >> "${DEFAULTS_FILE}.new"
        mv "${DEFAULTS_FILE}.new" "${DEFAULTS_FILE}"
      fi
    else
      # If there's no mention of the mime type in the file, add it.
      echo "${mime_type}=${1};" >> "${DEFAULTS_FILE}"
    fi
  done
}

update_defaults_list "google-chrome.desktop"

# This function uses sed to insert the contents of one file into another file,
# after the first line matching a given regular expression. If there is no
# matching line, then the file is unchanged.
insert_after_first_match() {
  # $1: file to update
  # $2: regular expression
  # $3: file to insert
  sed -i -e "1,/$2/ {
    /$2/ r $3
    }" "$1"
}

# If /usr/share/gnome-control-center/gnome-default-applications.xml exists, it
# may need to be updated to add ourselves to the default applications list. If
# we find the file and it does not seem to contain our patch already (the patch
# is safe to leave even after uninstall), update it.
GNOME_DFL_APPS=/usr/share/gnome-control-center/gnome-default-applications.xml
if [ -f "$GNOME_DFL_APPS" ]; then
# Conditionally insert the contents of the file "default-app-block" after the
# first "<web-browsers>" line we find in gnome-default-applications.xml
  fgrep -q "Google Chrome" "$GNOME_DFL_APPS" || insert_after_first_match \
    "$GNOME_DFL_APPS" \
    "^[ 	]*<web-browsers>[ 	]*$" \
    "/opt/google/chrome/default-app-block"
fi

# Add to the alternatives system
#
# On Ubuntu 12.04, we have the following priorities
# (which can be obtain be installing browsers and running
# update-alternatives --query x-www-browser):
#
# /usr/bin/epiphany-browser  85
# /usr/bin/firefox           40
# /usr/bin/konqueror         30
#
# While we would expect these values to be keyed off the most popular
# browser (Firefox), in practice, we treat Epiphany as the lower bound,
# resulting in the following scheme:

CHANNEL=stable
case $CHANNEL in
  stable )
    # Good enough to be the default.
    PRIORITY=200
    ;;
  beta )
    # Almost good enough to be the default. (Firefox stable should arguably be
    # higher than this, but since that's below the "Epiphany threshold", we're
    # not setting our priority below it. Anyone want to poke Firefox to raise
    # their priority?)
    PRIORITY=150
    ;;
  unstable )
    # Unstable, give it the "lowest" priority.
    PRIORITY=120
    ;;
  * )
    PRIORITY=0
    ;;
esac

update-alternatives --install /usr/bin/x-www-browser x-www-browser \
  /usr/bin/google-chrome-stable $PRIORITY
update-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \
  /usr/bin/google-chrome-stable $PRIORITY

update-alternatives --install /usr/bin/google-chrome google-chrome \
  /usr/bin/google-chrome-stable $PRIORITY

# System-wide package configuration.
DEFAULTS_FILE="/etc/default/google-chrome"

# sources.list setting for google-chrome updates.
REPOCONFIG="deb http://dl.google.com/linux/chrome/deb/ stable main"

APT_GET="`which apt-get 2> /dev/null`"
APT_CONFIG="`which apt-config 2> /dev/null`"

SOURCES_PREAMBLE="### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.\n"

# Parse apt configuration and return requested variable value.
apt_config_val() {
  APTVAR="$1"
  if [ -x "$APT_CONFIG" ]; then
    "$APT_CONFIG" dump | sed -e "/^$APTVAR /"'!d' -e "s/^$APTVAR \"\(.*\)\".*/\1/"
  fi
}

# Install the repository signing key (see also:
# https://www.google.com/linuxrepositories/)
install_key() {
  APT_KEY="`which apt-key 2> /dev/null`"
  if [ -x "$APT_KEY" ]; then
    "$APT_KEY" add - >/dev/null 2>&1 <<KEYDATA
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

mQGiBEXwb0YRBADQva2NLpYXxgjNkbuP0LnPoEXruGmvi3XMIxjEUFuGNCP4Rj/a
kv2E5VixBP1vcQFDRJ+p1puh8NU0XERlhpyZrVMzzS/RdWdyXf7E5S8oqNXsoD1z
fvmI+i9b2EhHAA19Kgw7ifV8vMa4tkwslEmcTiwiw8lyUl28Wh4Et8SxzwCggDcA
feGqtn3PP5YAdD0km4S4XeMEAJjlrqPoPv2Gf//tfznY2UyS9PUqFCPLHgFLe80u
QhI2U5jt6jUKN4fHauvR6z3seSAsh1YyzyZCKxJFEKXCCqnrFSoh4WSJsbFNc4PN
b0V0SqiTCkWADZyLT5wll8sWuQ5ylTf3z1ENoHf+G3um3/wk/+xmEHvj9HCTBEXP
78X0A/0Tqlhc2RBnEf+AqxWvM8sk8LzJI/XGjwBvKfXe+l3rnSR2kEAvGzj5Sg0X
4XmfTg4Jl8BNjWyvm2Wmjfet41LPmYJKsux3g0b8yzQxeOA4pQKKAU3Z4+rgzGmf
HdwCG5MNT2A5XxD/eDd+L4fRx0HbFkIQoAi1J3YWQSiTk15fw7RMR29vZ2xlLCBJ
bmMuIExpbnV4IFBhY2thZ2UgU2lnbmluZyBLZXkgPGxpbnV4LXBhY2thZ2VzLWtl
eW1hc3RlckBnb29nbGUuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwEC
HgECF4AFAkYVdn8CGQEACgkQoECDD3+sWZHKSgCfdq3HtNYJLv+XZleb6HN4zOcF
AJEAniSFbuv8V5FSHxeRimHx25671az+uQINBEXwb0sQCACuA8HT2nr+FM5y/kzI
A51ZcC46KFtIDgjQJ31Q3OrkYP8LbxOpKMRIzvOZrsjOlFmDVqitiVc7qj3lYp6U
rgNVaFv6Qu4bo2/ctjNHDDBdv6nufmusJUWq/9TwieepM/cwnXd+HMxu1XBKRVk9
XyAZ9SvfcW4EtxVgysI+XlptKFa5JCqFM3qJllVohMmr7lMwO8+sxTWTXqxsptJo
pZeKz+UBEEqPyw7CUIVYGC9ENEtIMFvAvPqnhj1GS96REMpry+5s9WKuLEaclWpd
K3krttbDlY1NaeQUCRvBYZ8iAG9YSLHUHMTuI2oea07Rh4dtIAqPwAX8xn36JAYG
2vgLAAMFB/wKqaycjWAZwIe98Yt0qHsdkpmIbarD9fGiA6kfkK/UxjL/k7tmS4Vm
CljrrDZkPSQ/19mpdRcGXtb0NI9+nyM5trweTvtPw+HPkDiJlTaiCcx+izg79Fj9
KcofuNb3lPdXZb9tzf5oDnmm/B+4vkeTuEZJ//IFty8cmvCpzvY+DAz1Vo9rA+Zn
cpWY1n6z6oSS9AsyT/IFlWWBZZ17SpMHu+h4Bxy62+AbPHKGSujEGQhWq8ZRoJAT
G0KSObnmZ7FwFWu1e9XFoUCt0bSjiJWTIyaObMrWu/LvJ3e9I87HseSJStfw6fki
5og9qFEkMrIrBCp3QGuQWBq/rTdMuwNFiEkEGBECAAkFAkXwb0sCGwwACgkQoECD
D3+sWZF/WACfeNAu1/1hwZtUo1bR+MWiCjpvHtwAnA1R3IHqFLQ2X3xJ40XPuAyY
/FJG
=Quqp
-----END PGP PUBLIC KEY BLOCK-----
KEYDATA
  fi
}

# Set variables for the locations of the apt sources lists.
find_apt_sources() {
  APTDIR=$(apt_config_val Dir)
  APTETC=$(apt_config_val 'Dir::Etc')
  APT_SOURCES="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourcelist')"
  APT_SOURCESDIR="$APTDIR$APTETC$(apt_config_val 'Dir::Etc::sourceparts')"
}

# Update the Google repository if it's not set correctly.
# Note: this doesn't necessarily enable the repository, it just makes sure the
# correct settings are available in the sources list.
# Returns:
# 0 - no update necessary
# 2 - error
update_bad_sources() {
  if [ ! "$REPOCONFIG" ]; then
    return 0
  fi

  find_apt_sources

  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"
  # Don't do anything if the file isn't there, since that probably means the
  # user disabled it.
  if [ ! -r "$SOURCELIST" ]; then
    return 0
  fi

  # Basic check for active configurations (non-blank, non-comment lines).
  ACTIVECONFIGS=$(grep -v "^[[:space:]]*\(#.*\)\?$" "$SOURCELIST" 2>/dev/null)

  # Check if the correct repository configuration is in there.
  REPOMATCH=$(grep "^[[:space:]#]*\b$REPOCONFIG\b" "$SOURCELIST" \
    2>/dev/null)

  # Check if the correct repository is disabled.
  MATCH_DISABLED=$(echo "$REPOMATCH" | grep "^[[:space:]]*#" 2>/dev/null)

  # Now figure out if we need to fix things.
  BADCONFIG=1
  if [ "$REPOMATCH" ]; then
    # If it's there and active, that's ideal, so nothing to do.
    if [ ! "$MATCH_DISABLED" ]; then
      BADCONFIG=0
    else
      # If it's not active, but neither is anything else, that's fine too.
      if [ ! "$ACTIVECONFIGS" ]; then
        BADCONFIG=0
      fi
    fi
  fi

  if [ $BADCONFIG -eq 0 ]; then
    return 0
  fi

  # At this point, either the correct configuration is completely missing, or
  # the wrong configuration is active. In that case, just abandon the mess and
  # recreate the file with the correct configuration. If there were no active
  # configurations before, create the new configuration disabled.
  DISABLE=""
  if [ ! "$ACTIVECONFIGS" ]; then
    DISABLE="#"
  fi
  printf "$SOURCES_PREAMBLE" > "$SOURCELIST"
  printf "$DISABLE$REPOCONFIG\n" >> "$SOURCELIST"
  if [ $? -eq 0 ]; then
    return 0
  fi
  return 2
}

# Add the Google repository to the apt sources.
# Returns:
# 0 - sources list was created
# 2 - error
create_sources_lists() {
  if [ ! "$REPOCONFIG" ]; then
    return 0
  fi

  find_apt_sources

  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"
  if [ -d "$APT_SOURCESDIR" ]; then
    printf "$SOURCES_PREAMBLE" > "$SOURCELIST"
    printf "$REPOCONFIG\n" >> "$SOURCELIST"
    if [ $? -eq 0 ]; then
      return 0
    fi
  fi
  return 2
}

# Remove our custom sources list file.
# Returns:
# 0 - successfully removed, or not configured
# !0 - failed to remove
clean_sources_lists() {
  if [ ! "$REPOCONFIG" ]; then
    return 0
  fi

  find_apt_sources

  rm -f "$APT_SOURCESDIR/google-chrome.list" \
        "$APT_SOURCESDIR/google-chrome-stable.list"
}

# Detect if the repo config was disabled by distro upgrade and enable if
# necessary.
handle_distro_upgrade() {
  if [ ! "$REPOCONFIG" ]; then
    return 0
  fi

  find_apt_sources
  SOURCELIST="$APT_SOURCESDIR/google-chrome.list"
  if [ -r "$SOURCELIST" ]; then
    REPOLINE=$(grep -E "^[[:space:]]*#[[:space:]]*$REPOCONFIG[[:space:]]*# disabled on upgrade to .*" "$SOURCELIST")
    if [ $? -eq 0 ]; then
      sed -i -e "s,^[[:space:]]*#[[:space:]]*\($REPOCONFIG\)[[:space:]]*# disabled on upgrade to .*,\1," \
        "$SOURCELIST"
      LOGGER=$(which logger 2> /dev/null)
      if [ "$LOGGER" ]; then
        "$LOGGER" -t "$0" "Reverted repository modification: $REPOLINE."
      fi
    fi
  fi
}

DEFAULT_ARCH="i386"

get_lib_dir() {
  if [ "$DEFAULT_ARCH" = "i386" ]; then
    LIBDIR=lib/i386-linux-gnu
  elif [ "$DEFAULT_ARCH" = "amd64" ]; then
    LIBDIR=lib/x86_64-linux-gnu
  else
    echo Unknown CPU Architecture: "$DEFAULT_ARCH"
    exit 1
  fi
}

NSS_FILES="libnspr4.so.0d libplds4.so.0d libplc4.so.0d libssl3.so.1d \
    libnss3.so.1d libsmime3.so.1d libnssutil3.so.1d"

add_nss_symlinks() {
  get_lib_dir
  for f in $NSS_FILES
  do
    target=$(echo $f | sed 's/\.[01]d$//')
    if [ -f "/$LIBDIR/$target" ]; then
      ln -snf "/$LIBDIR/$target" "/opt/google/chrome/$f"
    elif [ -f "/usr/$LIBDIR/$target" ]; then
      ln -snf "/usr/$LIBDIR/$target" "/opt/google/chrome/$f"
    else
      echo $f not found in "/$LIBDIR/$target" or "/usr/$LIBDIR/$target".
      exit 1
    fi
  done
}

remove_nss_symlinks() {
  for f in $NSS_FILES
  do
    rm -rf "/opt/google/chrome/$f"
  done
}

remove_udev_symlinks() {
  rm -rf "/opt/google/chrome/libudev.so.0"
}

remove_udev_symlinks

## MAIN ##
if [ ! -e "$DEFAULTS_FILE" ]; then
  echo 'repo_add_once="true"' > "$DEFAULTS_FILE"
  echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE"
fi

# Run the cron job immediately to perform repository configuration.
nohup sh /etc/cron.daily/google-chrome > /dev/null 2>&1 &

Phew.

Three-hundred and seventy-six lines. A Chromium Debian reference build - not identical, to be clear, in package parameters - nevertheless is notable for its comparative size:

Code: Select all

    #!/bin/sh
    #
    # Copyright (c) 2009 The Chromium Authors. All rights reserved.
    # Use of this source code is governed by a BSD-style license that can be
    # found in the LICENSE file.
    @@include@@../common/postinst.include
    # Add to the alternatives system
    #
    # On Ubuntu 12.04, we have the following priorities
    # (which can be obtain be installing browsers and running
    # update-alternatives --query x-www-browser):
    #
    # /usr/bin/epiphany-browser 85
    # /usr/bin/firefox 40
    # /usr/bin/konqueror 30
    #
    # While we would expect these values to be keyed off the most popular
    # browser (Firefox), in practice, we treat Epiphany as the lower bound,
    # resulting in the following scheme:
    CHANNEL=@@CHANNEL@@
    case $CHANNEL in
    stable )
    # Good enough to be the default.
    PRIORITY=200
    ;;
    beta )
    # Almost good enough to be the default. (Firefox stable should arguably be
    # higher than this, but since that's below the "Epiphany threshold", we're
    # not setting our priority below it. Anyone want to poke Firefox to raise
    # their priority?)
    PRIORITY=150
    ;;
    unstable )
    # Unstable, give it the "lowest" priority.
    PRIORITY=120
    ;;
    * )
    PRIORITY=0
    ;;
    esac
    update-alternatives --install /usr/bin/x-www-browser x-www-browser \
    /usr/bin/@@USR_BIN_SYMLINK_NAME@@ $PRIORITY
    update-alternatives --install /usr/bin/gnome-www-browser gnome-www-browser \
    /usr/bin/@@USR_BIN_SYMLINK_NAME@@ $PRIORITY
    update-alternatives --install /usr/bin/google-chrome google-chrome \
    /usr/bin/@@USR_BIN_SYMLINK_NAME@@ $PRIORITY
    @@include@@../common/apt.include
    @@include@@../common/symlinks.include
    remove_udev_symlinks
    add_udev_symlinks
    ## MAIN ##
    if [ ! -e "$DEFAULTS_FILE" ]; then
    echo 'repo_add_once="true"' > "$DEFAULTS_FILE"
    echo 'repo_reenable_on_distupgrade="true"' >> "$DEFAULTS_FILE"
    fi
    # Run the cron job immediately to perform repository configuration.
    nohup sh /etc/cron.daily/@@PACKAGE@@ > /dev/null 2>&1 &

Sixty-seven lines. A report of very unusual behaviour on the part of that script, from 2012.

A Lintian scan of the .deb package reads as follows...

Code: Select all

E: google-chrome-stable: embedded-library opt/google/chrome/PepperFlash/libpepflashplayer.so: openssl
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: lcms2
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: srtp
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: sqlite
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libpng
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libxml2
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjpeg
E: google-chrome-stable: embedded-library opt/google/chrome/chrome: libjsoncpp
E: google-chrome-stable: embedded-library opt/google/chrome/libffmpegsumo.so: libavutil
E: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_helper_bootstrap
E: google-chrome-stable: statically-linked-binary opt/google/chrome/nacl_irt_x86_32.nexe
E: google-chrome-stable: debian-changelog-file-missing-or-wrong-name
W: google-chrome-stable: new-package-should-close-itp-bug
W: google-chrome-stable: debian-changelog-line-too-long line 3
E: google-chrome-stable: no-copyright-file
W: google-chrome-stable: description-synopsis-starts-with-article
W: google-chrome-stable: extended-description-line-too-long
E: google-chrome-stable: dir-or-file-in-opt opt/google/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/libpepflashplayer.so
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/PepperFlash/manifest.json
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome-sandbox
W: google-chrome-stable: setuid-binary opt/google/chrome/chrome-sandbox 4755 root/root
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/chrome_100_percent.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/cron/google-chrome
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default-app-block
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/docs.crx
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/drive.crx
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/external_extensions.json
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/gmail.crx
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/search.crx
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/default_apps/youtube.crx
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/google-chrome
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/icudtl.dat
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libffmpegsumo.so
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdm.so
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/libwidevinecdmadapter.so
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/am.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ar.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bg.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/bn.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ca.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/cs.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/da.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/de.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/el.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-GB.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/en-US.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es-419.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/es.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/et.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fa.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fi.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fil.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/fr.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/gu.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/he.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hi.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hr.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/hu.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/id.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/it.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ja.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/kn.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ko.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lt.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/lv.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ml.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/mr.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ms.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nb.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/nl.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pl.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-BR.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/pt-PT.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ro.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ru.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sk.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sl.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sr.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sv.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/sw.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/ta.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/te.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/th.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/tr.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/uk.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/vi.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-CN.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/locales/zh-TW.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helper
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_helper_bootstrap
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/nacl_irt_x86_32.nexe
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/natives_blob.bin
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_128.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_16.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_22.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_24.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_256.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_32.xpm
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_48.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/product_logo_64.png
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/resources.pak
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/snapshot_blob.bin
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-mime
E: google-chrome-stable: dir-or-file-in-opt opt/google/chrome/xdg-settings
W: google-chrome-stable: non-standard-dir-perm usr/share/doc/google-chrome-stable/ 0700 != 0755
E: google-chrome-stable: executable-manpage usr/share/man/man1/google-chrome.1
E: google-chrome-stable: manpage-not-compressed usr/share/man/man1/google-chrome.1
W: google-chrome-stable: manpage-has-errors-from-man usr/share/man/man1/google-chrome.1 1: warning: macro `"' not defined
W: google-chrome-stable: binary-without-manpage usr/bin/google-chrome-stable
W: google-chrome-stable: pkg-not-in-package-test google-chrome usr/share/menu/google-chrome.menu
E: google-chrome-stable: prerm-calls-updatemenus
W: google-chrome-stable: executable-not-elf-or-script usr/share/man/man1/google-chrome.1
E: google-chrome-stable: shlib-with-non-pic-code opt/google/chrome/libffmpegsumo.so

Lintian finished with exit status 1

Do these results match known-good equivalents? It's entirely possible they do... but we'll be double-checking that, to be sure.

However, it's much harder to come up with a legitimate explanation for the presence of this parameter:

Code: Select all

 <netscape-remote>true</netscape-remote>

In /apt/google/chrome/default-app-block...

Code: Select all

  <web-browser>
      <name>Google Chrome</name>
      <executable>/opt/google/chrome/google-chrome</executable>
      <command>/opt/google/chrome/google-chrome %s</command>
      <icon-name>google-chrome</icon-name>
      <run-in-terminal>false</run-in-terminal>
      <netscape-remote>true</netscape-remote>
      <tab-command>/opt/google/chrome/google-chrome %s</tab-command>
      <win-command>/opt/google/chrome/google-chrome --new-window %s</win-command>
    </web-browser>

"Netscape-remote" shows up in only a few places, including the Russian-presenting "Sisyphus" nonstandard repository, in a Gnome-related package called "gnome-control-center" - we're helpfuly informed that "If you install GNOME, you need to install control-center." It's not clear if this repository is borked or not. What is clear is that the parameter for remote-access is flagged "true" in the build we got from "www.google.com" this weekend. It seems highly unlikely that's the default setting coming out from Google liegitimately... although, as with all such things, we welcome correction from specific subject-matter experts.

These transient issues with strange 'google' certificates have been repeating themselves during the past couple months. In early April, a journalist in the UK reported on invalid Gmail SMTP certs being served to users worldwide for several hours. The issue was reported on twitter... but the tweet is now gone.

It appears everyone assumed this was an error on Google's part (comments left on the article cited - two of them indicate transient continuance of the issue up through mid-April at least, although blame is cast on Google for 'misconfiguring' gmai's servers), although the carefully-worded status updated Google provided are notable in not actually saying anything specific whatsoever...

4/4/15, 9:46 PM
The problem with Gmail should be resolved. We apologize for the inconvenience and thank you for your patience and continued support. Please rest assured that system reliability is a top priority at Google, and we are making continuous improvements to make our systems better.

4/4/15, 8:58 PM
We expect to resolve the problem affecting a majority of users of Gmail at 4/4/15, 10:00 PM. Please note that this time frame is an estimate and may change. smtp.gmail.com is displaying an invalid certificate.

4/4/15, 8:00 PM
We're aware of a problem with Gmail affecting a majority of users. The affected users are able to access Gmail, but are seeing error messages and/or other unexpected behavior. We will provide an update by 4/4/15, 9:00 PM detailing when we expect to resolve the problem. Please note that this resolution time is an estimate and may change. smtp.gmail.com is displaying an invalid certificate.

4/4/15, 7:21 PM
We're investigating reports of an issue with Gmail. We will provide more information shortly. smtp.gmail.com is displaying an invalid certificate.

And of course, in early May we flagged the unusual sibling-cert publicly in twitter.

But what about the GPG signatures, right? That's the bulwark, and we've not addressed it. Our results are preliminary and await confirmation, because... well, because gnupg. We're going to provide a sample of output from our signature-validation efforts, locally; it is representative of what we've seen in the short period we've been working this particular angle.

Once again, it could be we've managed to mis-specify the test - code-signing is not our cryptographic focus, despite cryptostorm being... well, something of a crypto-specalist shop in daily work life.

~/# wget https://dl.google.com/linux/linux_signing_key.pub
--2015-05-17 14:26:38-- https://dl.google.com/linux/linux_signing_key.pub
Resolving dl.google.com (dl.google.com)... 173.194.112.64, 173.194.112.72, 173.194.112.78, ...
Connecting to dl.google.com (dl.google.com)|173.194.112.64|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1745 (1.7K) [text/plain]
Saving to: ‘linux_signing_key.pub’

linux_signing_key.pub 100%[=============================================================================>] 1.70K --.-KB/s in 0.001s

2015-05-17 14:26:39 (1.21 MB/s) - ‘linux_signing_key.pub’ saved [1745/1745]

~/# gpg --verify linux_signing_key.pub google-chrome-stable_current_i386.deb
gpg: verify signatures failed: unexpected data

~/# apt-cache policy google-chrome-stable
google-chrome-stable:
Installed: (none)
Candidate: 42.0.2311.152-1
Version table:
42.0.2311.152-1 0
500 http://dl.google.com/linux/chrome/deb/ stable/main i386 Packages

~/# gpg --import linux_signing_key.pub
gpg: key 7FAC5991: public key "Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>" imported
gpg: Total number processed: 1
gpg: imported: 1

~/# gpg --verify linux_signing_key.pub google-chrome-stable_current_i386.deb
gpg: verify signatures failed: unexpected data

~/# gpg -v -v --verify linux_signing_key.pub
gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
gpg: armor header: Version: GnuPG v1.4.2.2 (GNU/Linux)
:public key packet:
version 4, algo 17, created 1173385030, expires 0
pkey[0]: [1024 bits]
pkey[1]: [160 bits]
pkey[2]: [1024 bits]
pkey[3]: [1021 bits]
keyid: A040830F7FAC5991
gpg: verify signatures failed: unexpected data

~/# apt-key add linux_signing_key.pub
OK

~/# gpg --list-sig 7FAC5991
pub 1024D/7FAC5991 2007-03-08
uid Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sig 3 7FAC5991 2007-04-05 Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sub 2048g/C07CB649 2007-03-08
sig 7FAC5991 2007-03-08 Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>

~/# gpg --version
gpg (GnuPG) 1.4.18
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

~/# apt-get --reinstall install gnupg
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 2 not upgraded.
Need to get 1,170 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://http.debian.net/debian/ jessie/main gnupg i386 1.4.18-7 [1,170 kB]
Fetched 1,170 kB in 5s (208 kB/s)
(Reading database ... 149753 files and directories currently installed.)
Preparing to unpack .../gnupg_1.4.18-7_i386.deb ...
Unpacking gnupg (1.4.18-7) over (1.4.18-7) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for install-info (5.2.0.dfsg.1-6) ...
Setting up gnupg (1.4.18-7) ...

~/# gpg --version
gpg (GnuPG) 1.4.18
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

~/# gpg --list-sig 7FAC5991
pub 1024D/7FAC5991 2007-03-08
uid Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sig 3 7FAC5991 2007-04-05 Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sub 2048g/C07CB649 2007-03-08
sig 7FAC5991 2007-03-08 Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>

~/# gpg -v -v --verify linux_signing_key.pub
gpg: armor: BEGIN PGP PUBLIC KEY BLOCK
gpg: armor header: Version: GnuPG v1.4.2.2 (GNU/Linux)
:public key packet:
version 4, algo 17, created 1173385030, expires 0
pkey[0]: [1024 bits]
pkey[1]: [160 bits]
pkey[2]: [1024 bits]
pkey[3]: [1021 bits]
keyid: A040830F7FAC5991
gpg: verify signatures failed: unexpected data

These results remain open to clarification and correction, as we prepare to publish this report.

- - -

Corruptor-Injector attacks are not the sole province of the NSA, or their #Balrog system. China has made use of similar capabilties, often quite publicly - with a notable emphasis on session hijack of https 'secure' communiations via fraudulent certificates at mass scale. Private versions of the technology exist as well.

An old cryptographic adage goes that mathematical cryptanalytic attacks always get better; they never get worse. Corruptor-Injector Network systems apppear to have reached an inflection point; in game-theoretic terms, a potential 'tragedy of the commons' amoungst those giant entities who have them already. Once word begins to spread of how CINs work, the incentive to keep them under wraps drops asymptotically - since each attacker knows other attackers are likely to jump forward in aggressiveness and public visibility, even if they refrain. Thus, each has an incentive to be 'first to break' and the accelerating aggressiveness of these CIN tactics accelerates even further.

The end result is, in a word, internet chaos.

The security - and privacy - consequences of these tools spiralling into a frenzied battle for injector-primacy on our shared internet are simply impossible to overstate. Anyone infected with these - 'painted' by them, as disinfection is not structurally possible - will see themslves essentially driven offline if they are aware of the attack and must mitigate the security damage proactively by air-gapping. Those unaware they have been injected with a live session prion are rooted, and every activity of their computer, or smartphone, is being logged and remotely archived: email, encryption keys, chat logs, 'secure' web sesions, application updates. Screenshots are being taken and uploaded to the attacker, microphones enabled to record sound nearby, and webcams enabled to snap photos of the operator.

None of the items in this devil's list of extreme privacy violations is a could-be-possible, or a hypothetical. Leaked documents validate each one is being done, and more so each has been automated and works without manual intervention.

There is no greater threat to online privacy, network security, and the continued effective functioning of the internet for the next half-decade or more than Corruptor-Injector Networks, and their accelerating spread. All other threats combined likely don't meet the level CINs represent.

CINs are the 'dirty bombs' of mass surveillance: brutal, destructive, producing a long-term legacy of crippled internet functionality that will cost tens of billions of dollars in real human benefits foregone to these macabre engines of corruption.

But far worse than the economic devastation is the human cost of these privacy annhiliations, one person at a time. Activists picked up in their homes, tortued to death, bodies dumped in empty field by dictators with access to CIN intelligence. Minority groups wiped clean in tactical genocides enabled by absolutely totalistic, perfect intelligence data produced by CINs for violent fascists. Democratic political systems undermined by the massive blackmail leverage of total CIN visibility in the hands of opponents... the list goes on.

The time to face CINs as the threat they have become is now. The data exist to validate already-existing deductive confirmation of their expanding footprint, thanks to Snowden and other whistleblowers.

At cryptostorm, we are all-in to enable broad-scope CIN-evasion techniques, systems, architectures, and services. Already we're working on layered approaches, fluid and flexible and decentralised. The tools exist to do this - good tools, well-tested - but the will to face the threat will be the key driver. We have that will, because we know the damage our members face if they are without protection from CIN. It is our obligation to provide that protection, as a security service, and we look forward to working with other researchers to expand our vision and, in time, retake the internet from the power-mad corruption of these obscene mechanisms.

With sincerity,

~ cryptostorm_team

marzametal · Post by **marzametal** » Mon May 18, 2015 6:56 am

mustardman · Post by **mustardman** » Wed May 20, 2015 4:29 am

Is this really a honest analysis of non-benign corrupted content or intentionally overblown journalism?
You conclude your post being unsure if this content is decidedly corrupt, while stressing the consequences
of institutional content injection networks, and you have titled it implying that this content is explicitly fake.
I call shenanigans!

When I ping google.com I too get a 216- 216.58.211.14 -/muc03s13-in-f14.1e100.net.
When I ping www.google.com I get 173.194.112.82 -/ fra07s29-in-f18.1e100.net or similar on same domain - 7ms quicker than google itself.
These results should speak for themselves.
I visited the google chrome download page at https://www.google.com/chrome/ and got a certificate, below,
which expires in on august 3d of this year and was signed on the 6th of this month of this year.
It too, looks fishy. But I digress. Were I an agent out to manufacture CIN and infect the world,
the last people I would target are the crazies at cryptostorm. Too soon you would blow the cover and make my job
difficult if not impossible, as you are paranoid and constantly checking EVERYTHING. I would have your entire network
put on a whitelist of addresses to not target or present content to.

As you are well aware, google fingerprints the shit out of everyone, and consistently proposes content at you that
it thinks you would like to see. Just when you think you've managed to evade the beast again, it comes back! I've spent
countless hours in working to disable, block, remove, evade google's efforts to push content at me, to try and predict
what i would like to see, and my paranoia over this is far more rational and personal than yours, so listen. If you
have https on it will track you, and I always considered google to be embedding their own tracking data in certs, in
transit, in every way they can use to keep tabs on you and everyone who uses google.

When you observe that videos load too quickly or that amazon purchase shipped in a single day despite it being a rare
item, or facebook starts to ask you to add a person that sent you a text on a phone that you put the facebook app
on, but never gave it permission to access your contact lists, let alone phone texts from people not even in your list,
then you know you have a problem, and a big one. That spooky fingerprinting is coming from everywhere, not just your
CIN enemies, although it does make their jobs a jot easier.

This internet of people is creating a web of "you" that is far more personally detailed, intensely predicated,
and up to date than even your own conscious mind. Your control over it is intensely limited and bubbles are formed around you,
to protect you from the things you don't want to see, don't want to know about, don't want to do.. except.. you might one day.

To me this is far more scary and pertinacious than CINs. This stuff has me in hermit mode using aliases everywhere and
blocking all kinds of things. And it's a lot more real! I don't think you can argue that. I propose the following to anyone
who will listen and read:

One, that a browser plugin is written that harvests generic information like certificates, referrer headers, and other content
that is not intended to be user specific, and we correlate a database that is designed to show the differences and highlight
the efforts to fingerprint, inject, maliciously alter, etc you name it.

Two, based off of the research of this database, a standard set of hashes for files is maintained and distributed to keep
browsers secure. Start whitelisting content and systems. IPV6, CDN's, black lotus, this is the stuff of gold for balrogs.
To make this a lot harder, you have to think outside the box. For example, let's say my browser is told to download
jquery 1.5.9 from a specific server, and a CIN uses my cdn to inject a version of that content that has additional code to infect me.
My browser, however, checks the integrity of the archive downloaded against a sha512 sequence for that library
and version, and rejects it as corrupt, instead downloading a good known resource. Let's say I connect to google and
I get this shady server, but my browser decides THATS NOT GOOD ENOUGH when it encounters the bad certificate and
immediately switches servers until it finds a known google server that is using a known hashed whitelisted certificate.

Thank you, and have a great day.

Code: Select all

Post by **parityboy** » Wed May 20, 2015 6:33 am

@mustardman

This may be of interest to you.

marzametal · Post by **marzametal** » Wed May 20, 2015 3:19 pm

Shenanigans... been ages since I read that word... kudos lol

JakeMan · Post by **JakeMan** » Thu May 21, 2015 2:13 am

If your Google cert is a MiTM enabling one, then mine is too. We have that in common I guess. When I search for "5F:BB:FC:7C:4C:6E:FF:92" on Google, I get only two sites - yours and mine. I've been reading a little of your stuff, to try to see why the two of us would be under the same magnifying glass.

- Regards.
TJM

JakeMan · Post by **JakeMan** » Tue Jun 02, 2015 3:07 am

I must amend what I wrote in the (last) message. Yesterday, our two sites could be seen in a google search for the serial number of the cert. Today - it's just mine, unless I include "cryptostorm.ch" as a search term. So between yesterday and today, Google apparently de-indexed your article so that it requires an explicit naming of your site to see the items. I've noticed this kind of thing many times in the past, on some of my own sites. It's probably not coincidence. You're going to find it hard to be visible, I'm afraid...

sin · Post by **sin** » Wed Jun 03, 2015 7:11 am

yes, is this related to seo or something more sinister (pun intended).
only the onion site is being indexed, a baneki mirror too.

Buge · Post by **Buge** » Mon Aug 10, 2015 5:09 am

Note that icedove loads the page as https with no errors or warnings whatsoever. However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example:

Google never uses EV certificates. Where have you seen Google use EV certificates? The picture you show is of mozilla.org. Mozilla is not a Google service. They're completely separate organizations.

Check out tons of other criticisms of this post here: https://news.ycombinator.com/item?id=10030820

KonamiCodeNeeded · Post by **KonamiCodeNeeded** » Mon Aug 31, 2015 12:39 pm

I am going to make this clear. 1. I want to understand this stuff but, I need a mentor. 2. I have tried to contact someone for a bit. I have knowledge that can help. 3. I support your cause fully. Unfortunately, I am disabled and can't do much. 4. If you help me I swear to do what I can to help you. Also, to find ways to pay you more. 5. I know insider knowledge that I can't trust anyone with as everyone is working with google, cellphone providers, and did I say Google? 6. Github members as I am one of them work for massive corporations. 7. Finally, these companies are tied to agencies of the united states. I saw a private conversation between google and the agency that is invading everyone's privacy. They were also talking to the top Corp.'s. They invented a program that is hidden in phones that just came out and are coming out. It is supposively invisible to anyone who looks at it (I don't know how) but, what it does is the end of privacy completely. It is a program that literally jumps from phone to phone through hidden NFC as well as jumps to anything with a CPU/has any chip in it. From your phone to your tv; tv to computer, computer to mouse to basically all electronics. It finds the real you, all your personal information going back to about 20 years. It can and will find you. There is way more to it but, whatever. It is part of starting WWIII for some groups for others mind control, precrime detection...etc. I as a person who has spent 8 years in college studying psychology, philosophy, social psychology...etc. Know how this can and will be used. I don't know how to stop this. Do you?
My post that will probably get deleted and me banned
Your friendly neighborhood newest member, I would love a reply. I want to support your site and make use of your services. I have about $20 dollars to my name I'll pay that to get attention. Okay good luck. I love Iceland! Will not post again if not asked.

Tryceleon11 · Post by **Tryceleon11** » Tue Oct 13, 2015 5:02 pm

I just found your post here. I am new user into this forum. Though your post has taken sometimes to read it fully. I just want to know about vpn comparison review site. Do you know where can I get that?

hnoor0022 · Post by **hnoor0022** » Sat Feb 13, 2016 1:08 pm

They invented a program that is hidden in phones that just came out and are coming out. It is supposively invisible to anyone who looks at it (I don't know how) but, what it does is the end of privacy completely.

marzametal · Post by **marzametal** » Sun Feb 14, 2016 6:50 am

Are you referring to Stingray?

Guest · Post by **Guest** » Sun Sep 11, 2016 1:11 am

Minor correction: throughout the article you refer to your "icedove" Web browser but instead show that you're using iceweasel (icedove is an E-mail client not a Web browser).

hashtable · Post by **hashtable** » Sat Sep 24, 2016 6:27 pm

check this article: https://theintercept.com/2016/08/19/the ... s-confirm/

On Monday, a hacking group calling itself the “ShadowBrokers” announced an auction for what it claimed were “cyber weapons” made by the NSA. Based on never-before-published documents provided by the whistleblower Edward Snowden, The Intercept can confirm that the arsenal contains authentic NSA software, part of a powerful constellation of tools used to covertly infect computers worldwide.

The evidence that ties the ShadowBrokers dump to the NSA comes in an agency manual for implanting malware, classified top secret, provided by Snowden, and not previously available to the public.

SECONDDATE plays a specialized role inside a complex global system built by the U.S. government to infect and monitor what one document estimated to be millions of computers around the world. Its release by ShadowBrokers, alongside dozens of other malicious tools, marks the first time any full copies of the NSA’s offensive software have been available to the public, providing a glimpse at how an elaborate system outlined in the Snowden documents looks when deployed in the real world, as well as concrete evidence that NSA hackers don’t always have the last word when it comes to computer exploitation.

This overview jibes with previously unpublished classified files provided by Snowden that illustrate how SECONDDATE is a component of BADDECISION, a broader NSA infiltration tool. SECONDDATE helps the NSA pull off a “man in the middle” attack against users on a wireless network, tricking them into thinking they’re talking to a safe website when in reality they’ve been sent a malicious payload from an NSA server.

According to one December 2010 PowerPoint presentation titled “Introduction to BADDECISION,” that tool is also designed to send users of a wireless network, sometimes referred to as an 802.11 network, to FOXACID malware servers. Or, as the presentation puts it, BADDECISION is an “802.11 CNE [computer network exploitation] tool that uses a true man-in-the-middle attack and a frame injection technique to redirect a target client to a FOXACID server.” As another top-secret slide puts it, the attack homes in on “the greatest vulnerability to your computer: your web browser.”

What's new? NSA malware staging servers getting hacked by a rival is not new. A rival publicly demonstrating they have done so is. - Snowden

harry56 · Post by **harry56** » Sat May 27, 2017 9:49 am

I have a feeling this is fucking cool. I'm going to have to read and head-scratch for as long as it takes to check that, mind you. But, yeah, cool.

!	Message from: parityboy
	Spam link removed.

cryptostorm's community forum

Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google

Re: Live-Capture Forensics of Corruptor-Injector Network injecting fake Chrome install via https@google