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:
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.
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.
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.
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.
Attack vector: Local network
Impact: Information Disclosure