A Look Into API Security

There are new stories every week about this company or that being hacked. Many of these stories happen because of leaky API’s. Large RMM providers like Kaseya and ConnectWise are being targeted repeatedly for exploits.

What Is An API?

An API is an Application Programming Interface. API’s are used to extend and expand the functions of a product and to allow them to interact with other products. There are both public and private API’s which may be limited or wide open.

API’s can be layered in order to work with multiple platforms or in order to combine data sources. They may be chained in an ecosystem even. Almost any largely successful technical platform is going to have an API of some kind somewhere. You may not be able to access it, but someone can.

Common Exploits

Leaky API’s have already been mentioned, but not really explained. A leaky API is an API which reveals data it is not supposed to. A legitimate call to this API may result in providing information which is outside the normal scope of the user or product which can be used to further escalate access somewhere else or to glean more information about the target.

Privilege escalation is a common tactic on operating systems as well as API’s (like in the following). Oversight on filters or access levels of certain API’s can lead to exploitation. If an API isn’t locked down, a malicious actor may be able to perform tasks that their user couldn’t from the website or program itself. This can even happen without any account level exploit.

Deprecated Platforms and API’s

Most products will maintain some level of backwards compatibility. This can work as much for you as against you with certain API’s. A deprecated API may keep other abandoned services running, but may also introduce an entire suite of new exploits to your infrastructure or product.

Old products you used may have API access to an account which can be exploited. These are all things to consider when it comes to API security. Most people remember to disable a given account when an employee leaves, but how many remember to shutdown the API access a test account has? This kind of oversight is far more common than you think.

API’s in API’s

Deprecated platforms and API’s get even more convoluted when you mix API’s with other API’s. Some API’s allow you to call other API’s in order to combine or otherwise collate data. There are countless products which exist just to be the intermediary glue between various API’s which then offers its own API to make things even easier.

Layering API’s makes life a lot easier and reduces development costs depending on the platform, but also opens you up to oversights by the developers and maintainers of a given API. You may follow best practices, but what about the lone developer hosting an API soup which is completely proprietary that you rely on? All of your security amounts to nothing if they have the keys to the kingdom.

Plugging the Leak

Different API’s have different features and different weaknesses. One thing which works no matter what is removing unnecessary accounts and access from an API. If a given user account isn’t set up as an API user, why would you give it API access? If an API account only needs read only access, why give it full access to an account?

Turning on Two Factor Authentication (2FA) for users can help as well. An API account can’t really use most 2FA solutions, but a user which can make a new API user can. Block accounts which do not need access and make sure that any admins are locked down. Don’t give API access to admins and vice versa.

IP whitelisting can help if you know a API requests will only come from a specific network or specific networks. Rate limiting certain ports or, even better, accounts can be another great way to prevent API abuse. You may not be able to lock everything down, but you can at least buy enough time to hopefully notice an intrusion before it gets out of control.

The Weakest Link

API security feels more and more like the weakest link in a lot of products. Security is often an oversight for API development. The average API is written to facilitate ease of access by other products, so it is often overlooked for security purposes.

Security for your product or organization is only going to be as good as the weakest link in the entire stack. If you can’t get rid of the weakest link, at least move it out of a structural role in your process. Reducing what an attack can accomplish can be as valuable as preventing an exploit in some cases.

If an API has too many holes or opens up too many doors, it may be prudent to move away from it entirely. If you can’t do without that API, it may be worth reconsidering the entire project. A mediocre product which isn’t a backdoor is going to be better than a great product you can’t really trust. The best steel door means a whole lot of nothing if the windows are left open.

Further Considerations

API’s are being leveraged more and more for attacks and are often overlooked for security. They may not be your highest priority, but they should definitely be included in security audits and security hardening efforts. Obsolete API’s and exploitable API components should be removed wholesale where possible.

Fileless malware has gotten more and more common. An API which allows running arbitrary code can be leveraged for this sort of attack and already has been. This isn’t just a proof of concept, this is active in the wild. You can’t just secure yourself only, you need to be proactive in preventing API exploits.

Look at how a given vendor responds to an exploit or attack. If they hesitate too long, how proactive do you think they are for security? How quickly do they report exploits and known issues? How quickly do they begin working on a fix? What major CVE’s are associated with their API? These are all essential questions for protecting yourself.

Conclusion

API’s provide features and extensibility to products, but this may come with at the cost of security. Be aware of what harm allowing a certain API access can really do. Clear out both old API’s and unnecessary users and scope your access both from the API and your own network as much as possible to mitigate threats.

Reduce your attack surface. API security is a ticking time bomb with some platforms, but can be reasonably navigated on others. Knowing the landscape and reacting accordingly will protect you. A few minutes of research and preparation can save you weeks of pain. API exploits aren’t going anywhere except more mainstream.

Image by Free-Photos from Pixabay