What is a CTF?

A CTF(Capture The Flag) is a gamified hacking competition which allows people to practise hacking techniques in a safe, legal and ethical environment. “Flags” are placed in different locations for the player to find by a number of different methods. These can be thought of as sensitive data inside either an organisation such as PII, Bank details or anything that a company does not want to be seen. This teaches security professionals and security curious people different techniques that are used by real hackers to gain access to networks and systems.

Disclaimer

This blog is not to be used to teach anyone how to perform illegal hacking against the system. All hacking taking place in this blog is done against a machine that I am legally allowed to perform these techniques against.

Bounty Hacker (TryHackMe - Easy)

Questions:

Walkthrough

As a pentester, the first thing performed on a test like this is port scanning. Attackers and pentesters will do this to your network to find out about the system’s network services that are available to communicate on the network. From this, it is possible to start understanding the machine's purpose and what potential vulnerabilities and attack surfaces it has.

Nmap is the most common port scanner - not only due to it being open source and free but also its wide usability and added scripting potential.

Doing a simple command like this returns the top 1000 common ports that a machine can have open to a network using TCP.

If we use the “-sV” flag, Nmap returns the banners of the open ports giving us some insight as to what is running and their versions. This time however I wanted to take it a bit further and show the “-A” output. This returns a lot of information on a system and its open ports such as versions of OS and services by enabling Nmaps OS detection, version detection, script scanning, and traceroute.

Vulnerabilities found: Lack of network monitoring/protections

From this we can see a standard web application, SSH, and FTP. We then have the basic attack surface we will need for the CTF. Also, a simple script scan has been run and returned some interesting information. Nmap scripts are what make Nmap go from a simple port scanning tool to a networking tool powerhouse. However, if used against systems you do not own/have the legal right to test, can land a user in legal trouble https://nmap.org/book/legal-issues.html. Without going into too much detail or what is legal (can be a you should only scan/attempt to hack targets that you are legally allowed.

To demo this further I will run a specific .nse script called “Vulners”.

Vulnerabilities found:Out of Date Services

This shows us a large number of CVEs for each open service which took the banner message and matched them against the online database. This can give you a quick way to find exploits and ways into systems. For now, however, we will move on.

Now if this were a pentest we would need to go further in this stage, checking for more ports as there are a total of 65,535 TCP and UDP ports that could be used for network communications.

For this, we can run Nmap with the following -p0-65535 or the more commonly used -p-, a flag which covers 1-65,535 ports (however, it does miss a port 0 which has been known to be used in malware)

The findings show no new ports, so now we can move on.

The next requirement for recon during a pentest is checking for UDP open ports; this can be done again with Nmap with the “-sU” flag. (Please note due to this being a CTF and how long it takes to perform a UDP port scan, I only used the -F flag to only scan 100 ports for demonstration)

This would be enough to confirm the completion of “Task 1 question 2”

Further steps we could take if this were a pentest, would be to monitor network traffic. This can be performed using tools such as Wireshark/TCPDump passively or more active/offensive tools such as responder. Seeing what traffic is on a network can help identify weaknesses such as plain text communications, poisonable SMB signing requests and even normal activities of workers such as internet usage. As this is a CTF however, there is no traffic other than my own so we cannot perform these tests. The next common step in a standard pentest would be to run some form of vulnerability scanner such as Nessus against the scoped machines. This is used to find the low-hanging fruit and give the tester a baseline to work against for the manual testing.

As I have already run Vulners against the open ports I wanted to show another tool output. Nessus Pro is an industry-standard vulnerability scanning tool. This can be deemed expensive to use as a tester as it requires a yearly subscription, however for home use they do offer a “Nessus Essentials” that allows the scanning of up to 16 IPs. A pentester will normally always do some form of VA scan whether it be with Nessus or another tool, this is to catch “easy wins” and to gather as much information as possible in the shortest time. Automating this gives a pentester a starting point to identify weaknesses and where they can branch out from the profound exploitable systems.

Running an external (none non-authenticated scan) against the system found a large number of vulnerabilities broken into a small number of categories, The more systems and open ports the more categories you may be likely to see here.

Looking into these categories we can see the system has many high and critical rated vulnerabilities due to the system being unpatched for many years. An attacker could use any number of these to attack and compromise the system.

Now we have our recon performed and know our attack surface and likely vulnerabilities we may encounter we can move on to testing. We will now let's investigate what services are running and what information we can get from them.

Port 80 HTTP

If this was a normal website on the internet, and there were multiple known vulnerabilities on an exploitable user input this could be disastrous. From this, we could be able entirely to take over the system. However, in a real pentest this could get overlooked as custom web applications may be out of scope for testing. If this was a system-specific service such as a switch web login, or an HP iLO then standard testing may be performed, such as default/weak password attacks and version checking. It is always good practice to manually check internal intranet pages separately in pentesting to look for specific vulnerabilities they may pose. As this is a CTF we will now be diving into Web application pentesting. For a web application pentest, we first need to perform recon just like on a network pentest. We can do this in a number of ways, but the first is simply visiting the website. A pentester cannot test a website they have not seen, so it is likely that the first 5% of any web pentesting is performed simply by the tester running automated scripts and manually navigating around the application as a user to find the attack surface. One example of Tools we can use is called Nikto, which is a simple web and CMS scanning tool. We could also use Nuclei or even Nessus. This can give pentesters and hackers alike vital information quickly about the target. While we are not looking at this service in depth today for a pentest we still need to perform recon. The first thing we can do is look at the headers and source code of the application.

Vulnerabilities found: out-of-date Apache software/ cleartext communications

In the background I have run an automated directory-busting attack using a tool called Dirb. There are many tools which perform these tasks such as Gobuster, Feroxbuster, and some are even built into Burpsuite. However, being old-fashioned and due to its simplicity for the CTF I have used Dirb. Directory busting is a recon attack which automates finding pages and directories on a given URL/IP which may not be spiderable from the main index page. It can uncover hidden functionality and even reveal hidden admin systems that may have been forgotten about.

As we can see, not much has been found on the HTTP outside of the normal for an Apache server. The “server-status” is a common page that can fingerprint the server stack in this way. There is however, one potentially interesting part of this response, which is that the /images folder is listable. This could show files that the website designer/developer could have forgotten to remove from the App or secrets such as images used in authenticated parts of the system.

Vulnerabilities found: Listable Web Directorys

As can be seen the directory is listable, however, it gives no further information or potential hidden files that we have not already seen. While looking for other folders the following 404 page is found:

Vulnerability found: Verbose error message

This gives us further confirmation of the Server Version previously found, which while vulnerable, we do not wish to further attempt to exploit at this time so we will move on to the next service found on the system.

port 22 SSH

While we have already used Nmap to fingerprint this service, we can first perform a simple banner grab technique to verify this manually. Using Netcat we can make a simple connection to the port to retrieve the banner:

Vulnerability found: out-of-date Ubuntu/services running(OpenSSH)

We now confirm this is a standard SSH service by attempting to connect, and we find everything seems ordinary, so we can move on to attempting to attack this service:

Vulnerability found: SSH password authentication/root login possible/ no SSH lockout detected

Now we confirm this is standard SSH. We can perform multiple different types of attacks. First, we identify the service is out of date so we can attempt to find known vulnerabilities and exploits online. One Exploit is SSH user enumeration possible. However, when attempting this, it was found to be not possible on the machine with common tools. As this is an “easy” ranked CTF, this is not the method so I move on.

The next option, if this had worked or we have an idea of what names are used, could be to attempt to brute force the authentication. Doing so may find weak passwords in the management of the system. At this point and testing SSH, however, this is currently a brick wall and nothing further we can attack.

Port 21 FTP

In the past of the internet, many web server providers had FTP for users to upload and edit files on their site, meaning it was a common service on the Internet. If you still use this service, it is highly recommended to move to either SFTP or FTPS depending on your use case. Either way, ensure strong passwords or key authentication, with monitoring and lockout features where possible, should be enabled.

Like with web applications we can fingerprint the service. While we have already used Nmap to fingerprint this service we can first perform a simple banner grab technique to verify this manually. Using Netcat we can make a simple connection to the port to retrieve the banner or attempt to connect with FTP:

Vulnerability found: Cleartext communications/out-of-date services running(vsFTPd)/ Anonymous FTP login enabled

Now I have confirmed this is standard FTP we can perform a number of types of attack. First, we identify the service is out of date so we can attempt to find known vulnerabilities and exploits online, however, while this is missing several patches there is no known vulnerability we can exploit at this time. The next option is to attempt to enumerate users or if a username is known, attempt to brute force the authentication. Doing so may find weak passwords in the authentication of the system. The last potential “easy” exploit we can test is actually a feature in FTP called “Anonymous log on”. This allows the system admin to allow anyone to log in with the Username “Anonymous” and an email address as the password. Anonymous FTP access, while was in this instance and still is at times chosen behaviour for some system admins, can be deemed a severe configuration vulnerability in most systems. As you can see from our screenshot and previous recon, we know this is possible on this service. So we can log in as “anonymous” and verify the connection, doing a simple “ls” command shows two files shared on the server.

First, we need to download these files which is done with a simple get command as we are authenticated. Next, we can read them both.


Task.txt shows an in-universe note which gives us the answer to “Task 1 question 3”. It also gives us 2 names and a “project” name which can be used as insider information or a user list of brute force in accounts.

Vulnerabilities found: Bad User password storage

From downloading the second “locks.txt” it appears to be a wordlist and the name also hints at this. This would be like finding a user's “passwords.txt” or another form of password storage giving an attacker instant pivoting abilities into other systems or applications. As this is a CTF and there is only one system in scope we can try this list against the other service on the machine.
Now with this information, we need to look at what service we can bruteforce. As we saw previously the machine has SSH open, as I do have names and a potential password wordlist we can try this next. To do this there are several tools such as Hydra, however, because I already have Metasploit open I will use this.


Using the module auxiliary/scanner/ssh/ssh_login I can set the tool to test chosen usernames and any number of wordlists against the target machine shown in the options above.

Vulnerability Found: Weak Passwords

Using the verbose flag we can see each attempt to authenticate with the SSH and it stops when it finds the correct username/password. This has answered “task 1 Questions 4 and 5”.

Now we can log into the system and read the user.txt flag


This has completed the “task 1 Question 6”, gaining us our first flag.

Now we move on to the last part of the CTF. Here we are required to escalate privileges on the server and gain access to the root account to read the root.txt. To go about this, I attempted some standard checks on the system from looking at SUID values, to attempting to read the values of sensitive files such as /etc/shadow. As this has been a short CTF I want to show a tool that hackers and pentesters alike use to help find privilege escalation techniques. From their Github: “LinPEAS is a script that searches for possible paths to escalate privileges on Linux/Unix*/MacOS hosts. The checks are explained in book.hacktricks.xyz”. There are also versions released for other OS’s such as Winpeas.

As I want to run the full latest version of this tool, I first need a way to get this onto the machine from only an SSH connection. Looking around the tools installed on the machine I find the system has the minimal tools installed. This could indicate the machine has been at some point hardened or even just built for purpose. However, the more functionality a system requires the more potential exploitable services/applications it may have running.


As seen I find that the system has python3 installed which gives me the ability to use a locally hosted webserver hosting the linpeas.sh script and then download it using Python on the target machine.


Once downloaded it can be simply run on the machine and goes through a large number of different commands and attempts to find potential weaknesses in the system.


As we know from previous exploitation the system has anonymous FTP enabled, if we were an attacker who gained access to the machine, this could highlight the purpose of the system and give them a way to know that they could potentially share malicious files with other parts of the network and valid users.


Another example of the checks Linpeas can automate for users is the SUID and SGID settings of files. This is a very common Priv esc for CTFs and real systems alike and combined with GTFOBins can be a quick “win”.


As we have seen, the system is extremely out of date with a metric fuckton of known CVEs released. Linpeas while confirming this also gives us direct links to known working exploits which it has found the system to be vulnerable to.


Choosing one of these at random, we can download the exploit pack from GitHub, (I chose CVE2021-4034) and using the previous method we can then place the files on the system. Running the known working exploit as shown almost instantly gives us a root shell on the system. I have used this example to show how easy exploiting systems can be for somebody who has very little skill when they are left unpatched. In the industry these people may be called “script kiddies”, they can go out and download a bunch of tools with no idea what they do technically but still gain full administrative access to systems in a matter of seconds. If there is one takeaway from this part of the blog, it is PATCH YOUR SYSTEMS!


As this is a CTF and was released many years ago, these vulnerabilities are likely not to be the intended means of exploiting this system and gaining the privesc. Looking through the Linpeas output we see two common privesc roots which have not been populated. A “script kiddie” may (in a real attack) overlook this as there is no “red = bad”. As a senior pentester and Linux user I know these can be just as easy to exploit so I will go on to test for these.


As seen the lin account does not have the permissions to use su so this is a dead end. However, the Lin account can run tar as sudo. Using GTFObins we can quickly find that this can be used to escalate privileges.


Using the provided code from GTFOBins shown above gives us a newly opened shell as the root user via the tar command. Therefore, we now have the answer to “Task 1 question 7”


After all this, I can view the root.txt. In a real-world attack, this is unlikely to be a single-string text file; it could be your company's payroll, bank details, or sensitive client data - anything an attacker can find a monetary value in. If there is nothing to steal at this point, they now have root access to a system inside your network to plan further attacks or even pivot to other machines to spread ransomware and the possibilities are almost endless.

Pentest style management summary

During the penetration test, I found that Bounty Hacker appeared to be a simple message transfer system with little functionality and a small attack surface with few ports open and services running. However, in this small attack surface, an entire system takeover was possible via a small, easily repeatable attack chain. Due to this, I can deem this system to be a high risk to your organisation and requires immediate resource allocation to fix the vulnerabilities identified in this report.

While there were 3 High,3 Medium, and 2 Informational issues found by CVSSv3 score, the main high-risk issues are as follows:

While this is not the entire list of vulnerabilities, these are the leading cause of the system being taken over and require immediate attention, Most of these could be deemed as simple to fix on the current system.

The highest risk to the system is the lack of security patches. This led to a very simple priv esc attack from a known POC. This also meant that all services hosted were severely vulnerable to multiple high and critical CVE’s. It is highly recommended to first keep all systems up-to-date with the latest security and system patches. Without this, attackers could find and abuse many potentially known and documented exploits available.

While this system was found to not be accessible outside your network at this time, an attacker with access to the network via attacks such as social engineering or even a malicious insider could perform these actions with very little security knowledge or tooling as all parts of the chain are possible with simple online scripts and tools.

These were further escalated by no network monitoring protection, identifying suspicious traffic or functions on the network or server. While network monitoring would not stop an attacker, it could help identify an attacker in their original recon phase, which could have stopped attacks before they were performed.

On the system, there was a file called “locks.txt” which was found to be a list of passwords for both this and other systems. Having this in clear text means any user of the machine or process could access the file and retrieve those passwords. Passwords should be kept in a secure vetted password manager with a singular strong password. The risk was further increased by the file being publicly accessible on a clear text FTP server with Anonymous access enabled. This means an attacker does not even have to gain access to the machine to obtain this file.

As mentioned, the system is only used for what appears to be a single purpose, it could be replaced with a new and secure system quite easily without much disruption to the services. Using an up-to-date patched system with a secure server such as SFTP would give the same functionality found. The second highest requirement is user training around password security such as strong password use and secure storage.

Identified vulnerabilities

The following are examples of vulnerabilities found throughout the walkthrough that would be provided in the pentest report. Please note this is not the entire list of vulnerabilities, just a range of examples and how they rate in the CTF itself, not your application.

Out of Date systems

When testing the system, it was found that multiple parts of the system were running without the latest patches. This presents a considerable security risk to the organisation the longer they are left unpatched. It makes it easier for malicious actors to exploit them, which could seriously impact business operations. Some systems were found with known CVEs, which were not possible to exploit during the testing. CVE or Common vulnerabilities and exposures is a list of computer security flaws that are publicly disclosed and can be used to prioritise and address vulnerabilities in an effort to make systems more secure. The following were found out of date with an example CVE ID number:

CVSSv3 Score: 8.3 CVSSv3 Vector: CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Remediation: Ensure all patches are applied as soon as possible. If worried about patches causing downtime, first apply to a production machine to test compatibility, then once confirmed that no issues have been found, roll out to the live system.

Reference: https://www.linuxcapable.com/upgrade-apache-on-ubuntu-linux/

Bad User Password Storage

When testing the system, a txt file was found containing a list of user passwords. Having passwords stored on the system in such a way could potentially lead to an attacker getting hold of the file and therefore all the passwords contained. This file could be accessed unauthorised by several methods such as, Shoulder surfing the user accessing the file, a malicious process running on the machine could simply read the file, if the user was to leave the system unattended for a few moments.
This issue was made worse by the fact that the password list was accessible via the FTP service of the system which was found to have known vulnerabilities.

CVSSv3 Score: 8.5 CVSSv3 Vector: CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L

Remediation: Remediation: Do not store any credentials in clear text. Adopting a password manager for all passwords is considered the best advice for all password related issues, however this is not always possible. In a recent push, the information security industry is attempting to change the term “password” to “passphrase”, meaning instead of an uninformed user thinking “password” fits the criteria, teaching that different small secret phrases (12 characters and above) of unrelated but rememberable words should be used. When combined with a number and a symbol, this becomes almost uncrackable and non-bruteforceable in a reasonable amount of time.
Reference: https://saferinternet.org.uk/blog/password-security-understanding-the-basics

Clear text communications port 80/21

It was found that the web server only communicated over the HTTP protocol; this transmits data in plaintext over the network, allowing an attacker to intercept the communication at the network level. This gives an attacker the ability to read and modify the data transmitted, such as the login password for the application.
It was also found that the FTP service was running and sending communications in clear text meaning both authentication and file transfers were sniffable on the network.

CVSSv3 Score: 7.6 CVSSv3 Vector: CVSS:3.0/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L

Remediation: HTTPS should be used as it encrypts all traffic and proves the authenticity of the information by using certificates. This can be set up for free using tools provided by LetsEncrypt or with paid services.
FTPs or SFTP should be used if FTP service is required

Reference: https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/

Weak passwords in use

When testing, weak passwords were found for one user on the system. Passwords should always be used securely due to the sole purpose of what passwords are. It was found that the weak passwords were found in the SSH login of the system. While the user account was non-privileged, our attack chain demonstrates how this bad practice can be exploited.

CVSSv3 Score: 5.4 CVSS v3.1 Vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N

Remediation: Adopting a password manager for all passwords is considered the best advice for all password related issues, however this is not always possible. In a recent push, the information security industry is attempting to change the term “password” to “passphrase”, meaning instead of an uninformed user thinking “password” fits the criteria, teaching that different small secret phrases (12 characters and above) of unrelated but rememberable words should be used. Combined with a number and a symbol, this becomes almost uncrackable and non-bruteforceable in a reasonable amount of time.

Reference: https://saferinternet.org.uk/blog/password-security-understanding-the-basics

FTP Authentication weaknesses

No FTP lockout was detected. When testing, over 500 attempts were made to brute force the FTP password until it was found. This, combined with a lack of monitoring, means an attacker could easily perform as many attempts as required until the correct password is found, then impersonate the user on the FTP system.

The FTP service was found to allow Anonymous access. This allows a user to access the system without any form of unique or secure authentication. This also means it would be very difficult to monitor who has had access to files in case of an incident.

CVSSv3 Score: 5.0 CVSS v3.1 Vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

Remediation: Use SFTP and use SSH certificates for all systems with separate securely managed certificates.

Reference: https://nvd.nist.gov/vuln/detail/CVE-1999-0497

SSH authentication weaknesses

SSH is a remote management service which is widely used on many systems throughout the industry. While better than telnet due to its encrypted traffic, it can be configured in a way that's deemed insecure. The system was found to be lacking several security features which can make SSH auth potentially trivial to exploit. The following were found:

Password authentication was in use over the much more secure SSH Certificate. This is where a user has a key they log into the SSH with instead of a potentially weak rememberable password. Root login is possible on the SSH server, meaning if an attacker were to brute force the Root account password, they would have complete control remotely of the system. No SSH lockout was detected. When testing, over 500 attempts were made to brute force the SSH password until it was found.

CVSSv3 Score: 5.0 CVSS v3.1 Vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L

Remediation: Use SSH certificates for all systems with separate securely managed certificates.

Reference: https://smallstep.com/blog/use-ssh-certificates

No firewall, port scanning monitoring on the network

It was found that no network monitoring or protection was in place. If an attacker were to access the network, they could start performing scans such as those performed in this penetration test, but for malicious reasons. Some form of scanning firewall could be put into place to stop mass scanning. While using some form of SOC is not the be-all and end-all of security, it can identify attacks while they happen or at least log network activity in case an incident response is required.

Reference: https://network-king.net/best-network-monitoring-tools/

Web application security misconfigurations

Modern web browsers have multiple inbuilt protections for users, which can be enabled by a web application, such as: security headers, cookie security flags, CORs. While these do not directly protect the web application, using them as a defence-in-depth approach is a great way to add a final touch to your application's security for its users.

Security headers:

Security headers tell the user's browser details about that application and how it should deal with the data to protect against different attacks such as framing or XSS.

Remediation: Edit the Apaches enabled-site configs and set these headers.

Reference: https://securityheaders.com/

Info server header:

It was possible to identify the Apache server version and the OS running on the server via the Server HTTP header.

Remediation: Edit the apache2.conf and turn off ServerSignature and ServerTokens

Reference: https://ubiq.co/tech-blog/remove-server-name-apache-response-header/

InfoListable Directorys:

The application allowed directories to be listed. This could lead to sensitive or hidden files being leaked to an attacker.

Remediation: Edit the apache2.conf to “Options -Indexes +FollowSymLinks”

Reference: https://medium.com/@maheshwar.ramkrushna/securing-your-website-a-step-by-step-guide-to-disabling-directory-browsing-on-apache-ba77ce71914c

Verbose Error Message:

It was possible to identify the Apache server version and the OS running on the server via the error message returned.

Remediation: Edit the security.conf files to include “ServerSignature Off” and “ServerTokens Prod” then set “ErrorDocument” to a custom error page for all required HTTP response codes

Reference: https://httpd.apache.org/docs/2.4/custom-error.html

Conclusion

Tools/Techniques

The following is a list of tools and techniques used to solve this CTF.

Tools:

Dirb
https://www.hackingarticles.in/comprehensive-guide-on-dirb-tool/

NMap
https://www.networkworld.com/article/3296740/what-is-nmap-why-you-need-this-network-mapper.html

Netcat
https://www.varonis.com/blog/netcat-commands

msfconsole
https://www.metasploit.com/

GTFOBins
https://gtfobins.github.io/

Nessus Pro
https://www.tenable.com/products/nessus/nessus-professional

LinPEAS
https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS

Hacking Techniques:

Bruteforce
https://owasp.org/www-community/attacks/Brute_force_attack

Privilege escalation via Linux permissions
https://tbhaxor.com/exploiting-file-permissions-misconfigurations/

Directory busting
https://www.makeuseof.com/what-is-directory-bursting/

Privilege escalation via unpatched system application
https://book.hacktricks.xyz/linux-hardening/privilege-escalation

FTP anonymous login
https://henri-demanou.medium.com/exploiting-anonymous-ftp-access-and-ftp-brute-force-dccb07402b15



Blog home