From War to Web Security, Protect Your Attack Surface from the Weakest Link
With the rapid proliferation of data, increasing number of domains and subdomains as well as rise in third-party providers, the number of entry points through which attackers can infiltrate a company’s web environment is endless. Attacks are increasingly causing consequences felt beyond the perimeter of an organization, as demonstrated earlier this year with the Colonial Pipeline breach, which caused fuel prices along the U.S. East Coast to soar, and the attack on software provider Kaseya that forced hundreds of grocery stores in the Nordics to shut down business for days.
What Is True in Battle Is True in Business
Security breaches often happen through an avenue that no one saw coming — a server no one knew existed, an old landing page, weak passwords or an application that was missing a patch. It’s perhaps never been clearer than today that a company is only as strong as the weakest link in its growing attack surface.
The challenges companies face in today’s internet landscape brings to mind the concept of survivorship bias and its most famous example from World War II. One of the biggest problems the United States Air Force faced during the war was how to prevent their aircraft from being shot down. Fixing armor made the aircraft heavier with reduced range, so a solution was only armoring the most essential areas.
After analyzing where its planes had suffered the most damage, it determined that it needed to reinforce the planes’ wingtips, central body and elevators. However, mathematician Abraham Wald pointed out that there was another way to look at the data. He argued that the shielding shouldn’t be where the bullet holes are, but rather where the bullet holes aren’t — on the engines, because that’s where the damage was on the planes that were destroyed and didn’t make it back at all.
By drawing on an analogy between the internet and World War II, it’s easy to see how companies put in more resources in visible vectors rather than the more dangerous and invisible ones. Whether it’s battle or business, it’s all about being proficient at what you do and removing the inefficient systems and processes. Are you putting your armor in the right places? Are you looking for security issues where the attackers are? Where are the bullet holes in your company you can’t see?
These real-life attack methods are all examples of how survivorship bias comes into play in modern web security — and how to avoid them.
CVE-2019-7609: Kibana RCE
Sometimes protecting the attack surface can be as simple as assessing whether it actually adds value to have certain systems exposed to the web. Kibana is a free, open application used by companies to visualize internal data. Because it is used for internal data analysis, it generally lives on the company’s intranet and does not need to be exposed to the internet — so putting efforts here would seem like an inefficient use of security resources.
However, a quick search on Shodan, a search engine for internet-connected devices, reveals that approximately 8,000 Kibana instances are in fact exposed online, and I’m willing to bet that many of them shouldn’t be. Add to the mix the fact that Kibana relies on Elasticsearch, a search and analytics engine for numerical and text-based data, which in turn relies on Java-based logging framework Log4j.
Are you putting your armor in the right places? Are you looking for security issues where the attackers are? Where are the bullet holes in your company you can’t see?
Making sure to keep an eye on what is exposed online, and taking it off the internet if it shouldn’t be there, will save you resources that are better used elsewhere.
WordPress Plugin ‘Mailchimp for WooCommerce’ Local File Inclusion
Just because your third-party application is up to date doesn’t necessarily mean it’s protected from attacks — there can still be less obvious security holes underneath it. WordPress is the world’s most popular content management platform, estimated to power close to 40% of all websites globally. Lots of companies have WordPress installed somewhere in their infrastructure, and it’s easy to believe that as long as you’re running the latest version, you’re safe.
An example of this could be if you’re using an old version of the WordPress plugin Mailchimp for WooCommerce. An attacker could access secrets like configuration, log files, API keys and passwords that can be used as a foothold for other attacks. This bug can also be pivoted to a Remote Code Execution (RCE).
Keeping inventory of all the sites you create, especially those temporary ones used for a campaign, will be key for preventing attack surface exploits like hostile subdomain takeover or an RCE. There are many open source and licensed options out there that can automate the monitoring and enumeration of connected and forgotten web assets, and alert you if they change in any way.
Expiring Name Servers
Sometimes parts of the external attack surface fall into oblivion because they don’t require regular maintenance — although they’re a crucial part of the infrastructure and therefore should be constantly monitored for issues. One example is name servers, which are usually configured once and then left to be. It’s likely more common to configure, for example, CNAME records for campaign sites than entire name server records. Because of this, name server pointers are easy to forget about. However, the impact can be devastating and far-reaching if an attacker takes control of it. This was the case with the top-level domain for the Democratic Republic of Congo, “.cd”.
A year ago, I found that one of the name servers for the .cd country code was about to expire. Clearly, a domain of such importance — used by a population of 90 million people — wasn’t supposed to expire, but someone in the Congolese government probably forgot to pay for its renewal. Luckily, expired domains don’t disappear immediately.
When I found it was about to expire, I began to monitor it, assuming someone in the Congolese government would pay to reclaim the domain. But, to my surprise, nobody did. During the Christmas holidays in December 2020, the domain was about to fall off the internet. Within minutes of the domain becoming available, I snapped it up for $9 to prevent bad actors from taking it over.
If it would have fallen into the wrong hands, a malicious actor could have run a man-in-the-middle attack to intercept millions of users’ internet traffic. By being in that position, it was possible to abuse the issuance of SSL/TLS certificates to further undermine encrypted communication. This means an attacker could not only see but also modify the traffic flowing to and from all .cd domain names even when encryption was enforced (including everything from regular web traffic to emails and other sorts of internet communication), all because someone had forgotten about this small but significant corner of their attack surface.
Hacking Yourself Is the Only Way to Protect the External Attack Surface
Attackers have eyes and ears all over the web, and the successful ones always look where others aren’t looking. When I approach a target as a bug hunter, I skip the main application and look for less obvious and sometimes simple paths. I go for the path of least resistance, and that’s how I’ve been able to find security bugs in Google, Dropbox, Uber and Tinder among many others. In an ever-changing security landscape, companies need to constantly hack themselves to keep up with the hacking community.
This means applying the hacker mindset and continuously monitoring the assets you have, and pressure testing to find exploitable anomalies. You can also team up with ethical hackers in various ways to minimize the available attack surface. The way I see it, collaboration between companies and hackers is going to get us to a safer internet sooner.