-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathMITM-THM-AOC
152 lines (98 loc) · 12.6 KB
/
MITM-THM-AOC
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
Learning Objectives
In today's task you will learn about:
Self-signed certificates
Man-in-the-middle attacks
Using Burp Suite proxy to intercept traffic
Certified to Sleigh
We hear a lot about certificates and their uses, but let’s start dissecting what a certificate is:
Public key: At its core, a certificate contains a public key, part of a pair of cryptographic keys: a public key and a private key. The public key is made available to anyone and is used to encrypt data.
Private key: The private key remains secret and is used by the website or server to decrypt the data.
Metadata: Along with the key, it includes metadata that provides additional information about the certificate holder (the website) and the certificate. You usually find information about the Certificate Authority (CA), subject (information about the website, e.g. www.meow.thm), a uniquely identifiable number, validity period, signature, and hashing algorithm.
Sign Here, Trust Me
So what is a Certificate Authority (CA)?
A CA is a trusted entity that issues certificates; for example, GlobalSign, Let’s Encrypt, and DigiCert are very common ones. The browser trusts these entities and performs a series of checks to ensure it is a trusted CA. Here is a breakdown of what happens with a certificate:
Handshake: Your browser requests a secure connection, and the website responds by sending a certificate, but in this case, it only requires the public key and metadata.
Verification: Your browser checks the certificate for its validity by checking if it was issued by a trusted CA. If the certificate hasn’t expired or been tampered with, and the CA is trusted, then the browser gives the green light. There are different types of checks you can do; check them here.
Key exchange: The browser uses the public key to encrypt a session key, which encrypts all communications between the browser and the website.
Decryption: The website (server) uses its private key to decrypt the session key, which is symmetric. Now that both the browser and the website share a secret key (session key), we have established a secure and encrypted communication!
Ever wonder what makes HTTPS be S (secure)? Thanks to certificates, we can now have authentication, encryption, and data integrity.
Self-Signed Certificates vs. Trusted CA Certificates
The process of acquiring a certificate with a CA is long, you create the certificate, and send it to a CA to sign it for you. If you don’t have tools and automation in place, this process can take weeks. Self-signed certificates are signed by an entity usually the same one that authenticates. For example, Wareville owns the GiftScheduler site, and if they create a certificate and sign it with Wareville as a CA, that becomes a self-signed certificate.
Browsers generally do not trust self-signed certificates because there is no third-party verification. The browser has no way of knowing if the certificate is authentic or if it’s being used for malicious purposes (like a man-in-the-middle attack).
Trusted CA certificates, on the other hand, are verified by a CA, which acts as a trusted third party to confirm the website’s identity.
CA-issued certificates sometimes take a long time; if you want to test a development environment, it can make sense to use self-signed certificates. Ideally, this is an internal, air-gapped environment with no connection to the public Internet. Otherwise, it defeats the purpose of a certificate: the entire system of secure communication relies on the fact that both parties (the browser and the server) can trust the data being exchanged and that no one in the middle can intercept or modify it without detection.
Connecting to the Machine
Before moving forward, review the questions in the connection card shown below:
We need to start the AttackBox and the attached VM
To reproduce Mayor Malware’s attack, click the Start Machine button below to deploy our target VM that has the Gift Scheduler server running.
Start Machine
Then click on the Start AttackBox button at the top of the page to start the machine from which we—along with Mayor Malware—will attack the website. The AttackBox machine will start in split view. If it is not visible, use the blue Show Split View button at the top of the page.
How Mayor Malware Disrupts G-Day
There are less than two weeks until G-Day, and Mayor Malware has been planning its disruption ever since Glitch raised the self-signed certificate vulnerability to McSkidy during a security briefing the other day.
His plan is near perfect. He will hack into the Gift Scheduler and mess with the delivery schedule. No one will receive the gift destined for them: G-Day will be ruined! [evil laugh]
Preparation
First things first: the Glitch spoke about a self-signed certificate, but Mayor Malware can’t believe that the townspeople—usually so security-savvy it’s maddening to him—would easily disregard such a critical vulnerability. Is it a trap set up by the Glitch and McSkidy to catch him red-handed? He definitely needs to check for himself.
Before that, though, he wants to make sure that his tracks are well covered. To prevent any DNS logs from alerting his enemies, he will resolve the Gift Scheduler’s FQDN locally on his machine.
To achieve this, let’s add the following line to the /etc/hosts file on the AttackBox: 10.10.190.81 gift-scheduler.thm
We can use the following command:
Terminal
root@attackbox:~# echo "10.10.190.81 gift-scheduler.thm" >> /etc/hosts
To verify that the line above was added to the file, we can execute the following:
Terminal
root@attackbox:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 tryhackme.lan tryhackme
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.10.190.81 gift-scheduler.thm
Now, Mayor Malware can navigate to the Gift Scheduler website without leaving a trace on Wareville’s DNS logs.
Let’s open the Firefox browser and navigate to https://gift-scheduler.thm. We’ll be presented with the following warning page:
Firefox warning page titled 'Warning: Potential Security Risk Ahead'. The page displays two buttons, the first one labelled 'Go Back (Recommended)' and the second labelled 'Advanced'. A yellow box highlights the 'Advanced' button.
We can click on the Advanced button to expand the warning’s details.
Firefox warning page titled 'Warning: Potential Security Risk Ahead' showing advanced information. The details show that the host 'gift-scheduler.thm' uses a self-signed certificate. Two yellow boxes highlight a 'View Certificate' link, marked with number 1, and a button labelled 'Accept the Risk and Continue', marked with number 2.
When we click on the View Certificate link marked with a 1 in the screenshot above, a new tab opens with the certificate details.
Mayor Malware can’t believe his luck! This is evidence that the Glitch was speaking the truth: the Gift Scheduler web server uses a self-signed certificate.
This means that the townspeople and all the elves will be used to clicking on the Accept the Risk and Continue button (marked with 2 on the screenshot above) to access the website, to the point it’s become a habit.
Mayor Malware does just that and inserts his credentials into the login form.
THM Key Credentials
Username mayor_malware
Password G4rbag3Day
Website login page
With his credentials, he can’t do anything but send a gift request—as if he were to ever do such a sickeningly sweet gesture. To carry out his evil plan, he will need to sniff some admin credentials. Maybe some of the elves’ passwords. Or even—if he gets lucky—Marta May Ware’s account!
The 'Schedule your gift' form page
To sniff the elves’ traffic, the next step will be to start a proxy on his machine and route all of Wareville’s traffic to it. This way, the Mayor will be In The Middle between the townspeople and the Gift Scheduler. This position will allow him to sniff all requests forwarded to the sickening website.
Let’s start the Burp Suite proxy by typing burp in the terminal. A new window will open. We can accept the default configuration by clicking on Next, then Start Burp in the next window.
Burp Suite window. Three numbered yellow boxes highlight the following: 1-the Proxy tab; 2-an Intercept On button; 3-a Proxy Settings menu.
Once Burp Suite loads, we will select Proxy (number 1 in the screenshot above) and then toggle off the Intercept on option (number 2) to prevent users from noticing any delays in the website responses. Finally, let’s open the Proxy Settings (number 3) to set a new listener on our AttackBox IP address.
Burp Suite settings window open on the Proxy settings. A yellow box highlights a button labelled “Add” under the Proxy listeners section.
We can click on the Add button highlighted in the screenshot above. Burp Suite will prompt us for the new listener’s configuration.
Burp Suite window labelled 'Add a proxy listener' open on the 'Binding' tab. The number 8080 is written in the box next to a 'Bind to port' option. Under the 'Bind to address' section, the 'Specific address' option is selected. A partially covered IP address is specified in a dropdown box. A yellow box highlights the 'OK' button on the lower right.
We must set the listening port to 8080 and toggle the Specific address option. The box next to it will automatically specify the IP address of our AttackBox, 10.10.90.35. Finally, we can click on OK to apply the configuration.
The previous settings window will get displayed and we can see that the new listener has been added under the proxy listeners list.
The Burp Suite settings window open on the Proxy settings. A new listener is now listed under the Proxy listeners section. A yellow box highlights the phrase: Each installation of Burp generates its own CA certificate that Proxy listeners can use when negotiating TLS connections.
Mayor Malware rubs his hands together gleefully: as we can read in the yellow box in the screenshot above, Burp Suite already comes with a self-signed certificate. The users will be prompted to accept it and continue, and Mayor Malware knows they will do it out of habit, without even thinking of verifying the certificate origin first. The G-Day disruption operation will go off without a hitch!
Sniff From The Middle
Now that our machine is ready to listen, we must reroute all Wareville traffic to our machine.
Mayor Malware has a wonderful idea to achieve this: he will set his own machine as a gateway for all other Wareville’s machines!
Let’s add another line to the AttackBox’s /etc/hosts file. Note: The 10.10.90.35 address in the snippet should reflect the IP of our AttackBox, which can be found at the top of the page.
Terminal
root@attackbox:~# echo "10.10.90.35 wareville-gw" >> /etc/hosts
This will divert all of Wareville’s traffic, usually routed through the legitimate Wareville Gateway, to Mayor Malware’s machine, effectively putting him “In The Middle” of the requests. Note: In practice, the adversary can launch a similar attack if they can control the user’s gateway and their attack can easily succeed against websites not using properly signed certificates. This attack requires more than adding an entry into the /etc/hosts file; however, this task aims to emulate parts of the attack.
As a last step, we must start a custom script to simulate the users’ requests to the Gift Scheduler. On the AttackBox, the script can be found in /root/Rooms/AoC2024/Day14. If you are using your own attacking machine connected to our VPN, you can download the script from here. Remember to run chmod +x route-elf-traffic.sh to make it executable. Note: Keep the script running so that new user requests will constantly be captured in Burp Suite.
Terminal
root@attackbox:~# cd ~/Rooms/AoC2024/Day14
root@attackbox:~/Rooms/AoC2024/Day14# ./route-elf-traffic.sh
Verifying archive integrity... 100% MD5 checksums are OK. All good.
Uncompressing Intercept Traffic 100%
Intercepting user traffic in progress...
User request intercepted successfully at 2024-12-11 16:05:56
User request intercepted successfully at 2024-12-11 16:06:23
User request intercepted successfully at 2024-12-11 16:06:36
[...]
Pwn the Scheduler
At last, everything is in place. Mayor Malware’s evil plan can finally commence! [evil laugh]
We can return to the open Burp Suite window and click on the HTTP History tab.
HTTP history with some requests, one GET open.
There is a triumphant gleam in Mayor Malware’s eyes while he stares intently at the web requests pouring on his screen. He can finally see them: the POST requests containing clear-text credentials for the Gift Scheduler website! Now, he only needs to wait and find the password to a privileged account.