Jak zwiększyć bezpieczeństwo swojej webaplikacji – kilka prostych metod

Wstęp

W tekście przedstawiam kilka prostych kroków, które pomogą zwiększyć bezpieczeństwo aplikacji webowej. Są to techniki podstawowe i nie obejmują lokalizacji / usuwania bardziej technicznych podatności jak SQL injection / XSS / OS Command Execution, Path Traversal,  Authorization Bypass, itd. Osoby zainteresowane tego typu problemami odsyłam choćby do: OWASP Top Ten, OWASP Testing Guide czy tutaj.  O tym zagadnieniu napisano już całe książki.

Poradnik ma charakter subiektywny i jedynie wprowadzający w wybrane elementy bezpieczeństwa aplikacji www. Z drugiej strony, wskazane metody ochrony mogą być wykorzystane bez większego technicznego przygotowania.

Problem 1. Wyświetlanie błędów aplikacyjnych

Często nie jesteśmy świadomi, ile informacji nasza aplikacja udostępnia potencjalnym atakującym. Mogą to być szczegółowe informacje o wersjach użytych bibliotek czy komponentów, fragmenty kodu źródłowego, ścieżki instalacji aplikacji, fragmenty zapytań SQL, hasła bazodanowe itd.

1. Google hacking

Jedną z technik, którą można zastosować, aby wyłuskać interesujące informacje o aplikacji z komunikatów o błędach, jest tzw. google hacking – czyli, najprościej rzecz ujmując, poszukiwanie w Google zaindeksowanych stron zawierających komunikaty z błędami. Przykład tego typu zapytań do google?

site:www.securitum.pl error
site:www.securitum.pl warning
site:www.securitum.pl exception
site:www.securitum.pl invalid
site:www.securitum.pl sql query
site:www.securitum.pl unknown

Zauważmy, że korzystając z wyszukiwarki, atakujący nie musi w ogóle uzyskiwać dostępu do naszej aplikacji – więc nawet nie wiemy o potencjalnie rozpoczynającym się ataku…

Oto przykład:

Co więcej, wystarczy, że nasza aplikacja działała tylko chwilę w trybie ze szczegółowym wyświetlaniem błędów i że akurat w tym przedziale czasowym strony z komunikatami błędów zaindeksował robot. Ciekawą bazą zawierającą odpowiednio spreparowane zapytania do Google jest tzw. GHDB (google hacking database):

za: http://www.hackersforcharity.org/ghdb/

2. Odwołania do nieistniejących zasobów

Kolejnym częstym problemem – tym razem ujawniającym wersję użytych w systemie komponentów – jest odwołanie się do nieistniejącej strony (np. http://test.securitum.pl/qweqwe). Tego typu problem występuje choćby na serwerach http apache czy serwerze aplikacyjnym Tomcat, a nie są to przypadki odosobnione.

Oto przykład:

3. Komunikacja HTTP

Popularnym miejscem, w którym można zlokalizować informacje o wykorzystanych komponentach, są nagłówki HTTP odpowiedzi. W jaki sposób sprawdzić, co aplikacja przesyła w nagłówkach odpowiedzi? Można użyć jednego z narzędzi typu http proxy (np. darmowy burp suite) lub jednego z pluginów do Firefoxa, np.: Live HTTP headers lub Firebug:

4. Siłowe wywoływanie błędów

Innym często wykorzystywanym sposobem na „sztuczne” wywołanie błędu jest zmiana typu użytego parametru, np.: user_detail.aspx?id=1234 na user_detail.aspx?id=asdqwe (mamy tu do czynienia z zamianą typu integer na string). Odmianą tego problemu, charakterystyczną dla języka PHP, jest próba rzutowania zmiennej na tablicę, np.: user_detail.php?id=1234 -> user_detail.php?id[]=1234.

5. Jak się ochronić?

• Wykonać dla swojej strony do Google’a  kilka zapytań wyszukujących komunikaty o błędach, np. (site: .securitum.pl error). Jeśli zauważymy coś podejrzanego – trzeba usunąć daną informacje z cache Google’a.

Zrekonfigurować odpowiednio system, jeśli przynajmniej jeden z elementów poniżej będzie udostępniał informacje ujawniające techniczne szczegóły naszego systemu:

• Spróbować odwołać się do nieistniejącej strony np.: /qwnebkjqwejh i zweryfikować, czy aplikacja lub web serwer „przedstawia się” swoją wersją.
• Przeanalizować nagłówki http odpowiedzi w poszukiwaniu informacji o wykorzystanych przez system wersjach komponentów.
• W przypadku odwołania się aplikacji poprzez identyfikator liczbowy, np. user_detail.aspx?id=1234, spróbować użyć parametru nie będącego liczbą, np.: user_detail.aspx?id=asdqwe.
• W przypadku php dla dowolnego parametru użyć rzutowania na tablicę, np. user_detail.php?id=1234 zamienić na user_detail.php?id[]=1234.
• Jeśli aplikacja korzysta z Cookies – wysłać do aplikacji Cookies z nieprawidłową zawartością (np. ze znakami ’ ; ” \).

Problem 2. Nieaktualne komponenty

1. „Gotowce”

Do budowy aplikacji webowych czy portali stosuje się często gotowe komponenty albo biblioteki (jako przykład posłużyć mogą popularne systemy zarządzania treścią (CMS) jak Joomla!, Liferay czy silnik WordPress).

W momencie uruchomienia dana wersja systemu może nie posiadać znanych publicznie błędów, ale co będzie np. za rok? Istnieją serwisy – np. secunia.com – umożliwiające metodyczne sprawdzenie, jakiej klasy błędy występują w danej wersji wykorzystanego komponentu. Dla przykładu błędy w WordPress 3.x

Inne tego typu bazy warte wspomnienia to CVE czy słynny bugtraq.

Już podejmując opisane powyżej działania, atakujący może wejść w posiadanie sporej grupy informacji o naszym systemie. Istnieją jednak jeszcze inne metody wykrycia wersji komponentów, z których korzystamy.

2. Analiza źródła

Najprostsze z nich to analiza źródła wybranej strony HTML aplikacji czy plików charakterystycznych dla danego komponentu. Są tu dostępne gotowe narzędzia, które realizują tego typu testy: nikto, whatweb czy blindelephant:

Powyżej – przykład działania whatweb za http://www.morningstarsecurity.com/research/whatweb.

3. Zdradliwe pliki

Inna metoda to odczytanie standardowych plików typu README, Changelog, plików z dokumentacją itp.

Na przykład domyślna instalacja WordPressa zawiera plik readme.html, który informuje o wykorzystanej wersji tego oprogramowania. Wystarczy więc wejść na http://adresportalu-gdzie-znajduje-sie-wordpress/readme.html i… mamy wersję wordpressa:

Dla tego typu testów też istnieją gotowe narzędzia – choćby popularny skaner portów nmap z odpowiednimi pluginami NSE  czy wspomniany wcześniej burp suite pro.

$ nmap 192.168.0.101 -p 80 -sV --script=http-enum

Starting Nmap 6.01 ( http://nmap.org ) at 2012-07-20 14:08 CEST
Nmap scan report for 192.168.0.101
Host is up (0.00030s latency).
PORT STATE SERVICE VERSION
80/tcp open Apache httpd 2.2.16 ((Debian))
| http-enum:
|  /wordpress/: Blog
|  /wp-login.php: Possible admin folder
|  /robots.txt: Robots file
|  /wp-login.php: WordPress login page.
|  /readme.html: WordPress version 3.4.1
|  /icons/: Potentially interesting folder w/ directory listing
|_ /index/: Potentially interesting folder

4. Katalogi

Jeszcze inny sposób na lokalizację użytego komponentu to charakterystyczna budowa URL-ów, czy katalogi charakterystyczne dla danej wersji użytego komponentu. W tym przypadku mogą być pomocne testy ręczne połączone z zapytaniem do Google 'a czy innej popularnej wyszukiwarki.

5. Jak się ochronić?

• Sprawdź np. na serwerze secunia (lub podobnym), czy użyte przez Ciebie wersje komponentów nie posiadają istotnych błędów.
• Nie wyświetlaj w źródłach HTML informacji o wykorzystanym przez Ciebie rozwiązaniu.
• Usuń niepotrzebne pliki: README, Changelog, pliki z dokumentacją, przykładowymi aplikacjami itd.
• Użyj narzędzi typu: nmap, nikto, whatweb czy blindelephant w celu wykrycia dodatkowych problemów.

Problem 3. Panel administracyjny

1. Lokalizacja

Najczęstsza lokalizacja panelu administracyjnego to po prostu katalog: /admin. Jeśli dodatkowo administratorzy stosują proste hasła (nie tak rzadko spotyka się kombinację: admin/admin) albo w mechanizmie logowania występuje np. podatność SQL injection to przejęcie dostępu do portalu może być jedynie kwestią czasu.

Jeśli panel administracyjny nie jest umieszczony w katalogu 'admin’, to może jest to np. admin.php albo coś równie oczywistego? Często, atakujący stosują w tym przypadku próby bazujące na swoim doświadczeniu lub używają metody siłowej z wykorzystaniem popularnych słowników zawierających potencjalne lokalizacje panelu administracyjnego.

Inne metody poszukiwania obejmują weryfikację pliku sitemap.xml czy robots.txt – nie chcemy przecież, żeby Google szperał nam po części administracyjnej systemu – dlatego katalog z administracją widnieje właśnie tutaj:

Inna metoda, to próba odszukania panelu administracyjnego w Google (np. operator site: oraz słowa typu administracja, admin, management itd). Na przykład:

site: securitum.pl management

Można również spróbować wejść na stronę aplikacji, korzystając z przedrostka https, np.: https://portal.test/ – jest szansa, że zaprezentowany zostanie certyfikat SSL, a w nim (w common name) adres aplikacji służącej do zarządzania systemem. Oczywiście część administracyjna portalu powinna być dostępna jedynie poprzez protokół https (zapewniający m.in. poufność przesyłanych: loginu i hasła dostępowego).

Niekiedy serwer aplikacyjny, z którego korzystamy, ma również własną konsolę zarządczą dostępną pod innym adresem niż 'standardowa’ administracja systemem (często wymaga to bezpośredniego dostępu do application serwera, np. na porcie 8080 TCP). Prostymi przykładami mogą tu być: Tomcat czy JBoss. W przypadku tego pierwszego ścieżka administracyjna to /manager/html, z kolei dla JBossa to /jmx-console (który zresztą posiadał nie tak dawno temu istotną i prostą do wykorzystania podatność) oraz /web-console.

2. Hasła dostępowe

Osobą sprawą jest stosowanie odpowiednio złożonych haseł administracyjnych (np. hasło Malgorzata1, mimo że długie i pozornie skomplikowane – nie jest dobrym pomysłem), zwracam też uwagę na domyślne konta administracyjne/serwisowe do systemu (np. admin/admin, guest/guest, test/test, konto test@liferay.com z hasłem test dla  domyślnej instalacji popularnego portalu Liferay albo domyślne hasła dla serwerów aplikacyjnych Tomcat, Jboss, Websphere AS – przykłady można mnożyć).

3. Jak się obronić?

• Umieścić panel administracyjny w nietypowym katalogu (trudnym do odgadnięcia).
• Wymuszać połączenie szyfrowane dla dostępu administracyjnego (https).
• Wyłączyć (lub zmienić nazwę) kontom o loginie: admin, administrator itp.
• Stosować odpowiednio złożone hasła (minimum to: hasła spoza słownika o odpowiedniej długości / złożoności, najlepiej > 10 znaków, zawierające małe / duże litery / znaki specjalne / cyfry).
• Zweryfikować, czy w administracji nie ma domyślnych kont administracyjnych / serwisowych.
• Zlokalizować panele administracyjne dla ew. serwerów aplikacyjnych wykorzystanych w rozwiązaniu i zmienić domyślne hasła dostępowe – optymalnie – nie udostępniać konsoli zarządczych publicznie.
• Idealnie: umożliwić połączenie administracyjne tylko z wybranych adresów IP.
• Idealnie: zastosować dodatkowo certyfikaty klienckie SSL do połączeń administracyjnych.

Problem 4. Inne testowe aplikacje na tym samym web serwerze

1. Wejście „od kuchni”

Niekiedy system jest zabezpieczony niemal idealnie… z małym wyjątkiem.

Administrator na tym samym fizycznie serwerze i tym samym adresem IP umieścił (np. „po znajomości”) aplikację, której zabezpieczenia są… żadne. W tym przypadku atak może wyglądać tak: złamanie tej drugiej aplikacji, uzyskanie dostępu na poziomie systemu operacyjnego i zaatakowanie w ten sposób aplikacji „głównej”.

W jaki sposób uzyskać informacje o innych aplikacjach hostowanych na tym samym adresie IP? Może do tego służyć np. mechanizm: reverse Reverse IP Domain Check, dostępny online tutaj.
Po prostu w wyszukiwarkę wpisujemy nazwę interesującej nas domeny, którą chcemy sprawdzić, i otrzymujemy listę innych serwisów znajdujących się pod tym samym adresem IP.

Innym, wartym zaznaczenia sposobem, jest odpytanie serwera DNS: odpytujemy o adres IP portalu, a następnie robimy zapytanie odwrotne (reverse lookup) –  tj. podajemy adres IP, oczekując w odpowiedzi nazwy. Nazwa ta nie zawsze jest tą, od której zaczęliśmy…

2. Jak się obronić?

• Na początek można skorzystać z narzędzia: http://www.yougetsignal.com/tools/web-sites-on-web-server/.

• Mając dostęp do konfiguracji web serwera, warto zweryfikować, czy na tej samej fizycznej maszynie nie hostujemy innych serwisów / aplikacji (np. testowych, zupełnie niezwiązanych z naszą działalnością), które mogą stanowić łatwy obiekt ataku.

Problem 5. Directory listing

1. Charakterystyczne katalogi

Dość popularnym, a zarazem łatwym do zdiagnozowania problemem, jest tzw. funkcjonalność directory listing na serwerach http, polegająca na wyświetlaniu do użytkownika zawartości katalogu, jeśli katalog ten nie zawiera pliku index. Np. wejście na http://test.securitum.pl/cv/ mogłoby wyświetlić listę plików CV uploadowanych wcześniej przez osoby aplikujące o pracę. Wystarczy wtedy, że atakujący w tym momencie zlokalizuje odpowiedni katalog (kłaniają się tutaj metody brute-force lub zdrowy rozsądek). Jeśli atakujący posiada konto w systemie (np. aby aplikować o pracę, należy wcześniej założyć konto), to sprawa jeszcze bardziej się upraszcza – śledząc komunikację http, można próbować zlokalizować interesujące nazwy katalogów, w których aplikacja przechowuje dane.

Oto przykład:

2. Jak się obronić?

• Wyłączyć mechanizm Directory Listing na web serwerze.
• Jeśli składujemy pliki bezpośrednio w webroocie (katalog dostępny dla klienta przez przeglądarkę internetową), do których nie powinno być anonimowego dostępu, trzeba przenieść pliki poza webroot, a dostęp do nich zapewnić mechanizmem pośrednim.

Problem 6. Wyszukiwarka

1. Wildcard

Niewinnie wyglądającym elementem może być wyszukiwarka treści w portalu. Prostym trickiem umożliwiającym często wyświetlenie wszystkich zindeksowanych przez wyszukiwarkę zasobów jest użycie tzw. wildcardu, np.: jednego ze znaków: * %.

W ten sposób można namierzyć takie strony jak: testowy contest, dostęp do treści dostępnej tylko dla zalogowanych użytkowników, strony z błędami itd.

Można tutaj zastosować również techniki podobne do google hackingu (wyszukanie słów: test, admin, error, warning itd).

2. Cross site scripting (XSS)

Dość często wyszukiwarka podatna jest na tzw. cross site scripting (XSS), choć tego problemu akurat nie będę szczegółowo opisywał. Jako podstawowy, prosty test można spróbować wyszukać ciągów:

•  <script>alert(1)</script>
• „><script>alert(1)</script>
• ’><script>alert(1)</script>

Jeśli na stronie z wynikami wyszukiwania wyświetlony zostanie popup w javascript – mamy potwierdzenie XSS-a. :-)
Tematyka błędów cross site scripting jest bardzo szeroka i dotycząca potencjalnie niemal wszystkich funkcjonalności portalu. Poszukiwanie jej w wyszukiwarce to dobry początek.

3. Jak się obronić?

• Wykonać kilka sprawdzeń wskazanych wcześniej i zweryfikować informacje prezentowane w wyniku wyszukiwania.

Problem 7. Upload

1. Nieautoryzowany dostęp na systemie operacyjnym

Co jest niebezpiecznego w mechanizmie uploadu? A gdyby była możliwość uploadowania na serwer pliku wykonywalnego (.php, .aspx, itd.)? Często programiści nie pamiętają, aby tego typu mechanizmy odpowiednio zabezpieczyć.

Dobrym przykładem jest choćby luka w systemie dotnetnuke umożliwiająca anonimowy upload plików .aspx, a tym samym wykonanie poleceń w systemie operacyjnym. Jeśli serwer www działa z uprawnieniami administracyjnymi (częsty przykład to kombinacja: Apache + Windows), to atakujący otrzymuje w ten sposób dostęp administracyjny na systemie operacyjnym.

Aby się ochronić, należy zastosować tutaj tzw. whitelisting – tj. dokładnie wskazać, jakie rozszerzenia plików mogą być uploadowane (np. tylko .jpg .png .gif czy .doc).

2. Edytory wizualne

Swoją drogą, błąd ten dość często występuje w co najmniej dwóch innych odmianach. Jeśli do formatowania treści używamy edytora wizualnego (np. fckeditor, tinymce) to być może część elementów (np. upload manager) jest dostępna anonimowo. Wystarczy jedynie zlokalizować katalog, w którym dany edytor jest dostępny publicznie, a następnie spróbować, czy nie istnieje możliwość uploadu dowolnych plików na serwer.

Inna odmiana tego zagrożenia to aplikacje instalowane z biblioteką czy środowiskiem, na którym działa nasza aplikacja. Co jeśli zawierają one niezabezpieczony przykład funkcjonalności uploadu…?

Poniżej – krok po kroku scenariusz, zgodnie z którym może nastąpić atak:

3. Jak się obronić?

• Jeśli posiadamy mechanizm uploadu, trzeba zweryfikować, czy istnieje możliwość umieszczenia na serwerze plików o innych rozszerzeniach niż zamierzane (np. jpg, .pdf, itp).
• Umożliwiać upload plików tylko o popularnych, niewykonywalnych przez web serwer rozszerzeniach.

–michal.sajdak[at]securitum.pl