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!

This has a really good guide on how to pivot within a network. Additionally, there is a very large amount of tools that are mentioned.

Although red teaming is not my cup of tea, still good to have some resources just in case I ever need something!

This has the greatest OSI description that I have ever seen. If I get confused on the OSI model, I just view this picture.

One of my favorite companies, especially because of the great research they do! ISE also runs IoT village at DFECON.

Good quote from the article: "When testing for OS command injection, I typically start with functionality that needs to interact with the operating system. This means that I will prioritize functionality that allows the owner to ping devices, enable/configure other services, or read/write files. Using this methodology we identified a ton of vulns".

When dealing with embedded devices that have deal with the operating system, there are a plethora of attack vectors!

Besides the command injection, ISE typically tries to make the command injection unauthenticated. In order to do this, Rick Ramigattie wanted to use a CSRF (cross-site request forgery) vulnerability to do this. Although this does require some user interaction this is still a very valid attack vector. But, a value was being stored in local storage that made this attack impossible.

So, Rick found XSS (cross-site scripting) in order to trigger the command injection with the local storage. I thought the methodology for finding the XSS was interesting: "When I test for reflected XSS I go through my sitemap and look for all requests that have parameters that end up in the server’s response. Then, I manually go through each of the requests in that subset and look for requests that end up in the server’s response without modification".

Overall, this was a really good article with great insights! Well worth the read!

Most of the time, the mathematics behind crypto is fine; the issues come from the implementation and the usage. This article talks about instances of bad implementation in cryptographic software.

Heartbleed (bad memcpy) in TLS lead to RCE/memory leaks.

Apple poorly written code that did NO certificate validation.

WD self-encrypting drives used a fixed salt and a fixed number of iterations. This made the implementation susceptible to pre-computed hash tables in order to find the key with brute forcing. Additionally, the random number generator itself was not cryptographically secure.

Misconfigurations, such as using SSLv2 on TLS configurations. Security is only as strong as its weakest link!

There are other articles in how crypto has failed us within this article; feel free to read more! :)

The auth bypass was actually quite simple...a particular code path creates a valid session without requiring previous authentication.

This can be used in order to create an administrative session by adding a cookie: username=admin. This has then created a complete administrative and authorization bypass.

Why did this happen? Likely because the same code path was not used for all pieces of authorization. Modularity is quite important in terms of security! If authorization is implemented 10 different ways, it is very unlikely that all of them were done correctly.

Essentially, this pentester had an SQL injection but could not exploit it as all commas were replaced by some other character (breaking the query).

In order to extract data without the comma, some funky stuff had to be done. Character encoding are soooo weird!

The goal was to find a comma that would not be converted by the application but that the Oracle database would still use. After a couple of different comma-like characters, the full-width-comma worked as expected.

Blind XSS is when there is an XSS vulnerability that cannot be easily seen by the attacker. A good example of this is finding stored XSS in logging on the Administrative panel.

XSS Hunter is a really cool tool that allows for Blind XSS to be found!

After finding the blind XSS, user impersonation by stealing session cookies was found :)

When looking for bugs, keep searching! Sometimes, bugs are complicated and take a long time to find.

A pointer is created; but, only when going down certain paths. But, the value is still used later on! So, it is possible to send a request that goes around the switch statements creation of the pointer. From here, the out of bounds write can be turned into an RCE.

The other two vulns are created because no bounds check is done while writing data.

Additional article with a subtle vuln: off by one. This is not the most exploitable thing but could be the entry point into deeper memory corruption bugs.

What is an iFrame Buster: "iFrame Busters are HTML files hosted on publisher sites which allow ad creatives to extend outside of their standard boundaries".

Essentially, ads are creating XSS vulns in sites. These iFrames Busters used regex's to validate that only a proper domain was allowed. But, these regex's could be abused.

The XSS is created by allowing any site to load scripts.

Most of the vulnerabilities come from a bad whitelist regex function.

The last vulnerability in here described is pretty clever! He double encodes the URL to escape the check for periods, how to access files. Further, he uses the # sign at the end to negate the rest of the payload. Clever!

Hardware security is almost an impossible thing to do. In principle, the problem is trying to keep someone who has the physical device from doing stuff on it... This is such a hard problem!

This pdf is one of the very few pieces of research done on the Apple Secure Enclave :). Understanding hardware security is fascinating!