ASP.NET Core Elevation Of Privilege Vulnerability | Hacker News Reader

ASP.NET Core Elevation Of Privilege Vulnerability

github.com

76 pointsyread31 comments

I mean, to be fair to them somewhat, it is in their documentation and getting started guide. They highly recommend, in a production environment, to put a .Net Core web app behind a proxy because the Kestrel server engine is so new, every case is not handled yet. I'd hope, being Microsoft, that nobody just ignored that.

Maybe if Kestrel isn't ready yet they shouldn't be releasing it? Actually a lot of .NET Core feels half-finished.

It is an open source project, if they don't release it they cannot start receiving community feedback, patch sets, and bugs. Which means a lot of stuff still won't be found until it is released, no matter when that is.

.Net Core is definitely half baked but it is a pretty ambitious undertaking. They're completely re-developing .Net from the ground up to be cross platform, no small task.

For its intended purpose, it is ready enough and stable. But that is the point of open source as well, to have outside input into decisions made early on. Besides, is anything release actually fully ready yet? I don't think releasing it was a bad idea. .Net Core does seem to be moving fast but things are now stabilizing and it has been a combined effort of internal and external Microsoft developers, which is great for them. If they had simply released another .Net framework 5, I think a lot of developer mind share would have gone elsewhere. Open source was the right decision, and despite it feeling half-finished, it's actually a great improvement. Things will stabilize.

As of 2.0, ASP.NET Core does finally feel ready for primetime to me. I've been revisiting the whole picture periodically for 2 years, and finally the tooling seems to be complete and performant, and the end result and developer experience finally seem to have been worth all the headaches.

I don't think you've used .NET Core recently if you're saying that it feels half-finished. This is just FUD. At this point, .NET Core, especially 2.0, is excellent for almost every use case except native app development. Even then, you've got .NET Native attempting to solve that problem. The last time .NET Core was "half-finished" was probably its 1.0 release.

Have they finished Entity Framework yet?

Actually the fun topic of DB translated JOIN support was just announced as finished. Just that I do not remember for 2.0 or upcoming 2.1 release :)

Group by translation to SQL is still in the 2.1 preview. Even then it only supports grouping on columns from a single table at a time.

EF is not everyone's cup of tea. Dapper works just fine in Net Core 2.

I am still waiting for EF 6 feature parity, including DB visual designers, and Xamarin.Forms support for all .NET Core platforms.

They recommend not using Kestrel for an internet facing app and I agree. There is no reason not to use it for services that are not internet facing.

What an awful disclosure.

> <...>an elevation of privilege vulnerability exists when a ASP.NET Core web application fails to validate web requests correctly.

Fails to mention what "validating a request correctly" means. Recommends to limit allowed Host header values as a mitigation, but does not say what values are safe to accept. Example.com? localhost? 127.0.0.1? covfefe?

Host header attacks aren't exactly new [0]. However it seems that this is deliberately vague to prevent people from exploiting it whilst systems are patched. I note that the CVE details [1] are not yet available, so perhaps the actual issue is a bit more complex.

[0] https://www.acunetix.com/blog/articles/automated-detection-o...

[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0787

Hopefully Mr. Shcherbakov will provide more details

> What an awful disclosure. Fails to mention what "validating a request correctly" means.

Click one link, the first one in the main page text, scroll down, and you're here (1)

> Q: Are there any more details on what "fails to validate web requests correctly" means and/or a PoC for this?

> A: No. We don’t publish more details or PoCs.

This seems entirely deliberate and unsurprising on day 1 when few have applied the patch yet, and is therefore not "awful".

1) https://github.com/aspnet/Home/issues/2954#issuecomment-3728...

Actually and if you're against full disclosure it's the exact reverse of "awful".

I'm in favour of full disclosure ... eventually. Today does not seem like the right time for that yet.

Yeah, and it sounds more like RCE than a privilege escalation vulnerability. I wonder if there deliberately being brief and misleading about it to prevent attacks.

As usual, the .NET Core announcement contains no technical information, making it impossible to assess the actual impact for a specific application...

There's slightly more info here, which makes it sound somewhat less severe:

https://securitytracker.com/id/1040525

"ASP.NET Kestrel Web Application HTML Injection Flaw Lets Remote Users Reset the Target User's Password

A vulnerability was reported in ASP.NET. A remote user can inject HTML to reset the target user's password.

Kestrel web applications do not properly validate web input. A remote user can supply a specially crafted request to inject HTML and cause a 'password reset' email to be sent to the target user. The password reset may be triggered when the target user opens the email."

(edit) So I guess the host header somehow ends up in the password reset email without any filtering/escaping? Maybe you could abuse that by turning the password reset link into an <img> link to a server you control, with the password reset secret at the end. Once the image is loaded you get the password reset secret and can use that to get into the account. Something like that?

Not sure if I would classify that as a Kestrel issue.

This sounds like something along the lines of password reset poisoning as described in James Kettles' technical write-up "Practical HTTP Host header attacks". [1]

[1]: http://www.skeletonscribe.net/2013/05/practical-http-host-he....

"Apps hosted in Azure Web Apps are not susceptible to this vulnerability."

Was the first thing I was looking for, thankfully it's reasonably at the beginning of the article.

Are not now (ie already patched), or were never vulnerable?

Likely never, as Azure Web Apps uses a modified IIS and strongly bound bindings (e.g. *.azurewebsites.net) to work. This seems to impact only host headers delivered directly to Kestrel. There's no scenario I know of where you'd be able to do that in Azure Web Apps (since the whole thing is powered by IIS, even when .Net Core is in use).

Presumably the way it's proxied makes it immune by default, just as proxying through IIS without a wildcard would.

> No patches are available for ASP.NET Core 1.0.x or ASP.NET Core 1.1.x. Microsoft requires that you place your 1.x ASP.NET Core application behind a proxy (...) If you're not running ASP.NET Core 1.x behind a proxy, you must either place a proxy in front of your application or upgrade to ASP.NET Core 2.0.

This is quite alarming. Does this mean I'll have to continuously upgrade my applications (and all third-party libraries) to the newest .NET Core version to receive security updates? Upgrading from 1.1 to 2.0, when you reference dozens of external packages isn't too pleasant, even for small applications.

Since the 1.0 release the docs, tutorials, quick starts, etc have said not to expose ASP.NET Core Kestrel based apps directly to internet traffic.

Here is the current version of the docs that mention this: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/se...

The warning was repeated all over the place - you can search the web dig through the git history of the docs and see the warning to use a reverse proxy all over.

They probably should have made Kestrel complain loudly if it detected it was exposed and "force" everyone to be successful, but it's only partially their fault if people ignored the documentation.

For .NET Core MS recommended for security reasons to put any .NET Core Kestrel standalone apps behind a proxy. This concrete statement is therefore valid (because it should have been done like that).

In the past they had vulnerabilities covered in multiple versions at the same time. But keep in mind LTS support versions. Some of the 1.x will soon run out of their lifecycle (when I remember right).

Wonder what the vulnerability is? I can send any host header I like if I make a request from outside a browser. Maybe some special localhost magic baked into the Core self-host...

mods, if this is bad just delete it but it is public info now so i think quite an interesting vulnerability.

Just had a very quick look over the relevant code bits... it does look like it would just be an attacker-specified domain.. i.e. the following code is used for the default (new mvc app) uses:

                var callbackUrl = Url.ResetPasswordCallbackLink(user.Id, code, Request.Scheme);
                await _emailSender.SendEmailAsync(model.Email, "Reset Password",
                   $"Please reset your password by clicking here: <a href='{callbackUrl}'>link</a>");

which alllll the way down buried within the mvc or kestrel codebase (i forget which) is plucked directly from the host header. As kestrel listens globally, then i'd guess that the attacker would just sub out the regular domain with mynastydomain.com, and it would send someone an email with mynastydomain.com/reset?link=xxx. To fix this as they've recommended you'd wanna validate the domain via middleware (or just regex the password reset link before sending it out) or just not use the inbuilt authentication functionality/helpers whatsoever to reset passwords (and/or hardcode your domain).

looking at the actual code fix itself, is quite interesting. Apparently the following special characters are allowed in valid domains:

     // Matches Http.Sys
            // Matches RFC 3986 except "*" / "+" / "," / ";" / "=" and "%" HEXDIG HEXDIG which are not allowed by Http.Sys
            HostCharValidity['!'] = true;
            HostCharValidity['$'] = true;
            HostCharValidity['&'] = true;
            HostCharValidity['\''] = true;
            HostCharValidity['('] = true;
            HostCharValidity[')'] = true;
            HostCharValidity['-'] = true;
            HostCharValidity['.'] = true;
            HostCharValidity['_'] = true;
            HostCharValidity['~'] = true;

looking at the link generated, it is possible to close off the <a href='{callbackUrl}' by adding in a single quote on a specified domain (even after the fix)... before the fix i'd imagine you could cause potential XSS or something as "=" would have been valid, meaning that you can add an event handler. All of these would get stripped off anyway from all major email clients so ¯\_(ツ)_/¯

* edit * reason i wrote this and went into so much detail is that looking at the (imo pretty poor) advisory, i'd be vulnerable to this. Whereas in reality i am not. Others using their own authentication schemes or hard-coding values everywhere (as opposed to using the helper functions to generate URLs) would also be ok, i think.

Reply on news.ycombinator.com