Nawet jeśli obserwujesz wydarzenia tylko luźnoz grup hakerskich Anonymous i LulzSec, prawdopodobnie słyszałeś o hakowaniu witryn i usług, takich jak niesławne hacki Sony. Czy zastanawiałeś się kiedyś, jak to robią?
Istnieje wiele narzędzi i technik, któregrupy te używają i chociaż nie próbujemy dać ci instrukcji, jak to zrobić, dobrze jest zrozumieć, co się dzieje. Dwa ataki, o których konsekwentnie słyszysz o nich, to „(rozproszona) odmowa usługi” (DDoS) i „SQL Injections” (SQLI). Oto jak działają.
Zdjęcie autorstwa xkcd
Atak typu „odmowa usługi”
Co to jest?
„Odmowa usługi” (czasami nazywanaAtak typu „rozproszona odmowa usługi” (DDoS) ma miejsce, gdy system, w tym przypadku serwer WWW, otrzymuje tak wiele żądań jednocześnie, że zasoby serwera są przeciążone, system po prostu się zamyka i wyłącza. Celem i rezultatem udanego ataku DDoS jest to, że witryny na serwerze docelowym są niedostępne dla uzasadnionych żądań ruchu.
Jak to działa?
Logistykę ataku DDoS najlepiej wyjaśnić na przykładzie.
Wyobraź sobie milion ludzi (atakujących)wraz z celem, jakim jest utrudnianie działalności Firmy X, poprzez likwidację jej centrum telefonicznego. Atakujący koordynują się tak, 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ń jednocześnie, więc wszystkie linie przychodzące zostaną zajęte przez atakujących. Powoduje to, że legalne połączenia z klientami (tj. Te, które nie są atakującymi), nie dochodzą, ponieważ system telefoniczny jest zajęty obsługą połączeń od atakujących. Zasadniczo firma X potencjalnie traci działalność z powodu niemożności zrealizowania uzasadnionych wniosków.
Atak DDoS na serwer WWW działa dokładnie tak samota sama droga. Ponieważ praktycznie nie ma sposobu, aby dowiedzieć się, jaki ruch pochodzi z uzasadnionych żądań vs. 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 mieć wiele komputerów skoordynowanych, aby atakować jednocześnie. Powracając do naszego przykładu call center, wymagałoby to od wszystkich atakujących, aby zadzwonili o 9 rano i faktycznie zadzwonili w tym czasie. Chociaż ta zasada z pewnością zadziała, jeśli chodzi o atakowanie serwera WWW, staje się znacznie łatwiejsza, gdy wykorzystywane są komputery zombie, zamiast rzeczywistych komputerów załogowych.
Jak zapewne wiesz, istnieje wiele wariantówzłośliwego oprogramowania i trojanów, które raz w systemie leżą w stanie uśpienia i czasami „dzwonią do domu” w celu uzyskania instrukcji. Jedną z tych instrukcji może być na przykład wysyłanie powtarzających się żądań do serwera WWW firmy X o godzinie 9:00. Dzięki pojedynczej aktualizacji lokalizacji domowej odpowiedniego złośliwego oprogramowania pojedynczy atakujący może natychmiast koordynować setki tysięcy zainfekowanych komputerów w celu przeprowadzenia masowego ataku DDoS.
Piękno korzystania z komputerów zombie polega nie tylko na jego skuteczności, ale także na anonimowości, ponieważ atakujący nie musi wcale używać swojego komputera do przeprowadzenia ataku.
Atak SQL Injection
Co to jest?
Atak „SQL injection” (SQLI) to exploitktóry wykorzystuje słabe techniki tworzenia stron internetowych i zwykle w połączeniu z wadliwym bezpieczeństwem bazy danych. Skutkiem udanego ataku może być podszywanie się pod konto użytkownika lub całkowity kompromis odpowiedniej bazy danych lub serwera. W przeciwieństwie do ataku DDoS, atakowi 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 stronie internetowej i podajesz swoją nazwę użytkownika i hasło, w celu przetestowania danych uwierzytelniających aplikacja internetowa może uruchomić zapytanie w następujący sposób:
SELECT UserID FROM Users WHERE UserName='myuser' AND Password='mypass';
Uwaga: wartości ciągów w zapytaniu SQL muszą być ujęte w pojedyncze cudzysłowy, dlatego pojawiają się wokół wartości wprowadzonych przez użytkownika.
Tak więc kombinacja wprowadzonej nazwy użytkownika(myuser) i hasło (mypass) muszą być zgodne z wpisem w tabeli Users, aby można było zwrócić UserID. Jeśli nie ma dopasowania, identyfikator użytkownika nie jest zwracany, więc dane logowania są nieprawidłowe. Chociaż poszczególne implementacje mogą się różnić, mechanika jest dość standardowa.
Spójrzmy teraz na zapytanie dotyczące uwierzytelnienia szablonu, które możemy zastąpić wartościami wprowadzonymi przez użytkownika w formularzu internetowym:
WYBIERZ ID UŻYTKOWNIKA OD UŻYTKOWNIKÓW GDZIE NazwaUżytkownika = „[użytkownik]’ ORAZ Hasło = „[hasło]”
Na pierwszy rzut oka może się to wydawaćprosty i logiczny krok do łatwego sprawdzania poprawności użytkowników, jednak jeśli proste zastąpienie wartości wprowadzonych przez użytkownika zostanie wykonane na tym szablonie, jest on podatny na atak SQLI.
Załóżmy na przykład, że „myuser” - jest wpisane w polu nazwy użytkownika, a „false pass” wpisane jest w haśle. Używając prostego podstawienia w naszym zapytaniu szablonowym, otrzymalibyśmy to:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Kluczem do tego stwierdzenia jest włączenie dwóch myślników (--). To jest token komentarza do początku 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żącym pominięciem tutaj jest braksprawdzanie hasła. Uwzględniając dwa myślniki jako część pola użytkownika, całkowicie ominęliśmy warunek sprawdzania hasła i mogliśmy zalogować się jako „mój użytkownik” bez znajomości odpowiedniego hasła. Ten czynność manipulowania zapytaniem w celu uzyskania niezamierzonych wyników jest atakiem iniekcyjnym SQL.
Jakie szkody można wyrządzić?
Atak typu SQL injection jest spowodowany niedbalstwem inieodpowiedzialne kodowanie aplikacji i jest całkowicie możliwe do uniknięcia (co za chwilę omówimy), jednak zakres szkód, które można wyrządzić, zależy od konfiguracji bazy danych. Aby aplikacja internetowa mogła komunikować się z bazą danych zaplecza, aplikacja musi podać login do bazy danych (uwaga, różni się to od logowania użytkownika do samej strony internetowej). W zależności od uprawnień wymaganych przez aplikację internetową, to konto bazy danych może wymagać wszystkiego, od uprawnień do odczytu / zapisu w istniejących tabelach, po pełny dostęp do bazy danych. Jeśli nie jest to teraz jasne, kilka przykładów powinno pomóc w wyjaśnieniu.
Na podstawie powyższego przykładu możesz to zobaczyć, wprowadzając na przykład "youruser'--", "admin'--" lub jakąkolwiek inną nazwę użytkownika, do której możemy się natychmiast zalogowaćwitryna jako ten użytkownik bez znajomości hasła. Gdy 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 zapewnią w tym celu siatki bezpieczeństwa, ponieważ zazwyczaj strona internetowa musi mieć co najmniej dostęp do odczytu / zapisu do odpowiedniej bazy danych.
Załóżmy teraz, że witryna ma pełną kontrolęodpowiednia baza danych, która 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ą potrzebować tego rodzaju uprawnień, więc nie jest złą rzeczą, że pełna kontrola jest Zgoda.
Aby zilustrować szkody, które można wyrządzić w tej sytuacji, skorzystamy z przykładu podanego w powyższym komiksie, wpisując w polu nazwy użytkownika: "Robert'; DROP TABLE Users;--". Po prostej zamianie zapytanie uwierzytelniające staje się:
SELECT UserID FROM Users WHERE UserName='Robert'; DROP TABLE Users;--' AND Password='wrongpass'
Uwaga: średnik w zapytaniu SQL jest używany do oznaczenia końca określonej instrukcji i początku nowej instrukcji.
Który jest wykonywany przez bazę danych jako:
SELECT UserID FROM Users WHERE UserName='Robert'
Użytkownicy DROP TABLE
Tak więc użyliśmy ataku SQLI, aby usunąć całą tabelę Użytkownicy.
Oczywiście znacznie gorzej można zrobić, w zależności odz dozwolonymi uprawnieniami SQL, atakujący może zmienić wartości, zrzucić tabele (lub całą bazę danych) do pliku tekstowego, utworzyć nowe konta logowania, a nawet przejąć kontrolę nad całą instalacją bazy danych.
Zapobieganie atakowi iniekcji SQL
Jak już kilkakrotnie wspominaliśmy, SQLatakowi iniekcyjnemu można łatwo zapobiec. Jedną z głównych zasad tworzenia stron internetowych jest to, że nigdy nie ślepo ufasz wkładowi użytkownika, tak jak zrobiliśmy to, gdy wykonaliśmy proste podstawienie w powyższym zapytaniu do szablonu.
Atak SQLI jest łatwo udaremniany przez to, co jestnazywane odkażaniem (lub ucieczką) danych wejściowych. Proces dezynfekcji jest właściwie dość trywialny, ponieważ zasadniczo zajmuje się odpowiednio obsługą dowolnych wbudowanych pojedynczych cudzysłowów („)”, tak że nie można ich użyć do przedwczesnego zakończenia ciągu wewnątrz instrukcji SQL.
Na przykład, jeśli chcesz wyszukać „O’neil” ww bazie danych nie można zastosować prostej zamiany, ponieważ pojedynczy cudzysłów po O spowoduje przedwczesne zakończenie łańcucha. Zamiast tego dezynfekujesz go za pomocą znaku zmiany znaczenia odpowiedniej bazy danych. Załóżmy, że znak zmiany znaczenia dla pojedynczego cytatu w wierszu zastępuje każdy cytat symbolem. Tak więc „O’neal” zostałby zdezynfekowany jako „O’neil”.
Ten prosty akt sanitarny praktycznie zapobiega atakowi SQLI. Aby to zilustrować, przejrzyjmy nasze poprzednie przykłady i zobaczmy powstałe zapytania, gdy dane użytkownika zostaną zdezynfekowane.
myuser'-- / błędne podanie:
SELECT UserID FROM Users WHERE UserName='myuser'--' AND Password='wrongpass'
Ponieważ pojedynczy cudzysłów po zmianie nazwy użytkownika (co oznacza, że jest uważany za część wartości docelowej), baza danych dosłownie wyszuka nazwę użytkownika "myuser'--". Ponadto, ponieważ myślniki są zawarte w wartości ciągu, a nie w samej instrukcji SQL, będą one uważane za część wartości docelowej, zamiast być interpretowane jako komentarz SQL.
Robert'; DROP TABLE Users;-- / błędne podanie:
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, jak i myślniki są zawarte w ciągu wyszukiwania nazwy użytkownika, aby baza danych dosłownie szukała "Robert'; DROP TABLE Users;--" zamiast wykonywania usuwania tabeli.
W podsumowaniu
Podczas gdy ataki internetowe ewoluują i stają się coraz bardziejwyrafinowane lub skupione na innym punkcie wejścia, ważne jest, aby pamiętać o ochronie przed wypróbowanymi i prawdziwymi atakami, które były inspiracją kilku swobodnie dostępnych „narzędzi hakerów” zaprojektowanych do ich wykorzystania.
Niektóre rodzaje ataków, takie jak DDoS, nie mogą byćłatwo uniknąć, podczas gdy inne, takie jak SQLI, mogą. Jednak szkody, które mogą być wyrządzone przez tego rodzaju ataki, mogą wahać się od niedogodności do katastroficznych, w zależności od podjętych środków ostrożności.
