Tales From the Road: How Secure is Your API?

How We Were Able to Alter API Settings that Control Energy Production

During a recent security assessment of an Application Programming Interface (API) that dynamically manages the energy resources for a large energy utility and allows external client devices to communicate with end devices that sit behind the API server, DirectDefense was able to gain access to the API and modify device settings that control energy production. Had this been a malicious actor, the results could have been devastating!

For businesses like our client who are regularly incorporating third parties into their network and using the IEEE 2030.5 specification to communicate across energy devices, API security becomes a critically important issue not to be taken lightly. For utilities like this one, API breaches can result in serious consequences.

Read on to learn how we were able to breach our client’s energy resource API and get our tips for securing your API.

The API Assessment

Our consultants used a comprehensive set of tools, custom scripts, and manual techniques to thoroughly identify possible threats to the application. Like a traditional application penetration test, all identified threats were tested and validated to evaluate the depth of compromise and risk of exposure. 

For this assessment, our consultants conducted:

  • API information gathering
  • Manual validation testing of identified threats
  • Controlled penetration testing of the API

Step 1: Gaining access to the end device

DirectDefense consultants first needed to gain access to the end device through the proper security certificate in order to interact with the device and send requests. Our consultants observed that the API was not sufficiently validating input data sent in commands to end devices, meaning invalid inputs could be sent to the API to unsafely modify end device settings.

Pro tip: Any external data parsed by the API should be considered untrusted and validated for safety, even if it’s coming from an authorized source. Although requests must be authorized with a valid certificate, the API’s security model should account for scenarios in which an authorized client device is controlled by a malicious actor or in cases where a valid client certificate is stolen.          

Step 2: Changing device settings

Once it became clear that the internal logic on the device did not prevent our consultants from sending malicious requests and altering commands after the connection was established, our consultants got to work to see just what type of damage could be done.

Because the API controls a Distributed Energy Resource (DER), our consultants were able to modify, and even remove, wattage and current controls on the device itself. In addition to potentially causing the device to function unsafely, the removal of these settings violates requirements of the IEEE 2030.5 specifications that the energy utility is required to adhere to.

Reality check: If a real-life malicious actor gained the same access, there could be more serious repercussions to energy production, including removing alert mechanisms so devices can behave unsafely, or creating bottlenecks in the power flow.

Step 3: Securing the API

Strong access controls on the API restrict this attack to attackers holding valid client certificates authorized to communicate with the head end server, but because the API doesn’t have a robust security model for clients with access to a valid certificate, a savvy attacker with a device authorized to the API could use the device’s certificate to send malicious data to the API. This traffic should be considered a security risk and incoming traffic should be validated to prevent unsafe changes to the environment. 

The fix: Care should be taken to validate all incoming API traffic so that unsafe changes to the environment are prevented. Specifically:

  • End device power limiter settings should either be immutable or only allowed within a certain range of safe values.
  • Limit the amount of internal information exposed to clients whenever possible.
  • Make error responses as generic as possible in production environments. Attackers often use detailed error messages to more accurately profile systems.

The Bottom Line:

Communication to the API server and its end devices is performed according to the IEEE 2030.5 specification, which defines the rules and parameters for a communication channel from one device to another location. 

The IEEE specification is stringent about only allowing connections using valid certificates, which is a great security feature, but only conducting a security check of your certificates against the spec doesn’t account for manipulation of the device itself.

The moment a well-positioned attacker has physical access to a device, they can pull the certificate information out of it. Just because the input coming in has the correct certificate doesn’t mean it’s safe.  

Contact Us Today!

Want to continue to improve your cybersecurity maturity? Let our team of security experts review your API for vulnerabilities that could negatively affect your overall security posture. Get started today or call us at 1 888 720 4633.