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!

The OAuth handler for the Playstation network uses postMessage across websites to send the OAuth data.

The chosen window to send this to has some poor logic in it though. The Window option sends the message to the window.opener and does NOT validate the domain at all.

So, by opening up the OAuth handler on a malicious site, the OAuth code would be sent to the malicious site via postMessage!

Although this appears to be a very weird bug, understanding how the website works and thinking of interesting attack scenarios never gets old.

Elastic Objects are coined in this paper as objects that can have unlimited size. Why is this important? Altering sizes can be super useful for exploit development.

The first part of the paper figures out candidate fields to figure out if something is an Elastic Object. Then, profiles the type of cache it uses and so on. Eventually, they use constraint solving in order to figure out if an elastic object could be altered by some previous vulnerability.

At first, when I heard about this paper, I thought it was all about finding buffers with a dynamic size in order to target these for buffer overflows. However, this is something that is quite a bit different than that!

Heap objects with an infinite amount of size are incredibly useful for exploit development. In this case, the paper focused on bypassing KASLR and leaking stack/heap canaries. By altering these elastic objects, it can be useful for exploit development.

How to mitigate against this type of exploitation? The authors mention putting these types of objects into their own section. This is coined as shadow cache.

According to their site, SaltStack infrastructure automation software is used by IT, network, and security operations teams to drive security and reliability for digital business." So, finding a vulnerability in Saltstack could do real damage to a company.

The vulnerability is a simple command injection into an shell-spawning command. The interesting note was that the Saltstack APIs were verifying that data was sanitized. However, a few parameters were not being properly sanitized, which led to the vulnerability.

Additionally, this vulnerability was triggerable from an unauthenticated context. Another thing to note was that this vulnerability was not in a default configuration; an administrator had to turn this configuration on.

This was assigned TWO CVEs. One for the improper sanitization and the other for having the system spawn a shell when executing these commands. In languages like Java, the shell command is not usually injectable because the input is parameterized (like SQL queries). Apparently, this was running in a non-parametrized context; so, they made this fix for the CVE.

First, the developers attempted to do Basic HTTP Authentication on the website. However, because of a default password & the lack of HTTPs, this made the authentication not the most useful.

The author reversed the update mechanism of the device. It appears to take a connection on some port (over authenticated HTTP) and update the device. With some fiddling, anybody on the local network can update the device! Although this is 'RCE', what can we actually do post exploitation?

Edit the file /mnt/mtd/etc/start.sh with the firmware update in order to change the flow of execution.

In terms of reversing, the article goes into using networking tools and basic disassembly. The process for reversing and getting these mechanisms to work can be tedious and difficult. But, at the end of the day, this is where the real fruit is at! There is nothing truly new in this article but the reversing methodology is interesting.

This software will not be getting patched and now bug bounty is being rewarded for this. Honestly, IBM does not seem like a good company to do bug bounties for. They never seem to give out bounties when they should be rewarded for patch old software.

There was a feature that was labeled Bypass Logon, gives only limited functionality. This just looks like something good to attack! By patching the client for the admin functionality, it was possible to just use the app for all other normal admin calls. Client-side defense is never enough...

The rest of the article discusses a buffer overflow in a command line program, but is not triggerable remotely. Considering the program did not have Nx, ASLR or any binary protections, pwnage with a single memory corruption is quite likely.

This author is a SINGLE GUY who writes a bunch of awesome articles. If you have some free time, just go through this guys blog for a while.

Uses power consumption APIs on Intel RAPLs and AMD on a local machine in order to distinguish between instructions and memory loads. This allows for leakage of cryptographic keys, breaks KASLR and leaks other important bits of information.

For finding encryption keys, this takes a bunch of complicated mathematics. A bunch of data is encrypted, where the consumption of power is taken from the system for the given instruction. Based upon the power consumption (over lots of traces), this estimated power consumption can be used in order to figure the key.

For breaking KASLR, this attack uses a low memory consumption with the physical memory address of the kernel is actually accessed. While, with non-mapped memory will take longer to access, as it is not cached. This one is actually simple.

To mitigate this attack, Linux takes away the ability to access power consumption APIs from non-privileged users. Additionally, Intel released a Microcode patch to prevent this distinguishing of data to occur.

The post claims that AMD has the same issues but has not responded back to the researchers or fixed anything.

This is an interesting article about how people discover flaws within protocols in Cryptography. However, this article can be used for other types of bug finding.

To find bugs, meaningful engagement is required. What does this actually mean? Put in the effort!

The first claim is to write a proof. While writing a proof for the paper, some prevalent issues may appear that compromise the security of the system. This worked for an attacker on the Zcash cryptocurrency system.

What if there already is a proof? Then understand the proof and write one for yourself. This worked for an analysis of RSA-OAEP to find a bug and again for forgery an authenticated encryption scheme called OCB2.

What is next? Formal verification. This is defined as "In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics." - Wikipedia

This technique is a programmatic way to verify the soundness of an algorithms implementation. But, now what?

Sometimes, the integration between two points is the issue. This can be seen with the KRACK exploit on WPA WiFi networks. This is essentially just a trivial replay attack that was not considered previously.

Finally, implementing the protocol can allow people to discover their own bugs. For instance, a vulnerability in Zcash was discovered prior to releasing from exactly this. As a side note, this is an interesting article so it should be read!

Finding bugs is difficult. It requires a deep understanding of the system being worked with. Above are some ideas for attacking cryptography systems.

Web Scrappers are all over the internet working for search engines to discover content. However, a problem has came up some the JavaScript revolution: how does the search engine know the contents of the page if it is not static? In reality, the web scrappers will run the JavaScript in order to show the content to the Web Scrappers.

Some people have taken this to the next level though. Instead of allowing the Web Scrappers to be trusted with rendering the content in JavaScript, there is a way to dynamically render this content for yourself, then give it to the Web Scrapper. This control allows for Web Scrappers seeing exactly what the author wants it to see.

There are two common frameworks for this: Rendertron and Pre Render.

The first step is identifying if one of these engines is being used. This can be done by setting the User Agent header on a Curl request to be a bot. If the HTML sent back it pretty with NO script tags, then you have found something that is pre-rendering the content. Additionally, extra response headers are sent back to indicate the rendering are being used.

With Rendertron, there is a very nice page that allows for a trivial SSRF. Even with protections in place (disallows internal metadata requests to Cloud platforms), this mitigation can be bypassed by using your own webpage with iFrames that make requests to these endpoints.

Pre-render is harder to identify but can be used for similar SSRF techniques if exposed in the wild.

If these endpoints are protected, then looking for Open Redirects (within the rendering application) can allow for controlled requests to launch SSRF attacks to launch MORE SSRF attacks (lolz).

Overall, interesting use of technology. This shows every little piece of technology on the web can be exploited in some way.

The main crux of this problem is taking untrusted serialized data and deserializing it. This has been a common issue with Java based applications in the passed.

This is a good example of a deserialization issue occurring in Elixir. "In Elixir there’s a much higher chance that such a function is executed later down the road, thanks to the Enumerable protocol of Elixir." This means that going for arbitrary deserialization to code execution is much easier in Elixir than other languages.

Fuzzing the kernel is crazy complex and NOT time efficient. So, moving this to userland can be useful. This article goes into fuzzing the Linux Kernel. However, this fuzzing is left as an exercise for the reader.

In a previous bug, there was a vulnerability in the handling of 32-bit vs. 64-bit but it was processed in the same area. The solution was to put this into two areas of code: one for the 32-bit and one for 64-bit.

What went wrong with this patch? The code was copy and pasted into another function where only some data was edited for 32-bit vs. 64-bit. So, some copies were happening for 64-bit instead of 32-bit! This created an OOB write primitive.

What is the take away from this? A 'fix' may not actually fix the problem! Verifying that a vulnerability has actually been patched is an easy way to find more vulns :)