For v6 and v7 sites

gistfile1.txt

using System.Web.Routing;
using Umbraco.Core;

namespace RemoveRoutes
{
    public class RemoveRoutesStartupHandler : ApplicationEventHandler
    {
        protected override void ApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
        {
            // Reference: https://github.com/umbraco/Umbraco-CMS/issues/5206
            // Reference: https://shazwazza.com/post/need-to-remove-an-auto-routed-controller-in-umbraco/

            // Note: RouteTable needs System.Web.dll
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbRegister"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbProfile"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbLogin"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-surface-UmbLoginStatus"]);
            RouteTable.Routes.Remove(RouteTable.Routes["umbraco-api-Tags"]);
        }
    }
}

please advise how to test the code and to make sue it works.

thanks

@jennywangCCS - we don't want to post the code to perform a successful exploit here. The code published above has been verified by a third party to eliminate the security problem.

Please note that we have just updated this code and posted a new security advisory.

Please can you provide some detail on how this code can be deployed?

Thanks!

I believe "umbraco-surface-Tags" should be "umbraco-api-Tags".

@yfayerman is correct, see umbraco/Umbraco-CMS#5206 (comment)

Argh.. copy-paste error! Yes, of course, updated to umbraco-api-Tags now!

@nickzureus The easiest way is to save the code as a .cs file and drop it into the App_Code folder of your sites (if App_Code doesn't exist yet, just create it in the root of your site.

You can also choose to compile this code into your other custom code in your site and do a regular deploy.

hi @nul800sebastiaan
if we do not have App_Code folder does that meens that we are vulnerable?
if this fix is a must what the file name should be?

thanks

Hi @emeraldium,

The name of the class doesn't matter. Umbraco will load this file automatically.
More info concerning the ApplicationEventHandler

hi @KurtKellens
but this is a mandatory fix?
what exactly is members breach is?
if we do not allow external users to log into our umbraco but only backoffice users is this fix still apply?

thanks

@emeraldium Whether it's mandatory depends on what agreements you have with clients/customers. It's however strongly advised to always patch security issues if you're impacted by it. The linked blog post explains this in a detailed way...

If you don't use members in both the front-end (login to website) and back-end (to restrict public access), the worst thing that can happen is your database flooding with new members. And having the TagsController API still available will publicly expose all tags. Nothing major in most cases, but it could result in a data/privacy breach depending on the site.

@jennywangCCS perhaps the easiest way to check the code is working is to browse to <yoursite>/umbraco/api/tags/GetAllTags
If the fix is not there, this will return XML (possibly empty if you have no tags like <ArrayOftag xmlns:i="http://www.w3.org/2001/XMLSchema-instance" />)
If the fix is there, it will return 404 not found (or your custom 404 page).
(This information is in the description of umbraco/Umbraco-CMS#5206 so this comment is not exposing anything new)

Guys
can you simplify this issue for me (as i am no umbraco expert like you).
is this issue servility consider critical?
if we only use server requests to interact with umbraco is this resolution needed?
in case we need to implement this fix so we need to save the code above as fix.cs file and implement it at the App_Code folder even if it is do not exist?
thanks

@rangler2 - clearly that only tests if the fix for GetAllTags is applied, it doesn't test the other 4 routing updates.

@emeraldium

is this issue servility consider critical?

We posted the following information for you to consider how critical it is, we've marked it as high priority: https://umbraco.com/blog/security-advisory-july-30th-2019-patch-available/

if we only use server requests to interact with umbraco is this resolution needed?

If your server accepts public requests at all then you are affected. If your server requires authentication for each request you send to it then you are in a much better place, then it would not be possible for random people on the internet to abuse this vulnerability. You could still be vulnerable from people on the "internal" network.
So, in short: Anybody who can access the site can exploit the vulnerability.

in case we need to implement this fix so we need to save the code above as fix.cs file and implement it at the App_Code folder even if it is do not exist?

Yes, you can create an App_Code folder and put the above code in it, saving it to ~/App_Code/Fix.cs is perfectly fine.

I'm having some trouble running my visual studio debugger with the ApplicationStarted method.

I would expect to trace the routes being removed when I run a trace with my visual studio debugger and the solution first runs however, I can't see that happening.

I am using a customized global.asax with an OnApplicationStarted method to manage startup using IoC. Can I just remove the routes from the OnApplicationStarted method for my purposes or does it need to use the ApplicationEventHandler ApplicationStarted method used here?

This code breaks any member login functionality (that is used out of the box) on sites. We had a site that had members managed from the backoffice and after implementing this patch the login no-longer worked. Solution was to keep UmbLogin and UmbLoginStatus enabled. After that we groomed all registered members to ensure that there are no shady registrations that we don't recognize.

My question is - can this backfire, should we be careful about anything related to those controllers? There's not much information regarding UmbLogin and UmbLoginStatus apart that they could be used to exploit the Registration security hole.

@mkyukov - Indeed, it would break that. There's nothing all that harmful in the UmbLogin and UmbLoginStatus controllers, except if an attacker knows they exist then they could more easily try to perform a denial of service attack, especially for UmbLogin since each attempt will require some additional compute power. We added them to the list to be extra cautious mostly.

@nul800sebastiaan - Since we are having the same issue, Does your last comment means we are fine to keep UmbLogin and UmbLoginStatus enabled?

@nul800sebastiaan - Since we are having the same issue, Does your last comment means we are fine to keep UmbLogin and UmbLoginStatus enabled?

@nul800sebastiaan - Could you please advise on the question above, please?

@SarikaRansubhe - the UmbLogin and UmbLoginStatus actions to the best of our knowledge can not cause harm. However, we added them here since they could be used in a DOS attack, expecially UmbLogin.

We recommend you remove those routes and implement your own logic for handling a login and showing the login status. If you're not worried about DOS attacks then you could leave these two action a is.

Hi, do we delete the .cs file from App_Data once we run the website on the public server, or does it stay in there?

@bobi33 It has to stay in place.. it's the only thing protecting you if you do not upgrade to the latest version of Umbraco,