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.
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
Assessing this vulnerability using the Common Vulnerability Scoring System (CVSS):
CVSS Base Score: 3.5
CVSS Temporal Score: 2.7
CVSS Environmental Score: Undefined*
Overall CVSS Score: 2.7
*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the referenced links below.
Base Score Metrics:
Related exploit range/Attack Vector: Remote
Attack Complexity: Low
Level of Authentication Needed: Not Required
Confidentiality Impact: Partial
Integrity Impact: None
Availability Impact: None
Impact Value Weighting: Weight Confidentiality
Temporal Score Metrics:
Availability of Exploit: Proof of concept code
Type of Fix available: Official fix
Level of verification that vulnerability exists: Confirmed
Complete CVSS Guide: