Możliwość przeszukiwania dostępnego online kodu źródłowego aplikacji na krótką metę jest poważnym zagrożeniem. W dłuższym okresie musi doprowadzić do poprawy praktyki w dziedzinie bezpieczeństwa aplikacji.

Choć Google nie przestaje zaskakiwać, co rusz publikując nowe aplikacje działające online, przedstawiciele firmy przekonują, że trzy czwarte pracowników zajmuje się głównie technologiami i rozwiązaniami związanymi z indeksowaniem i przeszukiwaniem zbiorów danych. Oprócz znanej wszystkim wyszukiwarki internetowej Google oferuje także wiele wyszukiwarek specjalistycznych, jak Google Scholar dla publikacji naukowych, Froogle do przeszukiwania sklepów online, czy Google Ride Finder pomagająca zlokalizować taksówkę.

Najnowszą propozycją w tej dziedzinie jest Google Code Search (http://www.google.com/codesearch ) - narzędzie wyszukujące wyrażenia w kodzie źródłowym programów dostępnym w ramach rozlicznych online projektów open source. To ważna nowość - dla wprawnego programisty użyteczności Google Code Search nie sposób przecenić. Najprościej mówiąc, pozwala znaleźć rozwiązanie problemu, które ktoś już kiedyś stworzył i udostępnił. Niestety, jest i druga strona medalu.

Google Code Search okazał się świetnym narzędziem dla... hakerów poszukujących słabości w aplikacjach.

Włamanie według wyników

Oprócz opcji najczęściej wykorzystywanych w zwykłej wyszukiwarce, Google Code Search oferuje typowe dla programistów możliwości wyszukiwania wg nazwy pliku, licencji, języka programowania itd. Można nawet użyć wyrażeń regularnych, wykorzystywanych powszechnie m.in. w skryptach systemowych i aplikacyjnych (awk, perl) systemów Unix i Linux.

W tym właśnie tkwi problem. Wykorzystywanie wyszukiwarki do włamań jest na porządku dziennym, pisaliśmy o tym na łamach Computerworld (choćby w numerze 34/2005 w artykule "Wyszperać konsolę"). W ciągu ostatnich lat zmieniła się charakterystyka włamań. O ile jeszcze kilka lat temu typowe działanie polegało na szukaniu dziury w oprogramowaniu konkretnego serwera, o tyle teraz ciężar przesunął się w kierunku wyszukiwania serwerów, do których z góry wiadomo jak się włamać.

Innymi słowy: włamywacze najpierw dowiadują się o już zgłoszonych błędach programistycznych, potem szukają gotowego eksploita, bywa że automatycznego, względnie piszą go sami (rzadkość). Później wystarczy odszukać serwery podatne na ataki i zainstalować w nich konie trojańskie. Większość takich ataków z dużym prawdopodobieństwem powiedzie się, gdyż bardzo wielu serwerów nie da się zaktualizować "natychmiast". Inna sprawa, że częstokroć administratorzy pro prostu zapominają o aktualizacjach.

Jest cel, jest armata... ognia!

Jak przebiega typowy atak z użyciem Google Code Search? Większość programistów umieszcza w kodzie komentarze. Ułatwia to późniejszą analizę kodu i usuwanie błędów, dodawanie nowych funkcjonalności - czyli rozwój programu. Często w tych komentarzach są bardzo cenne uwagi odnośnie do fragmentów kodu, np. opisy kłopotów w trakcie tworzenia programu.

Typowym problemem jest przepełnienie bufora - błąd obecny od dawna w historii niemal wszystkich większych aplikacji. Pomimo specjalnych technik ochrony, nadal jest to jeden z ważniejszych powodów zagrożeń powszechnie wykorzystywanych do włamań. Programiści doskonale o tym wiedzą i w komentarzach dodają stosowne informacje. Gdyby zatem poszukać takich wpisów w kodzie aplikacji i pod jej kątem przygotować narzędzie do włamań... no właśnie.

Dotychczas było to uciążliwe - trzeba było pobrać kod źródłowy i lokalnie przeszukać wiele plików. Teraz Google Code Search usłużnie podaje hakerom pomocną dłoń. Dla przykładu wpisanie wyrażenia "bufor powinien być wystarczająco duży" ("buffer should be big enough") wyświetla sporo trafień (ponad 100 tys.). Niektóre z nich na pewno da się wykorzystać do włamań. Jeśli bufor jest duży, co będzie, gdy się wprowadzi jeszcze większą ilość danych? Teraz trzeba "tylko" znaleźć odpowiednią maszynę, korzystającą z danej wersji oprogramowania. Tutaj "zwykły" serwis Google może podać sygnaturkę serwera albo inne podobne informacje. Mamy cel, mamy armatę i... ognia!

Wnioskowanie z komentarzy

Wielu programistów w swoich programach daje dość ważne komentarze, informując innych o tym, że fragment kodu będzie w przyszłości wymagać poprawek. Skoro programista nie jest pewien prawidłowego działania tej części kodu, to istnieje spore prawdopodobieństwo, że jest tam jakiś błąd. Wyszukanie stosownych fragmentów kodu to kwestia chwili. Najbardziej typowe zapytanie to "this should be fixed", "fix this", "to be fixed" lub wręcz FIXME ("napraw mnie"). Skoro ta część kodu wymaga poprawki, to znaczy, że prawdopodobnie da się skorzystać z niej do jakiegoś naruszenia poprawnego funkcjonowania programu.

Ciekawe dla potencjalnego włamywacza są także komentarze zawierające opisy już wykrytych problemów. Najpoważniejszymi z nich są informacje o załamaniach programu. Przyczyn może być wiele. Bywa, że w kodzie są jeszcze dodatkowo nieprzewidziane przez programistów błędy. Jeśli w komentarzu jest fraza "this will crash", to znaczy, że usuwanie błędów w przypadku tego programu było dość kłopotliwe i prawdopodobnie nie zostało jeszcze zakończone. Włamywacz może zatem dość łatwo "przyspieszyć" ten proces, znajdując dziurę (lub więcej) i publikując stosownego eksploita.

Niektórzy programiści podchodzą bardzo krytycznie do własnego kodu. Nie zawsze jest to uzasadnione, ale komentarze mówią same za siebie. Bardzo dobrym słowem kluczowym do takich poszukiwań jest angielskie "kludge" (pejoratywne określenie nieeleganckich pomysłów tymczasowo rozwiązujących problem, słowem: prowizorka) - daje wiele ciekawych trafień. Inne słowo "bodge" nie jest aż tak negatywne, ale także wskazuje na fragmenty, które mogą być przyczyną kłopotów (np. "/* TODO: This is a bodge! */").

Problemy ze zgodnością z istniejącym oprogramowaniem były i są bardzo poważnym zmartwieniem dla Microsoftu. Bardzo wiele kłopotów było spowodowanych drobnymi zmianami w zachowaniu konkretnych bibliotek, względnie odstępstwem od standardów. Środowisko open source poszukujące sposobów na zachowanie kompatybilności z API Microsoftu również zmaga się z tymi odstępstwami i - sądząc po komentarzach - są one jednym z ważniejszych źródeł pasji. "BOOL is tri-state according to Bill Gates" (OpenSSL) albo "/* Ask Bill Gates what this is all about */" (ImageMagick).

Jest źle, będzie lepiej

Warto tutaj zaznaczyć, że powstanie Google Code Search powinno w dalszej perspektywie podwyższyć bezpieczeństwo aplikacji. Przy udziale odpowiednio skonstruowanych wyrażeń regularnych istnieje szansa masowego znalezienia i usunięcia typowych błędów.

Poprawienie takich błędów może być znacznie sprawniejsze niż się to na pierwszy rzut oka wydaje. Google Code Search na pewno ułatwi podwyższanie jakości kodu, ponieważ uprości to, co dla większości firm jest największym problemem - audyt kodu, i to wielu produktów naraz. W nieoczekiwany sposób podniesie to jakość aplikacji open source.

Na razie wypada jednak przyjrzeć się kodowi aplikacji, których używa firma, by pewnego poranka nie zostać zaskoczonym. Trzeba też koniecznie upewnić się, że firmowe witryny nie udostępniają publicznie poufnych informacji, które mogłyby przez przypadek zostać zaindeksowane i posłużyć do przyciągnięcia uwagi włamywaczy. To poważne zagrożenie. Jak się okazuje, wielu użytkowników sieci umieszcza na swoich serwerach pliki zawierające hasła.

Co prawda archiwa stron zawierające pliki z informacjami o hasłach dostępu do bazy danych są archiwizowane za pomocą takich narzędzi, jak tar i kompresowane za pomocą innego programu (np. gzip), ale dla wyszukiwarki nie jest to przeszkodą. Rezultaty nawet prostych wyszukiwań są zatrważające. Ciekawe wyniki daje także wpisanie słów "confidential", "proprietary" lub "trade secret".