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!

Web caching poisoning was thought to be a theoretical issue until recently when James Kettle published some awesome research. The basics of caching are that data that has already been sent out to other users should simply be stored somewhere instead of regenerating the request.

This creates a tricky problem though; how do we know what is the same? This is done via key and value matches on parts of the request. The idea behind the attack is to confuse the keying to cache something that should not be cached. This article goes into attacking many open source libraries for cache poisoning.

The first issue was GET parameter cloaking. Using a semi-colon (;) to separate out queries (I didn't know this was a thing!?), the cache can get confused and not realize this is a separator. Because of this, the cache will save an item that should NOT be saved.

Using this technique, we can control a usually keyed parameter to be sent back to other users. This vulnerability was found in Bottle, Tornado and Rack because of a parsing bug in parse_qsl for Python. Additionally, Ruby on Rails suffered from the same issue, as well. The remediation is to NOT parse the semi-colon as a separator (this is deprecated anyway).

The next issue was labeled FATGet parameters. Typically, GET parameters are passed in the query string of the URL. However, the HTTP specification allows for GET parameters to be in the body of the request. If the cache uses the URLparameters but the backend uses the body parameters then a difference can be created.

Using this difference, we can save a request in the cache using the GET parameters but get a different response from the body parameters. Now, the cache is poisoned with improper data. This issue was found when NGINX was used with Tornado.

The final issue described is that arbitrary parameters can be injected into the request because they are NOT keyed. Although this is not a vulnerability by itself, using this with the proper gadgets can lead to some interesting affects. For example, adding the _method to a request in Flask could change the request method being used to a user.

Because cache poisoning is becoming more and more accessible, I feel that normally unexploitable XSS (such as in a reflected POST request) should be considered higher impact with this idea in mind. These are some good methods for cache poisoning that are library specific; I wonder what other bugs exist in libraries?

Different technologies have different threat models, depending on the usage and sensitivity. In most scenarios, forcing a connection is not a huge deal. However, in the world of phones, being able to force audio or video on a call serious breach of privacy.

Most of the cellular phone apps used for Real Time Communication (RTC) use the standard WebRTC, such as Signal, WhatsUp and many more. Using WebRTC for calls and video works well but can be still be hit by security issues. WebRTC makes the app creators store an internal state for the user, such as consent for a call.

In Signal, the logic of the application did not check if the user accepting the call was the user callee. Because of this, an attacking user of the application could go through the routine for a call then force accept the connection for the user. By the way, Signal is on Github!

The second issue was found in both Jiochat & Mocha. Both of these applications attempted to make the transition from accepting the call and being on the call faster. In order to do this, they used a non-WebRTC client in order to handle this and pre-establish the connection. At this point, the only thing missing was a candidate (user to connect to). Once this was added, the call would be accepted.

With WebRTC, the candidate can be established on the initial connection. Because this was not the expected workflow, the WebRTC client had not implemented any logic for this! So, a phone could automatically be connected to just by sending the candidate object in the WebRTC call.

With Google Duo, it suffered from a race condition on the startup process. Upon making a connection, the application tells the state machine to not allow video/audio (since they have not consented to it). However, because call is done asynchronously, a few video frames could be sent prior to the state machine updating.

The author took 2 weeks in order to figure out a way to win the race. Eventually, she figured out that by adding multiple candidates to the connection (multiple ways to send data) and sending many messages at a time, the race could be won to get a few frames of data.

At the end of this, the author makes a point about asynchronous call issues: "However, asynchronous calls make it more difficult to model how a state machine will behave in all situations, so it is important to be cautious about adding asynchronous calls to WebRTC signalling."

Facebook Messenger was an entirely different beast! All of the previous apps had Java bindings (which decompiles nicely) but Messenger used C++ binding with a statically linked & stripped library. A good section of the article is just about reversing the messaging app itself.

The author noticed that when a track connection is added, it is put into an inactive state immediately, prior to the call being answered. There are some really nice diagrams on how all of these connections work too.

Several of the messages to this are completely ignored but some are processed, such as SdpUpdate. This was a feature that is called when a second device (phone and laptop) are both connecting to the call. Using this functionality, it is possible to force a connection!

Overall, state handling is hard. Memory corruption bugs are awesome and have universal patterns; hence, they sometimes require a lesser understanding of the system. These logic bugs require a very deep understanding of the ecosystem, but are fruitful once it is understood.

The vulnerability is a NULL pointer dereference because of an assumption being made by the object being passed in. Essentially, the object expects for a particular type of handler to be there but does NOT require this. Without any validation the handler can be set to NULL to trigger a jump to address 0.

Is this exploitable? It is a NULL pointer dereference after all. That is where the fun begins! In Windows, the NULL address is actually mapped for 16-bit processes under the NTVDM subsystem, which is only available on 32-bit. So, it IS possible to execute code from there!

Well, kind of. Modern operating systems have a protection that separates kernel code vs. userland code. This means that even if we could map something to 0 directly in userland (with the situation above), the SMEP protection would crash if the kernel jumped to this point.

Apparently, the author disabled SMEP and installed the NTVDM subsystem in order to verify that this exploit worked. Although this requires a very convoluted scenario, it is still possible to pull of!

When creating an account with an email, it is common practice to verify the email by sending an email to this user. In some functionality, it is common for applications to give specific access depending on the email being used, such as Slack workspaces.

What if you could break the parsing of the email verification? You could get credentials for something complicated! The application being tested used AWS Simple Email Service (SES) in order to send verification details but verified the domain using something else.

After a bunch of tests, the author came up with an input that worked (after a BUNCH of tests) differently on the two services: <aaa@bbb.com>ccc@ddd.com. AWS SES sends the message to the aaa@bbb.com but website used ddd.com as the domain for verification!

Using this discrepancy in the parsing, an email can be sent to one domain, but verified at another. This allows a bypass in the domain verification on the site.

After finding this one vulnerability, the author decided to look at a plethora of different email address parsing libraries to see which combinations would be vulnerability. From combinations of Python to PHP to NodeJS, the author found one other combination that was vulnerable and two that might be.

This is another classic discrepancy between two parsers leading to a security issue. This never gets old to read about!

The SameSite cookie flag is a protection meant to protect users against CSRF at the browser-level instead of the server-side level. This cookie flag that only parties from the first-domain (google.com to google.com) can send cookies off.

Recently (beginning of 2020), browsers have decided to have the SameSite cookie attribute to default to Lax (instead of None) in order to try to kill off the CSRF attack. But, with one special quirk...

Cookies set within the last two minutes without the SameSite flag will NOT abide by this rule. This is in order to give developers time to fix the login flows on a bulk of websites while limiting the damage greatly.

The author mentions this functionality, named LAX + POST, is temporary. But, as of January of 2021, it appears that nothing has changed.

Sudo is a setuid program that allows a user to execute commands as another user (impersonation feature). Because of this, finding a vulnerability in sudo is an important privilege escalation.

When running sudo with the -s or -i flag, turns on functionality that rewrites argv by concatenating all command-line arguments and by escaping all meta-characters with backslashes. Parsing is really hard!

When this transferring and escaping happens, is where the parsing issues occur. If a command line input ends with a single backslash, then issues happen with the copying functionality. It causes the while loop to over deviate because of an unexpected increase in the buffer. In other words, set_cmnd() is vulnerable to a heap-based buffer overflow, because the out-of-bounds characters that are copied to the "user_args" buffer were not included in its size.

Here is the problem though: it is not possible to call this function with a single backslash, by default. By calling sudoedit, the escape code can be skipped, causing the vulnerable path to hit. An example crashing exploit looks like the sudoedit -s '\' `perl -e 'print "A" x 65536'`. This hits iterates once too many, then copies extra data from the heap.

To an attacker, this buffer overflow is awesome because

• The size of the "user_args" buffer that we overflow, which is just the size of our concatenated command line arguments.
• Independently control the size and contents of the overflow itself. Our last command-line argument is conveniently followed by our first environment variables.
• Even write null bytes to the buffer that we overflow (every command-line argument or environment variable that ends with a single backslash writes a null byte to user_args.

The original idea for exploitation was to corrupt locale strings in order to turn this into a format string exploit. This is a common exploitation for sudo and other binaries with locales used. However, this technique did not produce any good results.

After setting up a fuzzer to find different exploitation primitives, a few ways were found that caused crashes with the proper heap grooming.

The first interesting crash was a direct overwrite of a function pointer within process_hooks_getenv . The main thing to note was that the function pointer could be partially overwritten in order to bypass ASLR.

The second exploitation method was found by a crash in nss_load_library. Using this crash, it was possible to overwrite the file path of the library being loaded to load an arbitrary library.

The final way they found to exploit this was different than all of the others. From the fuzzing, they noticed that a bunch of directories were created with root privileges by overwriting the location of the def_timestampdir. Using this, we can overwrite this directory then we can race against Sudo's ts_mkdirs(), create a symlink to an arbitrary file and (or create) this arbitrary file as root, and write a struct timestamp_entry to it.

Using this timestamp writing functionality, we can open /etc/passwd and write a user into this. Now, we can use sudo and become root.

PDFs are all over the internet, created without much effort and parsed everywhere. Does this have any security issues?

The first classification of attacks is denial of service (DoS). Within PDFs set of supported languages (JavaScript, etc.) infinite loops can be created. Additionally, this a classic compression expansion technique (like a zip bomb) can be done with the deflate command.

Using built in features of PDFs, data may be stolen. First, forms being filled out (by the user) can send the data off silently, exfiltrating the data. Calling home also leaks the IP address of the user, which is a privacy issue.

The others are very theoretical and are specific to implementation, such as parsing issues with files. I did not find this part of the article very useful.

The go get downloads and builds a package that contains import "C". With CLI tools, it is the goal of most systems (including Go) to limit code execution via commands being ran.

A bug in the package handling process allowed for setting the current directory to check for gcc when building the library. Because this occurs, we can control what gets executed! This means that running the go get command can run arbitrary code on downloading.

So, what is the fix? They came up with two of them. The first solution was to pass the full path of the GCC compiler instead of a just a command. The second fix was to remove the ability to execute a command based upon the PATH variable having . inside of it.

Handlebars is a server-side rendering tool for web services that is commonly used. NodeJS is a backend server that can be written in JavaScript.

The handlebar commonly accepts a load of JavaScript in order to remove the templating and add explicit values. However, one of these files allows for the controlling of an arbitrary file name, but not the extension. Using this, data could be exfiltrated from the system from handlebars.

Because of the template injection in handlebars, it would be possible to get the templating engine to execute arbitrary code. Using this, it is possible to get RCE with older versions of handlebars.

An additional threat to this attack is prototype pollution of the layout option itself. So, fixing this vulnerability requires help from the developers of handlebars and the developers of individual applications to cooperate too.

Mautic is an open source, widely used open source software for marketing automation. Mautic allows for unauthenticated users to use most functionality, which adds some attack surface.

The first bug was an XSS found in the Referer header, which was then shown to authenticated users. This was done by generating data from a malicious marketing lead.

With the XSS, when an authenticated user visited the site, the attacker controlled their account. The authors decided to make an admin user via the XSS.

As an administrative user, the attackers could upload a custom theme to the CMS to get code execution. Although this is NOT a vulnerability by itself, it does help in the exploitation process.