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

Agent Sudo (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.

Using 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.

Vulnerabilities found: Lack of network monitoring

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. However, 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 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 returns a filtered port 68 DHCP but attempting to connect shows this is not accessible.

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 this is a CTF, this is another step I will not be performing so some low-hanging fruit vulns may not be highlighted during this blog.

Now we have our attack surface of the machine answering “Task 2 question 1”. Now let's investigate what services are running and what information we can get from them.

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 a number of 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 these, however, this is currently a brick wall and nothing further we can attack.

Port 21 FTP

Or attempt to connect with FTP:

Vulnerability found: Cleartext communications /out-of-date services running(vsFTPd)

Now we confirm 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 a number of 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. This, while was and still is at times chosen behaviour, can be deemed a severe configuration vulnerability in most systems. At this point and testing these, however, this is currently a brick wall and nothing further we can attack.

Port 80 HTTP

Since we have tested the other ports, we have port 80 left until last. As you may know, port 80 is the standard port for WWW and likely the service you are reading this blog on. As I am writing this blog after completing the CTF and taking screenshots of the process I know this is our initial foothold into the machine. If this was a normal website on the internet, this could be disastrous. From this, we are able entirely to take over the system, however inside a network during a standard pentest this may 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 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.

An example of Tools we can use is called Nikto, which is a simple web and CMS scanning tool, Others we could use are Nuclei or even Nessus. This can give pentesters and hackers alike vital information quickly about the target.

Vulnerabilities found: out-of-date Apache software

I also ran 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 at times reveal hidden admin systems that may have been forgotten about. However, this finds nothing on this CTF.

For testing, I will use a web proxy tool called Burpsuite. This gives more vision into the communications between myself and the application, and I can view the requests as the server will receive them. Other tools can be used such as another favourite in the industry is OWASP ZAP.

Vulnerabilities found: Cleartext communications / Missing security headers / Info Server Header

Loading the application in my proxy browser I can see that it loads a simple HTTP still on port 80. As this is a CTF this normally is expected as the creators may not wish to set up and maintain encrypted services. So while this is a major vulnerability in modern-day systems, there is no attack surface during the CTF to potentially exploit.
Reading the message, it says we need to edit the user agent to a codename with the hint “Agent R” so using Burp we edit the request to the Agent name R:

While nothing new loads on the page, we get a secret message mentioning 25 employees, this indicates we are on the correct path. So we know there are 25 employees and the User-agent can be changed to change page content Using Burpsuite’s intruder feature we can set up what is called a “Sniper” attack in Burpsuite. This is where we supply a simple list of usernames and passwords separately against the application and send each potential password for each username.





When this is run, we can see a redirect when we use a specific letter:

Vulnerabilities found: User agent-dependent response / No authentication / Verbose error messages

This gives us the answers to “Task 2 questions 2,3” and a new hidden message. First, treating this like a pentest we can view this page without ever changing the user agent like the CTF expects:

Vulnerability found: Insecure Direct Object References

As can be seen, this page does not actually require the User-agent to be set to navigate to, meaning anyone who knows the URL can access it. If this was a real system with real authentication this would mean an attacker could for example simply shoulder surf or sniff local network traffic to see what this page contains. We also test the other Letters to see if any other hidden messages are available to no avail:

Vulnerability found: Verbose error message

Now we know to move on to Task 3, Which hints at brute forcing, as the message says the user has a weak password. Using the agent name we can attempt to bruteforce the other two services FTP and SSH. With the CTFs ‘handholding’, however, we know this is going to be the FTP service we need to attack to advance. So for this we can use multiple tools such as MSFconsole:

As can be seen, Metasploit has a module to brute force into FTP systems where we can set a list of usernames and a wordlist for the password. However, using the task hint we use another tool Hydra. This is a much more specialised tool for bruteforcing authentication systems and can be both faster and less overhead to both systems.

Vulnerability found: Weak password in use (FTP), No account lockout

Now we have found a user password to the FTP service we can log in, as seen having a weak password and username possible to gain from social engineering means a simple bruteforce attack is possible. In the past of the internet, a number of 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 were possible should be enabled.
In the FTP folder, we can find 3 files. Two images and a text file. We download these and view them normally first to see what the Agent could have wanted to store and send to their employer.

The message states that the password is in the fake image. This indicated that we now need to do some Steganography challenges. This is more a form of forensics and not common on pentests, or at least I have never done this on a pentest. However some of the tools and techniques I have used from monitoring data on a network to find images transferred in clear text. Steganography is a common task in CTF games as it can be a puzzle and show the players how data is stored, written and can be concealed.

Reading the tasks we now need to find a zip file using Binwalk a tool which identifies and looks at files at the data level, on both images shows one contains a zip file inside the image's data.

With Binwalk, we can take the ZIP file data out of the image and then attempt to extract the file's content but find it is password protected as the question indicates so we need to either extract the password hash or manually guess/brute force the password. in a real scenario, an attacker could also perform social engineering to retrieve this password.

Going down the hash extraction route we can use a script which comes bundled in the John the Ripper hash cracking application called zip2john, which simply extracts the hash into a crackable format. As this is an easy-rated CTF I use the standard John the Ripper password list and quickly gain the password to the database. Another tool available for cracking hashes is Hashcat. In a real-world scenario, an attacker could spend weeks or months at a time attempting to crack this hash to gain the content of the file or simply sell it to the highest bidder. If the company is not aware the breach has happened at this point the attacker has all the time in the world to attempt the next phase in their attack.

Vulnerability found: Weak password for Zip File

The password found was not only weak but guessable in the context of the image and file obtained. The real-world equivalent of this would be setting the password “Banking” on your bank password, or most commonly with staff “Password1” for their company password. Now we have the answer to “Task 3 Question 2” and can open the file which shows the following message:

As can be seen here, the zip file held a single text file with a new message with the “password” encoded in Base64. This was common in databases where DBadmins would encode entries such as passwords or other sensitive information stored As can be seen in this CTF it can be as simple as running a converter tool on the terminal or using a tool called CyberChef which can decode and even dehash multiple algorithms quickly from a simple web frontend. We now have the answer to “Task 3 question 3”

At this point, all hidden information has been found in the first image so now we can move on to the second. As we have seen Binwalk did not see any data in the file so we need to use a more specialised tool Steghide.

Vulnerability found: Weak encryption password, SSH password

Using this tool, we can see there is a hidden encrypted text file in the image. So using the tool with the password, I can extract the text file and read it. This gives us the SSH password which is extremely weak. So now we can log into the system and answer “Task 3 questions 4 and 5”.

When we log in the first thing we see is the user_flag.txt so we open that up and answer “Task 4 question 1”. Then next we see an image called “Alien_autopsy.jpg”. Now the question asks us what the incident in the photo is called, While this is a famous image I treat it as if it is the first time I have seen it. So using Open Source Intelligence (OSINT) techniques, I use Google reverse image search on the image. This analyses all images in Google storage for identical or visually similar images and returns where they are indexed. There are other tools online which also do this such as TinEye.

As we can see we have multiple hits and can easily identify the “incident” and we can answer “Task 4 question 2”.

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 a number of standard checks on the system from looking at SUID values to attempting to read the values of sensitive files such as /etc/shadow. Other techniques that could be covered can be found at GTFOBins. However, these were not the solution. As the CTF’s name is Agent Sudo, maybe that is a hint to the solution.

Vulnerability found: Out-Of-Date system applications

Checking the version of the sudo application using the -V flag tells us that it is running a known vulnerable version with a public one-liner exploit. We find this by simply checking the version in the online exploit database. Testing this we see we are forced to a root bash shell with root permissions. Therefore we now have the answer to “Task 5 question 1”.

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 can be almost endless.

Pentest style management summary

During the penetration test, I found that the “agent sudo” system appeared to be used for a simple purpose with what could be currently deemed little functionality and a small attack surface with few ports open and services running. However, due to the system being used to share and store sensitive and classified information, having any data leaks is considered critical. Performing an entire system takeover via a privilege escalation attack chain was also possible. Due to this, I can deem this system to be a high risk to your organisation and require immediate resource allocation to fix the vulnerabilities identified in this report.

While there were 2 High, 5 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 to the system being taken over and require immediate attention, however, it can be deemed these may not be trivial to remediate quickly.

I recommend the following:
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.

The second is to ensure all data is secured by a strong and trusted login mechanism with strong passwords, account lockout and MFA enabled. Without this attackers can simply navigate to the data without being stopped.
Once implemented and tested, ensure all passwords are strong following recommended government standards such as NIST or better. Have users use a trusted password manager to store and create secure passwords.

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 with all parts of the chain 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.

During the testing process, it appears that the majority of the system relied on obscure mechanisms to secure data. While security through obscurity does not weaken a system as a whole, solely relying on this can be the equivalent of no security at all as all it takes is an attacker to stumble across how these functions work to start bypassing them as if they are not there. The Approach taken by the design choices seems to show a “hide in plain sight” approach, However, with the system being solely dedicated to its function there is no way to hide among “normal” use.

As the system gains a secure and multi-layered authentication and authorisation system, a strong security-focused build process should be included in the later developments to ensure no new vulnerabilities are introduced.

Identified vulnerabilities

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 no issues have been found, roll out to the live system.

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

Clear text communications port 80/21

It was found 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 transferred 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, multiple instances of weak passwords were found. Passwords should always be used securely due to the sole purpose of what passwords are. It was found that the weak passwords at this time could be deemed less of a risk by whoever created them due to reasons that the web app did not contain anything sensitive at this time and the password manager was behind the levels of security. However, 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

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

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 attempt as many attempts as possible until the correct password is found, then impersonate the user on the FTP system.

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://smallstep.com/blog/use-ssh-certificates

User-agent dependent response / No authentication

Application responses may depend systematically on the value of the User-Agent header in requests. This behaviour does not itself constitute a security vulnerability but may point towards additional attack surfaces within the application, which may contain vulnerabilities. This behaviour often arises because applications provide different user interfaces for desktop and mobile users. While normally this is not a vulnerability, in this case however it is in place of user authentication. While this method could be seen as “security via obscurity” if the page did not indicate how it worked, an attacker may never know. However once it is known as can be seen in this report, there are no real protections on this system leaving it vulnerable to multiple attacks like Bruteforcing.

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

Remediation:
Use only strong tested authentication for keeping data on the web private. Including MFA, captcha and bruteforce protections.

Reference: https://medium.com/perimeterx/user-agent-based-attacks-are-a-low-key-risk-that-shouldnt-be-overlooked-1a5d487a1aa0

Insecure Direct Object References

Portswigger explains that Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. The term IDOR was popularised by its appearance in the OWASP 2007 Top Ten. However, it is just one example of many access control implementation mistakes that can lead to access controls being circumvented. IDOR vulnerabilities are most commonly associated with horizontal privilege escalation, but they can also arise in relation to vertical privilege escalation.

When Navigating the application an authorised user receives messages via triggering a redirect. Due to the lack of authentication and access control, this URL can be used by anybody who knows it exists. For example, an insider threat could be deemed a risk, if “Agent U” or an attacker who compromised “Agent U”’s device, they could easily see how the messages are distributed and change through the characters like in the walk-through to see messages to all agents.

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

Remediation:
The main remediation is to use strong tested authentication for keeping data on the web private. Including MFA, captcha and bruteforce protections. While no authentication may be designed not to indicate the site's intent, authentication could be done elsewhere.
Another way to combat IDORs is to design resources such as ids, names, and keys to be replaced with cryptographically strong random values instead of using a single letter that can be guessable, using a random unguessable string can stop attackers bruteforcing pages or identifying pages from their name.

Reference:https://medium.com/@paul_io/security-code-review-101-indirect-object-reference-91f3ad0451c5

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 performed in this penetration test, however, 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 the 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/

Verbose Error Message:

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

Thank you for reading my Second blog in this series. I was originally planning to release these on a semi-regular basis however Due to life I have had this and another 2 on the back burner. Now I spend around 30 minutes a week on these tops, and with new CTFs being released, I wanna play them more than blog haha. I have enjoyed doing CTFs since before I was even a full-time pentester back in university. Having participated in multiple CTF games and services such as Tryhackme featured here, and helping teach both colleagues and friends hacking techniques, I wanted to give something back and also leverage this to help both managers and IT staff who may be interested in how their pentesters operate to come to the final report that lands on their desk. I am targeting an extensive range of people in this blog and would love all feedback on how to improve or even open discussion around topics contained. Also, if I'm talking pure shit/wrong in any way… feel free to reach out and correct me, as in security we are always learning.

Tools/Techniques

Tools:

Hacking Techniques: