API10:2019 Insufficient Logging & Monitoring
One of the challenges for bad actors, apart from finding an exploitable flaw, is to pass unnoticed not only during the research process but also during the exploitation phase. Insufficient logging and monitoring make it hard or even impossible to detect and mitigate suspicious activity or attacks targeting APIs.
What is the issue?
API is running and accessible, but the infrastructure is not under monitoring, nor produced logs are used to (early) detect and mitigate any suspicious activity. Sometimes monitoring and log management are in place, but either log entries do not include enough details, or logging is too noisy that malicious activity passes unnoticed.
How does it look like?
In the API2:2019 Broken User Authentication article, we've depicted a Credential Stuffing attack. Following that example, we'll now focus on what is logged by the API server. Below you'll find a failed login attempt HTTP request and response, as well as the API server-generated log.
The log entry doesn't say that much, just that a POST request was received on the "/users/login" endpoint, which the API server rejected with a "401 Unauthorized" status in 1.265ms. The entry does not include any information about the request's origin (IP address), API client (e.g. user agent), affected user account, or simply when it was created. During a Credential Stuffing attack, you should expect the API server to log hundreds, thousands, or even millions of lines like this one.
When log entries are written to local files and no other process exists to ingest them to a centralized location, then the attack is likely to pass unnoticed. Even if there's such a process in place using, for example, a Security Information and Event Management (SIEM) solution, there's not that much that can be done to mitigate the attack: for example, there's no IP to ban or information about whether the attack is targeting a specific user account or random user IDs. Moreover, in the advent of a successful attack, API server logs won't be helpful to understand the extent of the attack and how many user accounts were exposed.
Where have we seen this issue lately?
When hacking APIs we don't gain access to log files that often, which does not allow us to say about the logging strategy or relevancy of the logged details. But, our activity is not blocked that often nor are the issues fixed before security advisories are received: that makes us always wonder whether our activities passed unnoticed.
Conclusion
According to the 2021 IBM Security X-Force Cloud Threat Landscape Report "Enterprises are still learning how to monitor for and detect threats in the cloud.". According to several breach studies, this means over 200 days to detect a breach, which typically happens by external parties rather than internal processes or monitoring.
As a golden rule, logs should use a format suited to be consumed by a log management solution and include enough detail to identify the malicious actor. With that in mind, having a centralized log management solution such as a SIEM is mandatory: configuring custom dashboards and alerts to detect and respond to suspicious activities earlier is a common feature among them.
A final word about logs: they should be handled as sensitive data both at rest and in transit.