18:50
4/5/2021

Pewnie spora część z Was czyta ten artykuł przy pomocy przeglądarki Google Chrome. Ucieszycie się więc, że dzięki Maciejowi Pulikowskiemu, Wasza przeglądarka nie ma już 6 błędów, z których część mogła pomóc w infekcji Waszego komputera złośliwym oprogramowaniem. Niektóre firmy za znajdowane w ich kodzie błędy pozywają badaczy bezpieczeństwa. Inne, jak Google, zamiast karać wolą badaczy wynagrodzić i uważamy, że to poprawne podejście. Maciek od Google otrzymał 5 000 dolarów. Przeczytajcie na czym polegały odkryte przez Maćka błędy i jak je namierzył.

Poniższa część artykułu jest autorstwa Maćka Pulikowskiego. Jeśli i Ty chciałbyś czymś pochwalić się na naszych łamach, daj nam znać!

Pobrałeś wirusa zamiast obrazka

Odkryte przeze mnie błędy dotyczyły mechanizmu pobierania plików przez użytkowników i znajdowały się w File System Access API. Przy ich pomocy można było ukryć prawdziwe rozszerzenia/typ pliku pobranego przez użytkownika. Oto film prezentujący podatność:

Na wideo można zaobserwować, że okienko systemowe do zapisu pliku wywołane przez Google Chrome pokazuje inne rozszerzenie (*.jpg), niż faktycznie pobrany plik posiada (*.lnk).

Plik .lnk można wykorzystać do wywołania np. skryptu Power Shella i warto zauważyć, że zastosowanie rozszerzenia .lnk w tym ataku ma jeszcze jedną “zaletę” — Windows domyślnie je ukrywa, co zwiększa szanse na otworzenie pliku przez ofiarę i może ją po uruchomieniu (ofiara myśli przecież, że pobrała obrazek) narazić na atak ransomwarem lub infekcję trojanem.

Jak ukryć prawdziwe rozszerzenie pliku?

File System Access API umożliwia aplikacjom webowowym wejście w interakcję z plikami na urządzeniu użytkownika. Użytkownik musi zaakceptować specjalne okienko, aby nadać uprawnienia dostępu do folderu w systemie, dzięki czemu aplikacja ma możliwość czytania, modyfikowania i tworzenie plików.

Wykryte przeze mnie błędy znajdowały się w metodzie showSaveFilePicker(), która wyświetla użytkownikowi okno systemowe zapisu pliku na dysku. Metoda ta jest wyjątkiem w API, gdyż nie wymaga ona akceptacji dodatkowych uprawnień w przeglądarce. Działa bardzo podobnie do tego, jak sprawuje się otwarcie okno wyboru przez prawy przycisk myszy na np. zdjęciu i kliknięcie w “Zapisz jako”.

Programista może wpisać do pola Save as type co chce, ale Chrome dla bezpieczeństwa dopisuje prawdziwe rozszerzenie pliku np. jpg. Okazuje się jednak, że nie zawsze! Przeglądarkę można było oszukać bardzo prostymi sposobami:

  1. Dodać do pola “Save as type” znak gwiazdki, który o dziwo usuwał rozszerzenie dodane przez Chrome,

  2. Dodać dużoooo spacji, co również umożliwiało ukrycie rozszerzenia, które dodawał Chrome.

Podsumowując, dzięki tym trickom, atakujący mógł sprawić, żeby w polu “Save as type” wyświetlany tekst nie wskazywał na prawdziwy typ pobieranego pliku. Ofiara widziałaby, np.
Save as type: JPEG Image (*.jpg)
Save as type: PDF File (*.pdf)

Natomiast pobrany plik mógł być wirusem z zupełnie innym typem pliku, np.
nazwa_wpisana_przez_użytkownika.exe
nazwa_wpisana_przez_uzytkownika.jpg.lnk

Jeśli chcecie rzucić okiem na kod, tutaj znajdziecie exploit proof of concept na CVE-2021-21123.

 


Psst! Jesteś programistą? Poznaj kilka prostych zasad tzw. programowania defensywnego, dzięki któremu możesz uniknąć wieeeeeelu błędów i dziur bezpieczeństwa tworzonych przez siebie aplikacjach. Zobacz nasz czwartkowy webinar pt. “Jak bezpieczenie programować?” (za dostęp możesz zapłacić ile chcesz — i nie jest to luka formularza rejestracyjnego! :-).

 

Jak namierzyłem błąd?

Po prostu spojrzałem na kod źródłowy silnika chromium, który jest opensourcem. Zauważyłem, że chrome domyślnie blokuje pliki o rozszerzeniach .lnk czy .local, zamieniając je na .download. Natomiast samo “File System Access API” nie blokowało tych rozszerzeń plików.

Pozostałe, równolegle wykryte przeze mnie błędy w File System Access API to:

    • Manipulacja nazwa pliku/rozszerzenia przez użycie RTLO (Right to Left Override),

    • Manipulacja nazwy pliku/rozszerzenia przez dużą ilość znaków białych,

    • Możliwość dodania do pliku Alternate Data Stream, bez możliwości uzupełniania,

    • Możliwość zmanipulowania nazwy tak aby można było dodać spację po rozszerzeniu – ciężko później taki plik usunąć na systemie operacyjnym Windows.


Błąd związany z manipulacją tekstu w polu “Save as type” został wyceniony jako HIGH na Chrome Bug Bounty. Wszystkie błędy zostały poprawione w wersji Google Chrome 88.0.4324.96, a łatka została opublikowana dnia 19.01.2021. Błędy istniały na różnych systemach operacyjnych – Windows, Mac OS i Linux.

Ty też możesz znaleźć błąd :)

Jak widać, warto testować nowy kod dodawany do Google Chrome pod kątem bezpieczeństwa, gdyż nawet w tak popularnej aplikacji można znaleźć parę podatności w jednym obszarze. Pomimo, że samo zabezpieczenie File System Access API posiada swój własny model bezpieczeństwa oraz dedykowana sekcje w dokumentacji na temat zabezpieczeń, możliwym było znalezienie w nim błędów. I to pomimo tego, że deweloperzy poświęcili sporo czasu na opracowanie zabezpieczeń tej funkcjonalności. Miejcie więc oczy szeroko otwarte. Obsługa plików to często obszar, w którym są różne nieprawidłowości. Powodzenia!

Od redakcji:
Przeczytałeś artykuł autorstwa Maćka Pulikowskiego. Jeśli i Ty chciałbyś opublikować jakiś tekst (artykuł, poradnik, news) związany z bezpieczeństwem, daj nam znać!

Jeśli jeszcze nie “pracujesz w branży”, ale chciałbyś “przeskoczyć z programisty na bezpiecznika” lub dopiero zaczynasz (albo kończysz) studia i chcesz rozwijać się w kierunku bezpieczeństwa, ale czujesz się zagubiony lub przytłoczony ogromem informacji, to polecamy nasz artykuł sprzed roku pt. “Jak zacząć swoją przygodę z branżą bezpieczeństwa IT“.

Przeczytaj także:

23 komentarzy

Dodaj komentarz
  1. Gratulacje.

  2. Tak z ciekawości – ile od tego trzeba podatku zapłacić? ;-)

    • Z każdym jest problem polegający na tym, że Google może nie chcieć się układać z polskimi przepisami:
      a) umowa o dzieło – nie wiem czy taka forma istnieje w USA, ale może z polskim oddziałem wtedy da się,
      b) faktura na usługę – o ile Maciek ma działalność,
      c) darowizna – 12%, 16% i 20%, w zależności od dokładnej kwoty w złotówkach,
      d) po cichu – ;-).

    • e) karta podarunkowa do Google Play

  3. Szacun za czytanie kodu WebKit’a ;)

  4. Linki “daj znam znać” są zbugowane – mają literówkę :)

  5. Zawszę się zastanawiałem czemu Windołs ukrywa lnk i pif.
    Albo np. chcę przeskanować skrót VirusTotalem, bo mi podejrzanie wygląda, to się nie da – bo próbuje załączyć obiekt docelowy.

    PS Poprawcie “daj nam znać”, bo mi Mario urywa od internetu ;)

    • Ponieważ przeznaczenie skrótów w windowsie nie jest dzielenie się nimi między innymi urządzeniami. Przynajmniej tak mi się wydaje :) Poza tym, nie są bezpieczne, łatwe ukrywanie prawdziwego rozszerzenia, ikony, exploity itp :)

  6. 5k USD za znalezienie calkiem sporej dziury w Chrome wydaje sie byc smieszna nagroda/motywacja… Ciekawe ile Maciek spedzil czasu nad przeanalizowaniem kodu

    • 30 minut max :) Serio, przeszukałem tylko metody pobierające w chromium a są one dosyć czytelne :)

    • 20 tysi za 30 minut gapienia się w monitor? Toż to skandal! 666 zeta za minutę , 11 zł na sekundę. Gratulacje :)

    • Szczerze wątpię, że to było pół godziny. Pół godziny to jest wtedy gdy wiesz czego szukasz a on nie wiedział czego szuka, szukał se… a to znaczy, że to mogło potrwać…

  7. Gratulacje dla autora. Jeśli dobrze rozumiem, błąd dotyczy głównie możliwości wykorzystania głupotek Windowsa, związanymi z próbami ukrycia logiki filesystemu przed użytkownikiem?

    • Podatność była na każdym systemie: Windows, Mac OS, Linux :) Nie musiał to być .lnk pobierany, zamiast tego mogliśmy pobierać np. .jar który wykonuje kod javy :) Pełna dowolność.

  8. Mnie bardziej zastanawia, czemu eksplorator plikow pokazuje ikone pliku graficznego na pliku .lnk, skoro to nie plik graficzny.

    • Tak, bo u mnie domyślnie otwiera się JPG w paintcie. Ale dla lnk można dowolną ikonkę systemową wykorzystać :)

  9. Ciekawe czy można dowolny plik zapisać tak żeby Windows pokazywał go jako *.jpg. Dało by to wiele możliwości w atakach oraz co na to powie anty wirus :)

  10. “Niektóre firmy za znajdowane w ich kodzie błędy pozywają badaczy bezpieczeństwa.”

    Ze wzgledu na dosc nietypowa (wzgledem innych produktow) charakterystyke software, jego producencu (developerzy) ciesza sie przywilejami znacznie odstajacymi od tego co spotykamy w innych branzach – wystarczy popatrzec co sie dzieje w przypadku “bugow” w samochodach, elektronice, narzedziach, jedzeniu, lekarstwach etc. etc.
    Pozywajac kogos, za znalezienie bug’a (czytaj. *defektu* w produkcie) producent stwierdza, ze jego produkt jest doskonaly zrzekajac sie branzowch benefitow. Ba, mozna to nawet podciagnac pod wspolódzial w przestepstwach dokonanych przy uzyciu bledow (w tym momencie celowych i swiadomych decyzji) w produktach takiego producenta.

    Ps. Nie rozumiem skad sie bierze poblazliwosc dla takich “wiejskich glupkow” biznesu…

  11. Ja kiedyś znalazłem błąd na stronie internetowej Universal Music Publishing, pozwalający na nieautoryzowany dostęp do wszystkich utworów z katalogu. Dla nieobeznanych, taki dostęp przyznaje się jedynie mediom, osobom pracującym w branży muzycznej, po podpisaniu umowy. Poinformowałem ich, że występuje u nich taki błąd oraz że za drobną opłatą mogę ich poinstruować na czym on polega oraz jak się go pozbyć. Błąd za kilka dni został załatany, bez mojej pomocy, i nie otrzymałem nawet od nich maila ze słowem “Dziękuję” ;)

    • Rozumiem Cię. Też kiedyś zgłosiłem lukę, która pozwalała na nieautoryzowany dostęp, a nawet pokazał się przyciski “Wypłać” przy dziesiątkach tysięcy dolarów :D
      Błąd zgłosiłem, dostałem ostrzeżenie żeby nie używać multikont bo to łamie regulamin, następnego dnia luka została załatana, “Dziękuję” też nie było.

      Ale są dwie kwestie tutaj
      1) Nie powinieneś żądać opłat za swoją pomoc – ja też nie wiedziałem czy Google mi cokolwiek zapłaci

      2) Lepiej zgłaszać błędy tam gdzie jest program Bug Bounty lub bezpośrednio do działu od bezpieczeństwa :)

  12. Trzeba nie mieć życia żeby kody źródłowe sprawdzać, kino

  13. Kolejny dzień, kolejny backdoor w zamkniętym oprogramowaniu…

    • Jak zapewne nie przeczytałeś nie do końca zamkniętym bo złapanie błędu polegało właśnie na porządnej analizie otwartego kodu….

Twój komentarz

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

RSS dla komentarzy: