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. 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: .. code-block:: bash binwalk Alte Version ^^^^^^^^^^^^ .. image:: ./img/project1/alt_firmware_binwalk_output.png :alt: Binwalk-Ausgabe alte Firmware Neue Version ^^^^^^^^^^^^ .. image:: ./img/project1/neu_firmware_binwalk_output.png :alt: Binwalk-Ausgabe neue Firmware 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 ``lzma`` - Neue 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. 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"): Extraktion mit ``dd`` ^^^^^^^^^^^^^^^^^^^^^ **Alte Version:** .. code-block:: bash dd if=original.bin of=original.squash skip=1180160 bs=1 count=2597236 **Neue Version:** .. code-block:: bash dd if=original.bin of=original.squash skip=1507840 bs=1 count=4891560 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: .. code-block:: bash hexdump -C original.squash | less **Alte Firmware:** .. image:: ./img/project1/hex_alt.png :alt: Hexdump alte Firmware **Neue Firmware:** .. image:: ./img/project1/hex_neu.png :alt: Hexdump 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. 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:** .. code-block:: bash firmware-mod-kit/trunk/src/others/squashfs-4.0-lzma/unsquashfs-lzma original.squash **Neue Firmware:** .. code-block:: bash 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. 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. Erstellen einer modifizierten Firmware -------------------------------------- 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:** .. code-block:: bash firmware-mod-kit/trunk/src/others/squashfs-4.0-lzma/mksquashfs-lzma squashfs-root newsquash.bin .. image:: ./img/project1/make_old_squash.png :alt: Makesquash alt **Neue Firmware:** .. code-block:: bash mksquashfs squashfs-root newsquash.bin -comp xz .. image:: ./img/project1/make_new_squash.png :alt: Makesquash neu Header extrahieren ^^^^^^^^^^^^^^^^^^ **Alte Firmware:** .. code-block:: bash dd if=original.bin of=newimage.bin count=1180160 bs=1 **Neue Firmware:** .. code-block:: bash dd if=original.bin of=newimage.bin count=1507840 bs=1 Header und modifiziertes Dateisystem verbinden ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: bash dd if=newsquash.bin >> newimage.bin 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) .. code-block:: bash mktplinkfw -i newimage.bin **Alte Firmware:** Fehlermeldung: Hash-Wert im Header stimmt nicht überein. .. image:: ./img/project1/hash_error_old.png :alt: Fehlerhafte Hashprüfung 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. .. image:: ./img/project1/hexedit_fix.png :alt: Hexedit-Korrektur Nun können wir erneut mit dem mktplinkfw-Tool die Cecksum testen. .. image:: ./img/project1/modded_firmware.png :alt: Fertige Firmware Ergebnis: Von uns modifizierte, flashbare Firmware! **Neue Firmware:** Hier testen wir ebenfalls das mktplinkfw Tool: .. image:: ./img/project1/header_v3_error.png :alt: Fehler bei neuer Firmware 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: .. image:: ./img/project1/header_struct.png :alt: Aufbau Header [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. 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. [Quelle](https://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969.html)