Zagrożenia w sieci

Protokół LDAP

Problem

Do zarządzania danych identyfikacyjnych i uwierzytelniania użytkowników w wielu aplikacjach wykorzystywany jest protokół LDAP (Lightweight Directory Access Protocol). Jeśli aplikacja nie będzie odpowiednio przetwarzać danych wejściowych użytkownika, zanim doda je do kwerend LDAP, to złośliwy użytkownik będzie mógł zmodyfikować logikę kwerendy. W ten sposób może mu się udać uwierzytelnić samego siebie bez znajomości danych identyfikacyjnych, uzyskać dostęp do poufnych informacji, a nawet dodać bądź usunąć treść z serwera.

Rozwiązanie

Aby przetestować podatność aplikacji na wstrzykiwanie instrukcji LDAP, spróbowaliśmy wprowadzić w polach wejściowych, co do których istnieje podejrzenie wykorzystywania w kwe­rendach LDAP, dane z listy zamieszczonej poniżej. Następnie obserwowaliśmy nietypowe odpowiedzi przesyłane przez serwer. Zaliczyć do nich można: losowy rekord użytkownika, listę wszystkich użytkowników itp. Otrzymanie takiej nietypowej odpowiedzi oznacza, że aplikacja jest wrażliwa na wstrzykiwanie instrukcji LDAP.

• *•

*)(|(cn=*;

*)(|(cn=*);

*)(|(cn=*));

zwykłeDaneWe)(l(cn=*;

zwykłeDaneWe)(|(cn=*);

zwykłeDaneWe)(|(cn=*)).

Aby podjąć próbę wstrzykiwania LDAP podczas uwierzytelniania użytkownika, należy wpro­wadzić ciągi znaków nazwy użytkownika i hasła w miejscu występowania ciągu zwykłeDaneWe. Można również wprowadzić w systemie istniejącą nazwę użytkownika oraz podstawić jeden z ciągów w roli hasła, a następnie spróbować wprowadzić w systemie istniejące hasło i pod­stawić jeden z ciągów jako nazwę użytkownika.

DYSKUSJA

Podczas wykonywania ataku wstrzykiwania instrukcji LDAP celem napastnika było uwierzytelnianie bez podania danych identyfikacyjnych lub uzyskanie dostępu do poufnych in­formacji. Obejmuje to odgadywanie postaci kwerendy LDAP, a następnie wstrzykiwanie spe­cjalnie spreparowanych danych wejściowych w celu modyfikacji jej logiki.

Spróbujmy skorzystać z przykładowych testowych danych wejściowych omówionych wcze­śniej w punkcie „Rozwiązanie". Pierwszy test byłby odpowiedni, gdyby kwerenda LDAP była podobna do kodu pokazanego w listingu:

Kwerenda LDAP do wyszukiwania nazwy użytkownika i hasła

(&(cn=nazwaUżytkownika)(password=hasłoUżytkownika))

Jeśli aplikacja uruchamia powyższą kwerendę i zakłada, że uwierzytelnianie przebiegło po­myślnie, gdy kwerenda zwróciła co najmniej jeden rekord, to napastnik będzie mógł prze­prowadzić uwierzytelnianie bez nazwy użytkownika lub hasła, jeśli w roli nazwy użytkow­nika i hasła wprowadzi znak *.

Kwerenda LDAP do wyszukiwania danych według nazwy użytkownika

(&(cn=nazwallżytl<ownika)(type=llsers))

Aplikacja powinna zawierać mechanizm blokowania konta działający w ten sposób, że po trzech kolejnych nieprawidłowych próbach logowania dla bezpieczeństwa blokuje konto użytkow­nika. Zastanów się, co się stanie, jeśli użytkownik wprowadzi jako nazwę użytkownika ciąg nazwaUżytkownika) (password=próbaOdgadnięcia oraz próbaOdgadnięcia jako hasło. Kwerenda LDAP przyjmie postać (&(cn=nazwaUżytkownika)(password=próbaOdgadnięcia)(type=lsers)) i zwróci rekord tylko wtedy, gdy hasłem użytkownika nazwaUżytkownika jest ciąg próba­Odgadnięcia. Jeśli kwerenda nie zwróci rekordu, to aplikacja stwierdzi, że nazwa użytkow­nika wprowadzona przez napastnika jest nieprawidłowa, i nie będzie mogła zablokować konta. Kiedy napastnikowi uda się odgadnąć prawidłowe hasło, uwierzytelnianie przebie­gnie pomyślnie. A zatem napastnik skutecznie pomija mechanizm blokowania konta i może odgadywać hasła metodą siłową.

Napastnik, żeby przeprowadzić skuteczne uwierzytelnianie w aplikacji, mógł wprowa­dzić symbol * w roli nazwy użytkownika oraz dowolne prawidłowe hasło w systemie. Wprowadzenie znaku * jako nazwy użytkownika powodowało zwrócenie wszystkich rekor­dów w magazynie LDAP. Aplikacja, która wykryła zwrócenie wielu rekordów, mogła sprawdzić hasło wprowadzone przez napastnika z wszystkimi zwróconymi rekordami i pomyślnie uwie­rzytelnić użytkownika, jeśli dla dowolnego rekordu para nazwa użytkownika - hasło paso­wała do siebie! Bezpieczeństwo aplikacji było więc zredukowane do możliwości odgadnięcia przez napastnika najsłabszego hasła w systemie.

Podczas interaktywnego testowania podatności na wstrzykiwanie in­strukcji LDAP przydaje się monitorowanie rzeczywistych kwerend, jakie generuje aplikacja. W ten sposób można dostroić atak do potrzeb konkretnej aplikacji. Istnieje kilka sposobów, jak można to zrobić. Jeśli do zabezpieczenia komunikacji pomiędzy aplikacją a serwerem LDAP nie jest wykorzystywany protokół SSL, to można użyć sniffera sieciowego do przeglą­dania kwerend aplikacji razem z odpowiedziami serwera LDAP. Dzienniki zdarzeń aplikacji lub dzienniki zdarzeń serwera LDAP to kolejne miejsca, gdzie mogą być dostępne wygene­rowane kwerendy.