OSCP Journey : IPV6 Attack
I - Introduction :
Lately, I've been focusing on IPv6 attacks. I used to work with tools like Responder and relay attacks, but now I'm exploring the potential of IPv6 vulnerabilities. Let's dive into what I've learned so far.
II - What is IPV6 Attack :
All our Windows boxes are currently using IPv4, and while IPv6 is enabled, it isn't configured. This raises an important question:
Who is handling DNS for IPv6?
The answer is: nobody. This is where our attack comes in.
By exploiting this gap, we can take over the DNS for IPv6, which allows us to intercept authentication attempts to the Domain Controller via LDAP or SMB.
III - Attack in action :
To begin, we need to set up a few things. First, we need to configure an LDAP secure certificate for our Domain Controller (DC). Since we are using LDAP to leverage our IPv6 DNS resolver, this step is crucial.
The mitm6 attack :
MITM6 initiates by monitoring the main interface of the attacker's machine, awaiting requests from Windows clients seeking IPv6 configuration through DHCPv6. By default, every Windows system from Windows Vista onwards routinely solicits this configuration.
mitm6 will reply to those DHCPv6 requests, assigning the victim an IPv6 address within the link-local range. While in an actual IPv6 network these addresses are auto-assigned by the hosts themselves and do not need to be configured by a DHCP server, this gives us the opportunity to set the attackers IP as the default IPv6 DNS server for the victims. It should be noted that mitm6 currently only targets Windows based operating systems, since other operating systems like macOS and Linux do not use DHCPv6 for DNS server assignment .
The screenshot illustrates MITM6 in operation. This tool seamlessly identifies the IP configuration of the attacker's machine and promptly responds to DHCPv6 requests initiated by clients within the network. It crafts DHCPv6 replies, incorporating the attacker's IP as the designated DNS server. Additionally, MITM6 offers an optional feature where it periodically dispatches Router Advertisement (RA) messages. These messages serve as notifications to clients, signaling the existence of an IPv6 network and prompting them to seek IPv6 addresses via DHCPv6.
Exploiting WPAD :
The initial safeguard, where WPAD is solely requested via DNS, becomes susceptible to bypassing through mitm6. Once the victim's machine designates the attacker as the IPv6 DNS server, it initiates queries for the network's WPAD configuration. As these DNS inquiries are directed to the attacker, a simple reply with the attacker's IP address (either IPv4 or IPv6, depending on the victim’s machine request) is sufficient. Even in cases where the organization already employs a WPAD file, this method remains effective, albeit at the cost of disrupting internet connections.
To circumvent the secondary safeguard, wherein credentials are no longer provided by default, a more elaborate approach is required. When the victim requests a WPAD file, authentication is not solicited; instead, a valid WPAD file is furnished, with the attacker's machine designated as a proxy. Consequently, when the victim accesses any application utilizing the Windows API for internet connectivity or simply browses the web, the attacker's machine is employed as a proxy. This exploitation extends across multiple browsers such as Edge, Internet Explorer, Firefox, and Chrome, as they inherently adhere to the WPAD system settings.
Upon the victim's connection to our "proxy" server, identifiable through the use of the CONNECT HTTP verb or the presence of a full URI after the GET verb, a response of HTTP 407 Proxy Authentication Required is issued. This deviation from the standard HTTP 401 code used for authentication requests is pivotal. Notably, IE/Edge and Chrome (leveraging IE's settings) will autonomously authenticate to the proxy, even on the latest Windows iterations. While Firefox permits this behavior by default, users can configure it as per their preferences.
- Full Attack :
The preceding sections provided an overview of the attack's conceptual framework. Executing the attack itself is relatively straightforward. Initially, we launch mitm6, which promptly responds to DHCPv6 requests and subsequently handles DNS queries targeting names within the internal network.
For the latter phase of our attack, we leverage our trusted relaying tool, ntlmrelayx. Developed as part of the impacket Python library by Core Security, ntlmrelayx represents an enhancement of the widely recognized smbrelayx tool. It boasts support for multiple protocols for relaying. Recently, Core Security and Fox-IT collaborated on enhancing ntlmrelayx, incorporating various new features. These enhancements enable ntlmrelayx to relay via IPv6, facilitate WPAD file serving, automatically detect proxy requests, and prompt the victim for appropriate authentication. For those interested in exploring these new features, the relay-experimental branch offers a glimpse.
To serve the WPAD file, simply append the -wh
parameter to the command prompt, specifying the host where the WPAD file resides. Given that mitm6 grants us control over DNS, any nonexistent hostname within the victim network suffices. To ensure ntlmrelayx listens on both IPv4 and IPv6, employ the -6
parameter. The accompanying screenshots demonstrate the seamless operation of both tools: mitm6 selectively spoofing DNS replies and ntlmrelayx serving the WPAD file while relaying authentication to other servers within the network.
-
Now, as we proceed with the attack, accessing the compromised Domain Controller (DC) should yield sensitive information.
If you've been following along with this blog series, you'll recall our earlier mention of a common mistake regarding the SQL service password in the description. Now, as we delve into the files within our "pwned" folder, a notable discovery awaits us: opening the "domain_users_bygroup.html" file promises a surprise.
Let's go even further by trying to login as the system administrator from KJOY Machine and see what will happend :
As we can see our ntlmrelayx tool just added new user for us in the network , we can even check that from the DC machine :
IV - Defenses and mitigations :
The only defense against this attack that we are currently aware of is disabling IPv6 if it is not used on your internal network. This will stop Windows clients querying for a DHCPv6 server and make it impossible to take over the DNS server with the above described method.
For the WPAD exploit, the best solution is to disable the Proxy Auto detection via Group Policy. If your company uses a proxy configuration file internally (PAC file) it is recommended to explicitly configure the PAC url instead of relying on WPAD to detect it automatically.
While writing this blog, Google Project Zero also discovered vulnerabilities in WPAD, and their blog post mentions that disabling the WinHttpAutoProxySvc
is the only reliable way that in their experience disabled WPAD.
V - Conclusion :
In conclusion, the exploration into IPv6 attacks has revealed significant vulnerabilities in network infrastructure, particularly concerning DNS and WPAD configurations. The demonstrated exploits, including mitm6 and WPAD manipulation, underscore the critical need for heightened awareness and proactive defense measures within organizations.
As highlighted, the absence of IPv6 DNS handling presents a glaring security gap, allowing attackers to intercept crucial authentication attempts. Additionally, the exploitation of WPAD further exposes networks to unauthorized access and data compromise.
While disabling IPv6 and implementing specific Group Policy measures offer initial defenses, the evolving nature of cyber threats necessitates ongoing vigilance and adaptation. The recent findings by Google Project Zero underscore the urgency of addressing these vulnerabilities comprehensively.
Ultimately, mitigating IPv6 attacks requires a multifaceted approach, combining technical solutions with robust network policies and user education. By staying informed and proactive, organizations can enhance their resilience against emerging cyber threats in an increasingly interconnected digital landscape.
Subscribe to my newsletter
Read articles from Ghassan Amaimia directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Ghassan Amaimia
Ghassan Amaimia
I am a dedicated cybersecurity student with a passion for protecting digital landscapes and a keen interest in ethical hacking. Currently, I am preparing for the prestigious Offensive Security Certified Professional (OSCP) certification. This certification will enhance my skills and knowledge in penetration testing and network security. With a strong commitment to continuous learning and professional growth, I aim to contribute to the ever-evolving field of cybersecurity.