Oracle dicht lek in databasesoftware na opduiken proof-of-concept

Oracle heeft maandag een bug in zijn database-software gedicht. De patch komt twee weken na publicatie van een poc. Alle versies van de software sinds 1999 zijn kwetsbaar. Een eerdere patch van Oracle bleek geen oplossing te bieden.

De proof-of-concept van de exploitcode werd twee weken geleden gepubliceerd nadat Oracle een patch had uitgebracht tegen de exploit zelf. Omdat de patch eigenlijk helemaal niets repareerde, kon iedereen ondertussen de exploit vrij misbruiken op alle getroffen servers, meldt de beveiligingsonderzoeker die het lek oorspronkelijk aankaartte bij Oracle in 2008.

De bug, die in alle versies van de databasesoftware sinds 1999 zit, kan worden misbruikt via een man-in-the-middle-aanval. De exploit, bijgenaamd TNS Poison, maakt verbinding met de Oracle TNS Listener-software die de connecties verzorgt tussen de databaseserver en clients. Vervolgens kan een aanvaller een nieuwe server registreren als onderdeel van het netwerk.

Door twee features van Oracle-servers, het clusteren van servers en een backupsysteem, kan de aanvaller het verkeer van de clients deels via de nieuw-geregistreerde server routeren als de nieuwe server onder dezelfde naam wordt geregistreerd als de originele server. Zodoende zou een kwaadwillende, met de nodige moeite, minstens de helft van het verkeer op het netwerk kunnen onderscheppen. Volgens de onderzoeker zou er zo ook malware kunnen worden verspreid en geïnstalleerd op een netwerk.

De beveiligingsonderzoeker spreekt zich sterk uit tegen de manier waarop Oracle met de kwetsbaarheid omging. Ten eerste duurde het vier jaar voor de bug gefixt werd, waarna die fix niet bleek te werken. Uit e-mailcommunicatie met Oracle leidt hij af dat het bedrijf weigerde om de kwetsbaarheid echt te patchen. Ze wilden ook niet duidelijk maken of er ooit een patch ging verschijnen, noch voor welke versies dat zou gebeuren.

Reacties (30)

[Verwijderd]

De beveiligingsonderzoeker geeft niet aan dat het lek niet gedicht is. De onderzoeker geeft aan dat het lek gedicht is in een normale update. Wat hij liever had gezien was dat er een CPU (Critical Patch Update) voor alle versies waren uitgegeven.

Wat Oracle nu gedaan heeft met dit lek is een patch uit te brengen voor de meeste recente versie. Maar wat Koret al aangeeft, het is een lek die tot versie tot 1999 reikt.

Wat Oracle hier dus in feite doet is een update voor Windows 7 uitgeven terwijl er een kwestbaarheid is gevonden in de gehele Windows kernel (Windows 7 en alle versies ervoor).

[Reactie gewijzigd door Verwijderd op 7 augustus 2024 19:53]

[fdh]

Er is ook een work-arround beschikbaar voor oudere versies (oudste dat ze opgelijst hebben is 10.2.0.3, wat volgens mij ook de laagste versie is die nog critical patch updates krijgt).

Edit: workarround voor versie voor 11.2 is blijkbaar enkel voor non rac omgevingen.
Verwachte datum voor een oplossing voor die versies is blijkbaar 05/05

[Reactie gewijzigd door fdh op 7 augustus 2024 19:53]

[mphilipp]

Precies. Op dit moment is Oracle 11g R2 de meest actuele en wordt 10g R2 nog ondersteund. Oudere releases krijgen geen patches meer.

Ik weet dat er nog bedrijven zijn die Oracle 9i en zelfs 8i nog gebruiken. Vaak is dat omdat ze ooit een pakket gebruikten dat alleen op die versies draait (wel heel erg fout geschreven imho) en ze de oude toestand nog willen kunnen benaderen. Een hele foute manier van geld besparen.

Ik ken zelfs een multinational die met Oracle 8 werkte die het productieproces aanstuurde (jawel! via een Forms applicatie met embedded C een fabriek aansturen!). Die konden niet eens meer upgraden zonder een rewrite want zowel de software bestaat niet meer en ook de machines die ze aanstuurden is helemaal verandert. Als de server stuk gaat, hebben ze een groot probleem, want ook de Unix versie is sterk verouderd. Echt grote fail voor zo'n miljardenbedrijf...

[tympie]

Tja, gek he. Microsoft brengt ook geen patches meer uit voor Windows 98, en voor linux geldt hetzelfde. Overigens, voorzover ik kan zien, hebben ze geen patch (software-aanpassing) uitgebracht, maar documentatie over hoe je de configuratie kunt aanpassen zodat de listener niet meer kwetsbaar is voor deze exploit. Daarbij noemen ze overigens alle versies die nog in (extended) support zitten, niet alleen de meest recente.

[fdh]

nee, voor 11.2 rac is er een patch (12880299) die je moet gebruiken voor de beveiliging van registratie met de local listener (in combinatie met een config aanpassing)

[The Van]

Nee - zie mijn reactie onder!
Het lek is NIET dicht. Het zal in een volgende productie release niet meer bestaan - er is geen patch (die werkt), en komt geen patch.

[Verwijderd]

niet echt de makkelijkste exploit dus...

[mphilipp]

Nee, het is idd nogal academisch. Ik heb dat idee bij heel veel 'exploits'. In een lab omgeving werkt het prima, maar je moet echt heel ver gaan wil je een real world situatie bedenken waarin dit een reële bedreiging vormt. Je kunt van buitenaf namelijk nooit zomaar een database server benaderen. Je moet dan toch echt binnen de firewall zitten. Zelfs al heb je toegang tot de web/applicatieserver die met de databaseserver praat is het nog niet zo simpel dit uit te voeren. Je moet nl echt toegang hebben tot het OS en volgens mij is deze exploit te omzeilen door je listener van een wachtwoord te voorzien. Dat is iig iets dat altijd aangeraden wordt.

Maar goed, dit soort verhalen doet het goed bij mensen die geen klap van Oracle weten natuurlijk...

[Reactie gewijzigd door mphilipp op 7 augustus 2024 19:53]

[tympie]

Als het goed is, zijn database servers inderdaad niet van buitenaf te benaderen. Maar het is natuurlijk ook de vraag of alle dreiging van "buitenaf" komt. Bij een beetje groot bedrijf heb je ook te maken met 3rd parties die van bepaalde databases gebruik moeten kunnen maken (en dus van buitenaf connectie kunnen maken met de listener), er lopen externen rond die met hun eigen laptop op het netwerk zitten, etc. Je hebt dus niet volledig controle over wie/wat er allemaal toegang heeft. En daarnaast zijn er nog gewoon de eigen werknemers... Al die partijen zijn weliswaar gebonden aan, al dan niet in mooie juridische terminologie uitgeschreven, gedragsnormen, maar daar koop je uiteindelijk natuurlijk niets voor.

Overigens betwijfel ik dat het beveiligen van de listener met een password dit probleem oplost. Een met password beveiligde listener kun je weliswaar niet mbv bijvoorbeeld lsnrctl beheren (starten, stoppen, status bekijken) zonder dat je het password weet, maar deze exploit maakt gebruik van hetzelfde mechanisme dat een database gebruikt om zich te registreren bij een (remote) listener. Ik kan in de Oracle docs zo snel niet terugvinden hoe je aan de database duidelijk zou moeten maken dat het om een beveiligde listener gaat, en wat dan het password daarvoor is, en evenmin dat dit proces niet zou werken bij een beveiligde listener. Daaruit concludeer ik dus maar even dat een database die zich registreert bij een listener, geen password nodig heeft.

Listener voorzien van een password is volgens mij trouwens tegenwoordig niet meer nodig, omdat die default alleen nog vanaf de lokale host te stoppen/starten is?

[John_Glenn]

Uit het verhaal op Ars Technica is op te maken dat die "listener" zo te configureren is dat hij van buiten bereikbaar zou zijn (niet erg verstandig natuurlijk, maar het kan dus). Verder begreep ik eruit dat het beveiligingsgat juist de wachtwoordcontrole waar je het over hebt omzeilt:

... an attacker can hijack connections legitimate users have already established with the database without the need of a password or other authentication.

[tympie]

De listener moet zo geconfigureerd zijn dat die bereikbaar is voor alles wat rechtstreeks gebruik maakt van de databases die door die listener geserviced worden. Dat is vaak bijna het hele bedrijf. En omdat (de IT infra van) een bedrijf niet echt een statisch iets is, betekent dat dus meestal dat de listener in principe bereikbaar is voor alles en iedereen (de company firewall zorgt er vervolgens wel voor dat er niemand van buitenaf op kan).

Maar al die gebruikers hoeven alleen maar connectie te kunnen maken met databases, die hoeven geen nieuwe databases te kunnen registreren. Dat zouden alleen geauthoriseerde databases/servers moeten mogen, maar daarvoor is er, in de default configuratie, geen aparte check. Dat is het probleem. Daardoor kan iedereen een "database instance" registreren, waar vervolgens (ongemerkt voor de eindgebruiker) reguliere connecties naartoe gestuurd worden, en dat levert dan weer een hoop mogelijkheden tot verder hackwerk op.

De wachtwoordcontrole die jij uit het Ars Technica artikel quote, en die waar mphilip (en ik in mijn reactie daarop) het over had, zijn twee verschillende. Jouw quote gaat over authenticatie richting de database, mphilip had het over authenticatie richting de listener.

[Reactie gewijzigd door tympie op 7 augustus 2024 19:53]

[OddesE]

In een 3-tier infrastructuur connecten clients niet rechtstreeks met de database. Zo kan business logic centraal afgedwongen worden. Als mensen (clients) de database rechtstreeks kunnen benaderen kunnen ze records inserten die niet voldoen aan de regels. Bijvoorbeeld als postcode 'Piet-je' of als telefoonnummer 'jadoeihoor'. Zie ook dit plaatje dat het verduidelijkt.

Dus voor veel applicaties en bedrijven zal dit nog niet zo'n probleem. Zijn. Ik wed dat bijvoorbeeld ook de Tweakers.net database niet zomaar van overal binnen hun eigen netwerk te bereiken is. De database bevat alleen de data (en wat eenvoudige business logic zoals verplichte velden of uniek etc) alle belangrijke / complexe logic zit in de website. Beheerders / redacteuren / moderators werken gewoon via de website. Slechts voor een enkele beheerstaak zal er directe toegang tot de database nodig zijn.

Correct me if I'm wrong Tweakers!

[tympie]

Dat eindgebruikers rechtstreeks naar de database kunnen, wil niet zeggen dat ze data kunnen zien/toevoegen/wijzigen die niet aan je business en access control rules voldoet. Je kunt business rules en authorisatie namelijk ook in de database zelf afdwingen (constraints, stored procedures, triggers, rechten/rollen, etc.).

Wat een 3-tier infra inhoudt, wist ik al zo ongeveer.

[OddesE]

Ja maar als je al je constraints in de database stopt wordt je applicatie erg ingewikkeld (stored procedures e.d. zijn in de regel lastiger om te programmeren) en ook lastig om eventueel van database te switchen aangezien talen zoals PL-SQL niet cross-database zijn.

Dat jij weet wat 3-tier is is natuurlijk cool, maar er komen meer mensen hier en ik vermoed dat er ook velen zijn voor wie het nog wel onbekend is.

[Floor]

Daarbij ga je er vanuit dat een firewall waterdicht is. Dat is een gevaarlijke veronderstelling. De hoog opgeleide hackers komen kunnen elk systeem kraken.
De combinatie tussen verschillende technieken, lagen van beveiliging enz maken het echter wel veel moeilijker.
Daarbij ga je er ook vanuit dat hackers solo werken maar ook dat is een gevaarlijke veronderstelling. Laat je een (fatsoenlijk) bedrijf je systemen en bedrijf doorlichten dan heb je minimaal al 2 man die bezig zijn en met elk een z'n eigen specialisme.

[mphilipp]

Nee, daar ga ik niet van uit natuurlijk. Tuurlijk kun je elk systeem kraken. Maar je kunt er niet vanuit gaan dat dan ook maar alles gekraakt gaat worden. Op papier is alles mogelijk, maar de praktijk is vaak weerbarstiger. Een kraker heeft tijd nodig om het systeem te verkennen. Daar kan ie tools voor inzetten, maar het kost uiteindelijk tijd en dat vergroot de kans op ontdekking. Het is niet zo dat ie in and out is in 60 seconden.

Waar je vandaan haalt dat ik denk dat hackers solo werken is mij een raadsel. Heb jij een kristallen bol ofzo? Hoe weet jij wat ik denk en waar ik vanuit ga?
Had ik een 24-delige reactie moeten plaatsen met alle dann-wann-und-abers?

[fdh]

zover ik het lees, gaat het erom dat een database zich registreerd op de listener van een andere database / server (remote_listener parameter) waardoor connecties op die listener soms doorgestuurd worden (omdat de db connecties gaat load balancen).

Je hebt dus geen toegang nodig tot de server waarop de database zicht bevind, maar je moet wel binnen het netwerk zelf zitten.

Ik heb dit zelf al eens gehad na het clonen van een rac database, waarbij ik vergeten was om de remote_listener parameter te wijzigen. Omdat de service names hetzelfde waren op de test omgeving kreeg de test database ineens conecties binnen van productie.

Ik vermoed dat voor de exploit een stuk code geschreven is om te registeren op de remote listener (je moet dan het ip of scan adres en poort nummer kennen) om dan de doorgestuurde sessies te onderscheppen en de passwoorden te onderscheppen.

Een work arround die oracle nu doorgeeft is om te zorgen dat enkel authorized instances zich op de listener kunnen registeren (door middel van oracle wallets met self signed certificates en de secure_register_<listener_name> parameter).
Normaal heb je hier wel een licentie voor nodig op de advanced security optie, maar blijkbaar is er een wijziging gekomen op de licentie regels voor deze exploit (al vind ik deze niet direct terug in de licensing guide).
Advanced security is (sinds 11g) trouwens niet afzondelijk meer installeerbaar, maar wordt altijd geinstalleerd omdat het te diep verweven zit in de code.

[Ford Prefect]

Je moet nl echt toegang hebben tot het OS en volgens mij is deze exploit te omzeilen door je listener van een wachtwoord te voorzien. Dat is iig iets dat altijd aangeraden wordt.

Dat is niet waar, het is niet een kwestie van je listener password zetten, het is een kwestie van een wallet aan te maken, dus een PKI infra op te zetten voor je listeners en scan listeners.

[BoringDay]

Als je van een usb boot? en de login weet … dan is een php script zo gepiept toch?
Niet dat ik de kans groot acht een werknemer dat zal doen, ik ga ervan uit dat deze mensen blij zijn ze werk hebben en betrouwbaar zijn.

Echter is het wel zo in sommige gevallen je zekerheid nodig hebt.
Zo kan ik ook eenvoudig inloggen op een Macbook ook al zit hier een wachtwoord op.
Niet zozeer een OSX probleem maar gebrek van de gebruikers en die snel aannemen dat iets veilig is.

Dat je van buitenaf nooit zomaar een database kan benaderen is natuurlijk de grootste onzin. SQL injecties bewijzen keer op keer het tegendeel terwijl dit al jaren bekend is.

[Verwijderd]

Dus kort samengevat: 4 (vier!) jaar nadat het lek bekend was komen ze met een oplossing omdat het in het wild gebruikt kon worden.
Sorry, maar dat vindt ik "wat mindere service".

[TDeK]

Het is een houding die je bij wel meer bedrijven ziet. Komt waarschijnlijk omdat je security niet makkelijk kunt 'verkopen' waardoor planning er geen tijd (of onvoldoende) voor vrij wil of kan maken. Je bent immers vele maanden aan het werken zonder dat je daar direct resultaat van ziet (niet gehacked worden is immers een non-event).

[BoringDay]

Toch zal je met test events moeten werken en zeker op fouten.
Je bent een bedrijf wat een product verkoopt en klanten betalen hiervoor.
Omdat men hiervoor betaald is een commercieel bedrijf verplicht op veiligheid te testen.
Anders moet men geen product verkopen.

Immers is dit bij andere sectoren ook verplicht.
Stel dat een supermarkt zijn voedselwaar niet meer controleert op houdbaarheid.
Of auto fabrikanten niet meer de veiligheid van auto's testen.

Natuurlijk kan er eens wat over het hoofd gezien worden.
Maar dan is tijd of wil geen excuus om je hiervan vrij te pleiten.

4 jaar er niks aan doen heet nalatigheid.

[Cameleon73]

Wat ik het meest aparte aan dit verhaal vindt, is dat er blijkbaar fundamenteel niets is veranderd in de Oracle TNS listener sinds 1999. Dertien jaar is een eeuwigheid in software-land...

[Ford Prefect]

Dat hangt er vanaf wat je als fundamenteel ziet, natuurlijk wijzigt er mijn ogen niets fundamenteels aan de listener. Zijn doel is om binnenkomende connecties af te handelen en door te zetten naar een database connectie. Er zijn zo in de loop van de jaren wel een groot aantal rollen bij de listener terecht gekomen, vanaf 11gR2 hebben we ook een SCAN listener erbij bv.

[citegrene]

Gaat dit vooral om verkeer wat zich doorgaans op een lokaal netwerk bevindt?

[The Van]

Ehhh.. kan ik een link naar de patch krijgen?

Ik zie namelijk helemaal niet, dat het lek gedicht is, integendeel, het lek is nog steeds niet gedicht!

Oracle security people: For the next time, don't say that a
vulnerability is fixed in a Critical Patch Update if the patch is not
published.

En het zit er waarschijnlijk al 13(!) jaar - sinds de introductie van listener load balancing/remote registration: de introductie van 8i.

[fdh]

patch 12880299
support notes 1340831.1 en 1453883.1

Als oracle klant zou je trouwens normaal hiervan ook een email moeten gekregen hebben

[tympie]

Volgens mij is 12880299 niet een directe fix voor het security issue waar het hier over gaat, maar een fix voor een probleem met RAC instances wanneer je de listener dusdanig configureert dat alleen registraties via IPC geaccepteerd worden. Omdat de workaround/configuratie-wijziging die Oracle voor het security-issue aandraagt, nou juist dat doet, moet die bugfix wel ingespeeld worden.

[fdh]

je moet toch juist ook TCP toevoegen bij de secure_register_listener parameter?

[Reactie gewijzigd door fdh op 7 augustus 2024 19:53]

[tympie]

Ik was even afgegaan op de korte beschrijving van de bug, maar zo te zien heb je gelijk:

The patch update allows for registration from only the local node over TCP provided that TCP is listed as a secure transport for registration.