Nuova Vulnerabilità su Domino

NEWS TIPS ADMIN bug attack attacchi violazioni violazione

  • 3 commenti
è di pochi giorni l'uscita sul sito di IBM di una recente vulnerabilità che affligge le versioni R5.x; R 6.x; R6.5.x e R 7.x di Domino. Secondo questo articolo parrebbe che avendo esposta (pubblica) la porta 1352 di un server Domino (che vi ricordo è la porta propietaria che i server Domino e client notes usano per lo scambio di dati) e avendo le ID degli utenti allegate al documento persona è possibile sferrare un attacco volto a trovare e scaricare tali ID. Ovviamente poi l'ID scaricata deve essere a suo volta attaccata con un brutal force attack per determinarne la password e quindi poter accedere al sistema con le credenziali dell'utente.

Il "BUG" sfrutta una funzione interna dei server che viene normalmente utilizzata da un client notes alla prima configurazione. In questa condizione il client fa un lookup (diciamo anonimo) su tutti i documenti persona per individuare quello del utente che si va configurando e poi esegue il download della ID se attached.

Personalmente la ritengo una vulnerabilità molto difficile da sfruttare dato che la condizione fondamentale è che le ID siano attached sui documenti persona (e questo può essere comprensibile solo per gli utenti acnora da configurare) e le stesse dovrebbero avere una password semplice. Ad ogni modo lascio a voi la sentenza finale...

L'articolo ufficiale lo trovate a questo link:

IBM Lotus Notes information leakage on port 1352

 Technote (FAQ)   Problem Andrew Christiansen contacted IBM® Lotus® to report a potential vulnerability in unauthenticated transactions using the Notes Remote Procedure Call (NRPC) protocol on port 1352.

The advisory address is as follows:
http://www.fortconsult.net/artikler/advisories.php

The NRPC protocol uses an unauthenticated transaction to look up a user who is not yet authenticated so that the user can fetch their ID file during Notes® setup. This transaction is optionally used when a user is first registered or when a roaming user connects from a new client.

As described in the advisory, it is possible to construct a list of possible user names and attempt to validate them using the unauthenticated name lookup transaction. If the user name exists and the person record contains an ID file, it is possible to download the user ID file. The attacker must then successfully execute a brute force attack on the password in order to use the ID file.

  Solution This issue was reported to Quality Engineering as SPR# KEMG6R8JBF and has been fixed in Domino® 7.0.2 and Domino 6.5.5 Fix Pack 2 (FP2). The fix requires setting the "BLOCK_LOOKUPID" variable in the server's notes.ini file. There are two settings available.


BLOCK_LOOKUPID=1

If the name lookup unauthenticated transaction finds the requested person but no ID file, the error message is changed from "No ID file found for this user" to "User not found in Directory" so that this transaction cannot be used to verify the validity of a user name in the directory that does not have an ID file. When this is enabled, setup can still fetch ID files and Roaming User can still fetch ID files.


BLOCK_LOOKUPID=2

If the name lookup unauthenticated transaction is performed, it will always return "User not found in directory". This completely prevents all the attacks described in this advisory/SPR. However, it also prevents new client setup using ID files in the directory from working. It prevents Roaming User setup from working. This setting can be used if new users are physically given their ID files and Roaming User is never configured to delete local files on exit.


Mitigation:

To mitigate risk, administrators should ensure that ID files do not remain in the Domino Directory for extended periods of time or use an alternative method of distributing ID files to new users. Strong initial passwords should be applied if distributing ID files to users via the Domino Directory.


Recommendations/options for protecting the ID file:

1. Enforce the use of strong passphrases. Administrators can control the strength of the user's passwords by configuring password policies. Options include use of the password quality algorithm (R5x, 6.x, 7.0x) or custom password policies (6.5.4/7.0 and higher).
2. Use custom password policies to "enforce password change on first Notes client use". This feature is available for Notes/Domino 6.5.4 and 7.0 (and higher).
3. Consider enabling password checking (and expiration) on the server.
4. Consider use of Smartcards to protect the ID file as an alternative to passwords.


Auditing the Domino Directory for ID files that should have been removed:

In general, the ID file is deleted from the user's Person document after initial Notes setup has been completed. This happens on the user's mail server and should replicate to the rest of the servers in the domain. In some environments, however, an administrator may have configured replication such that document changes made on the user's mail server are not allowed to replicate to the hub server(s). In this type of situation, the ID file(s) may remain in the Person document(s) on some servers.

Administrators can create a new view (this can be a private view) in the Domino Directory based on the Person view. Ideally, this should be done on the Administration server which has the ability to replicate changes to all other servers. Enter the following formula as the View Selection Formula:

SELECT Type = "Person" & $File !=""

This will display Person documents which contain ID files. If the user(s) have already run Notes setup and the ID files should not be stored there, the file attachments should be manually removed from the Person documents.

Additional Information:

Attack vector: Local network
Impact: Information Disclosure

3 Commenti:

  • #1 mere 11/18/2006 2:32:31 PM

    ok... siamo tutti d'accordo.... Giuseppe è un precisino ;)

  • #2 ignazio 11/18/2006 2:29:14 PM

    Giuseppe ha ragione, .... è un precisino!

  • #3 Giuseppe Grasso 11/18/2006 2:25:59 PM

    una precisazione, la porta 1352 è assegnata alle comunicazioni client/server lotus-notes/domino secondo registrazione IANA dell'ICANN, vedi: { Link }

    (lo so, sono un precisino.....)

Commenta articolo
 

Questo spazio web è stato creato da per un uso pubblico e gratuito. Qualsiasi tipo di collaborazione sarà ben accetta.
Per maggiori informazioni, scrivete a info@dominopoint.it

About Dominopoint
Social
Dominopoint social presence: