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 kwerendach 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 wprowadzić 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 podstawić 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 informacji. Obejmuje to odgadywanie postaci kwerendy LDAP, a następnie wstrzykiwanie specjalnie 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 pomyślnie, gdy kwerenda zwróciła co najmniej jeden rekord, to napastnik będzie mógł przeprowadzić uwierzytelnianie bez nazwy użytkownika lub hasła, jeśli w roli nazwy użytkownika 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żytkownika. 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óbaOdgadnięcia. Jeśli kwerenda nie zwróci rekordu, to aplikacja stwierdzi, że nazwa użytkownika wprowadzona przez napastnika jest nieprawidłowa, i nie będzie mogła zablokować konta. Kiedy napastnikowi uda się odgadnąć prawidłowe hasło, uwierzytelnianie przebiegnie 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ł wprowadzić 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 rekordó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 uwierzytelnić użytkownika, jeśli dla dowolnego rekordu para nazwa użytkownika - hasło pasował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 instrukcji 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 wygenerowane kwerendy.