Jak hakerzy przejmują witryny sieci Web za pomocą iniekcji SQL i DDoS
Nawet jeśli luźno śledziłeś wydarzenia z grup hakerskich Anonymous i LulzSec, prawdopodobnie słyszałeś o atakach na strony internetowe i usługi, takich jak niesławne hacki firmy Sony. Czy kiedykolwiek zastanawiałeś się, jak to robią?
Istnieje wiele narzędzi i technik, z których korzystają te grupy, i chociaż nie staramy się podać instrukcji obsługi, warto zrozumieć, co się dzieje. Dwa z ataków, które konsekwentnie słyszysz o ich użyciu, to "(Distributed) Denial of Service" (DDoS) i "SQL Injections" (SQLI). Oto, jak działają.
Obraz wg xkcd
Atak Denial of Service
Co to jest?
"Atak typu" odmowa usługi "(czasami nazywany atakiem" Rozproszona odmowa usługi "lub DDoS) występuje wtedy, gdy system, w tym przypadku serwer WWW, otrzymuje tyle żądań jednocześnie, że zasoby serwera są przeciążone, system po prostu blokuje się i zamyka się. Celem i rezultatem udanego ataku DDoS są witryny na serwerze docelowym, które nie są dostępne dla uzasadnionych żądań ruchu.
Jak to działa?
Logistyka ataku DDoS najlepiej wyjaśnić na przykładzie.
Wyobraź sobie, że miliony ludzi (atakujących) spotyka się z celem ograniczenia działalności firmy X poprzez usunięcie ich centrum telefonicznego. Atakujący koordynują, aby we wtorek o 9 rano wszyscy zadzwonili pod numer telefonu firmy X. Najprawdopodobniej system telefoniczny firmy X nie będzie w stanie obsłużyć miliona połączeń naraz, więc wszystkie nadchodzące linie zostaną zablokowane przez atakujących. Rezultat jest taki, że prawidłowe połączenia z klientami (tj. Te, które nie są atakującymi) nie zostają zakończone, ponieważ system telefoniczny jest zajęty obsługą wywołań od atakujących. Zasadniczo firma X może potencjalnie stracić swoją działalność ze względu na to, że uzasadnione żądania nie mogą zostać zrealizowane.
Atak DDoS na serwerze działa dokładnie w ten sam sposób. Ponieważ praktycznie nie ma możliwości sprawdzenia, jaki ruch pochodzi z uzasadnionych próśb względem atakujących, dopóki serwer internetowy nie przetworzy żądania, ten typ ataku jest zazwyczaj bardzo skuteczny.
Wykonanie ataku
Z powodu "brutalnej siły" ataku DDoS, musisz skoordynować wiele komputerów, aby atakować w tym samym czasie. Ponownie odwiedzając przykład naszego centrum obsługi telefonicznej, wymagałoby to od wszystkich atakujących, aby wiedzieli zadzwonić o 9 rano i faktycznie zadzwonić w tym czasie. Chociaż ta zasada na pewno zadziała, jeśli chodzi o atakowanie serwera WWW, staje się znacznie łatwiejsza, gdy wykorzystuje się komputery zombie, zamiast rzeczywistych komputerów załogowych.
Jak zapewne wiesz, istnieje wiele wariantów złośliwego oprogramowania i trojanów, które raz w twoim systemie są uśpione, a od czasu do czasu "dzwonią do domu" po instrukcje. Jedną z tych instrukcji może być na przykład wysłanie powtórnych żądań do serwera firmy X o godzinie 9 rano. Dzięki jednemu aktualizowaniu lokalizacji domowej danego złośliwego oprogramowania jeden atakujący może natychmiast skoordynować setki tysięcy zaatakowanych komputerów w celu wykonania ogromnego ataku DDoS.
Piękno wykorzystania komputerów zombie to nie tylko skuteczność, ale także anonimowość, ponieważ atakujący wcale nie musi używać komputera do wykonania ataku.
SQL Injection Attack
Co to jest?
Atak typu "SQL injection" (SQLI) to exploit wykorzystujący słabe techniki tworzenia stron WWW i zwykle połączony z wadliwymi zabezpieczeniami baz danych. Skutkiem udanego ataku może być podszycie się pod konto użytkownika do pełnego kompromisu z odpowiednią bazą danych lub serwerem. W przeciwieństwie do ataku DDoS atak SQLI można całkowicie i łatwo zapobiec, jeśli aplikacja internetowa jest odpowiednio zaprogramowana.
Wykonanie ataku
Za każdym razem, gdy logujesz się na stronę internetową i podajesz swoją nazwę użytkownika i hasło, aby przetestować twoje poświadczenia, aplikacja internetowa może uruchomić zapytanie podobne do następującego:
SELECT UserID FROM Users WHERE UserName = "myuser" I hasło = "mypass";
Uwaga: wartości łańcuchowe w zapytaniu SQL muszą być ujęte w pojedyncze cudzysłowy, dlatego pojawiają się wokół wprowadzonych przez użytkownika wartości.
Zatem kombinacja wprowadzonej nazwy użytkownika (myuser) i hasła (mypass) musi być zgodna z wpisem w tabeli Użytkownicy, aby można było zwrócić identyfikator użytkownika. Jeśli nie ma zgodności, żaden identyfikator użytkownika nie jest zwracany, więc poświadczenia logowania są nieprawidłowe. Podczas gdy konkretna implementacja może się różnić, mechanizmy są dość standardowe.
Teraz spójrzmy na zapytanie uwierzytelniające szablon, które możemy zastąpić wartościami wprowadzonymi przez użytkownika w formularzu internetowym:
SELECT UserID FROM Users WHERE UserName = "[user]" AND Password = "[pass]"
Na pierwszy rzut oka może to wydawać się prostym i logicznym krokiem do łatwej weryfikacji użytkowników, jednak jeśli na tym szablonie zostanie wykonane proste zastąpienie wartości wprowadzonych przez użytkownika, jest on podatny na atak SQLI.
Załóżmy na przykład, że "myuser'-" jest wpisane w polu nazwy użytkownika, a hasło "wrongpass". Używając prostego podstawienia w naszym szablonie zapytań, otrzymamy to:
SELECT UserID FROM Users WHERE UserName = "myuser" - "AND Password =" wrongpass "
Kluczem do tego stwierdzenia jest włączenie dwóch kresek (-). Jest to początkowy token komentarza dla instrukcji SQL, więc wszystko pojawiające się po dwóch myślnikach (włącznie) zostanie zignorowane. Zasadniczo powyższe zapytanie jest wykonywane przez bazę danych jako:
SELECT UserID FROM Users WHERE UserName = "myuser"
Rażące zaniedbanie to brak sprawdzania hasła. Uwzględniając dwie kreski jako część pola użytkownika, całkowicie obejściliśmy warunek sprawdzania hasła i mogliśmy zalogować się jako "myuser" bez znajomości odpowiedniego hasła. Ten akt manipulowania zapytaniem w celu uzyskania niezamierzonych wyników jest atakiem typu SQL injection.
Jakie szkody można zrobić?
Atak polegający na wstrzyknięciu SQL jest spowodowany niedbałym i nieodpowiedzialnym kodowaniem aplikacji i można go całkowicie zapobiec (co omówimy za chwilę), jednak zakres szkód, które można zrobić, zależy od konfiguracji bazy danych. Aby aplikacja internetowa komunikowała się z bazą danych zaplecza, aplikacja musi dostarczyć login do bazy danych (zauważ, że jest to coś innego niż logowanie użytkownika do samej witryny). W zależności od uprawnień wymaganych przez aplikację internetową to konto bazy danych może wymagać wszystkiego, począwszy od uprawnień do odczytu / zapisu w istniejących tabelach, aż do pełnego dostępu do bazy danych. Jeśli nie jest to teraz jasne, kilka przykładów powinno pomóc w zapewnieniu jasności.
Na podstawie powyższego przykładu możesz to zobaczyć, na przykład przez wpisanie, "youruser" - "," admin "-" lub dowolną inną nazwę użytkownika, możemy natychmiast zalogować się do witryny jako ten użytkownik bez znajomości hasła. Kiedy już jesteśmy w systemie, nie wiemy, że tak naprawdę nie jesteśmy tym użytkownikiem, więc mamy pełny dostęp do odpowiedniego konta. Uprawnienia do bazy danych nie zapewniają sieci bezpieczeństwa, ponieważ zazwyczaj strona internetowa musi mieć przynajmniej prawo do odczytu / zapisu do odpowiedniej bazy danych.
Załóżmy teraz, że strona internetowa ma pełną kontrolę nad swoją bazą danych, co daje możliwość usuwania rekordów, dodawania / usuwania tabel, dodawania nowych kont zabezpieczeń itp. Ważne jest, aby pamiętać, że niektóre aplikacje internetowe mogą wymagać tego typu uprawnień, aby nie jest automatycznie złe, że przyznano pełną kontrolę.
Aby zilustrować szkody, jakie można w tej sytuacji zrobić, użyjemy przykładu z powyższego komiksu, wpisując w polu nazwy użytkownika: "Robert", Użytkownicy DROP TABLE;. Po prostym podstawieniu zapytanie uwierzytelniające staje się:
SELECT UserID FROM Users WHERE UserName = "Robert"; DROP TABLE Users; - "AND Password =" wrongpass "
Uwaga: średnik w zapytaniu SQL służy do oznaczenia końca określonej instrukcji i początku nowej instrukcji.
Które zostanie wykonane przez bazę danych jako:
SELECT UserID FROM Users WHERE UserName = "Robert"DROP TABLE Użytkownicy
Tak po prostu użyliśmy ataku SQLI do usunięcia całej tabeli Users.
Oczywiście, można zrobić o wiele gorsze rzeczy, ponieważ w zależności od dozwolonych uprawnień SQL atakujący może zmienić wartości, zrzucić tabele (lub całą samą bazę danych) do pliku tekstowego, utworzyć nowe konta logowania, a nawet przejąć całą instalację bazy danych.
Zapobieganie atakowi SQL injection
Jak wspomnieliśmy kilkakrotnie wcześniej, atak SQL injection można łatwo zapobiec. Jedną z głównych zasad tworzenia stron internetowych jest to, że nigdy nie ślepo ufasz wprowadzaniu danych przez użytkownika, tak jak to zrobiliśmy, kiedy przeprowadziliśmy proste zastępowanie w powyższym szablonowym zapytaniu..
Atak SQLI jest łatwo udaremniany przez to, co nazywa się odkażaniem (lub ucieczką) twoich danych wejściowych. Proces dezynfekcji jest w rzeczywistości dość trywialny, ponieważ w rzeczywistości zajmuje się tylko wbudowanymi znakami pojedynczego cudzysłowu (') odpowiednio w taki sposób, że nie można ich użyć do przedwczesnego zakończenia ciągu znaków w instrukcji SQL.
Na przykład, jeśli chcesz wyszukać "O'neil" w bazie danych, nie możesz użyć prostej zamiany, ponieważ pojedynczy cytat po znaku O spowoduje przedwczesne zakończenie ciągu. Zamiast tego odkaża się go za pomocą znaku ucieczki odpowiedniej bazy danych. Załóżmy, że znak "escape" dla pojedynczego cudzysłowu inline jest poprzedzony każdym cudzysłowem \ symbolem. Więc "O'neal" zostanie oczyszczony jako "O \" neil ".
Ta prosta czynność sanitacji praktycznie uniemożliwia atak SQLI. Aby zilustrować, przyjrzyjmy się naszym poprzednim przykładom i zobaczmy wynikłe zapytania, gdy dane wprowadzone przez użytkownika zostaną oczyszczone.
myuser '-- / błędne przejście:
SELECT UserID FROM Users WHERE UserName = "myuser \" - "AND Password =" wrongpass "
Ponieważ pojedynczy cudzysłów po myuser jest unikany (co oznacza, że jest uważany za część wartości docelowej), baza danych będzie dosłownie szukać nazwy użytkownika "myuser" - ". Dodatkowo, ponieważ kreski są zawarte w wartości ciągu, a nie w samym słowie SQL, będą traktowane jako część wartości docelowej, a nie interpretowane jako komentarz SQL.
Robert "; DROP TABLE Użytkownicy;-- / błędne przejście:
SELECT UserID FROM Users WHERE UserName = "Robert \"; DROP TABLE Users; - "AND Password =" wrongpass "
Po prostu unikając pojedynczego cudzysłowu po Robercie, zarówno średnik i kreski są zawarte w ciągu wyszukiwania NazwaUżytkownika, więc baza danych będzie dosłownie szukać "Robert", Użytkownicy DROP TABLE; zamiast wykonywania usuwania tabeli.
W podsumowaniu
Podczas gdy ataki internetowe ewoluują i stają się bardziej wyrafinowane lub koncentrują się na innym punkcie wejścia, ważne jest, aby pamiętać o ochronie przed wypróbowanymi i prawdziwymi atakami, które były inspiracją dla kilku swobodnie dostępnych "narzędzi hakerskich" zaprojektowanych w celu ich wykorzystania..
Niektórych rodzajów ataków, takich jak DDoS, nie można łatwo uniknąć, podczas gdy inne, takie jak SQLI, mogą. Jednak szkody, które mogą zostać spowodowane przez tego typu ataki, mogą wahać się od niedogodności do katastrof, w zależności od środków ostrożności..
