Predictable Transaction ID Possible Vulnerability Allows Unauthorized Termination of OCPP Sessions

[Tano-Coppoletta]

Checklist

• I checked other issues already, but found no answer/solution
• I checked the documentation and wiki, but found no answer/solution
• I am running the latest version and the issue still occurs
• I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0
Operating system  : Ubuntu 22.04.1
JDK               : openjdk version "11.0.20.1"
Database          : version 1.0.3

Docker Container Setup

Two Docker containers are set up to simulate two OCPP clients for testing purposes.

Issue Description

A possible security vulnerability was identified where unauthorized termination of transactions is possible due to predictable transaction Ids. The server issues a new transaction ID upon receiving an incomplete StartTransaction request and, due to the IDs being auto-incremented, an attacker can predict and use them to terminate other transactions.

Steps to Reproduce

1. From the first Docker container (Client 1), a transaction is started:

   [2,"1","StartTransaction", {
       "connectorId": 1,
       "idTag": "test",
       "meterStart": 20,
       "timestamp": "2023-09-03T12:34:56Z"
   }]

2. From the second Docker container (Client 2), a StartTransaction request with an empty idTag is sent to obtain a new transaction Id:

   [2, "1", "StartTransaction", {"idTag": ""}]

3. Client 2 then sends a StopTransaction request using the new transaction ID minus 1:

[2, "1","StopTransaction", {
  "meterStop": 1,
  "timestamp": "2023-11-06T15:54:23Z",
  "transactionId": [Retrieved Transaction ID - 1],
  "reason": "EVDisconnected",
  "transactionData": [...]
}]

4.The unauthorized termination of Client 1's transaction is confirmed via the web interface.

Expected behavior

The server should not issue a transaction ID for incomplete StartTransaction requests and should authenticate StopTransaction requests before processing.

Actual behavior

The server processes unauthorized StopTransaction requests using predicted transaction IDs.

[lategoodbye]

From my point of view does the StartTransaction from point 2 violates the OCPP 1.6 schema (fields connectorId, meterStart and timestamp are missing). I think for OCPP 1.6J this should generate a CallError with ErrorCode = OccurenceConstraintViolation. There is no point in processing such a message, because no charging station should send such a mess.

[Tano-Coppoletta]

I appreciate your insight regarding the schema violation for the StartTransaction message. However, it's important to consider scenarios where a charging station might be compromised. If an attacker gains physical access to a charging station, they could potentially send malformed or incomplete OCPP messages. Therefore, server-side validation is crucial to safeguard against such threats.

[lategoodbye]

@Tano-Coppoletta Maybe you got me wrong, i wanted to say that Steve (server side) should generate a CallError and prevent further processing of the transaction. So your concerns are valid from my point of view.

[Tano-Coppoletta]

Hello,

I'm reaching out for an update regarding this issue.

We are in the process of submitting Common Vulnerabilities and Exposures (CVEs) related to this matter. However, we can wait if you are in the process of fixing it.

Additionally, we intend to publish our findings in an academic paper.

Your prompt response and attention to this matter would be greatly appreciated as it will greatly inform our next steps.

Thank you and looking forward to your response.