Application Protection Report 2019, Episode 5: API Breaches and the Visibility Problem
API Vulnerability Data
The sensor network that our partner Lorkya maintains found only 0.1% of attack traffic was definitively looking for API vulnerabilities. However, this is probably better attributed to the limitations of the sensor network than any trends about API attacks. Loryka’s sensors primarily detect wide-ranging probes and reconnaissance campaigns where attackers are looking for something to target, but API attacks will, by nature, be targeted and bespoke. There were still a few interesting findings worth mentioning.
Stalker_Portal
There was a burst of traffic from a single IP address that lasted for a few days targeting a specific path on any system it could find. The path that the traffic was targeting was www.example.com/stalker_portal/server/api/file.php. In just a few days this traffic came to constitute more than one third of the total traffic targeting APIs, and we don’t know what it is. It could be a misconfigured vulnerability scanner that was supposed to be scanning an internal environment, but we don’t really know, and we can’t draw any big conclusions from it.
PHP API Attacks
One interesting finding was that, of the traffic looking for APIs, 86.7% of it was scanning for sites with the PHP API. While notable, this is not actually surprising; we found in Episode One that 81% of the malicious web traffic Loryka detected on port 80 was targeting PHP. In other words, our API intelligence just cements PHP’s position as one of the great targets of the Internet.
Crafty Syntax Live Help
Loryka’s data also revealed that 1.8% of the API attack data was targeting paths containing a CSS file for an open source customer service product known as Crafty Syntax Live Help. An exploit was published in 2006 regarding a remote file inclusion vulnerability in version 2.9.9 of this product, specifically regarding a text-based database support API. It appears that someone was looking for an opportunity to exploit a very old vulnerability on any target they could find.
Generic and Other API Attacks
About twelve percent of the API-targeted traffic we saw did not fit into any broader trend, or was malformed. With the limited detail we get from Loryka’s sensors, it’s not possible for us to form a complete picture of this traffic. It is still worth exploring some specific traffic in detail, however:
- /api/.git/HEAD–This path probably represents an attempt to scrub HTTP header information from any system set up with a GIT API.
- /zabbix/api_jsonrpc.php–Zabbix is a network monitoring appliance with an RPC API that encodes traffic in a JSON format. This is probably an attacker scanning for servers with Zabbix APIs that have no access control.
- /include/api/xmlrpc–In all likelihood this is looking for any RPC-style APIs that might not require authentication.
- http://clientapi.ipip.net/echo.php?info=20180211134656–This path, which we saw exactly ten times in the dataset with different 14-digit values at the end, was interesting because it targeted an actual domain instead of any domain that had something at the target path. The target, IPIP.NET, offers IP geolocation and research services. We don’t know what the payload values were intended to do, or whether this was an attack or a misconfiguration.
- /api/log_browser/validate–This is another path whose intended target and function we do not understand, but we can reasonably guess that it was targeting the API of network traffic logging, server logging, or similar appliance, possibly for the purposes of network reconnaissance.
Known API Exploits with Plausible Linkages to Attack Patterns
We also found known exploits that line up with specific attack patterns, as noted by Loryka, that are worth mentioning:
- /wsdl/–Web Services Description Language (WSDL) is an XML-based description language that is often used for Remote Procedure Call-type SOAP APIs. In May 2019, a researcher published an exploit for ReadyAPI that allows attackers to upload WSDL files with malicious content to the API, such that when a victim requests information from the API, the malicious code runs on the victim’s computer. This attack path was probably targeting this vulnerability.
- StarOffice.ComponentContext–This attack path was targeting a remote code execution vulnerability in the Apache OpenOffice UNO API that StarOffice uses along with other open source office suites like Libre Office and OpenOffice.
- /v1/agent/self OR /v1/agent/service/register–These two paths are targeting a remote command execution vulnerability in the Hashicorp Consul service mesh API. The exploit for this vulnerability was published in early 2019.
- x41–We saw this path show up exactly 8000 times in our dataset, which corresponds to a known denial of service vulnerability in a network utility suite called Megaping, which is caused by a buffer overflow.
- pages.aspx?pageref=[SQL]–This path is an injection attack against the Grapixel New Media 2 tool’s ASP.NET API. Attacks like this illustrate how APIs are susceptible to many of the same kinds of vulnerabilities, and hence attacks, as other forms of software. Unvalidated user input like this is a risk no matter where it lands in a system.
- /api/hosts–Similar to the above exploit in an ASP.NET API, this is an attempt to target the REST API for the Unitrends Enterprise Backup (UEB) appliance with unvalidated user input, which results in remote code execution and root privilege.
- miner_getfile–Nanopool is a cryptocurrency mining and pooling platform that offers APIs for remote crypto miner management. The API has a remote code execution vulnerability that the attacker was presumably trying to exploit.
- /api.txt–This path probably represents attempts to use the network appliance Shodan’s API to force memcached servers to flood targets with a distributed denial of service (DDoS) attack.
OK, I Get It. APIs Are Risky. What Do I Do?
Inventory
To start, as always, you’ll need an inventory of your APIs. For some organizations, this is not as easy as it sounds. The large platforms that we mentioned earlier often depend on APIs to pull specific functions into their application, such as payment information processing, or linking to social media. The growing complexity of information systems, along with the accelerating rate of change, means that obtaining this inventory is not a trivial task. Maintaining the inventory over time can be even more difficult, because it is usually harder for people with other jobs to budget time for ongoing, routine maintenance tasks than it is to get together for a single discovery session. Nevertheless, it is absolutely essential to keep the inventory up to date, since APIs are quickly becoming the new nexus of business logic and application architecture.
As of June 2019, we know of approximately 22,000 published APIs. The majority of those are estimated to be private APIs, which means that access to them is restricted to internal developers or specific partners, as opposed to the public. Understanding which ones are which within your organization, and how each one contributes to your business operations is important for adding context to your inventory. This information allows you begin the process of assessing the risks that APIs might bring to your environment. The reason this is such a big deal is that all of the breaches we’ve seen so far have been attributable not to sophisticated zero-day exploits by genius hackers, but instead to failures to apply basic security principles to new operational needs.
There are two specific things we recommend for every API inventory, reflecting the role of APIs in contemporary systems: 1) Conduct perimeter scans. Perimeter scans are valuable particularly because they replicate the hacker’s eye view. 2) Perform in-depth discovery interviews with development and operations teams. This may save time and get you valuable information to supplement the results of internal scans. Find out what the de juris and the de facto states are, and prepare risk assessments for both.
API Authentication
By design, APIs execute commands. They should be considered root/admin interfaces and require strong authentication. F5’s State of Application Services 2019 found that 25% of the organizations surveyed didn’t deploy authentication for APIs at all. 38% reported that they did ”some of the time,” and 37% said ”most of the time.” Two things stand out about this to us. The first is that a full quarter of F5’s customer base is not controlling access to a component that offers a direct path right to the heart of some of their most valuable capital. The other is that even the leaders in this issue are still not controlling access all of the time. This is a prime example of risk models failing to keep up with a changing landscape.
There are different forms of API authentication; practitioners must consider the pros and cons of each type based on risk. Generally speaking, OAuth 2.0 is considered the best option for most REST APIs, but it really depends on the nature and design of the API, its intended uses, and the business model and threat model of the organization. (Note also that OAuth 2.0 authentication traffic must be encrypted to be effective.) There are also emerging frameworks for service-level authentication in modern architectures such as the SPIFFE framework, which offer a potential step forward in terms of managing authentication in complex environments. The real point here is that authentication of APIs is not optional given the trends and risk we’ve outlined above.
Furthermore, as in all authentication, credentials must be stored in a secure way. Whether your credentials take the form of user/password combinations (for either machines or human users) or API keys (which are simplified authentication strings that have specific uses), it is critical to treat them as sensitive information, because they really are the keys to the kingdom.
API Authorization
The other half of API access control is authorization, by which we essentially mean the permissions associated with any credential set. As with all credentials, API creds must be treated using the principle of least privilege. Role-based access control is the best way to do this for API accounts of all types. At a minimum, this should take the form of limiting the HTTP methods that specific roles can implement (DELETE being an obvious one to limit, but not the only one–again, let your own environment and business logic dictate this in a risk-based way). To go one better, define specific sequences of actions that correspond to the specific API use case, and limit the API to that sequence instead of simply specifying a list of permitted actions.
At no time should APIs be allowed to pass unsanitized or unvalidated input to the application. That is a sure recipe for an injection attack.
Log the API Connection
After implementing authentication and authorization controls, the next level of maturity is to implement monitoring on the API. As we mentioned in Episode 4, brute force attacks can easily go unnoticed; all the more so with the advent of clever, distributed, low-and-slow access attacks. As a result, you should log API connections regardless of their outcome and behavior, and review those logs, whether through humans, bots, or cloud services. Furthermore, given the number of APIs and connections across them, it’s best to also monitor the assets that the APIs serve to ensure their integrity and confidentiality.
Encrypt the API Connection
At the risk of sounding repetitive, APIs are like user interfaces for machine users. Their traffic still moves across the web like any other traffic. We increasingly encrypt all user traffic on the web—API traffic should be treated the same way. Encrypt those connections and validate the certificates like you would for any other service. That also takes care of the requirement to encrypt OAuth 2.0 authentication traffic, as noted above.
Look at API Security Tools
Consider looking at a proxy or a firewall that is “API aware” to inspect, validate, and throttle API requests. Some API security services can analyze the originating client and attempt to determine if a request is legitimate or malicious. They can also ensure that API requests stay where they’re supposed to stay, and do not escalate their privileges or exceed their reach into the app or data. A tool like this makes all of the aforementioned mitigation tasks easier. Many API security tools ingest OpenAPI/Swagger files, which will auto-configure the enforcement of the expected behavior.
Test Your API
APIs must be scoped in for scans, vulnerability assessments, and penetration tests. The point here is that the prevalence of APIs is matched only by their obscurity. Many organizations don’t even have a single person who is aware of all of the org’s APIs, and almost none of the orgs we’ve talked to have authentication on all of them. Testing is a part of any decent security program, and it applies here as well.
Given the difficulty of maintaining situational awareness, it is also a good idea to place a bug bounty on API vulnerabilities. Security researchers are constantly looking for things to report about, and Shodan has made it easy for researchers (and attackers) to discover your systems in detail. It is much, much cheaper to pay them quickly and quietly, patch your issues, and release a statement when applicable, than for them to go public—which could lead to bad press at best and a compromise at worst.
Wrap-Up
APIs are not new, but they are newly relevant for the way the Internet is growing and applications are evolving. As such, they do not so much introduce new risks as they reintroduce existing risks in forms that are more likely to be exploited, more impactful, and harder to recognize. At the same time, they are an unavoidable component in contemporary architectures, which means that avoiding or ignoring their issues is not an option for security teams. The Open Web Application Security Project (OWASP) has released one of their excellent Top 10 lists specifically for APIs. It is a good place to begin to explore these issues in greater detail.
Each chapter of the 2019 research series has featured well-understood risks, many of which have been around for decades, but that have taken on new forms as a result of changes in the tools and techniques that we use to provide web services. While this is in keeping with our long-running assertion that successful security operations are mostly about the thorough implementation of the basics across space, time, and diverse systems, this is not to say that we think that the changes are bad. When we talk about increased architectural complexity, this should be understood in light of the fact that applications also feature less complexity in the code itself. Other than for operating systems and similar heavy pieces of software, the days of millions of lines of code in a single piece of software are probably coming to an end. Instead, that complexity is re-appearing in architecture and infrastructure, as we assemble many small parts to create a complete whole. There are many advantages to these trends, but they also introduce added layers of abstraction in operations, which, in turn, raises issues for visibility and cascading failure modes. This is why the old issues are coming back in new forms. As security practitioners, we must not lament these changes, but adapt our practices to them with evidence, perspective, and a focus on enabling operations rather than hindering them.
Source link
lol
API Vulnerability Data The sensor network that our partner Lorkya maintains found only 0.1% of attack traffic was definitively looking for API vulnerabilities. However, this is probably better attributed to the limitations of the sensor network than any trends about API attacks. Loryka’s sensors primarily detect wide-ranging probes and reconnaissance campaigns where attackers are looking…