A web service shalt not divulge password hashes

Salting

In a previous security assessment, we were able to detect and extract the login userids and the associated password hashes for all users in an intranet web service.

These password hashes were not displayed in the web asset but were detected when inspecting the data through an intermediate proxy. 

So what is a password hash?

A representation of the password, which had been sent through a one-way mathematical function and is very difficult to reverse. This representation is saved and compared to, every time you login to the web asset with your password.

Password Hash

Although this weakness was not directly exploitable during the security assessment, this was still written up in the final report because:

  1. The password hashes could potentially be cracked using Crackstation or hashcat or even using FPGAs (for high priority targets).
  • Users could potentially be reusing the same password on other internal web or mobile applications in the company, leading to laterally movement through the company’s cyber assets after cracking the hashes.
  • There was no out-of-band authentication channel (ie SMS OTP or TOTP) used to further notify the end user if there was an authorised/unauthorised login.

This weakness suggests root causes of:

  • Writing insecure code,
  • Insufficient or inadequate unit or integration testing.

Although I had a rough idea how this problem came about during the assessment, I could only replicate this data leakage weakness after clearing couple security assessments later. I thought to share this weakness here and also how to fix this (which i’ll provide two solutions and contrast these two solutions with factors relating to testing and development in a later article.)

As a picture speaks a thousand words, below is a logical diagram showing the placement of the interception proxy, in relation to the web client and web service. We were basically sitting in the middle, inspecting the data streams from the web service to the web client and vice versa.

After placing the interception proxy, I was able to detect the password hashes getting returned from the web service, but were not displayed in the web client.

On the left panel, this shows the request made by the web client. On the right panel, this shows the data returned by the web service. The highlighted password hash was not displayed in the web client.

We were hoping to see only the username, email address and the role (Below).

In the next article, we will cover how to rectify this hash leakage via two methods. Each method will have its own requirements and challenges in terms of functional testing and securing the web service.

Say Hong TAN

CISA, CRT, CA (Singapore)
Founder and Director
Dynafense Cybersecurity

Leave a Reply

Your email address will not be published. Required fields are marked *