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!

OSSN is a open source start-yourself social media platform. So, lots of images!

First, there is just the ability to read any file. Just specify the actual path of the file. This is pretty standard... but, there is one twist: the crypto!

The file name used some custom cryptography (here we go) that was crackable. However, it was not trivial. A lot of digging took place in order to get this exploit to work.

First, an 8 character key is generated for Blowfish. However, the generation of this key reduced the space from 281,474,976,710,656 possible keys to 2,147,483,647. This is because the key was a value of md5(OSS + rand()). Rand only has 2^32 possible values! So, the key space was reduced.

Second, in order to brute force the key, a 'successful' encryption attempted needed to be identifiable. From reading the source code, it was discovered that the value for 'tmp/photos' could be easily grabbed with the encrypted blob. So, brute force the key until this value is found from the decryption process.

Finally, they were ready to brute force the key with a known correct result with all possible values that the key could be.

Overall, great write up! It is super interesting to see such subtle bugs in cryptography destroy the security of an application. Don't roll out your own crypto!

Cross site scripting (XSS) is when JavaScript can be ran on the domain as the current user through injected JavaScript. This is bad in its own right.

What if there was an XSS bug that affected every website on the internet? Well, that is a Universal XSS (UXSS). This tends to be a vulnerability with the browser itself!

The bug was within the Location Header of the incoming request. By adding JavaScript to this header, the previous domain (before clicking on this website) would execute the JavaScript! This could be used to steal sensitive information or make changes to the existing website.

This vulnerability existed in Brave, Cliqz and Firefox. It seems from a feature called bookmarklets that was added to Firefox for iOS.

The article dives into the protocol being used on these services and how it works. Because this protocol was complex and had not been tackled before, there was a good chance that something was going to be uncovered.

By reversing the protocol, they discovered an endpoint that was prior to any authentication! This endpoint was used to update critical information on the server, mainly configuration files.

This API was then trivially vulnerable to directory traversal, resulting in the ability to write any file to any location on the server.

How to get a root shell? They decided to use the unauthenticated API to overwrite configuration systems (which were obviously trusted). From there, they setup the authentication to a 'third party provider' of their own server.

By controlling this authentication scheme, they could control who was authenticated. So, they issued a token for the administrative user on the platform and logged in as them.

Finally: the RCE. The admin user can write TM1 scripts. This scripting language has a ExecuteCommand primitive, which enables easier code execution.

Overall, two things stuck out to me:

1. A simple lack of authentication on a single endpoint turned into a complete compromise of the server!
2. The lack of defense-in-depth on this from a single bug was interesting... it appears that several vulnerabilities in this single API could lead to a remote compromise of the server. A scripting language that can execute shell commands? They sounds like it is just waiting to get pwned.

Most of this article is just an overview of what .LNK files are and their structure.

However, I found the bug simple but interesting. At some point, a buffer is created but never initialized. Because of this, the buffer still has leftover values from when it was previously used for an entirely different purpose!

Eventually, this leads to a write to arbitrary memory. An attacker can choose 4 bytes (from the stream) and write those 4 bytes to any 8 bytes (from previous leftover value).

The off-1 features are usually where the bugs are at; not in the common and known features. This bug abuses the search string functionality of a .LNK file. Look at the weird and underused functionality for bugs.

OAuth is a protocol used in order to identify users on another website, without ever exposing the credentials of that site. This can be used to delegate authentication to a trusted provider.

In these implementations, the real back breaker of an implementation is the redirect_uri. If the redirect_uri can spoofed then the user account can be taken over via a stray link that a user clicks on. This is because the redirect_uri contains a token that acts as the authorization token for the website being used.

However, these bypasses are not easy to come by... even if they are found, they usually require a ton of creativity to exploit.

The Facebook redirect URI was fine... Except, it did not validate the file extension of the request. Because of this, a malicious actor can alter the ending (therefore, further into more directories) in order to find a way to redirect this. But, there's more to it though in order to make this exploitable.

The redirect was still only on the Facebook domain! Well, this redirect could be fed into a page that send a postMessage into the * domainThis meant that any page listening! And, this domain was iFrame-able.

So, three individual security issues were used:

1. Lack of proper validation of the redirect_uri
2. Insecure handling of postMessage request in an iFrame
3. Lack of proper headers set (allowed for the page to be embedded inside an iframe

Overall, this article was interesting! It took a three very small issues and turned it into a complete account takeover.

Typically, CSRF testing is just edit the token, remove the token... and so on. But, this article explains another way to bypass CSRF protections in some applications.

How? Sometimes, applications have redirects to different types of redirect. The author refers to this as method override. This method override can change the way a request is sent (change a GET to a PUT, for instance).

PHP has two comparison operators: loose and strict. Dealing with loose operator comparison in PHP is well known to be very weird with interesting results.

A good example of the weird is this table, which has a list of all of the comparisons and what happens to it.

The twitter link (above) is showing a CSRF bypass because of the loose type checking that occurs. By adding an array ([]) for the CSRF token (instead of the actual token) the type comparison gets messed up.

What actually happens? When empty array gets evaluated in the strcmp, it returns null. Then, it compares null with 0. According to the chart above, null == 0. So, this bypasses the security check!

An example of a vulnerable package.

A good starting point is noticing the usage of an insecure (and now deprecated) function in PHP: create_function. This function performs an eval on the code being ran. The code would normally turn into something like this: create_function('$a', "return str_replace('\\quote', 'quote', \$a);");

The developers thought this might be a security issue. So, they were converting all single quotes (') into \' (escaping it). But, the clever man realized that they were not escaping the escape sequence! So, the "\' would be transformed into "\\'". Therefore, the string would be escaped!

Now, how to actually exploit this? Some PHP trickery was used in order to make the payload work. Here's the following payload: ).passthru("id").die();}//\

A few of these bypasses are interesting. Most of them are just trying to close about parts of the function, in order to make the code run properly.

• The first ')' is terminating the str_replace function.
• The '//' is a comment to stop all code after this from running (preventing a seg fault).
• The '}' is required in order to keep the create_function from breaking.
• The backslash, at the very end, escapes the quote being used.

Overall, the bug was a very subtle bug and the exploitation required a lot of toying around in order to get everything to work just right!

First, what do we look for in a target for privilege escalation? This blogger explains that looking for SUID binaries is a good place to start. In addition, third-party vendors tend to implement binary helper programs (with SUID) that do not take the proper security precautions.

To trace the execution of other files, dtrace (like strace in Linux) was used and filtered out with the execve syscall. By doing this, it was discovered that VMware Fusion was trying to load in several non-existent files, which looked like a good path for an LPE!

The parsing of how these files are called is interesting and the author reverse engineered this use IDA. The parsing attempts to find files by complicated parsing measuring and ensuring that links are valid.

By setting a hardlink on a file (that should exists but the program cannot find) to a location where we can compile the payload, it tricks the program into keeping the setuid binary of the file!

Unlike Linux, macOS allows unprivileged users to create hard links to SUID executables. This is the main reason that this exploit was possible.

The vulnerability is quite interesting! The server itself only runs locally. But, with some tricks (email bouncing) the exploitable code can triggered locally.

The vulnerability stems from a parsing issue when sending commands. By abusing a subtle parsing bug, the email envelope can be altering by each newlines (or new commands). The injected lines, into the envelope completely alter the packet being processed by the mail server.

By altering the envelope, this gives us the ability to trick the code to run other things entirely. Hence, this later allows us to arbitrary shell commands.

The above only works on the client side code. With the server-side code, several issues have to be overcome. One stands above the rest though: the previous request (before the envelope was altered) has been cached on the server. So, how do we remove this cache? Let's crash the server! By crashing the server (with the previous vulnerability again) it will forget the cached value and run the injected command.

Overall, the creativity to get this exploit working server-side was pretty awesome. Real world bug hunting is much more complicated in that of a CTF.