Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

IBM Spectrum Protect is a backup solution that provides data protection. It has a client-server architecture style with different types of nodes involved. The authentication protocol has a vulnerability in it though.

Here are the steps for the protocol:

1. The client generates session and validation tokens. This information is encrypted using the hardcoded AES key and sent to the server.
2. The server selects the password of the connecting user from the database and encrypts it using the same hardcoded key. In this step, the clients information is also decrypted using the encrypted password as the key.
3. The sever generates its own validation token. The server encrypts the clients validation token and its own token suing the decrypted session token.
4. The information above is sent back to the client where the client decrypts the validation tokens using the session token.
5. Once the token is known (from the decryption process), the validation token is sent back to the server.
6. The server validates the two tokens are the same. This is done in order to verify that the client actually knows the session token.

The authentication method above uses a challenge-response format in order to verify if the user has the proper secret. If they have the proper secret, then they can access the server. So, what if we could brute force the secret somehow?

Prior to the server sending back the the challenge, it encrypts the data using the session token. Because we know part of the ciphertext (validation token from client), we have a known ciphertext problem!

With the known ciphertext, the session token from the server side can be brute forced offline until we get the expected plaintext! This allows us to authenticate, even though we never knew the secrets.

Although this requires the brute forcing of a key, it can be used to find the password on the server. Considering this is JUST a password (and not an AES key), this seems doable after a fair amount of tries.

Besides the vulnerability itself, the situation for this is interesting. This is the old protocol, which has been deprecated for security reasons. However, this legacy authentication method is still enabled by default on newly created administrators. So, even though this is deprecated, it is still possible to use!

Overall, this is a fun vulnerability in the authentication flow of an application. The sending back of user data does not feel like a big deal until you realize that the password used to encrypt this data can be learned with offline brute forcing. Great find!