Domino-Passwörter unzureichend geschützt?

[xemu]

Hallo an alle,

was haltet Ihr (Fachmänner/frauen) davon?
http://www.heise.de/newsticker/meldung/62147

Gruß xemu

[Glombi]

siehe
http://www.heise.de/newsticker/meldung/62147

hier die Quelle:
http://www.cybsec.com/vuln/default_configuration_information_disclosure_lotus_domino.pdf

Andreas

[koehlerbv]

Ist heute Doppelposting Day ? 

http://www.atnotes.de/index.php?topic=24556.0

[DatenDuck]

Hallo Leute,

vielleicht interessiert das ja den einen oder anderen:
http://www.heise.de/newsticker/meldung/62147

[Thomas Schulte]

nee triple  Im Offtopic ist das jetzt auch.
http://www.atnotes.de/index.php?topic=24559.new;boardseen#new

Wobei die Frage ist, wie verwundbar ist das dann wirklich.

[Glombi]

Danke Bernhard für den Hinweis, das habe ich glatt übersehen - Asche über mein Haupt .

Nichts desto trotz sollte man schnellstens den Workaround umsetzen, sofern man einen Domino-Server im Internet stehen hat.
Die "Verschlüsselung" des HTTP-Kennwortes ist ja geradezu ein Witz.

Andreas

[Glombi]

nee triple  Im Offtopic ist das jetzt auch.
http://www.atnotes.de/index.php?topic=24559.new;boardseen#new

Wobei die Frage ist, wie verwundbar ist das dann wirklich.

Ich habe alle drei Postings nun zusammengeführt.

Es ist ja kein Wunder dass es hier sofort an vielen Stellen hochkommt, denn wann wird schon mal negativ über Notes in Heise berichtet 

Andreas

[(h)uMan]

Hallo,

setzt jemand folgende Parameter für die Anmeldung über HTTP ein und kann Erfahrungen mitteilen?

"NABWebLookupView = viewname "
With this NOTES.INI variable, the server is directed to search the NAB for the name the user entered into the Name and Password dialog box using the view that is specified in this NOTES.INI variable. This "user" created view is used instead of the $Users view. This method allows administrators to design a new view in the public NAB that is similar to the $Users view, however, in the formula for the first column (Name) the formula that view may not have first names, last names, shortnames etc., so users would be forced to enter their full names to log in.


"NoAmbiguousWebNames=1"
This variable forces Domino to match Web user names to only one Person document in the NAB. Setting this flag will result in an authentication failure (like "Error 401 Authentication Exception") any time more than one Person document matches a Web user name. Users will have to "login" with a unique user name to authenticate.

For example, If a user enters "jdoe" in the Name and Password dialog box, Domino searches the $User view of the NAB for any matches. Let's say that it finds two matches (John Doe/Lotus and John Doe/Acme). In this case the user would receive an Error 401 Authentication Exception - because the name entered (jdoe) is ambiguous. At this point the user would need to enter his full hierarchical name (John Doe/Acme) in the Name and Password dialog box, so that he could be authenticated correctly.

Please note that if a customer site is using "NoAmbiguousWebNames=1", and if the site has users with the same name (either in the same NAB or in different NABs if a Master Address Book is being used), this could cause problems with authentication. For example, if you have two John Smiths in two different NABs, if they enter "John Smith" in the Name and password dialog box, neither will be authenticated because this name is ambiguous. The Administrator would need to edit the Person document and change their User name fields so that each has a different middle initial (John M. Smith and John S. Smith). Alternately the administrator could change the shortname field so that each is unique (jmsmith and jssmith). The users can then use the resulting "unique" name when prompted to authenticate via the Name and Password dialog box.

[xemu]

Dann bin ich aber froh, dass ich nix übersehen habe und somit der erste war 
Danke fürs zusammen legen der Threads.

Ich dachte nur, ist vielleicht auch für den ein oder anderen interessant. 

Gruß xemu

[Semeaphoros]

Offizielle Antwort von IBM:

http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21212934


Und da auch eine vieeel bessere Lösung als der angegebene Workaround. Offensichtlich wurde das Security-Team gar nicht hinzugezogen bei der Beantwortung dieses scheinbaren Problems. Die Lösung des Problemes selber gibt es bereits seit Release 4.6 .... und wer nicht umgestellt hat, ist selber Schuld, nebst dem, dass man ja schon mindestens einen Account "geknackt" haben muss, um überhaupt auf diesem Weg einen Angriff fahren zu können.

Gont: Ich hab jetzt wirklich überhaupt keine Lust, auf einen derart hingeschmierten Text eine Antwort zu geben ......

[datenbanken24]

Die ganze Meldung erscheint mir ebenfalls ein wenig suspekt.
Auch der Workaround-Vorschlag ist mit  Vorsicht zu betrachten :
Persönlich riecht das für mich wieder nach einer "Ich will meine unbekannte Firma bekannt machen - koste es was es wolle - Aktion"

Erstens
kenne ich keinen Grund das N&A direkt für Browser-Zugriffe zu öffnen.
iNotes, DWA, Webmail greifen zwar alle aufs N&A zu,
aber trotzdem kann das Directory in allen Fällen für Webzugriffe vollkommen dicht sein:
ACL Advanced Option: "Maximum internet name and password access: NoAccess"


Zweitens,
gibt es seit Domino 5 die Sicherheitsoption der sogenannten "gesalzenen" Internet-Passwörter, Internet-Hashs.
Das heißt, ein gleiches Passwort im Personendokument wird immer in einen anderen Hashcode umgesetzt. Die Rückverfolgung vom Hash zum Passwort geht dann meines Wissens mit dem PW Cracker nicht mehr, der kann nur die ungesalzenen (Standard) cracken

Zur Info:
So sieht ein ungesalzener Hash im Directory aus:
(C72630165BD0F9F185FAB71868FC98D8)

Und so ein gesalzener:
(F4hgwz5/kls/83DEvZhB)

Die Option findet man im Directory / Actions / Edit Directory profile
"USe more secure internet passwords"

Drittens,
der Workaround ist der Hammer
steht es bei Heise wörtlich genau so rum, dass man das Feld fürs Web öffnen soll

Feldern $dspHTTPPassword und HTTPPassword in den Eigenschaften "Hide paragram from" die Option "Web browsers" abzuwählen.

Da hat entweder der Übersetzer gepatzt oder ...?

Und einfach mal so eine Maskenoption des N&A zu ändern,

Formulareigenschaften "Generate HTML for all fields abgeschaltet werden”

hui - viel Spaß damit, mit diesem Workaround fängt man sich hundert mal Fehler ein, als die man behebt.

Gruß,
Uwe

[Christopher]

Hm also das ganze ist doch ein alter Hut und wurde auch schon mal ausführlich beschrieben siehe:

http://www.it-audit.de/assets/artikel/com/Hackerziel_Domino.pdf

[Semeaphoros]

Uwe, die gesalzenen und gepfefferten Passwörter gibts sogar schon seit R4.6, das wurde 1997 eingeführt, das nur der Vollständigkeit halber, der Rest steht ungefähr so ähnlich wie du es beschreibst in der von mir verlinkten Technote.

[datenbanken24]

Jou Jens - nur im besagten Artikel findet man eben kein einziges Wort darüber, z.B. als Workaround-Vorschlag.

Salzige Grüße,
Uwe

[Semeaphoros]

Ja, das Problem steckt ua. darin, dass bei IBM der Fall gar nicht erst bei den richtigen Leuten deponiert wurde, das Security-Team hat erst durch die Veröffentlichung von dem Fall erfahren, deshalb sind die Angaben, die angeblich von IBM stammen, derart ungenau, um nicht geradezu zu sagen, fahrlässig unvollständig bis gefährlich.

[Glombi]

Und einfach mal so eine Maskenoption des N&A zu ändern,

Formulareigenschaften "Generate HTML for all fields abgeschaltet werden”

hui - viel Spaß damit, mit diesem Workaround fängt man sich hundert mal Fehler ein, als die man behebt.

Im IBM Artikel steht:

To disable the display of hidden field values from View Source in the browser, open the Person Form in the Domino Designer. Select Design -> Form Properties. On the second tab, disable the option to "Generate HTML for all fields." When this setting is disabled, the values of all hidden fields on the document will not be displayed.

Andreas

[Semeaphoros]

Andreas, ob das eine gute Idee ist, wird auch IBM-Intern angezweifelt.

[Glombi]

Andreas, ob das eine gute Idee ist, wird auch IBM-Intern angezweifelt.

Entweder sagt IBM, dass ist ok oder das ist nicht ok. Warum das Zweifel bestehen ist mir nicht klar.
Und in dem IBM Artikel kann ich keinen Zweifel erkennen - oder soll das der geneigte User zwischen den Zeilen lesen.

Das überhaupt Passworte in Personendokumente geschrieben werden, ist ansicht schon sehr heikel. Ich denke da nun an die Notes-User, die per Notes-Client innerhalb eines Unternehmens auf die Personendokumente zugreifen können. Wenn dann das "gesalzene" Passwort nicht gesetzt ist, kann ein böswilliger User schon mal versuchen, dass Internetkennwort vom Chef zu erraten.

Andreas

[Semeaphoros]

Das ist alles klar Andreas. Dass die ungesalzenen Passwörter noch existieren liegt daran, dass es Fremdapplikationen gibt, die dieses Passwort nutzen, die würden "brechen", wenn man plötzlich nur noch die gepfefferten PWs zulässt. Das spätere Beseitigen von Funktionalitäten, selbst wenn sie fragwürdig sind, ist halt nun mal ein riesiges "Nightmare". Und hier haben es die Endkunden ja in der Hand, das selber zu stopfen.

[0xse]

Man nehme den Domino Hash Bruteforcer oder halt Brutus/John mit Addon, eine gute Wordlist und warte ein paar Minuten. In der Regel werden damit alle Passwörter geknackt

Bruteforce ist bei dem 256 Bit Hash eigentlich Zeitverschwendung.

Sollten Kunden Webzugänge haben, sollte man ihnen einfach den Zugriff auf's Adressbuch sperren. Wenn ein Mitarbeiter sowas macht, kann man ja immer noch in den Logs nachgucken welcher es war ^^