That's not just one vulnerability, that's a whole slew of failures. For instance there is absolutely no need to keep those documents on the live server for applicants once they have been used for their intended purpose. Blast radius reduction and all that.
I hope you got at least free tickets for life out of this.
You'd think but I keep meeting even "experienced" technical leadership that have been at this for a while that there's no way to get around validation and security that's implemented in client code.
I’ve used browser dev tools to regularly add additional drop down options to menus that weren’t present. Huel, for example, only offered 2 or 4 week subscriptions, so I added 3 weeks to it because that’s the frequency I needed, and it worked no problem. 3 weeks later my shakes arrived and every 3 weeks since.
Just out of interest have you had any legal threats etc from this kind of probing if they don't have explicit bug bounty programs? Also do you ever get offered bounties in on reporting where there wasn't a program?
The kind of probing they did and described in the blogpost, with the attempt to raise their privileges to admin is legally fishy AIUI. Usually this kind of thing would be part of a formal, agreed-to "red teaming" or "penetration testing" exercise, precisely to avoid any kind of legal liability and establish necessary guidelines. Calling an attempted access "ethical" after the fact is not enough.
Good-faith security research[0] is the only way this industry will move forward, for better or worse. It is clear that most companies do not want to invest in anything further like VDPs.
Without any sort of formally posted bug bounty program explicitly authorizing this sort of activity the CFAA prohibits unauthorized access of "protected computers". I would classify this as legally risky. If FIA had a stick up their ass they could definitely come after the researcher. The researcher's ethical standing is pretty clean in my book, but this was definitely a little more than just changing a URL parameter (only a little more). I would say this is unsafe to do if you are in the united states. The stopping point was somewhere around "I think I could provide the admin role" and reaching out to the best contact you can find and say "Hey, I am an ethical white hat security researcher and I noticed X and Y and in my experience when I see this there is a pretty reasonable chance this privilege escalation vulnerability exists. The chance it exists is high enough in my experience that you should treat it like it exists and examine your authorization code. If you would like I can validate this on my end as well if you give me permission to examine this issue. I am an ethical security researcher" ---> point over to your website and disclosed issues if you got em. To just do it is ehh... I would not take the risk. However if I /did/ do it I would definitely disclose it to them immediately and give an explanation like the above. Shooting the messenger in this case would be pretty asinine, especially if they didn't access anything sensitive, that would preclude FIA from having any evidence you did anything sketchy (cause you did not). The reason I would not do it is because you never know if a system like this pre-fetches data, etc. and that is definitely opening you up to liability of possessing PII etc. Overall, I have disclosed issues like this in the past without actually exploiting the issue to good results. Some times companies ignore it. You can always say "If you do not want to treat this issue as a vulnerability I am going to write this up on my website as an example of things you should probably not do" if you feel ethically compelled to force them to change without actually exploiting the issue. People tend to get the message and do something.
Actual legal threats are uncommon but I have seen some companies try to offer a bribe disguised as a retroactive bug bounty program, in exchange for not publishing. Obviously it is important to decline that.
When I was still in university I reported a vulnerability and when the company started threatening me with legal action, my professor wrote a strongly worded email and they dropped it. Haven't had it since in 8 years. Feels like many companies understand what we do now, atleast compared to 10 years ago.
Archaic company has archaic security. Well done on the RD, but boy does it not surprise me one bit. Would almost be willing to bet that the hash was MD5 too.
`bcrypt` is probably the "standard" in the sense that it has the widest adoption, but since 2015 [1] the "standard" in terms of what you should recommend for new work has been `argon2id` (and you can find parameter recommendations here [2]).
"Having been able to attend these events by hoarding airline miles and schmoozing certain cybersecurity vendors, Gal Nagli, Sam Curry, and I thought it would be fun to try and hack some of the different supporting websites for the Formula 1 events."
Ah, thanks! Hard to keep up with this stuff. Next thing you know the boffins will tell us we need to switch to rot104 or even rot208 because of "post-quantum cryptography" or something.
Mass assignment problems sometimes also come from (improper?) use of frameworks. This goes beyond frameworks and more about how thorough the testing and review of how the user account modification and access control is done.
There are some vulnerabilities frameworks can address wholesale (like CSRF or XSS) as long as you keep to the blessed way of doing things, but they aren't able to save you from a complete failure to build authorization into your API. Like how seatbelts save lives but can't stop you from accelerating directly into a pole if you choose to do so.
i respectfully disagree with this sentiment. i think that in general, reinventing the wheel can be a great learning opportunity in understanding how the wheel works.
Great to reinvent the wheel for your mom and pop blog, or to teach yourself these concepts and try to break in. But not for authn and authz for something official like this.
That's not just one vulnerability, that's a whole slew of failures. For instance there is absolutely no need to keep those documents on the live server for applicants once they have been used for their intended purpose. Blast radius reduction and all that.
I hope you got at least free tickets for life out of this.
Rule 1.
NEVER trust user supplied data.
Once that rule was broken, any other rules broken became clear to everyone
Never trust any data. Even if the data comes from a partner or internal system it could be compromised or defective.
>Never trust any data. Even if the data comes from a partner or internal system it could be compromised or defective.
I don't even call it data anymore. I call it datain't.
You'd think that client side security would be something that we'd gotten over by now.
You'd think but I keep meeting even "experienced" technical leadership that have been at this for a while that there's no way to get around validation and security that's implemented in client code.
I’ve used browser dev tools to regularly add additional drop down options to menus that weren’t present. Huel, for example, only offered 2 or 4 week subscriptions, so I added 3 weeks to it because that’s the frequency I needed, and it worked no problem. 3 weeks later my shakes arrived and every 3 weeks since.
Did you try adjusting price?
That’s incredible
Ian, it would be great to see an RSS feed on your website if you want to gain another regular reader :)
Ian is a great writer
Seconding this
my favorite type of hacking. reading the js an modifying the PUT. Works a lot more often than you expect.
missed opportunity to grant the authors a F1 super license and get the chance to actually drive one of the cars!
If only that's all it takes
That is shamefully poor security.
It's hard to even call it security - it was just wide open...
I will say though, this kind of thing does wonders for my imposter syndrome.
wait until you see the party footage
Just out of interest have you had any legal threats etc from this kind of probing if they don't have explicit bug bounty programs? Also do you ever get offered bounties in on reporting where there wasn't a program?
The kind of probing they did and described in the blogpost, with the attempt to raise their privileges to admin is legally fishy AIUI. Usually this kind of thing would be part of a formal, agreed-to "red teaming" or "penetration testing" exercise, precisely to avoid any kind of legal liability and establish necessary guidelines. Calling an attempted access "ethical" after the fact is not enough.
Good-faith security research[0] is the only way this industry will move forward, for better or worse. It is clear that most companies do not want to invest in anything further like VDPs.
[0] https://www.justice.gov/archives/opa/pr/department-justice-a...
Without any sort of formally posted bug bounty program explicitly authorizing this sort of activity the CFAA prohibits unauthorized access of "protected computers". I would classify this as legally risky. If FIA had a stick up their ass they could definitely come after the researcher. The researcher's ethical standing is pretty clean in my book, but this was definitely a little more than just changing a URL parameter (only a little more). I would say this is unsafe to do if you are in the united states. The stopping point was somewhere around "I think I could provide the admin role" and reaching out to the best contact you can find and say "Hey, I am an ethical white hat security researcher and I noticed X and Y and in my experience when I see this there is a pretty reasonable chance this privilege escalation vulnerability exists. The chance it exists is high enough in my experience that you should treat it like it exists and examine your authorization code. If you would like I can validate this on my end as well if you give me permission to examine this issue. I am an ethical security researcher" ---> point over to your website and disclosed issues if you got em. To just do it is ehh... I would not take the risk. However if I /did/ do it I would definitely disclose it to them immediately and give an explanation like the above. Shooting the messenger in this case would be pretty asinine, especially if they didn't access anything sensitive, that would preclude FIA from having any evidence you did anything sketchy (cause you did not). The reason I would not do it is because you never know if a system like this pre-fetches data, etc. and that is definitely opening you up to liability of possessing PII etc. Overall, I have disclosed issues like this in the past without actually exploiting the issue to good results. Some times companies ignore it. You can always say "If you do not want to treat this issue as a vulnerability I am going to write this up on my website as an example of things you should probably not do" if you feel ethically compelled to force them to change without actually exploiting the issue. People tend to get the message and do something.
Actual legal threats are uncommon but I have seen some companies try to offer a bribe disguised as a retroactive bug bounty program, in exchange for not publishing. Obviously it is important to decline that.
Decline because it'd mean you were profiting off of a crime? Or that the opportunity of publishing has higher value than the bribe?
Decline because the public deserves to know the company has that approach to security.
Thanks, its cool to hear attitudes have changed.
When I was still in university I reported a vulnerability and when the company started threatening me with legal action, my professor wrote a strongly worded email and they dropped it. Haven't had it since in 8 years. Feels like many companies understand what we do now, atleast compared to 10 years ago.
Archaic company has archaic security. Well done on the RD, but boy does it not surprise me one bit. Would almost be willing to bet that the hash was MD5 too.
What hash do you use?
bcrypt is the industry standard.
`bcrypt` is probably the "standard" in the sense that it has the widest adoption, but since 2015 [1] the "standard" in terms of what you should recommend for new work has been `argon2id` (and you can find parameter recommendations here [2]).
[1] https://en.wikipedia.org/wiki/Password_Hashing_Competition
[2] https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...
yescrypt is very common these days, default in Debian
It's an F1 racing site, their job is literally to move fast and break things. https://xkcd.com/1428/
No, this is the FIA[1], not Formula 1. They are very very different organizations.
[1] https://en.wikipedia.org/wiki/F%C3%A9d%C3%A9ration_Internati... https://en.wikipedia.org/wiki/Formula_One_Group
You break things in F1, you lose. Reliability and consistency is key.
Strange, the site is run by an Ian Carroll, but the examples show Sam Curry, who is a very famous bug bounty hunter.
From the post:
"Having been able to attend these events by hoarding airline miles and schmoozing certain cybersecurity vendors, Gal Nagli, Sam Curry, and I thought it would be fun to try and hack some of the different supporting websites for the Formula 1 events."
if you look at his other posts, it looks like they collaborate often.
responsible disclosure made you no money and even after that blogpost you still have to take the l33tcode interview
well at least it was a password hash :D
Don't get too excited. They never said what kind of hash. Given the rest of the site's security design, might have easily been unsalted md5
Or maybe rot26 — I've heard it's twice as secure as rot13!
It’s 2025, you should at least be on rot52.
Best practice guide: https://github.com/killerk3emstar/rot52
Ah, thanks! Hard to keep up with this stuff. Next thing you know the boffins will tell us we need to switch to rot104 or even rot208 because of "post-quantum cryptography" or something.
There's probably another rockyou out there waiting to happen
Imagine being a world class F1 driver and (someone) still have to upload your CV somewhere.
Just use a framework to build your site. Don’t reinvent the wheel!
Mass assignment problems sometimes also come from (improper?) use of frameworks. This goes beyond frameworks and more about how thorough the testing and review of how the user account modification and access control is done.
There are some vulnerabilities frameworks can address wholesale (like CSRF or XSS) as long as you keep to the blessed way of doing things, but they aren't able to save you from a complete failure to build authorization into your API. Like how seatbelts save lives but can't stop you from accelerating directly into a pole if you choose to do so.
> Just use a framework to build your site. Don’t reinvent the wheel!
How do you arrive at that conclusion after reading an article on how an API had a broken access control vulnerability?
He’s being sarcastic and suggesting using some out of the box rbac thing.
i respectfully disagree with this sentiment. i think that in general, reinventing the wheel can be a great learning opportunity in understanding how the wheel works.
Great to reinvent the wheel for your mom and pop blog, or to teach yourself these concepts and try to break in. But not for authn and authz for something official like this.
But maybe do that on a smaller scale personal project?
Reinventing the wheel for Formula 1 driving…
Depending on the wheel, maybe. Nowadays it's more standardized - same rims for example. The tires are standardized.
There's a lot less freedom in reinventing the wheel in formula 1 nowadays
https://www.formula1-dictionary.net/wheels.html
The steering wheel of course isn't even a wheel anymore, for a long time. It's some video game console / airplane cockpit looking monstrosity.
It can. But it can be very bad at producing wheels that don't break.
Not if you understand how the wheel works. That's the whole point.
I funnily just read a whole Twitter thread that had this same thesis, not 45 minutes ago... What a small world