Analysiert: Google-Interna im Second-Hand-Shop

06.10.2015 09:43 Uhr Florian Heinz, Martin Kluge

Ein in Deutschland gekaufter Gebraucht-Router hatte offenbar einen prominenten Vorbesitzer. Es lieferte den neuen Besitzern interessante und brisante Einblicke in die Infrastruktur von Google – einschließlich Zugangsdaten.

Bereits im März dieses Jahres erwarben wir, die Informatiker Martin Kluge und Florian Heinz, bei einem deutschen Händler einen generalüberholten Juniper-Router J6350. Beim Booten des Gerätes verriet die Passwort-Abfrage für den Benutzer root an der seriellen Konsole, dass der Router nicht im Auslieferungszustand war.

Hit [Enter] to boot immediately, or space bar for command prompt.
Booting [kernel] in 9 seconds...
<SPACE>
ok boot -s
% cli
> configure
Entering configuration mode

[edit]
# set system root-authentication plain-text-password

Um Zugriff auf den Router zu erlangen, führten wir den von Juniper empfohlenen Weg zum Zurücksetzen des Passworts durch. Hierzu musste das System in den Single-User-Mode gebootet werden:

% ls -l /config
-rw-r-----. 1 root   root     307 Apr 10 14:39 juniper.conf.1.gz
-rw-r-----. 1 root   root     360 Apr 10 14:39 juniper.conf.2.gz
-rw-r-----. 1 root   root   64068 Apr 10 14:39 juniper.conf.3.gz
-rw-r-----. 1 root   root     361 Apr 10 14:39 juniper.conf.gz
----------. 1 root   root      32 Apr 10 14:39 juniper.conf.md5
drwxr-xr-x. 2 root   root    4096 Apr 10 14:39 license
-rw-r--r--. 1 root   root       0 Apr 10 14:39 license-status.db
-rw-r-----. 1 root   root   21448 Apr 10 14:39 rescue.conf.gz
-rw-r--r--. 1 root   root     704 Apr 10 14:39 usage.db
-rw-r--r--. 1 root   root     824 Apr 10 14:39 usage.db.1331332072
-rw-r--r--. 1 root   root     716 Apr 10 14:39 usage.db.1331332354
% zcat juniper.conf.3.gz |wc -l
22177

Nach Abschluss dieser Prozedur fanden wir zunächst eine leere Konfiguration vor. Eine genauere Untersuchung des Dateisystems brachte jedoch ältere Versionen zutage, die teilweise über 22.000 Zeilen an Informationen enthielten:

% zcat juniper.conf.3.gz |grep -E "host-name|domain-name"
host-name isttekbr1;
domain-name corp.google.com;

Eine genauere Analyse der Datenfunde weist darauf hin, dass der Router ursprünglich im internen Netz der Firma Google seinen Dienst verrichtete. Diese Vermutung wurde durch den gesetzten Host- und Domainnamen gestützt:

Passwörter und Pre-Shared-Keys

Ebenfalls enthalten waren Informationen zur internen Topologie des Netzes wie Routing-Informationen, Radius- und TACAS-server, VPN-Endpunkte, Firewall-ACLs und Hinweise auf diverse Sicherheitssysteme wie IRIS-Scanner.

system {
    host-name isttekbr1;
    domain-name corp.google.com;
    domain-search [ corp.google.com google.com ];
    time-zone America/Los_Angeles;
    authentication-order tacplus;
    root-authentication {
        encrypted-password "$1$<SNIPPED>";
    }
    name-server {
        172.16.255.1;
    }
    tacplus-server {
        XXX.XXX.XXX.XXX {
            port 2800;
            secret "$9$<SNIPPED>";
            timeout 3;
        }
        YYY.YYY.YYY.YYY {
            port 2800;
            secret "$9$<SNIPPED>";
            timeout 3;
        }
        ZZZ.ZZZ.ZZZ.ZZZ {
            port 2800;
            secret "$9$<SNIPPED>";
            timeout 3;
        }
    }
}
interfaces {
    ge-0/0/0 {
        apply-groups [ MPLS-INTERFACE QOS-MARKDOWN-MPLS-INTERFACE ];
        description "[MPLS] TATA ID:00971322XXXXX  [T=euKM,pt64810]";
        per-unit-scheduler;
        link-mode full-duplex;
        unit 0 {
            description "[NOMON] TATA ID:00971322XXXXX [T=euKM,pt64810]";
            family inet {
                sampling {
                    input;
                    output;
                }
                address XXX.XXX.XXX.XXX/YY;
            }
        }
    }
}
services {
    ipsec-vpn {
        ipsec {
            proposal ipsec-proposal {
                protocol esp;
                authentication-algorithm hmac-sha1-96;
                encryption-algorithm 3des-cbc;
            }
            policy ipsec-policy {
                perfect-forward-secrecy {
                    keys group2;
                }
                proposals ipsec-proposal;
            }
        }
        ike {
            proposal ike-proposal {
                authentication-method pre-shared-keys;
                dh-group group2;
                authentication-algorithm sha1;
                encryption-algorithm 3des-cbc;
            }
            policy ike-policy {
                mode main;
                proposals ike-proposal;
                pre-shared-key ascii-text "$9$<SNIPPED>";
            }
        }
        establish-tunnels immediately;
    }
}

Des Weiteren enthielt die Konfiguration hochsensible Daten wie Passwörter und Pre-Shared-Keys, die – wie bei Routern oft üblich – leicht zu Klartextpasswörtern dekodiert werden können. Im folgenden Auszug haben wir die kritischen Informationen zensiert:

Die Shared Secrets liegen in der Juniper-Konfiguration verschlüsselt (nicht gehasht) vor, da das Klartextpasswort für die entsprechenden Services (IPSec, TACAS und andere) zwingend benötigt wird. Mit Webservices wie password-decrypt.com [1] kann man das Klartextpasswort leicht entschlüsseln. Mithilfe dieser Informationen wäre es vermutlich möglich gewesen, Zugriff auf interne Systeme und Netze von Google zu erlangen.

Google zahlt Finderlohn

Wir haben nicht versucht, mit den von Google zurückgelassenen Informationen auf die Infrastruktur des Internetriesen zuzugreifen. Stattdessen haben wir den Vorfall im Rahmen des Google Vulnerability Reward Program [2] gemeldet.

5000 US-Dollar Finderlohn

Google zeigte sich sehr interessiert und zahlte nach Überprüfung der von uns zugesandten Informationen eine Belohnung von 5000 US-Dollar aus. Die genaue Ursache für den Datenleck wollte Google nicht benennen, jedoch ist sie laut Unternehmensangaben wohl in einer Lücke im Design des Entsorgungsprozesses zu finden, die nun geschlossen wurde.

Dieser Vorfall zeigt, dass auch vermeintlich zurückgesetzte Geräte für versierte Techniker zugängliche Altinformationen auf niedriger Ebene erhalten können (Dateisystem, Blockebene), die mithilfe der vorgesehenen Benutzerschnittstellen nicht sichtbar sind. Dies könnte beispielsweise auch Logdateien und Debuginformationen betreffen, die auf die Herkunft und das Einsatzgebiet des Geräts schliessen lassen und im Zweifelsfall sensible Informationen preisgeben können.

Zu den gefährdeten Geräten gehören dabei nicht nur Netzwerk-Equipment wie (WLAN-)Router und Switches, sondern unter Umständen auch Drucker, Kameras, Telefonanlagen und Co. Die Gerätehersteller sind gefragt, Prozeduren bereitzustellen, die solche Informationen rückstandslos eliminieren, da man als Anwender meist gar nicht überblicken kann, an welchen Orten Daten gespeichert sind.

Bisherige Folgen aus der Analysiert-Reihe auf heise Security:

Wenn Sie Lust haben, eigene Erfahrungen als "Analysiert-Folge" zu veröffentlichen, kontaktieren Sie uns doch via E-Mail an red@heisec.de, Betreff: Analysiert [5]. (rei [6])

URL dieses Artikels:
https://www.heise.de/-2837379

Links in diesem Artikel:
[1] http://password-decrypt.com/
[2] https://www.google.de/about/appsecurity/reward-program/
[3] https://www.heise.de/hintergrund/Analysiert-Das-Comeback-der-Makro-Malware-2573181.html
[4] https://www.heise.de/hintergrund/Analysiert-PS3-Emulator-im-Schafspelz-2583457.html
[5] mailto:red@heisec.de?subject=Analysiert
[6] mailto:rei@heise.de