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 CPU optimization created a double fetch, of the same memory location... This does not seem like a big deal! But, a value can be verified as correct, then changed when actually used! This is known as a TOCTOU (time of check vs time of use).

The article claims to be that the vulnerability is caused by the variable not being set to volatile. However, my understanding of volatile is that the value should be regathered frequently, because the value could be changed out of band or something like that.

After not understanding what this flag on a variable meant, I found a great article explaining it all at barrgroup.

Quote to some up the reason for going down this attack vector: "When a privilged service writes to a user owned resource, it opens up the possibility of s symlink (vuln)...".

Used dnSpy to open up the C# binaries to get full source code recovery. That's a really nice thing to have! Another useful tool was procmon, which shows the running processes in Windows.

With an arbitrary file write with some Windows file black magic, they were able to take over the computer.

Why did this happen? Impersonation features are really hard to get right! Either don't do them or really test that they are done correctly.

By exploiting a simple IDOR (indirect object reference) it was trivial to create a post within a different group. However, the current users group id had to be used with a victim post? I thought this was really odd.

To me, the weirdest part was that a similar bug was found on Facebook and fixed! However, it was on a different part of the site...

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!