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!

SSO providers are the main authentication scheme to login to platforms, such as Google. Besides this, there are many corporate products, such as Cisco Identity Services Engine, Oracle Access Manager (OAM) and VMWare Workshop One Access. This post is aimed at finding a vulnerability in the SSO provider VMWare Workshop One Access.

To start with, there is a minimal attack surface for unauthenticated users; as a result, an auth bypass is required. The API generateActivationToken will generate an activation code for an existing OAuth2 client. Calling activate will return the client ID and client secret for this user.

Instead of finding a bad code path, they abused functionality in the app itself! By calling generateActivationToken to get the code and sending this code to activate for a default client in the system, we can now act as a application calling the provider. This gives us much more attack surface to work with.

The second vulnerability is a Java Database Connectivity (JDBC) Injection vulnerability. The function dbCheck accepts a JDBC URI in order to make a database connection remotely. However, this is a known vulnerable sink that can be taken to code execution.

One method is sending back an arbitrarily serialized object that will be deserialized into any object we want. Using the CommonsBeanutils1 gadget (found from ysoserial tool), a shell can easily be gained. A second way is abusing the local gadget socketFactory. By instantiating this object, an attacker can control trigger the execution of a constructor defined in an arbitrary Java class with a controlled string argument.

Is code execution enough? Nope! The author wanted to escalate the privileges on the box to become root. While reviewing the permissions of the horizon user on the box via sudo -l, they reviewed the scripts that could be run as root. First, the script publishCaCert.hzn will copy a file into a specified location then make it read/writable by the executor of the script. By doing this, sensitive files can be leaked.

The script gatherConfig.hzn will take a DEBUG file and change the permissions of this to be in the TOMCAT user/group. Using this script, we can specify a symbolic link called debugConfig.txt to a root owned file to change the permissions. To get persist access via either of these methods, the script certproxyService.sh can be set to modifiable then run as root.

Overall, really awesome post on finding vulnerabilities in the logic of an application and code execution bugs via non-command injection/memory corruption fashion. The post is extremely detailed with many extra routes on top of everything else.