This is the sixth blog post in a series documenting various bugs found in installed software during customer engagements. Vulnerabilities will be published, when the vendor has provided fixes, or our deadline for the vendor to take action expires. This process is aligned with the Improsec Responsible Disclosure Policy.
In these blog posts I tend to be a bit verbose and give some insights into the process. Concrete exploitation steps and code is listed at the bottom.
CVE-ID:2018-1435
IBM Bulletin:IBM Notes Remote Code Execution Vulnerability (CVE-2018-1435)
After looking at the opportunities for privilege escalation in IBM Notes, I decided to give the actual Notes client application a quick look, from the perspective of an attacker seeking code execution through a malicious link or email.
Looking at the filetypes registered to the application, I decided to explore the nsf file type. Some of the other type were generic types that could be registered to other applications, like Outlook, in installations found in enterprise settings, and I wanted an attack surface specific to IBM Notes.
The nsf file type is a complex format featuring both database, user interface and various forms of code, like LotusScript and Java. Notes include some safety measures to account for the dangers of running unknown code when opening nsf files, and by the default settings, you will not be able to execute code in a database signed by an unknown signer (as an attacker would be), without the user explicitly allowing this, similar to macros in Word.
Figure 1: Unsigned databases are limited in what they can do.
I played around with this a bit and found no obvious methods of circumvention.
I thought about fuzzing, but the process of loading a database involves at least three processes and some inter-process communication, so some work would be needed to set up an effective fuzzing session.
Not wanting to spend further time or coming up empty handed, I reverted to the quick and dirty method of using Procmon to look for possible DLL hijacking scenarios. I quickly found one in the nlnotes.exe process.
Dll hijacking is often used in Privilege Escalation scenarios but can have a use in client side attacks as well. Now, this vulnerability is somewhat restricted in its use, as it requires the user opening the file to have the current directory set to an attacker controlled folder. Clicking a link in a mail will not suffice. The following two attack vectors could be used, though:
The user receives a mail with a link to a Windows share and an instruction to find the database there. The user clicks the link, the share is opened in explorer, and the user opens the nsf file.
The user receives a zip-file containing the database and a malicious dll (and maybe more legitimate looking files to make the dll blend in). The user extracts the zip-file and clicks the database in explorer.
In this case the DLL will end up being loaded in the user’s process. The database can contain some valid content to avoid waking suspicions and will not crash when the malicious dll is loaded.
Recommendations
Apply the patch/fix provided by IBM in the related Security Bulletin (see above).
TL;DR
Exploitation steps:
Create a malicious dll called ndb2key.dll and place it in a folder containing a nsf file.
Have an unsuspecting user double-click the nsf file in explorer.