Gaining admin access to a Siemens cloud system

Eaton •

Originally published as an exclusive on The New Stack for Traceable ASPEN Labs

Over the past several years, when developers are tasked with building data-driven enterprise websites and applications, React and Angular JavaScript frameworks continue to be popular choices for accomplishing these goals. While these frameworks are powerful and provide built-in security features, it is still possible to make mistakes that could lead to security issues. The Traceable ASPEN team continues to discover a common anti-pattern in single page applications: the underlying server-side API does not properly authenticate users, or authentication is missing entirely. These APIs are often developed alongside the client-side application and developers often think security implemented client-side will be enough protection. We disclosed one such vulnerability with a fortune 500 company’s Angular application a few months ago and we are excited to unveil our latest discovery in a Siemens React web application.

Siemens AMA Cloud

Siemens develops and maintains a cloud system named AMA Cloud. AMA stands for “Asset Management Assurance”. The website is a React application, making it a prime target for API discovery and exploitation.

Disabling Microsoft SSO

In React or Angular applications that implement SSO, there are typically 2 ways developers design the initial loading of the application:

  1. A custom-designed login screen will be presented welcoming users. There will be a login button the user would click on and be redirected to the SSO provider.
  2. No login screen or other UI is loaded at all. Instead, the user is immediately redirected to the SSO provider.

The website uses method #2. Even though you are redirected to the Microsoft SSO page right away, there is a brief window where the entire React application is loaded. It is this window we took advantage of to view the source code of the application to see how it works. Since we are unable to log into a real Microsoft account, the login redirect needed to be disabled for the web app UI to even load. The only way to do this was to modify the client-side JavaScript code to comment out the redirect. Doing so stops the web app from redirecting to the Microsoft SSO page.

Faking a JWT

With the login redirect out of the way, the next step was to understand how the authentication and authorization worked beyond that point. We found that the login token gets stored in the browser’s session storage and the web app decodes the JWT to load the user information and, more importantly, the JWT’s expiration date. There is nothing wrong with this approach as long as the full JWT is sent with every API request so the server can verify the login is legitimate.

A common attack we will attempt is to create a “fake” JWT for the browser’s local/session storage and populate it with enough information to get the app to load without errors. This can be an easy way to determine whether the server-side API correctly checks for a valid token. We found a getUsers API endpoint that was unauthenticated.

This gave us all the information that we needed to fill in our fake token with real information. We looked for a user that had access to everything and created a JWT to that effect:

The signature was not important because it was not verified client-side. Even if it were, it would have been trivial to bypass. The next step was to put the token into session storage:

Admin access achieved

With the JWT in session storage and modified JavaScript applied, an attacker would be able to load into the website and gain full access. The reason the fake JWT worked is because the JWT wasn’t being sent to the API server at all – it was only used client-side. All the APIs were unauthenticated. However, it was still necessary for the information in the JWT to be accurate because the API used the user information in some requests:

Reporting to Siemens

The Traceable ASPEN team put together a report and sent it through Siemens’ vulnerability disclosure program. The timeline is as follows:

Siemens was extremely responsive to our vulnerability report. They promptly fixed the vulnerability by updating the client-side code to send the authorization token for every request, and updated the server-side API to require it. Their vulnerability resolution program is a testament to their commitment to security and privacy.

Lessons & takeaways

This was another example of missing/broken authentication – a common problem in the industry that continues to result in data breaches and damage to critical systems. When building your APIs, one of the first questions you should ask yourself is: do my APIs make use of the Authorization header? The first step is sending it to the server, but a sometimes-missed second step is making sure the API server validates the header and properly rejects clients that send a missing or invalid value. Server-side validation of the JWT signature is also vital to ensure that the user is who they say they are. While client-side validation can also be done, it is not recommended because the JavaScript can be modified to remove such validations.

Subscribe to new posts

Get an email notification every time something new is published.
📧