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!

A terrible vulnerability in an OAuth implementation is an arbitrary redirect. This is because the code from the OAuth provider is sent back in the URL before being turned into an access token. If an attacker can get the redirect to happen to their website with the code in it, they can compromise the account.

The redirect_uri is usually incredibly strict and checked by the provider. A value commonly used to hold extra state and prevent login CSRF is the state parameter. In some implementations the data is not validated as thoroughly but can control the flow of execution still.

The author found that the state parameter contained functionality to redirect to a secondary domain after the original domain, somewhat separate to OAuth. Their hypothesis is that the application had several different areas depending on the platform so it needed a firm redirect to satisfy the providers requirements and then would redirect to the platform specific page once it was done.

This redirect on the state led to a one-click account takeover of the applications account. I had personally seen this state used like this before so it was interesting to see a vulnerability in it. Good find!

ClipSp is a Windows driver used for Client Licensing. Because it's fairly sensitive, the driver has no symbols and they're even obfuscated. The author of this post spent some time reviewing this code to find a few OOB reads and writes.

The format processing is tag-length-value (TLV) format for a large group of blocks. Each one of these tag entries represented a bit of license information. One of these tags was a signature tag.

The code would iterate over the top of every single tag. When it saw the signature block it would use the an index to count to the number of bytes in the buffer before this that needed to be signed.

The issue with this scheme is that the data after the signature block would still be processed without being checked by the signature. If a field was already used, it could even be overwritten. I like this bug since it's a fairly deep implementation flaw of the algorithm. Good find!

Running a bug bounty program has a lot of difficulties. The program has a budget for the amount it's allowed to spend. The managers need to understand resourcing and time commitments to the program as well. This article has two tips on making the program better for yourself and hackers.

Three types of hackers do bug bounty: greenhats, passion players, and professionals. The green hats are in it for the money. Passion players do it for the technical intrigue. Professionals are looking to increase their reputation with a nice quote on a website or a CVE to pad their resume. Each of these types has different ways to keep them around. Although all are great things to do as a program manager, I personally appreciate #2 the most.

For the greenhat, bonus's are helpful. Even a $100 bonus for a bug gets them excited and makes them feel like that you appreciate their work. This $100 will go a long way and will likely keep them working on the program for a while. Additionally, pay consistently. If you paid $X for a bug before, don't change it.

For the passionate player, you should compliment their skills. Making them feel like a top-notch hacker will keep them around. Another mechanism to keep these technical folks around is root causing the issue with more technical details than they can see. For instance, information about the backend architecture and why this vulnerability occurred. The passionate players LOVE to understand every little detail of vulnerabilities they find.

The final one is the professional who is trying to improve their resume. For these folks, allowing them to post about the bug publicly, adding them to the hall of fame or any public items are what they want. Job offers also make their day, even if you don't really mean it.

The most important part of the program is the publicly facing policy page. This gives hackers an insight into your program and why they should hunt on it. The first tip is to keep the rules concise and broad, living off of the primacy of impact rather than semantics. The second thing is making it easy to start on. Things like async comms for an email, VPNs or anything else are a major turn off.

For vulnerabilities that are out of scope or long-lasting issues, make sure to publish these changes. It's the worst when you're hunting for something and are dupped by a ten-year-old bug or get out-of-scoped by a recent change to the program that you missed.

The final point is probably the most important: define your threat model. What impacts do you like and dislike? What are the security boundaries of your threat model? All of these things help hackers give the highest-quality reports they can.

I love this post, even though I typically only like the very technical things. Running a bug bounty program well is a skill that is often not talked about. I think this post really helps shine some light into making the program better.

The beginning of the article goes through dumping the firmware from a serial flash chip and accessing UART interface. In the UART interface, they noticed that the Linux OS was not giving any output. To fix this, they modified some UBoot settings to turn on the output. They popped them into a limited but not root shell, limiting their initial capabilities. Now, time for a chain of vulnerabilities!

In the sonia binary, they found a super simple unauthenticated stack buffer overflow. The systems has ASLR enabled, stack canaries and the write is via a strcpy, which limits the amount of NULL bytes we can write. Luckily, there is no PIE. By using a partial overwrite of the stack address (3 bytes), we don't need to break ASLR. In some cases, the 4th byte will be NULL and we will write to that with our NULL byte then. I'm guessing they brute forced this 1/256 chance.

This really limits our exploitation though. We can't write bytes after our address or any null bytes before that. The authors used this exploit to open up a new attack surface: the Image Quality Service (IQ). By calling the function sonia!thread_listen_handle, an unauthenticated listener is created that will loop infinitely. Neat!

Within the IQ functionality, they found a heap out-of-bounds read that returns information directly to the caller. Typically, this is used for an ASLR leak, but the authors had a better idea. In a separate service (DHIP) on the same binary, there are several unauthenticated commands like resetPassword that require a special 8-byte Auth Code with secrets known to the device and technican. By using the heap leak, the secrets for the string can be leaked by continually calling checkAuthCode! Wow, that's a pretty neat exploit and usage of an information leak!

The DHIP service contains an authenticated buffer overflow as well - it's a stack-based overflow into a stack buffer in JSON parsing. Now that we have leaked the password reset information, we have authenticated access to the service. The overflow occurs in a strncpy, which doesn't allow the writing of nullbytes with [ being overwritten with nullbytes after the overflow occurs.

The bug above allows writing a single pointer so the gadget must be chosen wisely and then overwrite the return address of the function. At 0x002C0A2C, there is a gadget that will execute arbitrary bash commands from a single provided stack buffer input. I'm slightly confused on how this works alongside ASLR but they say it does :) They had to do some shenanigans to force this not to crash after this point too. Now, we have a command execution on the system!

For whatever reason, this wasn't enough for them - they wanted the ability to execute arbitrary binaries. Since the kernel had ELF binary signature verification, this wasn't directly possible though. LD_PRELOAD can be used to load a library in an approved command to easily circumvent this protection though.

Overall, it is a super interesting blog post on the exploitation of this device. The usage of pre-existing functions to exploit the binary twice instead of a traditional ROP chain is cool to see. Additionally, the heap OOB read to leak secrets is a rare feat as well. To me, this means that binary exploitation will never die but the tricks may become different.

I was curious about the order in which the bugs were found and got a response from the author. They found the RCE bug first to allow for better debugging. Then, they wanted an auth bypass, which led to them finding the overflow and OOB read in the IQ stack. Upon realizing this wasn't hittable code, they found a way to turn it on. So, they effectively did this in reverse!

Spectral V2 allows people to create on-chain AI agents. Each agent owns a wallet that allows on-chain actions. There are three main contracts:

• AutonmousAgentDeployer.sol: handles swaps between SPEC and Agent tokens.
• AgentToken.sol: Goverance token with a taxing functionality. This tax is important for later.
• AgentBalances.sol: Manages and distributes tokens that came from taxes.

When transferFrom() is used on the token, a tax is applied to the funds being moved in AgentToken. Whenever this occurs, the AgentBalances contract is given an infinite approval to spend funds on behalf of the caller contract. Infinite approvals are prone to abuse, but they typically involve simply stealing funds.

The swapExactTokensForSPEC() function on the AutonomousAgentDeployer contract calls transferFrom(). If an attacker calls this function it gives the AgentBalances an infinite approval on this contract.

The attacker called a public deposit() function that allowed for the specifying of the from, tokenAddress and amount values on the AgentBalances contract. They don't have the ability to steal the tokens though - only transfer them somewhere else by mode of approvals. Why is this useful though?

The AutonomousAgentDeployer contract balances were used as part of the constant product market maker algorithm between AgentTokens and SPEC. Hence, if tokens were removed from the contract to somewhere else it would then change the price of the swap drastically!

So, the attacker triggered the infinite approval and exploited the approval to manipulate the price of the SPEC token. Since there is almost not AgentToken left only a small amount of AgentToken needs to be used in order to take all of the SPEC tokens. This exploit stole about 250K worth of tokens.

Overall, it is an interesting exploit! Sometimes, you find yourself with a primitive, like moving tokens from one account to another, but it isn't immediately useful. From there, you must find an exploitation route to profit from it. This feels like a good example of that.

I personally have no idea how Dark Web marketplaces work outside of them using Tor. This seems to have some good insight into how it works. I also learned that Donald Trump plans on releasing Ross Ulbricht, the founder and convicted felon of the Silk Road.

JavaScript is not seen on modern Darknet websites. Why? Websites can be actively fingerprinted, regardless of Tor's efforts to prevent this. Not using JavaScript drastically reduces the attack surface. But how does a modern website even work without JavaScript?

Captcha uses a weird feature of the browser's input type that will send the X and Y coordinates that were clicked in the image. People also do some crazy things with CSS. Most of the complicated code is run server-side instead of client-side as a result.

The onion links are nasty to look at. So, phishing becomes even easier against non-tech-savvy users. This is particularly bad because there are multiple mirror links of the same website. To get around this, there are multiple points where you are forced to think critically about the decision you are about to make.

Messages are typically encrypted using PGP, which is registered at account creation. If a message needs to get sent to the user, such as for 2FA, it's done using PGP.

After a user is logged in, they are given a publicly accessible website link to access the "clearnet". Since these are more risky, a given group of authenticated users is given a unique mirror to make the URL private and unique. After a user makes a transaction, the pool is upgraded. I'm not super clear on the terminology here but it sounds like a lot of defense-in-depth measures.

Many websites have an integrated wallet. This way, you can send your funds in once and just use them on the provided account all the time. To prevent exit scams, it's typically a 2 out of 3 (user, vendor and market) multisig wallet. Once you want to buy something, you communicate the shipping details using the PGP key information.

Remaining perfectly anonymous is really hard. Things like language and region-specific writing, such as commas vs. decimals on large amounts, made it possible to narrow down the location of the operators.

Overall, an interesting look into the design and usage of a darknet site. Good write up!

needrestart is a tool that probes the system to see if a system or service needs to be restarted. It's called when using apt-get upgrade when a shared library does not exist on the system anyone. The authors of this post for 3 LPEs in the application that runs as root.

To determine whether a Python process needs to be restarted, needrestart extracts the PYTHONPATH variable from the process before executing a pre-loaded script. Since an attacker can set the variable and the process uses the interpreter, we can put our binary at this path and execute it as root. The same issue also exists in Ruby as well.

To determine whether a process is Python or not, it checks the processes /proc/pid/exe file then matches it against a regular expression. A previous vulnerability existed on this that the regex was not anchored at the beginning and end. They realized that there is a time of check vs. time of use (TOCTOU) issue that allows for the verification to read one path but then the execution to use another by switching it out. Both Python and Ruby were vulnerable to this attack.

In Perl, the functionality was different than the other two. Instead, it calls into scan_deps to analyze a Perl script but reads its source files recursively. Unfortunately, it feel victim to a super bad pitfall in Perl: insecure usage of file operations. In Perl, open() will execute bash commands if there's a pipe (|) inside of it. By passing in /home/jane/perl| as the file name to read, the bash script gets run. Crazy!

After finding the insecure usage of open, there were several eval() calls vulnerable to code injection vulnerabilities as well. It's interesting how these vulns got through - many of them are fairly simple issues that I thought had died out years ago.

I love the Qualys posts. Straight to the point on the vulnerability with zero fluff. They keep finding really bad vulnerabilities in things on Ubuntu. On the Day Zero Podcast, they mentioned that the easiest way was the Kernel for a long time. Since that has been hardened, people have started looking elsewhere such as the userland apps that run as Root.

Cross-Site Request Forgery (CSRF) attacks have been mitigated largely by browser protections like SameSite cookie flags and pre-flight requests. Some technically work because of browser behavior but shouldn't be considered security-safe because the functionality could change.

One mechanism for detecting CSRF is the rejection of requests with a Content-Type not equal to application/json. Since JSON triggers a pre-flight, it's common to use other content types, such as text/plain, to avoid this.

There are some notable bypasses for this though. For instance, 307 redirects with Adobe Flash player in Firefox and in Chrome the navigator.sendBeacon had a vulnerability to set the content type header to an arbitrary value.

The fetch API in JavaScript is used to make web requests. This function accepts both a string and a Blob object. By passing in a Blob object without a type into the fetch function, it will send a request without CORS or a content type header! The actual data in the blob will become the body of the request.

They give an example of a Ruby on Rails endpoint that first checks the existing content type and then checks for the application JSON. Since it doesn't exist, the check is effectively skipped. Although this is unlikely to work as a complete bypass, it's an interesting trick none-the-less.

SSLVPN is essential protection for defenders. As a result, threat actors are constantly looking for bugs in it. This article describes and explains a vulnerability being used in an active campaign. They do this by doing some diffing on the changes.

The first interesting diff they did was on the Nginx route configuration for /etc/nginx/conf/locations.conf. The changes were setting a bunch of proxy_headers to the empty string and one of them to 'on'. Most notably, the X-pan-AuthCheck header was now being set to on.

The X-pan-AuthCheck header is used as part of an authentication check in uiEnvSetup.php. Authentication is entirely bypassed by providing this header and setting it to off. Hype!

Once logged in an application like this, RCE is practically a feature. AuditLog.php has a fairly obvious command injection. However, they were not only sure where the actual input came from but just knew it had to do with user impersonation. After trying a bunch of endpoints, they eventually found one that triggered the command injection from the username parameter on the call.

I personally liked the patch-diffing part of this article. As a defender of other companies, like this one, understanding what the vulnerability is and what you're up against is a requirement. So, I imagine so do a good amount of reverse engineering for these types of patches. Good work and knowledge sharing!

us-east-1 is the most popular region at AWS. Since the name is in many domains, such as S3 domains, the author decided to purchase us-east-1.com to see if it got any exciting traffic. The connecting computers are likely misconfigured somehow, but it's interesting nonetheless. They are flat out, but this domain or some higher-level domain string was accidentally left out.

prod-backend-db.cc66xuedqt2t.us-east-1.com had the most DNS queries. Given that there's some random identifier, I'd expect this to be some hosted database service URL from AWS. The root domain had a lot of hits as well.

loopback-streaming.us-east-1.com is likely some internal testing URL at AWS because it has loopback.

Another interesting one was Cisco Static File Reputation Host. Apparently, this is part of the legacy version of their email security gateway. Since this domain is incorrect, this email security gateway is misconfigured and could allow malicious files into the org.

Many other domains like storagegateway.us-east-1.com and s3.us-east-1.com were in there as well. The author thinks it was from somebody types out the wrong domain by hand instead of copying it. It's weird that these lasted for this long, as I'd expect them to notice the errors in the returned data. My personal favorite was the final one: smtp.mail.us-east-1.com

They kept getting a lots of emails from the AWS test environments as well. It appears that these test domains were configured incorrectly. For instance, aws-supply-chain@us-east-1.gamma.app.ketchup.aws.dev sent loads of emails. This is interesting and could potentially lead to data exposure of testing accounts.

The security of this domain matters. To me, many of the requests would be a lot more if it was the expected result to the end user. Once it fails, they probably reconfigured things. A malicious adversary could have returned unintended data or harvested the data if it was a storage system like S3. Additionally, phishing can be an issue as well. Overall, a good write up and money well spent on the domain!