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!

Apache Dubbo is a Java based remote procedure call (RPC) framework. Dubbo can use a variety of protocols but defaults to the Dubbo Binary Protocol. There are a few main components:

• The Registry is responsible for the registration and search of services.
• Provider registers services to the Registry, while reporting real time info.
• Consumer gets a list of services from Registry. Then, can call the Provider directly.
• Monitor is used to view what is going on in the instance.

The author LOVES CodeQL for finding potential attack surfaces. While others use it for variant analysis, the other uses it for quickly learning about and maneuvering through the source code. In particular, they wanted to know about the specific inputs of the program.

From viewing the inputs, the hacker noticed a few potential ways to hit Hessian deserialization options, which were responsible for previous CVEs. This was done by forcing the code down unexpected paths. This was mainly found with CodeQL.

While decoding the RPC calls, there is a supposed opt-in only allowlist for specific deserialization types. However, because the deserialization type can be specified in the RPC call, we can specify any type we want. This results in a bypass of the opt-in only operation and leads to an insecure deserialization bug.

Moving away from the RPC calls, the author started to look for other potential vulnerable code sinks, which CodeQL has a good collection of. From this, they found a few potential calls that deserialize YAML. From the sink, they did a reverse search to where these inputs came from. By accessing a specific registry, we can inject malicious YAML to get code execution with no auth.

Customers can specify routes for scripts which are then executed on the host system. An attacker, with any scripting language, can create a new route that will be consumed by all users. This just feels like a vulnerability by design!

When the verifier and the user are different, bugs are bound to occur. When trying to check if the serialization is safe or not, a function is called that attempts to verify that the serialization type exists via the path. However, as an oversight, there is no error being triggered on this code!

When attempting to do the actual deserizliation, a different function is used though: lookupService(path). This will look up the service by path while the later does it by version AND path. This desync allows the verification to not find anything but the actual deserialization to successfully retrieve the object.

Overall, this is a large collection of awesome vulnerabilities. CodeQL is a great tool to have in the tool belt to making auditing much easier and learning about the flow of the application. This is a great post on the power of CodeQL in complicated code bases.