Został zidentyfikowany luka w menedżerze pakietów APT (CVE-2019-3462), co umożliwia atakującemu zainicjowanie fałszowania zainstalowanego pakietu czy osoba atakująca ma kontrolę nad lustrem repozytorium lub może zakłócić ruch tranzytowy między użytkownikiem a repozytorium (atak MITM).
Problem został zidentyfikowany przez badacza bezpieczeństwa Maxa Justicza, znany z wykrywania luk w menedżerze pakietów APK (Alpine) oraz w repozytoriach Packagist, NPM i RubyGems.
Problem Wynika to z nieprawidłowej weryfikacji pól w kodzie obsługującym przekierowanie HTTP.
Jaki jest problem?
Ta luka umożliwia atakującemu podstawienie własnej treści w danych przesyłanych w ramach sesji HTTP (Debian i Ubuntu używają HTTP, a nie HTTPS, aby uzyskać dostęp do repozytorium, przy założeniu, że podpis cyfrowy jest wystarczający przy dopasowanych metadanych i rozmiarze pakietu.)
Zidentyfikowana luka zapewnia moc atakującemu zastąp przesłany pakiet, po czym APT uzna go za odebrany z oficjalnego serwera lustrzanego i rozpocznie proces instalacji.
Poprzez włączenie do złośliwego pakietu skryptów uruchamianych podczas instalacji, osoba atakująca może wykonać swój kod w systemie z uprawnieniami roota.
Aby pobrać dane z repozytorium, APT uruchamia proces potomny z implementacją określonego transportu i organizuje interakcję z tym procesem za pomocą prostego protokołu tekstowego z podziałem poleceń pustą linią.
Jak mogę wykryć problem?
Istotą problemu jest to, że procedura obsługi transportu HTTP, po otrzymaniu odpowiedzi od serwera HTTP z nagłówkiem „Location:”, żąda potwierdzenia przekierowania z głównego procesu.
Całkowite przeniesienie zawartości tego nagłówka. Ze względu na brak czystości przesyłanych znaków specjalnych, atakujący może określić podział wiersza w polu „Lokalizacja:”.
Ponieważ ta wartość zostanie zdekodowana i przesłana kanałem komunikacyjnym z procesem głównym, osoba atakująca może zasymulować inną odpowiedź z programu obsługi transportu HTTP i zastąpić fikcyjny blok 201 URI.
Na przykład, jeśli podczas żądania pakietu atakujący podstawi odpowiedź, podstawienie to spowoduje przesłanie następnego bloku danych do procesu głównego.
Wykonywane jest obliczanie skrótów dla pobranych plików, a główny proces po prostu sprawdza te dane za pomocą skrótów z bazy danych podpisanych pakietów.
Wśród metadanych osoba atakująca może określić dowolną wartość testowych skrótów powiązanych w bazie danych z faktycznie podpisanymi pakietami, ale w rzeczywistości nie odpowiada ona hashom przesłanego pliku.
Główny proces zaakceptuje kod odpowiedzi zastąpiony atakiem, poszuka hasha w bazie danych i uzna, że ładowany jest pakiet, dla którego jest poprawny podpis cyfrowy, chociaż w rzeczywistości wartość pola z hashem jest podstawiana w kanał komunikacji z procesem głównym przy użyciu ataku i pliku określonego w zastępowanych metadanych.
Pobieranie złośliwego pakietu odbywa się poprzez dołączenie go do pliku Release.gpg podczas przesyłania.
Ten plik ma przewidywalną lokalizację w systemie plików, a dołączenie pakietu do jego uruchomienia nie wpływa na wyodrębnienie podpisu cyfrowego z repozytorium.
Podczas uzyskiwania danych apt wyłącza procesy robocze, które specjalizują się w różnych protokołach używanych do przesyłania danych.
Następnie główny proces komunikuje się z tymi procesami roboczymi za pośrednictwem stdin / stdout, aby powiedzieć im, co mają pobrać i gdzie umieścić to w systemie plików za pomocą protokołu, który wygląda trochę jak HTTP.
Główny proces prześle wtedy swoją konfigurację i zażąda zasobu, a proces roboczy odpowie.
Gdy serwer HTTP odpowiada przekierowaniem, proces roboczy zwraca 103 Redirect zamiast 201 URI Done, a proces główny używa tej odpowiedzi, aby dowiedzieć się, który zasób zażądać w następnej kolejności.