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 VMWare cloud had a weird password reset implementation. They used the current password for the entropy on the reset token. Password reset tokens are supposed to be completely random!

So, what is the issue? If you know the password, then there is no reason for the password reset implementation. Well, there was a disabled backdoor user that had a hard coded password.

By using this disabled user (with the known reset link from the known password), the user became enabled! And, the best part, we knew the password.

The auth bypass was the main issue. However, there were other issues in the system that eventually led to compromise, such as a SQLi, file inclusion and directory traversal.

The Microsoft Teams application has a user facing application and a privileged XPC client. Historically, the XPC client on macOS has been a high-valued target, as it has high permissions.

The first issue is an insure validation of the sender of the requests to the XPC client. Of course, we ONLY want a specific application sending data to the XPC client. This is supposed to use an AuditToken to do. However, the application used the PID instead.

By using a classic PID reuse attack, an attacker controlled application can get the PID. This allows for arbitrary calling of the XPC daemon by an attacker.

Another interesting issue was that the application has the com.apple.security.cs.disable-library-validation. This means that any of the libraries within the application can be replaced with something else, without being validated. Both this and the first issue can be used in order to take control of the daemon.

What do we target within the XPC communication? The target of the attack was the Update mechanism. The update mechanism proper validates the Microsoft signature but does not block older installations with known vulnerabilities. Because of this, install the Auto Updater that is vulnerable to CVE-2020-0984 and exploit this known vulnerability.

Overall, XPC communication is difficult to do right, look over the entitlements of an application and NEVER forget about downgrade attacks.

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.