Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Zabezpieczenie mlekiem i miodem płynące

Jednym z elementów bezpieczeństwa sieci komputerowych są garnuszki z miodem (ang. honeypots). Służą one do wykrywania nieautoryzowanego dostępu do elementów sieci. Honeypot występuje w postaci komputera (bądź też aplikacji), którego celem jest skupienie na sobie całej uwagi napastnika, któremu uda się przełamać zabezpieczenia sieci. W przypadku wykrycia aktywności na przygotowanej maszynie administrator informowany jest o niebezpieczeństwie.

Schemat działania honeypotów. (źródło: sysdivision.com).

Schemat działania honeypotów. (źródło: sysdivision.com).

Webowy garnuszek

W przypadku aplikacji internetowych sposób użycia miodowych garnuszków wygląda inaczej, jednak idea pozostaje zbliżona. Zamiast dodatkowego komputera mamy tutaj plik (lub zestaw plików), który stara się wychwycić wszelkie odchylenia od normalnego korzystania z systemu (podobnie jak ma to miejsce w systemach wykrywania włamań). W przypadku wykrycia potencjalnej próby włamania napastnikowi przesyłane są fałszywe dane, dzięki czemu nie koncentruje się on na dalszych poszukiwaniach błędów tylko na analizie otrzymanych wyników. W tym czasie administrator może zapoznać się z przesłanymi przez atakującego zapytaniami i na ich podstawie wywnioskować czy mogły one, lub ich mutacje naruszyć zabezpieczenia systemu. W przypadku stwierdzenia podatności administrator zyskuje czas na stworzenie poprawek, tak aby po zakończonej analizie przez napastnika nie mógł on faktycznie przełamać zabezpieczeń.

Przesłanie fałszywych danych w przeciwieństwie do np. zablokowania dostępu do aplikacji nie daje agresorowi natychmiastowej wiedzy na temat zabezpieczeń systemu oraz jego potencjalnych błędów.

Czego szukać?

Przed rozpoczęciem pisania honeypota należy się zastanowić nad specyfiką jego działania. Najważniejszym elementem jest sposób jego uruchomienia. Może to być opisany wyżej sposób a’la system wykrywania włamań lub jedna z metod zaprezentowanych w artykule Web Application Honeypots. W przypadku pierwszej opcji należy ustalić jakie typy ataków mają być wykrywane.

Napisanie „sztywnego” kodu, który będzie chronił aplikacji przed wszystkimi możliwymi atakami nie jest dobrym pomysłem. Po pierwsze nie jest to wydajne ze względu na konieczność przefiltrowania przychodzących danych pod kątem wielu ataków, po drugie wyszukiwać należy niebezpieczeństw, które mogą zaistnieć w aplikacji. Przykładowo aplikacja przechowująca dane w bazie XML nie będzie narażona na ataki typu SQL Injection lecz na XPath Injection, tak więc nie ma sensu implementowanie ochrony przed tym atakiem. Najlepszą praktyką byłoby stworzenie modularnego zabezpieczenia. Dzięki temu jedyną modyfikacją podczas kolejnych wdrożeń byłoby dołączenie odpowiednich modułów.

Kolejnym elementem wartym przemyślenia jest sposób informowania administratora o zaistnieniu niebezpieczeństwa. Można zastosować tutaj dwa rozwiązania: informować o każdym potencjalnym niebezpieczeństwie, bądź też ustalić priorytety ataków. W przypadku drugiego rozwiązania administrator powinien być informowany tylko o poważnych zagrożeniach, resztę należałoby zgromadzić w formie raportu.

Przykład prostego honeypota: Calypso

Po obmyśleniu wstępnego planu działania honeypota postanowiłem wdrożyć pomysł w życie i sprawdzić czy podoła on stawianemu zadaniu. Po kilkunastu minutach powstał prosty kod PHP, którego celem była próba wyłapania najpopularniejszych ataków SQL Injection – powstało „aż” pięć sygnatur. W chwili zidentyfikowania zapytania jako niebezpieczne zmieniana była baza danych przez co wszelkie zapytania były wykonywane na podstawionych danych (w przypadku „normalnych” aplikacji tworzenie kopii bazy danych nie jest dobrym pomysłem ze względów wydajnościowych).

Ze względu na małą liczbę sygnatur kod był bardzo łatwy do obejścia jednak nie wpływało to na samo złamanie idei działania zabezpieczenia. Mimo dużej swobody w ataku zasadę działania Calypso udało sie poznać tylko jednej osobie. Był nią Łukasz Pilorz. Dokonał on szeregu ataków SQL Injection (log z wykorzystanymi zapytaniami), z których jedno zapytanie umożliwiło mu poznanie przyczyny pobierania „błędnych” danych z bazy. Było nim:

SELECT USER(), DATABASE()

Na podstawie rezultatu tego zapytania miał on jasność, że baza z której pochodzą dane nie jest tą samą bazą, która została ustalona w pliku.

Stosowanie honeypotów w aplikacjach internetowych jest kolejnym sposobem na zwiększenie ich bezpieczeństwa, jednak podczas ich wdrażania należy zastanowić się czy ma to sens. Ze względu na swoją specyfikę ten rodzaj zabezpieczenia nie jest skierowany dla stron, które nie zawierają wrażliwych danych. Wiąże się to z czasem jaki pochłania jego stworzenie oraz działanie. Czas ten powinien być adekwatny do wagi danych, które mają być chronione.

Kod Calypso:


Tagi:
Kategoria: Bezpieczeństwo, Bezpieczeństwo aplikacji internetowych


3 komentarze

  1. Wykrywanie i blokowanie dodawarek automatycznych do qlwebow dzialajace na podobnej zasadzie spisuje sie znakomicie :) 2 tygodniowy katalog ma liste kilkudziesieciu zablokowanych IP. Przeklada sie to na kilkaset zapytan dziennie blokowanych juz przez Apache, i nie obciazajacych bazy.

  2. Dobra adaptacja IDS sieciowego do zastosowan webowych. Niezla robota Lukasz Pilorza w obejściu mechanizmu. I wlasnie tu rodzi się pytania. Cale calypso opiera się na zdefiniowaniu 5 praktycznie statycznych reguł. Ciągle pojawiają się nowe sposoby ataków wykorzystujące np. różne kodowania znaków. Nie sposób się przed wszystkimi chronić poprzez zdefiniowanie takich typów. Rozważałeś zastosowanie technik heurystycznych?

  3. Hi, nie rozważałem, głównie dlatego, że Calypso powstało jako prosty przykład do tej notki, nie miało ono innego przeznaczenia :) A co do 5 reguł, myślę że jakby je troszkę rozszerzyć uwzględniając log Łukasza możnaby osiągnąć całkiem niezłą wykrywalność :)

Dodaj komentarz