[#thread š§µ] For this third day of #CyberAdvent (3/24), I'll tell you a story. The story of how I gained root access to a server by leveraging a really fun feature in a web application. This #pentest#writeup will explain the complete process from recon to root. š¦
[#thread š§µ(2/9)] In the recon phase of my pentest, as usual I was performing a port scan. In the output from nmap, I saw an uncommon port 86 with an HTTP server running "Micro Focus DSD 1.0.0":
[#thread š§µ(3/9)] When going on the page from a browser, surprise š„³š we have an unauthenticated access! This is cool, but I never saw this app before so I didn't know whether we could exploit it simply or not!
[#thread š§µ(4/9)] This application allows to manage #COBOL applications, like what Apache Tomcat does with Java applications. Let's mess around with this!šµļø
[#thread š§µ(5/9)] When we create a new application, we have a "Script" tab allowing to create a start/stop shell script that will be executed before/after starting the COBOL application.
[#thread š§µ(6/9)] We can execute commands on the server, but we do not have any output. And š± there is an unbelievable option on this tab. "User id", we can literally choose the user id the script will run as. I'm going to use uid=0 to run commands as root!
[#thread š§µ(7/9)] As the remote machine was an IBM server with ksh shell, I had to write a reverse shell by living off the land because classic payloads (even compiled static binaries) did not work. So I wrote a wget reverse shell during the night, and I tried it the next morning
[#thread š§µ(8/9)] Basically, it's a while True loop receiving and sending data in base64 through the User-Agent http header with wget:
[#thread š§µ(9/9)] I used my wget reverse shell as root to create a new user on the machine, and set its password. After this, I could simply connect with SSH to the machine, and boom I was in ! I also added my user to the sudoers to gain complete control over the server ! šš„³šµļø
Complete technical details about the MicroFocus exploit is available on my website here:
[#thread š§µ] For this second day of #CyberAdvent (2/24), we will be talking about a common #PrivilegeEscalation when using the * (wildcard) in shell scripts. Almost everyone has used at least once the * (wildcard) in a shell script but what really happens with the #wildcard ? š¦
[#thread š§µ(2/7)] We will take as an example this shell script, performing a backup of a website using tar and a wildcard:
[#thread š§µ(3/7)] In this script, the shell replaces the wildcard with matching files from the current directory then executes the command. The * character is never sent to the command (TAR in our case) instead a list of matched files will be sent as arguments to the command.
[thread] Did you know that ssh tries to authenticate with stored keys BEFORE the key specified with -i in the command line ? I just noticed this, the hard way š.
Let's imagine you have more than 5 keys loaded in your ssh agent. When authenticating to a remote server, you get:
After this message, ssh tries to authenticate with the keys in the order listed above. Why is that a problem ?
Because most servers have a default configuration with MaxAuthTries set to 6. After 6 tries, you will get a "Too many authentication failures" error.
So, ssh tries to authenticate with the keys in the order listed above, but gets disconnected after 6 tries. This means that if your agent has more than 6 stored keys, the key specified with -i is never used. This means you can't login to a remote server and you might not know why