Security vulnerabilities due to resource reuse (subdomain takeover is just one example of this) are rampant and readily exploitable for tons of major companies, especially as cloud providers and SaaS often overlook these as being client responsibilities.
This appears to be a case of differing convention and differing scope.
Our work isn’t fundamentally about just subdomain takeover, which has received substantial academic study (we cited multiple of these). Academic conference papers are highly space constrained, so it’s common to limit cites to seminal conference papers unless no such sources exist. In this case Liu et al. 2016 is the original academic cite and does cite the work you mention. The work you mention also specifically also deals with SaaS-related (not IP-related) subdomain takeover, which is a separate area that we don’t study in our work.
Biggest finding is that adversaries can easily allocate many IPs on public clouds. From this, automated traffic analysis can find what we call latent configurations (e.g., subdomain takeover) and exploit these. For instance you could allocate cloud IPs to collect SNS messages with PII to phish people, or receive passwords or data intended for other sites.
What do you find weird in the tone? I find it succinct, confirming they were already aware of the issue and that they are already working on a (bulk) solution.
If it hadn't taken them almost a year and actual subdomain takeover to fix it, I might be inclined to believe them.
The shameful thing about this is that I get "subdomain takeover" warning emails from Azure on a regular basis. Microsoft has a ton of automation around this for their customers already.
Isn’t Truffle Security opening themselves up to litigation from this? It’s harmless, but is the risk of having Microsoft’s army of lawyers throw CFAA at you really worth this?
These takeovers are often just a case of finding stale DNS entries that are pointed at resources which can be re-allocated by third parties, i.e. elastic IP addresses on AWS. So it's very likely that the person had legit access to that IP, not their fault MS pointed a DNS entry at it when they did not control it.
Fair. I don’t think MS would have a great case in court, assuming the court was technically competent enough to understand the situation upon hearing the case, which is not an easy thing to assume, but I also think many applications of the CFAA (including e.g. the one against Aaron Swartz) also make little more sense when you get to the nuts and bolts of what actually happened. You don’t have to be in the wrong to be bankrupted by the costs of litigation against you from a corporation like Microsoft — not in the US justice system in any case.
Maybe I’m just risk averse here. I assume most of big tech with more legal weight than they know what to do with have about a 50/50 chance of having someone upstairs greenlighting legal to throw a tantrum even if it’s not in anyone’s best interests.
Maybe if this firm demonstrated an exploit of CORS headers elsewhere open to *.microsoft.com or something, they’d be on worse footing legally.
> [...] the risk of having Microsoft’s army of lawyers throw CFAA at you [...]
Especially now that this has been on Hacker News, I don't think even Microsoft is stupid enough to go on the offensive over something like this. The bad press would be so much greater than anything they have to gain.
Exactly, most PR professionals know about the damaging effect of the Streisand effect. There are better ways to ensure this isolated incident doesn't make it to the press, and deal with the independent researchers accordingly for not going through the proper channels.
Someone has added http://cseo-coherence.microsoft.com to their CNAME file on Github Pages, as this domain's DNS entries were already pointing to GitHub Pages.
It's a subdomain takeover, but not as we would normally think of it (getting access to the DNS settings and pointing them to what we want) but from getting "access" to the server the subdomain already points to.
I'm not sure why you're being down voted so hard. You might be a little off topic, but not wrong.
I don't like the idea of consolidation. It's a bad security posture. People love to point out that "they" can secure your data better than you can, but always neglect to mention that a consolidated target has considerably more value. Credential theft results in compromised networks. If you host your own passwords, an attacker would have to start with access in order to steal credentials. If you put all your passwords on a 3rd party server that you can't audit, with millions of other passwords from millions of other customers, it's only a matter of time before they get leaked. In fact, it's almost guaranteed that it will leak, because the value of the prize is millions of times greater.
Why would I waste 3 months trying to hack one business to harvest credentials when I can spend 12 months hacking last pass to get a million passwords? It's a simple cost/ benefit calculation. And lazy administration to think anything different.
So go ahead, consolidate your whole business on infra you have no real authority over. The next major world conflict will result in 4 cloud providers being physically attacked with data centers destroyed and then you will be partly to blame when 90% of the free world's economy disappears overnight.
I’ll preface this with the acknowledgement that httponly is misunderstood by many, but it won’t change anything:
HttpOnly only prevents session theft as you cannot read the cookie, but you can still use it. you can still perform actions by sending AJAX requests with cookies attached.
In a subdomain takeover you receive cookies on all requests, you can view these irrespective of httponly unless you are limited to controlling html and js of the subdomain (which I think is true of GitHub static sites).
HttpOnly is largely a failed mitigation, modern SPAs require access to JWT tokens which compounds that; the solution is to focus on appropriate scoping (to prevent subdomain hijacks having such implications) and preventing XSS.
I read 2 examples of the links provided in the archive.today. Is this attack possible because the sub domain is provided by a CDN/S3 (or public cloud in general)?
What if it doesn't use any CDN? just plain web server serving the site but no longer available or the web server is down.
Without a shared service like this one, you can also have this happen if you CNAME or NS to a different domain and that domain becomes controlled by someone else (for example, if it expires and is registered by a new person).
Also possible with A/AAAA records, if the IP becomes controlled by someone else, that's less likely if you're self hosted with IPs you were assigned directly by an IP registry, than if you're borrowing IPs from a service provider.
Microsoft pointed abc.microsoft.com to GitHub pages through dns. That GitHub repo name was deleted; & eventually available back for anybody to get it. New user gets that repo name. Now new user publishes his content on that repo. Now if you type abc.microsoft.com you will see new user's content.
TIL why aka.ms/whatever is used redirects instead of having the redirect service be on a *.microsoft.com domain. Besides being shorter, I assume that this greatly reduces the risk for subdomain takeover as aka.ms shouldn’t have any associated cookies.
While we were waiting for our friend in the ER (she's fine), one of us downloaded an app that was a giant red button like that one and that's all it played, TURN DOWN FOR WHAT! And you could press it a bunch so it's like "TTTT TTT TT URN URN DOWWN FFFOORR WHAT WHAT! The nurses enjoyed it
It is possible that there can be divided in to 2 groups the people in this world: 1 who's first thought given this opportunity is to rick roll the eff outa the situation, and another group that for some reason wouldn't.
Shameless plug, I’ve worked on identifying/characterizing these issues on cloud providers: https://arxiv.org/pdf/2204.05122.pdf
It’s only a matter of time before adversaries become more sophisticated at identifying and exploiting these in bulk.