Blog...
BlackW0lf CTF Writeup series #1
This is my CTF walkthrough series I am writing to help both new testers and potential clients with how a tester performs a pentest. It looks at different techniques and goes into detail about a number of vulnerabilities found whilst solving the CTF.
The blog will follow the following format:
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.
Opacity (TryHackMe - Easy)
Opacity is a Boot2Root made for pentesters and cybersecurity enthusiasts.Opacity is an easy machine that can help you in the penetration testing learning process. There are two hash keys located on the machine (user - local.txt and root - proof.txt). Can you find them and become root? Hint: There are several ways to perform an action; always analyse the behaviour of the application.
Questions:
Walkthrough
Step one with any CTF or pentest is recon. As the description does not give much away about the machine other than there are a few routes to take, we can jump straight in and start looking for ways into the system.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 surface 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 SMB. 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 -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 only two new ports which are returned as filtered and when attempting to connect, we find there is no access.
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 more filtered ports and the UDP port for NetBIOS(SMB) communications.
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, 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 manually verify this. Using Netcat we can make a simple connection to the port to retrieve the banner:
Vulnerability found: out-of-date 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 onto 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 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 management of the system. At this point and testing these, however, this is currently a brick wall and nothing further we can attack.ports 139,445,137(UDP)
As these ports are part of the same service, I will group them together to attack. A manual way to test these services is to use tools such as RPCclient, SMBwalk, however, a favourite tool among pentesters which can automate a large amount of the information gathering is enum4linux. This tool automates multiple information-gathering techniques against this service and returns the information in sections. The following screenshots are from an unauthenticated (NULL) session connection and are a sample of the interesting information that is returned.
The first part of the response shows a number of useful things, such as the machine's name, which is part of a workgroup, not a domain, and some of the basic services it runs such as fileservers. While this information is not critical, it can give an attacker insight into how the company uses servers.
Vulnerability found: OS kernel out of date
The information provided here shows that the OS is Ubuntu running the latest(for the time of CTF creation) 6.1 kernel. While it is not the latest, there is no vulnerability in this version that can be exploited at this time.
If this was a file server for a company, there could be a number of open share folders to the network. As can be seen from the tool, this attempts to connect to them with the supplied credentials (in this screenshot NULL) and returns if they are accessible. As no shares are open outside the standard and my access is denied there are no vulnerabilities to attack at this time, however, during my time in pentesting, I have seen multiple servers known or unknowingly allow access to sensitive information in shares which were identified in this method open to anyone connected to the company network.
Vulnerability found: null sessions leading to RID cycling info disclosure
The last interesting part we find on this CTF is RID/SID cycling being possible. This can be used to identify both user groups and usernames from a machine. This gives an attacker the ability to attempt to brute force the account's credentials. In the screenshot, we can see an account called sysadmin is available on the machine, and as this is not part of the standard Ubuntu system usernames, it is a potential target for attack. This can be done using a number of tools such as Metasploit, Hydra, and Medusa depending on the services we would like to target. As this is a system user we can try against both SSH and the NetBIOS. This was unsuccessful during the CTF, and no further attacks were performed against this service.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 be now 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.
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: out-of-date Apache software/ cleartext communications
Loading the application in my proxy browser I can see that it first redirects to a login page still on port 80. As this is a CTF this, port used 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.
Viewing the login screen we can see it is a simple authentication using username and password so the first thing we can do is attempt to log in, using admin/admin to see how the application reacts.
As shown the login is very simple. The application takes username and password over a post request and returns “invalid login details” if false. Unfortunately, it does not offer information disclosure on if the username is correct, therefore to brute force it we need to guess a number of usernames to use.
Vulnerabilities found: No account lockout, no captcha/MFA
Using Burpsuite’s intruder feature we can set up what is called a “cluster bomb” attack in Burpsuite. This is where we supply a list of usernames and passwords separately against the application and send each potential password for each username. Using easily accessible wordlists we come across the Admin password.
Vulnerability found: Weak password in use/cookie flags missing
After a bit of time we find that the attack returns a valid login in the form of a 302 redirect request to the index page, however, viewing and navigating the site shows that it appears to be a simple placeholder site with no working functionality. Due to this, it appears to be a dead end.Going back to the recon phase 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 at times reveal hidden admin systems that may have been forgotten about.
As can be seen, this has uncovered a new directory /cloud/ which as we have seen from the index and login page is not mentioned in the application at all.
Navigating this page shows the application which appears to, as the name implies, be an image-uploading tool that works from downloading and storing remote images. Testing this against its own folder image shows the functionality and shows that the images appear to be removed from the system in the 5 minutes mentioned.
Using Burpsuite we can see how the application works and can attempt to upload malicious files. This leads us to learn a few further things about the application and system. First is that due to this being a CTF, the system has no access to the internet, which would replicate an intranet site in a secure environment. The second is that the application uses file type validation to stop attacks uploading files which do not end in an image file type such as .jpg.
As we can communicate with the application, my machine is part of the same network. Using a web server software or in this case python's simple HTTP server code we can host files in a simple HTTP format. This negates the first hurdle.
Vulnerability found: bypassable input validation
When interacting with a web application, some pages have section markers to guide users to parts of the page they are looking for, such as a table of contents. This is performed by adding “#section” , where the browser will automatically navigate to the section requested. When there are no sections or invalid sections requested, the page will just load like usual as the browser does not know where to travel. Using my Python server, I can host a PHP shell and use the application to download the PHP web shell but from a fake section of the downloaded document on the site test.jpg http://10.10.19.249:8000/shells/shell.php#test.jpg. This bypasses the validation as the application is only looking at the end of the URL, not the file type on the end of the download.The web shell used is a well-known one from GitHub which, when run in a PHP system, will make a reverse connection to a given IP address over a chosen port number.
To open the web shell, I needed to host the shell and open a port to listen for the connection. The tool Netcat can be used to open a simple listener port, and using the ‘-nvlp’ flags we can make it interactable once a connection has been made.
Vulnerability found: remote command execution via malicious upload
As shown when the malicious URL is used to upload the fake image, the Netcat listener receives communications for the shell giving us command line access to the machine.
At this point again in a normal web application pentest, it would be the end of the exploit chain without the prior written consent of the point of contact from the client company. This is due to the scope of a web application test being only the web application server and coded application, not the command line of the server. As this is a critical vulnerability, at this stage the tester should get in touch with the point of contact to explain the issue quickly and any mitigating factors or fixes that could be put in place immediately to stop any potential hack being performed between now and the report being handed to the IT staff member in charge of remediations. The point of contact and tester can then talk about whether to advance further down the attack chain (which we will be doing for the CTF) or to move on and look for other vulnerabilities in the application.
As mentioned, at this point we are beyond a normal pentest scope and more into a Linux server build hardening test. Some of the techniques performed here are for ease to solve the CTF and would be performed differently in a live pentest scenario. However, a real-world attacker could easily perform these actions and should be treated seriously.
The web shell we have gained access to is running in the www-data user sandbox, which is designed by applications such as Apache to be locked down to protect against potential attackers running severely malicious code on the web server if an attack like this was successful. Normally this does a good job but it is not always foolproof. We start by looking at what we have access to in the folder structure of the server, what applications we have the power to run, and even if we can run sudo commands on the machine. At this time and how the CTF is set up we find the solution in a readable file left in the /opt/ folder on the server. This appears to be a KeePass database file which as we know is a password manager. if this was a real pentest in a company this could contain a large number of usernames and passwords for the company systems and would be an immediate target for an attacker.
Vulnerability found: sensitive file accessible by www-data
Due to the value of this file I move it to the web application folder where I can simply download it from the server without restriction. On opening as expected, we find that it is password protected 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.
Vulnerability found: weak password manager password
Going down the hash extraction route we can use a script which comes bundled in the John the Ripper hash cracking application called keepass2john, 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.
When we open the file we find a single entry, a username and a password for “sysadmin” the user account we found early in the recon phase of testing.
Using this newfound information we can cancel our brute force attack on this user if it is still running and simply log into the SSH session with the newly gained credentials. As this is a CTF we can also read the local.txt answering question 1
Now we are required to escalate privileges on the server and gain access to the root account to read the proof.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. Remembering the system's web application removes uploaded files every 5 minutes and knowing that the sysadmin has a PHP script in its home directory, i first look at cron jobs using both crontab and checking the contents of the cron system such as etc/cron.daily. When this didn't work I needed to see what processes were running on the system, ps aux was not showing anything that could potentially identify this so using a known tool PSPY.
I uploaded and ran this tool and monitored the system PIDs and saw every 5 minutes the cron jobs were run and the system ran the script file located in the sysadmin home directory.
Reading this file we can see how it works and that on schedule (the 5-minute run job) it would run a further script in the subfolder lib/ and this gets run as root on the machine under the scripts cron process.
Vulnerability found: folder permission ownership of scripts ran with elevated privileges
As we can see for those who understand Linux permission values, the script that gets run is owned by the root user and is only editable by the root user. However, the folder the script is contained in is owned by the sysadmin user which I’m currently logged into. This means that I can remove and place files in this folder without restrictions as shown
I first make a new file called backup.inc.php, remove the one in the scripts folder and copy my new file in its place. According to the original script.php nothing has changed. The new file is what should run every 5 minutes as root.
Modifying the original script, I add a new line to open a new reverse shell into the system, which connects back to my original Netcat listener on a new port.
Placing this file into place and waiting 5 minutes for the script to run, we can see this executes and opens a root shell back to my attack machine where I can view the proof.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 opacity 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, 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 4 High, 4 Medium, and 4 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.
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, I came across a password manager. I would like to highlight that this is a great sign of basic security consciousness inside the organisation and a sign that the sysadmins do potentially have real care. However, in this case, it was found to be implemented poorly with a weak password to access the file. Seeing this, however, does seem that with simple training and regular interaction with pentesters, they could quickly adopt better practices and lock down the systems better in the future.
As the system seems to be intended for further functionality in the future due to evidence from the landing page, a strong security-focused build process should be included in the later developments to ensure no new vulnerabilities are introduced.
Identified vulnerabilities
The following are examples of vulnerabilities found throughout the walkthrough if they were 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 no issues found roll out to the live system.
Referance: https://www.linuxcapable.com/upgrade-apache-on-ubuntu-linux/
-Unrestricted File Upload leading to remote shell
Having a system that allows file upload can be deemed one of the most problematic features due to the significant risks it can present in the application. Issues can range from Denial of services via large files, XSS from both file content or name, malware upload, and even full system takeover via malicious shells. Unfortunately, due to the wide range of attacks and attack methods, it can be difficult for unaware developers to secure these systems fully. During this testing, there was found to be not a single check on what the file type uploaded is once an attacker bypasses the front-end input validation. This led to a simple PHP file being uploaded to the system, which gets executed to call out to my machine, allowing commands to be run as the www-data user.CVSSv3 Score: 8.3 CVSS v3.1 Vector AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
Remediation: File uploads should have multiple checks from the system to ensure only trusted files types and file content are uploaded. Check for file type and file size by allowing listing only. Do not rely on a single check on the front end; only execute (display the image) once confirmed safe.
Referance:https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload
-Insecure Permissions Leading to Privilege Escalation
File and Folder permissions in Linux can be quite complicated for new users. Both folders and files can have completely different permissions that do not, at times, work together to secure files. A file can have the permissions that only a root user can make any modifications, but a low-level user can read the contents while the folder it is contained in allows anyone to add or remove files. This is what happened during the testing. When looking at running scripts, it was found the cleanup process was owned and ran as the root user, however, the scripts themselves were stored in a low-level sysadmin accounts home folder. Having ownership of the folder in which a file is stored means it is possible to straight up replace the file.While the sysadmin may have permission to make edits to the system, if this was another user or this account was compromised, being able to modify running files means you can run your own code as another account, in this case, root.
CVSSv3 Score: 7.8 CVSS v3.1 Vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Remediation: Ensure all files and folders are set with correct file access permissionsunless specifically required. Ensure essential and sensitive files, such as pa$
Referance: https://www.redhat.com/sysadmin/linux-file-permissions-explained
-Clear text communications port 80
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.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.
Referance: https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/
-Bypassable input validation
Validating a user's input can stop malicious code or data from being sent to the server. Any input an attacker can use on a web application can be a potential for compromise. It was found that the application used a single URL style input which was required to end in an image file type such as .jpg. However, the input validation was only checking the last four characters of the user's input leading to using a common technique to bypass and input an invalid URL.CVSSv3 Score: 5.8 CVSS v3.1 Vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N
Remediation: Use more robust data input validation such as regex strings example :(?:([^:/?#]+):)?(?://([^/?#]*))?([^?#]*\.(?:jpg|gif|png))(?:\?([^#]*))?(?:#(.*))?
Referance: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
https://www.ietf.org/rfc/rfc2396.txt
-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. I would like to commend the sysadmin for having a password manager. This is the first step to better password security, meaning very little training and tweaking processes are needed to remediate this issue.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.
Referance: 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 foundCVSSv3 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.
Referance: https://smallstep.com/blog/use-ssh-certificates
-Web authentication issues
When testing, there were a number of issues found around the authentication into the web application. These were found to allow automated brute-force attacks. This is where an attacker can simply have a script send different passwords until the correct login is found. While this application appears to be in development, if protections are not put in place before future builds, an attacker could gain the credentials for the application and monitor for developments in the future, waiting for a vulnerability to be introduced.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: It is recommended to apply a range of security protections on web authentications systems such as MFA to stop an attacker gaining access from just a username and password.
Account lockout - if an attacker was to attempt to log into an account multiple times, lock the user account out from logging in and warn the user to change their password via a separate system such as Email.
Captcha which stops the ability to automate brute force attacks, requiring user interaction for authentication can severely slow down password guesses and can even put an attacker off this type of attack.
Referance: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
-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, COORs. 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.Cookie flags missing: Cookie flags tell the user's browser what it can do with the cookie, This can range from allowing it to be read by javascript or other URLs
Remediation: Add configuration changes such as "+ '; secure'" to apply flags.
Referance: https://blog.dareboost.com/en/2019/03/secure-cookies-secure-httponly-flags/
Security headers: Security headers tell the users 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 apache enabled site configs and set these headers.
Referance: 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
Referance: https://ubiq.co/tech-blog/remove-server-name-apache-response-header/
-NULL sessions leading to RID cycling info disclosure
SMB was found running on the system, allowing NULL sessions. This means that without authenticating, an attacker can view the shares and, in some configurations, information about the system. This can give attackers a deep understanding of both the system and environment, in this case, the usernames on the system.Remediation: Modify /etc/samba/smb.conf and set “client signing = mandatory”
Referance: https://learn.microsoft.com/en-gb/windows/win32/rpc/null-sessions?redirectedfrom=MSDN
-Sensitive file accessible by www-data
When setup up several standard web servers on Linux they will enable the sandbox www-data user, this is the user the entire web server will be run by to protect the file system from potential attacks such as RCE. from this account it was possible to find and read sensitive files such as the password manager database.CVSSv3 Score: 4.3 CVSS v3.1 Vector: AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Remediation: Ensure all files and folders are not set with global access unless specifically required. Ensure essential and sensitive files, such as password managers, are stored in secure locations.
Referance: https://www.redhat.com/sysadmin/linux-file-permissions-explained
-No firewall, port scanning monitoring on the network
was found that no network monitoring or protections 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.Referance: https://network-king.net/best-network-monitoring-tools/
Conclusion
Thank you for reading my first blog in this series. 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 it's my first blog of this type I'm sure I've miswritten parts ¯\_(ツ)_/¯ …and in security we are always learning.Tools/Techniques
The following is a list of tools and techniques used to solve this CTF.Tools:
Burpsuitehttps://www.pluralsight.com/paths/web-security-testing-with-burp-suite
Dirb
https://www.hackingarticles.in/comprehensive-guide-on-dirb-tool/
Hydra
https://www.freecodecamp.org/news/how-to-use-hydra-pentesting-tutorial/
Python3 HTTP server module
https://docs.python.org/3/library/http.server.html
Enum4linux
https://labs.portcullis.co.uk/tools/enum4linux/
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>
PSPY
https://vk9-sec.com/how-to-enumerate-services-in-use-with-pspy/
John the Ripper
https://www.golinuxcloud.com/john-the-ripper-password-cracker/
Hacking Techniques:
Bruteforcehttps://owasp.org/www-community/attacks/Brute_force_attack
Hash cracking
https://www.wired.com/2016/06/hacker-lexicon-password-hashing/
Input validation bypass
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
Privilege escalation via Linux permissions
https://tbhaxor.com/exploiting-file-permissions-misconfigurations/
Directory busting
https://www.makeuseof.com/what-is-directory-bursting/
Port Scanning
https://www.avast.com/en-gb/business/resources/what-is-port-scanning
SMB Enumeration
https://www.hackingarticles.in/a-little-guide-to-smb-enumeration
Blog home
