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!

The author of this post found a really straight forward buffer overflow in the authentication API of an IP camera that could overwrite the return address on the stack. The application had NX enabled and ASLR but had no canaries, no PIE and partial RELRO. Given that they couldn't find a libc leak for a simple RET2Win attack, they needed to do this without an information disclosure. They did have the ability to call arbitrary code in the binary via ROP chains though!

The technique they end up using is interesting: use the Global Offset Table (GOT) and Procedure Linkage Table (PLT) to bypass ASLR. The idea is to use the code in the PLT to jump to incorrect functions using relative offsets. At a high level, this can work by reading a GOT entry into a register, increment/decrement the register until it's at the proper value and then jump to the register. An additional path is incrementing the GOT pointer itself.

After some effort, they found the function isalnum from libc that could take in user controlled input and was already loaded in the GOT. The difference between this function and system() is only 0x13230. So, the goal was to add this much to the address in the GOT entry to trigger code execution. While hunting for quick/easy gadgets, they didn't find any. All of them had side effects that made it infeasible.

After searching for gadgets for a while, they found a string of gadgets that could perform what they needed to do. Notably, the gadgets sometimes needed to call other gadgets, which made this even harder to do. The list of gadgets was as follows:

1. Dereference isalnum@got and store the results in r6. The gadget wasn't perfect but did the job before jumping into the value in r3 for the next gadget.
2. Use the next gadget to add the offset to system back into the GOT entry stored in r6. This jumps to the value stored in r3 for the next gadget in the chain.
3. The final gadget writes r6 back to the GOT entry that we originally read. This is because they couldn't find a way to jump to r6.
4. Prepare function arguments for system(). Then, trigger the overwritten GOT entry for code execution.

At the end of the post, they point out that this was a 32-bit binary and the offsets could have just been brute forced. In fact, their original exploit did exactly this. The creation of the exact chain required some difficult maneuvering of values in order to not have bad side effects. Overall, a great post on the end to end of exploiting the device!

Fortinet had a 0-day that was identified publicly. This is a report of the timeline of the issue and the exploit that was found for it. It was made up of two security issues in total.

The first vulnerability is a fairly simple looking path traversal. By using a completely valid API path (/api/v2.0/cmdb/system/admin/) and then traversing backwards via ../ it was possible to traverse a different CGI executable on the device. The program likely took the rest of the path after the API endpoint and just used that as the path for the executable. However, the actual vulnerable path wasn't confirmed.

Once the CGI is called, that wasn't intended to be called, there are still two checks to bypass: input validation and auth check before it will process within cgi_process. The first check just performs basic JSON validation. The second item, labeled as cgi_auth(), is an impersonation function and NOT an authentication check. It extracts the header CGIINFO to decode a username, profile name, virtual domain and login identifier. With this information, you can impersonate any user in the application, such as the built-in admin.

The real exploit creates a local user with administrative privileges to take control of the device. Overall, an interesting bug that led to the triggering of unintended functionality. Pretty neat!

AI coding assistants can hallucinate non-existent package names. According to studies, somewhere between 5-21% are bad. 58% of these were recurring across multiple sessions.

In the past, typosquatting was a thing: create packages with common misspellings of a package to install code that the developer did not intend to install. This is the same thing but for AI generated code. To do this, monitor the AI output for commonly hallucinated package names, install the packages on PyPI, npm, RubyGems and other locations. By doing this, you can trick AI generated code to install malicious packages.

This is website is a tool that provides a lazy-loading trust scoring system with different tiers. With tier one, it does download, age and version history scoring. In tier 2 it does dependency analysis. In tier 3, it does a deep analysis of maintainer reputation, email domain verification and GitHub detection. This claims to have a very good accuracy and solve the problem. Under the hood, it's just a simple open source tool that does the scanning and even has GitHub CI integration support. Pretty neat!

Monsta FTP is a web-based FTP client that let's users manage and transfer files on remote servers through the web browser. A vulnerability was found in it - making it an N-day, that they decided to review. Once of these was an arbitrary file upload that leads to RCE. An SSRF and RCE weren't initially fixed, although reported in the CVE database. After going through lots of lots of versions, they found some input validation functions that were trying to prevent path traversal. Hurray, they found the patch!

The SSRF vulnerability that was reported still worked... so, was the RCE bug patched? Maybe the developers didn't understand what/where to patch. They were curious if the patch was sufficient. After looking at a large switch statement, they realized that DownloadFile didn't have any checks on it for directory traversal. By spinning up a malicious SFTP server that exploited the directory traversal, it allowed them to write the file to anywhere on the server.

They don't mention an authentication bypass... but, they claim this leads to an unauthenticated RCE on Monsta FTP. For me, there are two takeaways. First, not all patches are sufficient. Second, many of the time there are other variants of vulnerabilities lurking if you check those out. Overall, a good blog post on finding security issues once issues are already known.

N-Central is N-able's remote managing and monitoring solution. There was two vulnerabilities in the software. While reviewing the software, they found two more. This reports on all four of them.

CVE-2025-8875 was an insecure deserialization bug. ObjectInputStream is used to create an object from raw bytes. Using user controlled data, this could be used to create arbitrary objects. Although not explicitly stated, this commonly leads to RCE in Java-based products. CVE-2025-8876 was a simple command injection from input provided directly to Runtime.getRuntime().execute(). Both of these were on legacy APIs but required valid sessions.

They found that authentication could be bypassed via some pre-configured authentication information for various appliances. So, many authenticated endpoints, besides the SOAP ones, could be triggered using this. This opened up much more attack surface for them to work with and a partial authentication bypass.

While using grep for functions that use XML, they found a parser that wasn't configured with secure defaults. So, this led to an XXE issue. They used this vulnerability to retrieve arbitrary files on disk. In all likelihood, this would lead to a complete compromise of the system via extracting configuration, backup and database information with credentials.

Overall, a great chain of vulnerabilities to go from unauthenticated to taking over the machine directly. Great work!

CSS can style visited links differently than unvisited links. From a security perspective, this is a problem because a web page can review a user's complete history this way for other sites. This post provides a summary of the problem and proposes a solution.

Website authors can use the getComputedStyle function to determine if a link has been visited or not. An easy way to fix this would be to make this API lie. In practice, this approach doesn't work because the CSS styling itself can vary, including colors, spacing, and other elements.

To fix the above issue, a limitation would need to be put in place to limit the ability to style pages on whether links were visitd or not. Many CSS selectors will always act as if they've been visited. Additionally, the CSS properties applied to links should be limited to a few select options.

A few limitations of this approach are discussed, highlighting the importance of the mitigating threat model for these types of features. First, this is NOT intended to resolve attacks that require user interaction via clicks. Second, fine-grained timing attacks - they hope this prevents most practical ones. Finally, this doesn't intend to avoid browser cache-based attacks.

Overall, a great post on a proposed browser mitigation for a well-known attack vector while keeping as much functionality as possible.

The Same Origin Policy (SOP) is meant to prevent one website from requesting information on another website. In practice, data can be leaked from websites in other ways. A major one of these is timing of loading a resource.

An original vector was described by Chris Evans against Yahoo! Mail, where you can search the inbox of a website to see if results are returned or not based on the amount of time it takes. Later, this was coined as XSSearch with hard statistics on timing. Based on timing, a list of attack methods, such as frame counting, is becoming increasingly popular due to "browser misfeatures".

One of these methods that the author wants to bring to our attention is around browser caching. This can be used for timing attacks to understand if something was cached or not for the browser history. geographic information or general fingerprinting. Their variation is as follows:

1. Delete the cache for a specific resource.
2. Force the browser to render to a website as the user.
3. Check if the browser cached the resource.

They first check out Facebook for issues relating to this. According to them, URLs are signed, so it's not a simple cache or no cache problem. A good question to ask is " Does the image X get cached when the profile page is loaded?" By reviewing the cache, this could potentially be checked.

Another variant of this on Facebook is checking for user access to some resource, such as a private group. In this case, it requires that something cachable be loaded in some cases, such as a legitimate search, but not in an illegitimate search. When searching Facebook messages, an extra pop-up appears to confirm before any JavaScript loads, preventing this attack. Facebook has some pretty neat protections against these types of attacks!

How do we invalidate a cache entry? By making a POST request to the resource or issuing a Fetch API with a cache that returns an error from the server, such as a large HTTP referrer header. The final trick is quite simple: delete the cache, reload the page, and query the cache for the information. Crazy - the never-ending curse of caching.

They end the post with some caveats on exploitation and a note of a Wiki page with all known Cross-Site leak techniques. Great post!

Electron-Builder is marketed as a package and build system for Electron Apps with auto-update support. On MacOS and Windows, there is code signing and verification support built into it.

While reviewing the update mechanism of Electron-Builder for a client, they noticed that the validation failed open if the PowerShell command used signature validation failed. If there was a parse error, the command would still succeed silently. By claiming the file name contained a single quote, the parse error would return a valid result. Practically, this also had a command injection, which is less than ideal as well.

The command injection issue was eventually resolved, but the fail-open design remained. Since the expansion led to both a parse error and a command injection issue, this was sufficient for both problems. In reality, the fail-open design is still bad, and there are likely other ways to trigger this same issue.

XSS auditor was a Chrome feature that allows for the header X-XSS-Protection: 1 to block XSS attacks. If an XSS attack is found, then Chrome will clear the entire page. The author of this post decided to look at this feature for potential security issues.

XSS auditor attempted to find reflected XSS attacks. This was done by reading the request body and seeing if DOM-tree was created directly from input in the URL. This paper discusses some transforms that try to comply with, such as PHP magic quotes and Unicode normalizations. Any larger transformations cannot be caught.

The post linked in this report is all about creating an oracle based on whether the XSS auditor is present or not to leak data off the page. Since the number of iframes on a page can be read across windows, this can be used in conjunction with the removal of the iframe as an oracle. The page isn't IN the iframe, but the iframe serves as an oracle to determine whether the page is loaded correctly or not.

Their first idea was to read a user ID character by character by using fake XSS payloads. First, they include a fake XSS payload that looks something like <script>uid = 1337;</script> in the URL. This is what the page normally looks like, though. Now, you put the data that you want to check into the URL. For instance, <script>uid = 1;</script>. Since this is NOT on the page, nothing happens. You can iterate on the UID over and over again until the XSS auditor finds the string match and blocks.