APIsecurity.io - APISecurity.io Newsletter: Issue 157

JFrog recently published a report on a potential vulnerability in Prometheus, a popular open-source event monitoring and alerting solution. Attackers could parse unsecured endpoints to retrieve sensitive data.

Previously, the metrics had not been considered sensitive at all, but in version 2.24.0 support for TLS and basic authentication were added. Unfortunately, because this is a relatively new feature (v2.24.0 was released in January 2021) and many installations in the public domain still use an older version, JFrog concludes that large-scale data exfiltration is still currently possible.

The authors describe some elementary intelligence gathering techniques using Shodan and ZoomEye to ingest data from over 27 000 hosts. Their findings included:

• Sensitive operational information like usernames and passwords were exposed.
• 15.6% of endpoints had exposed and unsecured administration interfaces.

The key takeaways here are:

• If you are concerned with unintended information exposure, enable both basic authentication and TLS in your Prometheus setup.
• Be wary of default settings in any system, their security level might not be what you want and might have unintended consequences.

The old adage of “you can’t improve what you can’t measure” applies equally well to security: you can’t secure what you don’t know about. API security is no different beast here.

API discovery is increasingly under the spotlight because it enables organizations to understand the extent of their risk exposure stemming from their API estate. In complex organizations, the vast variety of internal and external APIs, programming language and framework choices, and hosting or cloud environments can make this — or even estimating your attack surface — a challenging undertaking. The most likely result is a wild “finger in the air” estimate.

Luckily, there is a free API attack surface calculator to get you started. It allows you to get an (albeit very basic) estimate of your API attack surface based on a few basic, easily identified parameters. While not being a discovery tool proper, undertaking such an estimate should be illuminating in its own right: what are the knowns, what are the unknowns, where more information is required, where should an organization start with their API security initiative.

The increased adoption of the OpenAPI Specification (OAS) standard over the last decade has resulted in a vast number of OpenAPI definition files in public repositories.

In a fascinating report, courtesy of Nordic APIs, the Australian security company Assetnote scanned over 200 000 publicly available OpenAPI files, with the goal of discovering underlying trends and patterns in them.

In summary, some of the key findings here include:

• 79% of API definitions are valid OpenAPI definitions — so conforming to the standard — which bodes well for the continued adoption of the OAS in large.
• APIs are increasingly complex: on average, each API had 37 paths and 51 endpoints.
• Understandably, GET is the most frequently used method, followed by POST.
• Most APIs tend to favor basic authentication, followed by API key methods. Somewhat worryingly, the third most popular option is having no security at all!

The continued interest in API security is being reflected in the availability of new, quality training offerings.

This week, we have news of an API security awareness event, featuring Isabelle Mauny (field CTO of 42Crunch) in a conversation with Tanya Janca (aka. @shehackspurple) as part of Tanya’s new We Hack Purple academy and community.

Also of interest to API security practitioners will be the upcoming mini-course from the We Hack Purple community. I look forward to featuring the course in this newsletter once it is available.