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!

JavaScript object are working on the prototype-based inheritance model. The prototype is a hierarchy where the object itself goes first, but then it's prototype is then checked, if a value cannot be found. For more on this, read the article linked or Mozilla docs.

The idea behind this vulnerability is to poison the prototype (of an object) in order to cause bad behavior to occur. In the past, prototype pollution has been used in NodeJS by object being parsed literally by the program (along with a merge operation) to cause crazy behavior in the program.

In this case, the author is attacking client-side HTML sanitizers. Because of this, we have complete control over the prototypes of objects.

The first parser (sanitize-html) is found to be vulnerable to prototype pollution by setting Object.prototype['*'] = ['onload']. By setting the * on the prototype (a check for all tags usable) will pass. Now, the onload attribute will be a valid tag! Also, this library was attempting to protect itself from prototype pollution but failed.

The second parser (xss) had a field called options which dictates what can and cannot be used. By polluting a field called whiteList by setting options.whiteList it is possible to set arbitrary tags/attributes for this field.

The third parer (dompurify) is very similar to the second parser issue. A field called ALLOWED_ATTR on an object was used in order to add more attributes than what should be allowed for an image. Now, when the parsing for the image takes place, the attributes were not removed because they were added to the prototype object.

The final victim (Closure by Google) has a custom format for specifying what is allowed and disallowed (which uses objects). By setting the prototypes of this object with the custom format to include src and onerror, it was trivial to get XSS.

The author created an automated way for finding prototype pollution methods for the HTML sanitization library! This can be found at pollute.js.

Although the author uses JavaScript in order to pollute the objects, this is STILL possible to trigger without JavaScript. In particular, insecure parsing of the JSON is often required.

Overall, great read that takes old research and brings it to be new again! :)

Adobe products are vastly complex! Because of this, they are riddled with security flaws. In this article (by a third party for a bug discovered by Mark Yason) in Adobe Reader.

Adobe Reader has a JavaScript interpretation engine itself. With EScript objects, associated with JavaScript objects, the data was stored in cache.

When this caching scheme is used, a data ESObject with the same PDDoc structure and name are reused from the cache.

The issue is that the ESObject pointer is freed, a pointer to it still exists in the cache. This creates a classic use after free (UAF) vulnerability.

The actual exploitation technique is only explained at a high level, but it is referred to as a classic method. At a VERY high level, it causes the garbage collection to free the object then uses the object again by accessing the cache. After this, the exploit is very down into the JS engine exploitation weeds.

Cisco Jabber is a video conferencing and instant messaging application used at many businesses. Jabber is built with Chromium Embedded Framework (CEF), which allows for embedded browsers to be put into the application.

The first vulnerability is a classic XSS bug. The application was using a deny list of bad attributes for custom style HTML. However, the list was not comprehensive and could be bypassed.

Although the CEF is in a sandbox, a way to escape this sandbox was identified. A function called CallCppFunction was noticed that calls an arbitrary executable on the system. By abusing this, and a built in file transfer feature, it was possible to execute arbitrary code on the system by XSS!

A vulnerability was discovered with several of the custom URI handlers. The protocol handler does not consider the case where a space is used. Because of this, we can inject arbitrary arguments into the binary, allowing for RCE on the CEF handling.

The next bug discovered was that SMB links were clickable within application. This is very bad because NTLM hashes will be sent to the user, allowing for the ability to learn the users password. This vulnerability can also be exploited by putting the link into an img tag instead of a clickable link.

Overall, several really good vulnerability classes here that demonstrate the importance of good Desktop security.

PPP is the Point-to-Point Daemon on Ubuntu (aka, a way to print).

The PPP makes an interesting target because 1) it is a setuid binary and 2) modprobe sometimes invokes the binary. Why is modprobe interesting?

The modprobe has ENV variables set for itself by setting MODPROBE_OPTIONS. The ENV variables not being reset have caused issues in the past, including CVE-2010-4170 and CVE-2017-0358. Because of this prior research, attacking PPP from the perspective of modprobe seemed like a good idea.

The MODPROBE_OPTIONS can be used in order to load an arbitrary kernel module, essentially spelling game over for the system.

What's the main takeaway? Specifically, not clearing out ENV variables when a new call is made is very dangerous. When running on a local system, ensure that ENV variables are used in a secure fashion.

A side-channel is a game over vulnerability when confidentiality is an important factor. For instance, if a nuke is going to be sent from Washington D.C., the amount of pizzas is D.C. increases because more people are working long nights from home. The pizza is not an issue with the confidentiality, but a result of something else (side-channel).

The most common side-channel in computer science is a timing attack. This is references to how much time an operation takes to occur. Some examples of these are the following:

• Fast failing comparison functions
• Cache-timing vulnerabilities
• Memory access patterns

Another common leakage, which requires physical access, is power usage. Different algorithms or operations require differing amounts of energy. Because of this, it is possible to leak secrets if the operations being done is known.

An additional side-channel is electromagnetic emissions. The computer gives off large amounts of electronic emissions, such as radio waves. Some of these emissions may leak information.

How do we prevent these attacks? For timing, this looks like having constant-time algorithms, or an algorithm that returns the data in the same exact amount of time every time. This article goes VERY deep into proper constant-time algorithms. Constant time math is not as simple as it seems.

For preventing power usage, it is very difficult to do and usually is just a bunch of obfuscation (instead of real security). An example of this is adding random operations of random time intervals to prevent any useful information from being gathered. Another way is to use different cryptographic algorithms, such as BearSSL using Montgomery Multiplication instead of square-and-multiply.

CGI (command gateway interface) is essentially an API, but differs in that it is meant for lower level operations. FastCGI and CGI are libraries in the Go language for the case of this article.

Differences between parsers can cause major issues when dealing with the security of an application. This is a well known fact! When it comes to HTTP, another example of this exists known as HTTP Request Smuggling.

When requesting something via the CGI directly, the default Content-Type (type of the file being sent) is NOT the png or anything else. Instead, it defaults to text/html. See where this is going?

Because the default type is set to text/html anything directly called by the CGI is now vulnerable to XSS, if the content can be controlled.

This is super interested because it is a XSS on ALL sites that use this functionality, not just a particular site!

GOG Galaxy is a video management software by GOG.

After installing the client, the author was looking at Wireshark packets to see what was happening. He noticed a file path within the Wireshark dump and thought this was interesting.

First, the author just replayed the original packet sent and the System command was ran. Upon modifying the payload, it did not work.

From reversing it, he noticed that the code was using an HMAC with a key on the local system. After finding out the key and the algorithm, the author was able to sign the payload and execute arbitrary commands. Because this was running as System (on Windows), it allowed for a very serious priv esc.

For the devs, secrets inside of executables are not secret!

Decoding protocols on the system in Wireshark is a good way to find issues; local traffic (on the machine) is rarely authenticated for third-party services.

Electron is a browser based development platform for Desktop applications. It uses NodeJs in order to program the entire thing. As such, being able to execute JavaScript in the context of the application means arbitrary NodeJs code and not just JavaScript.

While looking for XSS and HTML Injection, he found it pretty quickly (just added bold tags). However, with a clean CSP (Content Security Policy) all of the XSS payloads were blocked.

The CSP had a single flaw though: it allowed JS from all S3 buckets via a wildcard subdomain. This meant that JS was trivial to include by adding it to an S3 bucket.

After using another trick (iFrame src doc attribute to execute JS) the payload still did not work. The developers had done some odd changing of require to allow Angular to work in this context. Once figuring this out, a small change to the payload made RCE via a bad message possible.

However, this gets worse! The application had an open redirect vulnerability, even within the custom URI handler. By combining the open redirect (with the custom URI scheme) it was possible to have a single click of a URL lead to RCE.

How this would work was the following:

1. User clicks on link to custom URI
2. User (on the native application) is redirected via the open redirect
3. The newly loaded page uses the XSS to get RCE

Now, RCE has been achieved by clicking on a single link!

As a final note, the debugging was interesting too. Electron has devtools installed on the application, making source code very nice to read. In this case, the devtools had custom shortcuts though.

There are two types of requests, from the browser perspective: simple and preflights. Old school frameworks used to use the difference between these as a mechanism for CSRF protections on state changing actions.

The Play Framework used a blacklist on Content-Type on cross-origin requests in order to determine if the request was allowed or not. However, sending a valid request from the browser that was an invalid HTTP request, resulted in None being returned from the request for the Content-Type!

Although this was a very simple CSRF check, it looked to be solid, but was eventually defeated. To protect against CSRF attacks, add CSRF tokens to requests and make cookies Same-Site when possible.

There is a pretty trivial command injection within an administrative feature of the VPN. It simply passes a command into system.

At this point, you think the game would be over. However, Pulse Secure hooks into the System function to strip certain characters in order to make exploits MUCH more difficult to make.

As demonstrated by Orange Tsi on previous attacks, they used error messages to execute Perl code in the context of the website.

However, it was NOT possible to actual run malicious shell commands from the System call. Instead they outputted the error message to a cache of another Perl file.

Once the cached version of a file was called, the Perl Code was executed, resulting in code execution :)

Simple bug but complex exploitation!