Nawet jeśli tylko luźno śledziliście wydarzenia z grup hakerskich Anonymous i LulzSec, prawdopodobnie słyszeliście o włamaniach do witryn internetowych i usług, takich jak niesławne hacki Sony. Czy kiedykolwiek zastanawiałeś się, jak oni to robią?
Istnieje wiele narzędzi i technik, z których korzystają te grupy i chociaż nie próbujemy udostępniać instrukcji, jak zrobić to samemu, warto zrozumieć, co się dzieje. Dwa z ataków, o których często słyszysz, to „(rozproszona) odmowa usługi” (DDoS) i „SQL Injections” (SQLI). Oto jak działają.
Zdjęcie autorstwa xkcd
Atak Denial of Service
Co to jest?
Atak typu „odmowa usługi” (czasami nazywany „rozproszoną odmową usługi” lub DDoS) ma miejsce, gdy system, w tym przypadku serwer WWW, odbiera tyle żądań jednocześnie, że zasoby serwera są przeciążone, że system po prostu się blokuje i wyłącza się. Celem i wynikiem udanego ataku DDoS jest to, że strony internetowe na serwerze docelowym są niedostępne dla uprawnionych żądań ruchu.
Jak to działa?
Logistykę ataku DDoS najlepiej wyjaśnić na przykładzie.
Wyobraź sobie, że milion osób (napastników) spotyka się w celu utrudnienia działalności firmy X poprzez likwidację ich call center. Atakujący tak koordynują, że we wtorek o 9 rano wszyscy zadzwonią 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 linie przychodzące zostaną zajęte przez atakujących. W rezultacie legalne połączenia klientów (tj. Te, które nie są atakującymi) nie są przekazywane, ponieważ system telefoniczny jest zajęty, obsługując połączenia od atakujących. Zasadniczo więc firma X potencjalnie traci interes z powodu niemożności dotarcia do uzasadnionych żądań.
Atak DDoS na serwer WWW działa dokładnie w ten sam sposób. Ponieważ praktycznie nie ma sposobu, aby dowiedzieć się, jaki ruch pochodzi z uzasadnionych żądań w porównaniu z napastnikami, dopóki serwer WWW nie przetworzy żądania, ten typ ataku jest zazwyczaj bardzo skuteczny.
Wykonanie ataku
Ze względu na „brutalną siłę” ataku DDoS, musisz mieć wiele komputerów skoordynowanych, aby przeprowadzać ataki w tym samym czasie. Wracając do naszego przykładu z call center, wymagałoby to od wszystkich napastników, aby zarówno wiedzieli, że dzwonią o 9 rano, jak i faktycznie dzwonią o tej porze. Chociaż ta zasada z pewnością 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 i czasami „dzwonią do domu” po instrukcje. Jedną z tych instrukcji może być na przykład wysyłanie powtarzających się żądań do serwera internetowego Firmy X o godzinie 9 rano. Dzięki pojedynczej aktualizacji lokalizacji domowej odpowiedniego złośliwego oprogramowania pojedynczy atakujący może natychmiast skoordynować 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 jego anonimowości, ponieważ osoba atakująca nie musi w rzeczywistości w ogóle używać swojego komputera do wykonania ataku.
Atak typu SQL Injection Attack
Co to jest?
Atak typu „wstrzyknięcie SQL” (SQLI) to exploit wykorzystujący słabe techniki tworzenia stron internetowych i, zazwyczaj w połączeniu z wadliwymi zabezpieczeniami bazy danych. Skutkiem udanego ataku może być podszywanie się pod konto użytkownika lub całkowite złamanie zabezpieczeń 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ę do witryny internetowej i wprowadzasz swoją nazwę użytkownika i hasło, w celu przetestowania Twoich danych uwierzytelniających aplikacja internetowa może uruchomić zapytanie podobne do następującego:
WYBIERZ ID UŻYTKOWNIKA Z UŻYTKOWNIKÓW WHERE UserName = 'myuser' AND Password = 'mypass';
Uwaga: wartości łańcuchowe w zapytaniu SQL muszą być ujęte w pojedyncze cudzysłowy, dlatego pojawiają się one wokół wartości wprowadzonych przez użytkownika.
Zatem połączenie wprowadzonej nazwy użytkownika (myuser) i hasła (mypass) musi być zgodne z wpisem w tabeli Users, aby zwracany był identyfikator użytkownika. Jeśli nie ma dopasowania, nie jest zwracany żaden identyfikator użytkownika, więc dane logowania są nieprawidłowe. Chociaż poszczególne implementacje mogą się różnić, mechanika jest dość standardowa.
Spójrzmy teraz na zapytanie uwierzytelniające szablon, w którym możemy podstawić wartości wprowadzone przez użytkownika w formularzu internetowym:
WYBIERZ ID użytkownika spośród użytkowników WHERE nazwa_użytkownika = '[user]' AND hasło = '[pass]'
Na pierwszy rzut oka może się to wydawać prostym i logicznym krokiem do łatwego sprawdzania poprawności użytkowników, jednak jeśli w tym szablonie wykonywane jest proste podstawienie wartości wprowadzonych przez użytkownika, jest on podatny na atak SQLI.
Na przykład załóżmy, że w polu nazwy użytkownika wpisano „myuser’–”, a hasło „błędne hasło”. Używając prostego podstawienia w naszym zapytaniu szablonowym, otrzymalibyśmy:
WYBIERZ ID UŻYTKOWNIKA Z UŻYTKOWNIKÓW WHERE NazwaUżytkownika = 'myuser' - 'AND Password =' błędne przejście '
Kluczem do tego stwierdzenia jest uwzględnienie dwóch myślników
(--)
. To jest token początku komentarza dla instrukcji SQL, więc wszystko, co pojawia się po dwóch myślnikach (włącznie), zostanie zignorowane. Zasadniczo powyższe zapytanie jest wykonywane przez bazę danych jako:
WYBIERZ ID użytkownika z użytkowników WHERE nazwa_użytkownika = 'myuser'
Rażącym pominięciem jest tutaj brak sprawdzania hasła. Dodając dwie kreski jako część pola użytkownika, całkowicie pominęliśmy warunek sprawdzania hasła i mogliśmy zalogować się jako „myuser” bez znajomości odpowiedniego hasła. Ta czynność polegająca na manipulowaniu zapytaniem w celu uzyskania niezamierzonych wyników jest atakiem typu SQL injection.
Jakie szkody można wyrządzić?
Atak typu SQL injection jest spowodowany niedbałym i nieodpowiedzialnym kodowaniem aplikacji i jest całkowicie możliwy do uniknięcia (o czym za chwilę), 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, jest to inne niż logowanie użytkownika do samej witryny internetowej). W zależności od uprawnień wymaganych przez aplikację internetową, to odpowiednie konto bazy danych może wymagać wszystkiego, od uprawnień do odczytu / zapisu tylko w istniejących tabelach do pełnego dostępu do bazy danych. Jeśli teraz nie jest to jasne, kilka przykładów powinno pomóc w wyjaśnieniu.
Na podstawie powyższego przykładu możesz to zobaczyć wpisując np.
"youruser '-", "admin' -"
lub jakąkolwiek inną nazwę użytkownika, możemy natychmiast zalogować się do serwisu jako ten użytkownik bez znajomości hasła. Kiedy już jesteśmy w systemie, nie wiemy, że w rzeczywistości nie jesteśmy tym użytkownikiem, więc mamy pełny dostęp do odpowiedniego konta. Uprawnienia do bazy danych nie zapewniają zabezpieczenia w tym zakresie, ponieważ zazwyczaj witryna internetowa musi mieć co najmniej dostęp do odczytu / zapisu do odpowiedniej bazy danych.
Załóżmy teraz, że witryna internetowa ma pełną kontrolę nad swoją odpowiednią bazą danych, co daje możliwość usuwania rekordów, dodawania / usuwania tabel, dodawania nowych kont zabezpieczeń itp. Należy pamiętać, że niektóre aplikacje internetowe mogą potrzebować tego typu pozwolenia, więc przyznanie pełnej kontroli nie jest automatycznie złą rzeczą.
Aby więc zilustrować szkody, które można wyrządzić w tej sytuacji, posłużymy się przykładem z komiksu powyżej, wpisując w polu nazwy użytkownika:
"Robert '; DROP TABLE Users; -".
Po prostym podstawieniu zapytanie uwierzytelniające staje się:
WYBIERZ ID użytkownika z użytkowników WHERE UserName = 'Robert'; DROP TABLE Users; - 'AND Password =' błędne przejście '
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:
WYBIERZ ID UŻYTKOWNIKA Z UŻYTKOWNIKÓW WHERE UserName = 'Robert'DROP TABLE Użytkownicy
W ten sposób użyliśmy ataku SQLI do usunięcia całej tabeli Users.
Oczywiście można zrobić o wiele gorzej, ponieważ w zależności od dozwolonych uprawnień SQL atakujący może zmienić wartości, zrzucić tabele (lub całą bazę danych) do pliku tekstowego, utworzyć nowe konta logowania lub nawet przejąć całą instalację bazy danych.
Zapobieganie atakowi typu SQL injection
Jak już kilkakrotnie wspominaliśmy, atakowi typu SQL injection można łatwo zapobiec. Jedną z głównych zasad tworzenia stron internetowych jest to, że nigdy ślepo nie ufasz wprowadzaniu danych przez użytkownika, tak jak to zrobiliśmy, gdy wykonaliśmy proste podstawianie w naszym szablonie zapytania powyżej.
Atak SQLI można łatwo udaremnić przez tak zwane odkażanie (lub ucieczkę) danych wejściowych. Proces oczyszczania jest w rzeczywistości dość trywialny, ponieważ zasadniczo obsługuje wszystkie znaki pojedynczego cudzysłowu (') w wierszu w taki sposób, że nie można ich użyć do przedwczesnego zakończenia ciągu w instrukcji SQL.
Na przykład, jeśli chcesz wyszukać „O’neil” w bazie danych, nie możesz użyć prostego podstawienia, ponieważ pojedynczy cudzysłów po O spowodowałby przedwczesne zakończenie ciągu. Zamiast tego odkażasz go za pomocą znaku ucieczki odpowiedniej bazy danych. Załóżmy, że znak zmiany znaczenia w pojedynczym cudzysłowie w wierszu poprzedza każdy cytat znakiem \. Zatem „O’neal” zostanie odkażone jako „O \ 'neil”.
Ta prosta czynność sanitarna prawie zapobiega atakowi SQLI. Aby to zilustrować, wróćmy do naszych poprzednich przykładów i zobaczmy wynikowe zapytania, gdy dane wejściowe użytkownika zostaną oczyszczone.
myuser '-
/
błędne przejście
:
WYBIERZ ID użytkownika Z użytkowników WHERE UserName = 'myuser \' - 'AND Password =' błędne przejście '
Ponieważ pojedynczy cudzysłów po znaku ucieczki myuser jest chroniony (co oznacza, że jest uważany za część wartości docelowej), baza danych dosłownie wyszuka nazwę użytkownika
„myuser '-”.
Dodatkowo, ponieważ myślniki 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 ”; DROP TABLE Użytkownicy; -
/
błędne przejście
:
WYBIERZ IDENTYFIKATORA UŻYTKOWNIKÓW OD użytkowników WHERE UserName = 'Robert \'; DROP TABLE Users; - 'AND Password =' błędne przejście '
Po prostu zmieniając znaczenie pojedynczego cudzysłowu po Robercie, zarówno średnik, jak i myślniki są zawarte w ciągu wyszukiwania nazwa_użytkownika, więc baza danych dosłownie wyszuka
"Robert '; DROP TABLE Users; -"
zamiast wykonywać usuwanie 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 bezpłatnych „narzędzi hakerskich” zaprojektowanych w celu ich wykorzystania.
Niektórym typom ataków, takich jak DDoS, nie można łatwo uniknąć, podczas gdy innych, takich jak SQLI, można. Jednak szkody, które mogą wyrządzić tego typu ataki, mogą wahać się od niedogodności do katastrofalnych, w zależności od podjętych środków ostrożności.
