w tym artykule chciałbym wykazać, jak łatwo jest uzyskać poufne informacje z aplikacji internetowej, że… nie przywiązuje wagi do bezpieczeństwa. To, z czym będę pracować, to przykładowa aplikacja Java, którą stworzyłem podczas wiosennego rozruchu w celach demonstracyjnych. Ale przeprowadzone ataki są ważne dla każdego innego języka programowania lub frameworka. Niektóre luki i problemy z bezpieczeństwem, które zostaną wykazane, obejmują:
- SQL Injection
- ekspozycja wrażliwych danych
- niewystarczające logowanie
- złamane uwierzytelnianie
konfiguracja
będziemy pracować z fikcyjną aplikacją internetową, która pozwala zalogować się jako użytkownik, który jest częścią pewnej grupy. Na podstawie roli użytkownika może przeglądać podstawowe lub poufne dane. W takim przypadku zobaczysz listę pracowników w firmie, ich status itp.
możesz znaleźć źródła do tej aplikacji w moim Githubie: https://github.com/rapasoft/hackme.
atak #1: Man in the middle attack
wyobraź sobie, że siedzisz w restauracji i chciałbyś coś sprawdzić w powyższej aplikacji. Łączysz się z Wi-Fi restauracji, otwierasz stronę logowania, wprowadzasz dane uwierzytelniające i uzyskujesz potrzebne informacje (np. listę konkretnych pracowników). Teraz możesz nie mieć dostępu do danych uwierzytelniających. Przyjrzyjmy się dokładnie stronie logowania:
ta aplikacja nie używa SSL/TLS (np. brak połączenia https://
). Oznacza to, że wszelkie przesłane informacje mogą być postrzegane jako zwykły tekst przez każdego, kto ma dostęp do komunikacji między Klientem a serwerem.
to jest dokładnie to, co dzieje się w tak zwanym ataku człowieka w środku. Dokładniej, w tym przypadku spoofing ARP został użyty jako sposób na zatrucie całej sieci, aby atakujący był świadomy wszystkiego, co się dzieje i mógł wąchać wszystkie pakiety. Nie zamierzam wchodzić w szczegóły dotyczące tego, jak działa spoofing ARP, ale zademonstruję to na tym filmie:
może być konieczne otwarcie tego filmu na Youtube w nowym oknie i na pełnym ekranie, aby zobaczyć więcej szczegółów
to, co widać powyżej, to fakt, że uruchomiłem Ettercap, który jest kompleksowym pakietem ataków MITM i wykonałem spoofing ARP w mojej sieci lokalnej. W międzyczasie, gdy użytkownik (ja przez iPada) wprowadzi poświadczenia, są one widoczne zarówno w Ettercap, jak i w Wireshark (narzędzie do analizy ruchu sieciowego).
Atak #2: SQL Injection
kontynuując naszą rolę jako atakujący tę aplikację, mamy teraz poświadczenia dla użytkownika hgraves
z hasłem P4SSW0RD
. Widać, że nie tylko ta aplikacja nie używa TLS, ma bardzo słabą politykę haseł, dzięki czemu użytkownicy wybierali naprawdę okropne hasła.
logujemy się używając powyższych danych i widzimy jedno pole wprowadzania z opcją wyszukiwania listy osób. Po naciśnięciu Search
otrzymamy pełną listę osób. Jeśli na przykład umieścimy „Fra”, otrzymamy przefiltrowane wyniki na podstawie wyszukiwania. A co jeśli umieścimy tam jakiegoś nielegalnego bohatera? Oczywiste jest, że za tą aplikacją kryje się jakaś baza danych, więc spróbujmy znaku '
:
nie tylko nie powiodło się to, ale możemy zobaczyć, że POST
request nie powiodło się z bardzo specyficznym Komunikatem o błędzie, który ujawnia strukturę całego polecenia SQL. Widzimy, że WHERE P.NAME LIKE '%'%'
jest używane na końcu.
wykwalifikowany haker nie potrzebuje więcej. Dostosowanie szukanego ciągu może po kilku próbach przynieść te wyniki:
zastrzyk w tym przypadku stworzył oświadczenie union to select, które pobiera nazwy użytkowników i hasła wraz z ich rolą. Nie tylko to się udało, ale udało nam się wyświetlić go w oryginalnej aplikacji klienckiej.
mamy teraz poświadczenia wszystkich użytkowników i ich role (wyświetlane przez liczbę całkowitą w kolumnie „wiek”). Jeśli hframe
mA rolę 1, rgraves
musi być ważniejszym użytkownikiem z rolą 3.
atak # 3: Atakowanie słabo zahaszowanych haseł
dowiedzieliśmy się w pierwszym ataku, że prawdopodobnie nie ma żadnej polityki haseł ustawionej dla tej aplikacji. To dałoby nam nadzieję, że rgraves
nie poświęca zbyt wiele uwagi bezpieczeństwu.
najprostszym sposobem na złamanie hasha hasła, który używa niewystarczającego algorytmu haszującego (jak w tym przypadku MD5) jest wykonanie ataku słownikowego lub tęczowej tabeli. Możliwości jest wiele, ale najłatwiej jest skorzystać z usług internetowych, które mają już dużą bazę kombinacji password-to-hash:
pierwszy to
hframe
, drugi torgraves
.smorgan
wydaje się, że używa silniejszych haseł niż inne, ponieważ nie ma ich w słowniku .
widać, że hasło do rgraves
to miecznik, co oznacza, że nie wie teraz jak ważne jest wybranie hasła nie-słownikowego;). Teraz nic nie powstrzymuje nas przed zalogowaniem się jako ten użytkownik i odkryciem sekcji „admin” oraz poufnych informacji:
nie czytaj tego, jeśli jesteś Niemcem 🙂
Jak to naprawić?
można powiedzieć, że można temu wszystkiemu łatwo zapobiec. Można powiedzieć, że to były błędy nowicjuszy. Cóż, może to być prawda, ale prawdą jest również to, że projekt Open Web Application Security wymienia Injection jako lukę #1 w aplikacjach internetowych (i tak jest od kilku lat).
więc jeśli zastanawiasz się, jak temu zapobiec, podsumujmy:
- Zawsze używaj protokołu SSL / TLS podczas wysyłania czegoś na serwer. Nie musi to być poświadczenie, jest obecnie uważane za dobrą praktykę w ogóle. Nawet jeśli nie masz żadnych wejść na swojej stronie w ogóle! Najprostszym sposobem jest dostarczenie certyfikatu za pośrednictwem usług takich jak Let ’ s Encrypt.
- pamiętaj, że samodzielnie podpisane certyfikaty mogą złagodzić problem narażenia na działanie danych, ale nie uniemożliwiają atakującemu MITM podrabiania całej witryny za pomocą całkowicie podpisanego certyfikatu.
- w przypadku zapytań SQL zawsze unikaj parametrów uzyskanych od klienta. Najprostszym sposobem na to jest wykorzystanie możliwości Twojego frameworka, np. wiosną możesz użyć NamedParameterJdbcTemplate, co jest również dobre dla czytelności.
- bądź paranoikiem. Zweryfikuj wszelkie dane wejściowe użytkownika. Ponownie w Java / Spring world możesz dodać reguły walidacji używając implementacji walidacji
JSR-380
, takiej jak walidator Hibernate i parametry adnotacji, np.@Pattern(regexp = "*") String name
uniemożliwiłoby wpisanie'
. - rejestruje wszelkie próby przekazania nieprawidłowych danych wejściowych w aplikacji. Ponadto w przypadku błędu nie ujawniaj klientowi żadnych informacji dotyczących wdrożenia.
- popraw uwierzytelnianie.
- jeśli to możliwe, użyj przynajmniej uwierzytelniania dwuskładnikowego.
- nie implementuj niestandardowych algorytmów przechowywania haseł ani szyfrowania. Jest to niezwykle trudne do zrobienia na własną rękę i na pewno nie. Istnieją sprawdzone rozwiązania, takie jak BCrypt.
- Przeczytaj i dodaj do ulubionych OWASP TOP 10. Zacznij od tego, a następnie przejrzyj ich listę najlepszych praktyk.