Het artikel beoogt, met als leidraad de methodiek, de

Artikel

Methodiek voor preventieve, testgerichte beveiligingsaudits (penetratietesten) Een praktijkcasus (deel II) Maarten Veltman

In het eerste deel van Red-Green teaming bij Defensie (zie EDP-auditor 2007/2) is een methodiek geïntroduceerd voor het uitvoeren van een penetratietest. Dit tweede deel geeft aan de hand van een (fictieve) casus

Een korte terugblik op de methodiek (zie EDP auditor 2007/2) Een penetratietest is een techniek die getroffen beveiligingsmaatregelen voor ICT-middelen onderwerpt aan uitgebreide beveiligingstests, uitgevoerd vanuit een perspectief van risicobeheersing.

een praktische invulling aan een dergelijk onderzoek en

Deze tests verschaffen inzicht in de kwaliteit van de feitelijke

de daarmee samenhangende onderzoeksactiviteiten.

inrichting van een ICT-middel of samenstel daarvan. Het testen

Relevante aandachtspunten, leermomenten en aanbevelingen zijn opgenomen.

vindt plaats door de aanwezigheid van indringers en hieraan gekoppelde activiteiten in de (ICT-)omgeving te simuleren. In de uitvoering worden hiertoe methoden, technieken en middelen gehanteerd die binnen de hackergemeenschap gemeengoed zijn. Het vorige artikel licht een methodiek toe waarmee op gestructureerde en beheerste wijze invulling gegeven kan worden aan een penetratietestingonderzoek. De methodiek bestaat uit een vijftal fasen: 1. Formuleren opdracht 2. Opstellen plan van aanpak 3. Voorbereiding penetratietest 4. Uitvoering penetratietest 5. Afronding Servers, werkstations, netwerkapparatuur en applicaties vormen bij een penetratietest het voornaamste object van onderzoek. Onderzoeksactiviteiten zijn doorgaans dan ook op deze objecten gericht. Zoals beschreven in het eerste artikel kunnen middels een penetratietest eveneens de effecten op minder harde materie zoals het gedrag en handelwijze van mensen waargenomen worden. Of en zo ja, in welke mate deze objecten in het onderzoek betrokken worden, hangt af van de gestelde onderzoeksvraag.

H

et artikel beoogt, met als leidraad de methodiek, de toegevoegde waarde van de penetratietestingtechniek voor een IT-auditor te illustreren. Aan de hand van een casus worden aandachtspunten en leermomenten tijdens het doorlopen van dit proces, toegelicht. De IT-auditor kan, indien juist toegepast, met deze kennis en inzicht ook zijn of haar voordeel behalen in standaard IT-audits naar zowel opzet als bestaan. Ing. M. (Maarten) Veltman RE is sinds 2000 werkzaam bij het ministerie van Defensie als senior IT-auditor bij de Audit Dienst Defensie (ADD).

Aan de hand van een casus doorloopt het voorliggende artikel de diverse fasen en stappen binnen de methodiek. Dit artikel legt de nadruk op de uitvoeringsfase (fase 4). De uit-

10 | de EDP-Auditor nummer 3 | 2008

voeringsfase maakt aan de hand van concrete onderzoeksactiviteiten het gedachtegoed en werkwijze van een penetratietest inzichtelijk. Deze fase bestaat zoals in het eerste artikel beschreven uit een drietal stappen: a. informatievergaring; b. analyseren en c. ondernemen van vervolgstappen. Het doorlopen van deze stappen is een iteratief proces, wat inherent is aan een blackboxbenadering. Het is voor de auditor onmogelijk alle onderzoeksactiviteiten vooraf tot in detail uit te werken. De aandacht voor de uitvoeringsfase (fase 4) laat onverlet dat de afstemming met de opdrachtgever (stap 1), het uitwerken van een plan van aanpak (stap 2) en de voorbereidende werkzaamheden voor de penetratietest (stap 3) uitermate belangrijk zijn en de basis vormen voor het juist kunnen uitvoeren (stap 4) van de penetratietest.

Casusbeschrijving De gestelde onderzoeksvraag is gerelateerd aan een tijdregistratieinformatiesysteem op een intern bedrijfsnetwerk. De opdrachtgever wil vastgesteld hebben of sprake is van een toereikende logische toegangsbeveiliging waarbij alleen daartoe geautoriseerde bedrijfsmedewerkers toegang kunnen krijgen tot het informatie-

In het kader van de voorbereidingen zijn nog enkele specifieke aandachtspunten ten aanzien van de inzet, gebruik en inrichting van technische hulpmiddelen noemenswaardig. Als onderdeel van de kwaliteitsborging enerzijds en reproduceerbaarheid anderzijds is het van belang dat vanaf het moment dat (technische) onderzoeksactiviteiten starten een registratie van de uitgevoerde activiteiten plaatsvindt. Deze registratie kan uiteenlopen van een eenvoudige schriftelijke notitie onder vermelding van de activiteit, datum en tijdstip; tot een volledige integrale geautomatiseerde vastlegging van alle handelingen die het red team uitvoert vanaf de ingezette hulpmiddelen. Deze laatste variant vereist natuurlijk wel de benodigde hulpmiddelen (b.v. het vastleggen van toetsaanslagen en beeldscherminformatie of het registreren van al het netwerkverkeer). Verder is van belang dat de werking van alle middelen (tooling) uitgebreid getest is (in een testomgeving), voordat het team deze inzet in een productieomgeving. Deze tests moeten niet uitsluitend gericht zijn op het uitsluiten van de aanwezigheid van eventuele virussen of trojan horses, maar eveneens op mogelijke onnodige features c.q. eigenaardigheden en de keuze voor de juiste instellingen van een tool. Het vooraf testen voorkomt in belangrijke mate onverwachte, en daarmee ongewenste, effecten bij de inzet van de tool.

systeem en de daarop aanwezige gegevens. Het uitgangspunt voor het onderzoek is een blackboxbenadering. Dit betekent dat bij aanvang van het onderzoek geen informatie beschikbaar is over de samenstelling en technische inrichting van het informatiesysteem. Er wordt voor het onderzoek een intern profiel met beperkte rechten aangemeten. In de casus betekent dit dat het team beschikt over een geautoriseerd werkstation en toegang tot het kantoorautomatiseringnetwerk. Daarbij is sprake van een red team opdracht. Bij een dergelijke opdracht zijn de direct voor het informatiesysteem verantwoordelijken (eigenaar, functioneel en/of technisch beheer) niet op de hoogte gesteld van de uitvoering van het onderzoek.

Fase 1 - 3: Voorbereiding onderzoek De voorbereidende fasen en activiteiten hebben hoofdzakelijk betrekking op projectmatige aspecten. Zo zijn in de methodiek onder meer activiteiten onderkend voor het formuleren, uitwerken en formaliseren van de onderzoeksopdracht, hieraan gerelateerde onderzoeksvragen en de samenstelling van een onderzoeksteam. Naast de vastlegging van deze generieke projectmatige aspecten stelt de projectleider van het onderzoeksteam op aangeven van de opdrachtgever ook specifieke aan penetratietesting gerelateerde uitgangspunten voor het onderzoek vast. Het betreft hier bijvoorbeeld de vaststelling van het te hanteren profiel, scenario en daarmee de kleur van het team (redteam versus green team; zie hiertoe tevens toelichting bij de casus beschrijving).

Voordat het red team eigen apparatuur, zoals een laptop of werkstation, inzet, is het verstandig een aantal voorzorgsmaatregelen te treffen, waaronder: • het systeem zodanig inrichten dat het zich zo passief mogelijk gedraagt op het netwerk. Met behulp van bijvoorbeeld een netwerksniffer kan het passieve gedrag gecontroleerd worden; • het uitschakelen van onnodige (netwerk)services teneinde eventuele kwetsbaarheid van het systeem zelf te beperken en de passieve werking van het systeem te benaderen; • het installeren van de meest recente (beveiligings)patches teneinde de kwetsbaarheid van het platform en aanwezige applicaties te beperken; • het overnemen van het hardware adres (MAC-adres) van een geautoriseerd werkstation en aansluiten op dezelfde netwerkpoort, teneinde eventueel aanwezige netwerkbeveiliging te omzeilen. Uiteraard moet de inzet van eigen middelen overeen komen met het gekozen scenario en profiel en bijdragen aan de beantwoording van de onderzoeksvraag. Fase 4 : Uitvoering penetratietest onderzoek Bij aanvang van deze penetratietest is alleen de informatie beschikbaar uit de voorbereidingsfase. Het team start dan ook met activiteiten die gericht zijn op een nadere informatievergaring (stap 4a).


Uitgangspunt van alle activiteiten die in dit kader ondernomen worden, is dat deze bijdraagt aan de beantwoording van de onderzoeksvraag en aansluit op de onderzoeksdoelstelling. Stap 4a : Informatievergaring

Het startpunt in de uitvoering van elke penetratietest is de stap informatievergaring. De stap is gericht op een verkenning van het onderzoeksobject en de omgeving daarvan. Vooraf gedefinieerde activiteiten (onderdeel van stap 3) geven een initiële invulling aan deze stap. Het team start met een passieve vorm van informatievergaring. In dit stadium (start) is het doel met zo min mogelijk ruchtbaarheid zoveel mogelijk gegevens te verzamelen waaruit bijvoorbeeld afgeleid kan worden: • de eigenschappen van het informatiesysteem, waaronder omvang, (technische) samenstelling en afhankelijkheden; • locaties (zowel fysiek als technisch op het netwerk); • beheerverantwoordelijken, betrokken afdelingen en personen. Het scenario start met het gebruik van de standaard beschikbare (geautoriseerde) werkplek (in de casus: Microsoft Windows) en daarop aanwezige hulpmiddelen zoals Internet Explorer en commando prompt (met DOS tools zoals ping en nslookup). Het gebruik van een afwijkend werkstation of afwijkende tooling kan namelijk mogelijk gedetecteerd worden door de beheerorganisatie. Dit zou een voortijdig einde van het onderzoek kunnen betekenen, wat overigens zowel positief als negatief uitgelegd kan worden. Stap 4a: Informatievergaring -> Activiteit 1: Initiële informatievergaring omgeving

Een interessante en voor de hand liggende informatiebron om mee te starten, vormen de aanwezige intranet websites (bijvoorbeeld startpagina’s, portals) en de daarop beschikbare zoekfunctionaliteit. Bij grote ondernemingen zijn vaak diverse zoeksystemen (search engines) aanwezig die lang niet allemaal hetzelfde of op dezelfde manier indexeren. Betrek deze dan ook in het onderzoek.

dan ligt het voor de hand ook de websites van deze afdelingen te raadplegen. Mogelijk is sprake van een externe partij of systeemintegrator die betrokken is (of is geweest) bij ondersteuning of ontwikkeling. Een bezoek aan de Internet website van deze externe partij levert mogelijk nog aanvullende informatie op; • Een andere informatieve bron kan een geplaatste vacaturetekst zijn. Zo kan dit, zonder dat men zich dit realiseert, bruikbare informatie opleveren (denk aan gevraagde noodzakelijke kennis of technische opleidingen). • Het team kan systeemeigenschappen, afdelingen of betrokken personen uit de eerste informatieanalyse op Internet als sleutelwoorden googlen. Zo kan het voorkomen dat een systeembeheerder op Internet een oplossing voor een opgetreden probleem zoekt op een gebruikersforum op Internet, wat weer kan leiden tot nieuwe informatie binnen het onderzoek. De bovenstaande voorbeelden illustreren dat het succes voor het verkrijgen van bruikbare informatie mede bepaald wordt door de creativiteit van de leden van het red team. Stap 4b: Analyse informatie uit activiteit 1

Op basis van de verzamelde informatie kunnen met het nodige voorbehoud eerste voorzichtige conclusies getrokken en aanbevelingen gedaan worden. Een voorbehoud is hierbij op zijn plaats. Naar de achtergrond of bron van deze waargenomen effecten gist het team in dit stadium namelijk nog. Zo kan het in de onderstaande aanbeveling zijn dat in opzet toereikende procedures aanwezig zijn voor het screenen van informatie voordat een organisatie deze op een Internet site plaatst terwijl in bestaan/werking hieraan (op basis van waarneming) een ontoereikende invulling gegeven wordt.

Mogelijke aanbevelingen 1) Draag zorg dat alle publieke informatie zorgvuldig gescreend wordt voordat deze gepubliceerd wordt. 2) Draag zorg voor een beveiligingsbewustwording programma waarvan gedrag en uitlatingen op Internet/Intranet een onderdeel vormen.

Bij het gebruik van zoeksystemen en websites ten behoeve van de stap informatievergaring kan gedacht worden aan het volgende: • Maak gebruik van de bekende (beperkte) beschikbare informatie als zoekterm zoals de naam van het informatiesysteem of functionaliteit; dit kan leiden tot nieuwe informatie. Zo is het mogelijk dat de naam van het informatiesysteem terugkomt in een informatiebulletin, nieuwsbrief of een (gebruikers)forum; • Ook gepubliceerde pagina’s met incident- of storingsmeldingen kunnen interessante informatie opleveren, zoals verwijzingen naar logische systeemnamen; • Als binnen de organisatie duidelijk is (of in de lijn van de verwachting ligt) welke afdeling verantwoordelijk is voor het beheer en/of inrichting van het informatiesysteem

Het is mogelijk om aanbevelingen tijdens de uitvoering van het onderzoek bij te stellen. Bij de eindrapportage zal aanscherping plaats moeten vinden. Het voorleggen van onderzoeksresultaten aan de systeemeigenaar speelt daarbij een belangrijke rol. Dit doet overigens niets af aan het waargenomen effect in bestaan. Stap 4a: Informatievergaring -> Activiteit 2: Systeem identificatie

Om gerichter onderzoek te kunnen uitvoeren is het van belang dat het team ten minste één systeem identificeert dat te relateren is aan het object van onderzoek. Een mogelijke ingang voor het verkrijgen van een, in technische zin, adresseerbaar systeem is het bevragen van de


bedrijfsinterne DNS (Domain Name Service) of WINS server. Deze servers dragen zorg voor de vertaling van een logische naam (bijvoorbeeld organisatie.nl) naar een IP-adres en visa versa. Het team kan proberen een kopie van (delen van) de DNS database te verkrijgen. In DNS terminologie is dit bekend als een DNS zone transfer. Als deze niet goed is afgeschermd, is het voordeel dat zonder de doelsystemen zelf te benaderen, kennisgenomen wordt van de naamgeving en IP-adresgegevens van de in het netwerk aanwezige systemen. Op basis van de naam kan dan mogelijk een aanknopingspunt gevonden worden. Let wel dat het uitvoeren van een DNS zone transfer gedetecteerd kan worden en binnen de organisatie mogelijk als incident wordt beschouwd. Als het DNS register afgeschermd is voor een zone transfer, bestaat nog de mogelijkheid om, al dan niet handmatig, systeemnamen te raden. Hierbij gebruik makend van de eerder ingewonnen informatie.

informatie ook het noodzakelijke inzicht voor de diverse logische toegangspaden tot dit systeem. Bij een poortscan wordt via het netwerk contact gelegd met alle (of specifieke) TCP en/of UDP poorten van een systeem. Het succesvol opzetten van een verbinding betekent dat een service luistert op de aangesproken poort. Aangezien doorgaans sprake is van standaard service-poorttoewijzingen (zie [IANA] voor overzicht standaard poortnummertoewijzingen) kan eenvoudig een eerste indruk opgedaan worden van de eigenschappen van het systeem. In figuur 1 is het resultaat opgenomen van een standaard TCP SYN poortscan uitgevoerd met het hulpmiddel NMAP [NMAP] van alle TCP poorten tussen de 1 en 65535 op het geïdentificeerde systeem met het IP-adres 10.0.0.100.

Een andere mogelijkheid is het uitvoeren van een netwerkscan, waarbij alle mogelijke adressen binnen een netwerkdomein aangesproken worden. In potentie levert dit meer netwerkverkeer op en is de kans groter dat activiteiten gedetecteerd worden (bijvoorbeeld door een aanwezige firewall).

HTTP

In de casus is, door de voorspelbare naamgeving van het systeem, aan de hand van de DNS een systeemnaam geïdentificeerd. Het betreft de systeemnaam urenreg.company.nl, dat zich vertaalt naar: Oracle Listener

> nslookup urenreg.company.nl Server: dns.company.nl Address: 10.1.1.111 Non-authoritative answer:

HTTP server (secure)

Name: w2k.company.nl

HTTP server

Address: 10.0.0.100

<= IP-adres als aanknopingspunt

Aliases: urenreg.company.nl Figuur 1: Resultaten van een TCP poortscan met NMAP.

Stap 4a: Informatievergaring -> Activiteit 3: Systeemeigenschappen identificatie

Nu een IP-adres/DNS naam bekend is, kan geprobeerd worden of het adres bereikbaar is. Middels een ping (icmprequest) of traceroute wordt bekeken of het systeem antwoordt. Het niet bereikbaar zijn van het systeem kan wijzen op een aanwezige netwerkbeveiligingsmaatregel op het communicatiepad naar het systeem toe. Een voorbeeld is een aanwezige netwerk firewall of host-beveiliging. In de casus is het systeem niet nader afgeschermd door een netwerk firewall.

Stap 4b : Analyseren informatie uit activiteit 3

Een standaardtechniek voor het verkrijgen van systeemeigenschappen (en daarmee ook een indruk van de functie/ toepassing van een systeem) is het uitvoeren van een zogenaamde IP poortscan. In het kader van de casus vormt deze

In de casus blijkt na analyse van de poortscan (zie figuur 1) dat sprake is van o.a.: - een Microsoft Windows platform. Dit is af te leiden door de combinatie van aanwezige netwerkpoorten 135, 139,

In stap 4b vindt analyse en interpretatie plaats van de informatie die tijdens de verkenning (stap 4a) verzameld is. De stappen informatievergaring en analyseren worden iteratief toegepast. Een nieuw brokje informatie wordt geanalyseerd en leidt tot nieuwe onderzoeksactiviteiten dat weer kan leiden tot nieuwe informatie, dat weer geanalyseerd wordt, et cetera.


Oracle toegepaste netwerkpoorten is bijvoorbeeld vastgelegd in [MLN99721.1], [MLN235298.1]

445 en 3389. Overigens kan door gebruik te maken van andere opties in de gebruikte tool ook een voorspelling gedaan worden over de versie van het platform; - de aanwezigheid van een Oracle listener op de standaard Oracle listener poort 1521. Dit duidt er op dat het systeem als DBMS is ingericht. In figuur 1 is, na analyse, een aantal poorten gearceerd die toebehoren tot de Oracle inrichting.

Stap 4c : Ondernemen vervolgstappen en activiteiten

Het team brengt op basis van de geanalyseerde informatie mogelijke aanknopingspunten en vervolgactiviteiten alvast in kaart. In figuur 2 zijn deze aanknopingspunten in een schets afgebeeld.

De poortscan geeft vervolgens nog nadere informatie over de aanwezigheid van andere (netwerk)applicaties. Elke aanwezige service, luisterend op een poort, kan nader aan de tand gevoeld worden en daarmee in potentie gebruikt worden in de stap informatievergaring.

Gelet op de onderzoeksdoelstelling en vraag is na de analyse besloten om de aandacht in eerste instantie te richten op de aanwezige Oracle database. Er worden nu nieuwe onderzoeksactiviteiten uitgewerkt die gericht zijn op informatievergaring van de eigenschappen van de Oracle database inrichting. In de onderstaande beschrijving volgen de stappen informatievergaring, analyse en het ondernemen van vervolgstappen/activiteiten elkaar op.

De aanwezigheid van poort 1521 geeft op basis van de uitgevoerde poortscan geen garantie dat het hier ook een Oracle listener poort betreft. De toewijzing van poorten aan services kan namelijk handmatig gewijzigd worden. Om meer zekerheid te krijgen of deze poort in dit geval daadwerkelijk gebruikt wordt door Oracle kunnen andere tools ingezet worden. Een voorbeeld van een dergelijke tool is THC-AMAP [AMAP], dat beschikt over een zogenaamde fingerprint database waarmee met een redelijke mate van zekerheid vastgesteld kan worden welke applicatie en eventueel welke versie op de poort luistert.

Stap 4a: Informatievergaring -> Activiteit 4: Achterhalen database eigenschappen

Een voorname bron van informatie voor de eigenschappen van een Oracle DBMS vormt de Oracle listener. Aan de hand van de TCP poortscan (zie figuur 1) is de aanwezigheid van de Oracle listener en de poort 1521 waarop deze luistert, vastgesteld. Zaak is middels het juiste protocol (TNS) een verbinding met de Oracle listener op te zetten zodat informatie omtrent de inrichting van de Oracle database verkregen kan worden. Een eenvoudig Perl programma

Ook de aanwezigheid van een combinatie van poorten kan duiden op een specifieke toepassing. Een overzicht van door

Brute-force? Default account/pw?

Privilege escalation? PlsExtProc?

Injection?

Oracle listener SID? Security?

Client Attack?

DBMS Oracle

Database links? Brug naar OS

HTTP server Inhoud? Versie webserver?

FTP anoniem? FTP versie

Platform Windows 2000/XP/2003?

Active directory Info?

Bekende fouten? SMTP VRFY? SMTP DEBUG? SMTP versie

RPC endpoints? vertrouwensrelatie?

NetBIOS Share’s? User Enum?

DNS Zone transfer? OS ﬁngerprint

Figuur 2: schets van mogelijke aanknopingspunten en vervolgactiviteiten.


[TNSCMD] dat specifiek voor dit doeleinde ontwikkeld is, kan hiertoe ingezet worden. Uiteraard kan het team ook gebruik maken van de standaard SQL*PLUS client van Oracle (200 MB installatie). De inzet van het Perl script op de database levert de in figuur 3 afgebeelde informatie op.

instances (SID’s) aanwezig zijn. In het voorbeeld is alleen de instance GLOBDB aanwezig; • Tevens blijkt dat de ExtProc procedure (zie SERVICE_ NAME=PLSExtProc) actief is. Bekend is dat PLSExtProc misbruikt kan worden om commando’s op besturingssysteemniveau uit te voeren. Dit zal niet nader in dit artikel uitgewerkt worden. Voor achtergrondinformatie zie [ORASEC57].

Stap 4b : Analyse informatie uit activiteit 4

Aan de hand van de output van het TNS statuscommando (zie figuur 3) leidt het team onder meer het volgende af: • indicatie van merk en type platform waarop de database geïnstalleerd is (zie VERSION veld); • de versie van de Oracle database (9.2.0.1.0) (zie VERSION veld); • de locatie/pad waar de listener logfile zich bevindt (zie LOGFILE veld); • De uptime (zie UPTIME veld). De uptime kan behulpzaam zijn om bijvoorbeeld in te schatten of patches/ updates geïnstalleerd zijn. Voor het installeren van een patch zal namelijk de database tijdelijk gestopt moeten worden (en daarmee dus ook de uptime). Een uptime van een half jaar kan er op wijzen dat patches tenminste een half jaar niet geïnstalleerd zijn. • Security opties zijn uitgeschakeld (zie SECURITY=OFF) – geen listener security, geen admin restrictions. Hierdoor kunnen wijzigingsopdrachten (SET) aan de listener verstrekt worden. Tevens kan dit in combinatie met het ontbreken van een listener wachtwoord misbruikt worden om de database op afstand te stoppen. • Security Identifier (zie SERVICE_NAME=GLOBDB). Een belangrijke eigenschap van de Oracle listener is de zogenaamde SID. Zonder deze SID (Security Identifier) kan geen succesvolle verbinding met de Oracle DBMS opgezet worden. Er kunnen overigens meerdere database

Op basis van de bovenstaande waarnemingen (en analyse daarvan) kunnen de volgende aanbevelingen gedaan worden om risico’s te beperken.

Mogelijke aanbevelingen 1) Scherm de toegang tot de listener af met een wachtwoord.1 2) Stel ADMIN_RESTRICTIONS in op de Listener [MLN272633.1] 3) Gebruik moeilijk te voorspellen namen voor de SIDs. 4) Als dit niet nodig is, maak geen gebruik van PLSExtProc. Zo nodig maak gebruik van valid node checking. Draag op een Windows platform er voor zorg dat het proces niet als SYSTEM actief is.

Elke toegang tot de listener en pogingen daartoe worden overigens geregistreerd in de listener.log. Een oplettende beheerder zal deze registraties herkennen als afwijkend gedrag. In de praktijk worden logfiles van de listener vaak niet geanalyseerd. In het kader op de volgende pagina is een voorbeeld van de registratie in de listener.log opgenomen bij gebruik van Oscanner (deze tool wordt verderop in het artikel nog besproken) en bij gebruik van de standaard Oracle SQL*PLUS client. Wat hieraan direct opvalt is dat bij gebruik van SQL*PLUS veel meer gebruiksinformatie geregistreerd wordt dan de JDBC koppeling waarvan Oscanner gebruik maakt. De

Figuur 3: Deel van de informatie verkregen via de Oracle TNS listener (status commando)


SQL*PLUS client stuurt standaard namelijk het complete pad, hostnaam en gebruikersnaam mee. Dit biedt ook weer mogelijkheden door bewust deze gegevens te manipuleren zodanig dat dit overeenkomt met de gebruikelijke registraties op het systeem, teneinde bemerking van activiteiten van het team te bemoeilijken. Stap 4a : Informatievergaring -> Activiteit 5: default Oracle account/wachtwoord

Tijdens reguliere systeem IT-audits is een van de standaardonderdelen te onderzoeken hoe het gesteld is met de wachtwoord policy, opslag en distributie van wachtwoorden. Bij een penetratietest is die aandacht daarvoor nog nadrukkelijker. Als dit mechanisme verkeerd ingericht of toegepast wordt, vormt het de meest eenvoudige toegang tot een informatiesysteem en in dit geval de database. Een bekend gegeven van Oracle databases is dat eenmaal binnen (ook met minimale rechten) diverse mogelijkheden bestaan om rechten binnen de database en op het systeem op te waarderen (Engels: Privilege Escalation). Het slagingspercentage daarvan neemt met name toe op het moment dat patches niet of niet tijdig geïnstalleerd worden. Nu de SID (GLOBDB) bekend is uit de analyse van activiteit 4 kan de Oracle database instance rechtstreeks aangesproken worden. Het team start met het controleren of de Oracle database uitgerust is met default gebruikersnaam/ wachtwoordcombinaties. Binnen de Oracle DBMS omgeving en al haar deelapplicaties en verschillende versies, bestaan een groot aantal (honderden) default gebruikersnaam/wachtwoordcombinaties [FINNIGAN],[VULASS],[MLN160861.1]. Ter nuancering: in de praktijk wordt nooit een database aangetroffen waar al deze accounts terugkomen, hooguit een handvol. Met name bij oudere versies van Oracle is vaak sprake van krachtige accounts met standaardwachtwoorden. Een van de redenen hiervoor is dat tijdens installatie tot en met Oracle versie 8 niet afgedwongen wordt dat het wachtwoord van het sys en system account gewijzigd wordt van de standaardwaarde. Oracle geeft namelijk een standaard voorzet, terwijl bij recentere Oracle versies de gebruiker zelf een wachtwoord moet opgeven. In deze fase van het onderzoek is het zaak dat het team alleen op de aanwezigheid van default combinaties controleert en niet dat het op een brute-force basis, alle mogelijke

wachtwoord combinaties, probeert om toegang te verschaffen. Het risico is namelijk dat accounts blokkeren doordat het maximale aantal toegestane inlogpogingen bereikt is. Bovendien is op dit moment nog niet duidelijk welke accounts aanwezig zijn. Het controleren op de aanwezigheid van default account/ wachtwoordcombinaties kan met behulp van verschillende tools. Allereerst handmatig door zelf aan te loggen met een SQL client (bijv. SQL*PLUS). Daarnaast bestaan er verschillende tools (al dan niet commercieel) waarmee de aanwezigheid van default wachtwoorden geautomatiseerd vastgesteld kan worden. Voorbeelden van vrij verkrijgbare tools die zich richten op de default account/wachtwoordcombinaties zijn: • Oracle Auditing Tool (OAT) [OAT] (commandline, op Java/JDBC gebaseerd); • OracSec [ORASEC] (GUI) en • Oscanner [OSCAN] (Java gebaseerd). In de casus wordt deze tool ingezet. Oscanner voert standaard meer uit dan alleen een default wachtwoordcontrole. Middels een plugin bestand (oracleplugins.default) wordt aangegeven welke controles uitgevoerd moeten worden. Verstandig is om de eerste poging te beperken tot de EnumerateSIDS en CheckCommonPasswords plugin. Het bestand accounts.default waarin de default account/wachtwoordcombinaties zijn vastgelegd, kan aangevuld worden met de eerder genoemde default account overzichten. In figuur 4 is de output van de tool Oscanner vastgelegd. Het team start met het uitlezen van de SIDS. Dit is feitelijk een selectie van de output van het TNS status commando. Vervolgens wordt met de bekende default accounts ingelogd totdat een eerste hit ontstaat. In de casus is dit het account dbsnmp met het default wachtwoord dbsnmp (zie figuur 4). Nu dit succesvol is, logt oscanner met het dbsnmp account in en laat een database query op de Oracle account database los (select username from all_users) om zodoende de aanwezige accounts binnen de Oracle instance op te vragen (zie groen gearceerde tekst). Vervolgens probeert het tool alleen die accounts die ook daadwerkelijk aanwezig zijn. Bij het gebruik van de tool is het aan te bevelen om de verbose optie van deze tool te gebruiken. Dit is overigens niet in figuur 4 gebruikt. Met de verbose optie wordt namelijk ook duidelijk welke accounts wel geprobeerd zijn, maar waarvan het wachtwoord niet default is.


Stap 4b : Analyse -> Bevindingen activiteit 5 (default accounts)

Het resultaat van de inzet van de tool op de database is de vastgestelde aanwezigheid van twee default valide gebruikersnaam/wachtwoordcombinaties waarmee aangemeld kan worden op de database.

Stap 4a: Informatievergaring -> Activiteit 6: Aanwezigheid zwakke wachtwoorden

Naast het proberen van default gebruikersnaam/wachtwoord combinaties kan ook geprobeerd worden in te loggen met voorspelbare wachtwoorden (bijvoorbeeld uit een woordenboek) of middels brute-force (alle mogelijke combinaties). De ervaring leert dat een woordenboekaanval met name bij gebruikersaccounts succesvol kan zijn. In dat geval moet wel eerst bekend zijn welke gebruikersaccounts op de Oracle database aanwezig zijn. Aangezien veelvuldig geprobeerd wordt in te loggen met een account brengt een dergelijke aanpak ook risico’s met zich mee. De kans bestaat dat een blokkade van een account optreedt, doordat men het maximaal aantal foutieve inlogpogingen overschrijdt. Het blokkeren van het SYS account is overigens niet mogelijk [MLN225529.1]. Daarnaast worden toegangspogingen ook geregistreerd in logbestanden, zodat de kans bestaat dat de penetratietestactiviteiten in een vroegtijdig stadium ontdekt worden.

Figuur 4: Resultaten Oscanner tool default account-wachtwoord combinaties

Overigens heeft Oracle zelf ook een Default password controle tool uitgebracht [MLN361482.1] met daarin bijna 700 default gebruikersnaam/wachtwoordcombinaties. De tool van Oracle is alleen beschikbaar via Metalink (account nodig). De tool is uitgevoerd als SQL script, dat met hoge rechten geactiveerd moet worden. Het script vergelijkt de output van opgehaalde Oracle hashes (select username, password from sys.dba_users) met de bekende door Oracle in het script vastgelegde hashes. Als deze overeenkomen is duidelijk dat het een default wachtwoord betreft. Oracle heeft zelf niet (integraal) de ontcijferde (klare tekst) wachtwoorden gepubliceerd. Voor de werking van de Oracle tool is dit namelijk ook niet nodig. Een belangrijke beperking van de door Oracle geleverde tool in het licht van de inzet voor een penetratietest is dat men al beschikt over hoge rechten om de hash-waarden van de wachtwoorden in de database uit te mogen lezen. Een andere beperking is dat deze controle niets zegt over het gebruik van een zwak wachtwoord (niet zijnde default). Overigens staan (op een enkele na) alle wachtwoorden waarop de Oracle tool controleert reeds in de eerder genoemde wachtwoordlijsten op Internet. De aanwezigheid van een default account lijkt een open deur maar blijkt in de praktijk veelvuldig voor te komen. Een voor de hand liggende aanbeveling is dan ook de volgende aanbeveling:

Aanbeveling Wachtwoorden moeten gewijzigd worden van hun standaardwaarde.

Door het blokkeren van een account kan overigens wel achterhaald worden of en zo ja wat de password policy voor wat betreft het maximale aantal toegangspogingen is. Het is in dat geval verstandig om dit bij een regulier gebruikersaccount te proberen. Het blokkeren van service en systeem accounts leidt mogelijk tot problemen in een productieomgeving. Deze activiteit is niet nader in de casus uitgewerkt, aangezien het idee daarachter voor zich spreekt. Stap 4c: Ondernemen vervolgstappen

In de casus is vastgesteld dat sprake is van twee accounts die uitgerust zijn met het bijbehorende default wachtwoord. Deze accounts beschikken over beperkte rechten binnen de Oracle omgeving. Het nieuw te stellen doel is met behulp van deze accounts hogere rechten binnen de Oracle omgeving te verkrijgen. Om dat doel te bereiken zijn vervolgactiviteiten nodig. Ook hier wordt op basis van de nu bekende informatie, vooronderzoek, kennis en ervaring een initiële inschatting gemaakt van de mogelijkheden. Het ligt voor de hand te starten met relatief eenvoudig uit te voeren aanvalstechnieken gericht op bekende kwetsbaarheden met een grote impact. Het voorliggende artikel beschrijft als voorbeeld een tweetal vervolgstappen welke beide kunnen leiden tot verkrijgen van toegang met hoge rechten op de database. Het betreft hier twee activiteiten gericht op het binnendringen in een informatiesysteem (activiteiten 7 en 8) die geen onderdeel vormen van de stappen informatievergaring (stap 4a) of analyse (stap 4b).


Figuur 5: Rol toewijzing gebruiker SCOTT voor de aanval.

Figuur 6: Deel van Oracle client netwerksessie met bewuste alter

Figuur 8: Deel van Oracle client netwerksessie waarin aangepast

session SQL commando.

SQL commando verstuurd wordt.

De gebruiker SCOTT (met defaultwachtwoord TIGER) beschikt over de volgende privileges.

Figuur 7: Aanpassing van SQL commando in Oracle client sturingsprogramma.

Stap 4c: Vervolgactiviteit -> Activiteit 7: Oracle client aanval

Een relatief eenvoudig uit te voeren aanval met in potentie een grote impact is de Oracle Access Control Bypass in Login kwetsbaarheid [IMPERVA]. De aanval is gericht op een kwetsbaarheid in het login authenticatieproces als onderdeel van het TNS protocol. De technische achtergrond van de kwetsbaarheid is dat gedurende het inlogproces SQL commando’s (ALTER SESSION) uitgevoerd worden voor het instellen van de sessie-attributen. Dit SQL commando wordt echter niet uitgevoerd met de rechten van de gebruiker die zich aanmeldt, maar met de hoge rechten van de SYS database gebruiker. Dit gegeven in combinatie met de mogelijkheid het SQL commando aan de clientzijde aan te passen, leidt tot grote risico’s. Randvoorwaarde, naast dat de database hiervoor nog niet gepatched is, is de beschikking over een geldig database account/wachtwoord met minimale rechten (create session). In de casus is bij activiteit 5 de aanwezigheid van twee accounts met een defaultwachtwoord vastgesteld. Deze accounts worden in de onderstaande uitwerking gebruikt.

Het concept achter de aanval is om tijdens het authenticatieproces het ALTER SESSION commando te vervangen door een eigen commando. In de casus is dit een commando waarmee database beheer (DBA) rechten toegekend worden aan het gevonden SCOTT account. Er zijn verschillende manieren om misbruik te maken van deze kwetsbaarheid [ADP], [OAK]. De eenvoudigste manier is het aanpassen van de binaire bestanden van de Oracle client. Met behulp van een netwerksniffer (b.v. Wireshark, http:// www.wireshark.com) kan de communicatie tussen de Oracle client (SQL*PLUS) en de Oracle database server afgeluisterd worden. In figuur 6 is de bewuste ALTER SESSION SQL statement tijdens het (reguliere) inlogproces gearceerd weergegeven. De Oracle client verstuurt deze opdracht. Dit betekent dat de feitelijke samenstelling van deze opdracht gezocht moet worden aan de cliëntzijde. Het doorzoeken van de Oracle client binaries (in dit geval Windows) levert in één van de ondersteunende DLL’s diverse hits op (zie arcering in figuur 7). Met behulp van een binaire editor (hexedit) vervangen we vervolgens alle ALTER SESSION SET statements door een andere opdracht. In het geval van de penetratie test vervangt het team de opdracht door GRANT DBA TO SCOTT.

Figuur 9: Rol toewijzing gebruiker SCOTT na aanval.


Na aanpassing van de client software stuurt deze tijdens het opstarten en aanmelden op de database het gewenste commando en voert dit op de database uit met SYS rechten (zie figuur 8).

dat elke geauthenticeerde database gebruiker willekeurige SQL commando’s kan uitvoeren met de rechten van een database beheerder (DBA). Zie tevens [DRILOAD], [ALERT68].

Na het terugbrengen van de Oracle client in zijn originele staat leert een controle van de rechten van de gebruiker SCOTT dat deze nu DBA rechten heeft.

In de praktijk (zie casus) kan de aanval met een enkele opdracht uitgevoerd worden. De SQL injection aanval op de CTXSYS.DRILOAD package wordt hieronder geïllustreerd.

Op dit moment is toegang tot de database verschaft met hoge rechten en kunnen besloten delen van de database ingezien en aangepast worden. Dit biedt weer verdere mogelijkheden om bijvoorbeeld door te breken naar het onderliggende platform. Deze kwetsbaarheid is overigens in de Critical Patch Update (CPU) van Oracle in januari 2006 opgelost. In de casus is hiermee vastgesteld dat de Oracle database kwetsbaar is voor deze fout. De onderstaande aanbeveling ligt daarbij voor de hand.

Aanbeveling Volg de patch-cyclus van Oracle, let op waarderingen/impact die door Oracle aangegeven zijn (met name remote, unauthenticated/ authenticated exploits hebben hoge impact).

Een kanttekening in algemene zin is dat mogelijk sprake is van een valide onderbouwde afweging voor het al dan niet inzetten van een patch. Tijdens de uitvoering van een penetratietest kan het team op basis van een enkele waarneming niet vaststellen of sprake is van een weloverwogen afweging. Bij de risicoafweging kan ook als mitigerende factor sprake zijn van monitoring en alarmering waarbij de beheerorganisatie deze toegang en gebruik van DBA rol privileges opmerkt en op basis daarvan (geautomatiseerde) acties uitzet.

Eerst controleert de aanvaller de rechten waarover het DBSNMP account beschikt, als volgt: SQL> select * from user_role_privs; USERNAME

GRANTED_ROLE

ADM DEF OS_

------------------------------ ------------------------------ --- --- --DBSNMP

CONNECT

NO YES NO

Het DBSNMP account beschikt alleen over de connect roltoewijzing. Onderdeel daarvan is het minimale privilege dat nodig is voor het opzetten van een verbinding met de database. De aanvaller maakt middels het uitvoeren van de onderstaande SQL opdracht misbruik van een aanwezige SQL injection in de CTXSYS.DRILOAD package. Een execute immediate geeft opdracht om DBA rechten toe te kennen aan het DBSNMP-account. SQL> exec ctxsys.driload.validate_stmt(‘grant dba to dbsnmp’); BEGIN ctxsys.driload.validate_stmt(‘grant dba to dbsnmp’); END; * ERROR at line 1: ORA-06510: PL/SQL: unhandled user-defined exception ORA-06512: at “CTXSYS.DRILOAD”, line 42 ORA-01003: no statement parsed ORA-06512: at line 1

Stap 4c: Vervolgactiviteit -> Activiteit 8: SQL Injection

Om duidelijk te maken dat er meerdere manieren bestaan om deze rechten te verkrijgen volgt een korte illustratie van een SQL injection aanval. In het kort heeft SQL injection betrekking op het niet of onjuist controleren van gebruikersinput wat kan leiden tot uitvoeren van opdrachten (SQL) op de database. Zie [WIKI] voor een nadere toelichting.

Een controle van de rechten van het DBSNMP leert dat DBA rechten zijn toegewezen.

SQL> select * from user_role_privs; USERNAME

GRANTED_ROLE

ADM DEF OS_

------------------------------ ------------------------------ --- --- ---

De Oracle package CTXSYS.DRILOAD bevat een bekende kwetsbaarheid [ALERT68]. De kwetsbaarheid in een notendop: De betreffende package van CTXSYS is voorzien van publieke toegangsrechten en gebruikt voor het uitvoeren van opdrachten de rechten van de eigenaar (DBA) in plaats van de rechten van degene die de package aanroept. Daarnaast vormt de package zonder enige vorm van invoercontrole elk SQL commando uit. Het betreft daarmee een vorm van directe database SQL injection. Het risico bestaat

DBSNMP

CONNECT

DBSNMP

DBA

NO YES NO NO YES NO

Door het installeren van Oracle alert patch 68 wordt deze kwetsbaarheid verholpen. Zie tevens [MLN281189.1]. Een aanbeveling op basis van deze bevinding ligt in lijn met de aanbeveling gedaan bij de Oracle client hack.


Stap 4c: Vervolgactiviteiten

Het ondernemen van vervolgactiviteiten is afhankelijk van het al dan niet bereiken van de onderzoeksdoelstelling. Gegeven de beschikbare DBA rechten op de database (geïllustreerd op een tweetal manieren) behoren bijvoorbeeld de volgende activiteiten tot de mogelijkheden: • Het volledig in kaart brengen van het systeemlandschap van de database inclusief eventuele vertrouwensrelaties met andere databases. In de geschetste casus zou gekozen kunnen worden voor het bevragen van de aanwezige database profielen, waarin bijvoorbeeld eisen ten aanzien van wachtwoordsamenstelling, frequentie van wachtwoord wijzigen et cetera is vastgelegd. Ook het verkrijgen van inzicht in de toewijzing van database rollen en privileges past binnen de geschetste onderzoeksdoelstelling. Daarnaast kan het team ook achterhalen wat op welke wijze gelogd wordt en welke database alarmering (triggers) ingesteld zijn. • Het opvragen van de vercijferde wachtwoorden (hashes) van alle Oracle accounts. Deze hashes kunnen vervolgens met geautomatiseerde hulpmiddelen offline gekraakt worden. Zie bijvoorbeeld [ORABENCH] voor een benchmark van verschillende tools. De gekraakte wachtwoorden geven inzicht in de sterkte van de gekozen wachtwoorden. Daarnaast is het mogelijk om deze identificatie- en authenticatiegegevens te gebruiken op het platform, applicaties of andere systemen. De kans dat dezelfde account/wachtwoordcombinaties aanwezig zijn op andere toepassingen is groot. • Vanuit de databaseomgeving kunnen we uitstapjes maken naar het onderliggende platform of netwerk. In [ORAHB] is een heel hoofdstuk ingeruimd dat beschrijft op welke wijze het uitvoeren van besturingssysteem commando’s vanuit de database mogelijk is. Deze activiteit kan als opstap dienen voor het verkrijgen van volledige controle over het onderliggende besturingssysteem, applicaties en andere databases. Overigens is het ook mogelijk om vanuit het platform een aanvalsplan op te stellen. In figuur 2 is daartoe, op basis van de uitgevoerde poortscan (zie figuur 1) een voorzet gegeven. Activiteiten binnen dit aanvalsplan zijn, zoals in figuur 2 schematisch weergegeven, gericht op mogelijke kwetsbaarheden in aanwezige netwerkservices zoals SMTP, FTP en HTTP.

onderzoek en aanbevelingen voor aan de systeemeigenaar voor hoor en wederhoor. De afgestemde rapportage wordt voorgelegd aan de opdrachtgever. Alle verrichtte werkzaamheden en elektronische evidence voor het onderzoek komen in het onderzoeksdossier terecht. Het onderzoek wordt afgesloten middels een zelfevaluatie van het project om te leren van gemaakte fouten. Conclusie Een penetratietest richt zich op het vaststellen van de eventuele aanwezigheid van een (technische) kwetsbaarheid en de negatieve uitwerking die dit heeft op het onderzoeksobject. Een garantie over de afwezigheid van kwetsbaarheden kan de auditor niet bieden. In tegenstelling tot een reguliere IT-audit naar opzet en bestaan zijn bij een penetratietest met een red teamkarakter, de opzet, de inrichting van de beheerorganisatie, processen, procedures en werkinstructies geen object van onderzoek. Op zich ook logisch aangezien de auditor, gelet op gehanteerde profielen en scenario’s niet beschikt over deze informatie. De mate van zekerheid die een penetratietest biedt, is daarmee dan ook lager dan een reguliere IT-audit. De auditor zal deze beperkingen dan ook zowel vooraf als achteraf in de rapportage duidelijk moeten maken. Het voordeel van de penetratietesttechniek is dat door het in praktijk brengen van een realistisch scenario en dreigingprofiel de onderzoeksbevindingen het management overtuigen en bovenal erg aansprekend werken. De auditor heeft vanuit de praktische insteek en bijbehorende waarnemingen ook uitstekende handvaten om de kans en impact van het manifest worden van bedreigingen te duiden. Het benodigde kennisniveau, middelen, mate van complexiteit en ervaringscijfers vormen bij het inschatten van risico’s de belangrijkste referentiepunten voor de auditor. Daarnaast dwingt een dergelijke audittechniek af dat de IT-auditor omgevingsfactoren in zijn onderzoek betrekt. Waarnemingen vinden namelijk in eerste instantie vanuit de omgeving plaats. Penetratietesting als techniek biedt daarmee de mogelijkheid om een accuraat en realistisch beeld van de kwaliteit van de technische beveiligingsinrichting van een geautomatiseerd systeem te verkrijgen.

Casussamenstelling Voor de voorbeelden is gebruik gemaakt van een standaard Oracle 9.2.0.1 installatie op een Windows 2000 server met SP4 in VMWare.

In de uitwerking van de casus is direct toegewerkt naar DBA-toegang tot de database. In de praktijk zullen verschillende paden bewandeld worden, waarvan diverse paden doodlopen. In technische zin kunnen diverse technieken en methoden toegepast worden die in het kader van dit artikel te ver voeren.

Voor de duidelijkheid: Voor het demonstratieve karakter is een default installatie van een Oracle 9.2.01 database op een Windows 2000 platform ingericht. De toegepaste en beschreven technieken en middelen zijn vrij verkrijgbaar en binnen de gebruikersgroep algemeen bekend. ■

Fase 5: Afronding In de afrondingsfase legt het team de resultaten van het 20 | de EDP-Auditor nummer 3 | 2008

Literatuurlijst [ADP]

ADP Blog. On a breakable Oracle, 24 januari 2006,

[NMAP]

NMAP Security Scanner, http://insecure.org/

[OAK]

Oracle Assesment Kit, David Litchfield, http://www.vul

http://www.adp-gmbh.ch/blog/2006/01/24.php [ALERT68] [AMAP]

nerabilityassessment.co.uk/oak.htm

Oracle security alert 68, http://www.oracle.com/technology/

[OAT]

Oracle Auditing Tool 1.3.1, http://www.cqure.net

deploy/security/pdf/2004alert68.pdf

[ORABENCH]

Oracle password hackers benchmark, http://www.

The Hackers Choice AMAP portscanner, http://freeworld.

red-database-security.com/whitepaper/oracle_password_

thc.org/ [DRILOAD]

benchmark.html

http://www.red-database-security.com/advisory/oracle_

[ORAHB]

sql_injection_via_ctxsys_driload.html [FINNIGAN] [FINNIGAN2]

publishing. ISBN:978-0-470-08022-1

Default Oracle Passwords, http://www.petefinnigan.com/

[ORASEC]

OraSEC, http://www.woany.co.uk/projects/oracsec.html

default/default_password_list.htm

[ORASEC57]

Oracle security alert 57, 4 September 2003. http://www.

Oracle 11g password algorithm revealed, 24 september

oracle.com/technology/deploy/security/pdf/2003alert57.

2007. http://www.petefinnigan.com/weblog/ [IANA]

pdf

archives/00001097.htm

[OSCAN]

Oracle scanner 1.06, http://www.cqure.net/wp/?page_id=3

IANA Port number assignment, http://www.iana.org/

[SANS]

An Assesment of the Oracle Password Hashing Algorithm,

assignments/port-numbers [IMPERVA]

The Oracle Hacker’s Handbook, David Litchfield, Wiley

Joshua Wright, Carlos Cid, 18 oktober 2005.

Full disclosure Oracle DBMS – Access Control bypass in

[SIDGUESS]

SIDGuesser 1.05, http://www.cqure.net

Login, 17 januari 2006.

[TNSCMD]

TNSCMD Perl script, http://www.jammed.com/~jwa/ hacks/security/tnscmd

[MLN160861.1] Oracle Created Database Users: Password, Usage and Files References, Oracle Metalink Note 160861.1, 20 maart 2007.

[VULASS]

Default Oracle passwords overview, http://www.vulnera bilityassessment.co.uk/default_oracle_passwords.htm

[MLN225529.1] How to LOCK the SYS PASSWORD using Password Management with Profiles, Metalink note MLN225529.1,

[WIKI]

SQL Injection, http://en.wikipedia.org/wiki/SQL_injection

24 juni 2003.

[WINSID]

WinSID Pro, http://www.syntheticbytes.com (de tool is niet meer beschikbaar via de website).

[MLN272633.1] Description and usage of the ADMIN_RESTRICTIONS_ listener_name parameter, Oracle Metalink note 272633.1, 25 maart 2005. [MLN281189.1] FAQ for security alert 68, Oracle Metalink note 281189.1, 9 mei 2007.

Noot

[MLN361482.1] Frequently Asked Questions about Oracle Default Password [MLN99721.1]

1 Een drempel wordt opgeworpen wanneer de toegang tot de listener met

Scanner, Oracle Metalink Note 361482.1, 18 april 2006.

een wachtwoord zou zijn beveiligd. Om in deze gevallen toch een geldige

Listening Port numbers, Metalink Note 99721.1, 8 april

SID te verkrijgen, kan geprobeerd worden om de SID te raden. Een tool

2008.

waarmee dit mogelijk is, is SIDGuesser [SIDGUESS]. Een andere mogelijk-

[MLN235298.1] Overview of Default Ports Used by EM 10g Grid Control, DB Control and AS Control, Oracle MetaLink Note 235298.1,

heid is het raden van het listener wachtwoord. Dit kan bijvoorbeeld met de commerciële tool WinSID Pro [WINSID].

1 februari 2008.

ADVERTENTI E


Het artikel beoogt, met als leidraad de methodiek, de

Recommend Documents