Detectify co-founder and expert bug bounty hunter Fredrik Nordberg Almroth (@almroot) recently spoke at Hack Your Stockholm, our first in-person event after a 2-year hiatus, addressing the issue of the growing attack surface of companies and how it is the most pressing issue facing CISOs today. He recaps his thoughts in this post. [Watch the keynote again]
With more organizations migrating to the cloud, new systems being exposed online and growing attack surfaces, security risks continue to change leading to an increased complexity. Alongside, the lack of transparency leads to an expanding attack surface that is hard to defend from attackers.
And even though there are more than enough security tools to choose from, I still find ways to get past a target’s defence and find critical bugs, and it boils down to these 3 things: survivorship bias, managing the growing attack surface and finding your weakest links.
Survivorship bias – battles in business
The current Internet landscape is hardly far away from the challenges faced during the second world war. I illustrated the concept of survivorship bias by a short history lesson from World War II. One of the biggest problems the United States Air Force faced was how to prevent their aircraft from being shot down.
Fixing armour made the aircraft heavier with reduced range, so a solution was only armoring the most essential areas. The American military reinforced the airplanes in the worst hit parts working from results skewed by Survivorship Bias. 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 argued otherwise and pointed out that there was another way to look at the data. And that the shielding shouldn’t be where the bullet holes are, rather it should go where the bullet holes aren’t – on the engines. The best practice was to look at airplanes that didn’t return. The planes getting shot in the nose area, engines and mid-body were being destroyed from the damage and weren’t making it back and that’s where the fallacy was.
Consequently, 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 looking for security issues where the attackers are? Where are the bullet holes in your company you can’t see? Are you putting your armour in the right places? How can you protect against what you don’t know? 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 one more dangerous and invisible ones. In an ever-changing security landscape, companies need to stay up-to-date with their internet exposed attack surface where continuous monitoring and collaborating with the greater security community and ethical hackers is vital.
Applying war strategies to web security
With the rapid proliferation of data, increasing 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. Oftentimes, security breaches happen through an avenue that no one saw coming – a server that no one knew existed, an old landing page, weak passwords, or an application that was missing a patch. Attacks are increasingly causing consequences felt beyond the perimeter of an organisation, as demonstrated by Colonial Pipeline being forced to shut down operations causing fuel prices along the East Coast to soar.
A company is only as strong as its weakest link in its growing attack surface and here are three instances where we were able to find exposed vulnerabilities before an another attacker did.
Hacking our way to read access to Google’s production servers
Back in 2014, Mathias Karlsson (@avlidienbrunn) and I found an XXE vulnerability in Google where I was able to run my own code on Google’s server.
My aim was to find the newest features and products or go for the really old legacy stuff that the tech titan might have forgotten. Using Google search itself, I found a feature that dated earlier than 2008 – the Google toolbar button gallery. As a website user, you could add your own button to the toolbar so that other users could find you. An idea we figured was worth trying was to conduct an XXE attack as I noticed the title and description fields were printed out when searching for the buttons.
The root cause of XXE vulnerabilities are naive XML parsers that blindly interpret the DTD of the user supplied XML documents. By doing so, you risk having your parser doing a bunch of nasty things. Some issues include local file access, SSRF and remote file includes, Denial of Service and sometimes even remote code execution.
The full assessment of Google took about four hours and you can attempt many attacks in that time span. We could have tried to access any other file on their server, or moved on to SSRF exploitation in order to probe internal systems. To say the least, it was pretty bad. We contacted Google straight away, got a reply from the Google Security Team and found that the vulnerability was worth about $10,000.
This vulnerability was the result of an old unmaintained system that Google underestimated. If a tech behemoth such as Google can get hacked, are you sure your service is secure?
Hack Yourself Stockholm Keynote: Fredrik Nordberg Almroth
Patreon’s exposed Werkzeug Debugger
Remember when Patreon was hacked in 2015? We notified them days before the breach that a serious configuration error could lead to attackers accessing their data. The delay in resolving the issue led to 15 gigabytes’ worth of source code, user password data, and private messages made public. Access to the source code has the risk of exposing the encryption key said to protect social security numbers and tax IDs.
Patreon developers allowed a Web application tool known as the Werkzeug utility library to run on a public-facing subdomain where a Flask web app running on Patreon’s server was enabled with Werkzeug debugging functions. The Werkzeug debugger allows visitors to execute code of their choice from within the browser. The code-execution capability is supposed to be triggered only after a developer enters a secret key that’s generated when the debugger first loads. But by design, the debugger will get activated whenever a covered Web app experiences an error or exception. As a result, even unauthorized people who visited Patreon could activate the debugging tool, as long as they could trigger some sort of bug on the site. The Werkzeug utility library created a patch to prevent this vulnerability but it was too late.
Malicious attackers essentially created an interactive shell which connected to them remotely, which made it possible for them to walk around the server and push all data over to the attackers.
This risk emerged because the company was running a staging environment that was left exposed to the Internet. Additionally, it ran with a less hardened config and the site had real user data. By using an EASM approach this system was discovered, not only by us but also criminals and the inevitable happened. The hack against Patreon should serve as a warning for companies to be conscious of the environment of the data.
How I hacked the entire nation of Congo
It’s rare but not unheard of for a top-level domain (TLD) to expire. I was looking at all the nameservers of country code top-level domains – the two-letter suffixes at the end of regional web addresses such as .uk, net.cn, .com, .net, and .org among the list of others. In my attempt to analyse all TLDs, I found a critically important domain name for one country’s Internet space beginning to expire.
The domain scpt-network.com was one of two name servers for the .cd country code assigned to the Democratic Republic of Congo. Clearly, a domain of such importance 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. The clock started to tick for Congo’s government to buy back the domain before it was sold to someone else.
When I found this critical domain name 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.
I accidentally managed to hijack a TLD: https://t.co/dKLCnZc0o8
— Fredrik N. Almroth (@almroot) January 15, 2021
All .cd websites and domains used by a population of 90 million people were about to expire. If it fell into the wrong hands, a malicious actor could 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. What this means is that an attacker could not only see, but also modify the traffic flowing to and from .cd domain names even when encryption was enforced (this includes everything from regular web traffic, to emails and other sorts of Internet communication).
I reported the vulnerability to the entity operating .cd, and by monitoring specific data points the issue was spotted and mitigated before bad guys would have the opportunity to.
How do you make sure you’re not the next target?
Whether it was Google, Patreon or Congo with vulnerabilities such as unmaintained legacy systems, exposed staging environment with insecure configurations and expired domains respectively, I went for the weakest link which an attacker could take advantage of. I spotted the bullet holes which could have impacted these companies in a big way.
The ubiquity of high-profile attacks in the last few years and risks by the aforementioned vulnerabilities have highlighted the importance of online security. While security may be occupying a growing space in the attention of workforces worldwide, a host of companies might be still taking their security hygiene for granted. For years, those safeguarding an institution’s digital infrastructure were considered back-room employees à la Moss and Roy from the IT Crowd, neither seen nor heard. This is why companies need to have the processes in place to reduce all potential risks and exposures. Indeed, it’s not enough to just meet the minimum requirements when it comes to security. It’s imperative to fireproof the house instead of spending most of the time putting out fires.
Organizations must continuously look for new attack surfaces through third-party testing and an external attack surface monitoring system. Hack your applications before an attacker gets unsolicited access to your information. Even if you have access control measures in place; implement defence in depth measures, apply cloud-based security for attack surfaces and constantly attack attackable points before attackers do. Go Hack Yourself!
More from Hack Yourself Stockholm:
Detectify customers continuously manage their growing attack surface with hacker insights
Detectify is the only fully automated External Attack Surface Management (EASM) solution powered by a world-leading ethical hacker community. By leveraging hacker insights, security teams using Detectify can map out their growing attack surface to find anomalies and detect the latest business critical vulnerabilities in time – especially in third-party software. The only way to secure your growing attack surface is to hack it but it doesn’t have to be complicated. With Detectify, continuous security starts with a few clicks. Begin your 2-week trial today.