▲ 445 ▼ Tea App A Second Tea Breach Reveals Users’ DMs About Abortions and Cheating (www.404media.co) submitted 1 year ago by themachinestops@lemmy.dbzer0.com to c/technology@lemmy.world 112 comments fedilink hide all child comments https://www.bleepingcomputer.com/news/security/tea-app-leak-worsens-with-second-database-exposing-user-chats/ https://redlib.orangenet.cc/r/AskWomen/comments/1m9ydcn/what_iswas_the_tea_app_actually_like/
[–] gravitas_deficiency@sh.itjust.works 49 points 1 year ago (12 children) This is why you don’t vibe code a webservice permalink fedilink source hideshow 12 child comments replies: [–] FauxLiving@lemmy.world 22 points 1 year ago (10 children) This wasn't vibe coding, it's incompetant devops. You have to go out of your way to make these buckets public like this. Several giant "Everyone will have access to this" warnings, re-authentication, a permanent warning symbol on the dashboard AND regular e-mails reminding you that you have a public bucket. I don't even think you can do this via the API, it requires a human to manually make this setting. I'm guessing that they couldn't figure out how to configure the Access Control Lists and just made it public so that it would work. That's fine in a test environment, without any user data but it's pure incompetence to have a production system setup this way. permalink fedilink source parent hideshow 10 child comments replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago* (2 children) I don’t even think you can do this via the API Someone never heard of terraform & similar configuration management software? They enable configuration as code, which can be vibe coded. Practically anything online can be configured via API, especially cloud services. permalink fedilink source parent hideshow 2 child comments replies: [–] echodot@feddit.uk 1 point 1 year ago* (1 child) I'm pretty certain you would still get the constant emails though. I don't think there's a way to turn those off other than to secure the bucket. Anyway I still maintain that an AI wouldn't have made this mistake so the fact the mistake was made kind of implies that it wasn't vibe coded. permalink fedilink source parent hideshow 1 child comment replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago I don't know, man: AI assistants can put out some really stupid code, and whoever wants shit to "just work" doesn't care how. If the developers work in a team, those emails may end up going to whomever holds the company credit card who doesn't necessarily understand/know/care. permalink fedilink source parent [–] gravitas_deficiency@sh.itjust.works 8 points 1 year ago (5 children) I’d say it’s not fine in a test environment, because then your test env S3 bucket is publicly available. permalink fedilink source parent hideshow 5 child comments replies: [–] echodot@feddit.uk 2 points 1 year ago (1 child) Yeah I could see it being left like this for an hour or so while someone finds out what the actual security configurations are supposed to be, during which time it wouldn't have any data in it. But to leave it like this for any period of time is ridiculous and to release it like this is criminal. permalink fedilink source parent hideshow 1 child comment replies: [–] gravitas_deficiency@sh.itjust.works 1 point 1 year ago I’m sorry, no - this is something you just simply don’t so. Source: most of my career permalink fedilink source parent [–] FauxLiving@lemmy.world 0 points 1 year ago (2 children) It's not great, but it's an acceptable kludge if you're the one holding everyone back and you can't figure out the problem immediately. Set it to public, let the devs get to work and research the problem until you find a real solution. The test environment data should be generic so if someone were to discover the bucket they'll get some pictures of cats and a bunch of people who live at 12345 anywhere street. permalink fedilink source parent hideshow 2 child comments replies: [–] gravitas_deficiency@sh.itjust.works 10 points 1 year ago It’s a bad idea to leave your S3 perms wide open, because then anyone can use your S3 bucket for whatever reason they want, and it’ll hit your wallet. And if they can’t figure out basic IAM and ACLs, I’m also betting they can’t figure out “requester pays” permalink fedilink source parent [–] blargh513@sh.itjust.works 8 points 1 year ago What? No, this is a horrible practice. If you can't figure out how to set identity-based ACLs you shouldn't be working in technology! Oh I'll just set this shit to any/any and figure out later. FUCK ANYONE WHO DOES THIS IN THEIR LEFT EAR. permalink fedilink source parent [–] loudwhisper@infosec.pub 2 points 1 year ago* (last edited 1 year ago) If I were in the security team of that company, I would never accept ACLs on the bucket as a sufficient compensating control for this risk. Here the best most reasonable would be encryption, which would make the bucket being public relatively unimportant. When you are collecting so sensitive data (potentially including personal data of people not using your service), you simply can't even imagine doing that by storing the data unencrypted. Edit: grammar permalink fedilink source parent [–] echodot@feddit.uk 2 points 1 year ago Even an AI wouldn't do something this stupid. Every piece of information it its data set about Firebase would have told it to secure the database. permalink fedilink source parent
[–] FauxLiving@lemmy.world 22 points 1 year ago (10 children) This wasn't vibe coding, it's incompetant devops. You have to go out of your way to make these buckets public like this. Several giant "Everyone will have access to this" warnings, re-authentication, a permanent warning symbol on the dashboard AND regular e-mails reminding you that you have a public bucket. I don't even think you can do this via the API, it requires a human to manually make this setting. I'm guessing that they couldn't figure out how to configure the Access Control Lists and just made it public so that it would work. That's fine in a test environment, without any user data but it's pure incompetence to have a production system setup this way. permalink fedilink source parent hideshow 10 child comments replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago* (2 children) I don’t even think you can do this via the API Someone never heard of terraform & similar configuration management software? They enable configuration as code, which can be vibe coded. Practically anything online can be configured via API, especially cloud services. permalink fedilink source parent hideshow 2 child comments replies: [–] echodot@feddit.uk 1 point 1 year ago* (1 child) I'm pretty certain you would still get the constant emails though. I don't think there's a way to turn those off other than to secure the bucket. Anyway I still maintain that an AI wouldn't have made this mistake so the fact the mistake was made kind of implies that it wasn't vibe coded. permalink fedilink source parent hideshow 1 child comment replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago I don't know, man: AI assistants can put out some really stupid code, and whoever wants shit to "just work" doesn't care how. If the developers work in a team, those emails may end up going to whomever holds the company credit card who doesn't necessarily understand/know/care. permalink fedilink source parent [–] gravitas_deficiency@sh.itjust.works 8 points 1 year ago (5 children) I’d say it’s not fine in a test environment, because then your test env S3 bucket is publicly available. permalink fedilink source parent hideshow 5 child comments replies: [–] echodot@feddit.uk 2 points 1 year ago (1 child) Yeah I could see it being left like this for an hour or so while someone finds out what the actual security configurations are supposed to be, during which time it wouldn't have any data in it. But to leave it like this for any period of time is ridiculous and to release it like this is criminal. permalink fedilink source parent hideshow 1 child comment replies: [–] gravitas_deficiency@sh.itjust.works 1 point 1 year ago I’m sorry, no - this is something you just simply don’t so. Source: most of my career permalink fedilink source parent [–] FauxLiving@lemmy.world 0 points 1 year ago (2 children) It's not great, but it's an acceptable kludge if you're the one holding everyone back and you can't figure out the problem immediately. Set it to public, let the devs get to work and research the problem until you find a real solution. The test environment data should be generic so if someone were to discover the bucket they'll get some pictures of cats and a bunch of people who live at 12345 anywhere street. permalink fedilink source parent hideshow 2 child comments replies: [–] gravitas_deficiency@sh.itjust.works 10 points 1 year ago It’s a bad idea to leave your S3 perms wide open, because then anyone can use your S3 bucket for whatever reason they want, and it’ll hit your wallet. And if they can’t figure out basic IAM and ACLs, I’m also betting they can’t figure out “requester pays” permalink fedilink source parent [–] blargh513@sh.itjust.works 8 points 1 year ago What? No, this is a horrible practice. If you can't figure out how to set identity-based ACLs you shouldn't be working in technology! Oh I'll just set this shit to any/any and figure out later. FUCK ANYONE WHO DOES THIS IN THEIR LEFT EAR. permalink fedilink source parent [–] loudwhisper@infosec.pub 2 points 1 year ago* (last edited 1 year ago) If I were in the security team of that company, I would never accept ACLs on the bucket as a sufficient compensating control for this risk. Here the best most reasonable would be encryption, which would make the bucket being public relatively unimportant. When you are collecting so sensitive data (potentially including personal data of people not using your service), you simply can't even imagine doing that by storing the data unencrypted. Edit: grammar permalink fedilink source parent
[–] lmmarsano@lemmynsfw.com 1 point 1 year ago* (2 children) I don’t even think you can do this via the API Someone never heard of terraform & similar configuration management software? They enable configuration as code, which can be vibe coded. Practically anything online can be configured via API, especially cloud services. permalink fedilink source parent hideshow 2 child comments replies: [–] echodot@feddit.uk 1 point 1 year ago* (1 child) I'm pretty certain you would still get the constant emails though. I don't think there's a way to turn those off other than to secure the bucket. Anyway I still maintain that an AI wouldn't have made this mistake so the fact the mistake was made kind of implies that it wasn't vibe coded. permalink fedilink source parent hideshow 1 child comment replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago I don't know, man: AI assistants can put out some really stupid code, and whoever wants shit to "just work" doesn't care how. If the developers work in a team, those emails may end up going to whomever holds the company credit card who doesn't necessarily understand/know/care. permalink fedilink source parent
[–] echodot@feddit.uk 1 point 1 year ago* (1 child) I'm pretty certain you would still get the constant emails though. I don't think there's a way to turn those off other than to secure the bucket. Anyway I still maintain that an AI wouldn't have made this mistake so the fact the mistake was made kind of implies that it wasn't vibe coded. permalink fedilink source parent hideshow 1 child comment replies: [–] lmmarsano@lemmynsfw.com 1 point 1 year ago I don't know, man: AI assistants can put out some really stupid code, and whoever wants shit to "just work" doesn't care how. If the developers work in a team, those emails may end up going to whomever holds the company credit card who doesn't necessarily understand/know/care. permalink fedilink source parent
[–] lmmarsano@lemmynsfw.com 1 point 1 year ago I don't know, man: AI assistants can put out some really stupid code, and whoever wants shit to "just work" doesn't care how. If the developers work in a team, those emails may end up going to whomever holds the company credit card who doesn't necessarily understand/know/care. permalink fedilink source parent
[–] gravitas_deficiency@sh.itjust.works 8 points 1 year ago (5 children) I’d say it’s not fine in a test environment, because then your test env S3 bucket is publicly available. permalink fedilink source parent hideshow 5 child comments replies: [–] echodot@feddit.uk 2 points 1 year ago (1 child) Yeah I could see it being left like this for an hour or so while someone finds out what the actual security configurations are supposed to be, during which time it wouldn't have any data in it. But to leave it like this for any period of time is ridiculous and to release it like this is criminal. permalink fedilink source parent hideshow 1 child comment replies: [–] gravitas_deficiency@sh.itjust.works 1 point 1 year ago I’m sorry, no - this is something you just simply don’t so. Source: most of my career permalink fedilink source parent [–] FauxLiving@lemmy.world 0 points 1 year ago (2 children) It's not great, but it's an acceptable kludge if you're the one holding everyone back and you can't figure out the problem immediately. Set it to public, let the devs get to work and research the problem until you find a real solution. The test environment data should be generic so if someone were to discover the bucket they'll get some pictures of cats and a bunch of people who live at 12345 anywhere street. permalink fedilink source parent hideshow 2 child comments replies: [–] gravitas_deficiency@sh.itjust.works 10 points 1 year ago It’s a bad idea to leave your S3 perms wide open, because then anyone can use your S3 bucket for whatever reason they want, and it’ll hit your wallet. And if they can’t figure out basic IAM and ACLs, I’m also betting they can’t figure out “requester pays” permalink fedilink source parent [–] blargh513@sh.itjust.works 8 points 1 year ago What? No, this is a horrible practice. If you can't figure out how to set identity-based ACLs you shouldn't be working in technology! Oh I'll just set this shit to any/any and figure out later. FUCK ANYONE WHO DOES THIS IN THEIR LEFT EAR. permalink fedilink source parent
[–] echodot@feddit.uk 2 points 1 year ago (1 child) Yeah I could see it being left like this for an hour or so while someone finds out what the actual security configurations are supposed to be, during which time it wouldn't have any data in it. But to leave it like this for any period of time is ridiculous and to release it like this is criminal. permalink fedilink source parent hideshow 1 child comment replies: [–] gravitas_deficiency@sh.itjust.works 1 point 1 year ago I’m sorry, no - this is something you just simply don’t so. Source: most of my career permalink fedilink source parent
[–] gravitas_deficiency@sh.itjust.works 1 point 1 year ago I’m sorry, no - this is something you just simply don’t so. Source: most of my career permalink fedilink source parent
[–] FauxLiving@lemmy.world 0 points 1 year ago (2 children) It's not great, but it's an acceptable kludge if you're the one holding everyone back and you can't figure out the problem immediately. Set it to public, let the devs get to work and research the problem until you find a real solution. The test environment data should be generic so if someone were to discover the bucket they'll get some pictures of cats and a bunch of people who live at 12345 anywhere street. permalink fedilink source parent hideshow 2 child comments replies: [–] gravitas_deficiency@sh.itjust.works 10 points 1 year ago It’s a bad idea to leave your S3 perms wide open, because then anyone can use your S3 bucket for whatever reason they want, and it’ll hit your wallet. And if they can’t figure out basic IAM and ACLs, I’m also betting they can’t figure out “requester pays” permalink fedilink source parent [–] blargh513@sh.itjust.works 8 points 1 year ago What? No, this is a horrible practice. If you can't figure out how to set identity-based ACLs you shouldn't be working in technology! Oh I'll just set this shit to any/any and figure out later. FUCK ANYONE WHO DOES THIS IN THEIR LEFT EAR. permalink fedilink source parent
[–] gravitas_deficiency@sh.itjust.works 10 points 1 year ago It’s a bad idea to leave your S3 perms wide open, because then anyone can use your S3 bucket for whatever reason they want, and it’ll hit your wallet. And if they can’t figure out basic IAM and ACLs, I’m also betting they can’t figure out “requester pays” permalink fedilink source parent
[–] blargh513@sh.itjust.works 8 points 1 year ago What? No, this is a horrible practice. If you can't figure out how to set identity-based ACLs you shouldn't be working in technology! Oh I'll just set this shit to any/any and figure out later. FUCK ANYONE WHO DOES THIS IN THEIR LEFT EAR. permalink fedilink source parent
[–] loudwhisper@infosec.pub 2 points 1 year ago* (last edited 1 year ago) If I were in the security team of that company, I would never accept ACLs on the bucket as a sufficient compensating control for this risk. Here the best most reasonable would be encryption, which would make the bucket being public relatively unimportant. When you are collecting so sensitive data (potentially including personal data of people not using your service), you simply can't even imagine doing that by storing the data unencrypted. Edit: grammar permalink fedilink source parent
[–] echodot@feddit.uk 2 points 1 year ago Even an AI wouldn't do something this stupid. Every piece of information it its data set about Firebase would have told it to secure the database. permalink fedilink source parent