CloudPiercer: Is your cloud-protected website’s origin exposed?
In October 2015, an academic study paper relating to the CloudPiercer problem was released (“Maneuvering Around Clouds: Bypassing Cloud-based Security Providers”). This describes how sites that rely on cloud-based DDoS mitigation are often still vulnerable to attackers. The study suggests that 71.5% of 17,887 of the top domains (by traffic) protected by one of several leading cloud DDoS mitigation companies (DOSarrest, Incapsula, CloudFlare, Prolexic, and Sucuri Cloud Proxy) are exposed.
There was a smattering of follow-up blog articles by those mitigation companies, but it has since gone quiet and I think the work is well worth re-visiting because the lessons to be learned are crucial.
The problem arises from the fact that there are two common ways of making sure that Internet traffic is intercepted and scrubbed by a cloud DDoS mitigation provider before it is sent to the destination network. The first is using BGP routing to protect a whole network, which relies on the target being large enough to have their own sizable block of IP addresses (a ‘class C’ is usually the minimum) and the financial and technical capability to arrange for full network protection. The second is to use DNS. DNS is routinely used to deploy cloud DDoS mitigation by companies of more modest size and capability.
The Domain Name System (DNS) is the method by which human-readable server addresses (such as www.activereach.net) are converted into machine-readable server addresses (i.e. an IP address). You simply ensure that all public services have an appropriate domain name, and point those names at the cloud-based mitigation system of your choice – and they will scrub the traffic and then send it onto your servers minus any DDoS attack traffic (or with it much reduced at least). That’s the theory.
The problem is that traffic can be sent from the Internet to a target server by an attacker simply using an IP address instead of using the domain name, and so any mitigation system relying on DNS to direct traffic through a scrubbing centre can be bypassed if the target IP address (known as the ‘origin address’) is known to the attacker.
This is where this academic paper comes in.
Preventing Origin Exposure Attacks
The paper describes a set of techniques collectively called ‘origin exposure’. These techniques are designed to look for the real IP address of the target network or server. Some of these techniques are really simple. For example, you may have changed the IP address in your domain records for your website to point at a DDoS mitigation service (A record and CNAME record), but your e-mail record (MX) – or a related subdomain, may contain IP address information that an attacker can use directly, or as a springboard to guess a vulnerable address.
The various origin exposure methods are interesting for security professionals and can be educational for IT staff as well, but the question for me is “What can I do to make sure that I am not still exposed – even after spending a lot of money with a cloud-based DDoS mitigation company?”
Here are my top tips for cloud DDoS mitigation customers.
● Talk to your DDoS mitigation providers about preventing origin exposure.
If they can’t give you comprehensive advice, then best choose another provider who can. The paper suggests that few customers are receiving, or following best practice.
● Change your public IP addresses as part of implementing DDoS mitigation (always-on service).
This doesn’t necessarily mean changing hosting provider, but you should ask your hosting provider to give you a new address range and take the time to reconfigure your network using the new addresses.
● Block any inbound traffic from sources other than your mitigator’s network (always-on service).
Your edge security might not be able to deal with volumetric DDoS attacks, but there should be no traffic you accept directly from the Internet – so block/drop it anyway.
● Disable anything on the server that might reveal IP address information on request.
Some web and other application services and pages can reveal the server IP address, there’s quite a list to check – diagnostic tools, log files, as well as the web pages and URL header information sent to the requester. Whoever is building your website should be able to lock this down for you. Otherwise a WAF (web-application firewall) might be employed to look at outbound information and block anything suspicious.
● Check your domain record to see what an attacker might be able to use.
Subdomains, domain history, MX records – all might expose your origin. Have a look at what is published about you and see if an attacker could make use of it. You could also look at using CloudPiercer – the tool developed by the authors of this academic paper to see if you are vulnerable.
● Test your DDoS mitigation
Good DDoS mitigation costs a lot of money and it is your corporate responsibility and right to ensure that the mitigation you are paying for works and cannot be trivially bypassed.
Ultimately, using DNS to force traffic through a scrubbing centre before it gets to you is far from ideal. It relies on security-through-obscurity, which is not a good thing. Nevertheless, it is better to have DNS based protection, than no mitigation at all.
These tips should give you the chance to review whether or not you are adequately protected. After all, you could avoid paying for a service that might well be useless to you when you come under real attack.
If you would like to find out more about mitigating this risk, please visit our web pages on cloud-based DDoS Mitigation and DDoS Testing.
