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!

James Forshaw showed techniques that abuse NTFS Junctions and Symbolic links to escalate privileges back in 2015. Since then, using this has became an extremely popular method for hacking Windows clients.

The client (running as SYSTEM) writes a log file to C:\ProgramData\Hotspot Shield\logs. However, this location can be altered by any user! So, what does this mean? Arbitrary write to any file, using the log file!

To exploit this, the following must be done:

1. Delete all of the files in the logs folder.
2. Create an NTFS Junction (soft link) to \RPCCONTROL object directory.
3. Create a symbolic link between \RPCCONTROL\ and any destination file.

Although, because these are log files, this only results in a DoS because the content of the logs is not trivial to control to gain code execution. Still though, good find and explanation of the Windows bug that keeps on giving!

Security audits for websites are becoming more and more normal as security becomes a must-have for companies. However, the average person cannot afford a pentesting firm. So, they use freelancers.

The author of this article paid 7 people to test the same website which had two MAJOR vulnerabilities (auth bypass to admin and SQLi/hardcoded password on the login). What were the results?

The bulk of the testers (at different prices), just ran Nessus or some other automated security tool on the site. With this, very little was found. Out of the 7 testers, each bug was discovered and successfully reported ONCE. What does this tell you?

Hire professionals and people who know what they are doing. If you pay $50 for a security audit, expect to get a Nessus scan.

Arbitrary redirects are an interesting vulnerability class. The reason for this is that the impact is typically minimal (some bug bounties do not even accept this bug class) but can be immensely impactful in other situations.

In an interesting case, the url_for function in Ruby On Rails was accepting arbitrary parameters to it. Although this does not sound like a big deal, controlling the settings of a function can cause many issues!

To start with, a low-severity reflected XSS was found by setting the script_name field of the url_for function. This XSS required 2 clicks and the CSP blocked it. So the author decided to look for more.

By adding the script_name with just a domain, an arbitrary redirect was achieved. Although this seemed nice, what can be done with this?

When are arbitrary redirects really bad? OAuth! This exact vulnerability affected the Github Gist OAuth implementation. With the redirect, if a user clicked on a malicious link, it would be possible for them to login then be redirected to the malicious actors site. Now, with the redirect, the auth code would just be sitting on the bad actors site, waiting to be used.

Overall, this was a super interesting bug that was ONLY found because of source code review. I love the finding and would like to see more application bugs like this in the future.

Vakzz has MANY great writeups on his site; I highly recommend visiting this site for high quality writeups.

Github pages is a static site hosting platform via Github Enterprises. The creation process of these sites was interesting though!

The YAML parsers of the configuration used Kramdown. After reviewing the source code for Kramdown, the author noticed several interesting paths...

First, a path allowed for the loading of arbitrary files into Ruby. Additionally, it did not protect against directory traversal! So, if he could find a controllable file, the author could have an easy RCE. By adding a site (which was put into the tmp directory briefly) the author could execute arbitrary code.

Secondly, another path was found...this path allowed for the arbitrary loading of top-level Ruby objects, as well as controlling the first parameter. Using a brute force script to find all loadable objects, another arbitrary require was found! The two bugs used the same file read to get the payload to execute.

In order to get the file to stay around for longer, the author created a VERY large file so that the race could be won.

Usually, RCEs are a command injection or some type of memory corruption. In this case, it was an arbitrary file include! I find these bugs fairly interesting; they are definitely something that I had never thought of before!

Symfony is a PHP framework with many built-in features. Symfony is used in many popular PHP based products, such as Drupal, Joomla and others.

The framework allows for Edge Side Includes (ESI) on the /_fragment. However, this particular endpoint allows for only PART of the page to be executed and is customizable. So, this endpoint essentially accepts a GET parameter that is PHP code!

Fortunately (for the defense), this value has to be signed with an HMAC value in order to be executed. Additionally, this secret value is used for CSRF tokens and remember-me tokens as well.

Of course, finding a vulnerability that would allow for the reading of the secret would be nice. In some versions, the phpinfo page (if not disabled) will actually show all ENV variables, including the secret value. Additionally, a remote file inclusion bug would be nice to steal the secret value. In the real world, actual vulnerabilities have to be found in order to do the ones found above. However, there are two other avenues!

The first avenue is default values. In versions of Bolt CMS, EZPlatform and others, there is a default value that MUST be changed by the web administrator.

Secondly, the secret value can be brute forced offline.

Overall, having an endpoint exposed that can allow for arbitrary code execution is less than ideal, even if the value is signed in some way.

JavaScript Objects have a base type, known as the prototype. If part of the prototype can be overwritten, then it may result in the ability to bypass normal security operations.

This tool does scanning for prototype pollutions.

Discord is an extremely popular chat application using in gaming, but is starting to grow into other industries. The Desktop application uses Electron, a cross-platform JavaScript and Chromium based project.

Because the WHOLE thing is built on top of JavaScript and NodeJS, the consequences of XSS (JavaScript injection into the application) go from bad to RCE pretty quickly. This lack of isolation can be exploited in many ways, which is discussed in this write up.

There are two main settings that dictate if integration should be allowed in JS: nodeIntegration and contextIsolation. In this case, nodeIntregration was off (safe setting) and contextIsolation was off (unsafe setting). While the author could not directly call nodejs functionality for RCE, there was a work around!

With contextIsolation disabled, a web page's JavaScript can affect the execution of the internal JavaScript code renderer! So, still a chance for RCE! :) A few called out items were Electron Preload Scripts and other functions with the Electron app.

With the sandbox escape out of the way, how about an XSS? Using the built-in Markdown functionality, it was possible to load in content from a strict list of URLs into an iFrame. So, XSS on these URLs means XSS on the Discord app! From two of these URLs, the author found XSS.

Game over right? Well, because the content was in an iFrame and the content SHOULD be restricted by Electron. However, even though there was a check for going up to the next window, it still worked! This resulted in a CVE for Electron itself, oddly enough.

Overall, fairly good write up! It is always awesome to see so many bugs chained together, especially when a 0-day in a popular kit is found.

Cloudtrail is the AWS service that logs access to all AWS services, in particular it can log authentication and authorization events.

By using an errored request with specific APIs on AWS, it is possible to map out all access on the account (with a given set of credentials).

This is done by sending a malformed request where one of two things happens: the user is denied or a 400 error occurs. The best part, is that because this is considered an invalid request, it is not logged on Cloudtrail. Hence, a malicious actor could do this to enumerate the access they have (and resources in the account), without it being logged.

AWS considered this to be a non-issue. However, taking a defense-in-depth approach by mitigating this would exploitation even harder. Going forward, I can see this being big in AWS env exploitation.

Most of the time, computers run deterministically with what you tell them. But, what could happen if we could change how this ran?

Mobile device management (MDM) is used for administration of mobile devices. A bypass for an MDM on a phone would allow for the stealing of phones, even with the MDM installed.

Using electromagnetic (non-invasive) it was possible to glitch the phone! Even though this was IMPOSSIBLE to figure when and what was going to crash, sometimes, all we want is a crash.

With a debugging trap set on the phone (in hardware), all that was needed was a specific type of crash and the MDM could be whipped. To perform this glitching, a simple lighter was used. The original post was taken down. Here's a wayback link: here.

SalesForce Lightning is a Customer Relationship Manager or CRM. There are many pieces of software that require a substantial amount of setup and customization for organizations; SalesForce Lightning falls into that category.

Although the author does not find a particular issue WITH SalesForce Lightning itself, he discusses way to attack open SalesForce instances that are running in the wild. This can be VERY useful for a network assessment or bug bounty programs.