My name is Jack Cable and I’m from Chicago. I got into hacking by inadvertently finding a vulnerability in a financial site which allowed me to send negative amounts of money to other users, effectively stealing money from their account. Since then, I’ve participated in a mix of public and private bug bounty programs on HackerOne and Cobalt.
I’m a student and do bug bounties on the side (I plan to major in either math or computer science). I don’t really have a set timeframe for hacking, just whenever I have the time and feel like it.
On average, I probably spend around 5 hours a week hunting bugs, but this can vary. Since I started, I’ve reported 300 vulnerabilities on Cobalt and HackerOne, which comes out to 15 vulnerabilities a month.
Immediately! The first vulnerability I found was a critical vulnerability on a financial site (ChangeTip) which allowed me to steal any amount of money.
Several, I seem to have a knack for finding ways to get an infinite amount of money on financial sites. One of those, in particular, was in a private HackerOne program which allowed a user to create a transaction for a negative amount, but wouldn’t actually process the transaction unless it was a positive amount. I thought this was unexploitable until I found an undocumented parameter which allowed me to send multiple transactions at a time; I could then send $10 to one user and $-9 to another. This would only charge my account $1 (the sum of the transactions), but generated $10 in another user’s account.
I’ve always loved the challenge of trying to break into systems, and that has motivated me to explore white hat hacking and bug bounty programs. The hardest part is likely getting started with public programs, I would suggest looking at newest programs on HackerOne and starting from there.
There’s tons of great blogs and write-ups available to learn from. I suggest reading any of the blogs available here as well as HackerOne’s newsletter. Some great write-ups are posted on the Bug Bounty Forum Slack group as well.
I mostly work myself, though I would be open to collaborating.
I’ve recently been trying to improve my recon process and incorporate more tools. For finding subdomains, I use Jason Haddix’s domain tool, after which I test to see which subdomains are responding.
Once I’ve discovered dynamic content, I test for whatever it might be vulnerable to. This includes anything from XSS to SQLi, and less commonly looked at vulnerabilities like race conditions (I’ll elaborate more on these later).
Typically, yes, I look for everything. I’ve found that on larger applications it’s easy to get overwhelmed by the amount of content, and best to section yourself off to one portion of a site and do a comprehensive test for many vulnerability types.
Tools I use:
I don’t have much experience with RCE or SQLi (actually found my first RCE yesterday!), but I hope I can offer some tips on an often overlooked vulnerability: race conditions. A race condition occurs when an application has a delay between checking a state (i.e. if a user has enough money in their account to send a transaction) and executing the user’s request.
I’ll detail a few race conditions I’ve found in a variety of contexts. To test for race conditions in BurpSuite, right click a request and select ‘Copy as curl command’. Then, in the command line, execute the request in the form ‘(request) & (request)’. This repeats the request 2 times, sending it asynchronously.
ChangeTip - race condition in transferring money (with permission to disclose):
ChangeTip was a bitcoin tipping site that allowed users to send off-chain bitcoin transactions to other users. A user had a pocket with a USD balance and a BTC balance, and could transfer money between them.
Consider if a user had a balance of $1 in their USD balance. In BurpSuite, intercept a request to transfer $1 from the USD balance to BTC, and execute this asynchronously twice, as outlined above. The user now has $-1 in their USD balance and $2 in their BTC balance. This can be repeated to get any amount of money in an account:
(unfortunately, I was not rewarded $12 billion)
This is a more basic type of race condition, where repeating the same request multiple times leads to interesting results. I’ve found this common in financial sites, either in sending money or canceling pending transactions.
Instacart - race condition in redeeming coupons (https://hackerone.com/reports/157996)
Another common type of race condition is in redeeming promo codes, gift cards, or coupons. In Instacart, I found that I could redeem the same promo code twice, which would give double credit to my account. After a fix was issued, I discovered a bypass by redeeming two different promo codes. This demonstrates another case of race conditions, where it is necessary to test different values.
Race condition on private program exposes SQL query
The last race condition I’ll outline was on a private program. A user could process a unique, one time action with an item. I executed this request twice, and this exposed an unintentional error message containing the SQL query. This was because the database had the item set to be unique, and the server normally checked if the user had already processed the action. In this case, though, the server verified for both requests that the user had not yet added the item, leading to an SQL error being returned.
Many times! There’s always more bugs to find, my favorite example is with a find in Legal Robot, where the information of every user was being sent to everyone via websockets. This was when they launched after having a private program.
Yes, I had a background as a web developer before starting hacking. It helps both ways, my knowledge as a web developer has helped me learn vulnerability types and my hacking experience has allowed me to build more secure applications (I dare you to break mine!).
Indie folk / folk rock
I’m a student, so school + homework takes up a lot of my time. I enjoy working on math, board games, traveling, and coding.
I’ve gotten to know tons of awesome hackers and have been able to learn from them. I also plan to pay for college with them, so that’s a huge help.
There are going to be days when it’s difficult to find any vulnerabilities, and days when bugs come easily. It’s important to keep trying to approach targets in different ways, and switch targets once in a while.
Hardware hacking or reverse engineering seems interesting, since it would be a completely different challenge compared to web hacking,
Nutella’s good on just about anything.
I’ve had several cases where a clear vulnerability was not accepted. It’s important to learn where to pick your battles, and move on from them.
Probably Frans Rosén – subdomain takeover ninja.
An ability to collaborate on writing a report and share reputation/bounties would be nice, and could encourage hackers to work together.