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!

Accellion has a large collection of products that are meant to secure the ecosystem against outside attackers, such as encrypted email, secure file sharing and many other features. Kiteworks is a Content Fire firewall product.

The application wrote its own query builder library for SQL. However, there is no safe or standard way for protecting ORDER BY or LIMIT constraints. As a result, there are two SQL injections because of this. With the ability to stack queries on top of each other in the application, this vulnerability allows you to call UPDATE or exfiltrate arbitrary data.

Once the UPDATE was used to change or create a user with Admin privileges, this is enough to compromise the application. However, the author wanted to go from user to shell!

The product allows several SMS backends but also has a generic option that allows arbitrary HTTP requests to be sent from the Kiteworks host. Additionally, this had a test method to see if the SMS service was working properly. The message could be sent through the API and was sent to the phone number specified. The generic, data sent back and test just scream exploitable SSRF!

Using the SSRF, JWT tokens could be requested from the internal web server. Additionally, the backend has Apache Solr search engine. It is a known misconfiguration to have remote streaming enabled, which allows for an arbitrary file read from the operating system. Boom!

Using the arbitrary file read allows us to steal the HMAC key for the admin to make intra-cluster calls. With becomes particularly bad because an attacker who can obtain a valid JWT and the key material to HMAC can simply call into an endpoint like /dbapi/cli_exec/execute via the front-end webserver exposed to the internet, and have arbitrary commands run via the shell.

The user has the uid=500 or non-root permissions. There is a script that attempts to protect against root level access of particular binaries and scripts, which does an insane amount of validation on it. However, after patiently reading through the operating system, the author of the article noticed a permissions issue on the location with some of the binaries. As a result, one of the secure binaries could simply be switched out with another script to become root.

To make this attack more spicy, there is a reflected XSS vulnerability on one of the APIs. Using this, the rest of the vulnerability chain mentioned above could be performed. Unauthenticated to popping a shell!

The article ends with a failed attempt to get code execution via parsing read-only documents. The author touches on many different potential ways that were partially reviewed and things with known vulnerabilities being used. Additionally, the app runs within a sandbox called Firejail.

The sandbox itself is known to be secure; it limits access to the file system, network resources and many other things. The network was restricted by limiting access to all inet sockets. However, the application uses Nginx as a frontend to forward requests to the backend via domain sockets. The deployment of PHP is done using the “fastcgi” mechanism, where a long running PHP server receives requests to invoke scripts, to avoid the cost of process start-up.

The limitations of the socket are only done on the inet and not Unix. As a result, a Unix stream socket connection to the PHP FastCGI server can be made to execute a PHP script within the directory. With this, we have code execution outside of the sandbox.

Overall, the SSRF exploitation, privilege escalation and sandbox escapes were unique and enjoyable to read. Seeing the full attack and the scrapes of notes at the end were awesome.