HTB - Beep

Linux | LFI

Tools For This Room

• Local File Inclusion attacks - basic understanding of LFI will be helpful for this room - Acunetix's writeup on basics of LFI

TL;DR / Executive Summary

1. Scan and enumerate with nmap

2. Gain foothold with LFI

3. Privesc using SSH

Scanning & Enumeration

As is tradition, we start off with an nmap scan

• nmap

nmap -sV -sC -vv <IP>

We get quite a number of open ports back on this. 22: SSH 25: SMTP 80: HTTP 110: POP3 111: Open Network Computing Remote Procedure Call 143: IMAP 443: HTTPS 993: IMAPS (secure version of IMAP) 995: POP3S (secure version of POP3) 3306: MySQL 4445: I2P HTTP/S Proxy 10000: Network Data Management Protocol

Our full nmap scan yielded one extra port. 879: unknown

Gaining Foothold

We check out port80 and find this page:

After some quick checks, the IP is correct and other users have also come across this warning due to an expired certificate. Let's go ahead and visit the site anyway, to find this page:

We get a login page for Elastix which is a unified communications server. Although we don't have a version, let's do a quick search for any vulnerabilities.

searchsploit elastix

Let's check out the 'graph.php' LFI. and see if there's anything useful.

nano /usr/share/exploitdb/exploits/php/webapps/37637.pl

We get the sequence from the .pl file and append it to the login page URL.

https://10.10.10.7/vtigercrm/graph.php?current_language=../../../../../../../..//etc/amportal.conf%00&module=Accounts&action

The page which is generated is not formatted, but it's essentially the page source. So if we check out the page source, we'll find it neatly formatted for us to read.

If we look closely, we notice a recurring password "jEhdIekWmdjE", with various usernames.

Let's try this password with different usernames on the login page. We hit the jackpot with admin/jEhdIekWmdjE.

Privilege Escalation

At this point, we could try to figure out a way to upload a file and get a reverse shell, but since SSH is available on port22, let's see if these credentials are valid there too. However, we get the following response:

This means that there's a mismatch of key exchange algorithm between the client and server. In this case, the server is offering the diffie-hellman-group1-sha1, but OpenSSH does not use this by default as it's not secure. More information about this can be found here. The solution to this is to use the following command:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@10.10.10.7 -p 22

Unfortunately, the combination of admin/jEhdIekWmdjE does not work. However, we noticed that the password is re-used across different usernames in the view-source page.

When we try the combination of root/jEhdIekWmdjE, we're successful!

Let's pick up the user and root flags.