WPAD still standing its (quicksand) ground
Article published in SecurAware October 2017 - HACK - by Matthijs Koot, Senior Security Specialist
During penetration tests performed at internal networks, one objective is to obtain credentials and gain foothold in an authenticated environment. A range of theoretical attack paths to obtain credentials can be dreamt up for any environment, but not all paths are equally likely to be traversed successfully.
One attack path that we find to (still) often yield success is the abuse of Web Proxy Auto-Discovery (WPAD), a feature that is enabled by default on Windows and Internet Explorer systems.
A specification of WPAD was drafted in the previous millennium by a consortium that had usability in mind: to help computers find an internet connection when connected to a network, without the need to configure a proxy server. The draft specification expired in 1999 [https://tools.ietf.org/html/draft-ietf-wrec-wpad-01] and never reached the status of Internet Standard --- but WPAD is still present and found in today’s networks.
WPAD depends on DHCP or DNS, and on Windows systems can additionally fall back on LLMNR or NetBIOS (NBT-NS). If the DHCP server does not provide a WPAD url (something like “http://example. com:80/wpad.dat”, where example.com is an internal system), DNS is used as fallback mechanism. On Windows, Link-Local Multicast Name Resolution (LLMNR) and NetBIOS are also used as fallback mechanisms. A computer that has WPAD enabled --- again, this is the default setting in Windows --- but does not get a WPAD url via DHCP, periodically sends out a discovery request using fallback mechanisms. When DNS-, LLMNR- and NetBIOS-responses are unauthenticated, and they often are, an attacker can send a fake response and make the vulnerable client send all HTTP traffic through an attacker-controlled proxy server. The WPAD process takes place without human interaction and if the attack is performed with due diligence, it does not disrupt the user’s communication.
When the user opens a website in their browser, the attacker’s proxy can inject HTML code that fetches an image over an SMB url pointing to the attacker’s proxy. If the user is NTLM-authenticated, the browser will send an SMB request accompanied by an authentication token, which the attacker then possesses. This is all without human interaction, too. Alternatively, the attacker can inject a fake login prompt. If a network is set up such that users are, under normal circumstances, sometimes prompted for their credentials --- for instance to log on to an intranet site even though they already entered those to access their system --- they might very well supply their credentials. If the user is already authenticated to a non-HTTPS intranet site, such as through NTLM authentication, existing authentication tokens can be readily observed by the attacker and, depending on circumstances that exceed the scope of this explanation, be directly re-used by the attacker, or be cracked (for instance using hashcat).
If the client system is power-on but not in active use by the user, authentication tokens can still be observed if the client runs auto-updating software, for instance anti-virus, that gets updates from an internal server over an authenticated (but unencrypted) HTTP-connection. Update mechanisms should be configured to use non-user accounts (i.e., a computer account or service account) that have long and random passwords, and that have the least viable privileges on internal systems. In practice, this is not always the case; an attacker may then, depending on circumstances, use this information to obtain a foothold.
Don’t use WPAD
Abusing WPAD has always been relatively trivial from a technical standpoint; and the open source tool Responder, created by SpiderLabs and now maintained by lgandx, makes it a breeze. The fact that WPAD is often deployed in insecure way is well-known for years; and more issues surround it, including that under certain circumstances, WPAD discovery requests can end up on the public internet [http://www.computerworld.com/article/3074509/ security/top-level-domain-expansion-is-a-security-risk-forbusiness- computers.html]. It is left as exercise to the reader to think about the potential implications.
Our advice: don’t use WPAD. If that is not an option, make sure client systems only accept WPAD responses via an authenticated transport means, such as DHCP Authentication, DNSSEC, or signed NetBIOS. Make sure that users are never prompted for credentials when browsing intranet sites under normal circumstances, make sure auto-updates are done using properly (low-)privileged nonuser accounts, enforce HTTPS on intranet sites, and promote security awareness. Also make sure the IT helpdesk has the right resources and attitude to help users recognise and report unusual activity, specifically including unexpected login prompts. Employees, including users, sysops and developers, should always feel encouraged, never blamed, for reporting on unusual activity!