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!

This is a large article with trends from the HackerOne platform. Enjoy!

The vulnerability classes section is interesting. Access control issues have increased by 18% (IAC) and 29% (IDOR), while authentication issues have decreased by 9% and privilege escalation by 8%. Another category that has gone up is misconfiguration issues by 29%. SQL injection is down by 23%, code injection by 1% and XSS by 14%. Finally, business logic flaws are up 19% but down 5% in terms of payouts. AI vulnerability reported skyrocketed this year, as expected.

For XSS, SQLi, SSRF, and information disclosure, they claim it's because these "commodity" bug classes are reaching a maturity point. Hackbots could have something to do with this. In terms of total reports, XSS remains the most common vulnerability report, which is particularly interesting.

They examined bug bounty programs that had lowered payouts for similar types of bugs in the last year. Of these, 73% saw a decline in valid submissions and 50% were without a critical vulnerability in the last year. This indicates that if you pay out less, then you will get less people on your program. What entices researchers? Good scope documents, good triage/response times and fair/consistent payouts. These all build trust that the time is well-spent on the program.

They have a table of payouts by industry, divided into severity categories. Crypto/web3 has the highest payouts for bugs. After that is Internet/online services and Computer software. Things like financial services, government and retail are relatively low. The benefit of high rewards is that more people looking at the programs more.

The report discusses the exploit likelihood by industry. Bugs in finance are fewer but much likelier to be exploited. Within Government and technology, validated bugs carry a fairly high chance of being exploited in the wild.

Overall, an interesting report on the trends of security issues on HackerOne. Thanks for the open data!

In GitLab, you can specify a server for Sentry to generate function buttons for error tracking lists. By configuring the error information, you can modify the routing of subsequent requests to GitLab. This is a vulnerability known as Cross-Site Path Traversal (CSPT).

By using the ../../ in the error message, we can traverse up the path for other requests. In this case, it's possible to create arbitrary PUT requests on GitLab. The impact of this is immense! Trick users into adding admins, elevating membership, and approving membership. I assume that the contents of the PUT request are controlled via JSON with this.

The comments on the bug are interesting. One of them claims that an attacker could do this by tricking GitLab support with this issue. They also find other sinks that they decide to fix. They ended up adding enforce_path_traversal_check to an internal library, making this default to true. Great bug and great report!

In a previous blog post, Doyensec detailed how to exploit CSPT to perform CSRF by using file uploads to transfer data for routing in a subsequent request. In their example, there were no restrictions on the file upload functionality, but this isn't always the case. So, they detail some ways to add JSON files to the server in unintended ways.

The mmmagic library in NodeJs is used for file type detection. PDFs are notirous for being lax in their format. By creating JSON and placing %PDF in the JSON at all, it'll be considered valid PDF and valid JSON. It just needs to be within the first 1024 bytes.

In pdflib, it requires more than the PDF header. There is a polyglot technique that can be used to do this. The trick is to replace %0A between PDF objects with spaces. Then, open a double quote with the PDF header and other valid-looking PDF data.

The file has strict limits on input size. By making the sizes too large to handle, it may revert to the default file type. In many ways, this should trigger an error, but that apparently differs on the system.

This isn't a vulnerability class by itself. However, it DOES help in the exploitation. Good post on CSPT exploitation!

Client-side path traversal (CSPT) is a vulnerability where routing decisions can be controlled by a user-controlled value in the PATH parameter. For instance, the ID in the URL is set to ../../ID. On the frontend, this is then used on an API request. However, the ../../ID can change the routing of the request.

Cross-site request forgery (CSRF) is a classic vulnerability that has become harder and harder to do over time with A) knowledge of it and B) browser protections like same-site cookies. They wanted to combine these issues to allow for CSRF to still work in some cases.

CSPT will route a legitimate request. This can be used for CSRF-like attacks. Much of the time, there is no control over the HTTP method, headers, or body of the requests.

Sometimes, data is returned and then acted upon. When using a GET sink for CSPT, there is sometimes a response that contains the ID that is then used on future requests, such as state-changing POST requests. This allows for forcing the user to create arbitrary requests that shouldn't usually be possible. There's a key to this though: what data do we want to be returned from the GET request? The attacker must control the ID or routing value of the JSON. This can be achieved by exploiting file upload/download features to contain the content initially. Then, the state-changing action can occur.

They found an instance of this on the Mattermost chat application. An ID for telem_run_id in the URL was used in the routing that was vulnerable to CSPT. The only data being returned in the response that can be used is the action. This provides a minimal CSRF vuln with specific restrictions.

The whitepaper describes how important it is to know the limitations. Once you have this, you can explore more effective ways to exploit the issue. In this case, a single parameter is controlled in the POST request. However, arbitrary data can be put onto the path, including parameters. Knowing these restrictions, they noticed that the plugin installation process only required a single URL parameter. So, this led to RCE!

On Mattermost, they discovered a GET-to-POST-based sink. They uploaded a file to /api/v4/files to then use the returned data from the GET request in the POST request. Same as the previous issue, this led to RCE via URL parameters.

Overall, this is a good bug class to call out. It's somewhat new, which means many applications are likely to be vulnerable to it. It's a first-come-first-server game!

The author of this post had read Bypassing File Upload Restrictions To Exploit Client-Side Path Traversal. Upon reading this post, they found that many of the tricks weren't working. They mainly relied on tricking a parser to think something was a different datatype than it really was. Because this, they decided to read the source code of libmagic and found how it decides if something is a JSON file or not.

If a JSON file has 500 levels of nesting, it treats it as plaintext. It turns out, that most languages for detecting file types have this limitation—the call range from 64 to thousands. In the case of libmagic, and many of its wrappers, anything over these amounts will simply return the type as plain-text. Little quirks can go a long ways!

The author of this post had found a vulnerability in GitHub previously. They decided to conduct a scan for Dependency Confusion issues on GitLab and GitHub. While looking at package.json, they didn't find anything.

Their next step was to check Ruby dependencies on GitHub Enterprise, which is an open-source platform. They thought this was a good target because A) GitHub Enterprise isn't well-known to be open source, and B) dependency confusion in Ruby is less well-known. They noticed over 100 packages that were unregistered externally! So, they created a Ruby Gem for all of these that exfiltrated data via DNS to prove impact.

After waiting a bit, they had about 2K callbacks within a 24-hour window of submitting the vulnerability. This allowed them to execute code in several locations, including buildkitsandbox, vscode, and several others. After reporting the vulnerability, they were asked to take down the malicious gems to prevent further impact of the issue.

The author claims that they had access to the domain, which was used for the build process and dev code workspaces. They were awarded $20K but though it was going to be more. To give them credit, they stopped executing further payloads and didn't try to pivot at all. Based on this, they believe the payout should have been higher than the minimum payout for a critical. GitHub is known to have a good bug bounty program so it's hard to say who is right/wrong here.

A good write-up with sound guidance on the discovery process! I thoroughly enjoyed the blog post!

The author of this post was writing a Go implementation of ML-DSA, a post-quantum signature algorithm done by NIST last summer.

After 4 days of trying to create the implementation, the code was rejecting some valid signatures. They tried debugging it for several hours but were unable to resolve the issue. So, they asked Claude Code to check it out and left their computer for a bit.

The prompt explains what the code does and the issue they were dealing with. They granted it access to run the tests and implement the changes, as well as access to the source code for reading. They topped it off with ultrathink to make it go hard on the problem. To their surprise, an issue popped up! AI excels at well-scoped tasks like this one.

The issue was subtle in the math. They had merged HighBits and w1Encode into a single function for using it within Sign. This function was used in Verify(), which had already produced the high bits. So, they were effectively taking the high bits twice. Claude found the issue immediately without using any exploratory tool use!

Was this a fluke? They had two bugs prior to this that took an hour to debug. One was around incorrectly hardcoded constants. The other was an encoding being 32 bits instead of 32 bytes. In both cases, it was able to identify the issue through extensive debugging and multiple runs. Still, this was faster than the author of the post!

I love seeing use cases of AI and the prompts used. It helps me utilize the tooling better. Thanks for the article!

A Solana extension with real-time analysis of vulnerability classes. The extension performs checks on Anchor-specific issues, which are definitely needed! They have nine detectors. Of these, I find missing signer verification, unsafe math operations (overflows), and improper sysvar account checks to be the most interesting. Some of them aren't "security issues" like unused instruction attributes but it's good for static analysis checks.

There is also test coverage support. So, you can know which lines of code are not being hit by your unit tests/fuzzer. Good-looking extension!

Confidential Virtual Machines (CVMs) are Linux-based systems that run in automated environments, handling secrets in an untrusted setting. They run on an untrusted host machine but are interacted with remotely. These are used in applications like private blockchains or multi-party data collaboration. These systems require that the host OS not be able to read memory or modify the the logical operation of the CVM. Additionally, a remote party should be able to confirm that they are running against a genuine CVM program via a remote attestation process.

LUKS2 encryption is used for encrypting the hard drive of the CVM. It contains header information, followed by the actual encrypted volume. The main encryption setting is aes-xts-plain64. The setting cipher_null-ecb is an algorithm that just ignores the key and returns the data unchanged. When the null cipher is used, the key slot can be opened with any passphrase. Effectively, the key phrase is just ignored - in newer versions, the password must be empty in this mode.

This attack enables you to substitute an attacker-controlled drive for the legitimate one.

The threat model is really confusing to me. It's a malicious host attacking a VM that is modifying the VM. If the device is running an OS in a VM, couldn't you change the VM's memory to perform arbitrary actions anyway? Maybe I'm misunderstanding something.

The Windows Server Update Service (WSUS) is a Microsoft tool that allows IT admins to manage updates for Windows systems.

The upgrade process contains a cookie that is encrypted using AES-128-CBC. It is passed BinaryFormatter.Deserialize() from the cookie once decrypted. This is a known sink that can be used to get RCE.

The API endpoint POST /ClientWebService/Client.asmx is the vulnerable endpoint. The cookie is encrypted but I don't understand how they are able to encrypt the data and then have that be decrypted and used for the deserialization attack. The PoC just has hardcoded data so maybe the key is hardcoded in the application. According to this article, this can be used to get RCE with SYSTEM privileges. Pretty dangerous bug!