[HN Gopher] Problems with disk encryption in AWS
___________________________________________________________________
Problems with disk encryption in AWS
Author : DrRobinson
Score : 34 points
Date : 2022-12-16 13:50 UTC (9 hours ago)
(HTM) web link (tmp.bearblog.dev)
(TXT) w3m dump (tmp.bearblog.dev)
| badrabbit wrote:
| It helps you trust the data protection and destruction policies
| of AWS less. If a disk goes bad, will it be wiped properly before
| being discarded for example? Or will your confidential data be
| recoverable by anyone at the landfill? What if an AWS DC tech
| identifies the bare metal your VM runs on and replaces a disk in
| the raid and takes the old one home? How good is their security
| to prevent that from happening? I can think a few ways of getting
| that past man trap xray scanners and all that physical security.
| Ruq wrote:
| If you're complaining about encryption, you're doing it wrong.
| salawat wrote:
| Counterpoint:
|
| How many ways are there to do it wrong than to do it right?
| hanselot wrote:
| What about protecting your data from AWS?
| hk1337 wrote:
| > Delete the key and your data is gone
|
| That's pretty much the case for any type of encryption.
| cj wrote:
| > But what problems does it solve? Are you worried about someone
| breaking into the AWS data center, stealing the specific disks
| your data is stored on, and restoring and analyzing the disk data
| to target your organization? Just imagine how much effort such an
| attack would take.
|
| This sounds like it's coming from someone who's forgetting that
| all of our data in "the cloud" resides in physical buildings
| throughout the world, which are all high value targets for
| physical attacks.
|
| I don't think it's an antiquated idea to protect against physical
| data center attacks. It's best practice.
| orev wrote:
| Disk encryption is far more effective in addressing risks for
| devices like laptops, desktops, etc. that are not always locked
| inside an ISO27000 compliant data center that has tons of
| physical security controls.
|
| Could a data center break-in happen? Sure. Is it likely? No.
| When used in a data center, FDE is mostly useful when media is
| being transported or disposed, as an extra layer of protection.
|
| I'm not saying it shouldn't be used, but when comparing using
| FDE in other situations vs. a data center, in a data center the
| physical risk is far lower.
| flaviut wrote:
| Does AWS not already do full-disk encryption transparently on
| their side?
|
| If they do, I trust them to be good stewards of their keys. If
| not, then why not? I don't know about the enterprise part of
| the market, but I know consumer SSDs come with encryption
| permanently enabled in the firmware.
| osigurdson wrote:
| >> but I know consumer SSDs come with encryption permanently
| enabled in the firmware
|
| Where is the encryption key? It seems that it must be in the
| firmware itself. Presumably it would be possible to find this
| with enough effort.
| flaviut wrote:
| 2 ways I know this works:
|
| - the drive can request the key on each boot - the drive
| stores the key in the firmware, but part of the de-
| provisioning process would be to reset this key
| ckozlowski wrote:
| The key is stored in KMS, not on the drive firmware. You
| can read more about how this is done here, in the section
| at the bottom about "Isolation of Physical Hosts" https://d
| ocs.aws.amazon.com/kms/latest/developerguide/concep...
|
| But in short, the key is kept in memory on the HSM, and
| employees don't have access to it. They key can be
| referenced, but not actually read.
|
| It also means that if a user accidentally deletes their
| key, there's no recovery. That's it. (Pro tip: Deleting a
| key is a faster mechanism to make data unreadable than
| deleting the data itself. ;)
|
| Disclaimer: I'm an S-TAM with AWS.
| bmcahren wrote:
| The basis of this take is "because it doesn't happen very often,
| it's snake oil". Has DrRobinson considered that the mere fact
| they think this is proof it works?
|
| The entire point of encryption at rest (on the cloud) is that
| when any of the following happen you have nothing to worry about.
|
| 1. A machine/disk is rendered inoperable and can't be wiped.
|
| 2. The data stream coming off of a disk cluster is tapped.
|
| 3. An employee steals a disk or is lost.
|
| 4. An actor violates their account segmentation and can read raw
| data from segments of YOUR sectors of the shared disk.
|
| 5. SSD firmware goes bad/gets hacked and starts returning
| incorrect sectors of disk.
|
| 6. Memory pointers go bad and return sectors from the wrong area
| of the disk.
|
| It's incredibly naive to not use encryption at rest on AWS with
| how incredibly easy and problem free it is to deploy.
| DrRobinson wrote:
| I agree calling it snake oil is a bit too much, because I know
| there are benefits.
|
| As I mention elsewhere in the thread, I use encryption, but I
| don't consider it to be of high value compared to other
| security mitigations one can spend time on.
|
| As mentioned in the blog post, setting up encryption isn't
| always easy and problem free though.
|
| Regarding 1, disks are physically destroyed if they are
| inoperable. Thanks for sharing the list of potential problems,
| it's always interesting to see how other people think and what
| they worry about!
| pixl97 wrote:
| >disks are physically destroyed if they are inoperable
|
| 'Supposed to be' is missing from this statement. We have seen
| many vendors over the years say 'we destroy disks' only to
| have a disk show up in the wild.
| ThePowerOfFuet wrote:
| > It's incredibly naive to not use encryption at rest on AWS
| with how incredibly easy and problem free it is to deploy.
|
| It shocks me that this isn't on-by-default in AWS like it is on
| GCP.
| acdha wrote:
| Backwards compatibility -- GCP started enough later that
| their hardware could do this at close to zero cost but by
| then AWS had many large customers who had made decisions
| based on the performance delta.
|
| By now that's moot so I'd assume they'll set it by default
| for new accounts at some point but there's a regional option
| which you can turn on by default:
|
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry.
| ..
|
| If you use tools like Security Hub with the Amazon
| Foundational Security Best Practices suite of controls
| enabled there's a specific check for that setting:
|
| https://docs.aws.amazon.com/securityhub/latest/userguide/sec.
| ..
| greenthrow wrote:
| This is a low quality article. Disk encryption at rest has a
| bunch of reasons to be required besides someone breaking into AWS
| to steal the disk (and someone could bribe an employee to do that
| as easily as bribe an employee to steal your data digitially.)
|
| This blog post is like someone complaining "parameterized queries
| are so much more of a pain than just using string interpolation
| to build my queries. I'd never allow SQL injection in my app."
| Hubris of an inexperienced engineer imho.
| DrRobinson wrote:
| > Hubris of an inexperienced engineer imho.
|
| This seems unnecessarily hostile. I've worked with cloud
| infrastructure and security for more than 10 years. If you have
| experience of unencrypted disks being stolen from AWS I'm very
| interested to hear about it.
|
| Note, though, that I don't claim one shouldn't encrypt disks,
| but I consider it to be very low on the list of priorities when
| it comes to lowering risk. There is almost always risk-lowering
| actions with better cost:benefit ratio than encrypting disks in
| the cloud, since that risk is already so low.
| [deleted]
| ctvo wrote:
| tl;dr author finds it a hassle to set up proper encryption at
| rest and rationalizes away why they shouldn't need to do it.
|
| > You used the AWS default key to encrypt a database?
|
| Don't do that? Create a separate account to hold keys. Lock it
| down like you would your domain DNS or anything else with
| security implications that will impact your entire company.
|
| Share granular read permissions across accounts as needed to
| encrypt / decrypt.
|
| Agreed it's time consuming to initially setup, but it's a solved
| problem and can be implemented with your IaC flavor of choice
| (CloudFormation directly, CDK, Terraform, ...).
| DrRobinson wrote:
| Hello, author here!
|
| What you describe is essentially what I currently do. But I've
| inherited an infrastructure that was not setup that way, and
| re-encrypting things has been very time consuming.
|
| The company I'm at now use multiple AWS accounts where teams
| have their own accounts, and it's common for people to forget
| to use KMS when creating databases or similar. I might have
| just failed in my search but I couldn't find any way to block
| default keys via SCPs. If you have any suggestions for that I'm
| happy to take them!
| osigurdson wrote:
| >> Are you worried about someone breaking into the AWS data
| center, stealing the specific disks your data is stored on, and
| restoring and analyzing the disk data to target your
| organization?
|
| Is this really the only vector for data leakage?
| fragmede wrote:
| How to exfiltrate data is a large topic of discussion. A rogue
| developer copying the production database to their laptop is
| another threat, but then they have to copy the data from there,
| so then you disable USB devices on endpoints. It's an ongoing
| battle.
| tekla wrote:
| This is just a "its annoying to do things properly at a bare
| minimum level" blog post
| meepmorp wrote:
| I disagree that encryption at rest with AWS is actually the
| proper way. If someone can get to the actual hardware and steal
| disks, I can't trust that AWS hasn't also lost control of the
| encryption keys.
| cj wrote:
| Something is better than nothing, though.
|
| Just because something isn't 100% perfect in every scenario
| doesn't mean it shouldn't be done at all.
|
| But I agree with your point, if you're really worried about
| data to the point where you don't trust AWS with encryption
| keys, you should self-manage your keys and manually
| encrypt/decrypt data without AWS KMS.
| ratg13 wrote:
| Swiss Cheese Model
|
| https://en.wikipedia.org/wiki/Swiss_cheese_model
|
| AKA defense-in-depth
|
| Relying on one control is a recipe for failure, which is why
| security measures work best when layered.
|
| You don't trust in one control, you trust that you stack
| enough controls that one of them works.
| eloff wrote:
| I think the author and the commenters here are using two
| different threat models. A lot of people here are saying you
| should encrypt the disks because it's best practice for security.
| Or because it protects against some specific, if implausible,
| scenario. They're talking about theoretical security.
|
| The author is saying the probability that it improves your
| security is so low that any time it takes away from other
| security related work is actually making your security worse.
| That's a different threat model, and it's probably the better way
| to approach security, and the author is probably correct - if he
| actually uses that saved time to improve security in other ways.
|
| I have a question though, what are the laws that require
| encryption? I can think of HIPPA, SOC2 maybe? What about GDPR?
| lazide wrote:
| There are secondary effects to not using encryption you can
| see.
|
| For instance, it greatly expands the scope of 'I lost your
| data/I exposed your data' notifications in places like
| California, and for those under many of those other rulesets.
|
| Someone getting access to a repo of encrypted drive images, or
| someone losing an encrypted drive, doesn't count. And for
| reasonableish reasons.
|
| It's a basic risk mitigation/blast radius limiting move.
|
| For physical/on-prem especially, since old disks tend to
| 'wander' after retirement, and it's a great idea to always have
| had them full disk encrypted to reduce the odds someone
| sensitive gets exposed years down the line.
| acdha wrote:
| It's more that the author is arguing that their inexperience is
| universally applicable. "Why do banks have guards, I've never
| had someone break into my couch cushions?"
|
| Beyond the compliance requirements (e.g. CIS), it's wrong to
| assume that disks are always perfectly disposed of - simply
| never having to worry about featuring in one of those "look
| what I found on eBay!" posts and notifying your customers is
| worth the basically non-existent cost of basic encryption. It's
| something you turn on and basically never think about again -
| the performance hit disappeared around 2010 and it's easy to
| enable globally.
|
| Beyond that, however, there are two key benefits - the author
| even almost discovers one of them but didn't think about it
| enough: encryption means deletion is probably fast - delete the
| key and you don't need to monkey around wiping disks and
| snapshots.
|
| The other, bigger, one is that it can protect against mistakes
| or compromises. If you share a KMS-encrypted resource
| accidentally, an attacker won't have access to the data. An
| attacker can't access a resource with a custom KMS policy
| unless they compromise the specific role which has access or do
| more invasive things which will trip alerts. Again, not perfect
| but it protects against common mistakes like the Capitol One
| firewall breach, which is why all of those standards started
| recommending it.
| DrRobinson wrote:
| > It's more that the author is arguing that their
| inexperience is universally applicable. "Why do banks have
| guards, I've never had someone break into my couch cushions?"
|
| That was not my intention and it's unfortunate that's how it
| sounds. Just like most people don't need armed guards, most
| people don't need bank level security for their disks either.
| Encrypting disk encryption is usually not the most effective
| thing you can do to improve your security, there are usually
| other actions with better payoff.
|
| AWS zeroes the disks before they're reused, so from your
| point of view it's instant. As mentioned in the post,
| deleting a KMS key takes at least 7 days (and up to 30 days,
| depending on your configuration.) Regarding other point,
| that's also mentioned in the post as "if your IAM access
| configuration is bad your KMS access configuration might save
| you," which is referring to what you mention.
|
| > It's something you turn on and basically never think about
| again - the performance hit disappeared around 2010 and it's
| easy to enable globally.
|
| This is true if you, or the one you inherit the
| infrastructure from, configured it correctly from the start.
| But re-encrypting disks, databases, S3-buckets etc is time
| consuming and might require downtime. So it's not always easy
| or cost free (in terms of labor.) I'm not sure what you're
| referring to with "easy to enable globally", enable what?
|
| Thanks for sharing your perspective!
| acdha wrote:
| > AWS zeroes the disks before they're reused, so from your
| point of view it's instant. As mentioned in the post,
| deleting a KMS key takes at least 7 days (and up to 30
| days, depending on your configuration.)
|
| Yes, the point is that it separates physical and logical
| concerns. That's why all of the major services have been
| moving to have it on by default since it means that there's
| no way for lost hardware to cause a data breach, and while
| the KMS delays to prevent accidental / ransomware deletion
| are not instantaneous they're visible and deterministic:
| things are deleted when you think they are.
|
| > Regarding other point, that's also mentioned in the post
| as "if your IAM access configuration is bad your KMS access
| configuration might save you," which is referring to what
| you mention.
|
| I guess I'm just not seeing how that's "close to useless
| and potentially harmful" - defense in depth is a useful
| hardening technique, especially if you have to worry about
| admins being compromised or demonstrate that sysadmins
| can't access data without following a standard logged path.
|
| > This is true if you, or the one you inherit the
| infrastructure from, configured it correctly from the
| start. But re-encrypting disks, databases, S3-buckets etc
| is time consuming and might require downtime.
|
| Saying that something is hard to clean up later isn't
| "close to useless and potentially harmful" -- if anything,
| I'd take the opposite position that if you do the
| "pointless" compliance work, you're not going to be in that
| position later when you have a ton of data and busy
| applications.
|
| > So it's not always easy or cost free (in terms of labor.)
| I'm not sure what you're referring to with "easy to enable
| globally", enable what?
|
| Partially I was thinking about https://docs.aws.amazon.com/
| AWSEC2/latest/UserGuide/EBSEncry... but the more general
| point was just that these are easy to set up when you're
| creating new resources and there isn't a runtime impediment
| for having done so the way there was decades ago when
| performance was a reasonable concern.
|
| In general, when the entire industry is saying you should
| do something or, as is the case for the major cloud
| providers, turning it on by default, I would stop to ask
| whether it is in fact unnecessary or them trying to prevent
| yet another customer from ending up in a situation where
| the work required to deal with a problem is considerably
| greater than preventing it would have been.
| DrRobinson wrote:
| > Saying that something is hard to clean up later isn't
| "close to useless and potentially harmful"
|
| The "close to useless" is based on it lowering any risk
| with very little, it's not a big payoff security wise in
| most cases. "Potentially harmful" refers to the cost of
| potentially having to re-encrypt data, that is
| cost/effort that could instead be spent on other security
| mitigations with better cost:benefit ratio.
|
| You have a limited amount of resources, and with those
| resources you want to lower the risk as much as possible.
| I consider re-encrypting data to fare badly in such
| calculation. It's a high effort low benefit mitigation in
| most cases. If encryption is done correctly, it might
| cost little effort and gives little benefit and might
| therefore be worth it. It's very common to not do it
| correctly though, and that requires re-encrypting. I have
| not found an SCP that allows KMS keys but not default
| encryption keys, which means manual effort is spent on
| teaching developers and/or build/use tooling.
| knorker wrote:
| The author here is missing one big point:
|
| The people with physical access in AWS datacenters are not the
| same people who have access to the encryption keys.
|
| In fact, it's likely much more complex than that. The people with
| software access to the machines very likely don't have access to
| the key storing system (and _definitely_ not the hardware).
|
| This means that the number of people it's possible to bribe to
| get access to your data is _much_ smaller than if you can just
| bribe a DC employee to either smuggle the disk out, or make a
| copy onto a thumb drive.
|
| I'm not saying the number of people who could "break glass" and
| read anyone's data is zero. But it's at least an order of
| magnitude fewer than the hoards of people employed to swap hard
| broken drives all day every day.
|
| And the people with this "root" access will likely be very well
| paid, reducing (but not eliminating) risk of bribes.
| dexterdog wrote:
| You think the datacenter hands at AWS are well-paid? I imagine
| that's a pretty junior position that is watched with hawk-eye
| security.
| Bedon292 wrote:
| Not the datacenter hands. They won't have access to the
| encryption keys. So the hard drive they do have access to
| won't be very useful.
| knorker wrote:
| Like Bedon292 said, I think you misread my comment. I was
| saying thanks to encryption they _don 't_ have access.
|
| Most well paid engineers at AWS won't have access either.
| Presumably some minimal set would, but they would likely be
| pretty senior, and well paid.
|
| But ideally you'd want one set of people with access to the
| keys, another with access to the data, and a third with
| physical access, and no overlap. That way you need three
| people to conspire.
|
| But that's going to be very hard to achieve in practice. But
| it's not all or nothing. The closer you get to this goal the
| harder it'll be for someone to not just do it, but do it
| without triggering a tripwire from the security folks, or at
| least persist a log entry that if found would get them thrown
| in prison.
|
| Public cloud companies are not like a small startup where
| everyone has root.
|
| (sounds like twitter kinda was, according to recent reports)
| eloff wrote:
| The author is not talking about getting someone with physical
| access. He's talking about bribing someone with software access
| to your disks, who can access the data, regardless of the
| encryption settings.
| knorker wrote:
| As I explained, and elaborated here
| (https://news.ycombinator.com/item?id=34017654) it's not as
| simple as that.
|
| But also.
|
| > The author is not talking about getting someone with
| physical access.
|
| Right. The author missed this as one of the major attack
| vectors that this aims to protect against. I don't think
| leaving out a real justification for it when saying it's
| snake oil speaks in favour of the author's point.
| DrRobinson wrote:
| I think this is a valid point, though I don't expect the people
| in the datacenter to know which customer stores data on which
| disks. There could of course still be someone working there
| that steals data from all customers and you end up being part
| of that, but that's probably quite hard and risky for the
| employee since the datacenters are heavily monitored and access
| is restricted. As a targeted attack, I'd expect them to need to
| team up with a different department, which makes the attack
| even more expensive.
| knorker wrote:
| Yup. Security is layers. Checking this box helps against some
| threats. Definitely not "close to useless".
|
| Public Cloud cloud have their shit together, but they also
| deal with millions of hard drives. I could definitely see a
| story coming out where someone finds a hard drive, some
| sensitive stuff on it, and just nobody has any idea how it
| got out. Stranger things than that happen every day.
|
| If it's encrypted then that's another layer of swiss cheese.
| whoknew1122 wrote:
| > Delete the key and your data is gone
|
| This is partially true with respect to EBS (i.e. virtual disks).
| When you boot up an EC2 instance, the a plaintext data encryption
| key is loaded into hypervisor memory. As long as the EC2 instance
| is still running, you can add an additional EBS volume to the
| instance and then copy data from the disk that has the orphaned
| key. Even if the underlying KMS key was deleted.
|
| The rest of this stuff feels like FUD me. Yes, IAM has identity-
| based policies and KMS has resource-based policies. And yes,
| default service KMS keys are unique per account (why would you
| expect otherwise?).
|
| Implementing an encryption program takes forethought. This is
| true if you're hosting your own data, too. I really don't miss
| manually rotating drives, fighting with LUKS, and then putting
| drives in a fireproof safe (which was never locked anyway, so I'm
| not sure if it would've actually protected anything in an actual
| fire).
| DrRobinson wrote:
| > And yes, default service KMS keys are unique per account (why
| would you expect otherwise?).
|
| I expect it to be unique per account, but I would be happy if
| it was possible to share it with other accounts so one could
| make cross account backups (it's good practice to have a
| separate AWS account for backups.) Currently this requires a
| KMS key, which means data encrypted with the default key must
| be re-encrypted and that takes a lot of time and effort.
| rwmj wrote:
| Right now it's just defence in depth, to protect you if Amazon
| screws up their physical security. It will make more sense as
| confidential computing[1] becomes more common. This is because
| the data can't be accessed by the cloud vendor, assuming the key
| is generated inside the trusted VM.
|
| [1] The trust moves to the CPU vendors instead of the cloud
| vendors, but if you don't trust CPU vendors then you're going to
| have a hard time doing anything with computers in the modern
| world.
| cyberpunk wrote:
| Is there any tooling you're aware of in this space? I know of
| one small group in Europe making something but it's closed
| source..
| gcassie wrote:
| Implicit in this article is the idea that security posturing is a
| zero-sum game for many companies on the dimensions of both
| software complexity and time.
|
| Adding full disk encryption takes time from other projects and
| makes the system more complex. That equation needs to pay out. In
| all likelihood, the reason your data is going to get stolen is a
| privilege escalation in your app code or a bad actor on your
| team. Rogue AWS employee swiping your particular hard drive in
| us-east-1 is way down the list. Full disk encryption does nothing
| for the first two vectors.
|
| I think compliance programs are oriented around pushing companies
| into complex/expensive system designs thinking that is a proxy
| for a secure system.
| DrRobinson wrote:
| You put it really well, I think that's close to how I think
| about it.
|
| Compliance has good sides too though. For example, they force
| you to think about areas your intuition might otherwise not
| have gone, so I don't dismiss them but sometimes it makes you
| spend time on less than optimal things in order to stay
| compliant.
| fnordpiglet wrote:
| Aws has done a really good job making encryption fairly simple
| to enable. It does make some common tasks complex though, like
| sharing images between accounts. However it's not fragile or
| time consuming, and it is typically standardized in an org of
| any size that requires these sorts of compliance regimes so
| individual teams don't need to worry about it. But associating
| a volume with a key in KMS is not complex or difficult.
| Bedon292 wrote:
| The primary reason I see for encryption is because all of the
| disks are shared. Encrypting at rest is to make sure that the
| next user of the disk is not able to find any of your data. Even
| if the odds are low, you still don't want any private information
| leaking on accident. And you have to be able to guarantee it for
| things like HIPAA or PCI compliance.
| rwmj wrote:
| Are you saying that EBS exposes previous tenant disk contents
| when you provision a new disk? I've never heard of that
| happening. It would be incredibly insecure if true.
| lazide wrote:
| It shouldn't. But do you want to be the example 'oops'?
|
| If FDE is easy to do, it's usually worth it to reduce the
| risk to zero.
| NBJack wrote:
| I'm not sure if the author is aware that they can bring their own
| key material if they wish to KMS. The cost model is a little
| different, but you retain complete control of their life cycle
| across time and regions. It would seem to solve many of their
| pain points. Additionally, AWS recently added support for a user
| maintained keystore.
|
| As for some of these statements (i.e. loss of key equals loss of
| data, re-encryption with a new key is expensive to go through an
| entire disk, etc.), that is exactly the point of encryption and
| holds true beyond the cloud. It is not meant to be trivial; it is
| a layer of security that trades convenience and often some level
| of performance.
| andorov wrote:
| What about the disk being reused by another process without being
| thoroughly wiped by AWS?
| whoknew1122 wrote:
| Disks are wiped immediately before they are made available as a
| new volume. If your policies require a certain level of wipe,
| you should wipe the disk before releasing it.
| colonelpopcorn wrote:
| That's an interesting idea. I imagine they don't do DoD wipes
| of their disks because they are probably multi-tenant, right?
| Can a guest operating system do forensic analysis on the host
| disk?
| britneybitch wrote:
| AWS wipes disks before reusing them (loosely speaking--an EBS
| volume doesn't correspond 1:1 to a physical disk). Forensic
| analysis of overwritten data requires disassembling the
| physical disk, so no, it's not possible.
| likecarter wrote:
| Stealing disks does happen, especially on-premise, which is where
| these policies originated.
|
| Also, sometimes there are mistakes with decommissioning old
| drives, and you wouldn't want your data discovered in a landfill
| somewhere.
| lokar wrote:
| Google has very tight physical security (metal detectors, etc)
| and disks are either confirmed erased or shredded
|
| I assume aws is similar
| LammyL wrote:
| Google mostly runs their own data centers. Amazon mostly
| rents space in commercial data centers with lots of different
| companies. Aws is probably pretty secure but likely less
| physically secure compared to Google if you get into the
| nitty gritty details.
| fnordpiglet wrote:
| This is false. Aws builds and operates their own data
| centers. The design and architecture of their data centers
| are highly standardized and an enormous amount of the build
| is fully automated. When they do lease they lease just a
| basic power and fiber build and they build their data
| center ontop of the base. Given how much custom equipment
| they run at the data center level it would be impractical
| to do anything that was collocated. But most data centers
| for aws, especially in Virginia, are on Amazon owned land.
| As far as I am aware the only collocations are in the
| satellite zones, outposts, and in peering locations.
|
| https://www.datacenterknowledge.com/archives/2017/01/18/who
| -...
| eloff wrote:
| The author is talking specifically about AWS. The odds that
| there is a mistake decommissioning the disk that leaves the
| data intact, times that somebody salvaged it from a landfill,
| times that they care about your data is basically zero. Which
| means a logical person should worry about everything else.
| knorker wrote:
| You forgot to multiply by the millions of disks they
| presumably go through every year.
| im3w1l wrote:
| What are the odds that some arranges for all those things to
| happen though? When you try to go after them they will have
| plausible deniability.
| fnordpiglet wrote:
| Disk management and destruction is largely automated.
| That's extraordinarily unlikely.
| eloff wrote:
| That's an interesting attack vector. Bribe someone to
| replace the disk without wiping it, and be in a position to
| intercept it after that.
| kube-system wrote:
| They don't go into a landfill unless they're broken. Old drives
| that someone could still get the data off of end up on eBay.
| rolenthedeep wrote:
| I once bought a "new" hard drive off Amazon. The connectors
| looked suspiciously scratched up, like it had been used before.
|
| When I dug deeper, they had wiped the SMART data and the
| partition table, but it was absolutely full of readable data. I
| found clear text server logs indicating that this drive was in
| a backblaze center for several thousand hours.
| dexterdog wrote:
| Did you report that to backblaze? I would think a bug bounty
| would be paid on something like that.
| Jensson wrote:
| I'd worry they would sue for hacking to cover it up, dumber
| things has happened to nice developers who report
| vulnerabilities.
| lazide wrote:
| Most likely a subcontractor somewhere promised they would
| shred the drive, then didn't. Do tell them!
| hxugufjfjf wrote:
| Absolutely do not tell them. This is a can of worms you
| really do not want to open. You will not be met with a
| welcoming response. Its sad, but that is the state of
| affairs.
| lazide wrote:
| What can of worms exactly is opened with a 'Hey I bought
| this drive on eBay that seems to have your info on it -
| want it back?'
|
| What plausible damage have you done that they could sue
| you over? If all you want is your cost or the like, I
| can't imagine that is a crime either.
|
| If someone has a lot to lose, I guess sending a letter
| through a law office would be a sane option, but
| backblaze doesn't strike me as the shoot-first-ask-
| questions-in-the-deposition type of company anyway.
| fragmede wrote:
| I'd tell them anonymously. Register a new protonmail
| account and email support at Backblaze with some
| incriminating evidence that you're actually in possession
| of what you claim, and then offer to mail the drive back
| to them.
| dexterdog wrote:
| How could they sue if you legitimately purchased one of
| their discarded drives? When you bought it whatever was
| on it became yours and I doubt their CEO would like their
| data floating around like that unless it's considered
| useless.
| fragmede wrote:
| First they'd cast aspersions on the drive being
| "legitimately" purchased, then they'd float that you're
| an evil criminal, in violation of the CFAA and wire fraud
| acts, and for receiving stolen property.
|
| If the government is out to get you, they'll try and find
| something to come after you for. Just ask Josh Renaud.
|
| https://www.theregister.com/AMP/2022/02/15/missouri_html_
| hac...
| dexterdog wrote:
| Backblaze is not the government. I mean if you're
| paranoid about it you could submit a bug bounty with a
| temporary email address and gauge the response. If I were
| Backblaze I would like to know about this and would be
| willing to at least send you a pair of new replacement
| drives to get that one back, assuming this kind of
| disposal is not their SOP. It's possible they ran this
| drive through their vetting process and it didn't meet
| their spec so they sold it off. The logs might just be
| from that testing/vetting and any data even on real
| production backblaze drives I would assume is so striped-
| out that a single disk would not have anything of
| recoverable value.
| based2 wrote:
| https://docs.aws.amazon.com/workspaces/latest/adminguide/enc...
___________________________________________________________________
(page generated 2022-12-16 23:02 UTC)