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


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

NCL Summer 2015 Skyline Thoughts and Challenges Walk through

NCL recently ran a pilot to introduce there new skyline platform. Although this will likely be the NCL Summer 2015 competition i’ll be able to compete in, I wanted to give my honest opinion on the platform and walk through some of the challenges that I thought were well done.


First of all I find that this new Skyline platform had far better performance then old NCL scoring engine. This is likely due to the lower number of players in this summer round, but I hope the stability remains. Additionally, I thought the step by step approach with hints available will make challenges far more approachable to player who are new to the infosec competition space. My only real criticism would be the web app challenge, having it embedded into the skyline interface made it much harder to work with. In the further maybe still host web app challenges in AWS.


QR Code Images

There were really two very similar QR image challenges. These were among my favorite present, in this NCL round. Since some of the guided questions were very similar I will just cover them once. Now the latter image is given to you in 4 pieces and you are meant to use your forensic skills to reassemble the image based on some hex headers, footers, and commonalities. However, I just wrote a quick script to cat each of the files together in each of the possible permutations; then just opened the one that showed a valid thumbnail of the image.

What is the md5 hash of the image? In both chases the following command on that trust kali box will get you the

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