Sun Microsystem pouczony przez Polaków

Sun Microsystems Inc. to jeden z największych producentów sprzętu komputerowego oraz oprogramowania na świecie (m.in. współtwórca pakietu biurowego OpenOffice). Jego siedziba znajduje się w Santa Clara w Kalifornii. Według ogłoszonych 20 lipca 2004 r. wyników finansowych, za ostatni rok przychody Suna wyniosły ponad 11 mld USD. Jednak nawet tak potężna korporacja nie ustrzegła się błędów w kodzie swojej oficjalnej strony internetowej.

Odkrywcy błędu - Sebastian Mróz (Eax) oraz Michał Piszczek (PicH), uzyskali dostęp do bazy danych korporacji. Pozwolił im na to zdobyty uprzednio kod skryptu PHP, który zawierał zarówno nazwę użytkownika bazy, jak i jego hasło.

Ekipa webmasterów Suna została natychmiast powiadomiona o możliwości wycieku informacji. Trzy godziny później kod strony został poprawiony, jednak do tej pory Sun Microsystems Inc. nie odpowiedział w żaden sposób na wiadomość od Polaków.

Szczegóły opisu dokonań oraz dokumentację graficzną można znaleźć pod adresem http://83.19.17.2/

Poniżej prezentujemy wywiad z odkrywcami błędu na stronie korporacji Sun Microsystems.

Dziennik Internautów: Jak natknęliście się na błąd? Przypadek, czy celowe szukanie dziury w całym?

Michał Piszczek: Był to w dużym stopniu przypadek. Zawsze przeglądając strony zwracamy uwagę na poprawność kodu i potencjalne błędy. To zboczenie zawodowe - na co dzień zajmujemy się pisaniem systemów CMS/CRM...

Zastanowił nas fakt czy dział research.sun.com został stworzony metodą statyczną czy dynamiczną, tj. przy użyciu technologii PHP/ASP. Okazało się, że strona jest generowana dynamicznie i można wyświetlić zawartość includowanego pliku.

Po załataniu dziury przez Suna zdecydowaliśmy się na jej upublicznienie, aby uświadomić społeczeństwu fakt, że nie tylko amatorskie strony mogą zawierać krytyczne błędy, a ze poprawność kodu to nie kwestia pieniędzy, ale kompetencji programistów.

DI: Do jakich scenariuszy ataku mógłby posłużyć wykryty błąd?

Sebastian Mróz: W naszym przypadku, błąd który znaleźliśmy w systemie umożliwił dostęp do kodu źródłowego strony zawierającego m.in. hasło do bazy danych MySQL. Posiadanie nazwy użytkownika i hasła do bazy zezwala, w przypadku dopuszczenia połączeń z zewnątrz, na przeglądanie i edycję znajdujących się na stronie danych.

Znajomość kodu źródłowego umożliwiła również łatwiejsze znalezienie dużo groźniejszych błędów mogących prowadzić do przejęcia kontroli nad serwerem.

Dodatkowo, stosowane hasła są bardzo często takie same dla innych usług, np. poczty czy też FTP i SSH. Wykorzystanie takiego błędu tak naprawdę zależy tylko i wyłącznie od kreatywności atakującego ;]

DI: Jak szacujecie liczbę podobnych luk na polskich serwerach, zarówno firmowych jak i prywatnych?

MP: Jakość kodu PHP stron WWW jest w większości tragiczna, Wedle naszych obserwacji 30% stron firmowych zawiera krytyczne błędy widoczne dla specjalisty na 1 rzut oka. Kolejne 50% zawiera błędy których trzeba trochę dłużej poszukać i pomyśleć jak oraz czy można je wykorzystać. Statystyki mają się podobnie na świecie.

Jeśli chodzi o strony prywatne/amatorskie jest jeszcze gorzej. Błędy w kodzie PHP to nie tylko potencjalna możliwość podmiany strony, czy też nieautoryzowanego dostępu do poufnych informacji. W ok. 50% przypadków po wykryciu błędów PHP, przy "nierozsądnej" konfiguracji serwera WWW, można uzyskać doń dostęp z uprawnieniami Apache'a, a od tego już tylko krok do przejęcia całkowitej kontroli nad systemem.

Na co dzień, przeglądając tylko strony WWW (nie szukając dziur) dostrzegamy kilkanaście tego typu błędów. Nie sposób nawet informować wszystkich webmasterów o nich.

DI: Co więc poradzilibyście tysiącom użytkowników, którzy mają problemy ze swoim kodem? Jak mogą się uchronić przed atakami mającymi swoje podłoże w demonie HTTP?

MP: Przede wszystkim, korzystanie z usług kompetentnych programistów, którzy oprócz wiedzy akademickiej posiadają wyczucie problemów z natury bezpieczeństwa sieciowego.

Kolejny problem to presja czasu i finansów w projektach, która tragicznie wpływa na jakość kodu. Istotna jest zatem walidacja kodu, przez ludzi nie biorących udziału w projekcie. Takim osobom jest znacznie łatwiej dostrzec potencjalne błędy i zagrożenia.

DI: Jak długo zajmujecie się ogólnie pojętym network security?

MP: Nigdy się nie zastanawialiśmy nad tym... ale ok. 5 lat. Na co dzień piszemy systemy CMS/CRM dla jednej z małopolskich firm, oraz studiujemy. Jesteśmy również redaktorami znanego portalu traktującego właśnie o network security - to dla nas przede wszystkim pasja.

DI: Bardzo dziękujemy za rozmowę.

Komentarze