E-learning kursy i szkolenia Online |||S|G|||

Regularnie co pewien czas, gdy w Sieci zgromadzi się odpowiednia liczba podatności w popularnych systemach portalowych, e-sklepach czy mechanizmach zarządzania treścią, informujemy o takich najistotniejszych zagrożeniach. Systemy webowe, w większości rozpowszechniane na zasadach licencji z otwartym kodem, są łatwo edytowalne. Z tego powodu wielu programistów tworzy dla nich liczne dodatki i moduły. Najczęściej też to w nich właśnie wykrywane jest najwięcej podatności.

Co najbardziej zagraża CMS-om?

W znacznej większości wypadków, błędy wykrywane w kodzie portali są wariantami kilku typowych luk. Zagrożenia również są wciąż te same ? nieautoryzowany dostęp do zasobów zgromadzonych w wewnętrznej części serwisów. W zależności od wersji luk, można podzielić je na te, które wyłącznie umożliwiają odczytanie danych, czyli wydobycie ich z powiązanych z serwisem baz danych oraz na takie, które umożliwiają ich modyfikację.

Innym kryterium podziału, może być zasada działania exploitów. Część z nich stara się wykorzystać ataki Cross Site Scripting w celu przejęcia praw i danych sesji obecnie lub uprzednio zalogowanego użytkownika (bądź administratora), a następnie uzyskać dzięki temu możliwość poruszania się w systemie jako ten użytkownik. Inną grupę stanowią zaś luki, które stosują boczne wejścia (niedopatrzenia w kodzie modułów lub szczeliny w mechanizmach ochronnych portalu/sklepu), dzięki którym intruz może wyłowić dane ? np. odgadując położenie pożądanego pliku o zadanej nazwie i typowej dla danego rozwiązania lokalizacji w drzewie katalogów.

Osobną grupę zagrożeń stanowią wstrzyknięcia. Zasadniczo wyróżnia się tu dwie wersje ? atak na sam kod strony WWW, traktowanej jako zbiór skryptów HTML, JavaScript czy XSD (HTML script injection) oraz ataki wstrzyknięć poleceń SQL (SQL injection), które są wymierzone w bazę danych. W wypadku obu rodzajów wstrzyknięć w ich wyniku najczęściej może dojść do wydobycia danych ? czy to wprost z bazy poprzez zmianę zapytań SQL, czy też poprzez manipulację skryptami, które dadzą pośrednie odpowiedzi na zadawane przez napastnika pytania. Rzadziej dochodzi do ataków zmierzających do zmiany danych (np. dopisania użytkownika, zmiany hasła już istniejącego konta czy podmiany powiązanego z kontem adresu e-mail w celu późniejszego zmienienia haseł dostępu). Takie wypadki bazują na błędach SQL injection, które pozwalają na dokonanie szerszych zmian w poleceniach, poprzez połączenie typowych zapytań SQL do bazy typu SELECT z poleceniami INSERT lub UPDATE.

Ostatnia popularną metodą jest atak podłączenia pliku z kodem. Taki atak przeważnie łączy w sobie wcześniej wspomniane scenariusze, wykorzystując możliwość umieszczenia kodu skryptów wykonywanych po stronie serwera (PHP, ASP, Pyton, Ruby itp.) z atakiem wstrzyknięcia kodu po stronie przeglądarki. Może być ona wówczas zmuszona do pobrania z innej lokalizacji pliku zawierającego kod, a następnie dzięki błędom walidacji parametrów przesłanych w danych sesji, przekazania ich do kodu po stronie serwera.

Luki w oprogramowaniu

Na liście nowych luk i podatności znalazły się popularne moduły dla CMS-ów Drupal i Joomla. W wypadku systemów Moodle i XOOPS, luki znajdują się w ich głównym kodzie.

Moduł Drupal Project Module 5.x nie weryfikuje poprawnie rodzaju plików wgrywanych na serwer. Pozwala to przesłać pliki skryptów lub inne typy plików niż jest to oczekiwane. Drugim błędem jest również błąd walidacji ? tym razem mogący prowadzić do ataku Cross Site Scripting i wydobycia danych o sesji zalogowanych użytkowników. Nowa wersja 5.x-1.3 nie zawiera już wspomnianych podatności.

Drugim podatnym modułem Drupala jest ImageField Module 5.x, który podobnie jak poprzednik, pozwala przesłać inny typ pliku graficznego. Może to posłużyć do ?wyexploitowania? kodu PHP służącego do obsługi grafiki.

Kolejnymi wadliwymi modułami są dwie wersje 5.x i 6.x Drupal Views Bulk Operations Module, które dzięki luce w kodzie funkcji theme_views_bulk_operations_confirmation() pozwalają na atak Cross Site Scripting. Poprawne wersje to odpowiednio 5.x-1.3 i 6.x-1.4.

Kod systemu Moodle, zawiera serię niemal wszystkich wspomnianych w pierwszej części luk ? znajdziemy tu podatności na ataki Cross Site Scripting, możliwość nieautoryzowanego wydobycia wrażliwych danych i eskalację uprawnień kont działających w ramach portalu. Błędy dotyczą wersji Moodle 1.6.x, Moodle 1.7.x, Moodle 1.8.x oraz Moodle 1.9.x. Odpowiednio poprawione wersje są dostępne i oznaczone: Moodle 1.9.4, 1.8.8, 1.7.7, i 1.6.9.

System XOOPS jest podatny na ataki spreparowanymi wartościami parametru mydirname, który może być przekazywany do modułów oninstall.php, onupdate.php, notification.php oraz onuninstall.php w folderze xoops_lib/modules/protector. Wartości nie są odpowiednio weryfikowane i umożliwiają przesłanie kodu PHP, który zostanie uruchomiony poleceniem eval().

Ostatnią podatną wersją jest moduł Flash Magazine Deluxe dla Joomli!. Jest on podatny na atak SQL injection. Wartość przekazana do pliku index.php poprzez parametr mag_id przy jednocześnie włączonej opcji option = com_ flashmagazinedeluxe umożliwia przesłanie poleceń SQL, które zostaną scalone z kodem SQL poprawnych zapytań samej Joomli!. W wypadku tej podatności w Sieci dostępny jest już publicznie exploit wykorzystujący lukę.

Jak się zabezpieczyć?

Dla tych modułów i systemów które dysponują nowszymi poprawionymi wersjami, należy je zainstalować lub zaktualizować. W wypadku pozostałych, gdzie jedyną możliwością jest własnoręczna edycja kodu, warto pamiętać o kilku dość prostych środkach, które pozwalają uniknąć podatności.

• Należy sprawdzać każdą daną, jaką może wprowadzić użytkownik (bezpośrednio w formularzach) lub w adresie URI, w sygnaturze przeglądarki, polu odniesienia źródła (reffer) itd.
• Podczas przekazywania parametrów do zapytań SQL, warto sprawdzać je pod kątem występowania w nich znaków i ciągów, które niemal zawsze wiążą się z próbami modyfikacji zapytania ? INNER JOIN, LEFT JOIN, UNION itd.
• Dane plików wrażliwych (logi, pliki tymczasowe powstające podczas przetwarzania danych na serwerze) powinny być nieosiągalne z zewnątrz serwera przez innych użytkowników niż właściciel procesu samego serwera i/lub interpretera. Ponadto pliki takie powinny być składowane poza drzewem katalogów osiągalnych przez serwer WWW.
• W wypadku PHP warto pamiętać, aby wyłączać feralną możliwość automatycznego pamiętania danych w sesji ? register_globals. W znaczącej części exploitów podłączających zewnętrzny kod, funkcja ta odgrywa kluczową rolę, pozwalając na zapis danych do sesji z zewnątrz bez jakiejkolwiek walidacji.

Źródło: InfoProf.pl