IBM Domino (formerly Lotus Domino) is a particular interesting (and lengthy) setup. The build is not terribly complicated, but the software has been vulnerable for a long time, so it’s definitely worth exploring. We might as well have titled the blog “Building a Domino Box” with the vulnerability simply assumed.
This box was also featured on the final for my university students (one of the more point-worthy boxes). The exploit itself is multi-step but not terribly difficult to get through. We fairly regularly encounter this exposure on assessments; in fact, every time the team has encountered a Lotus Notes/Domino server on an engagement since I have been at RSM, at a minimum, a compromise of the email server has resulted (and it is more often than not the first step in a full domain compromise).
What is Domino?
Domino is the server component of a collaborative software package currently offered by IBM. Originally created by the Lotus Development Corporation and released as “Lotus Notes” in 1989 (IBM Notes now refers exclusively to the client portion), the suite now includes email and calendar functionality, file sharing, and instant messaging among a host of other benefits.
Historically, Domino has not been a shining example of best security practices. Over the years, numerous exploits targeting Domino have been released. The exposure we’re going to cover, however, has more to do with broken functionality.
With a valid username and password, an attacker can log into a specific page (URL/names.nsf) and obtain the password hashes for every other user regardless of privileges.
You read that correctly.
Once the box is built, a user will be able to take the following steps to compromise the machine:
- Use default credentials to log into names.nsf
- Retrieve the password hash for an administrative user
- After cracking the password, use the credentials to log into webadmin.nsf
- Execute commands on the backend system through the Quick Console function
Let’s take a look at the build process. I would like to stress that this is the most up-to-date version of Domino available.
The Setup
The first step is to download the Trial version of Domino. Head to IBM’s Trials and Downloads page. You’ll be required to register before doing anything. I recommend using a throwaway Gmail account rather than a Mailinator or other temporary address. I have not have any luck with the latter. The registration process will complete without any issues, but when you go to log in to download Domino, you’ll be greeted with an “Account Does Not Exist” page. I have not encountered any such issue using Gmail accounts.
Download
As always, I recommend using a separate virtual machine for each Vulnerable Box build. In this case, I have chosen Windows 7 32 bit. The platform is not specifically listed in the Domino-supported platforms (see screenshot below), but I have not had an issues thus far. Obviously, you’re more likely to encounter this on a server, but the exploit process won’t really be any different if you’re planning to use this as a teaching (or learning) tool. When you select the appropriate version (top-most is the current, up-to-date version, v9.0.1), scroll to the bottom of the screen and click “Continue.”
You’ll be asked to give additional information as to your purpose for downloading the software. Fill in whatever you’d like and click “Confirm.” At long last, you will find yourself on the actual download page. I would recommend using the HTTP download option rather than the Download Director which requires Java (though you’ll have to install and update Java during the installation process anyway, so you may as well get started now).
Installation
Running the executable will kick off a standard installation. You will first be asked to choose a temp folder. Feel free to click through until you are presented with the window below.
I would recommend going with the defaults for the Domino and the Data directories (C:\Program Files\IBM\Domino and C:\Program Files\IBM\Domino\Data respectively). Be sure to select the “Domino Enterprise Server” which includes both messaging and application services when given the choice.
The installer will drop two shortcuts onto the desktop. One is for spinning up the server, and the second is a console application for the server.
After the installation process completes, double-click on the IBM Domino Server shortcut to start the process of setting up your new server. Since this will be stand-alone, click the corresponding radio button.
Click through the installation process and set values appropriately. When you arrive at the Administrator name and password screen, I would recommend setting a “crackable” but not necessarily “guessable” password. Additionally, I would use a non-standard name. The goal will be for the student to guess the password for a user, retrieve the hash for the actual administrator, and then crack that hash to obtain the password. In this case, my chosen administrative user is “leader.” The non-privileged user will be “admin.”
Note: The reason for the switch is simple enough. On a real pentest, usernames are normally retrieved using OSINT. Accounts are recovered by running the resulting list of employee usernames against weak passwords. Since we will not be using a valid company (thus no OSINT), we can simulate the required step by using an easily-guessable password for a standard account name (in this case, “admin”).
Make sure to click all of the check boxes on the following page (HTTP services must be enabled). I would also recommend customizing your hostname to match the domain name set earlier.
Once the server setup process has completed, double-click on the IBM Domino Server shortcut again. This will allow you ensure that the services run at system startup. Double-click a third and final time to manually run the service (a system restart would do the same thing at this point).
Open a web browser on the local system and browse to http://127.0.0.1/ to make sure everything is up and working.
Ensuring Vulnerability
Now, from your host, browse to the server’s IP address to make sure you can hit it. If you’re greeted with the same screen as displayed above, add “/names.nsf” to the end of the URL. You should be prompted with a login box.
Enter the administrator credentials you created during the installation and setup process. Names.nsf is a database of all email users on the server. It is a database of one at the moment, but we’re going to change that. But first, however, let us take a look at the exposure that your target audience will be exploiting.
The Exposure
From within Names.nsf, click on your username (if you skipped ahead and added a username, click on any of them). You will be dropped into that user’s Basics page. Right-click in the frame that dominates the screen and select “This Frame” and then “View Frame Source” (I used Firefox for these demos, but all of the major browsers include similar functionality).
Within the source, look for the hidden field named “dspHTTPPassword.” The character string you see in parentheses is the selected user’s password hashed using dominosec (John the Ripper Jumbo supports this).
The important thing to remember is that any user, administrative or not, can get to these values when default permissions and provisioning are put into place.
Add Some Users
Our administrative user does not have a default username, nor is the password guessable, assuming you followed my lead earlier. We will now add a user to Names.nsf with a “default” username and easily guessable password as a jump-off point for our students.
Make sure your Java security settings allow for the plugins on this site to be used. You’ll have to close and re-open your browser if you change the settings with the browser still open.
Once you have logged in with your administrative user, click the “Add Person” button at the top of the screen. Edit the fields as you see fit. The important ones to hit are completed in the screenshot below. I would recommend simply copying the values from your administrative user’s profile and changing the name where appropriate. Remember that we want this user to appear to be an administrative user and use easy-to-guess credentials (I chose admin/password). Add additional users as you see fit.
Your new users will have access to names.nsf by default but not webadmin.nsf.
Webadmin and the Quick Console
Once your users are added, head to URL/webadmin.nsf. I have had the most luck with Firefox on this particular application page. Log in using your administrative user account. Your added users will not have access to this page by default.
From the main screen, click on the “Server…” button in the top bar. You’ll find the Quick Console on the left.
Note: There is a Live Console available, but it is disabled by default. I have not had any success enabling it, nor have I seen it enabled in the wild. The Quick Console will suit the needs of the exercise, in any case.
Typing “help” into Quick Console’s “Domino Command” box shows all of the available options. The one in which we are most interested is “load.” This will allow you to execute operating system commands via cmd.exe. Unfortunately, it will not let you see the output. Note that there are ways to redirect your output so that it can be read in other ways, but I’m not going to cover those. Feel free to explore.
The steps to compromise (one option among many) from this point are very similar to the Rejetto HFS exploit we reviewed in the last post.
load cmd /c net user testuser testpass /add
load cmd /c net localgroup administrators testuser /add
Simply psexec to the target machine or use remote desktop with your created credentials.
Storage
Be sure to drop this build onto your ESXi server with the rest of them. Domino can be loaded onto a variety of operating systems, so it may be worth your time to try different flavors.
I haven’t decided what’s on deck for next time. If you have any recommendations or requests, don’t hesitate to tweet them my way.
