5 ms·

ASP.NET Core Elevation Of Privilege Vulnerability

76 points by yread 9y ago

figers 9y ago
"Apps hosted in Azure Web Apps are not susceptible to this vulnerability."
- giancarlostoro 9y ago
  Was the first thing I was looking for, thankfully it's reasonably at the beginning of the article.
- ams6110 9y ago
  Are not now (ie already patched), or were never vulnerable?
  - Someone1234 9y ago
    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).
  - breakingcups 9y ago
    Presumably the way it's proxied makes it immune by default, just as proxying through IIS without a wildcard would.
sjustinas 9y ago
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?
- gtsteve 9y ago
  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-of-host-header-attacks/ https://www.acunetix.com/blog/articles/automated-detection-o... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0787 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0787
- yread 9y ago
  Hopefully Mr. Shcherbakov will provide more details
- SideburnsOfDoom 9y ago
  > 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-372801591 https://github.com/aspnet/Home/issues/2954#issuecomment-3728...
  - duozerk 9y ago
    Actually and if you're against full disclosure it's the exact reverse of "awful".
    - SideburnsOfDoom 9y ago
      I'm in favour of full disclosure ... eventually. Today does not seem like the right time for that yet.
- j0hnml 9y ago
  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.
euroclydon 9y ago
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...
deleted 9y ago
[deleted]
Cshelton 9y ago
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.
- symlinkk 9y ago
  Maybe if Kestrel isn't ready yet they shouldn't be releasing it? Actually a lot of .NET Core feels half-finished.
  - Someone1234 9y ago
    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.
  - Cshelton 9y ago
    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.
    - m_fayer 9y ago
      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.
qYXgq1Qp 9y ago
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 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.
- EdOverflow 9y ago
  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-header-attacks.html http://www.skeletonscribe.net/2013/05/practical-http-host-he....
magnat 9y ago
> 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.
- barake 9y ago
  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/servers/kestrel?tabs=aspnetcore1x#when-to-use-kestrel-with-a-reverse-proxy 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.
- oaiey 9y ago
  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).
morrbo 9y ago
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.

76 points by yread 9y ago

figers 9y ago

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

giancarlostoro 9y ago
Was the first thing I was looking for, thankfully it's reasonably at the beginning of the article.
ams6110 9y ago
Are not now (ie already patched), or were never vulnerable?
- Someone1234 9y ago
  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).
- breakingcups 9y ago
  Presumably the way it's proxied makes it immune by default, just as proxying through IIS without a wildcard would.

sjustinas 9y ago

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?

gtsteve 9y ago
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-of-host-header-attacks/ https://www.acunetix.com/blog/articles/automated-detection-o... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0787 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0787
yread 9y ago
Hopefully Mr. Shcherbakov will provide more details
SideburnsOfDoom 9y ago
> 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-372801591 https://github.com/aspnet/Home/issues/2954#issuecomment-3728...
- duozerk 9y ago
  Actually and if you're against full disclosure it's the exact reverse of "awful".
  - SideburnsOfDoom 9y ago
    I'm in favour of full disclosure ... eventually. Today does not seem like the right time for that yet.
j0hnml 9y ago
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.

euroclydon 9y ago

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...

deleted 9y ago

[deleted]

Cshelton 9y ago

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.

symlinkk 9y ago
Maybe if Kestrel isn't ready yet they shouldn't be releasing it? Actually a lot of .NET Core feels half-finished.
- Someone1234 9y ago
  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.
- Cshelton 9y ago
  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.
  - m_fayer 9y ago
    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.

qYXgq1Qp 9y ago

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 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.

EdOverflow 9y ago
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-header-attacks.html http://www.skeletonscribe.net/2013/05/practical-http-host-he....

magnat 9y ago

> 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.

barake 9y ago
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/servers/kestrel?tabs=aspnetcore1x#when-to-use-kestrel-with-a-reverse-proxy 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.
oaiey 9y ago
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).

morrbo 9y ago

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.