Tell HN: Rise in AWS accounts getting hacked and owner being stuck with the bill

Is that even legal? How is it the user fault that aws can't properly track and terminate the account resources? (Altough they seem very efficient in tracking usage when the goal is to charge credit cards).

AWS has a free tier that lasts for a year. I actually used it to get hands-on experience with enough services that I was able to get my AWS Certified Solutions Architect, Cloud Practitioner and Certified Developer certifications. I easily spent 60 hours creating and deleting services and it didn't cost me a cent.

I don't even know how you'd accidentally get to thousands of dollars accidentally unless you were doing something more complicated like setting up an autoscaling group.

Spin up a t3a.micro EC2 instance and run it as much as you like - it's free. If you go into it (as I did many years ago) thinking, "Let me just spin up a 16 core server with 128 GB of RAM" because that's what you'd set up in your on-prem data center then of course you're going to have a big bill.

But that's not what cloud is about. It's about resources popping in and out of existence for the minimal time and resources needed to accomplish a task.

how is it still profitable after 1600 cost?

Good point. I probably should replace all the credit cards I have with temporary ones...

While this may be safest, it doesn’t make sense why Amazon doesn’t save themselves a couple (hundred) grand in refunds by locking down root accounts.

You can keep the password unset as well.

Organization child accounts are not rootless, they're just seeded with a random password

aws-vault works too

Like $120,000 after paying like $.30 for cloudfront for 10 months

It was pretty obviously uncharacteristic

You actually can't mix hardware tokens and OTP apps. You're only option is to scan the code twice and skip hardware tokens entirely (which is quite reasonable, as the recovery for an app would be easier than for a failed/lost hardware token).

Note, though, that the new SSO login actually supports MFA in a normal way.

You create several users with admin privileges each with separate MFA.

Don't token limits reduce attack surface?

FWIW, at a workplace I'm familiar with, the hardware MFA devices for a group 'disappeared' from the office during COVID and despite the company having an active relationship and contracts with AWS, it was taking over a year to get access to the root accounts in question reset. It is not an easy process.

That said, I have to imagine this is the wrong procedure and there's some way to duplicate hardware MFA devices to have redundancy for such a case...

Don't use a "cloud" vendor then? Just use a VPS vendor.

Right, but if someone buys say a shirt with your stolen card, it isn’t the store that picks up the bill. It’s the credit card company.

That link looks like MFA can be disabled but this chart shows otherwise (baseline versus opt-in enhanced): https://docs.microsoft.com/en-us/azure/active-directory/fund...

I think that rate of usage would trigger EC2 abuse alerts. Usually it's something that looks plausible but accumulated over 30 days.

Jeff Bezos did not become a billionaire by being user-friendly. Guess anyone trying to cancel their Amazon Prime subscription would agree.

There's still a lot they could do around that though, e.g. requiring that billing details be re-entered upon change or sending an email alerting the user with instructions to secure the account if it was not authorized.

Just as likely as basic credential compromise is lateral attacks on compute resources from vulnerabilities such as Log4J.

Enabling MFA, restricting intra/inter-VPC access, removing hard-coding credentials from configuration files/source etc., switching to SSO/removing user accounts with passwords, creating and applying restricted IAM roles, and applying those reduced privileges to EC2/ECS/EKS instances are all things that and should be done as soon as possible. (Non-exhaustive, but illustrative list)

AWS could simply require the user verify they have access to the card or other payment method on file.

It's not hard to invert the transaction, ask the billing service if an action can be done instead of bill upon completion. Done. This isn't that hard. If your credits won't make it to the end of the month, send out the email warnings to top up - which should be predictable unless there's a large spike hitting the account. If you prefer invoice billing because you never want your services going down, it's trivial to accommodate with this system design.

Sure, big warnings about data loss/services down in the event of zeroing out your credits.

Having such a safety net would really help the thousands of people who sign up for transient reasons. I don't recommend a noob set up an AWS account. I also don't let my kids play on the freeway.

In theory, all IaaS services could be built like an Ethereum node:

1. fill an account with abstract "multi-resource usage credits" (or gas);

2. have each API call specify how many credits the caller is willing to spend from their account on the operation (a gas limit);

3. operations in progress are tracked using real-time resource accounting (= distributed tracing, but cheap-as-possible at the expense of granularity);

4. any operation that goes over-budget is cancelled (even if it completed successfully, the user doesn't get the benefit of that completion), with the user being charged exactly the limit they specified.

(Yes, that means that the IaaS eats the overhead costs of any additional processing they did before noticing and stopping the workload going beyond its limit. This incentivizes the IaaS to optimize their scheduling, at all levels of the stack, to minimize the amount of "overhang" work it allows.)

And yes, to be clear, this would "infect" every layer of every service. If the IaaS provided a DBaaS, the DB's query planning and execution layers would need to know about these limits and accounting mechanisms. Etc.

I'm not saying it's practical. But it's definitely possible, with no foreknowledge of cost.

azure seems to manage that just fine with their free azure credit that they give to MSDN subscribers ($150/month spending limit, refilled every month, no chance of going over).

They bill by the request or minute for most of the services. Billing for storage is a little more complicated, but many services could easily be limited.

Somehow Oracle of all companies is able to get this right with their free tiers for their cloud services.

This does not stop the high bills from your account being hacked. Just reduces the amount before you notice. spinngin up gpu and ec2 resources until limits are hit in how many are created is an operation that takes seconds.

AFAIK setting a budget or alerts does not say "Not authorized to spend more than X amount, deny any spending over this limit". It will alert you, yes. (Also, not on by default)

Can you set a "hard" budget? Like, never let me get more than $20/mo in services from AWS and after that just disable my account?

And these can then be turned off by the hacker.

You can execute Budget Actions to stop services and revoke permissions. It’s not simple but it’s possible.