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!

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.

There are 12 extremely serious bugs that are mentioned (all critical). So, sit back, relax and enjoy findings from all of the Apple platforms!

First, a complete authentication bypass was discovered on the Apple Distinguished Educators site, which used a Jive forum to work.

This bypass was done because a custom password value (###INvALID#%!3) which was imbedded in the page, was used to determine if this was a new user or not. If this was a new user, then the sigin-with-apple account would be linked to this account, resulting in an authorization bypass with all accounts that had no registered on the site.

After this, they wanted to get admin access to the Jive console. The URL admin/ had a deny list on it. However simply adding a semi-colon (/admin;/) to the URL would make it possible to go to the Jive admin console.

The next bug was an authorization bypass of the manufacturing and distribution site that Apple used. At first, there is nothing interesting because you need credentials to login; otherwise, you are just redirected back. However, there is a special case where an authenticated user needs to access site functionality: password reset.

The password reset functionality gave a user the account name Apple No Password User. Using these credentials, it was possible to use the OAuth endpoint in order to generate a Bearer token to use the rest of the site! After reversing the APIs, they had full access to the site.

iCloud has an email client that you can use! The next vulnerability was a stored XSS via bad sanitization and altering of tags. Using this, there was an easy stored XSS (via email) that could be used to steal all iCloud information.

What are other good targets for findings XSS? Hyperlinks are typically translated into actual links, within the web browser with anchor tags. However, doing this properly is extremely difficult to properly. So, the author found a way to break out of this with weird parsing to get XSS.

The next bug is a simple command injection within the ePublisher functionality. This was found because of an error message that was returned that looked suspiciously like CLI output. From there, they add || test123 and recieved the error message /bin/sh: 1: test123: not found to make this fully known to be command injection.

With iCloud and the Open in Pages functionality, the URl was sending a request to a allowed-listed domain on the internal network. However, adding the @ourdomain.com, resulting in the first part of the URL appearing to be a username.

Using then bug, a SSRF vulnerability could be used in order to exfiltrate the returned data from Apple, including the source code for iOS and other things.

Another bug was providing by messages to a particular API gave back extremely verbose error messages that included authorization tokens. Using these authorization tokens, parts of some applications could be visited.

Within Apple Books, they found two interesting bugs. First, a trivial XSS on the book title (no need to talk about this more). Secondly, a noticed that screenshots were being taken of HTML of books in an S3 bucket. By assumption, they assumed this MUST be using PhantomJS to do this.

Because PhantomJS was being used, they added JS XSS payloads into the HTML in order to perform SSRF on the internal network. Because this was running in AWS, they could use the SSRF to steal arbitrary data from the S3 bucket and some AWS temporary creds.

Next, a SpringBoot (eSign) application exposed the actuator/heapdump endpoint, which allowed for a complete compromise of the application. This dump (a .db file) had valid session tokens for Apple employees! This gave them access to 50+ new application endpoints on the site.

XXE (no response) into a blind SSRF was another bug.

An SQLi was found in the GBI Vertica endpoint. This endpoint was created custom SQL queries, with the ability to control most parts of a query. Although Vertica was trying to prevent SQLi, it was trivial to escape the queries and return arbitrary data. The only thing was bypassing the restrictions of the keywords with /**/ constants

A BUNCH of IDORs were discovered on various applications, including one in FindMyFriends.

Overall, this shows a few important things:

• All things are hackable. Just spend the time, put in the effort and you will find vulns
• Apple has a high security-by-obscurity by restricting access as much as possible, which can give the illusion of security. However, these findings prove this does NOT work.
• XSS is still hard to prevent in complicated applications
• Error messages are really valuable for recon and info disclosure
• Recon is incredibly important! Take the time to understand the infrastructure and find all of the targets