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!

Veeam published a CVSS 9.8 score for a complete authentication bypass vulnerability on their product. The author decided to take the time to understand the issue and write it up. Since they only have information from the CVE, they'll have to do some reverse engineering for this.

The author goes down the authentication flow to find some weirdness with SSO. In particular, when using VMWare SSO, a SAML XML document is provided. One of the controlled values is the URL to check against.

Since an attacker can provide their own SAML server to check again, it's trivial to bypass the authentication! If you can validate yourself, then you can easily exploit this.

The core vulnerability is simple - bad input validation on sensitive values. However, this would have required a fairly deep understanding of SAML and the authentication flow to exploit.

The author of this post ended up looking for issues in Veeam themselves after this. When doing JWT authentication on the Recovery Orchestrator, it had a hardcoded JWT. Since this is hardcoded, we can sign our own JWTs.

On Zoom, the cookie _zm_csp_script_nonce was used on every single page as part of the CSP script-src field. The CSP was set within an HTML tag that wasn't being escaped. So, it was possible to escape the context of the string to add in our own HTML.

The badly reflected data was put into the CSP nonce field. The CSP nonce uses single quotes while the HTML uses double quotes. Additionally, the second nonce will be parsed. So, using a double quote within the first nonce, using a valid nonce after that then putting our HTML within this cookie gives us XSS on the page. Pretty neat!

Cookie tossing is a technique that abuses the domain flag on a cookie. By having XSS on any subdomain of Zoom, setting the _zm_csp_script_nonce now leads to XSS on the main page. After hunting on other subdomains, they found a post-based XSS to use with this.

How does the chain work to get XSS on the main page? This is how we get XSS on the main Zoom page.

1. Make a POST request to the vulnerable endpoint on the Zoom subdomain with the XSS payload.
2. Payload will set the cookie via cookie tossing with the long path trick.
3. Redirect the page to the Zoom main page.

To prove maximum impact, the authors decided to use some OAuth dirty dancing with XSS. Frankly, this is a little out of my league to write here but is interesting none-the-less. By using the XSS, they're able to abuse the Google login flow to get an OAuth token that was never processed.

For some stupid reason, the Zoom team rated this as a medium since they hadn't proved persistence - that was a mistake! The Zoom team wanted a password reset to demonstrate persistence. Instead, the authors decided to use the cookie aspect of the XSS to get persistence. As long as the cookie lives, the attacker will make access to their account.

Second, they realized that zoom.us has permissions for video and audio. Since the user had already approved this, the attacker could turn this on camera silently then send it to themselves. The aspect of the extra permissions was interesting and not something that I had considered before.

The final technique was a denial of service via abusing the WAF. By using the POST based XSS to set any cookie, an attacker could set this with an obvious XSS payload. By doing this, the WAF will reject all requests to Zoom until the cookies are cleared. I had never seen this before so something interesting to see.

A crazy string of bugs to cause serious havoc on Zoom. I personally really enjoyed this post with the diagrams and unique takes on exploit development. Great work!

The vulnerability is a known issue that was originally processed over 10 years ago. However, it's such a common mistake that languages keep making the mistake again and again. When executing system commands via a subshell, it's important escape these characters. Otherwise, command injection can be used to control the system. Most languages have this feature and it works well.

In order to prevent command injection, the malicious inputs are commonly escaped. Additionally, the inputs can be processed with a unique argument context, preventing the meaningful bash metacharacters from doing anything on Linux and Mac. On Windows, the process is entirely different though.

When executing a .bat (batch) file on Windows, the OS will automatically do C:\Windows\System32\cmd.exe .\test.bat within CreateProcess. Most languages want to escape the input being used in order to prevent command injection. However is this escaping done? Using backslashes! However, unlike Linux, Windows doesn't process these as an escape - it uses ^. So, \" is insufficient.

This leads to shell metacharacters being able to break out of the escaping! For instance, using "&calc.exe as the input for a spawn in NodeJS will execute calc. This leads to command injection on Windows systems whenever a batch file is used and inputs can be provided to it.

The obvious way to fix this would be using a caret(^) instead of backslash. However, the command prompt will expand variables inline before other parsing. So, it's possible to use substring of ENV variables to add in your own quotes once again, which is bad. How do we actually fix this then?

As a developer, fixing this issue is super tricky because of the issue mentioned above. It involves disabling the automatic escaping then replacing a bunch of dangerous characters by hand. As a runtime maintainer, no extra info was added but was something that just needs to be fixed... weird.

Overall, a weird vulnerability in the interoperability of different systems. The bug has been around for a while! I enjoyed the debunking of the obvious fix in my mind as well.

Parser bugs can be real bad, given the wide spread use of them. The article has a few awards: most impactful, parser differential, hardest to fix and weirdest machine.

For most impactful, it was the webp bug. The huffman compression was absolutely everywhere. The runner up was a H.264 file format set of bugs.

For hardest to fix, it was binarly post. Since they deal with low level firmware, it's non-trivial to fix. It was a memory safety issue in image parsing (of course).

Personally, I found the BatBadBut cooler as a parsing command injection bug. Bash and C tokenize arguments for invoked programs the same way. However, Windows bat batch do something entirely different, which most languages, including Rust and Java, didn't account for. In Windows, backslashes are NOT an escape for quotes - the carat is. So, the normal escaping didn't work.

The winner for best parser diff was a Gitlab parsing issue related to YAML processing in Ruby vs Golang. The runner up was a request smuggling vulnerability in NodeJS and several other servers via differences in the interpretation of carriage return within optional whitespace.

The winner for weirdest machine was the NSO groups exploitation of a parser bug to create their own architecture in a PDF parser, as researched by P0. Probably the craziest blog post I've ever read.

I appreciate the author grouping these all together! I hadn't read all of these so it was good for me to get.

XML eXternal Entity (XXE) injection is a vulnerability in XML parsing that allows for the adding of entities for file reads, SSRF and other issues. Most of the time, XXE bugs are fairly simple but this one was a weird URL parsing issue.

Microsoft.SharePoint.WebControls.BaseXmlDataSource is a class in Microsoft Sharepoint for loading data source objects on a Sharepoint page. The DataSource URL can be controlled as an arbitrary URL. While reading the code with claimed XXE protections, they tried to include a DTD and it surprisingly worked! According to the author, code that properly blocks DTD inclusion in .NET is pretty rare.

So, what was going on? The resolver will try to handle the entities THEN will perform a prohibit check. So, an exception ends up being thrown but NOT before the request is actually made. When doing the check for DTD inclusion within XmlSecureResolver, it does a check to URL check to prevent arbitrary domains from being used. In particular, the domain being pulled from MUST be the same as the data being requested.

The end goal was to get a XmlSecureResolver policy that allows for the reading of local files and allows for HTTP requests. The goal is to trick the policy writer to give us an unrestricted policy yet still be able to request data. This is a classic situation where URL parsing differences really matter.

After tinkering around for a few hours, they came to file://localhost\c$/sites/mysite/test.xml. Since this is a file URI, it gets ignored. Next, it looks for the ending of the file path, which is a local file system path, which we can freely write to anyway.

With this, the XXE bug becomes exploitable. Here are the steps:

1. Upload the malicious XML file to sharepoint as part of a website. This requires a low privileged user to do.
2. Next, create a page with the datasource being the malformed URL above.
3. Step 2 will retrieve the malicious XML.
4. The XmlSecureResolver creates a policy based upon the URL without any restrictions.
5. The malicious XML trigger the XXE bug.

Even though an error is triggered on the XXE bug with a DTD exception, it is too late in the processing. The requests to retrieve arbitrary files, such as win.ini, are already done. I found the error being triggered after the processing so fun. It's a good reminder to always look for side effects on a request that are not directly returned in the response.

Overall, a really good write up! I enjoyed the images throughout, as it was a difficult bug to think about.

devfiles are a mechanism for describes Workspaces in Kubernetes environments for Gitlab. Workspaces are isolated environments. The parent field can be used as a base for a workspace, but was banned in the devfile for security reasons.

At this point, the author noticed that two parsers existed: Ruby for Gitlab and Go for the Workspaces. So, if the author found a difference between the two parsers where Ruby didn't see something but workspaces did, it would be possible to smuggle in the parent field.

Prior to this, they had found a difference between Python and Go with the !!binary option. This didn't work but something similar did - !binary. The Go parser will decode the binary data for the key but the Ruby parser doesn't not. So, it's possible to add a parent but ONLY within the Go parser.

The author needed another bug to make this worthwhile. The devfile tar.gz parsing had a directory traversal issue. They had told the Go linter to ignore the opening of an arbitrary file because it was cleared. However, with relative paths, filepath.Clean does NOT actually clean the path. So, this directory traversal allows for the writing outside of the intended area.

They add a few more notes... First, parser differentials are everywhere and should be looked for. Second, don't trust the comments. Third, you can't find all the bugs, as they missed a go-git vulnerability while auditing this that was reported afterwards. Overall, a good writeup on an interesting bug!

WinRAR is a Windows specific compression tool. It also has a terminal version as well. ANSI is the escapes sequences used in terminals to change the color, orientation and many other things about text.

If the ANSI escape sequences can be included into text printed out to the terminal then it can be weaponized to change the screen. When WINRAR outputs the data to the screen, a malicious file could rewrite the entire screen by adding the escape sequences to the comment of the file.

Because escape sequences can be used to rewrite the entire screen (like in VIM), the author of the post was able to use the comment of a file in WinRAR to rewrite everything. In particular, change the file name output to be something that's different than the original. This could be used to hide viruses or something like that.

Interesting bug with awesome context. Good write up!

CVE-2023-34992 was for FortiSIEM command injection vulnerability. The phMonitor takes in a server_ip variable. This was being used to execute a python script via os.system that led to a command injection.

The vulnerability was fixed by just validating the IP address being passed in, solving the immediate issue. Within the same request as the original command injection, there is another field called mount_point. This field is saved then used in another script when testing the mount.

With this, we have a second order command injection that we first make a request to save the data then another request to execute the exploit from the saved data. I enjoyed this aspect of the exploit, as second order bugs are commonly forgotten about. Overall, good bug report :)

A while ago, Jacob reported a bug named p2p storms that ICF deemed wasn't worth fixing. If the blocks are 20mb each and the mempool is full, then the chain liveness are severely impacted. The author claims that this affects all chains and can be done cheaply with lots of large MsgUpdateClient