Leveraging Malicious DNS Records For The Subversion of Hardened Web Redirect Code

Until recently, I wrongly assumed that servlets already patched for open HTTP Location: redirect vulnerabilities were a lost cause in the theater of web app exploitation (TL;DR Scroll down to see hyperlinks & DNS zone file entries.) Some instances of such server-side code are riper for attacking than one may initially think — depending upon many deployment details of course including: HTTP daemon, WAF’s and other middleware software configs, server-side coding, control flow as determined by CGI programming, etc. Under the contemporary state of web application vulnerability research, I only recommend malicious DNS record creation to be used as a last-ditch effort when all other test cases fail. Before applying DNS to the problem, it’s still prudent (and much easier) to test for more rudimentary edge cases in the behavior of server-side code. Perhaps start by checking if encoding the URL with Basic authentication credentials makes a difference (similar to pseudo-code hyperlinks shown below):

Original Hyperlink Supplied by Redirect Script on Target Server:
Modified Hyperlink Likely to Bypass String Verification Functions:

After clarity is established upon the fact that the usual bag of tricks won’t be working this time, begin poking around at server-side code behavior in the context of resolver library use. Some developers have actually based their open redirect mitigation strategy upon the domain name system by requiring a successful DNS lookup for the host piece of a given URI as determined when invoking the resolver library call getnameinfo() (known as GetNameInfoW() to WinSock). However, the host name must first and foremost be a member of the current origin’s domain. It’s quite helpful when distinct behavior can be observed between the submission of a location with a non-existent host name versus submitting a link with a host that properly resolves. Once that happens, one can be fairly certain that DNS has indeed entered the equation. Consider the syntax of the following hyperlink:

Percent-Encoded Periods Offset Real Domain From Crafted Record:
Location Redirect After HTTPS Response With 3XX Status Code:
Location: http://xx.dom.evil.co:81/d/

There are many reasons why such attacks succeed. Maybe there’s a naive test for the dot acting as the field separator for the URL host’s main domain and TLD (an attempt by the servlet to detect if the host name has been terminated.) For instance, rindex() from string.h may analyze the query variable u to ensure there are no further periods after a trusted host that strncasecmp() detected, or worse —strstr()! Another faulty approach is to use ispunct() from ctype.h on characters after the web server’s domain when looking for a colon denoting alternate port number use or forward slash marking the beginning of a file system path. Many times webmasters just write bad regular expression patterns.

Any number of things can make percent-encoding requisite for malicious redirect links, but one of the most significant is middleware that will decode the packed hex digits into the dot separating DNS domains before the URL is output as an HTTP Location: response header. In the case of multi-tier architecture double encoding (or more) may be necessary. Consider a reverse proxy and load balancer on top of a WAF!

Obviously, exploitative use of the HTTP query variable named u in the URL above required preliminary setup of a nameserver authoritative for the evil.co domain. A vulnerable site I tested permitted both CNAME (Canonical Name) and A (Address) records of the IN (Internet) type to be used as well as wildcards. Two corresponding zone entries are shown below in the ISC BIND (Berekeley Internet Name Domain) style RR (Resource Record) format:

Zone File Syntax in Rogue Name Daemon Under Attacking Entity Control:
xx.dom.evil.co. 1 IN CNAME redteam.evil.co.
xx.dom.evil.co. 1 IN A

The terminating period that makes the records above setup an FQDN (Fully Qualified Domain Name) can also be used within malicious HTTP requests — more on that soon. Set TTL’s small in case further updates are needed as testing unfolds! Depending on the target site’s CORS policy, (semi-)arbitrary CSRF’ing of the user’s session may now be possible. Moreover, that session could be continuously polled out-of-band with XHR to avoid idle session tear-down.

Doubly-Encoded Malicious Redirect Link With FQDN SOP Subversion:
Location Redirect After HTTPS Response With 3XX Status Code:
Location: http://xx.dom.evil.co

Who said logout CSRF’s should be excluded from bug bounty programs?! It’s fairly common for sign-off pages to perform redirects. Aside from skipping over non-cached TLD RDATA operations, that DNS host termination dot syntax has quite a few perks for attackers . The virtual hosts configs of some web servers will allow host names to be served in both FQDN and non-FQDN formats. Still wondering what the big deal is?

First of all, this is a SOP (Same Origin Policy) bypass. If that’s news to you, then read up on The Web Origin Concept in RFC6454. If you’re already hip to SOP bypasses..ponder over the attacks that could be carried out by data flow and state transitions resulting from the doubly-encoded malicious redirect link above. That so-called “logout” page won’t necessarily end an active session when its authorization token is in a cookie whose domain attribute doesn’t match the FQDN in the malicious link’s host component!

During my own testing, a site hosted by Akamai and using Perl CGI scripts to serve HTML5 documents left the login session authorized while malignant JavaScript statements were served by a “test” rogue web server (like xx.dom.evil.co is above.) Do _not_ count on web software to treat cookie origins or domain attributes canonically — or any other HTTP state management mechanisms for that matter. Although the IETF has attempted to solidify behavior by drafting up the SameSite and $Origin attributes for cookies as well as a Origin-Cookie HTTP request header, none have ever been published in a finalized RFC document. RFC6265 which updated cookies as an HTTP State Management Mechanism was published in April of 2011 and alluded to the problem under “Ambient Authority” in “Security Considerations”. Trailing dot domains have extremely unpredictable behavior in the realm of HTTP, TLS and other cloud computing essentials; trailing dots have negatively reinforced many areas of application vulnerability taxonomies for decades now. For more information on this vast subject, see this blog article about trailing dots with Extended Validation SSL Certificates on the Amazon Web Services CloudFront WAF/CDN.

To be extra diabolical, apply double hex nibble percent-encoding obfuscation to the vulnerable logout page’s file path component of its hyperlink in order to stifle any thought by the target about actual logout or contacting technical support if they happen to see the attack URL in their browser’s status bar (or possibly address bar if they’re attacked passively.)

Syntax of Basename Corresponding to CGI SCRIPT_NAME (Before):
Obfuscating Logout Servlet via Double Hex Nibble Percent Encoding (After):

Odds are stacked in the attacker’s favor when they have admin access to HTTP daemons on the public Internet and authoritative nameservers with SOA (Start of Authority) records which correspond to a zone that those HTTP daemons have virtual host(s) configured in. Attackers that have LAN’s or wireless intranets in their sights have additional options when taking advantage of DNS to attack buggy partial redirect servlets that I won’t be going into detail about. In short, a spear-phishing MoTS (Man-on-The-Side) can utilize an HTTP redirect to a plain text protocol the target’s browser supports a URI scheme for to airpwn-ng some MiTC (Man-in-The-Client) action. Alas, if an FQDN SOP bypass isn’t possible consider redirection to forward-resolving host names in the .arpa DNS hierarchy, especially if the web server renders the vulnerable domain when unknown hosts are requested (this is being left as an exercise for the reader.) Don’t forget to subscribe to my feed — I’ll be publishing more dank vulnerability research soon…Peace!