GUEST ESSAY: Successful tactics threat actors leverage to probe, compromise vulnerable networks

When new vulnerabilities re announced or flaws are discovered in public or “off the shelf” applications, several things happen. News spreads of the risks while attackers and security professionals alike begin searching for potential attack targets for the purpose of exploiting or protecting them.

Related: How GraphQLs expanded the attack surface.

When Log4Shell first hit the street, we immediately saw attacks against almost every one of our customers.

As attackers started scanning for targets, our research team repurposed their techniques resulting in a tool that we used to help our customers find vulnerable API endpoints. This had a few interesting results, so let’s take a look at several different aspects of modern applications, as well as what can be found while poking around a large enterprise.

Scanning for viable targets

When an attacker is scanning a domain, the first thing that they want to do is find as much information about it as possible. This often means inferring something is available and testing for it. As the list of possible targets within an organization grows, it becomes necessary to weed out false positives, false negatives and possible flaws in the inference engine.

Standard things, like login endpoints, are easy to find since  requesting any resource that needs authentication is going to redirect to the login page. Application redirection is only going to get the reconnaissance to advance so far. In order to hit defaults, like endpoints and GraphQL pages, the scanner has to look for them.

Similarly, API spec documents and third-party  APIs are great targets as they offer rich data sets. Here’s a breakdown of attack targets:

Login Endpoints. Often these endpoints not only accept authentication credentials, but also help the unauthenticated by showing the data that needs to be collected. Requesting anything that should be authenticated usually redirects to the auth page, allowing for an attacker to probe that service.

GraphQL pages. Displaying data coming from large JavaScript Object notation, or JSON object, is something that can be scanned for. JSON refers to a file formatting standard used mainly to transmit data between a web server and a web application.

Scanners looking for these endpoints often are looking to scrape data from a target by exploiting the very nature of “fast data display” that GraphQL is built around.

APIs spec documents. As more and more organizations write API specifications, they often load them onto the internet to allow for sharing with trusted parties. These documents can be very dangerous in the wrong hands. Think of this as a map of every URL in the API as well as, whether or not the communication needs to contain certain data or authorization keys.

Leaky third-party APIs. Many applications are built with APIs specific to what their businesses do – particularly those that are built on a third  party framework such as health status endpoints that can tell an attacker that the service exists and is online. Default pages are often sprinkled throughout off-the-shelf application packages. Simply knowing what these endpoints are often yields tremendous results.

For example, some domain search results gave me a common endpoint that was returning an HTTP Response Code of 200. In web attacker parlance, that endpoint was online and responding.

Upon opening the endpoint communication, I realized I was dealing with the API for the company’s web-enabled email. The email service they use is a third-party service with an open API. In the mind of an attacker, this is interesting.

Recognizing attack vectors

When something is interesting, the attacker might spend a few minutes tinkering with this finding or they might spend the next month unlocking its secrets. If the target is important enough and the finding is rich enough, it is worth the time. Mostly, I want the API to show me what I need to make it work.

Post-recon means that an attacker is on to something, which could be unimportant or it could mean that they are poised for a vicious attack. The things that feed the attack come from doing thorough recon and the attackers have plenty of time. How do we defend our APIs against these attacks?

Discovering what is on our perimeter by acting like an attacker, in a programmatic way, allows for us to figure out what is being advertised to the outside world. Once we have a good inventory, testing for vulnerabilities in both the server and application fabric is important and will keep the attackers in the recon phase for much longer.

About the essayist: Jason Kent is a hacker in residence at Cequence Security, a Sunnyvale, Calif.-based application security vendor.

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at: https://www.lastwatchdog.com/guest-essay-successful-tactics-threat-actors-leverage-to-probe-compromise-vulnerable-networks/