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!

transmute converts between types in unsafe code by reinterpretting the bytes in Rust and forgets the original reference. It effectively disables Rusts built-in type checker by design. While as converts to things smartly, such as float to int, transmute is very dumb about it.

Because transmute bypasses built-in type checks, it must be sound. Otherwise, major security issues can occur. Violating soundness can lead to undefined behavior. It has a special section about "transmutation between pointers and integers". In particular, special care must be taken when transmutting between pointers and integers.

Agave, the original Solana validator written in Rust, uses transmute in an insecure way. It converts between an integer to a &mut T. This causes the reference to obtain the provenance(space) of an integer, which is none. If T isn't zero-sized, this instantly incurs undefined behavior as a result.

Overall, I learned something new about Rust type-safety. Good issue!

SAML libraries often parse an XML document, store it as a string and later er-parse it. For secure authorization, the document must be parsed and serialized consistently. Otherwise, these differences could result in serious issues. Round trip attacks can be used break the parsing logic of programs.

In Ruby-SAML, this process involved two different parsers: REXML to parse/verify and Nokogiri to access the fields. This vulnerability had a collision with the researcher in the post. They decided to investigate notation declarations, based on previous research, to see if parsing issues could be found. While doing this, they found that mutations could be introduced using the SYSTEM identifier.

When parsing SYSTEM, a comment with a single quote in the attribute is initially fine. When it's reparsed, the comment is not properly escaped and the single quote is made into a double quote. This modifies the syntax of the document, causing an XML comment to be processed and adding data in another comment to be part of the node instead. Using this method, it's possible to smuggle in data on the second parse to falsify the fields, such as the necessary assertions for users.

In Ruby-SAML, the library verifies that the SAML response contains a valid certificate in the document. Here's how it works:

1. On the first parse of the document, get the certificate to take a hash of it. This is used for signature validation later.
2. Certificate is extracted from the SAMLResponse.
3. The document is converted from XML back to its in-memory representation. This is the round-trip issue.
4. The library ignores the attackers assertion when doing the processing on the original element.
5. Accessing the data will now use the modified data added in by the attacker. Neat! We have a winner!

They wanted to see how far they could take this though. There is some XML scheme validation that prevents doing some trickery. This works by validating define elements, attributes, data types and number of elements. Although you could find an XML document on a developer forum, they went for a namespace confusion attack.

They use a discrepancy between the two parsers to bypass the signature verification. The XPath query on the signature uses the ds namespace, which would prevent element conflict. Normally, an included ATTLIST inclusion declaration with the same namespace would be rejected. However, REXML ignores this restriction in doctype declarations!

REXML will use the attacker defined namespace collisioned document. However, the other parser will use the original! This means that the verification will be done on a Digest that's real while the usage will be done on one that is fake.

To exploit this, a single valid signed XML document is necessary. WS-Federation is used by default on most IdPs though. Since this provides signed metadata, these signatures are accessible publicly from any user! The namespace confusion attack only requires a valid signature - it doesn't matter what it's for! By using this document, GitLab SAML authentication can be bypassed to login as any user.

Any time you see two different parsers, or data being parsed more than once, you hacker senses should start to tingle. This vulnerability was exploited in two different ways in this article and an entirely separate way in another post. This is awesome research - I will be looking for similar things in the future!

Discord created a new end to end encryption protocol they call DAVE. This will be used on DMs, group DMs, voice channels and live streams on Discord in the future.

For key exchange, they use the Messaging Layer Security protocol. This protocol allows having a per sender encryption key for all members of a group. Whenever a member of the group leaves or joins, the key exchange must be done again to prevent some attacks, which is well-thought out.

For identity and user verification, they use the MLS ciphersuite with ECDSA signatures. Each participant generates an identity key pair and shares this with other members on the call. Each device generates a private key so no synchronization isn't needed between devices. These are ephemeral and re-generated for each call.

I love reading articles from big companies about security best practices. Since these companies have the money and time to put effort into it, the needle can really be moved with the effort!

Sec-Gemini is an experimental AI model focused on cybersecurity. The model has been proven to do very well on cybersecurity-specific topics - better than other models on similar concepts. Pretty neat!

One fantastic hacker is better than five good ones. We can make all of the checklists that we want and this will always be the case. Most bugs are not just items from a checklist - they are broken assumptions or mismatches between what the developer intended and what the code actually does. This article is about Spec Thinking - a strategy to uncover assumptions and the implicit rules of the system.

A smart contract is an asset management system where actors gain access to benefits through actions. Pretty simple way to break down some code! The author claims that all bugs fall into three categories: missing paths, incorrect happy paths and unexpected paths. Missing paths are just user intentions that aren't there - you can deposit money but can't withdraw.

Incorrect Happy Paths are features that exist but there's a fault or mistake in the state transitions. This is "wrong result but the right path". Things like rewards being miscalculated or state not being updated are good examples of this. These are often caught in testing but it becomes harder to find these with larger codebases or very complex flows.

Unexpected Paths are parts of a system that do more than intended. Weird edge cases, unsafe flows or badly scoped permissioned are where these bugs exist. In my experience, this is where most bugs are at and threat modeling works the best.

Specifications are how the system is supposed to behave. Invariants are statements that always must hold about a system. For instance, total supply must always equal the sum of all balances. Properties define what should hold true after executing a specific state transition. As an example, after withdrawing the user's balance should decrease by the withdrawn amount.

These matter because a bad property means something is wrong. If you understand the invariants, intents and expected properties, you can find how to break them. Understanding these parts of the system helps you get better good coverage. The idea is using this understanding of the system to create specifications at three different levels.

The first is the high level specification. This is in plain English how it works like "a user cannot lose funds unless they voluntarily withdraw or trade." The second is mid-level specification with state tracking. Finally, the code level specification for function-levels conditions and transitions. Drafting out the properties, invariants and flows of the protocol allow you to understand the code much better.

Formal methods teach you to understand the design intentions versus the implementation. You should be asking yourself three questions when working through these specs:

1. What is expected?
2. What is allowed?
3. What was assumed but never enforced?