Kiedyś, około 2000 roku, korzystanie z Internetu ograniczało się zazwyczaj do przejrzenia poczty i przeczytania kilku newsów. Niektórzy bardziej „zaawansowani” podejmowali się internetowych zakupów np. na rozwijającym się wówczas Allegro. Obecnie technologia poszła do przodu tak bardzo, że jesteśmy w stanie zrobić większość rzeczy bez wychodzenia z domu. Płacimy rachunki, robimy zakupy, doładowujemy telefon, korzystamy z portali społecznościowych. Wszystkie te udogodnienia spowodowały również wzrost czyhających na użytkowników zagrożeń. Obecne strony internetowe mają dużo więcej zadań niż tylko wyświetlić teksty, obrazki czy kilka tabel. Często są to poważne aplikacje internetowe, które przyjmują sporo danych od użytkowników i wykonują różne, niejednokrotnie skomplikowane operacje.

OWASP Top 10

Twórcy oprogramowania powinni być świadomi, na co narażone są aplikacje i nie powinni podchodzić do tematu bezpieczeństwa niedbale. Skąd mogą czerpać wiedzę na ten temat? Z pomocą przychodzi OWASP. Jest to fundacja działająca non-profit, mająca na celu zwiększenie poziomu bezpieczeństwa aplikacji internetowych. Fundacja ta regularnie wydaje dokument OWASP Top 10, który zawiera, jak sama nazwa wskazuje, listę 10 najpopularniejszych podatności występujących w aplikacjach internetowych. Po więcej informacji na temat działalności organizacji i jej projektów zapraszam na stronę internetową.

Proponuję Wam serię wpisów blogowych, z których każdy będzie poświęcony jednej z pozycji z listy OWASP Top 10. W tym artykule zajmiemy się numerem jeden – Injection.

Czym są ataki typu Injection?

Injection to podatność polegająca na wstrzyknięciu danych, które zmuszają aplikację do nieprawidłowego, często szkodliwego działania. Czym może skończyć się taki atak? Możliwości jest wiele. Są to np.:

• Kompromitacja całego systemu
• Utrata danych
• Ominięcie uwierzytelnienia
• Kradzież danych

Nieprawidłowe działanie niejednokrotnie jest spowodowane brakiem odpowiedniej filtracji parametrów pochodzących od użytkownika. Do rodzajów wstrzyknięć należą m.in.:

SQL Injection
Polega na wstrzyknięciu złośliwego kodu w zapytanie SQL, co może spowodować np. zwrócenie poufnych informacji z bazy danych. Na ten atak narażone są aplikacje przyjmujące dane od użytkownika, które bezpośrednio bez żadnego filtrowania trafiają do zapytania SQL.

OS Command Injection
Atak zbliżony do SQL Injection, ale zamiast fragmentu kodu SQL atakujący wstrzykuje ładunek, który zostaje wykonany jako komenda systemowa. Atak ten jest możliwy, jeżeli aplikacja wykonuje wywołania systemowe i dane od użytkownika uczestniczą w ich wykonaniu.

LDAP Injection
Analogicznie do pozostałych, ale zamiast kodu SQL i komend systemowych, atakujący wstrzykuje złośliwy kod w wyrażenie LDAP

XPATH Injection
XPATH to mechanizm umożliwiający pobieranie wybranego fragmentu z pliku XML. Atakujący skupia się na uzyskaniu dostępu do zawartości pliku XML, próbując wstrzyknąć złośliwy kod do zapytania XPATH.

SQL Injection

W dobie nowoczesnych frameworków, dużej liczby publikacji na temat pisania bezpiecznego kodu oraz znanych sposobów zapobiegania tego typu atakom, podatność ta jest ciągle żywa. Występuje raczej w starszych aplikacjach. Do wytłumaczenia mechanizmu działania podatności związanych ze wstrzyknięciami posłużę się przykładem opartym na SQL Injection.

Atak ten polega na doklejeniu szkodliwego fragmentu do zapytania znajdującego się w kodzie programu. Najczęściej winą jest zapisanie zapytania jako zwykłego stringa i doklejenie do niego parametrów za pomocą konkatenacji. Poniżej przedstawiam przykład takiego zapytania:

Parametry username oraz password są dostarczane przez użytkownika np. z pól formularza. W celu pokazania, do jakich danych może dostać się osoba, której udał się atak, użyłem aplikacji mutillidae udostępnionej przez OWASP. Służy ona do przeprowadzenia ćwiczeń związanych z testowaniem bezpieczeństwa aplikacji internetowych. Poniżej pokazuję przykładowy formularz wymagający podania loginu i hasła w celu wyciągnięcia szczegółów konta. Pochodzi on z wyżej wymienionej aplikacji.

W celu sprawdzenia, czy w aplikacji nie ma źle skonfigurowanej parametryzacji zapytań SQL, możemy dla testu w pole name wpisać apostrof.

Wysłanie tak uzupełnionego formularza powoduje następującą odpowiedź z aplikacji:

Jak widać, mamy do czynienia ze źle skonfigurowaną obsługą błędów. Z tego komunikatu atakujący jest w stanie dowiedzieć się, z jakiej bazy danych korzysta aplikacja, a także jakie zapytanie używane jest pod spodem. Zwróćmy uwagę na fragment username=”’. Dzięki temu fragmentowi jesteśmy w stanie stwierdzić, że wejściowy parametr nie został w żaden sposób zwalidowany ani przefiltrowany, a zapytanie tworzone jest za pomocą konkatenacji.

Jest to idealny cel do przeprowadzenia ataku SQL Injection. Pole name uzupełniamy tak jak na obrazku poniżej.

Po wysłaniu requesta do aplikacji, wyrażenie, które jest pod spodem, przyjmuje następującą postać:

Na zielono oznaczyłem apostrof, który łączy się z zaznaczonym na czerwono fragmentem podanym w polach formularza i tworzy jedno spójne zapytanie. 1=1 to warunek logiczny, który zawsze daje nam wartość True, w związku z tym w naszym wyrażeniu zawsze będziemy mieć spełniony warunek, który znajduje się po słowie kluczowym OR, dodatkowo – – powoduje zakomentowanie tego, co się znajduje za nim. Wpływa to na niewykonanie fragmentu zapytania oznaczonego na szaro.

Poniżej zamieszczam przykład, który pokazuje, co zwraca nam aplikacja mutillidae.

Oczywiście jest to tylko prosty przykład. Atakujący może spowodować nawet usunięcie całej bazy danych.

Blind SQL Injection

Nie zawsze jednak dostajemy dane bezpośrednio od użytkownika. Czasem nie mamy możliwości sprawdzenia odpowiedzi zwróconej przez serwer. Jest to specyficzna kategoria podatności z rodziny Injection. Z pomocą w testowaniu takich podatności przychodzi np. funkcja sleep. Umożliwia ona wstrzymanie wykonywania bieżącego wątku na określony czas.

Pewnym ograniczeniem takiego testowania jest to, że możemy uzyskać jedynie odpowiedź „tak” lub „nie”. W poniższym przykładzie sprawdzamy, czy podana przez nas litera jest równa pierwszej literze hasła, które próbujemy złamać:

Jeżeli zapytanie wykona się błyskawicznie, to znaczy, że „A” nie jest pierwszą literą łamanego hasła. W przeciwnym wypadku, jeśli odpowiedź będzie trwała dłużej, oznacza to, że warunek został spełniony, a my możemy szukać kolejnej litery.

To tylko dwa przykłady podatności typu Injection. Temat jest dość szeroki, a jego rozwinięcie można znaleźć na stronie OWASP.

SQLMap

Dzięki automatyzacji nie jesteśmy skazani na żmudne szukanie takich podatności. Z pomocą przychodzą nam różne programy. Jednym z popularniejszych jest SQLMap, open source’owe narzędzie umożliwiające łatwe testowanie aplikacji pod kątem występowania podatności SQL Injection.

SQLMap posiada sporo funkcjonalności. Są to m.in.:

• Obsługa następujących baz danych: MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB i HSQLDB
• Obsługa różnych typów SQL Injection
  • wstrzykiwanie oparte na wartościach boolowskich (boolean-based blind)
  • wstrzykiwanie bazujące na czasie (time-based blind)
  • wstrzykiwanie bazujące na błędach (error-based)
  • z użyciem UNION (UNION query)
  • z użyciem stosów zapytań (stacked queries)

• Możliwość działania jako klient bazy danych
• Integracja z projektami Metasploit i w3af
• Wsparcie dla pobierania i wysyłania plików do serwera bazy danych

Więcej o SQLMap można dowiedzieć się na stronie projektu. Jeżeli pojawi się zainteresowanie tematem, to chętnie poświęcę osobny artykuł na omówienie obsługi tego narzędzia. 🙂

Wnioski

Liczba podatności w aplikacjach internetowych nie maleje. A wraz z nowymi technologiami pojawiają się nowe luki. Całe szczęście rośnie również świadomość programistów na temat tego typu zagrożeń. Dodatkowo w Internecie można znaleźć sporo artykułów na temat bezpiecznego pisania kodu.

Przede wszystkim nie powinniśmy pod żadnym pozorem używać budowania wyrażeń za pomocą konkatenacji. Zapytania powinny być budowane np. za pomocą prepared statement. Wszystkie parametry przychodzące od użytkownika powinny być odpowiednio walidowane i filtrowane. Należy również zwracać uwagę na to, żeby w zespole była świadomość występowania takich podatności, co pozwoli wykryć ewentualne błędy np. podczas code review. Jeżeli używamy nowoczesnych frameworków, to problem bardzo często nas nie dotyczy, co nie znaczy, że jesteśmy w 100% bezpieczni. Dlaczego? Zainteresowanym tym tematem polecam lekturę artykułu „HQL Injection Exploitation in MySQL”.

Bardziej szczegółowy opis metod zabezpieczenia przed tego typu podatnościami można znaleźć w materiale SQL Injection Prevention udostępnionym przez OWASP.

Paweł Kaleciński  – Full Stack Developer w Onwelo. Zainteresowany nowinkami technicznymi, bezpieczeństwem aplikacji internetowych i muzyką rockową.