Comprehensive Guide to Host, Port, and Vulnerability Discovery Using Nmap and Other Tools

I. Host Discovery

This attack specifies an IP and does not involve the host discovery process.

II. Port Discovery (Services, Components, Versions)

Using the command sudo -u root nmap 172.16.33.53 -n -Pn -p- --reason -sV -sC -O to discover open ports on the host, services provided, components used, and their versions.

Open Ports

Services Provided

Components Used

Component Versions

22/tcp

ssh

OpenSSH

7.9p1

80/tcp

http

Apache httpd

2.4.38

8082/tcp

http

nginx

1.14.2

os

Debian Linux

?

III. Vulnerability Discovery (Gaining Access)

Port 8082 / HTTP Service

Component Vulnerabilities

01. Middleware Component: No Nday vulnerabilities for nginx 1.14.2 were found using the command searchsploit nginx 1.

02. Application Components: Automated detection using browser plugins like Wappalyzer, FindSomething, and manual detection using tools like BurpSuite did not reveal application component information.

URL Vulnerabilities (Directories, Files)

01. Direct Access: Open the browser at http://172.16.33.53:8082/ to find only an image of bamboo.

02. Directory Scanning: Used the command dirb http://172.16.33.53:8082/ -R to scan directories and files, but nothing was harvested.

03. Fuzz Testing: Based on currently known information, fuzz testing of directories and files on the website is deemed unnecessary.

04. Information Gathering: All previous site visit traffic through Firefox used a BurpSuite proxy, with sensitive information analysis through the HaE plugin, but nothing fruitful was found.

This non-standard port ended up in a dead-end, despite great expectations.

Port 80 / HTTP Service

Component Vulnerabilities

01. Middleware Component: No Nday vulnerabilities for Apache httpd 2.4.38 were found using the command searchsploit Apache httpd 2.4.

02. Application Components: Automated detection using browser plugins like Wappalyzer, FindSomething, and manual detection using tools like BurpSuite did not reveal application component information.

URL Vulnerabilities (Directories, Files)

01. Direct Access: Open the browser at http://172.16.33.53/ to find only an image of bamboo.

02. Directory Scanning: Used the command dirb http://172.16.33.53/ -R to scan directories and files, discovering the /cms/ directory and its subdirectories and files, the /info.php file, and the /system file.

02-01. Opening the /cms/ directory redirects to http://172.16.33.53/cms/site/.

02-01-01. Automated component recognition using plugins like Wappalyzer, FindSomething and searching for Nday vulnerabilities for identified versions through searchsploit and search engines revealed no exploitable vulnerabilities.

02-01-02. Directly visiting http://172.16.33.53/cms/site/ reveals a static page with pseudo-links in the form of href="#".

02-01-03. Individually accessing subdirectories and files discovered in the /cms/ directory scan yielded no results.

02-02. The /info.php file opens to a phpinfo() page, which reveals information currently not exploitable.

02-03. The /system file is actually a /system/ directory requiring HTTP Basic Authorization to access, and surprisingly, a quick test with admin/admin was successful, redirecting to the Mantis Bug Tracker login page at http://172.16.33.53/system/login_page.php.

02-03-01. The application components detected with the Wappalyzer, FindSomething plugins are the same as earlier, hence no further exploration was conducted.

02-03-02. Found default credentials administrator and password root in the MantisBT 2.0 Admin Guide[2], but unable to log in.

Using BurpSuite’s Intruder to brute force username and password yielded no results.

Attempted to register an account to log in, which prompts email verification, but such internal systems can’t send emails.

02-03-03. Directory and file scanning using the command dirb http://172.16.33.53/system/ -R resulted in response code 401 Unauthorized. Interestingly, the prior account and password bruteforce attempt at Mantis Bug Tracker http://172.16.33.53/system/login_page.php did not require authentication.

Conducted a new scanning session using dirb http://172.16.33.53/system/ -R -u admin:admin, revealing some directories.

Examining each directory, only /system/config/ seems noteworthy. The a.txt file in /system/config/ matches the config_inc.php.sample file in content, suggesting it is an old configuration file of MantisBT with some parameters already set. Both files are the same size, whereas config_inc.php is significantly smaller, indicating the current file may not have modified credentials, only redundant comments and configurations removed. We’ll note down MySQL database credentials here: mantissuser/password@123AS.