Dylematy administratora bezpieczeństwa Oracle

Wojciech Dworakowski, SecuRing
wojtekd@securing.pl

Od blisko roku przybliżam Państwu nowe zagrożenia związane
z produktami Oracle w Biuletynie Bezpieczeństwa PLOUG, drukowanym na łamach
naszego pisma. Za każdym razem gdy opisuję jakąś „dziurę”
zastanawiam się, ilu z administratorów wgra poprawkę (patch) do swojej
instalacji Oracle. Z podobnymi dylematami wśród administratorów Oracle
spotykam się również podczas prowadzenia audytów i ocen bezpieczeństwa.
Bardzo często widzę systemy zainstalowane, uruchomione i nie ruszane od lat.
Obowiązuje zasada: „Działa – więc lepiej nie grzebać”. W
poniższym, krótkim artykule postaram się przekonać Państwa, że mimo
wszystko – warto nakładać poprawki producenta, jednak należy to robić
w sposób racjonalny.

Czy warto wgrywać poprawki?

Pytanie wydaje się retoryczne. Zwłaszcza gdy stawia je człowiek
zajmujący się zawodowo bezpieczeństwem IT. Oczywiście – jasne jest, że
poprawki usuwają błędy, a przez to podnoszą bezpieczeństwo. Jednak pamiętajmy,
że współczesne podejście do bezpieczeństwa IT wyróżnia trzy równorzędne
dziedziny: poufność, integralność i dostępność. O ile wgranie poprawki na
pewno podnosi poufność i integralność danych, to z dostępnością tych
danych bywa już różnie. Większość administratorów boi się ingerować w
system informatyczny na niskim poziomie, przez nałożenie poprawki. Od razu
przypominają się tu każdemu noce spędzone nad przywracaniem systemu do życia
po „przedobrzeniu”. Tak więc odpowiedź na to pytanie nie jest taka
oczywista jak by się mogło wydawać. Tym trudniej jest dać jednoznaczną
odpowiedź, że – o ile ryzyko związane z utratą poufności danych i
wyciekiem informacji z systemu jest dość abstrakcyjne dla większości
administratorów, to ryzyko związane z utratą stabilności i dostępności
danych jest bardzo konkretne i namacalne. Bliższa ciału koszula…

Mimo to jestem zdania, że należy nakładać poprawki
przygotowane przez producenta. Statystyki mówią same za siebie. Według badań
FBI ponad 90% incydentów związanych z naruszeniem bezpieczeństwa IT,
wykorzystuje podatność w oprogramowaniu znaną już wcześniej administratorom
obiektu, który stał się celem ataku!

Tak więc warto nakładać łaty – jednakże należy to
robić w sposób racjonalny. Jak w wielu innych dziedzinach należy tu stosować
zasadę złotego środka. A więc: systematycznie zmniejszać podatność
naszych systemów na ataki, przy jednoczesnym zachowaniu wysokiego stopnia
stabilności i dostępności. Jak pogodzić te pozornie sprzeczne cele? Przez
stosowanie odpowiednich zasad zarządzania bezpieczeństwem.

Jak zarządzać poprawkami?

Do codziennych zadań każdego z administratorów powinno
należeć zarządzanie poprawkami. Wyróżniłbym tutaj następujące etapy:

1. Zdobywanie informacji o nowych podatnościach.

Np. przez prenumeratę Oracle Security Alerts i/lub lekturę
Biuletynu Bezpieczeństwa PLOUG.

2. Ocena ryzyka w środowisku eksploatowanego systemu.

Jedno z kluczowych zadań. Chodzi o ocenę, na ile dana
poprawka jest kluczowa dla naszej konkretnej instalacji. Nie wystarczy opierać
się tutaj na wycenie zagrożenia opublikowanej przez Oracle. Trzeba przede
wszystkim wziąć pod uwagę specyfikę naszego systemu. Punkt ten rozwinę w
dalszej części artykułu. Celem oceny ryzyka powinno być
„posortowanie” zagrożeń i związanych z nimi poprawek na dwie lub
trzy klasy w zależności od stopnia ryzyka.

3. Testowanie poprawek.

Przy prawie każdym systemie produkcyjnym powinna istnieć
bliźniacza instalacja eksperymentalna. I tak jest z reguły w praktyce. Nie
musi to być oczywiście kopia całości instalacji 1 do 1, ale powinna umożliwić
wcześniejsze przetestowanie zmian i ocenę zagrożenia płynącego z samego
wprowadzenia poprawek.

4. Instalowanie poprawek w cyklach.

Kluczowych zmian do systemu nie powinno się wprowadzać ad
hoc. Dobre zasady mówią o wyznaczeniu strategii wprowadzania poprawek. Np.:

  • Raz na pół roku wprowadzamy wszystkie ostatnio
    opublikowane uaktualnienia.
  • Raz na miesiąc wprowadzamy wszystkie uaktualnienia mające
    znaczący wpływ na bezpieczeństwo naszego systemu.
  • Poprawki najbardziej kluczowe, wiążące się z dużym
    ryzykiem (np. dla systemów wystawionych do Internetu) należy wprowadzać
    na bieżąco lub należy stosować obejścia problemów (o ile to możliwe).

Oczywiście zaliczenie danej poprawki do którejś z tych
kategorii wynika z oceny ryzyka (punkt 2).

Każde wprowadzenie poprawki powinno zostać poprzedzone krótką
analizą ryzyka obniżenia dostępności systemu i dokładnym przeczytaniem
instrukcji dołączonych do poprawki (!) oraz (last but not least) –
sprawdzeniem aktualności kopii bezpieczeństwa.

Jak ocenić zagrożenie?

Jak wiadomo – nie ma systemów w stu procentach
bezpiecznych. Stary model zarządzania bezpieczeństwem przez unikanie ryzyka,
okazał się mało praktyczny i od pewnego czasu odchodzi się od niego na rzecz
zarządzania ryzykiem. Podstawą zarządzania ryzykiem jest właściwa analiza
ryzyka i wycena zagrożeń.

Odradzam opieranie się tylko i wyłącznie na ocenach zagrożenia
publikowanych przez producenta. Zupełnie naturalne jest, że producent zawsze będzie
stawiał swój produkt w pozytywnym świetle, a przez to mimowolnie obniżał
realne zagrożenie. Dużo lepszym źródłem informacji są notatki publikowane
przez niezależnych badaczy, którzy często są odkrywcami danej podatności.
Biuletyn Bezpieczeństwa PLOUG jest budowany przede wszystkim na podstawie
takich informacji.

Poza tym – podatność może w różny sposób
„działać” w różnych środowiskach. Każdorazowo, administrator
powinien poznać istotę problemu związanego z daną „dziurą” i
ocenić jak ten problem może zaistnieć w jego środowisku informatycznym. Pamiętajmy
– żadna aplikacja nie działa w odosobnieniu. Współczesne systemy
informatyczne to skomplikowane mechanizmy, składające się z wielu różnych
części. Również współczesne metody ataków wykorzystują wiele różnych,
często drobnych podatności, dla osiągnięcia celu. Tak więc dopiero
spojrzenie na całość konkretnego systemu informatycznego daje możliwość
prawidłowej oceny zagrożenia.

Przykładowo: W większości dokumentów Oracle Security
Alert dotyczących bazy danych Oracle można znaleźć zdanie:

„Unless you connect the database directly to the
Internet (e.g., no intervening application server or firewall), a remote attack
via the Internet is, in our opinion, unlikely. This vulnerability is susceptible
to an insider attack originated on the corporate Intranet.”

Większość instalacji bazodanowych stoi w sieci LAN bądź
w sieci wydzielonej i nie jest bezpośrednio osiągalna z Internetu. Wydawać by
się mogło że w związku z tym problemy bezpieczeństwa (i wyceny zagrożeń)
można sprowadzić tylko i wyłącznie do zagrożeń płynących z Intranetu. Często
administratorzy mają bezgraniczne zaufanie do swoich użytkowników i nie
podejrzewają ich o jakąkolwiek możliwość ataku. Jeśli już, to ryzyko to
jest ograniczane przez odpowiednie przepisy wewnętrzne. Niestety – we współczesnym
świecie jest to zbyt daleko idące uproszczenie. Stacje robocze są z reguły
najmniej chronionymi zasobami i najłatwiejszym kąskiem dla intruza. Stacja może
zostać opanowana stosunkowo łatwo a potem może stanowić przyczółek dla
intruza w naszej sieci LAN. Dodatkowe zagrożenie stanowią stacje mobilne (np.
laptopy) które często działają poza siecią kontrolowaną przez nas.
Standardem jest używanie laptopów w domu np. do grania lub ściągania z
Internetu muzyki i filmów. O infekcje w takich środowiskach nietrudno.
Wystarczy że laptop zostanie zarażony poza siecią firmową, a potem zostanie
wpięty do LAN-u. Automatycznie zagrożenie obecne standardowo w Internecie,
staje się również zagrożeniem wewnętrznym.

Doskonałym przykładem praktycznym są tutaj epidemie różnego
rodzaju robaków internetowych (np. CodeRed, Slammer). Wielu administratorów
zignorowało zagrożenie i wgrało poprawki tylko do serwerów wystawionych do
Internetu. Jakież było ich zdziwienie gdy parę miesięcy później ich
serwery wewnętrzne zostały zainfekowane.1 Jeżeli ograniczony
automat działający na oślep, może tak łatwo przenikać do sieci wewnętrznej,
to jak łatwo może to zrobić intruz ukierunkowany na konkretny cel?

Innym ważnym czynnikiem, jaki należy wziąć pod uwagę
przy wycenie zagrożenia, jest ocena łatwości wykorzystania podatności. Jeżeli
w Internecie są dostępne dokładne instrukcje i programy (exploity) to należy
zakładać, że wykorzystanie luki jest trywialnie proste, co automatycznie
podnosi stopień zagrożenia.

Przy tej okazji warto krótko opisać jedną z najczęściej
spotykanych metod ataku – atak przez przepełnienie bufora wejściowego (buffer
overflow). W największym skrócie – wykorzystywany błąd w
oprogramowaniu polega na braku sprawdzania długości pobieranych danych. Intruz
może przepełnić bufor wejściowy, nadpisać adres powrotu z procedury i w
rezultacie wykonać na serwerze swój kod. Wykrycie luki tego typu jest
stosunkowo łatwe, jednak napisanie programu (exploita) wykorzystującego tę
lukę wymaga nieco wiedzy, czasu i dostępu do atakowanego oprogramowania. Nie
jest to jednak zadanie niewykonalne. Buffer overflow jest metodą bardzo dobrze
udokumentowaną i stosowaną powszechnie. Również w kontekście oprogramowania
Oracle.

Przy podatnościach typu „buffer overflow” można
wyróżnić trzy poziomy ryzyka związanego z upublicznieniem informacji o
podatności:

  • Jest publicznie dostępny exploit.
  • Exploita nie ma, ale opublikowano wystarczająco dużo
    informacji żeby napisać go samemu.
  • Opublikowano bardzo mało informacji, a co za tym idzie
    intruz musi szukać miejsca w którym występuje błąd.

Pamiętajmy jednak, że ilość informacji udostępnionych w
Internecie, to tylko czubek góry lodowej. Hackerzy tworzą własne zamknięte
społeczności i większość kluczowych informacji nie opuszcza wąskiego kręgu
osób.

Warto też zaznaczyć, że opublikowanie przez producenta
poprawki łatającej jakąś „dziurę” nie oznacza, że została ona
wykryta kilka dni wcześniej. Przykładowo – w bieżącym numerze
Biuletynu Bezpieczeństwa PLOUG są opisane podatności, o których Oracle
wiedział już we wrześniu 2002, a więc blisko rok temu.

Opisałem tutaj tylko dwa czynniki jakie należy wziąć pod
uwagę przy ocenie ryzyka związanego z daną podatnością: dostępność
systemów i łatwość wykorzystania podatności. Przy wykonywaniu pełnej
analizy ryzyka można zastosować jedną ze sformalizowanych metodyk. Przykładem
jest metodyka DREAD. Polega ona na ocenie zagrożenia w pięciu kategoriach:

  • Damage potential – Co uzyskuje intruz jeśli
    uda mu się wykorzystać podatność?
  • Reproducibility – Czy podatność da się
    wykorzystać zawsze, czy też tylko w określonym czasie lub warunkach?
  • Exploitability – Jak wielkiej wiedzy wymaga
    przeprowadzenie ataku?
  • Affected users – Jak wielu użytkowników
    dotyka podatność?
  • Discoverability – Ile informacji
    opublikowano i jak ciężko jest wykryć istnienie podatności?

W każdej kategorii, zagrożenie ocenia się w skali od 1
(niskie) do 3 (wysokie). Na koniec wyciąga się średnią, która jest miarą
zagrożenia

Komentarz do bieżącego Biuletynu Bezpieczeństwa PLOUG

Na koniec chciałbym zwrócić Państwa uwagę na zawartość
bieżącego Biuletynu Bezpieczeństwa PLOUG. Tak się złożyło, że rodzaj
podatności wykrytych w ostatnim okresie w oprogramowaniu Oracle, stanowi
doskonały materiał szkoleniowy, a zarazem podsumowanie powyższych rozważań.

Oto mamy prawdziwy urodzaj na błędy odkrywane w Oracle
E-Business Suite. Dlaczego tak się dzieje? Czyżby wcześniej nie było tych błędów?
Oczywiście nie – błędy przez cały czas istniały, lecz dopiero teraz
znalazł się badacz, który zechciał je ujawnić i powiadomić o tym
producenta. Podobna sytuacja była około trzech lat temu z DBMS Oracle. Oracle
uważano za system stosunkowo bezpieczny, ale tylko dlatego że nikt się nie
zajął systematycznym badaniem jego bezpieczeństwa. Sytuacja zmieniła się
diametralnie, wraz z licznymi publikacjami Pete Finnigana i Davida Litchfielda.

Jeśli już mówimy o E-Business Suite, to w uaktualnieniu do
Oracle Security Alert #47, Oracle zwraca uwagę użytkownikom E-Business Suite
11i, że w skład tego pakietu, wchodzi część komponentów Oracle Application
Server 9i Release 1 (wersje 1.0 i 1.0.2.2). Tak więc błędy, które są obecne
w 9iAS R1 (a jest ich sporo), mogą dotyczyć także instalacji E-Business Suite
11i. Fakt ten nie był wcześniej zaznaczany w Oracle Security Alerts.

Drugą ciekawostką w bieżącym Biuletynie jest błąd w
kodzie poprawiającym „dziurę” związaną z Oracle External
Procedures. Okazało się, że Oracle tak nieszczęśliwie poprawił znany błąd,
że wprowadził nową podatność – tym razem typu buffer overflow. Wydawać
by się mogło, że jest to przykład kuriozalny, jednakże tego typu wpadki
zdarzają się każdemu. Np. Microsoft kilka miesięcy temu wycofał jedno z
uaktualnień systemu, gdyż okazało się, że w specyficznych warunkach odcina
ono system od sieci. Jeszcze gorsza wpadka zdarzyła się producentowi programu
antywirusowego McAffe. W listopadzie 2000 roku opublikował poprawkę, która
zawieszała cały system operacyjny.

Jak widać – nie ma tutaj miejsca na działania
automatyczne. Jedynym wyjściem jest testowanie uaktualnień oraz zabezpieczenie
w postaci aktualnego backupu. Jeśli chodzi o najświeższe poprawki i najnowsze
wersje systemów, to najlepiej ujął to mój znajomy: „Jeśli coś nie ma
drugiego service packa, to nie może być stabilne”. Odnosiło się to
akurat do produktów Microsoft, ale w światku Oracle, w zdaniu tym jest również
dużo racji.

Tak więc – aktualizować tak – ale racjonalnie i
w sposób uporządkowany.

Z ostatniej chwili:

Informacje płynące z kwatery głównej Oracle wspominają,
że przed końcem roku ukaże się nowe narzędzie do zarządzania poprawkami. Będzie
ono w stanie dokładnie sprawdzić jakie poprawki są zainstalowane i doradzić
podstawowe kroki zmierzające do zabezpieczenia systemu. Narzędzie będzie
prawdopodobnie darmowe.

http://www.eweek.com/article2/0,3959,1120074,00.asp?kc=EWAV10209KTX1K0100440

W Internecie: