|
klafbang posted:While it is easy to laugh at people for open S3 buckets, a lot of the blame should also go to Amazon. S3 buckets suck and access control is too complex. Just allow access without all of the IAM crap and service accounts already. Yeah, there really needs to either be a "Tutorial on securing your bucket" or extremely tight restrictions put in by default. Azure has the same issue IIRC with their version of buckets.
|
#
?
Nov 21, 2019 19:22
|
|
|
|
| # ? Apr 29, 2024 16:57 |
|
|
CommieGIR posted:Yeah, there really needs to either be a "Tutorial on securing your bucket" or extremely tight restrictions put in by default. To be fair, Amazon does make buckets locked off by default and give you quite loud warnings if you try making them public. They just make it really, REALLY hard to make any kind of access control on, and people don't realize/care to build an API between the bucket and applications running on untrusted devices. Funnily enough, access control from EC2 is reasonably easy to set up.
|
|
#
?
Nov 21, 2019 19:26
|
|
|
azure storage is also not public by default, although i have no idea what warnings show up if you try to make one public
|
|
#
?
Nov 21, 2019 19:28
|
|
|
amazon honey bucket
|
|
#
?
Nov 21, 2019 19:31
|
|
|
CommieGIR posted:Yeah, there really needs to either be a "Tutorial on securing your bucket" or extremely tight restrictions put in by default. amazon tells you not to make it public and sends out emails regularly if you have public buckets to make sure you actually want those public all the lifeguards in the world cant stop an idiot from making GBS threads in the pool. people who do that poo poo deserve it, should be fired (and probably personally fined/jailed if its sensitive enough) and shouldn't be in charge of networked resources in general.
|
|
#
?
Nov 21, 2019 19:56
|
|
|
There is a (bad) pattern where you host documents you share via special url. https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html So you can't enumerate the contents of the bucket over http but if you happen to know the url is http://mys3bucket.amazonaws.com/deadbeef800835/doc.pdf you can download it. People use this to grant access to docs without auth. It's possible that this was the case here and someone put the list of these urls in public github 
|
|
#
?
Nov 21, 2019 20:18
|
|
|
does amazon trip and ban you if you guess the wrong filename too many times, or can you write a script to just bang out numerous possible filenames
|
|
#
?
Nov 21, 2019 22:58
|
|
|
Farmer Crack-rear end posted:does amazon trip and ban you if you guess the wrong filename too many times, or can you write a script to just bang out numerous possible filenames if you want to try to brute force a modern cryptographic signature, I doubt anyone’s going to bother to try and stop you assuming you’re talking about the things the post above yours was talking about I mean. idk about random buckets
|
|
#
?
Nov 21, 2019 23:48
|
|
|
What I do know is that Amazon S3 bucket names are globally unique (e.g. if I were to create a bucket called 'yospos' you wouldn't be able to), and that an API call to a private bucket that exists anywhere in the world but you don't have access to, returns a different error message than an API call to a bucket that doesn't exist at all. So this way you could build up a list of private buckets that exist at some moment in time but I'd guess AWS would start throttling you at some point.
|
|
#
?
Nov 22, 2019 07:39
|
|
|
Farmer Crack-rear end posted:does amazon trip and ban you if you guess the wrong filename too many times, or can you write a script to just bang out numerous possible filenames these aren't just "is the filename right" but are signed URLs using your credentials, that are time based. you can even set the expiration time (which is encoded in the URL signed with your key) that lets you set the expiration as low as 1 minute. nobody is ever going to guess it.
|
|
#
?
Nov 22, 2019 13:43
|
|
|
Carbon dioxide posted:What I do know is that Amazon S3 bucket names are globally unique (e.g. if I were to create a bucket called 'yospos' you wouldn't be able to), and that an API call to a private bucket that exists anywhere in the world but you don't have access to, returns a different error message than an API call to a bucket that doesn't exist at all. They don't throttle at all, I did this a while ago and also indexed contents and permissions where possible https://twitter.com/hilare_belloc/status/1018922843290161154?s=19 https://twitter.com/hilare_belloc/status/1027622205062955008?s=19
|
|
#
?
Nov 22, 2019 14:53
|
|
|
jre posted:There is a (bad) pattern where you host documents you share via special url. 1. What is bad about presigned URLs? They are very useful. 2. Your example is not a presigned URL. 3. No this is not what happened. The bucket was public. That’s a bad pattern. Sorry, mildly triggered AWS engineer here.
|
|
#
?
Nov 22, 2019 18:08
|
|
|
Rufus Ping posted:They don't throttle at all, I did this a while ago and also indexed contents and permissions where possible yeah this is exactly what i was wondering about hilarious
|
|
#
?
Nov 22, 2019 18:22
|
|
|
Adhemar posted:1. What is bad about presigned URLs? They are very useful. 
|
|
#
?
Nov 22, 2019 19:06
|
|
|
 mequote:We are reaching out to you directly as we have discovered that part of your order information was accessed by an unauthorized party. We can confirm that your payment information, password and account are safe, but your name, contact number, email and shipping address may have been exposed. edit: I mean I assume oneplus is sending all my data to China already so this is not really much worse
|
|
#
?
Nov 22, 2019 19:07
|
|
|
CRIP EATIN BREAD posted:these aren't just "is the filename right" but are signed URLs using your credentials, that are time based. you can even set the expiration time (which is encoded in the URL signed with your key) that lets you set the expiration as low as 1 minute. you can also do this locally with nginx btw, we used that at a previous job
|
|
#
?
Nov 22, 2019 20:29
|
|
|
s3 also suffers from its legacy security model where object acls and bucket acls are handled in a different way so a bucket can be private but objects might be public
|
|
#
?
Nov 22, 2019 22:05
|
|
|
Hi everyone. A few years ago I asked you kind souls for book recommendations about cryptography and a very wise person suggested The Code Book by Simon Singh which rocked and I'm very grateful. There's something about the way that the book was written that really held my interest in a way that few books have. It's weird. My question: Is there a book written in a similar style/tone about the history of cyberwarfare, or a sort of overview Nation/State activities in the space? Sorry if I'm dropping this in the wrong place and killing the vibe.
|
|
#
?
Nov 23, 2019 05:19
|
|
|
secfuck: my vibe!
|
|
#
?
Nov 23, 2019 05:20
|
|
|
Adhemar posted:1. What is bad about presigned URLs? They are very useful. They give a false sense of security, anyone with the url can access the object. quote:2. Your example is not a presigned URL.  quote:3. No this is not what happened. The bucket was public. That’s a bad pattern. quote:One of their repositories contained a script that included the URLs of PDFs hosted on unprotected Amazon servers. These URLs did not require authentication to access, and Motherboard was able to scrape them en masse
|
|
#
?
Nov 23, 2019 13:54
|
|
|
jre posted:They give a false sense of security, anyone with the url can access the object. until the presigned URL expires but any kind of file hosting is just a false sense of security by that standard, since you can just share the other request headers needed to make the thing work these leaks come from either indexes being enabled or predictable file names; if the file name starts with a big enough random enough thing it’s not an issue
|
|
#
?
Nov 23, 2019 14:10
|
|
|
direct object links are real because object acls take precedence over both bucket acls and bucket policies. it's hosed up and aws should have killed off the distinction between per object and per bucket permissions years ago
|
|
#
?
Nov 23, 2019 14:20
|
|
|
https://www.dataviper.io/blog/2019/pdl-data-exposure-billion-people/ public elasticsearch
|
|
#
?
Nov 23, 2019 14:23
|
|
|
cinci zoo sniper posted:https://www.dataviper.io/blog/2019/pdl-data-exposure-billion-people/ Yes. I got a hibp mail about this. I never gave those assholes any information, they just scraped it from the web somehow.
|
|
#
?
Nov 23, 2019 16:12
|
|
|
from the tesla threadTheFluff posted:the powerwall 2 has some pretty amazing secfucks in it
|
|
#
?
Nov 23, 2019 16:14
|
|
|
plausible deniability of arson secfuck
|
|
#
?
Nov 23, 2019 16:18
|
|
|
AARP LARPer posted:Hi everyone. A few years ago I asked you kind souls for book recommendations about cryptography and a very wise person suggested The Code Book by Simon Singh which rocked and I'm very grateful. There's something about the way that the book was written that really held my interest in a way that few books have. It's weird. I'm not familiar with the book you mentioned but I've recommended the book Dark Territory for people interested in the subject before and they enjoyed it.
|
|
#
?
Nov 23, 2019 18:23
|
|
|
how is that a data breach when its just consolidating publicly accessible information people willing provide
|
|
#
?
Nov 23, 2019 18:44
|
|
|
power botton posted:how is that a data breach when its just consolidating publicly accessible information people willing provide because not all of it is publicly accessible: a) at the present b) ever at all c) linked/assembled in a specific manner
|
|
#
?
Nov 23, 2019 19:04
|
|
|
power botton posted:how is that a data breach when its just consolidating publicly accessible information people willing provide The HIBP guy wrote a blog post about it: quote:What's immediately obvious is the alignment to data I've consciously and deliberately published to LinkedIn so that it's publicly accessible. One look at my LinkedIn profile makes it very clear where much of this data has been sourced from so on the one hand, you could reasonably argue there's nothing either sensational nor particularly newsworthy about this breach. Yet on the other hand... Basically, he wanted to and it gets his site publicity/outrage shares. He backs his position with a Twitter poll responding to a different question.
|
|
#
?
Nov 23, 2019 19:21
|
|
|
power botton posted:how is that a data breach when its just consolidating publicly accessible information people willing provide because public/not public isn't a useful binary, you gotta consider if public data is in a big useful named bundle vs. scattered across a thousand pastebins it's more important to you sure it only ever moves in one direction, but it's still good to know when "nebulous threat" becomes "immediate threat"
|
|
#
?
Nov 23, 2019 19:26
|
|
|
jre posted:They give a false sense of security, anyone with the url can access the object. Yes, that’s literally the intended purpose of presigned URLs. That’s why they’re intended to be secret, should be time limited, and not stored anywhere, let alone in a public GitHub repo. jre posted:What are you basing that statement on ? I interpreted “unprotected Amazon servers” as non-techie speak for open buckets. Seems like other goons did too.  . Otherwise there were 160 separate presigned URLs stored in GitHub, and all of them had not yet expired. Seems less likely than just another open bucket.If you’re right though,it would just be a spectacularly bad use of presigned URLs (see reasons above). They have legitimate use cases and are incredibly widely used. We even use them internally in our own AWS services.
|
|
#
?
Nov 23, 2019 20:09
|
|
|
Adhemar posted:Yes, that’s literally the intended purpose of presigned URLs. That’s why they’re intended to be secret, should be time limited, and not stored anywhere, let alone in a public GitHub repo. presigned urls aren't the only way to access objects in s3. every object has a canonical url and object acls, bucket acls, and bucket policies make it trivial to make those objects publicly accessible.
|
|
#
?
Nov 23, 2019 20:13
|
|
|
Adhemar posted:Yes, that’s literally the intended purpose of presigned URLs. That’s why they’re intended to be secret, should be time limited, and not stored anywhere, let alone in a public GitHub repo. Something I didn't realise was the max signature age is 7 days, so more likely to be unpredictable urls, rather than proper signed urls.
|
|
#
?
Nov 23, 2019 20:16
|
|
|
Rufus Ping posted:They don't throttle at all, I did this a while ago and also indexed contents and permissions where possible Is there a bucket named mycrimes?
|
|
#
?
Nov 23, 2019 20:29
|
|
|
power botton posted:how is that a data breach when its just consolidating publicly accessible information people willing provide Imagine if someone made a website called "Is Power Botton home" and they point a camera at your house and publish graphs of what times you come and go. All that data is public, but you would be right to be mad that someone was aggregating, storing and publishing it.
|
|
#
?
Nov 23, 2019 20:55
|
|
|
Blinkz0rz posted:presigned urls aren't the only way to access objects in s3. every object has a canonical url and object acls, bucket acls, and bucket policies make it trivial to make those objects publicly accessible. I know, we can speculate what caused the breach all day long, that’s not why I chimed in. Regardless of this WeWork breach, I just objected to jre’s statement that presigned URLs are inherently bad. They’re useful, but can be used poorly, like any feature.
|
|
#
?
Nov 23, 2019 21:04
|
|
|
presigned urls are the best we're able to run a massive document ingestion pipeline because our on-prem component signals its intent to send data to our edge services which generate presigned urls to send the docs gently caress ingesting petabytes through a service which has to be scaled exponentially let aws do it
|
|
#
?
Nov 23, 2019 21:11
|
|
|
presigned urls are how you should be granting external access to data in s3 they're inherently timeboxed and are narrowly scoped
|
|
#
?
Nov 23, 2019 21:13
|
|
|
|
| # ? Apr 29, 2024 16:57 |
|
|
A Man With A Plan posted:I'm not familiar with the book you mentioned but I've recommended the book Dark Territory for people interested in the subject before and they enjoyed it. Thank you for the recommendation. I’ll start there.
|
|
#
?
Nov 24, 2019 04:18
|
|