Nawet jeśli luźno śledziłeś wydarzenia z grup hakerów Anonymous i LulzSec, prawdopodobnie słyszałeś o zhackowaniu witryn i usług, takich jak niesławne hacki firmy Sony. Czy zastanawiałeś się kiedyś, 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
Co to jest?
Atak typu "odmowa usługi" (czasami nazywany atakiem "Rozproszona odmowa usługi" lub DDoS) występuje, gdy system, w tym przypadku serwer sieci Web, otrzymuje tyle żądań jednocześnie, że zasoby serwera są przeciążone, system po prostu blokuje się i wyłącza 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ń na raz, więc wszystkie nadchodzące linie zostaną zablokowane przez atakujących. Rezultat jest taki, że legalne 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 potencjalnie traci swoją działalność, ponieważ uzasadnione żądania nie mogą zostać zrealizowane.
Atak DDoS na serwerze działa dokładnie w ten sam sposób. Ponieważ praktycznie nie ma sposobu, aby dowiedzieć się, 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. Wracając do naszego przykładu z centrum obsługi, wymagałoby to, aby wszyscy atakujący oboje wiedzieli zadzwonić o 9 rano i faktycznie zadzwonić w tym czasie. Chociaż ta zasada na pewno zadziała, jeśli chodzi o atakowanie serwera internetowego, staje się znacznie łatwiejsza, gdy wykorzystywane są 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 pojedynczemu uaktualnieniu do macierzystego położenia danego złośliwego oprogramowania, jeden atakujący może natychmiast skoordynować setki tysięcy zainfekowanych 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.
Co to jest?
Atak "SQL injection" (SQLI) jest exploitem, który wykorzystuje słabe techniki tworzenia stron internetowych i, zazwyczaj w połączeniu 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.
Tak więc kombinacja wprowadzonej nazwy użytkownika (myuser) i hasła (mypass) musi być zgodna z wpisem w tabeli Users, aby można było zwrócić UserID. 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 proste podstawienie wprowadzonych przez użytkownika wartości jest wykonywane na tym szablonie, jest podatne na atak SQLI.
Załóżmy na przykład, że "myuser" - jest wpisane w polu nazwy użytkownika, a hasło "błędne przejście". Używając prostego podstawienia w naszym szablonowym zapytaniu, otrzymalibyśmy 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"
Oczywistym pominięciem tutaj jest 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 typu "wstrzyknięcie 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ć od uprawnień do odczytu / zapisu w istniejących tabelach tylko do pełnego dostępu do bazy danych. Jeśli nie jest to jasne, kilka przykładów powinno pomóc w zapewnieniu jasności.
Na podstawie powyższego przykładu możesz to zobaczyć, wpisując np. "youruser" - "," admin "-" lub jakakolwiek inna nazwa użytkownika, możemy natychmiast zalogować się do witryny jako ten użytkownik bez znajomości hasła. Gdy 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ć co najmniej dostęp 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, które można zrobić w tej sytuacji, użyjemy przykładu przedstawionego w powyższym komiksie, 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 = "błędne przejście"
Uwaga: średnik w zapytaniu SQL służy do oznaczenia końca danej instrukcji i początku nowej instrukcji.
Które zostanie wykonane przez bazę danych jako:
SELECT UserID FROM Users WHERE NazwaUżytkownika = "Robert"DROP TABLE Użytkownicy
Tak po prostu użyliśmy ataku SQLI, aby usunąć całą tabelę 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 już kilkakrotnie wspominaliśmy, 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 istocie rzeczy traktuje wszystkie wbudowane znaki pojedynczego cudzysłowu (') odpowiednio, tak, że nie można ich użyć do przedwczesnego zakończenia ciągu znaków wewnątrz 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 zapobiega atakowi SQLI. Aby zilustrować, przyjrzyjmy się naszym poprzednim przykładom i zobaczmy wynikłe zapytania, gdy dane wejściowe 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 dosłownie wyszuka nazwę użytkownika "myuser" - ". Dodatkowo, ponieważ kreski są zawarte w wartości ciągu, a nie w samej instrukcji SQL, będą traktowane jako część wartości docelowej, a nie interpretowane jako komentarz SQL.
Robert "; Użytkownicy DROP TABLE; / błędne przejście:
SELECT UserID FROM Users WHERE UserName = "Robert \"; DROP TABLE Users; - 'AND Password = "błędne przejście"
Po prostu wymykając się pojedynczemu cudzysłowiowi po Robercie, zarówno średnik i kreski są zawarte w ciągu wyszukiwania NazwaUżytkownika, więc baza danych będzie dosłownie wyszukiwać "Robert"; DROP TABLE Users; - " zamiast wykonywania usuwania tabeli.
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 tym, aby chronić się 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 katastrofalnych w zależności od podjętych środków ostrożności.
