Am 22.01.2019 wurde eine schwere Sicherheitslücke in apt, dem Paketinstaller von Debian und dessen Derivaten bekannt, die einem Angreifer Remote Code Execution als root erlaubt hatte. Die Schwachstelle befand sich laut dem Entdecker, Max Justicz, im Zusammenspiel der HTTP-Subroutine und dem Paketinstaller selbst und hat vom Security-Team die CVE-2019-3462 zugewiesen bekommen. Seit dem Abend stehen Updates bereit, welche die Lücke schließen. Es ist der zweite schwerwiegende Bug in apt seit 2016.
Um die Lücke auszunutzen, musste der Angreifer einen Man-in-the-Middle-Angriff auf die Kommunikation zwischen dem verwendeten Debian-Update-Server und dem anfragenden System durchführen, oder einen präparierten Mirror bereitstellen und die Kommunikation z. B. via DNS-Spoofing darauf umleiten. Apt weist in einem HTTP-ähnlichen Protokoll beim Update die Subroutine an, ein bestimmtes Paket zu laden. Als Rückantwort an apt wird jedoch nicht nur der Antwortcode verarbeitet, sondern auch andere, nachfolgende Messages des Update-Servers, was unter Anderm einen Redirect auf einen malignen Server ermöglichte. Zwar sind die Hash-Werte der einzelnen Pakete in der signierten Manifest-Datei von apt hinterlegt und werden damit abgeglichen; apt vertraut aber der Response seines Subprozesses, die ebenfalls vom Angreifer über die vertrauensselige Geschwätzigkeit des http-Fetchers injected werden kann. Somit ist es möglich, mittels Redirect einen Download vorzutäuschen und einen gültigen Datei-Hash. Um jedoch tatsächlich eine Datei auszuführen, musste ein Umweg über die Signaturschlüsseldatenbank gewählt werden, die sich als erstaunlich robust gegenüber Fremddaten herausgestellt hat, sofern nur die Keys dabei nicht beschädigt wurden.
Alles in Allem brauchte es eine längere Kette an Exploits, um als Angreifer tatsächlich eigene Pakete ins System einzubringen, und der Weg war bei verschiedenen apt-Versionen teils stark unterschiedlich, hätte jedoch durch den Download via HTTPS nahezu überall verhindert werden können.
Warum wurde bislang für Pakete kein HTTPS verwendet?
Die landläufige Meinung war bis dato, dass das Bereitstellen von Paketen mit gültigen Hashes und Signaturen für einen Angreifer aufgrund der Länge/Komplexität der Signaturschlüssel und Hashfunktionen einen unmöglichen Aufwand darstellt. Insofern war man der Ansicht, dass die Nutzung von HTTPS keinen Sicherheitsvorteil gebracht hätte, und die Nachteile, nämlich höhere Komplexität in der Implementierung des Downloadmechanismus sowie das schwieriger mögliche Cachen von Server-Antworten/Downloads schwerer wiegen. Dass der Crypto-Mechanismus hier geschickt umgangen wurde, stellt die Problematik in neuem Licht dar, zumal die aktuellen Bandbreiten eine besondere Sparsamkeit bei Downloadrequests für die oftmals sehr kleinen Pakete ziemlich lächerlich erscheinen lässt. Die Möglichkeit, Pakete über HTTPS zu beziehen, ist jedenfalls schon lange implementiert, wenn auch von den meisten Admins ungenutzt, und wird über apt-transport-https bereitgestellt.
Quellen:
https://justi.cz/security/2019/01/22/apt-rce.html
https://lists.debian.org/debian-security-announce/2019/msg00010.html
P.S.: Das Forum wurde von mir zeitnah gepatcht; HTTPS werde ich nach einem privaten Test vermutlich die nächsten Tage festtackern.
Um die Lücke auszunutzen, musste der Angreifer einen Man-in-the-Middle-Angriff auf die Kommunikation zwischen dem verwendeten Debian-Update-Server und dem anfragenden System durchführen, oder einen präparierten Mirror bereitstellen und die Kommunikation z. B. via DNS-Spoofing darauf umleiten. Apt weist in einem HTTP-ähnlichen Protokoll beim Update die Subroutine an, ein bestimmtes Paket zu laden. Als Rückantwort an apt wird jedoch nicht nur der Antwortcode verarbeitet, sondern auch andere, nachfolgende Messages des Update-Servers, was unter Anderm einen Redirect auf einen malignen Server ermöglichte. Zwar sind die Hash-Werte der einzelnen Pakete in der signierten Manifest-Datei von apt hinterlegt und werden damit abgeglichen; apt vertraut aber der Response seines Subprozesses, die ebenfalls vom Angreifer über die vertrauensselige Geschwätzigkeit des http-Fetchers injected werden kann. Somit ist es möglich, mittels Redirect einen Download vorzutäuschen und einen gültigen Datei-Hash. Um jedoch tatsächlich eine Datei auszuführen, musste ein Umweg über die Signaturschlüsseldatenbank gewählt werden, die sich als erstaunlich robust gegenüber Fremddaten herausgestellt hat, sofern nur die Keys dabei nicht beschädigt wurden.
Alles in Allem brauchte es eine längere Kette an Exploits, um als Angreifer tatsächlich eigene Pakete ins System einzubringen, und der Weg war bei verschiedenen apt-Versionen teils stark unterschiedlich, hätte jedoch durch den Download via HTTPS nahezu überall verhindert werden können.
Warum wurde bislang für Pakete kein HTTPS verwendet?
Die landläufige Meinung war bis dato, dass das Bereitstellen von Paketen mit gültigen Hashes und Signaturen für einen Angreifer aufgrund der Länge/Komplexität der Signaturschlüssel und Hashfunktionen einen unmöglichen Aufwand darstellt. Insofern war man der Ansicht, dass die Nutzung von HTTPS keinen Sicherheitsvorteil gebracht hätte, und die Nachteile, nämlich höhere Komplexität in der Implementierung des Downloadmechanismus sowie das schwieriger mögliche Cachen von Server-Antworten/Downloads schwerer wiegen. Dass der Crypto-Mechanismus hier geschickt umgangen wurde, stellt die Problematik in neuem Licht dar, zumal die aktuellen Bandbreiten eine besondere Sparsamkeit bei Downloadrequests für die oftmals sehr kleinen Pakete ziemlich lächerlich erscheinen lässt. Die Möglichkeit, Pakete über HTTPS zu beziehen, ist jedenfalls schon lange implementiert, wenn auch von den meisten Admins ungenutzt, und wird über apt-transport-https bereitgestellt.
Quellen:
https://justi.cz/security/2019/01/22/apt-rce.html
https://lists.debian.org/debian-security-announce/2019/msg00010.html
P.S.: Das Forum wurde von mir zeitnah gepatcht; HTTPS werde ich nach einem privaten Test vermutlich die nächsten Tage festtackern.
