Translate: 
EnglishFrenchGermanItalianPolishPortugueseRussianSpanish

Shared hosting: wykradanie ciasteczek HTTP


  click here to see different articles in english

Serwery typu shared web hosting posiadają jedną wielką zaletę, w przeciwieństwie do serwerów dedykowanych założenie konta jest na nich bardzo tanie. Pozwala to na szybkie i bezproblemowe założenie niewielkiej strony internetowej, małego sklepu, czy też własnego portfolio bez większych nakładów finansowych.

Wiadomo jednak, że serwery te posiadają też i swoje mroczne strony, związane szczególnie z bezpieczeństwem.

W tym artykule skupię się na jednym z mniej znanych luk bezpieczeństwa – na wykradaniu ciasteczek HTTP pomiędzy różnymi kontami na tym samym serwerze.

Teoria

Większość serwerów hostingowych udostępnia konta z darmową „domeną” przypisaną do konta. W tym przypadku nazwa „domena” jest jednak podana niejako na wyrost, w rzeczywistości jest to tylko subdomena w domenie głównej hostingu.

Jeśli strona główna hostingu mieści się pod adresem http://servername.com, to domena użytkownika nosi wtedy nazwę: http://userdomain.servername.com.

Nazwa taka jest często bardziej przyjazna dla użytkownika, niż stosowanie podkatalogów w ramach domeny głównej serwera (w latach 90-tych popularne były adresy typu: http://servername.com/~username/), w teorii zabezpiecza też przed współdzieleniem ciasteczek WWW przez różne konta na serwerze.

Zabezpieczenie to jest jednak złudne, oryginalny dokument RFC dotyczący obsługi ciasteczek HTTP zakłada dosyć naiwne ograniczenia, dla jakiej domeny są one dostępne:

Only hosts within the specified domain can set a cookie 
for a domain and domains must have at least two (2) or 
three (3) periods in them to prevent domains of the form:
 ".com", ".edu", and "va.us". Any domain that fails within 
one of the seven special top level domains listed below 
only require two periods. Any other domain requires at 
least three. The seven special top level domains are: 
"COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT"

W praktyce oznacza to, że dla większości serwisów hostingowych z domenami krajowymi najwyższego poziomu (np.: servername.fr, servername.jp) możliwe jest modyfikowanie ciasteczek w ramach wszystkich subdomen poniżej drugiej kropki (np.: myhost.servername.jp, yourhost.servername.jp).

Jakie są zagrożenia?

Jak wiadomo ciasteczka HTTP są uniwersalnym środkiem przechowywania danych o użytkowniku witryny przez co od początku swojego istnienia mechanizm ten jest krytykowany za negatywny wpływ na prywatność w Internecie. Zapisywane są tam często informacje dotyczące czas ostatniej wizyty, loginu w serwisie, numer sesji WWW, a w najgorszym przypadku nawet zaszyfrowane hasło do konta.

Wykradanie ciasteczek HTTP daje więc hackerowi możliwość przeprowadzenia bardzo różnorodnych form ataku: od zwykłego Denial-of-Service, po przejmowanie kont użytkowników i wykonywanie operacji w ich imieniu.

Wachlarz dostępnych opcji zależny jest przy tym wyłącznie od wiedzy programistów zabezpieczających atakowany serwis. Ci niestety rzadko zdają sobie sprawę z tego, jak łatwo jest przejąć kontrolę nad danymi, jakie stworzył ich program.

Przykład ataku

Dla potrzeb naszych testów przyjmijmy, że atakowany serwis (sklep internetowy) znajduje się pod adresem http://shop.yhosting.com/, a napastnik przeprowadza atak z domeny http://hacker.yhosting.com/ (na tą domenę wchodzi też na chwilę niczego niepodejrzewający klient sklepu).

Załóżmy teraz, że na stronie sklepu loguje się zwykły użytkownik. W ramach odpowiedzi serwer wysyła jego przeglądarce ciasteczka z informacjami o numerze sesji HTTP, która będzie go później identyfikować w sklepie:

Date               Thu, 07 Apr 2011 10:51:54 GMT
Set-Cookie         SHOP_ID=0493e0cdfeb9025534d97444d7288e9b; expires=Thu, 07-Apr-2011 11:51:56 GMT
Vary               Accept-Encoding
Connection         close
Transfer-Encoding  chunked
Content-Type       text/html

Klient sklepu otrzymał więc ID sesji o wartości 0493e0cdfeb9025534d97444d7288e9b.

Czy hacker potrafi odczytać powyższe dane z poziomu domeny hacker.yhosting.com, aby móc je użyć? W większości przypadków nie jest to możliwe.

Ustawiane ciasteczko nie posiada informacji, do jakiej domeny należy, przeglądarka klienta ograniczy więc jego zasięg do domeny shop.yhosting.com, uniemożliwiając tym samym odczyt lub zmianę jego zawartości przez inne serwisy w domenie .yhosting.com.

Dla napastnika nie jest to jednak wielki problem. O ile nie ma wpływu na już utworzone ciasteczko, może je po prostu podmienić na własne.

W tym celu musi oszukać zabezpieczenia przeglądarki WWW, która nie pozwala mu zmodyfikować istniejącego ciasteczka. W tym celu pomocne okazują się… inne zabezpieczenia przeglądarki: ciasteczka o tych samych nazwach ale różnych domenach mogą ze sobą koegzystować.

O ile podczas nawigowania po stronie shop.yhosting.com w pierwszej kolejności odczytywana będzie wartość z ciasteczka sklepu (ustawionego dla domeny shop.yhosting.com), o tyle ciasteczko te jest zazwyczaj ciasteczkiem sesyjnym, które wygasa po zamknięciu okna przeglądarki. Po jej ponownym otwarciu, ciasteczkiem obowiązującym staje się to, które ustawił hacker dla domeny nadrzędnej (.yhosting.com).

Od tego momentu atakowany sklep nie ma już żadnej kontroli nad spreparowanym ciasteczkiem HTTP.

W celu utworzenia takiego ciasteczka wystarczy uruchomić niewielki kod JavaScript:

function setCookie(c_name,value,exdays,domain)
{
    var exdate=new Date();
    exdate.setDate(exdate.getDate() + exdays);
    var c_value = escape(value) + ((exdays == null) ? "" : "; expires=" 
       + exdate.toUTCString()) 
       + "; domain="+domain+"; path=/";
    document.cookie=c_name + "=" + c_value;
}
setCookie("SHOP_ID", "DEADBEEF", 14, ".yhosting.com");
alert("POISONING FINISHED");

Przedstawiony skrypt tworzony nowe ciasteczko z ID sesji ustawionym na przykładową wartość DEADBEEF (wygenerowaną przez napastnika i zapamiętaną przez niego do późniejszego wykorzystania).

Posłużyłem się w tym przypadku językiem JavaScript, aby uzmysłowić wagę zagrożenia: skrypt w tym języku może zostać w prosty sposób wstrzyknięty do kodu HTML niewinnych, słabo zabezpieczonych stron WWW znajdujących się na tym samym serwisie hostingowym.

Efekty ataku

W tym momencie mogą pojawić się dwa efekty działania skryptu, zależne od rodzaju zabezpieczeń w atakowanym sklepie:

  • Denial of Service
    użytkownik nie będzie mógł się zalogować do sklepu, nawet gdy wpisze prawidłowe dane na ekranie logowania (aż do czasu usunięcia złośliwego ciasteczka). Oprogramowanie sklepu rozpozna, że ID sesji jest nieprawidłowe, niestety nie będzie w stanie usunąć złego ciasteczka, gdyż przeglądarka zapamiętała, że zostało ono ustawione z poziomu innej domeny
  • Session fixation
    użytkownik będzie mógł się ponownie zalogować na atakowanej stronie. Jeśli mu się to uda, to znak, że oprogramowanie sklepu przyjęło ID o wartości DEADBEEF (czyli ustawionej przez hackera) jako nowe ID dla sesji zalogowanego użytkownika. Od tego momentu hacker przy użyciu tego ID może podszywać się jako zaatakowany klient sklepu (wystarczy że w swojej przeglądarce utworzy ciasteczko o tym samym ID).

O ile oba przedstawione efekty są niebezpieczne dla klienta oraz właściciela atakowanej witryny, o tyle najgroźniejszy jest atak typu Session fixation. Jest on wektorem do wielu dalszych, bardziej złowrogich działań: umożliwia wykonywanie operacji w imieniu zaatakowanej ofiary, czy nawet atakowanie samego serwisu od środka (jeśli ofiarą był użytkownik o prawach administratora na atakowanym serwisie).

Błędne jest też myślenie w stylu: „mi to nie grozi, kto byłby na tyle głupi, by atakować moją stronę ze swojego konta na tym samym serwerze WWW”. Napastnikiem nie musi być właściciel serwisu, z którego nastąpił atak. Strona ta może być zarażona wirusem, lub dotknięta inną formą ataku (np. XSS, SQL injection, itp.).

Jak się przed tym bronić?

Należy zawsze pamiętać, aby nigdy nie ufać danym otrzymanym od użytkownika (mantra każdego developera WWW).

Najprostszym rozwiązaniem w tym przypadku byłoby wykupienie własnej domeny lub znalezienie hostingu, gdzie domeny są wieloczłonowe. Należy jednak przede wszystkim sprawdzać poprawność ID sesji, jaką legitymuje się użytkownik, każdorazowo generować nowe ID podczas logowania do serwisu, a także sprawdzać czy nikt nie zmieniał treści ciasteczek (np. mechanizmem HMAC).

Tagi:

Dodaj odpowiedź