It's not clear if the author was hired to do this pentest or is a guerilla/good samaritan. If it is indeed the latter, I wonder how they are so brazen about it. Does chattr.ai have a responsible disclosure policy?<p>In my eyes people should be free to pentest whatever as long as there is no intent to cause harm and any findings are reported. Sadly, many companies will freak out and get the law involved, even if you are a good samaritan.
then again, the people in potential harm's way seem to be the poor sods trying to get hired by these companies for a meager hourly wage<p>I don't see how this "p0wns" the companies themselves
> Timeline (DD/MM)<p>> 06/01 - Vulnerability Discovered<p>> 09/01 - Write-up completed & Emailed to them<p>> 10/01 - Vulnerability patched<p>Note those dates are DAY-MONTH. At least they patched it within a single day.<p>I find it funny that the author found a massive vulnerability but chose to wait a couple days to report it so they could finish a nice write-up.<p>Reminds me of my experience with HackerOne: We had some participants who would find a small vulnerability, but then sit on it for months while they tried to find a way to turn it into a larger vulnerability to claim a higher prize.<p>Then when they finally gave up on further escalation and submitted it, they'd get angry when we informed them that we had already patched it (and therefore would not pay them). The incentives in infosec are weird.
>With an upbeat pling my console alerted me that my script had finished running<p>Forget the pwn how do I do this<p>Also, HN used to think this was cool now there are 20 posts blaming the hacker…
Full permissions for a user is blatant negligence.<p>For anyone who's never used Firebase before this is as simple as a single piece of logic that appears basically as:<p>if authUserID is UserDirectoryID<p>That simple.
You are a good human. Seems they had not tweaked the database rules correctly, maybe even left the default setup! That means you could have executed this:<p>Firebase.database().ref('/').set('All your data is gone').<p>Better yet, download the whole DB and then:<p>Firebase.database().ref('/').set('I have all your data, pay me to get it back').
If this had been exploited and the job applicants to Target, Subway, Dunkin et al, had bank/credit fraud committed in their name's, would the big companies be liable for not performing due dilligence on chatter.ai? To be clear, I'm asking from a legal standpoint not a practical one.
I was looking at jobs for my son at Safeway supermarkets and lazily put <a href="https://www.safeway.com/jobs" rel="nofollow">https://www.safeway.com/jobs</a> in the browser.<p>That redirects to <a href="https://www.careersatsafeway.com/desktop/home" rel="nofollow">https://www.careersatsafeway.com/desktop/home</a> -- which is very much not about jobs at safeway -- appears to be an Indonesian gambling/gaming site.<p>Safeway.com has <i>zero</i> email contacts published and expects communication to be via phone call or chatbot. I found their domain admin email and sent them info with no response, and no change to their site behavior.<p>This makes me think that they might be ripe for more monkey business but that's not my thing. Oh well.
Firebase is a shitshow. I say this as someone who really tried to like it and sadly built a project for a client using it.<p>Other than this security vuln, the issues vs. just using postgres are:<p>* It is more work! Despite being a backend as a service it is much less code to just write a simple API backend for your thing both in time to do it and time to learn how to do it. Think of Firebase as being on the abstraction level of Sinatra or express and you may as well just use those. Things like Firebase and Parse etc. are more complicated. For the same reason it is more complicate to walk to work with just your arms and no legs (even though there are fewer limbs to deal with and no backend!).<p>* Relational is king. Not being able to do joins really sucks. Yes you need to make async calls in a loop. NoSQL is premature optimisation.<p>* Lots of Googlization. This means lots of weird, hard to find out clickops configuration steps to get anything working. Probably why this security flaw existed(?).<p>* Emulator is flakey, so for local dev you need another cloud DB, and yes all that Googlized setup RSI inducing clickops.<p>* I reckon it is slower than postgres at the scale of starting a project. Traditional architecture are blitz fast on modern hardware and internet. Like playing a 90s game on your laptop.<p>* Apparently as you scale it gets pretty pricey.<p>The main thing is: it actually slows you down! The whole premise is this should speed you up.
Who's to say they're the first to discover this? They're the first to discover it and do something to fix it.<p>I thought there was a US law now where breaches like this have to be reported?
And folks, this is why you sell your exploits to the highest bidder.<p>Being "good" and giving companies free work is a HORRIBLE idea. They're never gonna pay, or even than you. If they're not willing to treat security researchers properly, I see no reason to return the favor.<p>Remember security groups: if your company wont pay, there are others that will.
Stepping aside for a moment and thinking about the scope of this, I think it’s a good example of why technological diversity is something to long for. If Chattr can be pwned like this so easily, they likely have many much more serious issues which in turn will affect half of America’s fast food chains.
This is my problem with the whole architecture of FE -> DB. Without a middle server layer, things like token storage, authentication, and other things become really easy to screw up.
It seems crazy that no thanks or recognition has been given.<p>Is this because doing so might be seen as an admission of liability, and could be used in any legal cases that are brought?
> If you grab the list of admin users from /orgs/0/users, you can splice a new entry into it giving you full access to their Administrator dashboard.<p>I'm not clear on this. Splice a new entry into what? The list of admin users? And then do what with it?
I worked with Firebase for a while, lured in because of how easy it was to do certain things. It makes certain kinds of operations essentially zero effort, such as getting realtime updates on the frontend when something changes. But it also creates a huge amount of effort that is trivial with other frameworks, such as creating a huge effort for security. I found that what I gained in convenience, I lost by needing to do so much work continuously battling with security rules. I left it behind and never looked back, and it made me much more cheerful about the work that I needed to do to establish and maintain more conventional backend data systems.
From Eva’s post:<p>> we didnt know much about firebase at the time so we simply tried to find a tool to see if it was vulnerable to something obvious and we found firepwn, which seemed nice for a GUI tool, so we simply entered the details of chattr's firebase<p>Genuinely curious (I’ve no infosec experience), wouldn’t there be a risk that a tool like this could phone home and log everything you find while doing research?
If they're already using firebase, can anyone think why they are storing passwords? Firebase Authentication is incredibly easy and quick to setup and use (less than a day for someone new to it), which means you have no need to worry about passwords.
Sad that in 2024 people continue to set their Firebase security rules to be wide open. Back in maybe 2015-2019 that was excusable because that was the default but now it’s just lazy.<p>Don’t expose your database / api / blob storage bucket / etc to the public! It’s not that hard to do it right, or at least “right enough” that you can’t get owned by someone scanning a whole TLD.
This is extremely annoying. Instead of fucking with other people’s companies why not build your own?<p>You pwned them? What are you twelve? All you did was commit a felony and post it online.
At this point I would not apply for a job if the employer used a third party online service. Seek out employers who do their own hiring and talk to candidates face-to-face.<p>If they steer you to one of these third party services, send your resume by snail mail directly to the HR director with a cover letter highlighting all the data breaches such as this one, LinkedIn, Indeed, etc. You'll stand out as someone who pays attention.
Firebase is like a half baked product which lures people who are just starting out .It helps build products which can quickly go to market, but then once you start to scale, a lot of their products like firestore, firebase auth have basic features missing
I would have stopped once I confirmed the leaked keys were valid. Looking at what types of data you had access to wasn't required. Downloading plaintext passwords of other people is probably too far. Impacted users may need to be notified about a breach. If needed, create an account of your own and target only that.<p>If there was a pentester agreement, safe harbor, or other protection that's different. Be careful out there.