Principle

Databouncing at it's core, is soliciting a Hostname Lookup via something somewhere else outside of your networks reach… so what can you get to perform a hostname lookup? we’ve seen host headers, link previews, email addresses but is there more ? if it performs a lookup ... it will probably have utility, we focus on headers as example one, and an easy corpus to demonstrate with.

Databouncing takes domain level blocking defences off the table and provides A bit of a nightmare for defence to understand where it was used and to what effect.

Currently there are no meaningful countermeasures, this means whatever defence product you're reliant on should be seen as useful in other places, if we're being diplomatic.

A web request leaves your organisation, its connecting to a service your computers connect too every day, frequently, only this request has a different Host header, this host header is ‘secretmessage.exfilz.uk’, you wouldn’t notice unless you had deep inspection, but its going to that trusted domain … so its no big deal … unless somewhere on that request requests journey something wants to know the IP address of the hostname, this can happen for a number of reasons, but when it does happen, it’s handing over your ‘secretmessage’ to your domain, as the subdomains are the data stores… now break files up into small chunks and line them up. Databouncing.

In real terms defenders are fighting web requests that look like legitimate requests going to legitimate, trusted destinations that will later unbeknownst to the org will transform into a DNS lookup Morphing from a TCP protocol to a UDP protocol

These web requests could be Http1,2 or 3, a HEAD, PUT, GET it could be fired at many otherwise trusted domains prior to this new method - below an eleven minute video of some observations from vulnerable domains ripe for their assumed domain trusts to be abused

And to that point, the lookup abusing headers at least will often take place without the knowledge of the domain that is being abused.

If you look at the image below, we have tried to conceptualise the principle, the circle is the trust between yourself (A) and your trusted service the pip at the top of the circle( B), however, the pip outside of the circle (D) above to the right, is the exfiltration.

The challenge for organizations is that first leg of the exfil are known, trusted and needed by business.

Once you get this principle, the internet becomes a playground for creativity, how many ways can we get trusted 3rd party systems to perform a hostname lookup that unbeknownst to them is a transport medium for covert data transport ?

Here's a few we've been working on at various paces:

• Web Request headers
• Link Previews
• Email

For now the heaviest focus from us will be Web request headers, there are a few good reasons for this that we will go into in other parts of the site but at a high level, can you see why those three would work ?

Web headers, for nosey analytics, insight, threat intel, network reports, optimizations for CDNs and more...

Link Previews, for filtering good and bad traffic, or it's own insight

Email, well, it has to perform a lookup to find the records

Coming back nicely to 'How can we get other things to perform a lookup?' this is what we've found ourselves enjoying as driving question in this space.

The reason this is and will continue to be successful is that everyday processing of information is embedded in the modern internet, without specific context and extremely strict governance, defense is mostly really fighting intent.

To visualise the journey in a more technical lens you can look at this flow diagram you will see how DNS lookups are part of the modern web and it’s constant need to consume as much given data as possible, that’s what we’re exploiting.

The Closest pre-existing issue we can find to Databouncing is the 'Confused Deputy', only the 'target' mentioned below in our case would be our exfiltration address, or end game destination, perhaps there will be some adjusted wording in the future.

CWE-441:

Unintended Proxy or Intermediary ('Confused Deputy')

https://cwe.mitre.org/data/definitions/441.html

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. 

If an attacker cannot directly contact a target, but the product has access to the target, then the attacker can send a request to the product and have it be forwarded to the target. The request would appear to be coming from the product's system, not the attacker's system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests, since the requests would not be coming directly from the attacker. 

Since proxy functionality and message-forwarding often serve a legitimate purpose, this issue only becomes a vulnerability when: 

• The product runs with different privileges or on a different system, or otherwise has different levels of access than the upstream component; 
• The attacker is prevented from making the request directly to the target; and 
• The attacker can create a request that the proxy does not explicitly intend to be forwarded on the behalf of the requester. Such a request might point to an unexpected hostname, port number, hardware IP, or service. Or, the request might be sent to an allowed service, but the request could contain disallowed directives, commands, or resources.