Wordpress

W jednej ze starszych wersji Wordpressa odnaleziono także błąd w implementacji identyfikatora sesji wynikający tym razem z braku efektywej ochrony integralności przekazywanych tam danych - czyli nazwy użytkownika i czasu ważności sesji. Tym razem ochronę przed fałszerstwem identyfikatora autorzy próbowali zapewnić przez dołączenie do identyfikatora skrótu MD5 z tych danych. Błąd polegał na tym, że na wejściu do MD5 podawano po prostu jako dwa sklejone ciągi znaków. Oznaczało to jednak, że identyczny skrót da nazwa użytkownika "admin" z datą "21 Apr 2011" ("admin21Apr2011") i nazwa "admin2" z datą "1 Apr 2011", co umożliwiało podrobienie tokena.

Typo3

W innym popularnym systemie CMS, tym razem Typo3, (atak opisał greg w prezentacji "Non-obvious bugs by example") autoryzacja dostępu do stron była realizowana przez sprawdzenie kodu przesyłanego w zmiennej juHash. Kod ten jest generowany za pomocą funkcji MD5, na której wejściu podawany jest m.in. adres strony oraz - znowu - tajny klucz aplikacji, przechowywany w konfiguracji Typo3. Skrót ten był następnie skracany do pięciu bajtów (40 bitów). Kluczowy jest jednak operator użyty do sprawdzenia wartości przysłanej przez użytkownika z wartością oczekiwaną przez aplikację - był to standardowy operator równości (==), który ignoruje typy porównywanych zmiennych (w przeciwieństwie do operatora ===). Z punktu widzenia PHP identyczne będą więc wartości np. 10 i 1e1 oraz 100 i 1e2, bo PHP "usłużnie" wykona dla nas konwersję notacji i typów.

Zobacz również:

• Indywidualna kryptografia na dobre uniemożliwi współdzielenie kont na Netflixie?

Autor ataku policzył, że wystarczy maksymalnie ok. 5500 prób by trafić w odpowiedni skrót, który dzięki tej właściwości operatora równości zostanie potraktowany przez PHP jako "poprawny" dla danego pliku. Co więcej, w ten sposób można było również pobrać plik localconf.php zawierający klucz aplikacji i swobodnie obchodzić wszystkie pozostałe zabezpieczenia.

Joomla

Przykładem dość naiwnego, choć rozpowszechnionego, podejścia do implementacji funkcji kryptograficznych jest błąd obecny w starszych wersjach systemu Joomla, w module generującym "losowe" hasła. Autor tego modułu mając najwyraźniej świadomość jego ważności próbował zmaksymalizować złożoność produkowanego hasła za pomocą technik pozornie poprawnych - tyle, że całkiem błędnych. Były to kolejno:

* inicjalizowanie generatora liczb losowych przy każdym wywołaniu funkcji

* wykorzystanie do inicjalizacji bieżącego czasu

* przepuszczenie go przez dodatkową funkcję CRC32, która w rzeczywistości ograniczała rozrzut wartości inicjalizującej.

W rezultacie generowane hasła, choć w małej próbce wyglądały na "losowe", były łatwo przewidywalne. Prawdziwy problem polegał jednak na tym, że funkcja ta była używana np. do resetowania haseł do kont - zatem wysyłając do serwisu żądanie resetu hasła administratora i rejestrując bieżący czas można było przewidzieć zbiór haseł, wśród których znajdowało się także to wlaśnie wygenerowane dla konta administratora.

Czy to naprawdę 3DES?

Inny ciekawy przypadek opisują H. Leininger i K. Monroe w prezentacji "Home-grown crypto". Jako pentesterzy otrzymali od producenta oprogramowania aplikację wysyłającą raporty do serwera. W specyfikacji producent deklarował, że dane są szyfrowane za pomocą silnego algorytmu 3DES. W przypadku pobieżnych audytów taka informacja wystarczyłaby do zaakceptowania takiego poziomu bezpieczeństwa. Ale dokładna analiza danych przesyłanych do serwera ujawniła poważny błąd w samej koncepcji szyfrowania.

Otóż co prawda same dane były szyfrowane algorytmem 3DES, ale za to klucz szyfrujący był dołączony w nagłówku przesyłanej wiadomości i - co gorsza - był jedynie zakodowany za pomocą trywialnej tablicy podstawieniowej. Oznaczało to, że potencjalny podsłuchiwacz dysponował zarówno zaszyfrowaną wiadomością jak i kluczem do jej rozszyfrowania. A siła wymyślonego przez projektanta aplikacji zabezpieczenia - pomimo stosowania silnego szyfru 3DES - była bliska zeru.

Czasochłonne zaciemnianie

W innej analizowanej przez ten zespół aplikacji, tym razem do hazardu on-line, występował inny typowy dla domorosłych kryptologów problem - procedury "zaciemniające", które w języku polskim nie dorobiły się żadnej lepsze nazwy poza "obfuskacją" (obfuscation). W zamierzeniu autorów miały one służyć ukryciu szczegółów algorytmu skracania haseł przed potencjalnymi włamywaczami i podnieść bezpieczeństwo dość słabego skądinąd algorytmu, od którego zależał m.in. mechanizm uwierzytelnienia użytkowników.

Deasemblując niezwykle skomplikowane - w zamyśle autorów - procedury w ciągu zaledwie kilku godzin zespół testujący podsumował to uwagą, że zapewne autorzy musieli poświęcić znacznie więcej czasu na ich napisanie.

Patrz także artykuły Bezpieczne hasła w XXI wieku i Jak bezpiecznie pisać aplikacje webowe?.