I would normally say that "That must be a coincidence", but I had a client account compromise as well. And it was very strange:
Client was a small org, and two very old IAM accounts had suddenly had recent (yesterday) console log ins and password changes.
I'm investigating the extent of the compromise, but so far it seems all they did was open a ticket to turn on SES production access and increase the daily email limit to 50k.
These were basically dormant IAM users from more than 5 years ago, and it's certainly odd timing that they'd suddenly pop on this particular day.
Receive an email that says AWS is experiencing an outage. Log into your console to view the status, authenticate through a malicious wrapper, and compromise your account security.
Good point. Phishers would certainly take advantage of a widely reported outage to send emails related to "recovering your services."
Even cautious people are more vulnerable to phishing when the message aligns with their expectations and they are under pressure because services are down.
Always, always log in through bookmarked links or typing them manually. Never use a link in an email unless it's in direct response to something you initiated and even then examine it carefully.
You can also use phishing-resistant login/2FA like passkeys/FIDO keys, where it is available (and I'm pretty sure amazon supports it), to minimize the risk of accidentally login into a phishing website while under pressure.
If my memory is correct, AWS supports FIDO for web login but not for the API, so you either have to restrict access to FIDO and then use the web UI for everything done as that user, or have a separate non-FIDO MFA device (without FIDO's phishing resistance) for terminal/API interactions.
You don't put the temporary credentials behind FIDO because they're temporary anyway. You put FIDO on the main account that has the privilege to generate the temporary credentials.
So in the off chance that you get a phishing mail, you generate temporary credentials to take whatever actions it wants, attempt to log in with those credentials, get phished, but they only have access to API for 900s (or whatever you put as the timeout, 900s is just the minimum).
900s won't stop them from running amok, but it caps the amok at 900s.
You aren't grokking what I'm saying. AWS does not allow FIDO2 as an MFA method for API calls.
So if your MFA device for your main account is a FIDO2 device, you either:
1. Don't require MFA to generate temporary credentials. Congrats, your MFA is now basically theater.
2. Do require MFA to generate temporary credentials. Congrats, the only way to generate temporary credentials is to instead use a non-FIDO MFA device on the main account.
Nobody is getting a phishing email, going to the terminal, generating STS credentials, and then feeding those into the phish. The phish is punting them to a fake AWS webpage. Temporary credentials are a mitigation for session token theft, not for phishing.
Require FIDO2-based MFA to log into AWS via Identity Center, then run aws sso login to generate temporary credentials which will be granted only if the user can pass the FIDO2 challenge.
The literal API calls aren't requesting a FIDO2 challenge each time, just like the console doesn't require it for every action. It's session based.
I definitely wasn’t grokking that, because the prior commenter never mentioned AWS Identity Center, and instead linked to STS, which works how I described (you can’t use FIDO MFA for the authentication of the call that gives you your short-lived session creds).
I’m excited to see that Identity Center supports FIDO2 for this use case.
> Always, always log in through bookmarked links or typing them manually. Never use a link in an email unless it's in direct response to something you initiated and even then examine it carefully.
If you still want to avoid the comfort of typing in stuff manually or navigating the webinterface, logging in on a new tab and then clicking on the link is also an option.
Mini-rant here but I hate how websites for SaaS products are so over-optimized for the sales funnel. It's like giant blue button to sign up, teeny tiny link to login, if there is even one at all on any of the main pages. Often your access is on an entirely different subdomain that barely ranks on Google. If it's something that "just works" and you only access every 6 months, it's pain to go hunting through your email to rediscover if it's clients.example.com, portal.example.com, or whatever the heck it is.
I hate how many sites do that, always a signup first then a small little "Already have an account" link below that. Feels almost hostile to your existing users.
These were accounts that shouldn't have had console access in the first place, and were never used by humans to log in AFAICT. I don't know exactly what they were originally for, but they were named like "foo-robots", were very old.
At first I thought maybe some previous dev had set passwords for troubleshooting, saved those passwords in a password manager, and then got owned all these years later. But that's really, really, unlikely. And the timing is so curious.
Almost this exact thing happened to me about a year ago. Very old account login, SES access with request to raise the email limit. We were only quickly tipped off because they had to open a ticket to get the limit raised.
If you haven't check newly made Roles as well. We quashed the compromised users pretty quickly (including my own, the origin we figured out), but got a little lucky because I just started cruising the Roles and killing anything less than a month old or with admin access.
To play devil's advocate a bit. In our case we are pretty sure my key actually did get compromised although we aren't precisely sure how (probably a combination of me being dumb and my org being dumb and some guy putting two and two together). But we did trace the initial users being created to nearly a month prior to the actual SES request. It is entirely possible whomever did your thing had you compromised for a bit, and then once AWS went down they decided that was the perfect time to attack, when you might not notice just-another-AWS-thing happening.
Thanks for sharing. After digging in, it appears that something very similar happened here, after all. It looks like an access key with admin role leaked some time ago. At first, they just ran a quiet GetCallerIdentity, then sat on it. Then, on outage day, they leveraged it. In our case, they just did the SES thing, and tried to persist access by setting up IAM Identity Center.
I wonder if a few cases of compromise right after the outage can also be a coincidence. If we have a lot of reports of the same, then it gets interesting.
(The particulars of your case being strange is a separate question though.)
I find your public road network analogy interesting. Should your car require you to prove your age before it will start? How else can we protect your kid (and others) from the dangers of an 8 year old taking the family sedan for a spin?
No, eg, liberal capitalist Americans oppose Marxism — and the adoption of neo-Marxist ideas has collapsed movie and game sales because their ideology is widely unpopular.
That’s a trope by Marxists to attempt to normalize alt-left ideology by accusing anyone who objects of being Nazis; a trope that’s become tired in the US and minimizes the true radical nature of the Nazi regime.
Notice the motte and bailey here: using the uncontroversial "liberal capitalist Americans oppose Marxism" claim to advance the idea that whatever social views they call "neo-Marxism" are unpopular.
I think there's diminishing returns. A broad, liberal arts, undergraduate education develops critical thinking and reading skills in a zero-to-one kind of way. Once you've attained those skills (whether through a college degree or some other way), further enrichment via self-study is much more easily doable.
This is definitely true. I think pre-graduate college is pretty eye opening, at least when I went. In most high schools, they just cover the top layer of knowledge; in college they go quite a bit deeper. "They never taught us that in high school," is a saying that applies.
I don't get your strong objection. A 1.0 release that is fit for use by >80% of the addressable market, and gets high marks from those users is a "boondoggle"?
Perhaps you overestimate the fraction of taxpayers that itemize deductions, have gig/rental/business income?
Structuring (splitting up cash deposits to a bank so that they don't trigger the bank to file a CTR) comes to mind. It does have a mens rea component, but the money being entirely clean doesn't make the act not-structuring, IIUC.
That thinking strikes me as "clear, simple, and wrong". (I appreciate that 230's bright-line rule may also be clear, simple and wrong)
Consider defamation. Often, the difference between a defamatory and non-defamatory statement is truth. Expecting websites to distinguish true statements from false ones is a non-starter.
Let's say my family has a horrible experience with a youth pastor. I post about it on facebook to warn people in my community. If my claims are false, they're almost certainly actionable defamation. If my claims are true, disallowing them to mitigate Facebook's potential liability is also bad, but not in a way that affects Facebook.
The idea that there's an indistinct difference between "publisher" and "common carrier" doesn't seem right. Google or Facebook are not, and have never been, common carriers. The entities that most resemble "common carriers", as that term is historically used, are infrastructure-layer companies. I don't see how the distinction could be sharper.
Monopoly concerns are better addressed by going after monopolies for being anticompetitive. Intermediary liability seems pretty orthogonal to competition concerns. I would need a lot of convincing to start believing that categories like search or even social media (despite network effects) are natural monopolies akin to railroads or POTS-type phone companies of yore – where you can't have efficient competition, and don't have thorny 1A issues to deal with, so common-carrier approaches are defensible.
As an aside, one reason I think 230 pretty much correct is that authoritarians on both sides of the spectrum want to axe it, but for different reasons.
OK, but you ignored the "mergers and acquisitions" point: if they're big enough to have acquisitions scrutinized closely (but not big enough for antitrust actions, as your points address), then maybe they should lose some 230 protections.
Why though? Seems to me that while any website of any size that allows any kind of user generated content (without every post being pre-approved before it goes live) needs protections like what Section 230 is meant to provide, the more users posting, the harder your problems are and the more important those protections are…
I mean, you can make the argument “I don’t like big tech so I want to make it impossible for them to legally function while allowing any user-generated content” but I’m not sure most would agree.
The "idea that these providers are simply neutral carriers of content" is a false premise, isn't it?
The piece you link is ... weird. First, it doesn't really describe the problem it's trying to solve. Then it presents some very vague policy prescriptions like "site[s] should be regulated by sector-specific rules that apply to that particular line of business".
There’s probably better writing on this by Matt Stoller that’s just the first thing I found.
A core premise of this argument is that 230 is bizzare exception to pretty clear core rules that we typically have on things like libel and product liability.
There’s just absolutely no argument at this point that these platforms are fundamentally consequential commercial enterprises. The create products, and profit from them, and those products and and do hurt people and cause horrible effects, but this law designed to preserve free speech utterly insulates them from any consequences of their profit making enterprise.
It’s just bizarre. Like the Washington Post can be sued for publishing content that’s harming people and wrong, but Google can’t?
If my kids are exposed to pedophiles every time they go to Chuck E Cheese, and they know about it and don’t do anything I can sure as hell can sue them. But not if it happens on Instagram? Why?
Any article published by the Washington Post is written by agents of their company, and that's why they are the responsible entity. Should you be able to sue every newsstand in your local city if they are selling a newspaper that defames you? After all, those newsstands are profiting from the sale of libelous content...
Client was a small org, and two very old IAM accounts had suddenly had recent (yesterday) console log ins and password changes.
I'm investigating the extent of the compromise, but so far it seems all they did was open a ticket to turn on SES production access and increase the daily email limit to 50k.
These were basically dormant IAM users from more than 5 years ago, and it's certainly odd timing that they'd suddenly pop on this particular day.