Pliki polyglot

Poliglota to osoba znająca wiele języków. Ale termin ten ma również znaczenie w odniesieniu do kwestii związanych z bezpieczeństwem.

Dzisiaj o plikach polyglots, które przyspieszają testowanie aplikacji internetowych.

Weźmy prosty atak XSS - czyli wykonanie złośliwego kodu na naszej stronie internetowej.

Dochodzi do niego jeżeli programista nie będzie odpowiednio wyświetlał danych pochodzących od użytkownika.

Te dane, mogą być wyświetlane na stronie w różnych miejscach - tak zwanych kontekstach.

Najprościej rozpatrywać to na przykładzie.

Treść od użytkownika może być wyświetlona w formularzu.

Tworzy się go przy pomocy tagu input w HTML.

Wyświetlaną wartość przechowuje się w atrybucie value pomiędzy podwójnymi cudzysłowami.

Jeżeli więc twórca witryny nie będzie ich konwertował na encje w tekście pochodzącym od użytkownika - atakujący będzie w stanie zamknąć atrybut value i dopisać do niego swój kod JavaScript.

Najprostszy payload, który przetestuje czy strona jest podatna może wyglądać mniej więcej tak:

"><script>alert(1);</script>

Niektórzy programiści mogą jednak użyć pojedynczego cudzysłowu - który dalej jest traktowany jako prawidłowy kod HTML.

Wtedy, musimy zmodyfikować nasz payload - tak aby zamykał atrybut value przy pomocy pojedynczego cudzysłowu.

Jak widzisz, aby przetestować stronę tylko dla tak prostego przypadku potrzebujemy dwóch różnych ciągów znaków w celu przetestowania dwóch różnych kontekstów.

Ale takich potencjalnych kontekstów - może być wiele.

Dlatego też w celu oszczędności czasu wykorzystuje się tak zwane polygloty.

Są to specjalne ciągi znaków, które zostały przygotowane w taki sposób, aby działały w wielu kontekstach równocześnie.

Popatrzmy na stronę konkursu na najkrótszy polyglot¹, który jest w stanie przetestować aż 20 różnych kontekstów na raz.

Dla tego ciągu znaków nie ma znaczenia czy testowany ciąg zostanie wyświetlony pomiędzy tagami title, script czy też iframe - w każdym wypadku będzie działał tak samo - czyli wyświetlał proste okienko.

Ale ataki XSS to nie jedyne miejsce w którym polygloty mogą być przydatne.

Z SQL Injection mamy do czynienia wtedy, kiedy programista nie obsługuje odpowiednio zapytań do bazy danych co pozwala na wykonanie dowolnego zapytania przez użytkownika.

I tutaj podobnie jak w formularzach - treść od użytkownika może zawierać się pomiędzy pojedynczym albo podwójnym cudzysłowem - zazwyczaj w kontekście zapytań where.

Może też znajdować się bezpośrednio w ciele SELECT - kiedy to pozwalamy użytkownikowi na wyświetlenie jednej specyficznej kolumny.

Do przetestowania tych 3 kombinacji - potrzebowalibyśmy zatem 3 różnych ciągów znaków.

Dzięki polyglotowi - możemy tego samego dokonać wysyłając dane tylko raz.

Ale nic nie stoi na przeszkodzie aby stworzyć jeden polyglot, który jednocześnie będzie wyszukiwał błędów XSS oraz SQL Injection².

Ten zademonstrowany tutaj jest dodatkowo prawidłowym plikiem PHP, który może wykonać dowolną komendę która zostanie do niego przekazana jako parametr A.

Idea tego rodzaju plików nie jest związana jedynie z bezpieczeństwem.

Na forum Stack Exchange³ znajduje się wątek z plikiem, który jest odpowiednio obsługiwany przez 232 różne języki programowania.

W zależności od języka w którym uruchomimy podany wyżej kod wyświetli on odpowiednią liczbę - która wskaże na konkretny język użyty do uruchomienia tego kodu.

Prawda ze imponujące? Warto zapoznać się z cały wątkiem w którym użytkownicy tłumaczą przy pomocy jakich sztuczek udało im się zmieścić tak wiele języków w jednym kawałku kodu.

Przykłady zależą tylko od naszej wyobraźni i dobrej znajomości formatów które chcemy ze sobą połączyć.

Weźmy pod lupę 3 wydanie magazynu Proof-of-Concept⁴.

Plik ten możemy otworzyć jako pdf, zip, obrazek jpg albo png.

W każdym z tych formatów zawarte są inne dane.

Większość numerów tego magazynu to istna skarbnica wiedzy.

Numer 13⁵ to prawidłowy PDF/ZIP oraz PostScript

A numer 12⁶ to pdf, zip oraz aplikacja androida.

Obecne przeglądarki mają coraz więcej wbudowanych mechanizmów, które mają chronić przed atakami.

Jednym z takich mechanizmów jest CSP - czyli Content Securit Policy, który pozwala właścicielom stron na zdefiniowanie z których domen skrypt mogą zostać uruchomione przez przeglądarkę.

To znacząco utrudnia atak XSS - bo tym razem oprócz odnalezienia błędu musimy także znaleźć sposób na ominięcie polityki.

Zazwyczaj twórcy stron pozwalają na wykonywanie kodu JS, który pochodzi z ich własnej domeny - co jest logiczne - jako właściciele kontrolują bowiem co znajduje się na ich serwerze.

Co bardziej twórczy atakujący i na to znaleźli sposób - większość serwisów w obecnych czasach pozwala na wysłanie pliku graficznego, który jest naszym avatarem.

Plik ten zostaje zapisany na serwerze, który jest dopuszczony do wykonywania przez polityke CSP.

Zamiast więc obrazka wysyłamy nasz kod JavaScript - co pozwala na ominięcie polityki.

Dlatego też niektóre witryny przed zapisaniem pliku graficznego sprawdzają jego poprawność.

Tym razem nie pozwolą zatem na wysłanie dowolnego pliku z rozszerzeniem jpg czy też gif a dokładnie sprawdzą czy jest to rzeczywiście zdjęcie.

I tutaj znowu pomogą nam polygloty.

Możemy bowiem stworzyć prawidłowy plik jpg, który jednocześnie będzie prawidłowym plikiem JS.

To samo tyczy się pliku gif, który nie jest już tak popularny jak jeszcze kilka lat temu⁷.

Ostatnia ciekawostką o której chciałbym wspomnieć są różnice w przetwarzaniu danych formatów w zależności od oprogramowania jakiego użyjemy.

Nazwy w archiwum zip mogą być przechowywane w co najmniej trzech różnych miejscach.

W zależności od narzędzia którego użyjemy możemy uzyskać różne wyniki na tym samym pliku.

Dla osób które chciały by zgłębić ten temat polecam prezentacje Dziesięć tysięcy pułapek: ZIP, RAR, etc⁸.

Icon made by Freepik, Smashicons, Stockio, kank from www.flaticon.com

=TenThousandSecurityPitfalls_theZIPfileFormat.pdf