[ORACLE] secure password methode

[Verwijderd]

Het volgende is het geval. Enige tijd terug ben ik bezig geweest met een klein onderzoek naar een methode voor het aanmaken van Oracle Apps user accounts en hoe om te gaan met deze gebruikers in het geval dat ze hun wachtwoord vergeten waren. Na wat onderzoek is het duidelijk geworden dat het, met een simple aanpassing, mogelijk is om een wachtwoord te de-crypten welke in de oracle database encrypted is opgeslagen.

Na het vinden van deze security bug ben ik nu aan het kijken naar een mogelijkheid om een goede en meer veilige manier te bedenken om om te kunnen gaan met gebruikers wachtwoorden in Oracle Apps. Hierbij wel rekening houdend dat er niet al te veel verbouwd dient te worden aan de bestaande Oracle PL/SQL packages.

Wat ik me afvraag op dit moment is of er nog andere personen zijn die tegen deze bug zijn aangelopen en of ze methodes hebben ontwikkeld in PL/SQL om de aanpak die Oracle zelf gebruikt te verbeteren? Zo ja dan zou ik hier graag wat pointers over krijgen.

Voor een uitleg in wat meer detail over de bug kun je het artikel lezen wat ik op mijn weblog heb geplaatst. http://johanlouwers.blogspot.com/2006/12/oracle-applications-passwords.html

[JaQ]

Ik ben zelf nauwelijks bekend met apps (enkel wat pl/sql werk gedaan onder 10.3 of 10.4), maar wel met Oracle (zowel RDBMS als AS, ik werk als DBA), dus ik kan dingen roepen die niet logisch zijn....

Apps maakt dus geen gebruik van database-users (en zo nee, waaarom niet)? Wordt er wel iedere keer een context gezet voor iedere user die inloggen, of wordt dit ook achterwege gelaten?

[reddog33hummer]

Waarom zijn mensen nog steeds bezig om paswoorden in databases op te slaan ?

Integereer het met de rest van de organisatie, en gebruik mogelijk een radius of kerberus login.
Dit isoleert de paswoorden op 1 punt en geeft de gebruiker een single logon.

[The Eagle]

reddog33hummer schreef op dinsdag 12 december 2006 @ 16:31:
Waarom zijn mensen nog steeds bezig om paswoorden in databases op te slaan ?

Integereer het met de rest van de organisatie, en gebruik mogelijk een radius of kerberus login.
Dit isoleert de paswoorden op 1 punt en geeft de gebruiker een single logon.

Gezien vanuit een ICT-oogpunt zou dat een logische keuze zijn. Single Sign-on echter (waar jij het dus over hebt) vereist een complete omslag van de cultuur van een bedrijf. De impact is zovel groter als je denkt.

@Suntac: Ik werk zelf met PeopleSoft, en ook daarbij worden passwords encrypted in de DB opgeslagen. Het vereist rechten op Oracle-niveau in het SYSADM-schema om die te kunnen wijzigen. En dan is het idd een fluitje van een cent: gewoon overschrijven met de encrypted string van een bekend password

Wellicht zou je ook eens contact kunnen zoeken met deze lui. Ik weet (ken de eigenaar persoonlijk) dat zij redelijk gevorderd zijn in het encrypten van Oracle DB's en alles wat daarmea samenhangt

[Verwijderd]

reddog33hummer schreef op dinsdag 12 december 2006 @ 16:31:
Waarom zijn mensen nog steeds bezig om paswoorden in databases op te slaan ?

Integereer het met de rest van de organisatie, en gebruik mogelijk een radius of kerberus login.
Dit isoleert de paswoorden op 1 punt en geeft de gebruiker een single logon.

Onder Oracle kan dit met SSO (Single Sign On), helaas heeft Oracle voor het opslaan van Oracle Apps passwords gekozen voor een manier waar je niet erg gelukkig van gaat worden. Ten eerste is mijn grote probleem met deze manier dat het wachtwoord dat opgeslagen is ook daadwerkelijk het wachtwoord is al is het dan encrypted, een HASH value zou beter zijn in mijn ogen. Ten tweede heeft Oracle zich er in mijn ogen nogal makkelijk vanaf gemaakt. Door het aanpassen van een simple package kan ik alle wachtwoorden decrypten.

Als je naar de DB users zelf gaat kijken is dit beter gedaan maar op het gebied van Apps is het een drama. Mijn hoop was dat er iemand op dit forum zou zijn die dit probleem ook is tegen gekomen en een goede manier heeft gevonden om dit te veranderen. Het probleem is echter dat als je hier aan gaat veranderen je een super internal stukje van Oracle Apps gaat customizen en dit kan nog wel een ongewenst zijn. Ik vraag me dus af of er mensen zijn die dit hebben gedaan en die hier een voorbeeld van hebben.

[Verwijderd]

The Eagle schreef op dinsdag 12 december 2006 @ 16:40:
[...]
@Suntac: Ik werk zelf met PeopleSoft, en ook daarbij worden passwords encrypted in de DB opgeslagen. Het vereist rechten op Oracle-niveau in het SYSADM-schema om die te kunnen wijzigen. En dan is het idd een fluitje van een cent: gewoon overschrijven met de encrypted string van een bekend password

Klopt je zal bepaalde rechten moeten hebben, echter... je hoeft de gegevens niet te overschrijven, je kan met een simple query de gegevens ophalen en met een standaard oracle package de wachtwoorden decrypten. De beveiliging die er in zit vanuit een Oracle oogpunt is dat de decrypt function niet buiten het package beschikbaar is, als je voldoende rechten hebt om dit aan te passen dan kun je de function ook buiten het package beschikbaar maken en is het vinden van een wachtwoord dus een fluitje van een cent.

Heb je echter deze rechten niet dan kan je altijd nog het Java package downloaden wat uiteindelijk aangeroepen wordt door het PL/SQL package. Een tool schrijven die de encrypted wachtwoorden ophaalt uit de fnd_user table en deze door het java package laten decrypten. De Java function oracle.apps.fnd.security.WebSessionManagerProc.decrypt zal in de normale Oracle opstelling uiteindelijk ook het werk doen dus deze zou je ook handmatig kunnen aanroepen en zijn werk laten doen.

Als ik eerlijk ben ben ik een beetje geschokt door de knullige manier waarop Oracle de authentication methode heeft toegepast.

[JaQ]

reddog33hummer schreef op dinsdag 12 december 2006 @ 16:31:
Waarom zijn mensen nog steeds bezig om paswoorden in databases op te slaan ?

Integereer het met de rest van de organisatie, en gebruik mogelijk een radius of kerberus login.
Dit isoleert de paswoorden op 1 punt en geeft de gebruiker een single logon.

En hoe had je dat in gedachten bij alle third-party paketten die je inkoopt als bedrijf? Je verwacht dus van iedere softwareleverancies dat deze de denkkronkels van een lokale systeembeheerder kan doorgronden die de radius, kerberos of andere willekeurige variant heeft ingericht? Gaat niet werken, vooral omdat een leverancier de stabiliteit van zijn eigen pakket niet gaat laten afhangen van derden op dat niveau. (wel op het niveau van hardware en OS, alhoewel daar ook eissen aan worden gestelt)

Verwijderd schreef op dinsdag 12 december 2006 @ 16:51:
[...]
Als ik eerlijk ben ben ik een beetje geschokt door de knullige manier waarop Oracle de authentication methode heeft toegepast.

Nou... applications heeft al jaren het stempel van trainingspakket voor Oracle junioren die net bij Oracle Corp. zijn gaan werken (nofi). Ik vrees dat dit een gevalletje security by obscurity is...

Heb je trouwens een reactie van Oracle gekregen toen je dit aankaartte in een SR?

[80000]

my 2 cents:

Correct me if I am wrong, maar in je methode ga je ervan uit dat je het APPS password weet, anders kan je geen packages wijzigen (wat je nu doet) en heb je geen toegang tot de FND packages voor het uitvoeren van enkele foundation functies of variabelen die je beschrijft. Verder is dacht ik (moet ik effe aan de expert vragen) voor het decrypten voor zowel PL/SQL en java het APPS password ook nodig.

Maar als ik het APPS password al heb, hoef ik niet eens meer de fnd user passwords te weten, dan heb ik sowieso al toegang tot bv de HR en AR tabellen en kan ik alles lezen en wijzigen met simpele statements .

Vandaar bij het bedrijf waar ik nu zit:
- APPS password is alleen maar bekend bij de DBA's, niemand anders heeft het ook nodig
- Iedereen die sqlplus toegang nodig heeft, krijgt een OPS$ account met alleen lees rechten voor beperkte tabellen, geen package en functie execution rechten
- Elke cloon van productie, zeker voor devvers, die hebben nog wel eens het APPS password nodig, wordt belangrijke data gescrambled, fnd_user passwords gereset, APPS password gewijzigd.

[Verwijderd]

Het verhaal klopt qua technische details wel (heb het zelf ook uitgeplozen). Echter, alle voorbeelden van code en SQL uit het artikel gaan inderdaad (zoals mrox al aangaf) uit van de positie dat je al ingelogged bent als APPS user. Zonder dat kun nl. niet bij de fnd_user table dus ook niet bij encrypted foundation password. En dat is uiteindelijk hetgeen wat achterhaalt moet worden om er in te kunnen.

Dus -
Om select * from fnd_user; te kunnen uitvoeren moet je er al in zijn.
Om de FND_WEB_SEC package body te kunnen bekijken moet je er al in zijn.
Om fnd_profile.value te kunnen aanroepen vanuit een query moet je er al in zijn.
Om fnd_web_sec.decrypt te kunnen aanroepen moet je er al in zijn.

Wat ik al zij, technisch klopt het verhaal helemaal maar het is geen bewijs voor een security issue in Oracle Applications. Het bewijst alleen dat je security code van oracle begrijpt.

[80000]

Als followup, je hebt dus niet het APPS password nodig om te decrypten, maar de FND java security packages worden niet naar de client gedownload om te hergebruiken of te reverse engineeren. Andere mogelijkheden om eraan te komen zijn uiteraard wel mogelijk.

[Verwijderd]

Beste MROX, Helaas klopt dat niet helemaal in de JInitiator cache zijn wel degelijk de classes AolSecurtity en AolSecurityPrivate te vinden (de de-/encryption code). Echt het voorgaande blijft overeind. Je hebt er niets aan als je niet bij de FND_USER ENCRYTED_FOUNDATION_PASSWORD kan