Tuesday, July 31, 2018

Practical Protection Against DNS Rebinding Attacks

DNS rebinding is a known attack against the same origin policy of modern browsers. 

The attack works by abusing DNS where a request with a small TTL is set. After the TTL is reached, another query that resolves to another IP address (a local or internal IP address in typical cases). This way, an unauthorized party is capable to bypass the same origin policy by loading malicious code on browsers, then executing it against local or internal networks. Theoretically speaking, SOP prevents this from happening, however, DNS rebinding can bypass this protection on certain circumstances.

There has been a large amount of research on exploiting DNS rebinding attacks in the previous years.


Although that this attack is known for years, securing an environment against DNS rebinding is normally done on application level only.

I don't find this to be the best approach, as there is a larger surface that we can control to block these attacks.

Proposed Solution

A DNS rebinding attack that exploits a local service shows that the domain name is pointing to a loopback address. Similarly, if it's exploiting a service in the internal network, the domain name will be shown to be pointing to a private address.

In a well-structured environment, we should not rely on public DNS records to point to a loopback or private address; there is no reason to do so.


If the DNS query response is a record that points to a loopback address, then this is a potential DNS rebinding attack. This should be blocked.

If done correctly, this will effectively block DNS rebinding attacks against local addresses.


DNS resolvers have this feature built-in. For example, you can configure BIND to block a query where the DNS record is on the IP range.

IPtables can help with applying a patch too. The problem that there is no direct way to apply it.

$ iptables -I INPUT  -p udp --sport 53 -m string --algo bm --hex-string '|7f000001|' -j DROP

This will block any DNS UDP inbound traffic on port 53 that holds "127".

Why not ""?

The internal loopback is /8 range. Any IP address on the range is pointing to the associated local machine. 

Will this IPtable rule 100% mitigate against the attack?

This is a starting point for a research on protecting against DNS rebinding attacks. It initiates a starting point for security vendors and endpoint security solution vendors to apply it for customers.

All IANA-private IP ranges should be blocked within local network using the same approach discussed above.

This is of course in addition to IPV6 address that points to the internal loopback.

The IPtable command is a simple proof of concept.

Blocking DNS queries that resolves to Private IP addresses via DNS resolvers

DNS resolvers have the ability to block this attack. For example, BIND9’s RPZ (Response Policy Zone) can be configured to block responses of queries resolving to specific IP addresses via “Policy Trigger - IP Trigger”.

This can be a stable solution for production environments.

How about QUAD9 Secure DNS Resolver?

I have tested QUAD9 Secure DNS resolver, and they apparently do not provide protection to DNS Rebinding attacks.

Other DNS resolvers are assumed to not provide protection, as this is not their goal. However, QUAD9 should block attempts of DNS rebinding attacks.


I would like to thank Andzej Valcik for his contribution to the research.

Update (September 16th, 2018):

 NCC Group released a research regarding DNS rebinding attacks along with a tool called "Singularity".

An interesting bypass that NCC group demonstrated in the research is the usage of a CNAME that points to "localhost". Since "localhost" is already registered in the typical local resolver (at hosts file for example) as, this will be also required to be blocked using the same approach mentioned in my research.

Blocking this bypass will be straightforward. The rule should block/drop any DNS query that responds with a CNAME of "localhost".

 Link to NCC group research: Link

Monday, July 23, 2018

Creating an Emojis PHP WebShell

I recently came across an interesting behaviour on PHP. Apparently, PHP permits the usage of Unicode characters as variable names. Therefore, friendly emojis can be used as a PHP variable.

$😶="Hello World!";

>> Hello World!
Which is valid.

I thought about making a fancy example of a PHP Web-Shell using emojis. This is made for entertainment purposes, no real advantage is gained by using Emojis webshell. It may disturb/confuse a WAF or back-end parser, but it’s not confirmed against a real-world environment.


Usage can be as:

You can create a CLI for it to do more; I am only publishing it as a proof of concept.


[Download] Emojis web-shell: [Link]

Tuesday, July 17, 2018

Using HTML Attribute Separators for Bypassing WAF XSS Filters


This is an experiment I have done recently in order to identify and utilize attribute separators in constructing XSS vectors. The crafted vectors can be used in bypassing XSS filters on modern browsers. These characters can be used in bypassing WAF XSS filters.


An example for a common XSS vector is:

<img src=x onerror=alert(1)>

We will be using this vector as a baseline for the demonstration in this experiment.

An image is requested at `./x`. If the image does not exist or invalid, the JavaScript event handler executes the JavaScript code as instructed. The space “ “ value is what is separating the attributes.

A typical XSS regular expression that blocks this example vector checks for whitespaces.
This can be bypassed via the exact vector by using the slash “/” character as an attribute separator (a well-known payload):


Fuzzing for Valid Attributes Separators in Modern Browsers

HTML is a very flexible language. Browser engines render contents in numerous structures. I have written a simple fuzzing script in JavaScript that renders all Unicode values as attribute separators in a browser.


1. Carriage-Return (0x0D)
2. Line-Feed (0x0A)
3. Horizontal Tab (0x09)
4. Form-Feed (0x0C)

In addition to the previously known characters: Space (0x20) and Slash (0x2F) characters.

Notes on Bypassing WAFs Using Identified Attributes Separators

In general, WAF rule sets are strict on blocking certain inputs. By utilizing odd attribute separators, it’s possible to bypass weakly written WAF rules. This is an aid to construct a valid XSS vector; I do not expect a vanilla <img(attribute-separator)src=x(attribute-separator)onerror=alert(1)> would be a straight payload that bypasses a WAF rule set directly. Instead, tweaking the payload can increase the potentials in writing a valid vector that bypass the WAF XSS filters.

Furthermore, I have demonstrated a number of payloads previously that utilizes attribute separators implicitly to bypass XSS filters of popular WAFs. You can read about my previous research at [Link].

The techniques were tested against Mod-Security CRS. The default installation blocks almost all variants; raising the Paranoia Level to 2 protects from the remaining payloads.
I would like to thank Dr. Christian Folini for testing it against ModSecurity CRS.

What to Do?

Penetration Testers

These characters can be used to craft better payloads to fuzz WAF XSS filters. Feel free to use them on your next WAF assessment.


Consider different HTML attribute separators when constructing filters. It can be used to bypass rulesets.