We all know how important operational security (OpSec) is within our own organizations and professional lives, but how many of us think about the OpSec of the vendors we work with? In my own experience working with companies of all sizes, this is one of the first things that I look at whenever I am trying to assess the overall security posture of a company. If they’re sloppy with the small, easy-to-catch details, they’re probably missing a whole lot more. The reality is, that sloppy OpSec can put the value of any security solution at risk, and potentially undermines the investment that has been made.
We take our operational security very seriously to ensure that we’re not making any rookie mistakes that could adversely impact any of our customers. As such, we naturally look to our peers and competitors and in doing so, discovered that while some are tidy, many are not. Here’s what we found with some suggestions on how to avoid these pitfalls at your organization.
Why does my security vendor’s OpSec matter?
In security, it is important to keep any and all information that may be potentially beneficial out of the hands of our adversaries. This can include everything from the backend infrastructure / software that may be running on the backend, to the security solutions protecting these applications. The more an attacker knows, the easier it is for them to build out a successful attack. Therefore we want to work as hard as possible to prevent someone from taking even a small step.
What happens when OpSec is overlooked?
To really understand the impact of an OpSec oversight, let’s take look at a real-world example of an organization providing website security services which may not be following best practices. For the sake of anonymity, we’ll call this company “Anti Bot Website Protection Inc.” In this scenario, we’re going to pretend that we’re attackers attempting to perform a distributed credit card washing attack, to resell valid credit cards on the ‘dark web.’
The first thing we’ll attempt to do is to understand the security infrastructure sitting around the payment gateway so that we know what we’re up against.
What are we being told without even asking?
The first thing we will do is look at the HTTP Response Headers to a simple HTTP GET request to the website. This will serve as our starting reference point.
From here, the following key pieces of information are made clear:
- The application load balancer / proxy is Envoy
- The service is running on Google Cloud
- There is a service running on this website called Anti Bot Website Protection
After attempting to send a single HTTP POST request with our credit card testing bot, we receive a HTTP 403 Access Denied with a number of other HTTP Headers that match the earlier Anti Bot Website Protection ones.
One Google search later…
From here, we turn to Google, and simply search “Anti Bot Website Protection Inc Bypass” and we are served with thousands of results. The results of this search include pre-written / pre-configured bots, designed specifically to bypass these detections, as well as specific instructions on how to set up a new bot to bypass.
So within five minutes of coming up against this security solution, we’re able to leverage hundreds of hours of work done by others, and know exactly where to start with our attack.
Accessing Critical Code
Now let’s pretend that a bypass mechanism for this security solution did not exist on the public internet. We’d need to learn how the system works from the inside out, and attempt to find flaws that way. After finding the Anti Bot Website Protection Inc website, we look for the documentation about integrating their solution. In this case, many of these documents are accessible from the public domain. After finding the integration documentation for the Envoy proxy being used by our target, we can now read the exact script being used to trigger the solution.
Now that we have our hands on the crown jewels (the code being used to integrate the solution), we are able to understand exactly how it works. This leads us to finding multiple ways to attack the solution and perform our credit card washing attack that we set out to perform.
Final Observations
This is just one example of how a few small pieces of information can lead to a very detrimental outcome, that undermines the investment that we make in some security products. Therefore, in order to get the most out of the tools that you leverage, it is critical to assess the OpSec of these tools. If they miss the simple, little things, odds are they’ll miss the much larger, critical ones too.
At Kasada, we take this kind of Operational Security very seriously, and ensure that we always design our solutions and behave in a way that is conducive to providing our customers with the best possible service.