Oracle's sikkerheds tilstand

I flere og flere tilfælde bliver Oracle databaser angrebet og hacket udefra - og kigger vi lidt på den organiserede undergrund; ser vi dels flere og flere præsentationer på såkaldte hacking konferencer (Blackhat, Defcon).

 Digital self defence - Blackhat 

Sikkerhedshuller udnyttes og der skrives specifikt software til at udnytte disse. Orme er fundet i Oracle Databaser, Alpha Voyager, Spida worm. Helt galt står det med at der rent faktisk skrives "White papers" på hvordan man angriper oracle databaser.

Så er du en ny hacker og vil du hacke din første oracle database bør du læse README.html og White papers 10G - Kom godt igang

Før 2005 var sikkerhed og Oracle mest som sikkerheds fix/patches til produkterne. Idag er der kommet mere flow omkring applikationer, komponenter og andet i og omkring oracle databaser. Sikkerheds alerts og patches kan ses her.

- Før 2000 - 1. af oracle anerkendt sårbarhed.

- Fra juli 2000 til august 20002 - 41 rapporter omkring sårbarheder på www.oracle.com

- 772 Resultater fra Securityfocus.com

Mange firmaer føler sig dog alligevel sikre - selv idag - da deres Oracle databaser er bagved firewall's. Er de sikre ? Overhovedet ikke. De fleste jobs at den beskidte slags ordnes indenfra - Der er typisk 2 stk drivkrafter - at man er ondsindet og vil gøre skade - eller man, er del af, en mere langsigtet plan, med nogen medsammensvorne, der over tid, får de rigtige priviledger til system/database m.v.

Tænk over selv hvis du er konsulent - med adgang til mange systemer; hvor mange systemer rundt omkring har du egentlig adgang til ? Hvor mange brugernavne og password i forskellige varianter kender du til ? Hvor let er det får dig at få fat i brugernavne, passwords i en ny virksomhed ? Med lidt fantasi - hvad skulle der til, for du kunne få adgang til virksomhed X ? Og endnu bedre - de oplysninger omkring virksomheder/brugere/passwords ....... Hvor gemmer du det ? Tilgængeligt på en web server ? I sikkerhed bag din egen firewall ?

Tænk så over det samme, men som den hardcore forbryder du er; Du er ikke tekniker - du er vant til det hårde miljø - du er helt sikkert også klar over der er penge i hjerne - Herfra er det et spørgsmål om kontakt - og informationer.

Hvordan for man lettest informationer ud af EDB fyre uden ligefrem at skulle være venner ?

Hvis du skulle have adgang til mailkonti - ville det være en løsning at betale studerende, af høj kaliber, et beløb for at få adgang ? Dette foregår og tit er disse beløb ikke meget større end DKK 1.000,-

Hvis ovenstående kan lade sig gøre; Så kan vi vel også begynde at tale om hvilke firmaer er interessante - hvem har noget af værdi, vi kan bruge og hvad skal der til for vi kan få fat i det.

Hvad er mulighederne for at organisere dette ? De er meget meget store, og foregår allerede. Selv hvor EDB fyren (dig i ovenstående) for specielt attraktive firma, lader sig ansætte, med formål at opnå insider informationer. Er de hardcore fyre på forkant med IT udviklingen, teknologier ? Ja !

Sikkerhed er noget man bør vuderere løbende - og man skal aldrig stoppe og sige - min firewall er sikker nok - men se tingene fra alle vinkler - specielt med forbryder masken på - har jeg noget der er intressant, værd at tage - Har vi som firma nogen lig i lasten ? Nogen der vil skade os ........ Mange muligheder ikk ?

Lad os vende tilbage til Oracle og kigge lidt på nogle ting omkring database systemmet.

Listener servicen

Lad os starte med at kigge på en enkelt komponent fra Oracle, nemlig listener prosessen. Listener prosessen er en proxy i forbindelseøjeblikket mellem klient og database. Klienten opretter en forbindelse til listener servicen - der etablererer en server prosess (dedicated server process) - og retunerer denne adresse til klienten, der hermed forbinder sig til server processen, for at opnå en forbindelse til databasen.

Der eksisterer det udestående, med vores listener process at den har en separat godkendelse (authentication) og er administreret og kontrolleret udenfor databasen. Listener servicen kører som en separat prosess.

Listener servicen accepterer kommandoer og andre opgaver andet end blot håndtering af database forbindelser.

Hvordan sikrer vi sikkerheden omkring listeneren ? En default installation har intet listener password sat - og mange sætter det aldrig - så her ville det være et godt sted at starte; Password til listeneren; Password til denne kan sættes på 2 måder;

1. via lsnrctl

2. i listener.ora filen

Passwordet skal være et stærkt et - dvs lad være med at benytte enkle passwords i produktions miljøer og minimum 8 karakterer. Listener servicen har ikke nogen form for password lockout dvs det er let at skrive en program der forsøger en 5.000 - 10.000 kombinationer uden at man bliver stoppet hele tiden.

Vær opmærksom har man læse rettighed til listener.ora kan password'et benyttes til remote login på listeneren. Apro po remote - Lad vær og administrer din listener remote - password sendes i klar tekst over netværket (replayable hash) så alle der sniffer på netværket kan opfange passwordet. Og får man nu fat i passwordet er det tit det også er benyttet andre steder til andre ting - så er det ud på opdagelse :)

Følgende kommandoer kan benyttes;

LSNRCTL> help, start, stop, quit, exit, status, set, show

Problemmet med listeneren er SET password og den videre administration - dvs der er ingen. Ingen password lockout, ingen expire, ingen auditering.

Buffer Overflow

Før vi kigger nærmere på buffer overflow i Oracle, skal vi kende betydningen af dette.

Programmer som listener og Oracle benytter sig at memory områder til at læse og skrive fra og til. Disse områder er sammenhængende; Når et program allokerer lad os sige 1000K og forsøger at skrive 1001K får vi et overflow og memory skrives steder, hvor andre data skulle have været skrevet. Det kræver lidt forsøg og tålmodighed at finde ud af hvilke programmer der reagerer, lad os sige, uhensigtsmæssigt - men for en hacker er det hele prossesen værd.

Overskrivning af stack pointeren er specielt farligt fordi det tillader hackeren at rediregerere eksekveringen af programmet. Det er meget normalt  for et buffer overflow i stack memory, at tillade hackeren at overskrive stack pointeren, og skrive operations kode til memory. Så når aktive eller nuværende funktion slutter retuneres eksekveringen til hackerens opcode.

Dette kan være ekstremt farligt når det data der skrives er fra ens eget netværk.

Hvordan finder en hacker så disse buffer overflow's ? Lad os prøve at kigge endnu engang på listeneren fra Oracle; En typisk streng til at opnå forbindelse kunne se ud som;

(DESCRIPTION=(CONNECT_DATA=(CID=(PROGRAM=)(HOST=)(USER=))(COMMAND=status)(SERVICE=LIST)(VERSION=135294976)))

En hacker ville nok typisk starte med at sende en rimelig mængde garbage data, som en del af forbindelses strengen. Hvis man f.eks sender en mængde garbage til USER= (et sikkerheds issue i 8.1) eller en mængde garbage til SERVICE= (et issue i 9i) er det vigitgt at udviklerene af listener programmet, når de har erklæret en 1024K buffer til at holde data, allokeres ikke yderligere ved mængder større end det ellers vil bufferen ende op i en overflow.

Programmer skal være intelligente nok til at genkende at der kun er allokeret 1024K og ikke forsøge at allokerer mere end det.

f.eks

(ERROR_STACK=(ERROR=(CODE=1153)(EMFI=4)(ARGS='(CONNECT_DATA=.)ervices))CONNECT_DATA=(SID=OAS10)(global_dbname=mot-2.dk)(CID=(PROGRAM=C:\Oracle\bin\sqlplus.exe)(HOST=mot-2)(USER=kbirch))')) (ERROR=(CODE=303)(EMFI=1))))

Der har været et antal sager for Oracle's listener program der faktisk lige præsis er af ovenstående karakter; Problemmet er at hvis du begynder intenst at manipulere ved disse ting, blotter Oracle sig og gør mærkelige ting og gør sig dermed sårbar.

Hvis du faker, størrelsen på de data pakker du sender vil listeneren, vil listeneren retunere - vilkårligt data den har i kommando bufferen, op til størrelsen på den buffer du sendte. Med andre ord; hvis forgående kommando fra en anden bruger er 100 karakterer lang og din retur værdi er 10 karakterer - så vil de første 10 karakterer blive overskrevet af listeneren, og der vil ikke korrekt blive null termineret på retur værdien. Så bliver listeneren forvirret og der foregår en eller anden form for streng kopiering, herfra retuneres dine 10 karakterer plus 90 karakterer af sidste kommando.

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\u01\oraclexe\app\oracle\product\10.2.0\server)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = CLRExtProc)
      (ORACLE_HOME = C:\u01\oraclexe\app\oracle\product\10.2.0\server)
      (PROGRAM = extproc)
    )
  )

Eksterne procedurer tillader at man kan lave funktioner der refererer eller kalder externe DLL filer, share libraries på operativ systemmet. Det er en stærk feature at lade databasen få kraft til at gøre hvad OS kan. I princippet kan der peges hvorsomhelst på et operativsystem til hvilken somhelst DLL der kan udføre OS kommandoer.

Hvordan er det lige extproc validerer brugere (authentication) ? DET GØR DEN IKKE!

WEB applikationer (SQL injection)

Kan angreb komme ind gennem ens firewall - JA! De fleste database administratorer mener de er sikre bagved en firewall i f.eks en DMZ zone. Selvom din firewall er top tunet - kan angrep nu sagtens forekomme - en hyppig årsag er gennem web applikationer. Dårlig kode fra udviklere er den typiske vej ind.

Hvor mange har skrevet en dynamisk SQL ved brug af execute immediate eller DBMS_SQL ? Har du prøvet det ?

Specielt i disse tider er der stor fokus på Oracle Application Server . og Oracle Portal - ethvert firma med respekt for sig selv kører en portal applikation (DONG, KE, IT og telestyrelsen m.fl).

SQL injection er en måde at angripe data i en database gennem den firewall der beskytter disse. Det er en metode gennem parametre til webapplikationer der benyttes og modificeres for at ændre de SQL udtryk der sendes til databasen og derved ved slut resultatet. Ved helt enkelt at tilføje f.eks et (') til en forespørgsel er det muligt at eksekverere en 2 forespørgsel mod databasen sammen med den første.

Kunne man tricke en SQL forespørgsel i en web applikation med en UNION og en SELECT * FROM DBA_USERS - ville man da være nået langt på kort tid ikke ?

Der er efterhånden mange måder/sprog der gør det muligt at angripe oracle systemmer her er nævnt et par stykker;

JSP, XML, Javascript, Portal (den gamle WEBDB og nyere og nyeste versioner), OCI, Pro*C, CGI og mange flere.

Hvilket somhelst af ovenstående kan være udgangspuntet for at lave SQL injection mod databasen; der skal dog først være følgende forudsætning;

- Dynamisk SQL (ellers er SQL injection ikke mulig)

En anden ting - et hvilket somhelst tool eller applikation udgør fare for SQL injection hvor dynamisk SQL benyttes og ikke KUN web applikationer. I disse dage er det dog nok der vi mest ser det idet mange efterhånden benytter internet m.v og det er den letteste måde at "shoppe" rundt på.

Her er det igen vigtigt at påpege at de fleste sikkerheds trussler kommer indenfra - fra brugere i f.eks et firma der kan læse data og af en eller anden årsag er ondsindet. Derfor kan det ikke påpeges nok at vigtige data skal sikres - der skal være en klar strategi i firmaet omkring data og så som disse vokser (og firmaet også).

SQLNET.log

Herlig fil - indeholder brugernavn, host forbindelse fra, hvornår etc. Har været ude på mange besøg hos kunder med produktion web sites i store hosting miljøer - hvor log filen ligger tilgængelig når du først er på netværket. Sansynlighed; Er den stor for f.eks en bruger indtaster password i username feltet ?  

Lad være med at placerere filen på web sitet - eller web serveren - lav ikke forbindelser fra web serveren - gør det fra en klient op mod serveren.

Populære sikkerheds brister

Well; brugerene SYSTEM, SYS, OUTLN, DBSMTP, SCOTT, MDSYS osv. Her er 2 tilfælde; 1. de ændres overhovedet ikke eller 2. SYS og SYSTEM har MANAGER som password.

Det er afhængigt af version og type af Oracle installation mht. hvilke defaulte konti der er på systemmet. Det anbefales at man tager sig tid til at kende sin Oracle installation.

En anden ting; Profiler i Oracle giver mulighed for management; lockout og expire - og bør overvejes i installationen.

Der findes på et Oracle system også en masse views - f.eks ALL_USERS - Du får ikke ligefrem password serveret - men for en ikke privilegeret konto - på udkig - får du ihvertfald en bunke brugernavne du kan undersøge nærmere.

PL/SQL

Næsten som med SQL injection kan du via PL/SQL tilføje udtryk til SQL med henblik på manipulation og at se poster du ikke har adgang til. Det er kun et problem når funktioner eksekveres med OWNER RIGHTS, ikke når en procedure udføres med INVOKER RIGHTS.

Der er 2 måder for at udføre dette; EXECUTE IMMEDIATE og DBMS_SQL.

CREATE PROCEDURE KBIRCH  ( NEW_PASSWORD VARCHAR2 ) AS TEST VARCHAR2;

BEGIN

EXECUTE IMMEDIATE 'UPDATE ' || TABLE_NAME || ' SET ' || COLUMN_NAME || ' = ''' || NEW_PASSWORD || '''‘ WHERE USERNAME= = ''' || CURRENT_USER_NAME || ''';

END KBIRCH;

EXEC KBIRCH( ‘testabc’ );

SQL der udføres 

UPDATE APPLICATION_USERS SET PASSWORD = ‘testabc’ WHERE USERNAME = ‘kbirch’

Dette er et eksemple på en rigtigt input. Det er eksekveret fra en OCI forbindelse over ODBC. Jeg opdaterer mit password i APPLICATION_USERS tabelen til testabc.

Lad os prøve som en der vil udføre noget andet med vores procedure;

EXEC KBIRCH ( ‘testabc’’, ADMIN=1, FULL_NAME=‘’TEST’ );

SQL der udføres

UPDATE APPLICATION_USERS SET PASSWORD = ‘testabc‘, ADMIN=1, FULL_NAME=’TEST’ WHERE USERNAME = ‘kbirch’

Læg mærke til jeg tilføjer '' til testabc passwordet. Jeg tilføjer et komma og sætter ADMIN=1 så jeg er administrator af applikationen - tilføjer en 3 kolonne og fyrer '' igen for at terminerer single quoten jeg startede med.

Det kræver selfølgelig lidt indsigt i miljøet man går efter - er det muligt ? Hertil må jeg svare Ja!

Konklusion

Der findes mange steder at finde "huller" vedr. sikkerhed. Og man bør i så vid udstrækning som det er muligt, grunlæggende kende og undersøge samt opdaterer og vedligeholde - sine miljøer.

Del 2 af disse sikkerheds poster omhandler - OS systemmet, Databasen og andre eksotiske ting

Be carefull outthere