Issue 131: API vulnerabilities at John Deere, Springfox, JWT lab, AutoGraphQL

This week, we check out the recent API vulnerability in John Deere farming machinery, the best practices in using Springfox annotations for API security, a new JWT penetration testing lab, and AutoGraphQL  – a tool for GraphQL authorization testing.

Vulnerability: John Deere

John Deere is one of the leading manufacturers of expensive farming equipment, such as tractors and combine harvesters. Many of these are automated to the highest degree and cost millions of dollars.

Researchers found a few vulnerabilities in the APIs behind the web and mobile applications for the machinery. John Deere has since fixed the found vulnerabilities.

The first vulnerability allowed attackers to look up usernames. The researchers found that as they were creating the username in the John Deere Account Portal, the interface kept making API calls to check if the username existed. There seemed to be no authentication and no rate-limiting in place. A quick script iterating the names of Fortune 1000 companies found 192 company usernames in the system:

while IFS=, read -r COMPANY JUNK; do
    TRIMMED_COMPANY="$(tr -dc "[:alnum:]" <<< "${COMPANY}")"
    echo "${TRIMMED_COMPANY}"
    USERNAME="${TRIMMED_COMPANY}"
    RESPONSE="$(curl 'https:// myjohndeere. deere. com/wps/PA_myjd_live/struts/validateUserName' -H 'User-Agent: Mozilla/5.0 (X11;
Linux i686; rv:60.0) Gecko/20100101 Firefox/60.0' -H 'Accept: application/json, text/javascript, */*; q=0.01' -H 'Accept-Language: 
en-US,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded' -H 'X-Requested-With: XMLHttpRequest' -H 'Origin:
https:// myjohndeere. deere. com' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Sec-GPC: 1' -H 'Pragma: no-cache' -H 'Cache-Control: 
no-cache' --data-raw "userName=${USERNAME}")"
    echo "${USERNAME}"$'\t'"${RESPONSE}" >> results.tsv
done < Fortune1000.csv

The second vulnerability was in the APIs behind John Deere Operations Center. The researchers could easily enroll for a developer account and get access to the portal. They looked at the API call for adding new equipment to the operations center and found out that the API responded with a whopping 5,800-character-long JSON.

The JSON contained lots of information about the equipment, including the owner’s name, physical address, equipment GUID, terminal remote access availability, and so on. The information was returned for any equipment regardless of the owner (and, interestingly, even the manufacturer if a non-Deere VIN was provided).

This is effectively a combination of:

• OWASP API1:2019 — Broken object-level authorization (BOLA): Lack of authorization enforcement to ensure that only authorized users get access to their resources.
• OWASP API3:2019 — Excessive data exposure: Clearly, in this particular business scenario, all that sensitive and PII data was not even necessary, just leaking without any purpose.

It’s also worth noting that even with significant software and API use in their machines, at the time, John Deere seemed to be lacking a clearly defined process for reporting vulnerabilities and bugs in a safe and secure way, as attested by the complaints on the issue in our researchers’ report.

Lessons learned here:

• Authentication is not enough. You need to also implement authorization checks for any resource access in your APIs. Rate limiting and other protections against enumeration and scripted attacks rarely go amiss, either.
• Beware of your API responses. For any API, consider the actual use-case, the bare minimum of the information that you need from the API, and the risks of the data getting retrieved by malicious actors.
• If software, web services, or APIs play any significant part in your products — especially if data classified as PII or sensitive is involved — do set up and clearly document a process how bugs — especially security bugs — can be safely reported.

Best Practices: Springfox annotations and OpenAPI

Spring is a popular framework in the world of Java development, especially for micro-services and thus API development. Spring uses annotations to programmatically mark chains of dependencies and define the behavior of the Spring framework.

And, even better, Spring annotations can actually make your APIs a lot more secure. I.e., they can automate generating machine and human-readable API definitions in JSON from Spring projects:

• Springfox for generating API definitions that follow the OpenAPI Specification (OAS) v2
• Springdoc for generating API definitions that follow the OAS v3

These annotations not only document the APIs, thus enable testing their security and behavior and protecting them, they also enable some automated data validation from Spring. Thus, adding the annotations to your Spring projects is time well spent.

Isabelle Mauny and Edgar Silva from 42Crunch have published a two-part blog post on this scenario:

• Creating High-Quality OAS Definitions with Springfox – Part 1: Security Definitions
• Creating High-Quality OAS Definitions with Springfox – Part 2: Data Validation

If you work with Spring, definitely worth checking out.

Pentesting: JWT hacking challenges

JWT (JSON Web Token) vulnerabilities and attacks are a common topic in this newsletter. They are critical because JWT serves as the foundation for authentication in many modern OAuth and OpenID Connect APIs.

Ricardo J. Uviedo Garrido has created an open-source lab that you can use to see some of these vulnerabilities in action. The lab includes the following JWT signature attacks:

• none
• weak secret key
• key confusion
• key injection
• JWKS spoofing
• kid

Tools: AutoGraphQL

AutoGraphQL by Ron Chan makes it easier to test GraphQL APIs for authorization vulnerabilities. AutoGraphQL can detect both Broken Object-Level Authorization and Broken Function-Level Authorization, making it very useful as these are high on the OWASP API Security Top 10 list.

The process is quite straightforward:

1. Read the introspection file.
2. Pick the API calls that you want to test.
3. Set user accounts to be used in the tests.
4. Run the tool and check which calls succeeded and which failed, then see if these authorization tests were in line with what you expected.

Check out this video of the tool in action:

---

Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy

---