I wonder if this was made by AI or a shit programmer
I wonder if this was made by AI or a shit programmer
106 comments
-
Believe it or not a lot of hacking is more like this than you think.
-
Social engineering is probably 95% of modern attack vectors. And that's not even unexpected, some highly regarded computer scientists and security researchers concluded this more than a decade ago.
-
I work in security and I kinda doubt this. There are plenty of issues just like what is outlined here that would be much easier to exploit than social engineering. Social engineering costs a lot more than
GET /secrets.json.There is good reason to be concerned about both, but 95% sounds way off and makes it sound like companies should allocate significantly more time to defend against social engineering, when they should first try to ensure social engineering is the easiest way to exploit their system. I can tell you from about a decade of experience that it typically isn't.
-
The percentage is closer to 75% than 95%.
-
Many years ago, I discovered that my then-employer’s “home built” e-commerce system had all user and admin passwords displayed in plaintext at home/admin/passwords.
When I brought this to the attention of leadership, they called the “developer” in and he said “oh, well, that’s IP locked, so no one on the web can access it!” When I pulled it up on my phone, he insisted my phone was on the work WiFi, despite it being clearly verifiable that was not the case. (The same work WiFi that had an open public connection, which is the one my phone would have been on, if it were on it…)
He did fix that, but many other issues remained. Eventually a new COO hired someone competent as his ‘backup’, replaced our website and finally suggested he pursue other employment opportunities before he could no longer voluntarily pursue them. (There was concern he might sabotage.)
-
I think that’s less about “hacking” and more about modern day devs being overworked by their hot-shit team lead and clueless PMs and creating “temporary” solutions that become permanent in the long run.
This bucket was probably something they set up early in the dev cycle so they could iterate components without needing to implement an auth system first and then got rushed into releasing before it could be fixed. That’s almost always how this stuff happens; whether it’s a core element or a rushed DR test.
-
modern day devs being overworked
And then there is meningspunktet.dk which had all the time in the world to do whatever they wanted, and even get their hosting paid for by a university. They still leaked everyones email, phone, full legal name and location on day one and only fixed it because I pointed it out.
-
-
Shodan lists 100'000s of publicly accessible security cameras.
-
If I was a hacker, I would just get a job as a night cleaning person at corporate office buildings. And then just help myself to the fucking post-it notes with usernames and passwords on them.
-
Security by obscurity.
-
-
AI just enables the shit programmers to create a greater volume of shit
-
I'll tape this to my office door.
-
-
I remember when a senior developer where i worked was tired of connecting to the servers to check its configuration, so they added a public facing rest endpoint that just dumped the entire active config, including credentials and secrets
That was a smaller slip-up than exposing a database like that (he just forgot that the config contained secrets) but still funny that it happened
-
That's not a "senior developer." That's a developer that has just been around for too long.
Secrets shouldn't be in configurations, and developers shouldn't be mucking around in production, nor with production data.
-
I would have put IP address access restrictions on that at the very least. I may have even done something like that more than once for various tools in the past.
That way it acts completely open to people (or other servers) in the right places and denies all knowledge to anything else.
-
-
This reminds me of how I showed a friend and her company how to get databases from BLS and it's basically all just text files with urls. "What API did you call? How did you scrape the data?"
Nah man, it's just... there. As government data should be. They called it a hack.
-
ah yes, the forbidden curl hack
-
-
What was the BASE_URL here? I’m guessing that’s like a profile page or something?
So then you still first have to get a URL to each profile? Or is this like a feed URL?
-
It's a public firebase bucket
-
Oh Jesus
-
🤦♂️
-
That should be criminally negligent.
-
-
Possibly from the decompiled APK. 404media reported that they found the same URL as the posted one in the APK (archive link).
-
-
Disabling index and making the names UUID would make the directory inviolable even if the address was publicly available.
-
Security through obscurity never works.
-
It's not security through obscurity in this case. The filenames can't be obtained or guessed through brute force. At least not with current technology or processing power...
Security through obscurity is when you hide implementation details.
Saying that my suggestion is security through obscurity is the same as telling that ASLR is security through obscurity...
-
-
-
Even the best models fine tuned for coding still have training that was based on both good and bad examples of programming from humans. And since it's not AGI but using probability to generate the code, you're going to get crap programming logic dependent on how often such things were used and suggested by humans to other humans. Googling for an answer on how to code something pulls up all sorts of answers from many sources, but reading through them, many are terrible. An LLM doesn't know that, it just knows that humans liked some answers better than others, so GIGO.
-
Gorilla In Gorilla Out?
-
Sounds like a good time
-
-
who'd have thought that javascript and client side programming was incredibly susceptible to security flaws and deeply unsafe
-
Securing the db is more of an ops thing.
-
I absolutely despise Firebase Firestore (the database technology that was "hacked"). It's like a clarion call for amateur developers, especially low rate/skill contractors who clearly picked it not as part of a considered tech stack, but merely as the simplest and most lax hammer out there. Clearly even DynamoDB with an API gateway is too scary for some professionals. It almost always interfaces directly with clients/the internet without sufficient security rules preventing access to private information (or entire database deletion), and no real forethought as to ongoing maintenance and technical debt.
A Firestore database facing the client directly on any serious project is a code smell in my opinion.
-
I think it's less about the tech picked and more about developers with no sense of security and a poor understanding of networking. I've seen far too many web applications where the developer needed some sort of database behind it (MySQL, PostGres, MSSQL) and so they stood up either a container or entire VM with a public IP and whatever the networking layer set to allow any IP to hit the database port. The excuse is almost always something like, "we needed the web front end to be able to reach the database, so we gave the database server/container a public IP and allowed access". Which is wonderful, right up until half of the IP addresses in Russia start trying to brute force the database.
-
-
Does anyone have a source for this?
-
The original article is paywalled (I mean, registration-walled?), this summary is not
404 Media reported that 4chan users claimed to be sharing personal data and selfies from Tea after discovering an exposed database.
-
-
I wonder if their data is poisoned by below average Dev. I mean if your test subjects are met or below Dev and mad Ethel lost 20% efficiency imagine what you can do to good dev
-
Not below average dev necessarily, but when posting code examples on the internet people often try to get a point across. Like how do I solve X? Here is code that solves X perfectly, the rest of the code is total crap, ignore that and focus on the X part. Because it's just an example, it doesn't really matter. But when it's used to train an LLM it's all just code. It doesn't know which parts are important and which aren't.
And this becomes worse when small little bits of code are included in things like tutorials. That means it's copy pasted all over the place, on forums, social media, stackoverflow etc. So it's weighted way more heavily. And the part where the tutorial said: "Warning, this code is really bad and insecure, it's just an example to show this one thing" gets lost in the shuffle.
Same thing when an often used pattern when using a framework gets replaced by new code where the framework does a little bit more so the same pattern isn't needed anymore. The LLM will just continue with the old pattern, even though there's often a good reason it got replaced (for example security issues). And if the new and old version aren't compatible with each other, you are in for a world of hurt trying to use an LLM.
And now with AI slop flooding all of these places where they used to get their data, it just becomes worse and worse.
These are just some of the issues why using an LLM for coding is probably a really bad idea.
-
Didn't expect this much. I don't think about tuto example being weighted heavier. This make sense.
-
Yeah, once you get the LLM's response you still have to go to the documentation to check whether it's telling the truth and the APIs it recommends are current. You're no better off than if you did an internet search and tried to figure out who's giving good advice, or just fumbled your own way through the docs in the first place.
-
-
-
Not a big fan of the wording here. Plenty of skilled programmers make dumb mistakes. There should always be systems in place to ensure these dumb mistakes don't make it to production. Especially when related to sensitive information. Where was the threat model and the system in place to enforce it? The idea that these problems are caused by "shit programmers" misses the real issue: there was either no system or an insufficient system to test features and define security requirements.
-
I can tell you exactly what happened. "Hey Claude, I need to configure and setup a DB with Firebase to store images from our application." and then promptly hit shift+tab and then went to go browse Reddit.
nothing was tested. nothing was verified. They let the AI do its thing they checked in on it after an hour or so. once it was done it was add all, commit -m "done", push origin master. AI doesn't implement security stuff. there was zero security here.
-
I have found the exact same type of bug shown here probably over a dozen times, most of those long before AI was writing code.
-
-
106 comments