Tales from the Front Lines: Whitelist and Forget, A Cautionary Tale

Stopping attackers and their malicious intent is every security practitioners’ goal. But there are times when we need to grant unfettered access to network resources for day-to-day operations. Better known as whitelisting, I have seen scenarios where an over-zealous whitelist granted from-anywhere to-anywhere access to a database. Security best practices dictate that this level of permissiveness should raise an eyebrow or two.

Keep digging when you see any 10X pop

During a recent customer engagement, our CQ Prime Threat Research team observed a massive traffic spike coming from a single whitelisted IP address. Although the IP was whitelisted (and many security professionals would move on), the 10X volume of traffic drove our research team and the customer to dig a bit further. In analyzing the traffic and its behavioral characteristics, it became clear that attackers had identified a whitelisted service and had begun using it for their nefarious purposes.

Why would you whitelist this traffic? 

A quick WHOIS lookup of the whitelisted IP identified it as a translation and localization service used by the customer. The translation service uses some unique technologies to allow any organization with a web presence to have their site translated into many different languages simply and easily. All the organization needs to do is direct their DNS records to point at the translation servers, sending API calls back to your web service. It works very well, as evidenced by their customer testimonials.

The service allows www.examplecompany.com to subscribe to the translation service, stand up a site in a country, say Brazil, www.examplecompany.br and have the site run in Portuguese with minimal, if any, additional effort. All the backend calls occur between the translation service and the application fabric at Example Company’s data center or cloud deployment. For the translation service to not look like a Denial of Service attempt (because a single IP is making all the requests), Example Company must whitelist the translation service traffic.

Proxies (and attacks) hiding in plain sight

To make their attack appear as legitimate as possible, the bad actors routed their traffic through BulletProof proxy network before hitting the translation service. BulletProof Proxies allow a bad actor to distribute (and anonymize) their attack traffic across many ISPs in different countries. In the example above, the attack traffic might be routed through a proxy network in Brazil, while the bad actor might be in the U.S. The target destination is the whitelisted translation service IP address, which bypasses all security inspection.

No doubt many organizations have whitelisted not only translation services but also accessibility services that assist the hearing and vision impaired. These services provide significant value to any organization, but this should be a reminder that you should trust but verify that they have blocked bad traffic.

Based on volume and other behavioral characteristics observed, the customer and CQ Prime Treat Research Team deemed the traffic to be malicious and policies were implemented to mitigate the attack.

Whitelist judiciously; review and verify frequently

The lesson to learn here is that once something is whitelisted, don’t ignore it. A best practice is to review those “permanent” settings and make sure they do what you intended when first implemented. Whitelisted services, broad ranges of IP addresses, and even applications require periodic reviews to ensure they are used only for the intended purposes.