Issue 145: APIs and electric car charging stations, The Nuts and Bolts of OAuth 2.0 🔩

Researchers at Pen Test Partners looked into the security of several popular smart charging stations for electric vehicles.

The chargers are typically controlled through a cloud platform and a mobile app, and hence have APIs that can be accessed remotely and can be vulnerable.

The potential exploits that Pen Test Partners found were threefold:

• Attackers might be able to retrieve users’ personal details.
• Attackers might be able to control the charging process for an individual car.
• Attackers might be able to mass-control all charging stations in a country or region and use them to cause massive spikes of power consumption, affecting the national power grid.

Here are some API vulnerabilities that they found:

• Project EV / ATESS / Shenzen Growatt (the largest platform that they looked at with over 2.9 million devices):
  • The API call for login (POST on /ocpp/user) did not actually need a password and would let anyone in if they simply supplied the username or the serial number of the charger!
  • The serial numbers were predictable and easy to enumerate (TTD0xxxxx).
  • Starting or stopping a charger was a matter of sending the corresponding lock/unlock command to the /ocpp/api endpoint:

    POST /ocpp/api/ HTTP/1.1
    Content-Type: application/json;charset=UTF-8
    Content-Length: 64
    User-Agent: Dalvik/2.1.0 (Linux; U; Android 9; Redmi 8A MIUI/V11.0.3.0.PCPMIXM)
    Host: charge[.]growatt[.]com
    Connection: close
    Accept-Encoding: gzip, deflate
    
    {"chargeId":"TTD0xxxxx","connectorId":1,"lan":1,"cmd":"lock"}

• Wallbox had Broken Object-Level Authorization (BOLA/IDOR) issues, meaning that the attacker could log in with their account but then use device IDs belonging to other customers to take over their chargers:
  
• EVBox had an API flaw that allowed unprivileged accounts to be escalated as administrators through what seems to have been a mass assignment vulnerability. In a profile update call, a user could add additional roles (possible values discoverable through error messages) as the roles array, and the backend just applied the requested change. By adding the tenant admin role to their user, attackers could take over  all charging stations in that tenant:

  PATCH /api/users/profiles/00uascl0k2XXZXT8w416 HTTP/1.1
  Host: api[.]everon[.]io
  Accept: application/json, text/plain, */*
  
  {"profile":{"firstName":"egw",
  "roles":["ADMIN","ACCOUNT_OWNER", "tenantadmin"]
  }}

• Chargepoint, a charging infrastructure provider with about 150,000 stations globally, had a GraphQL endpoint that allowed introspection, thus exposing customer database details. The researchers didn’t retrieve or manipulate any data as they assumed this was a production system with real customer information.
  

All vendors have since fixed the vulnerabilities, but the magnitude of what could potentially have been achieved through them is quite chilling here.

Lessons learned:

• In the world of the Internet of Things (IoT), API security — or the lack of it — can have significant privacy, personal, and even national security consequences.
• Authentication, authorization, and data validation are all extremely important and serve as the foundation of API security.
• If using GraphQL, learn more about its security and don’t just go with the defaults.

Learn OAuth from one of its creators! Aaron Parecki has released his “The Nuts and Bolts of OAuth 2.0” class on Udemy that covers:

• OAuth 2.0
• OpenID
• PKCE
• Deprecated flows
• JSON web tokens (JWTs)
• API gateways
• Scopes

No programming knowledge is needed. Here’s a 5-minute intro video:

Gartner Hype Cycles offer nice visual representations of where the technologies are in terms of their hype, maturity, and adoption.

Mark O’Neill and John Santoro have just released their “Hype Cycle for APIs and Business Ecosystems, 2021” report. As the chart below shows, API security testing is sharply on the rise (as are Graph APIs), API threat protection is still near the top but further along the maturity route.

See the full report (behind a paywall) for more details on the technologies mentioned.

A huge number of APIs these days are APIs exposed by microservice-based applications. This means that the APIs exposed by an app are implemented as microservices that receive your call and likely make their own API calls to other, more back-end microservices in the system.

For example, a call to api/v1/user?id=1337 might mean that this microservice is making its call to some_internal_domain/users/1337.

That backend likely blindly trusts the frontend microservice, and if there is no data validation in place, an attacker may be able to get to other parts of the system by manipulating the parameters in the API call. For example, calling api/v1/user?id=1337/../../ might get translated to some_internal_domain/users/1337/../../ and thus normalized to some_internal_domain/, getting to the root of the backend.

Watch this recording of a talk by Jasmin Landry at a recent OWASP event in which he covers the traversal attacks that can come out of microservices architecture. He discusses various variants of potentially dangerous API inputs (query parameters, path parameters, JSON payloads), as well as his real-life experience in finding and reporting such vulnerabilities:

Lessons learned from this one:

• Zero trust approach and diligent data validation are really important. Define and enforce all your API inputs (parameters and payloads) as well as outputs in all your API definitions.
• Validate and enforce all allowed paths and operations.