cve
Eksperci z Uniwersytetu Cambridge opisali lukę w zabezpieczeniach, która ich zdaniem zagraża większości nowoczesnych narzędzi do kompilowania. Nowatorska metoda ataku wykorzystuje nieszkodliwą funkcję narzędzi programistycznych, w której kod źródłowy wyświetla jedną rzecz, ale kompiluje coś zupełnie innego. Dzieje się tak dzięki magii znaków kontrolnych Unicode.
Znaki określające kierunek Unicode pozwalające zmieniać kolejność ataków. Źródło.
W większości przypadków znaki kontrolne nie pojawiają się na ekranie wraz z resztą kodu (chociaż niektóre edytory je wyświetlają), ale w pewien sposób modyfikują tekst. W tej tabeli znajdują się na przykład kody algorytmu dwukierunkowego Unicode (bidi).
Jak zapewne wiesz, część języków, którym posługują się ludzie, jest zapisywana od strony lewej do prawej (np. angielski), inne są zapisywane od prawej do lewej (np. arabski). Gdy kod zawiera tylko jeden język, nie stanowi to żadnego problemu, ale gdy na przykład jeden wiersz zawiera słowa w języku angielskim i arabskim, wtedy kody bidi określają kierunek tekstu.
W swojej pracy autorzy badania wykorzystali takie kody, aby na przykład przenieść w kodzie Pythona terminator komentarzy ze środka wiersza na koniec. Za pomocą kodu RLI przesunęli tylko kilka znaków, a resztę pozostawili nienaruszoną.
Przykład podatnego na ataki kodu Python wykorzystującego kody bidi. Źródło.
Po prawej stronie znajduje się wersja, która programiści widzą podczas sprawdzania kodu źródłowego; lewa strona pokazuje, w jaki sposób kod zostanie wykonany. Większość narzędzi do kompilowania ignoruje znaki kontrolne. Każda osoba, która będzie sprawdzać kod, pomyśli, że piąta linia jest nieszkodliwym komentarzem, lecz w rzeczywistości ukryte w nim polecenie spowoduje, że program pominie operację obciążenia konta bankowego. Innymi słowy, w tym przykładzie symulowany program bankowy wyda pieniądze, ale nie zmniejszy salda konta.
Dlaczego jest to niebezpieczne?
Na pierwszy rzut oka luka wydaje się zbyt prosta. Kto wstawiałby niewidzialne znaki, aby oszukać osoby przeprowadzające audyt kodu źródłowego? Niemniej jednak problem uznano za wystarczająco poważny, aby przypisać mu identyfikator luki (CVE-2021-42574). Przed publikacją swojego artykułu jego autorzy powiadomili o sytuacji twórców najpopularniejszych narzędzi do kompilowania, dając im czas na przygotowanie stosownych poprawek.
W raporcie przedstawiono podstawowe możliwości ataku. Istnieją dwie strategie: ukrycie polecenia w komentarzach lub w wierszu, który na przykład pojawia się na ekranie. Teoretycznie możliwe jest osiągnięcie efektu odwrotnego: stworzenie kodu, który wygląda jak polecenie, ale w rzeczywistości jest częścią komentarza, więc nie zostanie uruchomiony. Z pewnością istnieją jeszcze bardziej kreatywne metody wykorzystania tej podatności.
Na przykład za pomocą tej sztuczki ktoś może przeprowadzić wyrafinowany atak na łańcuch dostaw, w którym kontrahent dostarcza firmie kod. Będzie on wyglądać poprawnie, ale nie będzie działać zgodnie z przeznaczeniem. Następnie, po publicznym udostępnieniu produktu końcowego osoba postronna może użyć „alternatywnej funkcjonalności” do przeprowadzania ataków na klientów.
Jak bardzo jest to niebezpieczne?
Krótko po opublikowaniu artykułu programista Russ Cox skrytykował atak Trojan Source. Delikatnie mówiąc, był rozczarowany. Podał następujące argumenty:
- To wcale nie jest nowy atak.
- Wiele edytorów kodu używa podświetlania składni, aby pokazać „niewidoczny” kod.
- Poprawki dla narzędzi do kompilowania nie są konieczne — wystarczy dokładnie sprawdzić kod w celu wykrycia przypadkowych lub szkodliwych błędów.
Rzeczywiście, problem ze znakami kontrolnymi Unicode pojawił się na przykład w 2017 roku. Niczym nowym nie jest również podobny problem z homoglifami – znakami, które wyglądają tak samo, ale mają różne kody — który także może umożliwić przemycanie obcego kodu.
Jednak Cox nie zaprzecza, że problem istnieje, ale raczej potępia surowość raportów — w tym apokaliptyczny artykuł autorstwa dziennikarza Briana Krebsa.
Problem jest realny, ale na szczęście jego rozwiązanie jest dość proste. Wszystkie łatki, które już są dostępne lub które mają pojawić się wkrótce, zablokują kompilację kodu zawierającego takie znaki. Jako przykład może służyć ten poradnik bezpieczeństwa przygotowany przez twórców narzędzia do kompilowania Rust. Jeśli używasz własnych narzędzi do tworzenia oprogramowania, zalecamy dodanie podobnego mechanizmu sprawdzania ukrytych znaków, które normalnie nie powinny być obecne w kodzie źródłowym.
Zagrożenie ze strony ataków na łańcuch dostaw
Wiele firm zleca zadania programistyczne podwykonawcom lub wykorzystuje w swoich projektach gotowe moduły z otwartym kodem źródłowym. To zawsze otwiera drzwi do ataków na łańcuch dostaw. Cyberprzestępcy mogą włamać się do podwykonawcy lub osadzić kod w projekcie z otwartym kodem źródłowym i umieścić szkodliwy kod w ostatecznej wersji oprogramowania. Audyty kodu zazwyczaj ujawniają takie backdoory, jednak nie zawsze — wówczas użytkownicy końcowi mogą użyć oprogramowania z zaufanego źródła, a mimo to stracić swoje dane.
Trojan Source jest przykładem znacznie bardziej eleganckiego ataku. Zamiast próbować przemycić megabajty szkodliwego kodu do produktu końcowego, atakujący mogą wprowadzić do krytycznej części oprogramowania trudny do wykrycia implant i wykorzystywać go przez wiele lat.
Jak zachować bezpieczeństwo
Aby chronić się przed atakami typu Trojan Source:
- zaktualizuj wszystkie używane kompilatory języka programowania (jeśli wydano dla nich poprawkę) oraz
- napisz własne skrypty, które w ograniczonym zakresie wykrywają znaki kontrolne w kodzie źródłowym.
Walka z potencjalnymi atakami na łańcuch dostaw wymaga przeprowadzania zarówno ręcznych audytów kodu, jak i testów automatycznych. Nigdy nie zaszkodzi spojrzeć na własny kod z perspektywy cyberprzestępców — czasami można dostrzec jeden prosty błąd, który może zerwać cały łańcuch bezpieczeństwa. Jeśli brakuje Ci wewnętrznych zasobów do tego rodzaju analizy, rozważ zaangażowanie ekspertów zewnętrznych.
Porady