How 1 Exposed Honeywell API Gave us Control Over an Internal Engineering System

Developers are increasingly turning to APIs as a mechanism to expose and consume data for their web applications. APIs enable users to rapidly develop their web applications while supporting many different user-agents, but properly implementing access control across all workflows can be challenging. This is especially true for large enterprise APIs that are subject to frequent updates and expansion. In the race to launch new products, and with limited developer resources, it can be challenging to truly prioritize security.

The time for API security is now. These simple API security problems are occurring in some of the world’s largest organizations. If your organization develops APIs, there is always a chance of a security flaw existing now or in the future. These problems are a key focus of our work here at Traceable and our goal is to detect these security flaws before they lead to data breaches or damage. Traceable ASPEN has discovered another case where just one insecure API endpoint was enough to take control over an entire application: Honeywell’s BEDQ system.

Honeywell BEDQ

Honeywell has a lot of subdomains and we eventually stumbled upon the BEDQ website: https://uopbedq.honeywell.com/. BEDQ is an internal system used by Honeywell employees and partners to submit engineering project proposals. It stands for “Basic Engineering Design Questionnaire”. It is used by companies all over the world to submit information about their projects to Honeywell. It is particularly popular in the oil & gas industry.

The BEDQ website requires a Honeywell ID to log in. By going to a different Honeywell website, we could register one and then use the login here. Honeywell IDs can be registered by anyone and the BEDQ login page was the same for internal users and consumers. In cases like this, websites may not correctly differentiate between an internal employee and a customer who just registered to access a specific website. This is similar to Mercedes-Benz where the employee/corporate login system is the same one that external independent service providers use.

The users API

After logging into BEDQ, we were quickly shown a “401: Unauthorized” page. This was not surprising, and it was good to see that Honeywell had access controls in place for their internal websites. While we could not progress past this page, we could view the source code of the website. It is an Angular application and we dug into the code to see if there were any interesting APIs that might be exploitable. While most of the APIs were properly secured, there was one critical oversight: the users API did not require authentication. In other words, a simple HTTP GET request to the “/api/users/” endpoint would return a list of all users registered in the system:

By exploring further we were able to chain this initial vulnerability with another. This is important when exploring the impact of security vulnerabilities, as attackers will always seek to pivot within a system or escalate their privileges. While exploring the “/api/users/” API we noticed two interesting facts:

1. There was an old/unused test user.
2. The API allowed a regular user to make a PUT request to update users other than their own. This is something that usually requires administrator privileges.

Putting these two findings together, we were able to update our user as an internal user with super administrator privileges.

Internal super admin access achieved

With the user update done, the moment of truth was at hand: logging in again and seeing if we were granted access. Since our Honeywell ID’s email address was now in the BEDQ system, we believed the login would work since this is now a match. Our theory was correct - the login succeeded, and we were granted complete control over the entire system. This means we had full access to the projects of every company and all the sensitive information inside. We decided to stop here and quickly report our findings to Honeywell.

Reporting to Honeywell

The Traceable ASPEN team reported to Honeywell’s vulnerability disclosure program. We also made sure to tell them about the changes to the test user so that they could restore it to its original state. The timeline is as follows:

• August 18, 2023: Report sent.
• August 24, 2023: Follow-up sent asking if they received the report. They responded same-day confirming they did.
• September 11, 2023: We requested an update.
• September 15, 2023: Honeywell confirms the vulnerability is resolved and asks for hall-of-fame credit information, which we provide.

Honeywell’s prompt response to our vulnerability report highlights their commitment to customer security. We appreciate their partnership in helping improve the security of their BEDQ application.

Lessons & takeaways

This Vulnerability was caused by chaining two very common API vulnerabilities:

1: Broken Authentication is one of the most common API vulnerabilities that we come across. In this instance, even though nearly all APIs were authenticated and had access controls, it only took one unauthenticated Users API to bypass the security of the entire platform.

2: Broken Function Level Authorization is an API vulnerability caused by inadequate authorization controls. A common scenario is when a function that should be limited to a privileged user is made available to a non-privileged user. In this application, the HTTP PUT method on the users API should be only available to an admin user. 

Recommendations

• Depending on the application stack, it is generally recommended to have a single gateway or reverse proxy to implement authentication and authorization. This ensures that over time, as new APIs are developed or existing ones are modified, they all continue to provide the standard access controls.
• APIs and Users should be explicitly mapped to user roles and if a user accesses an API that requires a more privileged role, it should be blocked by a 403 - Forbidden error.
• Interactive Application Security Testing (IAST) is a good mechanism to test APIs and find such vulnerabilities earlier in the SDLC before the application is deployed in the production. For example, a relevant test case would be to mutate HTTP requests and remove request headers one or multiple at a time to test authorization controls.

How Traceable can help

Traceable's mission is to secure the world's APIs. Traceable Sonar offers advanced external attack surface discovery, so you know what's public, be it leaked credentials, misconfigurations or sensitive data. If you'd like to find out more, request a demo.