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!

Templating engines are used to embed dynamic content into web pages and emails. Template injection occurs when user input is embedded in a template in an unsafe manner.

The templating is a vulnerability that can easily be overlooked as a poor XSS vulnerability. SSTI is essentially server-side template injection inside a sandbox.

There are two distinct contexts: plaintext (inject directly into HTML) and code context (placed within a template statement as a variable name). Both of these being used incorrectly can lead to XSS and/or RCE.

The first aspect is figuring out which template engine is being used (identify). The article has a flow chart to figure out which engine is being used.

The second part of this is exploitation. The article shows several steps to to attacking: reading, exploring and attacking.

Read: Each language and templating engine has many complex built in functions, leading to many possible outcomes. So, understanding the template injection and reading the documentation on this is very important. This includes basic syntax, security considerations, builtin methods and plugins.

Explore: Explore the environment that is being used on the application. What is in the namespace? What objects are available?

Attack: Understand the application as a whole and proceed to normal exploitation techniques.

There are several cases of applications being exploited within this application. I always enjoy the real world exploitation within the Portswigger articles!

Interrupters are IMPOSSIBLE to do correctly... Anytime there is an interrupter go after it!

EL (expression language) is used for creating templates for several frameworks. In this situation, the HubL EL was being used in the HubSpot Customer Relationship Manager (CRM).

The classic example is {7*7} evaluating to 49. By abusing the templating engine (which is in Java), specific functions in Java could be called that lead to a complete compromise of the system. Although, calling Java in this restricted context is very complex...

I was super impressed with the reverse engineering that allowed this to be possible! Lots of reading from the JinJava project, as well as just general Java knowledge.

Here is the final payload: {{'a'.getClass().forName('javax.script.ScriptEngineManager') .newInstance().getEngineByName('JavaScript').eval(\"var x=new java.lang.ProcessBuilder; x.command(\\\"netstat\\\"); org.apache.commons.io.IOUtils.toString(x.start().getInputStream())\")}}

Fragmentation is necessary for data transmission from each and every network.

By abusing the way that TCP and UDP fragment data works, the resources of a web server could be consumed. This creates a denial of service (DoS) attack.

.git holds all of the information about the version control of a Git repo. Because of the period (.) in the directory name, it is commonly missed (such as ls -l command will not find this). These can be used to completely recreate the source code of the application!

Some web servers, such as Apache, will then show all of the contents of that directory to the rest of the world!

By putting these all together, downloading .git repo from a site can allow for a complete reconstruction of the source code.

When I tried searching for the .git file in Google a significant amount of repos were vulnerable to this attack.

It should be noted that the article has all commands to perform this attack. However, the .git reset takes a fair amount of time to do.

The authentication on the site uses a SAML based model.

During the digital signature check on the application, it uses the first parameter even though multiple can be specified.

This creates a HTTP Parameter Poising vulnerability that can bypass security features.

ProtonMail claims of perfect end to end encryption for the ProtonMail app An article was released disputing this claim.

The argument is that because the browser could be compromised that the encryption keys could be discovered... Although this is true, this situation is very, very unlikely.

This Reddit link is hilarious though. After posting this article, ProtonMail officially comments on this paper in the Reddit thread! I thought this was absolutely hilarious. Feel free to read through the thread.

Although XSS is super common, there is an infinite amount of ways to trigger it!

Copying and pasting payloads into forms is good for a while but not that great to get a pHD in XSS.

The base tag is used for the base of a URL. However, JavaScript URI's cannot be in the URI. This needs to look like a normal URL but still execute the JS (// looks like a comment). This can be bypassed by either using a multi line comment or a regex.

Gareth Heyes, from Portswigger, demonstrates a parsing bug in Safari that looks like it makes zero sense...Just abusing the parser and understanding of the browser.

Good hacking can be found by a deep understanding of something with a large amount of creativity.

A great overall description of heap memory corruption!

The main memory corruptions:

1. Freeing pointer that from malloc
2. Double free (freeing a pointer twice)
3. Use After Free
4. Heap Overflow

Interesting notes about malloc... If the MALLOC_CHECK_ is turned on then it will detect all double free errors. Additionally, malloc cannot detect trivial use-after-free and out-of-bounds bugs.

The reason for the name electric fence is that this is a tool to held find memory corruption bugs. This tool works by replacing malloc, free and related functions with special debugging versions of them.

Besides this tool, there is also Valgrind, DynamoRIO and Pin.

A Dangling Pointer is a pointer that a selected pointer has either been deallocated or is invalid altogether.

This article dives into what a dangling pointer is and how to exploit it in multiple scenarios.

Across several subdomains a single authorization token is used. So, the team tried finding an XSS bug within one of the subdomains that did not have the HTTPOnly protections turned on.

The XSS bug is a reflected XSS bug within the JavaScript in the page. Because of this, 'this kind of XSS would not be blocked by any XSS Auditor because it resides in the JavaScript itself and not consist of scripts or events'. I thought this was super interesting! What is actually blocked from the XSS auditor?

The mobile application had many debugging and reversing protections. Using Frida, among other things, did not work. It was discovered that the app actually spawned a process that had Frida already attached to it, making is impossible to add another process to it. To bypass the SSL pinning, they had to overload SSLContext and hook a different trust manager.

After getting the MCK (metadata-key) token from the XSS the login process can be hijacked by replacing the MCK in the login request with the stolen one.