Why can't Amazon protect you from Bitcoin mining on your account? | Hacker News Reader

Why can't Amazon protect you from Bitcoin mining on your account?

1 pointlogicallee13 comments

I got major downvotes - but no answers - for why Amazon can't ask you if you'll be mining bitcoins:

https://news.ycombinator.com/item?id=8818170

So, why not?

They don't need to do deep introspection on the VM's, a sample every now and then could easily tell whether your instances are churning through SHA hashes.

If I'm wrong for some technical reason - what is it?

Since this is a major risk, I'm curious why it's impossible for Amazon to protect you against it.

View on HN

They may not want to be subject to secondary liability. The most famous example is likely Playboy Enterprises, Inc. v. Russ Hardenburgh, et al., where screening for materials which infringed on copyright meant that Rusty-N-Edie's had secondary liability for the presence of infringing materials on their board.

If they start an infrastructure for deep introspection of the VMes, especially for something which isn't prohibited by their agreement (at least, I don't think it's prohibited) then what is their liability for not looking for other signatures?

There are other virtual currencies. Some don't use SHA, I assume. Even if all Bitcoin attempts could be identified and killed within a second, I assume that people would switch to other systems.

interesting idea. so running a VM is fine, but if you protect your users by sometimes checking for certain usage patterns (that they said they didn't want), you become liable for a lot more?

I thought though that they did do some pretty deep stuff, like silently update for heartbleed - http://distinctplace.com/2014/04/16/openssl-heartbleed-ec2-a...

did I misread?

Well, yes, you can become liable for failure to do what you said you would do. That's what secondary liability means.

If you check for certain usage patterns, but there's a 10% chance of failure, then will 10% of that customer base sue you for not doing the job you said you will do? Remember, you've started with the premise that there is a clear signal. Certainly it's possible to tweak any SHA calculation enough to confuse detection algorithms.

What advantage is there for Amazon to put the infrastructure in place, as compared to the current (seemingly generous) practice of revoking fees for abused accounts?

obviously, the benefit is that they are not then out all that computing power! (for which they refund fees at a 100% loss.) I would think their gross profit isn't all that high - certainly not nearly 100% where they can do these refunds without a second thought or loss to them. it's like asking, if a store refunds things stolen from you, what is their incentive to reduce this theft? well, obviously, the fact that after these refunds they are out these goods. . . The only time they don't care is with 100% profit margin.

regarding your first point... they don't have to promise they will check for bitcoin mining by having a fraud prevention check in place. the fact that I cheerfully allow my bank to hold some transactions that look questionable to them while they verify with me, doesn't mean I will extend liability to them if they fail to hold a transaction or find it questionable. it's more a matter that they might refund me if I did not actually make a transaction (as with Amazon) so they want to cover themselves in some instances from this happening in the first place. more power to them.

Have you tried to estimate their profit or gross margin?

I think it's wrong to analyze this as stolen goods. It's an opportunity cost. Unless they are fully utilized, the cost is power, cooling, and depreciation on the hardware. Not the market price of what that CPU time would have been sold for. Based on http://www.geekwire.com/2014/heres-startup-dumped-amazon-web... the internal cost might be 50% or even less than market price.

You have a habit of positing that because you wouldn't do something means that others wouldn't as well. You can sue a bank for acting in bad faith, which "does not necessarily involve furtive or evil motives, but has a commercial sense of disregard of and refusal to learn the facts when available; and that the circumstances and conditions may be so cogent and obvious that to remain passive amounts to bad faith" - http://caselaw.findlaw.com/ky-court-of-appeals/1496975.html#... .

Bear in mind that it's very difficult to extrapolate from a regulated bank to an unregulated company. there are also a lot of banking laws put into place define exactly what bad faith means. For example, it used to be that you were liable for stolen credit card misuse until the time it was reported. The law changed to limit your liability, which placed more emphasis on the bank to do fraud detection.

The parallel here is obvious; if as a matter of principle they decided to assume 100% liability, then this gives them inventive to improve fraud detection, which can be done through things like usage analysis. While assuming no liability gives them less inventive to go after fraud. If Amazon wants happy customers, then great service helps - no principle needed.

(In addition, the US government requires additional reporting and oversight of your bank account. For example, the bank can be in trouble if they decline to notice a pattern of structuring your transactions to be under the $10,000 reporting limit to the government.)

1) Your comment has an answer.

2) They can detect that the computer is running near 100%, but I guess there are a lot of legit users that use near the 100%.

3) I'm not sure of the privacy conditions, but most people would not like that Amazon peeps into their VM. Perhaps you are simulating a new secret drug medicine, or you are enhancing a porn video, or you are encrypting/decrypting your users post/photos, or you are deep mining health information to send medical spam/advertising/advice. These don't use a massive sha calculation, but it may be difficult to notice the difference automatically.

4) The more similar real word application I can think now is doing a massive git rebase (rebase all the Linux kernel from start, or all github repositories). IIRC git uses sha-1 and bitcoin uses sha-256, so this is not an exact application.

5) They would have to test the use of instance to mine scrypt based coins, like Litecoin. And other mining schemes ...

Isn't the statement "Amazon doesn't have access to the data on the instance" totally wrong? How can you 'not have access' to the data on a VM you're personally running?

Your answer (3) makes sense, but wouldn't these people opt in to lift this limit? I can think of few such applications that someone would elect to run on Amazon without knowing it in advance.

do people really do (4) on amazon's hardware? (instead of their own).

In (5) are you saying that this, combined with (2) is not really possible for them technically? Why not?

It just seems trivial to me. If there are false positives you could lift the restriction out-of-band (not with your normal credentials, like the 'atm card/pin' combination.)

I know I would prefer to keep that protection in place, just as I keep my ATM daily limit in place.

Amazon EC2 is HIPAA compliant. As such, it has specific restrictions in place. Quoting from http://d36cz9buwru1tt.cloudfront.net/AWS_HIPAA_Whitepaper_Fi... :

> For Amazon EC2, AWS employees do not look at customer data, do not have access to customer EC2 instances, and cannot log into the guest operating system. AWS internal security controls limit data access.

Yes, since they have physical access to the machines, it's possible to get access. However, it's not designed with that in mind. Adding that capability would make it harder to be HIPPA compliant, which is something they want to do. Also, there's AWS GovCloud http://aws.amazon.com/govcloud-us/ for government computing which has its own level of confidentiality. It's more expensive to have 3 different infrastructures than one.

There are many whitepapers about running #3 on EC2. I think your lack of knowledge isn't a useful guide.

As for (4), my own data system does about 40 million SHA2s during a database update.

Thanks (upvoted.) This was the answer to my question, thank you. It is interesting though that per the original write-up at

https://news.ycombinator.com/item?id=8817299

"When I woke up the next morning, I had four emails from Amazon AWS and a missed phone call from Amazon AWS."

So Amazon clearly did have some very clear fraud signals.

I agree with you that my lack of knowledge isn't a guide, which is why I phrased it in the form of a question and asked HN. Your current comment is in fact the only actual (and perfectly sufficient) answer.

---

EDIT: regarding 4), out of curiosity, if they could legally and were allowed to tell programmatically if miner proceses were running and stop these for you, would you want them to? [preauthorize them to check and not allow it unless/until you lift this]. I would do so personally, as an added measure of security simply due to the incentive people have to steal my keys for this reason, and the fact that as a practical matter it does happen - as in the write-up, in which a .gitignore was ignored.

>so I installed the Figaro gem (a rails API key security gem), and trusted it to keep my API key off of git when I pushed. I opened the console and git push origin master to send the new version of my app, Shriek to Heroku.

>Figaro pops up on the command line as usual, but this time instead of saying “created application.yml, created .gitignore” It just said “created application.yml”.

It certainly sounds like something that could happen to me, or anyone, and does every day. but it sounds like you would not opt in to this? just curious.

Accounting signature changes - eg, starting a large number of machines - is different than inspecting the VM. That alone could be the source of the fraud signals.

My software works with proprietary chemical structures. I would not want Amazon's scanners looking at it. I want to be able to tell potential customers/clients that it's secure.

A signal for unexpected charges (based on past history), combined with a generous waiver policy, which seems to be the case now, is all I need.

keeping your credentials safe instead of relying on amazon sounds a lot easier to me

It's not either/or is it? This is something that is one of the biggest incentives to steal credentials: it is immediate, untraceable cash. (bitcoin.)

your argument is like saying a daily withdrawal limit (like $500) you can lift at any time isn't sane, because "keep your card and PIN safe" sounds a lot easier. Well, yes, but the point is your card/pin can (and does) get stolen, and so do Amazon credentials.

I just don't understand why they don't add that extra layer.

(Well, I can understand. If 98% of the clients with stolen access are huge companies that have no idea whether their charge should be $170 or $85,000 per month and are happy to pay either, then the policy might make sense to Amazon. But that doesn't seem likely, as they go out of their way to try to reach you and notify you that this might be happening. . .)

I wasn't making an argument but I see where you are coming from. with your bank card analogy, at least here in Ireland there is no liability on the account holder for theft or fraud anymore so even if you don't keep those things safe the bank takes the hit. That seems to be the strategy amazon is taking at the moment, if that gets too expensive for them i am sure they will invest in another layer of protection. Now that I think about it it also seems like this is an opportunity to win the loyalty of a customer. By contacting them, explaining the problem and the solution and then by waiving potentially large charges from their account without hassle they are garnering a lot of trust. Just a random thought that popped into my head

Reply on news.ycombinator.com