$45k in AWS charges due to account being hacked to mine cryptocurrency
twitter.com
twitter.com
"Welcome to AWS Cost Management
Since this is your first visit, it will take some time to prepare your cost and usage data. Please check back in 24 hours."
My "cost and usage data" is that I have an S3 account costing ~$10 a month containing my cloud backups of my family's high-priority data, for maybe the last 18 months. That's it. I just reloaded in case 24 hours was some sort of pessimistic estimate and they actually had it done in a couple of minutes, but the message persists.
WTF.
I can set up any of dozens of services in thirty seconds and spend thousands, but it's going to take 24 hours to understand ~$100 in costs over the course of the last year? Someone could read aloud the entire history of the account, every S3 transaction I did, in that amount of time.
I can really feel the love here.
I'm not saying that neglecting this is a conscious, cynical choice. It may just be that there's simple no incentive to build it in the first place. A self-motivated engineer or team manager is probably not going to say, "I know! Instead of working on the next bit of shiny exciting tech, I'm going to work on cost controls!" Though sure, it could also be deliberate.
You also may not be cynical enough here: Lookup the Amex tax avoidance strategy that they pitched to companies for a while before a whistle blower tipped off the IRS [0]. Or pretty much any fraud that originates at a high level in a corporation. Companies make risk/reward decisions about doing bad things all of the time. ::ahem Theranos::
[0] https://www.wsj.com/articles/amex-pitched-business-customers...
- Billing code/codebase and everything around it is (was?) a big crapshow and people are naturally reluctant to stick their hands in something so critical and hard to adjust (and equally reluctant to approve such projects).
- Some teams believe that customers don't want such a feature and may have been explicitly told that they don't want that feature to exist. The latter part seemed like hyperbole to me but I don't have the context they have.
That pretty much lines up with my comment about engineers that would prefer to work on some bit of shiny new tech that's more glamorous than cost controls, and my general sentiment that AWS simply doesn't benefit from pursuing these changes.
Driving this billing project is going to be thankless work, and at the end of it Amazon will lose money.
It's a lose-lose.
I have heard such reasoning many times to get away with all sort of BS.
The argument is often impossible to refute, since you don't have any customer at the meeting and the feature is on the idea stage. So I guess it is some sort of argumentation fallacy, referring to a non-existing person?
The person might exist, but either way I'd say the fallacy is an improper argument from authority, in two stages: First, AWS is claiming authority on the matter and citing other customers as their evidence. That evidence is an improper appeal to authority as well because the expertise (or even existence) of the person(s) behind it cannot be validated. Sort of like a celebrity endorsement where you don't even know who the celebrity is-- e.g., An unnamed person who endorses a basketball sneaker but you don't even know who if they play professionally and actually use the sneakers themselves.
For that matter, even a proper appeal to authority (area of expertise is relevant to the topic at hand, expertise had been validated, there are no conflicts of interest like getting paid for it) are not very strong evidence for a claim. They are indirect evidence where the person is saying "You don't need the data, I've reviewed it and you can trust me".
For other option, it does seem like GCP (I don't know much about Azure in this) is a little better in this area. Admittedly, I'm speaking from limited experience playing around with free tiers in both, along with the stream of stories that we hear about AWS.
I think it's also fair to point out that cost controls may not have helped much in the example of this particular article: If your account gets hacked, presumably the hacker will also have some access to remove cost controls.
And setting up two-factor authentication is far easier.
Except you can create a budget that is based on individual services or usage instances. And you can view each service's cost in zoom-able billing statement.
What information are you unable to find about your bill?
(NOTE: I'm not an AWS shill. Every time I see AWS billing threads I'm concerned I'm missing something obvious and putting myself and my biz at risk, so I drill down on posts to make sure I know what I'm doing.)
https://console.aws.amazon.com/billing/home?#/budgets/overvi...
What on earth are you getting at?
What is needed is a way to say "I only expect charges of $10 or less per month. If charges go over that, disable the account until I can get in there and find out what is happening."
If I have lost ROOT access, as the OP did, nothing can save me: all alerts and thresholds can be shut off by the hacker. Just like any other system.
If a total shutdown when aggregate monthly budget is triggered is insufficient, and fine-grained quotas are too complex, you probably shouldn't be in the cloud because Azure and Google are equally complex. Or do you like another cloud-computer service better than AWS because their budgeting quota systems are better? Please share, I'd like to know what you use.
I never said that. In fact, that's what I'd prefer. I don't use AWS for anything critical, only for testing, so I'm fine with my account getting temporarily disabled or all requests returning error codes.
> Please share, I'd like to know what you use.
B2. B2 has a 10GB free tier for object storage and returns an error code if that limit is exceeded without a credit card on file. They have limits (called Caps), like AWS, but B2 apparently automatically sets their limits low, because when I checked, my limits are $1, $5, $1, $1. Pretty sure I never set these. They will email or text when limits are exceeded by 70% and 100%. As far as I can tell, they don't have a hard limit (return error codes) once a credit card is on file like they do with no credit card on file, but I think that would be a good thing to add.
I can only report what happened. Why this couldn't be preloaded for my teeny tiny account and its probably on the order of dozens of kilobytes of data is something you'd have to take up with Amazon, not me.
And it'd be nice to just have a $100/month killswitch on my personal AWS account and I have no idea how possible that is with their actions (which seems to require configuring IAM accounts). I don't run anything "production" there and I'd be happy to have all my shit suspended if that dollar figure was exceeded, but fuck if I know how to do that without taking a week to catch up on the past decade of how to manage infrastructure with AWS.
It may be simpler to just suspend my AWS account entirely. I think I only have some ancientsauce mysql backups on S3 which are costing me a few pennies a month.
So far, this time, they haven't. I hope they do for this guy's sake, but to not have that as an official policy, or to implement a tech solution, is beyond terrible.
* Never used anything above the free tier
* Never had a credit card attached
* Was only ever logged in from the UK
* Hadn't been used at all in 3 years
Naively my root credentials were the same as my Linkedin details (which were all leaked), and one random Sunday, someone from Brazil logged in and spun up 50+ GPU instances across multiple zones. Amazon let that go for around 12 hours before they sent me an email asking me to check that my deployments were working as expected. £2,000 in just those few hours.
I did get the fee waived (though they took two weeks to finally decide this), and I accepted that it was my fault for reusing passwords and not enabling MFA (which IIRC may not have been an option when the account was opened) but I was very critical of Amazon for not preventing expensive nodes from being spun up when there wasn't even a card attached to the account.
I mean, it could "never" happened if you just thought of a better password for your AWS account. Why blame AWS for that? All the preventive things AWS could implement wimm help the few users who didn't get that they should good passwords and hinder all the users who "know" what they are doing and just need some machines up-and-running. IMHO.
The problem isn't that AWS does not let you manage limits, because they do, to some extent: https://docs.aws.amazon.com/general/latest/gr/aws_service_li...
The problem is that if someone has your root credentials, they can just change these limits and go to town.
From there, a discussion continued, but the problem of what to do when some sort of resource allotment is exceeded, is still not solved.
Personally, i think that static allotments (e.g. you get a VPS with X bandwidth per a month, where the port speed will be decreased 10x until end of billing period in case it's exceeded) are the way to go for people working on non-critical projects, where downtime or degraded performance is preferable to not being able to buy food or afford rent.
Though with some platforms, you still need to protect yourself, either with virtual cards or other means, since there's no guarantee that cases like those in this post will be noticed and the fees even waived by the corporations. Of course, the legal aspects of all of that are somewhat unclear. All the more reason to look for solutions with simpler billing, or at least billing alerts in lieu of that.
Fortune 500 companies have literally just decided handing blank checks to Amazon and Microsoft every month to make their technology needs disappear was good business sense.
Of course the conversation is usually about how to get someone else to pay the bill instead of get costs under control.
Unfortunately most of us Americans cannot comprehend this fact or are too helpless to do anything about it. I love the folks who tout their awesome employer based plan without really thinking about the insane costs just because they are not the ones paying most of it. I also love the folks who just think a total Universal Healthcare like Medicare for All is the solution which honestly I am not totally against but only if the costs are first regulated in any way.
The practice: you pay for a news article about a grandma unable to get healthcare. The government reacts by ensuring that all healthcare is paid for - with no cap to cost. After all, every life is sacred.
COVID-19 response showed us.
> My mother is not expendable. Your mother is not expendable.
> We will not put a dollar figure on human life.
https://mobile.twitter.com/nygovcuomo/status/124247702908329...
Try reading the contract you have to sign before receiving medical care :)
AWS isn't the only example of giving blank checks to some vendor...
(Also, at least around here if the water agency notices abnormal flow for a long time they drive by and if they see a leak they shut off the water. Happened to me once when a sprinkler pipe blew out.)
Every big business has an in-house data centre, which is operated as a cost centre; success, for a cost centre, means delivering service as cheaply as possible. Providing an easy way for developers to spin up new databases? That would practically be an invitation to increase costs - it's the last thing they should be doing!
So when a developer from that big corporation uses AWS and encounters an environment that makes it easy for them to spin up a new database, it's a big productivity increase.
It literally removes agency from financial folks and gives it to tech people.
Every year on the cloud can roughly cover the expense for double that capacity deployed on prem.
Complaints of "operational costs" generally assume a woefully incompetent staff.
For me it has always been a no brainer to avoid the bureaucratic pain.
Well the doom does sometimes happen, perhaps not well publicized. I've been in one startup that ran out of money where the astounding AWS bill was part of the demise. And in another startup where the AWS bill hindered growth since it took such a large slice of the funding.
> I'm still absolutely blown away we tolerate an industry model with uncapped cost.
How could the cost be capped? Fortune 500 companies run their global infrastructure on AWS, so AWS has to support these huge use cases. If you've set "spending limits", an adversary that has your credentials can change your limits to those same limits used by the F500 companies.The way I have seen this being operazionalized in AWS is by Finance having the exclusive access to a "parent" AWS account controlling billing (and nothing else), and then providing sub-acconts to Production, Development, Data Science and other technical stakeholders.
I was pretty inexperienced and I accidentally committed my Amazon credentials to git and went to bed.
When I woke up I had a handful of emails from Amazon alerting me to the situation. Back then $10k was almost a third of my yearly income, so it was a pretty traumatic morning say the least hah.
When I spoke with an Amazon representative they were very nice about the situation and dropped all the charges, since it was obvious what had happened. I'm sure that's what will happen in this situation, especially given the social media attention.
These soft limits and email alerts are easy to miss and a lot happens by the time you can stop it.
Cost management at AWS is an absolute mess. And I believe it is done on purpose. I was tasked with finding out how much a virtual machine was costing us. It didn't have tags. The task was very literally impossible.
Hopefully the downvote brigade doesn't come after me as I'm truly just trying to share this as I think it'd be helpful in the context of this post and I imagine the majority of folks on HN would fit into our free tier...but this is a huge reason why people use Vantage (linked above)
We profile all resources by hitting List/Describe service APIs in your AWS account and automatically apply rates based off of that. So essentially you get a full inventory of everything in your AWS account and see exactly how much its costing you per hour and also if it were extrapolated out for the full month. People tend to use Vantage as a companion to their IaC that's provisioning things to gut-check from a cost perspective.
In both cases, we received a partial credit. Amazon expects you to setup cost explorer and budget controls before doing anything else. These features must be manually activated on every billing account. It's kind of maddening actually that even turning on Cost Explorer takes 24 hours.
PSA: Turn on Cost Explorer immediately after creating a new AWS account and don't give out API keys until you've setup budget limits. If you join a new company in a role where you have access to the AWS billing account, make sure the cost and budget features are enabled.
There's no way on earth I would use AWS on my personal card unless I could set a limit.
Does it matter -- what AWS limits were imposed?
Those 'real' limits would have to be set by the card issuer. Not AWS. Otherwise trivial for hacker to change the limits.
Again if a hacker was to access your AWS account with root this feature would be disabled and you would not be notified. Someone accessing your AWS is fundamentally the problem.
AWS is much easier to use than a DIY infrastructure, unless significant resources are invested in that DIY infrastructure.
Yes you can spin up a crap fast on amazon. But it’s crap and you will pay an arm and leg for it.
I don’t care about “easy” as much I care about sustainable and cheap.
Amazon RDS is everything but not crap. The great value-add that RDS provides is that they take care of all the tasks you'd normally need many days of setting up, evaluating, regularly checking they still work: replication, automated failover, backup/restore, version upgrades.
The challenge is for the smaller guys who are just experimenting with AWS. I see a lot of these stories where they haven't even used the account much or at all and then get hacked.
Of course AWS can impose limits but they clearly don't want to. They would rather refund these cases whenever they feel like.
We all know it would be straightforward to implement. Even if the time to shut down systems creates some overage that the provider is unwilling to eat (although I can't believe it would cost more than continually refunding these bills), then it would be perfectly fine for "$200 hard limit" to mean start shutting down systems at $100. Just let me limit the damn magnitude!
But since they've all decided it's good business to be sticking users with bullshit bills, we're left to create our own. I've got LLCs on the brain, so I'm wondering if running one's cloud expenditures through an LLC would work.
Besides the paperwork overhead, the biggest worry would be piercing of the corporate veil for being undercapitalized. But I hope it would be hard to argue that a company was undercapitalized because it lacked the ability to pay for unexpected expenses that it did not initiate.
Does anybody know the legal and practical issues with signing up for these cloud providers through an LLC? Even if you're already operating as a company (eg startup), it would still be prudent to sign up through a separate subsidiary. At the very least an extra layer would make for some red tape they'd have to cut through to press the debt.
There is almost no way what so ever to limit risk and it's crazy.
Cloud operators state that it is because they don't want to shut down popular services or similar - and to be honest, I get this argument - but, it is just awful in practice.
Nearly every cloud has cost report delays of anything up to a month for some services and it's just a nightmare.
I kind of agree that if you have a service costing £5,000 a month - you shouldn't limit spend to £5,001 - but, you should be able to limit to £7,500 - enough room to burst/grow, but not have risk!
All clouds could learn a thing or two from telecoms and rate limits... e.g. if you have services that when not in use have a fixed monthly limit - e.g. storage - then take that out of monthly limit and then use the excess for variable costs.
e.g. storage costs £500 a month, compute costs £200 a month... if a client sets a budget of £1,000 - then deduct £700, maybe ~£100 extra for idle transactions (if in a cloud/model that charges), then have prepay of £200 for "extras".
I just see "the clouds" do AMAZING new features - all this crazy and cool AI bits, yet they can't get basic costs correct - it's crazy in my mind.
There is no global "DROP DEAD" action freezing my account and my liability to Amazon.
My ideas for fake notification addresses and their purported actions are likely against HN rules. I'm just going to leave Amazon AWS.
I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for other development tasks, and you have the ability set hard limits for those services.
AWS already has hard limits on things like the number of S3 buckets you can create, that require manually requesting an increase if you want more. Why can’t people say ‘I only want a maximum of 5 EC2 servers, and I don’t want the ability to spin up anything above a t3.large(translated to maybe ~20cents/hour per server)’. A similar approach can be taken for other resources.
This gets around the issue of ‘what should AWS do if you hit your spending cap’ by allowing you to set an upper bound in the amount of hardware you can actually spin up. It also solves the issue of a compromised dev key or root user account that would likely trivially allow someone to remove a spending limit anyway.
You can get pretty far along by never using the root user, and having very limited iam policy for your day-to-day user. That is also what AWS documents as best-practice:
> We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones.
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi...
You can not set quotas that way, but you can at least limit which services are accessible. Furthermore e.g. ec2 has fairly rich set of conditions you can use in policies to lock down the access even more:
https://docs.aws.amazon.com/service-authorization/latest/ref...
That said, AWS should make it easier or even require it. AWS is full of footguns and weak security defaults and small players (like the person who tweeted about the bill) lack the knowledge and experience to adequately defend themselves.
Also, it's less of a "hack" than a likely publishing of AWS keys (if you publish them in a public Github repo, they're compromised in seconds)
I don't want to monitor it and these stories give me some anxiety.
I guess I'm supposed to close my AWS account? I wonder if this is even possible if it's the same credentials as your Amazon account.
This is not about sneaky AWS, this is about a hack. There is not much you can do if someone gets root access to your system.
Setting up a billing alert to notify you your aggregate cost exceeds a certain limit takes about 90 seconds. I don't understand the overwhelming friction to the AWS billing tools in this thread.
There is also the remote possibility they're playing the victim to get out of charges after they realized it wasn't economical to mine on AWS.
"I don't know how my key leaked. It's a 9yr old account, under utilized + running old projects.
AWS do have alerting systems you can use to catch overspend. You should.
They didn't exist when I signed up. And with 200 links in their main menu, they're not easy to find."
Don't blame the user for what is essentially Amazon's problem. They don't have a way to set a hard limit on spend. They don't even do basic velocity tracking apparently.
I recall a VPS that i had years ago being hijacked due to Docker socket being exposed publicly (when i set one up for testing and was just learning about Docker), which was mining crypto throughout the night before i noticed it.
Imagine what would happen if there had been some sort of auto scaling in place and i had used a managed Kubernetes solution (many of which didn't yet exist back then)...
Is it Amazon's problem? Not really, apart from the bad PR that charging private individuals exorbitant sums (for them) might cause, so sometimes these bills are waived after people mess up. For the corporation at the size of Amazon, that's probably not too much in the grand scheme of things, but it's also understandable why people might be appropriately upset about not being able to set hard spending limits, merely alerts (which aren't enabled by default).
That's just the reality that we live in for now, however one can also think about why a corporation that cares a lot about uptime might not necessarily want to implement functionality that'd let resources be easily cut off when spend limits are hit or something similar, since most businesses that utilize their services might just swallow the occasional expensive bill like that anyways.
Not saying the OP has no responsibility here. Just that I don't think it is that black and white. There is plenty AWS could do to avoid this sort of thing happening. Totally fair to call them out for that. Especially when the cost of phoning support is $2-3k specifically because of the new costs on your account!
Absolute spending caps, or spending growth rate limits, would both be useful even outside of situations where a user's credential is compromised.
One example: When teaching colleagues how to use AWS tooling, I gave them full access to a sandbox account where they can learn without disrupting anybody else's infra. It would be nice to be able to place a spending cap on that account.
Another example: With things like autoscaling, it's very easy to accidentally misconfigure it to where it will happily start launching tons and tons of VMs. You might do this and not notice. If I had the ability to voluntarily opt into limits on how fast I can increase the aggregate $/second spend rate, then AWS could alert me in general when I'm doing something that exceeds that soft limit.
The OP was a victim of the hacker and not AWS.
My point is that AWS failing to implement spending controls makes this type of attack significantly more damaging, and the slow turnaround on CloudWatch spending alarms means five or six-figure sums of money can be spent before customers are alerted.
AWS can and should do more to give its customers additional control over spending as a defense-in-depth measure. This would be valuable both to limit unauthorized spending (this scenario, or a "rogue employee" scenario) and also unanticipated spending ("autoscaling gone wild" type scenarios).
AWS is a big target, and the fact that credentials can be used to spend an unlimited quantity of money means they are a huge target for criminals. Defense in depth would be wise in this situation!
Security needs to have depth. The one thing we have learned in these few decades of learning how to do online security is that any single measure can fail, and given enough scale, will fail. For anything to work, you need to be able to layer your security measures so that one failure, no matter how grave, will be fatal. AWS could add a very simple security measure here, making their service dramatically safer for their users, but they choose not to.
But the 3.4 trillion dollars have to be paid back by Monday! And take better care of your information next time. It is the duty of every customer to check cash dispenser for skimmers before using them! This is clearly written out in out general terms and conditions!
Every time I see a story like this (and there have been many), Amazon always ends up dropping the bill. Idk what this one hack on Lambda actually cost Amazon, but I’m guessing it’s nowhere near $45k.
Yeah, one key issue is that it's deceptively easy to set something up in AWS, but there's actually a ton of customizability, complexity and potential gotchas lurking in the background.
They've essentially SaaS-ified sysadmin, network admin, DBA, etc. roles. So relatively casual users are pointing, clicking, copying and pasting like they're just navigating any ol' app, but beneath the surface they're commanding potentially massive/unlimited resources with the attendant costs those resources impute.
Makes you wonder whether it's just too much power to casually have on offer.