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!

Ever done a blackbox test that had a insecure file upload vulnerability but been stuck on how to get RCE? Yeah, me too!

This link has a list web shells in different languages. If you have no idea what the back end is using to execute code, just use this list. Hopefully one of them will work!

The Auth0 API ensures that the none JWT signature is not used (in order to ensure that an actual signature is used).

However, a case sensitivity issue was discovered! Using something like nonE would bypass the check.

This just makes me wonder: how many validations are out there using insure casing checks? Something to consider!

One of the greatest hacking articles I have ever read! This is true hacking to me. Just toying with Safari, understanding its perks and using these perks against itself.

There is no super major bug in this article. There are 8+ several subtle things. These subtle bugs chained together lead to an interesting compromise.

How was this research done? "Here's how I expect something to work... and Here's how it actually works. Ryan just plays with the parsing and generally how Safari works continually.

By exploiting very subtle bugs in parsing and Safari quirks (and having a great understanding of what was happening), he was able to make this possible.

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.