Finding Cross-site Scripting (XSS)
Cross-site Scripting (XSS) issues occur where user supplied input is insecurely included within a server response, or insecurely processed by a client-side script. If the payload is included with the response that immediately follows the request containing the payload then this is known as Reflected XSS. It is also sometimes referred to as Non-persisted XSS. If the payload is stored by the server and returned in a later response, it is known as Stored XSS, or Persistent XSS. Where the issue is due to insecure client-side processing it is known as DOM-Based XSS. Finding and exploiting DOM-Based XSS is quite different to stored or reflected, so we’ve separated it into its own article: Finding DOM-XSS.
Finding DOM-Based XSS
We’ve previously written about Reflected and Stored Cross-site Scripting, however this time we want to tackle DOM-Based Cross-site Scripting, or DOM-XSS for short. The exploitation of DOM-XSS is frequently very similar to Reflected Cross-site scripting, were the payload is stored within the URL and exploitation occurs where a user can be tricked into clicking the link, such as through a phishing email – but we’ll break it down step by step.
Cross-site Scripting vulnerabilities occur where scripts can be executed within another user’s view of a web application. It can allow for attacks such as virtual defacement of the page, the theft of confidential data, or the distribution of malicious software to users of the site.
Wireless Security: WEP
It’s well known that the WiFi security protocol WEP is broken. It’s been broken for years. However, if we’re writing a series on wireless security we should start at the beginning. Whilst it stands for Wired Equivalent Privacy, it hardly lives up to its name. WiFi comes under the IEEE 802.11 family. WEP was part of the original standard and was quickly superseded by WPA – WiFi Protected Access.
WEP can be broken using the aircrack-ng suite. However you will require a compatible wireless card with features such as injection support – the aircrack-ng documentation discusses supported cards. In this article we’ll be using a USB Alfa AWUS036ACH, which inside has a Realtek RTL8812au. To get injection support requires patched drivers, but again they’re available from aircrack:
Wireless Security: WPA
We previously spoke about WiFi security and how utterly broken WEP is. Now it’s time to take a look at WPA and WPA2 bruteforcing. This isn’t the only weakness of these protocols – but weak keys are common. The first thing to note is that the key-length for WPA is between 8 characters and 63 characters – this is important when building brute-force word lists.
Setting up the tools for these attacks is very similar to our previous post. We’re going to be using aircrack-ng and you’re going to need a compatible wireless card. We’ll be using a AWUS036ACH, with a Realtek RTL8812au. Drivers to support injection can be installed on Kali Linux.
Hashcracking with AWS
Password cracking is a common step during compromising networks, from cracking wireless networks to compromising user passwords captured when LLMNR spoofing. In a previous post, I showed the steps to capture a WPA handshake and crack it using Hashcat. On my tiny travel laptop I achieved 416 hashes per second, which is…slow. AWS offers “GPU Optimized” EC2 instances which can offer a significant speed increase.
In this post we'll run through setting up Hashcat on an AWS instance to allow for rapid password cracking. These instances are pricey, but you often only need to run them for short bursts.
Breaking Enterprise Wireless
In our previous posts we discussed how WEP is completely broken, known weaknesses with WPA, and bruteforcing WPA using AWS. This time around it’s time to look at “Enterprise” Wireless security. These are networks protected with EAP – Extensible Authentication Protocol.
However EAP is not just one protocol, but a collection of protocols. We won’t be breaking down every authentication method here, we’ll simply be highlighting that using Enterprise security for a wireless network doesn’t immediately remove all risk – and can in fact introduce more risk.
Both EAP-MSCHAPv2 and EAP-TTLS utilise password based authentication; for example to authenticate to Active Directory. This could be a machine account or a user account. This addresses one of the issues with WPA, which is the difficulty in revoking a user’s access to the network – as all devices use a single Pre-Shared Key (PSK).
Content Security Policy
In our post on Fixing Cross-site Scripting, we recommended the use of Content Security Policy (CSP) to mitigate the effects of this vulnerability. It does this by allowing you to set up an allow-list of resource locations (such as scripts) for your web pages, and therefore inform the browser to block any scripts that do not come from an authorised source. The problem is, you have to set up an allow-list of resource locations, or the resource will be blocked.
So initially setting up the header can be difficult, but the benefit of preventing attacks such as Cross-site Scripting, and ClickJacking can be worth it.
Extracting Domain Hashes: Mimikatz
We previously covered how to perform incredibly fast hashcracking with AWS. In this post we’ll take a step back, and look at one simple method to extract the hashes from a domain controller. To be clear, this is a post exploitation step and to perform these steps a domain administrator account will be needed.
There are several tools which can be used to extract hashes directly on a domain controller, such as fgdump or Meteterpreter’s hashdump too. However, Mimikatz can perform this step from any domain joined machine, which is a little easier and often a benefit when it comes to antivirus evasion steps.