From Secure to Breached: The Journey from Confidence to Compromise

“We’re Totally Secure… Except When We’re Not”

How many times have you heard the phrase “we take security seriously” from companies eager to assure you of their bulletproof defenses? A few times, I’m sure — it’s a popular mantra in the industry, as if every company possesses a magical cybersecurity wand that fends off every conceivable threat. I mean, they utilize a stack of XYZ security vendors that they heard about at conferences and have clean penetration tests, so how could they not be super duper secure!?

All too often, businesses that tout their top-notch security find themselves caught off guard by unforeseen vulnerabilities, leaving them highly exposed and vulnerable. In reality, such confidence can be misplaced when faced with actual malicious actors or skilled security researchers who often uncover vulnerabilities that traditional assessments and vendor solutions might miss.

Consider the topic of authentication bypasses (traversal of one or more authentication mechanisms), which can provide unauthorized access and control over critical admin accounts, entire network/application portals belonging to an organization, and even the ability to exfiltrate highly sensitive PII. This article explores how even the most robust security assurances can unravel when faced with sophisticated threats. It highlights the crucial need for continuous vigilance and proactive measures to stay ahead in the ever-evolving landscape of cybersecurity.

At first glance, the target seemed to have a fairly solid set of defense mechanisms. It showcased a robust, albeit pesky, web application firewall, alongside strict access control protocols. Direct attacks and exploitation attempts on the target’s main web applications appeared to be effectively thwarted. The engagement brief mentioned frequent audits and testing, suggesting that the primary assets were well-protected. Furthermore, the immediate assets were also limited in functionality, so it was time to dig a little deeper.

I mean, maybe this is a waste of time, right? It’s not as though organizations with such a heavy security layer could ever lose track of assets they own…right?

Well… let’s get into it!

Overlooked assets pose significant risks to organizations because they often become the weakest links in a company’s security posture. These forgotten assets typically include outdated servers, neglected databases, and unused network segments that slip through the cracks of routine maintenance and audits. This oversight frequently occurs due to rapid growth, mergers, or shifts in organizational priorities, which can lead to a lack of comprehensive asset management.

Without direct visibility into these assets, companies expose themselves to potential data breaches and cyberattacks, highlighting the importance of continuous monitoring and thorough inventory practices.

Digging Deeper

My recon process has different branches and can take many different forms, depending on the target I’m after. In this particular case, I decided to hop over to Hurricane Electric and started poking around.

For those unaware, Hurricane Electric is a great publicly available tool for digging deeper into network details. Known for its strong network infrastructure and IP address services, it provides useful information about how IP addresses are connected and routed. By tapping into Hurricane Electric’s global network data, you can trace IP addresses and see how they link up within an organization’s network.

After searching for the target’s organizational name here, it presented several values as a result, such as ASN’s/IP ranges associated with them, all of which belong to the target in question.

Shodan Sleuthing

NOTE: This article does not go into how to set up Shodan CLI, API keys, etc.

For anyone not familiar with Shodan, imagine a search engine that doesn’t just browse the web but dives deep into the vast sea of connected devices and services. That’s good old Shodan for you. It’s a powerful tool that scans the internet for everything ranging from web servers and IoT devices to routers all the way to industrial control systems. Shodan indexes these devices, revealing not just their IP addresses, but also the software they’re running, open ports, and even the geographical location of their servers.

Shodan offers both free and paid plans. The free version lets you search and explore connected devices but has limits on queries and data. Paid plans provide more features, including advanced search, higher query limits, and detailed analytics.

Moving on, with the discovered target ranges, I looped them into Shodan for a quick glimpse into any additional active assets that may be lingering about.

What’s going on in this command? Well, I’m querying Shodan for a specific IP range and then specifying that I want the IP address, hostname, associated port(s) and any additional information as to what may be running. For me, the details I’m after can differ depending on the recon path I’m after. Thus, I prefer to fine tune what I’m after as opposed to running default queries when leveraging scripts, tools, or any other manual recon action(s).

Here, the results depicted a few interesting juicy endpoints, all of which were up/active. Due to the privacy associated with the engagement, I have obfuscated some relevant information related to this example. However, the entry with “Server” in the HTTP title result was part of a longer string, similar to something along the lines of “Prod Test Server Admin.”

Unfortunately… this is definitely something that the organization forgot about asset wise. Fortunately, for me, it is ABSOLUTELY something that I would go on to check further!

File Fuzzery Magic

Upon first accessing the area, I was met with a rather bland Administrator login panel area, with the only option being to log in.

After spending some time analyzing any/all JavaScript files and all resources of the area, nothing really stuck out in terms of direct immediate exploitation. However, with this being an IIS server, I immediately took note of the the “/new_login.aspx” landing when the associated area is loaded.

“Armand, dude, bro, what is your fuzzing process? I need a magical answer!”

Welp, sorry to disappoint, but…again, as I mentioned before, as with most of my methodologies, it differs depending on what I am after and/or looking at, thus there is no magical answer here. In this particular case, the word “new” was rather interesting to me. If something is “new,” then there may be a possibility that it potentially used to be “old” at some point in time.

Though, could this be a rabbit hole, since we always expect our organizational SysAdmin/Dev buddies to always ensure that security is in tip top shape and that any decommissioned/retired dangling directories/endpoints are completely removed?

Yep…

It totally was…

NOT removed…

Let’s Talk About It

Fuzzing for me generally involves using my trusty friend, FFUF.

NOTE: This is not an in-depth peek into FFUF and its advanced usage, though it highlights the main point of a specific type of fuzzing I prefer to do.

Usually, when fuzzing is leveraged, I see it being done in the classic way of just using one or more wordlists with the standard “https://blahtest.com/FUZZHEREPLZ” method. This is fine and dandy, but I believe that the real magic is in the additional creative ways that one can leverage fuzzing.

Since I knew that “new_login.aspx” existed, I crafted and ran the following FFUF query, which would show me 302/200 responses associated with any direct wordlist value hits:

ffuf -u “https://highlysecure.supersecuretarget.com/FUZZ_login.aspx" -w /path/to/armands/wordlist.txt -mc 200,302

I quickly saw a 200 response for “old_login.aspx,” which when visited, led me through to a totally different looking panel.

Peeking Behind the Curtains

When I inspect targets and any type of asset that I happen to be testing/viewing, I always look to my co-pilot Burp Suite to help me sift through each and every call/response.

When I attempted to log in with random credentials, I noticed that the response immediately brought me back to the main area, due to the following JavaScript snippet I observed, intended to redirect due to the “top.document.location.href=old_login.aspx” line:

<script language=’JavaScript’>
top.document.location.href=’old_login.aspx’
</sript>

Replaying that same request again, except this time completely stripping that entire redirect action had a rather…odd response.

After I removed the entire thing and let the request through, I immediately noticed a slew of PII being presented to me, ranging from what appeared to be administrator accounts, actual users of the platform, and any/all relevant information for them, such as full names, addresses, financial information, etc. I was on the super secretive administrative back end panel with full access, able to make very sensitive and rather…scary changes, and even exfiltrate all obtained data.

After realizing how super duper secure this area was, I was able to confirm that it was an administrative dashboard used for all sorts of account changes, new admin account creations, with the ability to take accounts over, tweak server settings, and also manipulate the organization’s customer service endpoint.

In the hands of an actual malicious actor, this would have been a treasure trove of highly sensitive data, especially due to the number of records/users with full PII.

Why Did This Happen?

Well, wait a second, wasn’t this the highly secure target that had the latest and greatest security vendors on their aside, in addition to squeaky clean penetration tests/assessments?

Hmm, well about that…

In this particular case, it seems that the application was relying solely on client-side JavaScript to manager redirections and enforce access controls. This is a big “no, no,” as it is inherently insecure. If manipulating the request ultimately allows access to the admin portal, it suggests that the server-side authentication or authorization mechanisms are completely missing and/or not implemented adequately. The server should always verify whether a user is authenticated and authorized to access certain pages, regardless of any form of client-side scripting, etc.

Using client-side scripts for redirection or access control means that anyone (such as myself) with the ability to modify or intercept JavaScript can potentially bypass these controls, which in turn bypassed authentication entirely.

That’s it for this article, thank you for reading!

As for myself, on to the next “secure” target.