freenode seems to be super flaky lately infosecatom: I remember that rant too so wow erratic was part of that breach I skimmed that complaint (I'll read it all later) won't be surprised if the FBI calls Surprised they hadn't already! Things move somewhat slowly over there ;) I meant to ask: what was done with the hard drives from kvr02? My root disk is now encrypted, but it wasn't before and that's a bit concerning if those drives get into the wrong hands. they are in storage our IRC logs have been posted several times to Twitter now #publicity lol Publicity = awareness = customers ;) why, yes, that's what I was implying :) So long as they're the right kind of customers... :) Not the cast of Looney Toons? Something like that. If you were curious, I think erratic dropped their /28 of VPS's with y'all because they ran out of money Coincidentally enough they started using AWS next... https://ejj.io/blog/capital-one some speculation about how the attack was conducted tl;dr if you can make arbitrary http requests from some AWS VMs, you can get IAM credentials which give you S3 access it would be pretty cool if the metadata endpoint was a unix socket or something instead of a network endpoint one thing to note is AWS GuardDuty will notify you within 15 minutes any time a credential is taken out of an instance and used somewhere else - so any large org should really have guardduty turned on i like the two factor idea though I think the problem with unix socket is that the data doesn't come from the actual VM itself so it has to go over the network I didn't know about that metadata thing until now but it sounds so sketchy is there an option to block the credential from being used elsewhere? instead of just being alerted and having to clean up afterwards yea the metadata service is fun (and essential!). it's mostly static - there's only a couple ways to signal dynamic data through the metadata service. IP addresses, ami info, reservation ids etc hmm, i don't think so, especially because (in most cases) traffic to AWS services technically goes over the public internet, so the source IP information isn't very useful. IAM won't know if it came from your VPC or whatever maybe i should ask for it in a ticket :) i saw a case of credential exfil in my org, some developer didn't have AWS yet and just pulled a cred off an instance to use on his laptop. we shut that down so fast in general I'm kinda sketched out by IAM like why did that credential that was stolen have access to every S3 bucket? shouldn't people lock down their credentials to only access what's necessary? seems like common sense maybe it's just inexperience, but those iam policies sometimes seem a bit complicated like it's easy to make a mistake and grant too much access it's also just time constraints. my workplace started using dozens (35+) aws accounts for this type of thing, so one team's * doesn't give successful attackers access to stuff belonging to other teams. which solves... like 10% of the problem at most, lol people don't like spending time determining what their app needs when S3:Write* or S3:* or even just * will work fine :( i would love to have some audit system so i could say 'what has this role done in the past 7d? now apply that as the whole access list' but i don't see that getting built in lol. i have a lot of opinions on aws not sure how much to ramble on about here. yeah it seems like a real deficiency in AWS's service to me now that IAM is starting to include ssh access into instances, i think the cloud user community needs to really think about what can be done to be more careful with IAM imo you shouldn't need to have separate root accounts to be confident in the security separation of your cloud services my initial impression is that Azure does a lot better at this my org keeps root account creds on encrypted flash drives in a safe no one is allowed to touch them day to day it's a bit insane to me that's necessary I feel like even the default AWS recepies in the GUI portal and stuff don't really make use of IAM properly they're just like "yeah you need to have S3::* for this to work so make an iam role for that"