1. Projekt 1 – Analyse und Vergleich der Firmware von TP-Link MR3020¶
In diesem Projekt wird herausgefunden, wie man Firmware von Geräten analysieren kann. Es wird untersucht, wie ältere Firmware Versionen im Vergleich zu neuen Versionen aufgebaut sind und welche Sicherheitsrisiken diese im zweifel mit sich bringen. Hierzu werden die alte Version und eine neue Version der Firmware des TP-Link MR3020 verglichen.
1.1. Analyse der Firmware¶
Die Firmware liegt in beiden Versionen im Binary-Format vor, daher können wir Binwalk zur Analyse verwenden. Binwalk identifiziert eingebettete Dateien, komprimierte Daten und Dateisysteme innerhalb von Binärdaten und ermöglicht deren Extraktion für eine tiefere Analyse.
[Quelle](https://github.com/ReFirmLabs/binwalk)
Usage:
binwalk <firmware.bin>
1.1.1. Alte Version¶
1.1.2. Neue Version¶
Aus der Ausgabe geht hervor, dass beide Firmware-Versionen sowohl komprimierte Dateien als auch die eigentliche Firmware enthalten. Diese ist im SquashFS-Dateisystem Version 4.0 komprimiert.
Unterschiede:
Alte Version: Komprimierung mit
lzmaNeue Version: Komprimierung mit
xz
Zusätzlich zeigt die Analyse, an welchen Speicheradressen und in welchen Größen die jeweiligen Datensätze liegen. Im Falle der alten Firmware fängt das Dateisystem bei Byte 1180160 an und ist 2597236 Bytes lang. Bei der neuen Firmware fängt das Dateisystem bei Byte 1507840 an und ist 4891560 Byte lang.
1.2. Extrahieren der Firmware¶
Das Dateisystem kann nicht direkt extrahiert werden, da die .bin-Datei noch Metadaten enthält.
Der zweite Teil der .bin muss vom ersten getrennt werden. Dazu dient das Tool dd, welches zum bitgenauen Kopieren und Konvertieren von Dateien verwendet wird.
[Quelle](https://wiki.ubuntuusers.de/dd/)
Man kann in der Spalte DECIMAL ablesen, ab welchem Wert das Dateisystem beginnt und bis dahin alles überspringen (Parameter „skip“) und unter dem Wert image size in der DESCRIPTION Spalte sieht man wie groß das Dateisystem ist (Parameter „count“):
1.2.1. Extraktion mit dd¶
Alte Version:
dd if=original.bin of=original.squash skip=1180160 bs=1 count=2597236
Neue Version:
dd if=original.bin of=original.squash skip=1507840 bs=1 count=4891560
1.2.2. Magic Number prüfen¶
Die Magic Number dient als Signatur des Dateisystems.
[Quelle](https://dr-emann.github.io/squashfs/)
Mit hexdump lässt sich der Anfang der Datei prüfen.
[Quelle](https://www.man7.org/linux/man-pages/man1/hexdump.1.html)
Der Parameter -C zeigt uns die Daten Formatiert im ASCII Format an:
hexdump -C original.squash | less
Alte Firmware:
Neue Firmware:
Hier muss man beachten, dass die Firmware im little endian Format vorliegt (siehe Binwalk-Ausgabe).
Das bedeutet man muss die Bytes rückwerts auswerten, um die Magic Number richtig zu lesen.
Der damit entstehende Code sqsh am Anfang zeigt: Extraktion des SquashFS Dateisystems war an der richtigen Stelle.
1.3. SquashFS-Dateisystem analysieren¶
SquashFS ist ein komprimiertes Dateisystem, das verschiedene Komprimierungsalgorithmen unterstützt (gzip, lzma, xz, zstd, usw.).
Um es zu entpacken kann man die Toolchain SquashFS verwenden. Hierzu gibt es den Befehl unsquashfs.
[Quelle](https://wiki.ubuntuusers.de/SquashFS/)
Für die alte version mussten wir jedoch auf ein anderes Tool zurückgreifen, da die lzma extraktion mit dem SquashFS Toolkit nicht zuverlässig fuktioniert hat. Deshalb wird hierfür eine alte version vom Firmwaremodkit benutzt. Das Firmware-Mod-Kit ist ein Toolkit zur Extraktion, Modifikation und Rekonstruktion von Firmware-Images. Es hilft dabei, eingebettete Firmware zu analysieren, zu patchen oder um zu konfigureren.
[Quelle](https://github.com/rampageX/firmware-mod-kit)
Alte Firmware:
firmware-mod-kit/trunk/src/others/squashfs-4.0-lzma/unsquashfs-lzma original.squash
Neue Firmware:
unsquashfs original.squash
Dadurch entsteht ein Verzeichnis squashfs-root, das das Dateisystem enthält.
Hier kann man Schwachstellen finden oder eigene Modifikationen durchführen.
Um zu testen, ob es einfach möglich ist, modifikationen zu machen und daraus wieder eine flashbare Firmware zu bekommen, wird das Dateisystem untersucht.
1.3.1. Webinterface untersuchen¶
Im extrahierten Dateisystem befindet sich ein web-Verzeichnis. Dies ist das Webinterface des Routers.
Um einen einfachen Test zu machen versucht man ein Bild durch ein eigenes zu ersetzen und daraus eine lauffähige Firmware zu erzeugen.
Dafür wird eine unter gleichem Namen, ein neues Foto in den jeweiligen Images Ordner der Websites, geladen.
1.4. Erstellen einer modifizierten Firmware¶
1.4.1. Neues SquashFS erstellen¶
Das veränderte Dateisystem muss in ein komprimiertes SquashFS Dateisystem umgewandelt werden. Für die alte Firmware wird, wegen der LZMA Komprimierung, wieder das Firmware-Mod-Kit verwendet und für die neue Version wieder das SquashFS Toolkit:
Alte Firmware:
firmware-mod-kit/trunk/src/others/squashfs-4.0-lzma/mksquashfs-lzma squashfs-root newsquash.bin
Neue Firmware:
mksquashfs squashfs-root newsquash.bin -comp xz
1.4.2. Header extrahieren¶
Alte Firmware:
dd if=original.bin of=newimage.bin count=1180160 bs=1
Neue Firmware:
dd if=original.bin of=newimage.bin count=1507840 bs=1
1.4.3. Header und modifiziertes Dateisystem verbinden¶
dd if=newsquash.bin >> newimage.bin
1.4.4. Validierung mit mktplinkfw¶
Mit dem tool mktplinkfw von openwrt kann ein flashbares image gebaut werden, da es dabei hilft die Checksum im Firmware Header zu korrigieren.
[Quelle](https://github.com/artynet/openwrt-stable/blob/master/tools/firmware-utils/src/mktplinkfw.c)
mktplinkfw -i newimage.bin
Alte Firmware:
Fehlermeldung: Hash-Wert im Header stimmt nicht überein.
Da der Hashwert nicht mit dem Hashwert, der erwartet wird übereinstimmt, wird die Firmware vom Router nicht akzeptiert werden. Jedoch lässt sich die Datei einfach mit einem Hex-Editor, wie Hexedit, manuell korrigieren.
[Quelle](https://linux.die.net/man/1/hexedit)
Hierzu muss man lediglich den falschen Wert im Hex Format finden und durch den erwarteten Wert ersetzen und abspeichern.
Nun können wir erneut mit dem mktplinkfw-Tool die Cecksum testen.
Ergebnis: Von uns modifizierte, flashbare Firmware!
Neue Firmware:
Hier testen wir ebenfalls das mktplinkfw Tool:
Durch Recherche findet man heraus, dass neuere Firmware Versionen den TP-Link V3 Header verwenden. Hier ist der Aufbau des Headers im TP-Link V3 Format:
[Quelle](https://github.com/xdarklight/mktplinkfw3)
Dieser hat eine RSA-Signatur statt einem einfachen CRC zur Validierung der Firmware. Diese Signatur wird mit einem privaten TP-Link-Schlüssel erzeugt und mit den public Keys auf den Routern wieder entschlüsselt. Ohne den private Key von TP-Link ist eine Manipulation und anschließende Signierung der manipulierten Firmware nicht möglich.
1.5. Fazit zur Sicherheit¶
Der neue v3-Header erhöht die Sicherheit signifikant:
Schutz vor Manipulation und Schadcode
Keine unautorisierten Updates
Signaturbasierter Schutz statt nur Hash
Im Gegensatz dazu waren die v1 & v2-Firmwares leicht manipulierbar.
Dies kann dazu führen eine backdoor in das System ein zu bauen und damit einen Angriff zu betreieben.
Solche Schwachstellen in der Firmware von Netzwerkgeräten wurden nach Berichten von Edward Snowden bereits von der NSA verwendet.