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!

One of the best pieces of research I have ever seen!

To start with, the amount of reversing on this project was unreal! It appears that the crazier projects are starting to have more and more of this...

In order to create a testable env, they used a serial connection (to pins on the board) and a known vulnerability in order to get a debugging env possible.

The details of exploiting this are quite awesome! Even though the stack was executable, this was not as simple as one would think (as it had an I-Cache and a D-cache). Using a ROP chain, the D-cache and I-cache were cleared. Then, some shellcode was written, on the stack, to make this exploitable. Finally, they had a usable debugging environment!

After the recon stage, on how fax machines work, two vulnerabilities were found within parsers. Each allowed for a very large buffer overflow, resulting in RCE.

They wrap up with not just an RCE, but how to weapon this vulnerability in the fax machine as a whole. Again, amazing research :)

While normal SQLi is quite popular, No SQL is starting to become more of an issue.

In this case, the parameter not being sanitized was being put into a query. This query could be dynamically altered by adding NoSQL operators to it.

Although this is blind, the discovery of this was via source code analysis.

CSP's (content security policies) are really hard to get right! So, this is a large collection of poorly written CSPs, just for the fun of it.

Bypassed upon a username being valid or not, two different code paths were taken.

One, with an invalid username, closed the connection immediately. The other, did something entirely different. This subtle difference made it possible to deduce if a username was valid or not!

The beginning says it all: serialization / deserialization is hard to implement correctly. Anytime complicated serialization is being done, this is a good place to look for vulns.

By adding a fuzzer, to test the extension, several crashes were found.

Eventually, by playing with the serialized values enough, a crash resulted with the classic "AAAA" (0x41414141) being within the instruction pointer.

With a combined memory leak and the ability to write to the program, this essentially guarantees a RCE :)

This is the article that really got me into hacking! Please, just go read the article; there is so much wisdom on that page.

Looking at a native PHP project from the year 2000... Bound to find a ton of bugs!

SQLi everywhere! But, we need to choose one wisely. Preferably, one that returns as much data as we want from the database. The exploitation was made significantly easier because stacked queries were enabled.

The SQLi was used in order to create an administrative user. After this, an authenticated command injection vulnerability was found in order to achieve RCE.

This article goes through the process of finding vulns and working through the hurdles!

This product is built off of Jupyter Notebook. The main aspect, that is being tested, is the Markdown editor. It was discovered that it had some sort of input sanitation, making it a good target.

The hacker went through the source code on the frontend in order to find how the parser worked. This included regex's and library's being used.

Eventually, this recon turned into discovering that Google Collaborator actually parses LaTex too. Now, it was about finding a XSS in the MathJax library.

By abusing the LaTex, an easy XSS was found. Now, it is time for the CSP bypass :)

By abusing previous research, the CSP was able to be bypassed. Great research :)

IPConfigure Orchid Core VMS

By simply URL encoding the ../ to be %2e%2e%2f it was possible to traverse the entire file system in order to read arbitrary files.

The discovery is the most interesting part though! Initially, when trying to read /etc/shadow on a Linux server an error message appeared: Could not locate resource /etc/shadow. Because of this, they URL encoded everything... Then, it came through!

No-Cors request: Makes no checks for CORS policies. This only applies to specific resources, such as images, CSS files and non-module scripts.

Range requests were never standardised: Because of this, all browsers do different things when dealing with HTML.

By using the fact above, several security issues were found...What should happen when someone requests an audio file from a site then redirects to another site? This probably should redirect (which Chrome and Safari) did, but some browsers did not.

In Firefox, this leaked the frequency, bit depth and channel of the audio (in the header).

In Microsoft Edge, things got much worse. The browser allowed for the web audio API to be called after the redirect. Using this feature, CORS is entirely bypassed! The content of the page was passed back, simply from visiting a site and playing some audio.

Finally, the article concludes with a rant about how standards are important in order to prevent security issues like this one.