Random URL string: What kind of attack is this, and what can be done to stop it?

Question

EDIT:

It's been a little while since this was posted, but I'm here to report that this does NOT appear to have been some sort of attack after all.

Rather, this particular URL string indicates a cookieless session.

It seems that this was nothing more than one (or multiple) of our users hitting our site with cookies disabled, and our app wasn't set up to properly handle this being inserted into the URL string.

I suppose it is still possible that someone was trying to manipulate this effect (the timestamps and frequency were of interest), but I believe this was more likely a case of us jumping on the "we're being attacked!" train a bit too early. It was surprisingly difficult to find information on this!

Ultimately, we figured this out when I encountered this exact URL pattern in our (isolated) test environment and decided to do some additional research on the issue.

Thanks everyone for your help with this, and sorry for any confusion! I'm leaving the initial question intact to avoid invalidating the answers that are already present.

Original Text:

I work for a company that has a public facing website for our customers. In the past several weeks, we have been seeing a series of log entries that look like this:

The controller for path '/(x(1)s(mpwcjessdyhikng0a1kyud1z))/' was not found or does not implement IController.

These entries are typically about 1 second apart and always start with x(1)s followed by a random string of characters, followed by various paths to different pages, especially /account or /account/recoverpasswordrequest/. This tends to go on for 10-30 minutes, and then we don't typically see it again until the next day, although it does happen pretty much every day.

We've blacklisted several IPs that this has happened from, but this person(s) is obviously using many different IPs to run whatever script is doing this.

Can anyone help me understand what is going on here, especially with what x(1)s is, or what kind of information this person might be trying to obtain? The attack happens to be failing because we don't have a randomly named controller that will accept this information, but it would be wonderful to be able to put a stop to this or at least have a better understanding of what's happening.

EDIT: This "request" always follows the same (x(1)s(random)) pattern. There are 3 URLs primarily being hit:

The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/register' was not found or does not implement IController. The controller for path '/(x(1)s(31k5il1as0vxxnbfnnsrzm3b))/account/recoverpasswordrequest' was not found or does not implement IController.

The full URL would be: https://example.com/(these requests)

The site uses MVC, so these particular error messages are due to us not having a controller named (x(1)s(blah)) that this URL can resolve to. The log entries show the same random string being used for all 3 URLs, then a new random string is generated and the same pattern is tried again.

These log entries are from this request failing and causing an exception in our application logic. Therefore, they are bypassing the firewall and actually failing inside our code.

Answer 1

I agree with @RomeoNinov that this is likely fuzz logic/testing or just a scanner sweeping all available applications. In terms of stopping this, you're best off white-listing all acceptable requests. Otherwise you're playing whack-a-mole by blocking all unnecessary requests which is far too large to keep up with.

My recommendation is to leverage IIS Request Filtering since it is native functionality within IIS7+. Add all of the application's URLs (i.e. cs-uri-stem) to the alwaysAllowedUrls setting. Then set the allowable file extensions to the following as it will only allow the default document and no others. Just having these two items in place would have returned an HTTP 404 very early in the IIS pipeline so the request wouldn't have been processed by application code.

<fileExtensions allowUnlisted="false">
    <clear/>
    <add fileExtension="." allowed="true" />
</fileExtensions>

FWIW, I've been posting to my blog about defining thresholds for IIS Request Filtering. There's still much to add but hopefully it will help get you started.

Answer 2

This pattern look for me like fuzz logic/testing.

The reason can be to fingerprint your infrastructure

and/or

Get/find any bug in your web software which can be explited further

and/or

Find nonsecured resources in web site for stealing some internal/customer info.

The usage of fuzz logic also seems to be for search for valid path in the web site/app(s)

P.S. Of course this above is worst case scenario, but in security IMHO this is the way to get good evaluation of particular issue

Answer 3

It appears this can occur if the user has cookies disabled, so it falls back to including information in the URL:

http://blog.syedgakbar.com/2013/02/asp-net-cookieless-session-and-absolute-urls/

Answer 4

Some unix systems do not handle unescaped parentheses correctly in path names, especially if the system is using some kind of script to do URL rewriting or something like that.

I don't know what you mean by "MVC" (System.Web.Mvc framework?).

There is nothing you can do to stop such probing except ban IPs. In the old days when I used to run a web server I had to block the entire island of Taiwan (because at that time all of China's traffic ran through Taiwan).