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!

Panaoptic is a company that maintains trading and perpetual (longs/shorts) contracts. When you take out a short, you are stating that I think this token will drop. This contract is called a position that a user takes. The vulnerability was a spoofing issue around the position data. This was received as a bug bounty report. The user received a $250,000K payout - the maximum on the program.

The position is all stored within a uint256 with different sections to the value for gas efficiency reasons. These include four legs, each consisting of an asset ID, an option ratio, a boolean indicating whether it's a long, a strike price, and many other fields. Additionally, there's a one-time section for Uniswap pool information. So, what's the big deal?

A user can have up to 25 open positions. Instead of storing each position ID on-chain, they combine the hashes to create a single fingerprint. When the user wants to interact with the contract, the positions are passed in, hashed, and verified against the user's current fingerprint. The fingerprint generation is as follows:

1. Hash the provided number associated with the position.
2. Take the lower 248 bits of the hash output.
3. XOR the lower 248 bits with the accumulated hash, which defaults to 0x00.
4. Add the amount of legs associated with the position and add them to the upper bits of the fingerprint. This is to know how many legs are associated with the user.
5. Repeat steps 1-4 until you're left with a value.

The usage of XOR is a significant problem here. XOR is associative, commutative, and self-canceling. This appears like the hashing function XHASH, which is known to be broken. By treating this as a set of linear combinations, it's possible to use Gaussian elimination to find overlaps with large sets of provided tokens. This allows you to create fake positions because the fingerprint will match. This requires brute-forcing the correct keccak256 hashes for the input values, but the problem isn't particularly computationally intensive.

Another issue that made this MUCH easier to do was that the usage of the fingerprint was not limited to 25 positions. Additionally, there was very little input validation placed on this either, since it was assumed the fingerprint couldn't be spoofed. This made it possible to use giant token lists, making the solving easier.

To exploit this, an attacker would do the following:

1. Borrow assets via a flash loan.
2. Use the funds to deposit a lot of collateral.
3. Open two very deep in the money positions with both a call and a put with leverage.
4. Call the withdrawal methods on the contract with a list of zero collateral requirement positions. This allows you to credit your account without triggering the collateral subtraction.

They were unable to upgrade the contracts while this major vulnerability was present. So, they commenced a migration process. Over the course of two days they messaged all Panoptic users to remove funds from the protocol. Additionally, two wallets had 70% of 1.6M in them. They were able to find the users who owned these wallets, and they withdrew. They led to $550K in the protocol.

Time for the crazy part: the whitehat hack. Their plan was the same as described above on the attack: take a flash loan, borrow a lot of tokens to open positions and withdraw the tokens with the spoofed IDs that were provided. They took the reporter's PoC and made it work within a single Tx. They didn't post to GitHub or other tools out of fear of leaking. So, the PoC was done on a single devs machine.

They tried using the Flashbots RPC to recover the funds. This is a requirement because, otherwise, a bot could frontrun the whitehat hack and steal the funds. Unfortunately, Flashbots rejected the transaction because it required more state reads than they allowed. After contacting Flashbots, they updated the rate limit for them, and the recovery succeeded. It was first done on the Ethereum L1 and done immediately after on the L2s. They claim that 98% of customer funds were safe. To claim their funds, the team created a Merkle root verification system for users.

Awesome post! They have some good lessons learned:

• Several issues were discovered relating to these issues on the C4 contest platform but they didn't put the whole spoofing issue together. This quote is perfect: "If we had spent time ourselves trying to come up with a position-list-spoofing method, we may have been able to foresee this vulnerability."
• Recovery methods, outside of whitehat hacks, are massively important. A large amount of the funds was recovered through reaching out to users. I find this risky because one of the users could have looked for the vulnerability and exploited it. The more people who know, the more likely it is to get exploited.
• A rule as old as time: Use available tools and methods at all times. This is specifically true with cryptography.
• If you need to do a whitehat hack, prepare to be perfect. RPC listening, mempool watching, compromised dev machines, GitHub snooping... all of these would have allowed an attacker to carry out this attack themselves. This is a case where perfection is required.

Many vulnerabilities, both classes of them and individual instances of them, are missed by hackers. It's easy to stay in the comfort zone and look for the standard bugs over and over again. There's a big problem with this though: over years and years of an application existing, more and more niche security lay dormant ready to be discovered. This presentation goes through James Kettle's perspective on hunting security issues that others miss. He is the perfect person to publish this research!

One reason is a highly visible defense. In the web browser, this may be X-Frame headers, for instance. In the case of James Kettle, they wrote a proof of concept for a side-channel leakage that required the X-Frame to not be there; Mozilla said this is impossible because the header was not there. James didn't see the defense so they tried the PoC and it worked. It turned out that a bug in FireFox allowed for this to be possible. What's the takeaway? Write PoCs without considering the defenses and figure them out later. Modern applications are too complicated to fully understand by simply reading the code.

A lot of times, it's a vulnerability fad. A good recent example of this HTTP Smuggling. Vulnerability classes get popular, many of the bugs get found and then it floats into obscurity until the cycle happens again. The advice here is to review old research and techniques and apply them to today's applications.

But, there's a catch... techniques get corrupted over time. HTTP Request Smuggling was originally a desync between proxies. Over time, it become the ability to bypass WAFs and that was it. James recommends to go to the original source of the research. It will have the most complete amount of information and give you information that was lost over time.

The next reason is around fear of failure. Again, an example of this is around HTTP Smuggling. Either the technique isn't feasible, it's too complicated, it's not there... etc. James says to just go ahead and try it! If it's super new or super old, then there's likely a lot of good bugs to find with it.

Another reason is the invisible link. This is either application-specific or context-specific knowledge. For instance, a website that uses a custom authorization scheme. Unfortunately, this is inconvenient and time-consuming. However, it is essential to find great bugs!

The author thinks that automation can help find better bugs as well. Not full automation - fuzzing specific inputs. Scan for interesting input not bugs. Use the scanner as a lead for issues not as the issue itself. This helps go from a huge attack surface to finding the juicy bits. James calls this curiosity-powered hacking. Test a hypothesis, ask questions and iterate.

To do this effectively, make the questions cheap to ask. The longer you spend on something, the more sure you should be. The next advice is eliminate noise and be specific with the questions you're asking. Finally, do non-default things.

The end of the presentation has the best advice: make it your own. If you do the same thing that everyone else does then you'll be crowded by noise and not do well. There's no winning formula; there are only different formulas. Great talk!

The author of this post was on a twelve hour trip from Canada to Hong Kong. The plane had WiFi but it was a requirement to pay $30.75 For everyone else on the WiFi, it offered free texting.

acwifi.com is the captive portal and asks for a Aeroplan payment. So, some websites work, such as https://acwifi.com, but others do not? For instance, github.com. Can we circumvent this!?

Initially, they tried to disguise the domain. They set the /etc/hosts to be acwifi.com to go to a proxy server. By doing this, the DNS record would be rebinded. When they tried to ping the IP, this failed. Their best hypothesis was that ICMP and TLS were blocked.

Much of the time, DNS arbitrarily works. This was the case here as well. This was both UDP and TCP-based DNS queries. This tells us one thing: the firewall allows all data through port 53. So, they setup a proxy on port 53 and connect to it. Boom! WiFi without paying for it ;) They also think that DNS tunneling would have worked as well.

Another mechanism for bypassing the protections would be to use ARP Spoofing. By becoming a different MAC address you can simply become another user who is paid, as far as the network is concerned. This is a slightly more criminal so they decided not to do this though.

When you use a major AI service like ChatGPT there is more than one model that you're talking to. How does it decide which model to use? More AI! According to this post, very quick neutral networks choose which model to use, known as the router. Some of the backend models are more powerful while the some other ones are less powerful.

This creates a potential security issue when it comes to jailbreaking: what if you can trick the router to use a less powerful model? By tricking the router, it makes jailbreaking much, much easier to do.

This is more of an abuse issue than anything else. You could likely get ChatGpt to generate inappropriate content such as create recipes for bombs and such. Being able to downgrade jailbreaking detection is interesting!

To support debugging applications written in Unity, the Android library adds a handler for the intent containing unity data onto a UnityPlayerAcivity. Android does manage feature flags it does not prevent the execution of intents.

The unity field contained a lot of extra flags. While reverse engineering the library they found that xrsdk-pre-init-library could be used as an argument to dlopen to load arbitrary libraries. This gives the threat of an RCE in the application!

A malicious Android application can trigger the intent with their own created library. By doing this, the application would have the same permissions as the Unity application.

Exploitation from the browser is somewhat nebulous though. Because dlopen needs a local file path, we need to trick the user to downloading a file. By good design on Android, SELinux prevents the usage of dlopen for files in the downloads directory. Nice protection!

This isn't full-proof though. dlopen doesn't require a file to have the .so extension. Since /data is allowed, if an application writes arbitrary data to storage on the device then this can be used as a malicious library. Good find!

Meta's Facebook Messenger can use end-to-end encryption. In particular, you can select a friend and decide to start a conversation with them. Because the chat is encrypted, everything must be verified on the client-side. This creates a pretty large attack surface that the author of this post looked into.

The author was playing around with Android and sending attachments to a user on a Windows computer with encrypted chat. The author tried a trick as old as security itself: path traversal. They added some ../ to the path to see what would happen. If a victim can receive messages from you then you can add a file into any location on their Windows machine!

This has two crucial limitations: files cannot be overwritten and there's a character limit of 256 symbols because of the Windows FS limit. The path that the file name is appended to has a 212 symbols, giving us 44 available to work with. To get to the main C drive with a traversal, we only have 12 characters left. What to do?

Slack and Viber are very small names. So, the author decided to try to exploit these directories. By using DLL hijacking, they were able to add a DLL that those programs would execute. Naturally, this led to RCE on the victim devices.

Initially, they received a payout of 35K. They linked to a bug bounty page about payouts and claimed that the information provided was insufficient. After doing that, they were aware of another 75K. It's essential to push back on your payouts!

A lot of people hate compliance. There's always some new standard to follow. Compliance is a snake eating its own tail. This is a good thing!

The tech industry is constantly evolving. If the standards stayed the same, then they would be out of date. That doesn't mean that the original standard was bad - it was just meant for a different time. The next standard will be good for the current cycle, but it will eventually go out of date as well.

Sometimes, things become too cumbersome and need to be rethought. Other times, there are more important things to consider than the original design. A pretty short article, but I like the rebirth mentality of compliance standards.

Vibe Coding is the practice of using an AI-assisted programmer to write all of the code without paying attention to whether it's correct or not. So, what's the term for a seasoned professional who uses AI to accelerate their work? Productivity with LLMs on non-toy projects is actually very hard to do correctly. The author proposes that we call this vibe engineering.

LLMs actively reward existing top-tier software engineering. By forcing the LLM to write tests, you can quickly figure out if something works or not. A good test suite really benefits the AI and you're sanity on the code. Another way to be better is to Plan in Advance. Providing the AI with a detailed plan of how you want a particular task done will significantly enhance the output.

Comprehensive Documentation greatly heps AI. Whether it's just a subset of a codebase, documentation for a library or something else, allowing the LLM to read relevant documentation goes a long ways.

LLMs are apparently amazing at Git. They can navigate the history to find the origin of bugs. Effective automation provides good impact as well. Linters and CI/CD help find bugs quickly.

The most important thing to me is a culture of code review at the company. This makes sure bad code isn't added at the organizational level. From a personal level, this means reviewing the code that the LLM writes for bugs and correctness.

A good article on what needs to be done well in order to be a good usage of LLMs when programming.

Building a reputation within a company is hard. Many people think it's through being talented but this probably isn't the case. Many strong engineers are unrecognized and many bad engineers are very well recognized. Why is this? The author discusses the natural Ratchet Effect.

Initially, you have a starting point that is not the lowest, but it is the lowest. Similar to how you join Chess.com at a 1200 rating. Judgements are made quickly at this stage. At first, you're only given regular JIRA tickets, bug fixes and nothing that stands out. Over time, your team, that sees the work, sees you and you gain status.

Since you did a good job on the work, you are given more work with visibility from other teams. If you did a good job at this, this creates even more positive visibility. This gives you a higher status within the organization. As you repeat this process with more and more teams, you are assigned higher and higher-profile projects until you reach your limit. All of a sudden, the CEO is choosing you by name to lead a project. Why?

Reputation is quick to form but very slow to change. Once someone outside of your immediate circle has a good or bad opinion about you, it's likely to stay. Individual teammates may know your skills more accurately but the skip managers only see the original perspective. It's hard to get out of this.

Some people try to jump straight into high-profile work to prove themselves, whether they are new hires or those with a bad reputation. According to the author, this usually doesn't work. Most of the time, big projects have a lead put on it ahead of time. Second, executes have a clear picture who is good and bad; if it's a key project, they won't risk putting a bad person on it.

What's the best way to gain clout? Focus on small pieces of work to build a reputation. Slowly pick up the importance of things to transition to higher-profile and more visible work. Your first high-visibility project is critical to forming a reputation with more senior management so you better do well on this one. If you have a failure, slowly build back with small successes.

Overall, a good piece on building yourself up as a good engineer at a company.

Many software engineers avoid dealing with company politics because they consider it pointless to get involved. The main reasons why this is the case are as follows:

• Technical decisions are made for selfish reasons that cannot be influenced.
• Many powerful stakeholders are incompetent.
• The political game depends on private information that software engineers do not have. This sucks.
• You play a different role. If you're not spending your time playing politics and others are, such as your manager, then you're unlikely to succeed with less effort.

This Hacker News comment describes the first point really well. They claim a few interesting things. First, devs/supervisors want the new hot thing on their resume. Another reason is to push the newer version of something by proving that the older version is bad, much of the time at the expense of others. Third, the organization needs the new buzzword to show to VCs or get the opportunity. Another comment claims that proposals are often accepted by everyone but then rejected by the C-Suite because they played golf with somebody that changed their opinion of it.

Given that politics are present in the workplace, how do we address them? We're clearly not well-equipped to do it. Their first piece of advice is to work on a high-profile project successfully. If you kicked ass in your own area, then you will have respect from others. Making this success known to those people is a challenge in its own right, though. This gives you rewards like bonuses and more clout.

The hard way is to drum up support for your own project. Since this doesn't align with others and you don't have the political clout, this is very hard to do.

Instead, let other people fight for you. When the next political initiative that lines up with your project comes out, push it hard. For example, imagine your project is pulling some existing functionality into its own service. If there's a mandate at the company for reliability, then push your project. The org will get behind your project in response to it aligning with others without much political debt.

This waves come and go but the executes are always excited to be doing something. So, always have an important thing lined up that matches their flavor of the month. A good quote: "Having the right idea handy at the right time is your responsibility."

Overall, a good post on politics and how to navigate them as engineers.