Open Systems, Open Threats
API Security Series Part 1

In recent years, many security point products have hit the market. Many of these singular solutions have already been absorbed through mergers and acquisitions, leaving consumers and manufacturers with an integration problem. An optimal solution integrates different security tools to share information and provide holistic protection. This is why application programming interfaces (APIs) have been developed and are, in theory, maintained. Anyone who has worked with an API in the past understands the challenges. Many APIs are limited in functionality, and security can be an afterthought by developers. As APIs are openly published and accessible to the Internet, it’s easy for bad actors to exploit both open API specifications and open endpoints. As an integration engineer needs that one missing API function, so does the security engineer cringe and demand API protection.

In this API Security Series, we will review how to use these interfaces, exploit them, and prevent an organization’s name from appearing on the news.

What Is an API?

Applications and IT systems started configuring through a command-line interface (CLI). A well-skilled IT or systems administrator would connect to a console and use the CLI to modify configurations. Over time, systems became simpler to manage through a web interface (HTTP) or graphical user interface (GUI). In addition to configuration, leveraging HTTP to manage and share information became a standardized way for systems to intercommunicate because we can create, read, update, and delete through HTTP methods. If we consider how to leverage APIs with security tools, certain information or signals discovered from one system could allow another system to perform an automated action. For example, a threat detected on an endpoint security product can use APIs to share that information with a firewall to automatically block malicious activity at the perimeter. You can see the rise in popularity because of how valuable APIs have become for system provisioning, configuration, management, and operations.

This external extensibility is usually documented with examples provided on the open Internet for all to use. However, how about the security here? Are we securing this connection via HTTPS? Are we authenticating the user and checking authorization for their role to use certain functions, with others restricted? What if there is a bug that permits an exploit?

Why Is API Security Important?

APIs are in our everyday lives. If you dabble with home automation, you have access to a controller that uses APIs. If you monitor your door locks, home thermostat, or security cameras remotely, you are using APIs. If you stream videos on your home entertainment system, you are also using an API. This technology is everywhere. Would you like someone unauthorized to spy on your security cameras or control your thermostat? Those are good reasons to care about API security or preventing unauthorized access and exploitation.

Let’s look at two examples in the news of why executives should be demanding security on their publication of APIs: the 2021 LinkedIn breach and the Log4Shell vulnerability.

The 2021 LinkedIn breach resulted in the data associated with 92 percent of users being exposed, harvested, and offered for sale on the dark web¹. The exposed public API lacked authentication, and bad actors now had the available data, including professionals’ email addresses and phone numbers worldwide. Such a treasure trove of contact details is ripe for abuse with advanced phishing attacks. The data was not available in one location like an Amazon AWS S3 bucket archive; still, a crafty developer could programmatically harvest details and build the database offered for sale on the dark web over some time.

API security was also to blame for the Log4Shell vulnerability. The Log4j logging framework contained a bug allowing the insertion of arbitrary strings into logs. The API not only accepted unauthenticated requests, but it also didn’t sanitize the posted data. Since the Log4j logging framework also didn’t sanitize the data, bad actors could establish connections between a compromised application and their servers. This allowed for deploying advanced persistent threats (APTs) and system compromise.

Given these examples of widely popularized instances of API compromise, the attack surface for bad actors is wide and open. There should be an imperative drive to secure these communication systems, primarily if the business relies on APIs. Financial, retail, transportation, and utilities rely heavily on either communication with third parties or lightweight communications via small personal devices within the field. Compromise could be catastrophic both for service delivery and for an organization’s reputation.

Nexum Can Help with Your Open Systems

Nexum is well-positioned to deliver API security solutions. Our engineers have consistently worked to provide integrations involving APIs across various product lines and understand how these communications work. Let us help you bolster your organization’s API security by layering in encryption for increased privacy. We can prevent unauthorized access by leveraging proper authentication methods. Nexum can assess your applications and systems for vulnerabilities. Lastly, we can help monitor traffic to detect active exploit attempts, API anomalies, and misuse. Use our Talk with an Expert form to get in touch with us.

¹ https://www.forbes.com/sites/quickerbettertech/2021/07/05/a-linkedin-breach-exposes-92-of-usersand-other-small-business-tech-news