We asked our technical lead Alex Walworth to sit down for a discussion on his recent work identifying security issues with our client’s legacy systems. If you have questions about the security of your legacy systems, feel free to contact us at us.info@pitss.com.

What legacy system security risks did you identify for our client?

In a recent engagement, a default service account necessary to authenticate a request to our services, which were built to expose data for a customer. As the data displayed was user-specific, our client had established a means of serializing the user-identifying parameter passed to all services to prevent people from passing anyone’s email address to the services and viewing data they should not be able to see otherwise.

This was accomplished by requesting the serial number from a different service by passing the actual user’s identifying information.

How did you identify the issue? Why was it an issue?

The risk of implementing this form of security is two-fold:

• A service account is not a recommended means of security as the user’s authentication does not dictate what level of authorization is allowed. This means that either all access levels are allowed, or another means of authorization must be established, which was the case in this scenario.
• The means in which the user-identifying value was serialized could be performed after the authentication was established from the front-end. This means that any user, should they discover the means of performing the serialization, could pass any employee’s email that they knew and receive the serialized representation and access any data that the new value allowed.

How did we resolve the issue?

These legacy system security risks were solved by ensuring that the service that exposed the serialization process was not consumable. The means of authorization should not be determined by the front-end’s request.

This was solved easily in most use cases by modifying the authentication process to no longer be based on a service account. This allows the authorization to be established completely in the back end and not manipulatable by someone hoping to seek unauthorized access.

What steps do you recommend for organizations who have insecure legacy systems?

One main recommendation to make when securing legacy applications, especially ones that have a means of authorization and authentication that is deprecated is to make the steps to allow modern means of authentication take place.

In the example I’ve described, this occurred due to an attempt to keep a legacy style of authentication alive and was unsuccessful. My advice is to bite the bullet and do the upfront work of modernizing your authentication and authorization architecture from the beginning.