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!

HashiCorp Vault is a widely used tool for securely storing, generating and accessing secrets such as API keys, passwords or certificates. Although this does provide security benefits, it is a dream for an attacker, if they can get access. Because of how impactful this could be, it makes a wonderful target.

The 'Vault' has MANY ways of authenticating to it, including AWS and GCP cloud environments, LDAP or Radius, OpenID Connect and many more. Within AWS, this looks like giving specific functions access to data via a Role (temporary credentials). This goes two ways: share a role name with Vault and create a role in AWS.

When the Llambda function executes, it authenticates to Vault with a simple API call to /v1/auth/aws/login to return a short lived token to for the needed secret. Even though this appears to be secure, how does the endpoint validate roles? IAM is complex and using it outside of the AWS ecosystem is difficult to do properly.

The actual request (for the API in Vault) was signed (similar to AWS SigV4). However, it did not verify many things, such as the URL path, query, POST body or any HTTP headers. This lack of validation (although the rest of the request was signed) led to a complete compromise in the authentication.

The first two ideas did not pan out: altering the query parameter itself (https://sts.amazonaws.com/:foo@example.com/test) and altering the host header did not yield any fruit. So, we have looked at the request, how about the response?

The response looks for XML data from STS and just expects a status code of 200. However, the Vault never verifies the XML response, as STS should always send back good data. Why is this bad? It turns out that AWS also supports JSON responses and not just XML! For some reason, Go (which is the language used in this case) allows for non-XML data to be used and will attempt to parse whatever is passed in!

The AssumeRoleWithWebIdentity is used in order to verify JWT's with an OpenID Connect (OIDC) provider into AWS IAM identities. SubjectFromWebIdentityToken is a response element that can be used for this type of STS token.

So, again what do we control: path, request response type and some data being passed in. From the JSON response (and being able to control the path) it was possible to make a request to the OpenID and keep back a controllable field of the JWT that could contain XML: sub. Of course, this required a custom IdP in order to work (which the author had to make).

What does this allow? We can spoof the response from STS to be something that is attacker controlled, allowing for the authentication of arbitrary user roles! We can now see all secrets in HashiCorp that use AWS. All an attacker needs to know is the role name to use.

Now, for the GCP equivalent... The GCP env strictly uses JWT tokens throughout. JWTs have MANY ways to go wrong, especially in environments with multiple hierarchies of keys (such as google). People often see JWTs as a silver bullet but improper usage can be destroy to the security of the system.

GCP has a multitude of ways to sign JWTs (with valid signatures). Even though the service verifying assumes that the claims are proper (from GCP), it is possible to use a GCP generated key to create arbitrary compute_engine claims to act as a metadata server. Of course, this JWT must have all other proper fields for it to be considered a proper VM.

Boom, GCP version authorization bypass by creating a spoofed JWT.

Quote in the conclusion - "In my experience, tricky vulnerabilities like this often exist where developers have to interact with external systems and services. A strong developer might be able to reason about all security boundaries, requirements and pitfalls of their own software, but it becomes very difficult once a complex external service comes into play. Modern cloud IAM solutions are powerful and often more secure than comparable on-premise solutions, but they come with their own security pitfalls and a high implementation complexity. As more and more companies move to the big cloud providers, familiarity with these technology stacks will become a key skill for security engineers and researchers and it is safe to assume that there will be a lot of similar issues in the next few years."

To me, introducing the Cloud Computing revolution sounds great, but comes with its own risk of high complexity. There are many bugs like this out there, we just have to look!

The HP Device Manager uses TCP port 1099 on the internal networks for lots of enterprises. This is the default port for Java Remote Method Invocation (RMI) service registry.

Without the corresponding Java classes, you typically cannot interact with the service. However, several recent tools have made it possible to interface with RMI (BaRMI and rmiscout).

With the remote call, deserialization must take place. So, the first idea was to attack this. Using some Java gadgets, it was possible to

One of the remote calls was called ServGetUser and was used to retrieve HP Device Manager accounts. Using this call, it was possible to steal MD5 hashes of users. Using this, it would be possible to run a dictionary attack or brute force the hashes to the passwords.

Hibernate is a query language that allows for object relational mapping object classes to relational database tables so that developers do not have to write SQL queries by hand. Hibernate Query Language(HQL) is one way to query for this information.

There's this old thing called SQL Injection(SQLi). Although this vulnerability is impactful, it has largely been patched. This application had a query injection in a similar language: HQL Injection (HQLi). After some time planning around with injection queries into HQL, the author had successfully figured out how to smuggle arbitrary queries into HQL that would talk to the installed Postgres database.

By being able to injection arbitrary commands into HQL (hence PostgresDB), the author used a known privilege escalation/RCE technique in PostgresDB in order to become root.

From the HQL injection, it was become to become the root user! Overall, this was a well written article with many rabbit holes being discussed along the way.

Cross-Site Request Forgery (CSRF) is a somewhat dying bug in the age of modern browsers. However, if found, the attack is quite devastating, as a single click can force actions to be performed as that user.

This exploit is only possible on Google PDF products on Internet Explorer. The reason why? Content-Sniffing! This is the practice of inspecting request data to deduce the ACTUAL file format, even if a specific Content-Type is specified.

Why is this a security issue? Well, what would happen if a text file could be converted into an HTML document when being loaded back? The HTML would execute, even though it was just a text file.

In previous research is was shown that PDFs support a language called formcalc which can execute GET, POST and PUT commands. Why is this a big deal? Well, if they can upload PDF's, a user can create makes requests on an origins website using formcalc.

This particular MIME sniffing attack can be used in order to trick I.E. into thinking that any URL is a PDF. This is a big deal because is bypasses the Same Origin Policy (SOP), allowing us to run requests (on the hosting domain) from the previous research done.

To perform this attack, attach ;.pdf to the end a URL and have some PDF-looking content within the request. Using this, it is possible to make arbitrary requests in the users browser, on the hosting domain. The new piece of research here is adding the MIME sniffing attack to the PDF SOP bypass, making this MUCH more exploitable.

From the research, the most common place for this vulnerability was on CSV export/import functionality. Although this only affected IE and several clicks were required, Google paid out 30K!

Slightly confused on this (the article is not the best explained article) so feel free to reach out to correct any wrong parts of this post. Thanks!

This is a dedicated security guy who has been a senior engineer for Android and ChromeOS since 2011. Additionally, he was the technical security lead on the Ubuntu team for 6 years. So, this guy knows security!

On his blog, he posts technical articles about software security mitigations. In particular, he does a security feature review of version releases for Linux, such as here.

Overall, just a good guy to keep tabs on!

Fork can fail! What does it fail when it returns? -1!

What happens when you send a signal with kill with -1? It targets ALL processes!

So, if you can get fork to fail (and it is not the checked), you can trick the signal call to send the signal to ALL processes!

I did a similar thing with -1 while writing a CTF challenge. So, this was a fun little thing that I wanted to mark down.

There are two vulnerabilities in this blog post: authorization bypass and arbitrary file write. They will be discussed in this order.

The first vulnerability is really just poor logic. The authentication handling in IBM WebSphere has MANY different ways and is very complex. The program uses SOAP (XML stuff) in order to do the authorization dance.

When using token based authorization, there was a check to see if the user DOES NOT have a proper authorization token, by checking for NULL. But, in reality, this passes a value back called Unauthenticated instead of NULL. Now, the user can use the rest of the program, with limited users access.

From this minimal authorization bypass, it was possible to trigger a Deserialization Vulnerability that had already existed. But, the "patch" (notice the bunny ears) was to ensure that the user was authenticated. Because of this authorization bypass, this vuln was back on the table!

After this, the author had to find a custom Deserialization Gadget (as most of the default Java ones have been fixed now), which has in a different blog post entirely

The second vulnerability was a classic directory traversal in the file upload functionality. Of course, this allowed for an easy RCE :)

Arbitrary URL redirections are a common vulnerability where the impact is often disputed. Some bug bounty reports do not consider this a vulnerability at all.

So, with the arbitrary URL redirection, what else can be done? In order to increase the impact, the author of this article asked that question!

On the 302 redirect, all URL encoded data was decoded and put into the body. In fact, this even includes newlines! Because of this, it was possible to alter the body of the 302 redirect. This is called a CRLF (carriage return, line feed) injection.

From this, the author pulls up articles that found ways to get XSS via a 302 redirect. However, most modern browsers will not execute JavaScript in this context.

After brute forcing several URIs, it was discovered that (on Firefox) using the websocket URIs (ws or wss) for the redirect link allowed for the JavaScript to be executed!

To make matters even better, another user posted that a similar bypass exists (on Chrome) by not having a redirect link (just adding the newlines and the XSS payload) all together.

So, have an arbitrary redirect? Try to make the impact even better by turning it into an XSS!

The feature in test is IOSurfaceAcceleratorClient::user_get_histogram. The reason to go after this function was that the AppleM2ScalerCSCDrive IOService is one of the few user clients can be called within the app sandbox.

When being created, the histogramBuffer is allocated but never initialized. Additionally, IOMalloc does not 0 out the previous data. After making a call to this (without directly setting the values), a bunch of garbage was displayed; which is good sign for uninitialized memory leakage.

In order to exploit this, wanted memory (addresses) need to be on the heap. Although this could be leveraged in multiple ways (KASLR bypass or Mach Port finding), all that matters is doing some grooming to put the proper data at this location (to leak).

For a POC, the author leaked a Mach Port by sending OOL port arrays (importantly, the same size as the histogram object) then freed them. Now, use the histogram feature and the leak is there! :)

Bhyve is a hypervisor that can be used on Intel and AMD chips in order to run virtual machines. It is exclusive to BSD.

Even though I am not familiar with how virtualization works, the bug is pretty simple! The AMD (and likely Intel, but not directly mentioned) chips have a number of instructions that act directly on the VM host physical addresses. These instructions should be trapped (intercepted) but are not.

The instructions VMLOAD, VMSAVE and SKINIT are the ones that are not being intercepted. This can allow for a write-what-where primitive on the Host of the VM (with some restrictions).

The author puts a teaser for a super easy way to get code exec, but does not actual put it. But, there is a little more information on twitter.

WhatsApp uses a native library called libpl_droidsonroids_gif.so in order to do previews. This is the main target for the attack.

When doing previews, some reallocation's are done for different buffers. When a frame is of size 0 the rasterBits is freed. What happens if we have 2 frames of size 0? Well, this frees this buffer twice, causing a double free vulnerability!

On the application, the Double Free vulnerability will result in the same buffer being added twice into the heap allocator. This means that two consecutive allocations would result in the same buffer twice! It should be mentioned that each GIF is parsed twice, for whatever reason.

With the double free bug, what actually happens? The GFInfo struct is what contains rasterBits. Because we can control the size of the allocations, we can make GFInfo the same size as rasterBits! With both of the allocation as the same size, BOTH GFInfo AND rasterBits will point to the same spot in memory! Woah!

GFInfo has TWO function pointers that we can overwrite, making it a great target for compromise. From here, gaining code execution is pretty trivial... call system and find a gadget that allows for the first parameter to be set.

One thing that is not covered, is an Info leak. To exploit this, the base address of libc.so and libhwui.so. To me, it is really interesting that this RCE is such a big deal, when there is NO leak with it... this makes the vulnerability unexploitable and targeted, as a custom file must be made for each user you attack, depending on the locations of the above libraries.