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 LFI (local file inclusion) allowed for any file to be easily included from the OS. This was trivially identified by a parameter which had a file name in it.

LFI's leading to RCE are quite common. So, always try to upgrade this!

Common ways to LFI listed are listed in the article... Here are a few:

1. Using file upload forms/functions
2. Using the PHP wrapper expect://command, php://file or php://filter
3. Using input from log files, mail or other controllable input.

However, none of these worked!

He realized that the session_id and user were being added to the sessions file for PHP (yes, sessions are held in a file called /var/lib/php5/session_[PHPSESSID]. Now, by calling this session file with a particular username lead to RCE!

Know how stuff works. pwn. profit.

Browsers can use custom URI schemes in order to call different apps. A good example is the common mailto: which will open a mail client.

The URI scheme for the WScript.exe passes user tainted input that is not escaped properly.

Using this, in combination with a directory traversal makes it possible to call any file on the OS :)

One thing that is really awesome is that the author explains and tags in other articles that helped them on their way. The article was looking for WSH injection into a VBS script. Eventually, a single script appeared to be vulnerable to this!

This vuln was a simple page being loaded within Microsoft Edge. Then, a custom URI allowed for RCE!

From a defensive standpoint: input validation is killer for attack vectors. Edge did not sanitize for single quotes, which made this attack possible. By making the input as tight to the needed characters as possible, this attack would have failed early on in the process.

AEM is a content management system from Adobe that is written in Java. This is made from blood, sweat and Java lol.

The AEM consists of three tiers: author, publish and dispatch. This different tiers have different filters that are unimportant (read the article to learn more).

For this vuln, the Publish tier admin resources should not be accessible via the Dispatch tier. However, the filter for 'glob' can be bypassed on the URL by adding HTTP query parameters in the URL! For example, files that end in .css should be accessible to the outside world. While https://Dispatch.example.org/system/console should not be accessible, this filter can be bypassed by adding a .css to the end of it, such as https://Dispatch.example.org/system/console?.css.

The Microsoft signout.live.com used the Adobe AEM on the back-end... This meant that the vulnerability above made stuff much more possible. At this point, an authentication page came up. What is the most obvious thing that you can try? Well, let's try admin : admin! This freaking worked!

By uploading an extension to this page, a very "lame" and easy RCE had been created.

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.