[dg1yiq]

Hallo,

das ist hier mein erstes Posting und möchte damit alle User grüßen...

(22.02.2015, 13:22)Schimmelreiter schrieb:  Durchaus möglich, daß fl!nk/new/DGF den ssh rausgenommen haben.
War ja auch ein bißchen sehr auffällig.

Ich hatte mal vor einiger Zeit regen Kontakt mit der DG - weil ich ähnliches wie der Themenstarter festgestellt hatte - bin dann aber noch ein wenig "weiter" gekommen.

Lobenswert muss ich die DG erwähnen... ich hatte die Auffäligkeit auf einem Donnerstag Nachmittag gemeldet - das Telefonat war sehr interessant. Samstag Nachts wurde die Lücke provisorisch geschlossen und kürzlich mit einer neuen FW.

Daher glaube ich nun, dass ich die Detail veröffentlichen kann, da die Lücke nicht mehr Nutzbar ist.

***********************

Vorwort

Dieses Dokument ist in der Intention erstanden, das Verhalten der Genexis CPE im Netzwerk der Deutschen Glasfaser zu verstehen. In keinem Fall wurde die Absicht verfolgt, dass Netzwerk zu kompromittieren und/oder Daten zu entwenden, zu verändern oder sonst Schaden zuzufügen. Auch wurden bislang keinerlei Informationen an Dritte weitergeleitet. Diese Dokument dient dazu dem Betreiber Bornet bzw Deutsche Glasfaser eine Sicherheitslücke aufzuzeigen.

Warum nun wirklich...

Das ganze fing damit an, dass die DG nur Internetanschlüsse mit IPv4 Carrier Grade NAT zur Verfügung stellt. Dieses bietet leider keinen direkten IP Zugang zu den Gerät aus Richtung des Internet's. Die Einführung von IPv6 durch Dual Stack verschob sich mehrfach und wurde von mir sehnlichst erwartet, damit meine sich zu Hause befindlichen Dienste wieder erreichbar waren.

Nach der Einführung von IPv6 musste ich leider feststellen das ICMPv6 Pakete nicht weitergeleitet wurden und ich nun wissen wollte, was da genau passiert.

Damit fing es an...

Vorweg genommen, was könnte ein Angreifer tun?

Um die Spannung zu nehmen, will ich bereits an dieser Stelle die möglichen, zum Teil bereits getesteten, Angriffsszenarien nennen:

Manipulation jedweder Konfigurationsmöglichkeit des CPE Router's
abhören von VoIP Telefonaten von direkt an der CPE angeschlossenen Telefone über die VoIP Debug Funktion
Identifikation einer CPE anhand dessen Konfiguration (Tel. Nr. in SIP Einstellungen)
WLAN PSK, PIN – hidden command „show wlan usp“
Up- und Download von veränderter Firmware und/oder „second stage“ Bootloader
Manipulation der CWMP (TR-069) Parameter
DNS Manipulation um Datenverkehr umzuleiten
DOS Attacke – permanent „unbrauchbar“ machen einer oder vieler CPE's
eventuell Zugriff auf die bekannten VLAN's an einer CPE
eventuell Angriff auf das Management Netz der DG

Auf einige Punkte werde ich im Laufe des Dokumentes näher eingehen.

Was ist aufgefallen:

Am Anfang konnte ich nur auf das „GUI“ User Webinterface des Routers, welches über die IPv4 Adresse 192.168.1.254 oder der IPv6 Autoconf IP, zugreifen.

Ein Scan dieser IP mit nmap brachte nichts spannendes zu Tage. Leider kann man aus dem LAN heraus die WAN Adressen nicht erreichen, ABER man kann die IPv6 WAN Adresse aus dem Internet erreichen. Dort brachte ein nmap Scan eine Interessante Entdeckung:

xxx@xxx:~$ nmap -6 -Pn 2a00:61e0:xxxx:xxxx::1

Starting Nmap 6.40 ( http://nmap.org ) at 2014-12-31 23:38 CET
Nmap scan report for 2a00:61e0:xxxx:xxxx::1
Host is up (0.011s latency).
Not shown: 996 filtered ports
PORT STATE SERVICE
22/tcp open ssh
5060/tcp closed sip
5061/tcp closed sip-tls
8082/tcp closed blackice-alerts

Nmap done: 1 IP address (1 host up) scanned in 6.16 seconds

Ohh ein offener ssh Port... den schauen wir uns mal genauer an:

xxx@xxx:~$ telnet 2a00:61e0:xxxx:xxxx::1 22
Trying 2a00:61e0:xxxx:xxxx::1...
Connected to 2a00:61e0:xxxx:xxxx::1.
Escape character is '^]'.
SSH-2.0-dropbear_0.51

Dropbear SSH Server... nur ich kam mit keinerlei User oder Kennwort drauf. Ich kam an der Stelle nicht weiter und habe erst mal aufgegeben. Eine Broute Force Attacke hielt ich für wenig Erfolgreich, da ein ISP sicher sichere Kennwörter verwende würde (ggf Radius, LDAP ect)

(Bild fehlt - symbolisch dargestellter Aufbau der CPE)

Der erste Zugriff:

Es war zu erwarten das die in der CPE verbaute CPU eine serielle Schnittstelle besitzt. Nach ein wenig Suche auf der Platine konnte ich sowohl RX wie auch TX der seriellen Schnittstelle finden und diese verwenden.

Nach dem Einschalten der CPE meldete diese sich mit folgender Ausgabe:


DDR Training.............................................................Done

drgboot-hrg1000-1.3.1-RC12 (Jun 12 2012 - 21:49:27)

DRAM: 128 MB
Comcerto Flash Subsystem Initialization
Flash: 32 MB

...Ausgabe gekürzt...

Checking for bootloader images...
0x21EA0000: drgldr-hrg1000-1.3.1-RC14
0x21F20000: drgldr-hrg1000-1.3.1-RC14
Bootloader loaded from 0x21EA0000 to 0x87000000...


drgldr-hrg1000-1.3.1-RC14 (Jun 27 2012 - 17:04:44)

...Ausgabe gekürzt...

Hit any key to stop autoboot: 1 ### 0
### JFFS2 loading '/.boot' to 0x84800000
Scanning JFFS2 FS (press ^C to abort): ##. ## done.
Completed scanning JFFS2 FS
### JFFS2 load complete: 315 bytes loaded to 0x84800000
Image 0 will be be loaded.
-rw-r--r-- 11020468 Tue Sep 30 05:28:10 2014 drgos-hrg1000-1.12.2-EFT17.img
-rw-r--r-- 11022807 Tue Sep 02 03:24:30 2014 drgos-hrg1000-1.12.2-EFT15.img
### JFFS2 loading '/00/drgos-hrg1000-1.12.2-EFT17.img' to 0x84800000
### JFFS2 load complete: 11020468 bytes loaded to 0x84800000
## Booting image at 84800000 ...
Image Name: drgos-hrg1000-1.12.2-EFT17
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 11020404 Bytes = 10.5 MB
Load Address: 80808000
Entry Point: 80808000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
do_bootm()@cmd_bootm.c:433

Starting kernel ...

Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.33.5-drgos-hrg1000-1.12.2-EFT17 (builder@drgbuild) (gcc version 4.1.2) #1 Fri Sep 12 16:12:36 CST 2014

...Ausgabe gekürzt...


Also augenscheinlich wird dort ein Linux Kernel geladen welcher in ein System mit Busybox endet – wobei der hervorgehobene Teil der Ausgabe mein Interesse geweckt hat.

Ich tat diese bei dem nächsten Start und musste feststellen, dass es sich bei dem Bootloader um eine leicht angepasste Version von Uboot handelt.

Daraufhin habe ich mit das Linux System und auch den Bootloader genau angeschauen und bin zu folgenden Erkenntnissen gekommen:

Flash Layout:

0x000000000000-0x000000020000 : "Bootstrap" 128kB
0x000000020000-0x000001ea0000 : "JFFS2" 31232kB
0x000001ea0000-0x000001f20000 : "Bootloader1" 512kB
0x000001f20000-0x000001fa0000 : "Bootloader2" 512kB
0x000001fa0000-0x000001fc0000 : "UniqueParam" 128kB Text (2359Byte)
0x000001fc0000-0x000001fe0000 : "BootloaderCFG" 128kB leer
0x000001fe0000-0x000002000000 : "SharedCFG" 128kB leer

Wobei der Flash im Adressbereich von 0x20000000 bis 0x22000000 gemapt ist. Zuerst habe ich mit „MD“ einen Memory Dump erstellt und diesen gespeichert.

20000000: ea000012 e59ff014 e59ff014 e59ff014 ................
20000010: e59ff014 e59ff014 e59ff014 e59ff014 ................
20000020: 87800120 87800180 878001e0 87800240 ...........@...
20000030: 878002a0 87800300 87800360 12345678 ........`...xV4.
20000040: 87800000 87800000 87811150 87811734 ........P...4...
.
.
.
21ffffe0: ffffffff ffffffff ffffffff ffffffff ................
21fffff0: ffffffff ffffffff ffffffff ffffffff ................

Diesen habe ich mit einem kleinen Konverter in Binärcode umgewandelt und konnte diesen danach aufteilen und einzeln analysieren.

Die Interessanten Teile sind der „JFFS2“ und „UniqueParam“ Bereich. Im JFFS2 Filesystem befinden sich die Firmware Images sowie diverse Konfigurationsdateien:

-rw-r--r-- 1093 Fri Oct 31 15:57:47 2014 hosts
-rw-r--r-- 1288 Tue Nov 04 17:23:48 2014 .ox-user-config
drwxr-xr-x 0 Thu Jan 01 00:01:23 1970 tr069
-rw-r--r-- 2029 Thu Jan 01 00:02:32 1970 .ox-startup-config
-rw-r--r-- 315 Tue Sep 30 05:29:38 2014 .boot
drwxr-xr-x 0 Tue Jul 22 02:23:56 2014 00
drwxr-xr-x 0 Tue Apr 15 08:45:15 2014 01

Da innerhalb der Firmware keinerlei Dateien geändert werden können, müssen alle Konfigurationen und oder sich ändernden Dateien im JFFS2 abgelegt werden. Dabei fällt auch auf, dass keinerlei Logdateien dauerhaft angelegt werden. Die Logdateien im DRGOS werden nur temporär in der Ramdisk abgelegt und bei einem Neustart gelöscht.

In den Ordnern „00“ und „01“ befinden sich die Firmwarefiles, das aktuelle Image sowie die Vorversion.

hrg1000 > ls /00
-rw-r--r-- 11020468 Tue Sep 30 05:28:10 2014 drgos-hrg1000-1.12.2-EFT17.img
hrg1000 > ls /01
-rw-r--r-- 11022807 Tue Sep 02 03:24:30 2014 drgos-hrg1000-1.12.2-EFT15.img

Die Datei hosts enthält die aktuell erkannten „Hosts“ im Netzwerk.

00:c0:b7:xx:xx:xx;apcxxxxxx
00:c0:b7:xx:xx:xx;apcxxxxxx
...

Die Dateien „.ox-user-config“ und „.ox-startup-config“ sind sehr interresant, da sie die allgemeine und User spezifische Konfiguration enthalten.

Wobei die „.ox-startup-config“ vom besonderem Interesse ist (in Auszügen):

...Ausgabe gekürzt...

!username "admin" password "admin"
!username admin access gui
!username "operator" password "operator"
!username operator access cli

...Ausgabe gekürzt...

interface lan
ip nat external-interface vlan320
!ip address 192.168.1.254/24
ipv6 external-interface tunnel1
!ipv6 address auto

interface lan/ethernet1
queue-scheduling mode wrr
vlan member 4093
vlan untagged 4093

interface lan/ethernet2
queue-scheduling mode wrr
vlan member 4093
vlan untagged 4093

interface lan/ethernet3
queue-scheduling mode wrr
vlan member 4093
vlan untagged 4093

interface lan/ethernet4
queue-scheduling mode wrr
vlan member 4093
vlan untagged 4093

interface tunnel1
tunnel mode 6rd
tunnel 6rd interface vlan320

interface vlan1
shutdown
!ip address dhcp
!ipv6 address auto

interface vlan302
service "mgmt"
ip address dhcp

interface vlan320
ip access-group napt-acl in
service "internet-bng"
ip address dhcp

interface vlan4093
downstream
ip nat external-interface vlan320
ipv6 external-interface tunnel1
ipv6 address auto

interface wan
queue-scheduling mode wrr
vlan member 302,320
vlan untagged 4092

...Ausgabe gekürzt...

Die Config als solches sieht einer Cisco Config sehr ähnlich... wobei Inhalte mit vorangestelltem „!“ auskommentiert sein sollten. Hierbei sollte !username operator access cli sicher der deaktivierte Standard-User für den SSH Zugriff sein. Das kann sich ja kein ISP erlauben. Aber dennoch habe ich es probiert:

marco@kvm:~$ ssh operator@2a00:61e0:xxxx:xxxx::1
operator@2a00:61e0:xxxx:xxxx::1's password:

Digital Residential Gateway Operating System (DRGOS)
Copyright © 2009-2014 Genexis B.V. All rights reserved.
DRGOS version: drgos-hrg1000-1.12.2-EFT17
000xxxxxxxxx-000xxxxxxxxxxxxx# show version
Digital Residential Gateway Operating System (DRGOS)
Copyright © 2009-2014 Genexis B.V. All rights reserved.

DRGOS version: drgos-hrg1000-1.12.2-EFT17
Compiled: Fri Sep 12 16:12:36 CST 2014
Source ID: xxxx

000xxxxxxxxx-000xxxxxxxxxxxxx uptime is 3W9h44m48s
Last boot: unknown

Bootloader 1 version: drgldr-hrg1000-1.3.1-RC14 (Jun 27 2012 - 17:04:44) - Active
Bootloader 2 version: drgldr-hrg1000-1.3.1-RC14 (Jun 27 2012 - 17:04:44) - Active
Bootstrap version: drgboot-hrg1000-1.3.1-RC12 (Jun 12 2012 - 21:49:27)

Product name: HRG1054
Product number: xxx
Product revision: 3
Product date: 2014-07-01
Serial number: xxx
Base MAC address: xxx

000xxxxxxxxx-000xxxxxxxxxxxxx#

Owned... würde ich mal sagen... Anscheinend wird der Standard-User „operator“ nicht entfernt bzw dennoch angelegt.

Die CLI von DRGOS ist stark an Cisco iOS angelehnt und wird quasi analog dazu bedient. Ein Bestätigung erhielt ich damit, dass ich ohne Probleme in den ACL's die Freigabe von ICMPv6 erlauben und danach meine IPv6 Host im Lan per Ping erreichen konnte.

**************

vG
Marco