Artykuły dotyczące tematu: edukacja

dodany: 12.02.2013 | tagi: , ,

Zaawansowany SQL Injection

0

W artykule Bezpieczeństwo aplikacji webowych – SQL Injection przedstawione zostały podstawowe zasady przeprowadzania ataków typu SQL Injection. Niniejszy artykuł przedstawia bardziej zaawansowany wariant tego ataku – Blind SQL Injection oraz zagrożenia płynące z utrzymywania aplikacji, które są podatne na wstrzyknięcie i wykonanie obcego kodu SQL. W kolejnym artykule przedstawione zostaną techniki przeciwdziałania tego typu atakom, które można zaimplementować w co najmniej dwóch warstwach systemu webowego.

W podstawowym wariancie ataku typu SQL Injection, agresor bez trudności może zobaczyć wyniki działania wstrzykniętego zapytania, zaraz po wykonaniu zapytania. Zazwyczaj wyniki te są widoczne na ekranie w postaci komunikatu o zalogowaniu na uprzywilejowane konto, uzyskaniu wysokiego wyniku w grze, niestandardowej zawartości wirtualnego koszyka zakupowego lub wyjątkowo okazyjnej cenie produktu albo jeszcze innej anomalii. Takie bezpośrednie sprzężenie zwrotne zdecydowanie ułatwia i przyspiesza opracowanie groźnego zapytania.

Istnieją sytuacje, gdy agresor nie może odczytać wyników zapytania, gdyż badana przez niego funkcjonalność systemu nie przewiduje możliwości wyświetlenia wyniku działania zapytania. Taką sytuację można wyobrazić sobie np. w przypadku wypełniania anonimowej ankiety internetowej. Po wciśnięciu przycisku ‚Wyślij’ agresor otrzymuje wyłącznie informacje o przyjęciu komunikatu przez serwer. Innymi słowy, agresor nie widzi efektu działania zapytania, co pozornie czyni go ślepym na takie efekty. W takiej sytuacji zdecydowanie trudniej jest stwierdzić, że zamierzony atak odniósł skutek. ‚Zdecydowanie trudniej’ oznacza, że być może jest to możliwe, gdyż przy odpowiedniej obserwacji reakcji serwera jesteśmy w stanie wydedukować, jaki był wynik zapytania.

W przypadku Blind SQL Injection, atak sprowadza się do uzyskania informacji binarnej – 0 lub 1, NIE lub TAK, które świadczą o powodzeniu (lub niepowodzeniu) zapytania. Posiadając informację o wyniku, skrupulatny i konsekwentny agresor jest w stanie przygotować serię zapytań, które w ostateczności doprowadzą go do uzyskania pożądanej informacji lub dokonania zmiany w nowo poznanej strukturze danych.

‚No dobrze, co może być takim semaforem?’ zapytać powinien każdy adept sztuki tworzenia zapytań. Odpowiedzi może być wiele – od zauważalnego opóźnienia w uzyskaniu odpowiedzi, przez zwrócenie komunikatu błędu typu HTTP 500 (sam komunikat nie niesie szczególnych informacji) przez serwer aplikacji, aż do odebrania pozornie nieistotnego komunikatu sieciowego przez serwer będący pod kontrolą agresora.

Generalnie zapytania SQL mają postać:

(Na potrzeby zwiększenia czytelności przykładów, fragmenty wymagane do powodzenia wykonania SQL Injection będą pomijane).

Po otrzymaniu takiego zapytania, serwer rozpoczyna przeszukiwanie tabeli B na okoliczność spełnienia warunku C. Jeśli warunek zostanie spełniony, serwer wykonuje i zwraca wartość A. W przypadku, gdy warunek C nie zachodzi, serwer nie przetwarza ciągu określonego przez A. Dzięki temu zachowaniu, można skonstruować takie formuły A, których wykonanie będzie wpływało na działanie serwera, co da agresorowi wiedzę o powodzeniu zapytania.

Przykład:

Powyższe zapytanie spowoduje wystąpienie błędu dzielenia przez zero dla serwera bazy danych Oracle w przypadku, gdy w tabeli users istnieje użytkownik o nazwie ‚zygzak’. Jeśli aplikacja nie przewiduje otrzymania tego typu odpowiedzi, najczęściej użytkownik ujrzy komunikat HTTP 500.

Dla innych baz danych ten sam przykład miałby postać:

Jak widać, tworzenie zapytań w wariancie Blind SQL jest trudniejsze niż w podstawowym wariancie, ale należy pamiętać, że hacker dysponuje ogromną wiedzą informatyczną i nawet obserwacja wyników powyższych zapytań, może dać mu przesłanki co do typu wykorzystywanej bazy danych. Znajomość zasad przetwarzania zapytań przez hakera, pozwala mu przygotować zmodyfikowaną postać powyższego zapytania w przypadku, gdyby aplikacja miała zaimplementowaną funkcjonalność unieszkodliwiania pierwszej części zapytania (A) lub:

Logika działania serwerów baz danych jest tworzona tak, aby aplikacja otrzymywała wyniki w jak najkrótszym czasie. W tym przypadku, jeśli warunek C nie zachodzi, to serwer nie analizuje zapisu 1/0=1, co w rezultacie nie prowadzi do uzyskania błędu.

Załóżmy, że aplikacja jest przygotowana na wystąpienie błędu i maskuje wystąpienie takich sytuacji. W takim przypadku, należy zmienić formułę A i użyć testu czasowego.
Schemat jest identyczny, jak powyższy:

– i w przypadku, gdy zachodzi warunek C, przetworzenie A zajmuje serwerowi odczuwalnie dużo czasu i na podstawie tej obserwacji, agresor może wydedukować wynik zapytania.

Przykłady:

W przypadku serwera Oracle trudno znaleźć metodę, która mogłaby wprost posłużyć do wygenerowania opóźnienia. Sprytny agresor nie załamie rąk i być może uda mu się skorzystać z pakietów z rodziny UTL zainstalowanych na atakowanym serwerze. Przy ich pomocy można próbować odwołać się do adresu, o którym agresor coś wie (np. to, że nie jest obecnie wykorzystywany lub jest pod jego kontrolą) i na tej podstawie wydedukować wynik 1 lub 0.

Ten sam pakiet może posłużyć do… wykonania wstępnego rekonesansu w sieci, w której funkcjonuje serwer Oracle. Test penetracyjny przez serwer bazy danych? Brzmi abstrakcyjnie, ale w przypadku, gdy ktoś niefrasobliwie nadał szerokie uprawnienia użytkownikowi bazy danych, takie zapytanie może się powieść. Na szczęście, firma Oracle wprowadziła dla serwerów Oracle Database 11g dość rygorystyczne podejście do wykonywania połączeń przy wykorzystaniu pakietu UTL i takie ataki skazane są praktycznie na porażkę.

Mamy już wiedzę, która pozwoli przeprowadzić atak, polegający na odczytaniu zawartości dowolnej znanej kolumny. Atak polega na iterowaniu kolejnych znaków zapisanych w polu bazy danych. Poniższy zapis, okrojony z oczywistych powodów, testuje wartość najmłodszego bitu w pierwszym bajcie słowa Admin. Automatyzując atak, wykonując osiem analogicznie zbudowanych zapytań (zmieniany jest wyłącznie wykładnik), jesteśmy w stanie ustalić wartość pierwszego bajtu. Kontynuując, po 128 zapytaniach, jesteśmy w stanie podać wartość 7-literowego hasła (lub jego skrótu).

Budując w podobny sposób zapytania, atakujący jest w stanie stworzyć zestaw zapytań, które pozwolą mu poznać nazwy kolumn, nazwy tabel i wiele innych informacji dotyczących bazy danych w dość krótkim czasie. Z wiadomych powodów, takie receptury nie zostaną tu przedstawione.

Wniosek:
Umieszczenie w aplikacji miejsca (pole formularza, formuła w importowanym dokumencie), które umożliwi wstrzyknięcie i wykonanie kodu SQL stanowi bardzo duże zagrożenie dla wykorzystywanej bazy danych. Ryzyko powodzenia ataku SQL Injection, nawet w przypadku, gdy użytkownik nie widzi wyników działania SQL, należy bezwzględnie minimalizować przez stosowanie mechanizmów na co najmniej dwóch warstwach systemu. O kilku przykładowych technikach, napiszę na portalu Websecurity za 2 tygodnie.

dodany: 08.11.2012 | tagi: , ,

Pojęcie bezpieczeństwa. CIA.

1

Chyba każdy administrator wie, że z chwilą podłączenia swojego systemu do większej sieci, pojawia się w jego codziennych obowiązkach pilnowanie bezpieczeństwa powierzonych mu usług i danych. Niemniej liczne obserwacje skłaniają mnie do stwierdzenia, że wyobrażenie tego, czym jest bezpieczeństwo, jak je zdefiniować i chronić, bywa niekompletne. Zwłaszcza administratorzy systemów operacyjnych miewają niepełny obraz tego, na czym polega ich zadanie.

Bezpieczeństwo danych i usług to nie tylko włamywacze. Wprawdzie ostatnimi czasy w prasie wykradzione hasła i zdjęcia zyskały na popularności, głównie dzięki pewnej pikanterii, niemniej każdy szanujący się administrator powinien wiedzieć, że bezpieczeństwo to pojęcie znacznie szersze niż tylko kwestia źle zabezpieczonych kont i podatności w kodzie.
Tradycyjne rozumienie bezpieczeństwa opiera się na trzech podstawowych parametrach, które w języku angielskim układają się w znany akronim: CIA. Tym razem jednak nie chodzi o agencję wywiadowczą, ale o trzy wskaźniki, których pożądany dla danego zasobu poziom należy zdefiniować, obserwować i utrzymywać.

(więcej…)

dodany: 06.11.2012 | tagi: , ,

Bezpieczeństwo aplikacji webowych – SQL Injection

2

W poprzednim odcinku rozpoczęliśmy nasz cykl poświęcony tematyce bezpieczeństwa aplikacji webowych. Dzięki pierwszemu artykułowi poznaliście kilka historii z życia wziętych i mam nadzieję, że nabraliście przekonania, iż warto się tym tematem zainteresować szerzej. Od tej chwili skupiamy się więc na aspektach technicznych naszych projektów – na lukach bezpieczeństwa w kodzie źródłowym czy konfiguracji serwerów.

W pierwszej kolejności przyjrzymy się problemowi, który od kilku lat wciąż zajmuje najwyższe lokaty we wszelkiego rodzaju rankingach zagrożeń i niebezpieczeństw IT. SQL Injection, bo o nim tutaj mowa, stanowi bardzo groźną lukę w zabezpieczeniach, którą potencjalny atakujący może wykorzystać do np. zmiany informacji w bazie danych, struktury tabel, uzyskania nieautoryzowanego dostępu do danych czy też przeprowadzenia ataku Denial of Service. Choć lista możliwych zagrożeń jest jeszcze dłuższa, to powyższe zestawienie i tak powinno już przyprawić o porządny ból głowy. Zastanówmy się więc nad genezą tego typu problemów…

W tym celu będzie nam potrzebny zapowiedziany w poprzedniej części prosty serwis społecznościowy, wyposażony we wszystkie typowe funkcjonalności: rejestrację i logowanie, nawiązywanie znajomości pomiędzy użytkownikami, wysyłanie wiadomości prywatnych, upload zdjęć, wystawianie komentarzy. Zaplecze technologiczne również będzie tu bardzo typowe i znane chyba każdemu programiście: Linux, Apache, MySQL i PHP.
Nasza aplikacja jest bardzo prosta i na chwilę obecną umożliwia założenie konta za pomocą przedstawionego formularza <SCREEN>, w którym po wprowadzeniu adresu e-mail oraz hasła użytkownik otrzymuje wiadomość z linkiem aktywacyjnym. Na obsługę po stronie serwera składa się poniższa tabela w bazie danych:

oraz następujący skrypt PHP:

 

Przyglądając się strukturze tabeli user, trudno znaleźć w niej jakąś oczywistą lukę. Kolumna przechowująca loginy użytkowników posiada jednoznaczny klucz UNIQUE. Konta użytkowników posiadają flagę aktywności oraz czas ostatniego logowania, a dodatkowo wszystkie hasła są kodowane z wykorzystaniem salta, co skutecznie utrudnia ataki na hasła użytkowników. Drugi z przedstawionych elementów jest już niestety o wiele bardziej niebezpieczny, a pochodzi niemal wprost z jednego z blogów poświęconych programowaniu w języku PHP. Jego zadaniem jest odebranie danych wysłanych z formularza za pomocą metody POST, obliczenie wartości salt i utworzenie rekordu użytkownika w bazie danych. W wyniku jego działania, gdy w aplikacji zarejestruje się Jan Kowalski, w bazie danych prawdopodobnie znajdzie się rekord podobny do poniższego:

Co się jednak stanie, gdy jako login użytkownika podany zostanie ciąg znaków: “hack.me’, ‘haslo’,’salt’, 1);–“ ? W bazie danych znajdą się wówczas dane:

Jak widać, atakujący ominął w ten sposób logikę skryptu i samodzielnie ustawił wartości poszczególnych kolumn. Było to możliwe, ponieważ skrypt w żaden sposób nie zadbał o weryfikację i walidację danych wejściowych. Do bazy danych zostały przekazane dane bezpośrednio z POST-a, a dzięki użyciu apostrofu oraz znaku komentarza SQL atakujący może zmienić strukturę zapytania. W szczególności możliwe jest także założenie konta o loginie: “empty.me’, ‚haslo’,’salt’, 1); TRUNCATE TABLE user; –“, przy czym w takiej sytuacji ilość rekordów w tabeli spada zauważalnie.

W tym przypadku baza danych wykonała dwa zapytania. W pierwszej kolejności wstawiony został rekord nowego użytkownika, po czym wszystkie dane z tabeli user zostały usunięte. Oczywiście równie dobrze mogło się tam pojawić zapytanie wstawiające rekordy do innych tabel czy też usuwające całą bazę. Jeśli podobny kod PHP będzie odpowiedzialny za obsługę logowania, również i w tym przypadku możliwe będzie wykonanie SQL Injection. Aby zalogować się na dowolne konto, wystarczy wówczas znać jego login, a w formularzu logowania określić je jako np. “jan.kowalski’ OR 1=1;–“ lub po prostu “jan.kowalski’;–“.

Przeprowadzenie ataku SQL Injection w praktyce jest trochę bardziej skomplikowane – nie mamy przecież dostępu do kodu źródłowego, a struktura tabeli nie jest nam znana. Jednak w bardzo wielu przypadkach pozostawione luki bezpieczeństwa ułatwiają cały proces, np. poprzez wyświetlenie komunikatów o błędach. Choć oczywiście czasami atakujący otrzymują informacje podane na srebrnej tacy, tak jak w przypadku pewnej prywatnej wyższej uczelni, kształcącej studentów na kierunkach informatycznych, na stronach której w kodzie HTML stron widnieją wszystkie zapytania SQL wraz z dodatkowymi informacjami dla debuggera. Gdy wszelkie informacje o błędach są ukrywane przez użytkownikami, pomyślne wykonanie ataku Blind SQL Injection choć o wiele trudniejsze, zazwyczaj nadal jest możliwe.

W tym miejscu przytoczę krótką historyjkę… Otóż, gdy kiedyś pracowałem w agencji interaktywnej, na potrzeby jednego z projektów poszukiwaliśmy JavaScriptowej biblioteki do generowania wykresów. Razem z kolegą zaczęliśmy więc sprawdzać co ciekawsze wyniki z Google, przy czym naszą uwagę zwróciła strona, na której wykresy wyglądały naprawdę nowocześnie, ale były wyświetlane w postaci statycznego pliku PNG. Adres tego pliku wyglądał mniej więcej tak: /scripts/chart.php?query=SELECT * FROM chart_table WHERE chart_id = 123. Jestem przekonany, że autor tego rozwiązania był zadowolony z jego uniwersalności i poświęcił chwilę czasu na wyjaśnienie, dlaczego przestały się renderować…

Aby uniknąć problemów wywołanych przez SQL Injection pomocne mogą być następujące zasady:

  1. Dane wejściowe powinny być zawsze weryfikowane i walidowane zgodnie z założonym typowaniem. Nigdy nie należy ufać danym otrzymanym bezpośrednio od użytkowników.
  2. Umieszczanie danych w zapytaniach SQL powinno zawsze odbywać się w sposób bezpieczny, czy to poprzez zastosowanie funkcji mysql_real_escape_string czy też PDO::bindParam.
  3. Aplikacja webowa powinna korzystać z bazy danych za pomocą użytkownika o ograniczonych uprawnieniach. Jeśli to możliwe, uprawnienia do wykonania poleceń typu DROP czy ALTER powinny zostać odebrane.
  4. Błędy wykonania i związane z tym komunikaty serwera powinny trafiać tylko i wyłącznie do logów.
  5. W niektórych przypadkach warto zabezpieczyć się już na poziomie serwera WWW, np. poprzez instalację mod_security czy odpowiednią implementację mod_rewrite.

Zadanie
Na koniec mała niespodzianka… Po zabezpieczeniu logowania i rejestracji w naszej aplikacji, na niektórych środowiskach serwerowych dalej istnieje możliwość zalogowania się na dowolne konto, tym razem bez wstrzykiwania zapytań SQL czy podsłuchiwania komunikacji i kradzieży sesji.
Jeśli domyślacie się, w jaki sposób funkcjonuje ta luka bezpieczeństwa, napiszcie o tym w komentarzu.

dodany: 25.09.2012 | tagi: , , ,

ZRTP – bezpieczna komunikacja głosowa

2
voip

Telefon. Urządzenie tak powszechne w XXI wieku, że dla wielu stanowi przedłużenie ciała. Używamy telefonów każdego dnia rozmawiając i o rzeczach codziennych, i o tajemnicach. Ilu z nas jest jednak świadomych, jak proste jest podsłuchanie naszej rozmowy?

Rozmowy przez telefon GSM są szyfrowane 64-bitowym kodem A5/1, stworzonym w roku 1987. Obecnie złamanie takiego szyfru za pomocą standardowego komputera z dobrą kartą graficzną zajmuje kilka minut. Jeśli podsłuchującego stać na dokupienie do komputera kilku terabajtów dysków SSD, czas ten spada do kilku sekund. Samo fizyczne przechwycenie danych jest bardzo proste – nie trzeba się nigdzie włamywać, wykopywać kabli ani podłączać do nich specjalistycznego sprzętu. Fale radiowe rozchodzą się we wszystkich kierunkach i do przechwycenia sygnału wystarczy programowo przestrajany odbiornik radiowy SDR (np. z projektu GNU Radio).

(więcej…)

dodany: 13.08.2012 | tagi: ,

Złośliwe oprogramowanie – choroba systemu komputerowego

0

System komputerowy można porównać do organizmu człowieka. Wszystkie jego procesy są ze sobą bardzo powiązane. Kiedy do ciała ludzkiego dostanie się jakaś infekcja, natychmiast opanowuje cały ustrój. Złośliwe oprogramowanie to bakteria, zaraza, która atakuje system odpornościowy naszego komputera.

Złośliwym oprogramowaniem (z ang. malware, malicious software) jest to wszystko, co ma szkodliwe działanie dla komputera i jego użytkownika. W tym aplikacje i skrypty, które są zagrożeniem dla ich poprawnego działania. Niektóre z nich służą nawet jako narzędzia w działaniach niezgodnych z prawem.

Wyróżniamy wiele rodzajów złośliwego oprogramowania. Tak jak w przypadku chorób, każda jest inna. Wymaga leczenia i konsultacji u odpowiedniego specjalisty – analityka, researchera do spraw bezpieczeństwa IT lub hakera.

(więcej…)

dodany: 23.07.2012 | tagi: , ,

Kto to jest haker?

1

Na dźwięk słowa „haker” pewnie wielu z nas zaczyna gorączkowo aktualizować swoje oprogramowanie antywirusowe albo kasować spam z obawy przed kliknięciem w któryś z linków zamieszczonych w podejrzanych e-mailach, wysłanych nam przez nieznanych nadawców.

Krótko mówiąc – boimy się hakerów. Po pierwsze dlatego, że – podczas gdy my potrafimy, co najwyżej, skorzystać z wyszukiwarki, napisać coś w Wordzie i zagrać w grę flashową – oni posiadają ogromną wiedzę o komputerach i IT. Po drugie dlatego, że kojarzą nam się z włamaniami do różnych systemów i baz danych, cyberatakami, zamykaniem stron internetowych, fałszowaniem informacji oraz wirusami i robakami – a więc całym złem w Internecie.

Skąd się bierze ten pejoratywny obraz hakerów? W ten właśnie sposób mówią o nich media. Pragnąc wzbudzać jak największe emocje wśród odbiorców, informują o sensacyjnych cyberprzestępstwach, odpowiedzialność za nie zrzucając na całe środowisko hakerów.

(więcej…)