6

In my Drupal 7 logs I see entries such as:

http://example.com/?q=file/ajax/name/%23value/form-tkSDwR6W66a8vR_AIDxAzwMVklkjTkNMjf8SEqfTX8Q

There are several entries like this one, with only the last string changed.

It is by an unauthenticated user.

I tried to access the URL as well, and I get the following:

[{"command":"settings","settings":{"basePath":"\/","pathPrefix":"","themename":{"topoptiontext":"Page selection"},"ajaxPageState":{"theme":"themename","theme_token":"xxxxxx"}},"merge":true},{"command":"insert","method":"replaceWith","selector":null,"data":"\u003Cdiv class=\u0022messages error\u0022\u003E\n\u003Ch2 class=\u0022element-invisible\u0022\u003EError message\u003C\/h2\u003E\nAn unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (128 MB) that this server supports.\u003C\/div\u003E\n","settings":null}]

In the above log entry I removed the name of my theme and replaced the toke with xxxx I guess the attacker did not manage to get in.

My site is patched to the latest version 7.58

Should I worry about it? Is there something that I should be doing to prevent it?

Many thanks

MMT
  • 97
  • 5

1 Answers1

6

This looks like part of an attempt to exploit CVE-2018-7600 aka SA-CORE-2018-002, the vulnerability that was fixed in Drupal 7.58 (and 8.3.9, 8.4.6 and 8.5.1). This was being widely exploited at the time this question was asked.

If you were already running a fully patched Drupal then you were not vulnerable to this attack. However, Drupal 7.58 is now known to be vulnerable to a similar attack, so you should make sure to update to the latest version, if you haven't already.

Generally anyone using Drupal should make sure to keep both Drupal core and any modules and themes they use up to date (this is true of all software). Drupal publishes its security announcements, along with information about how to get notified when they become available, at https://www.drupal.org/security.

If you have any Drupal sites that are still not patched, see https://www.drupal.org/docs/develop/security/your-drupal-site-got-hacked-now-what.

If you're interested, you can add $conf['sanitize_input_logging'] = TRUE; to your settings.php file (on a fully patched site) to enable additional logging of detected attempts to exploit this issue. You will then start to see messages about "Potentially unsafe keys removed..." in your watchdog log when an exploit attempt is detected.

The original attack (for Drupal 7) is in two parts. The first part makes a crafted request to a page with a form, usually the password reset form, to store a special value in a cache; the second requests the /file/ajax... URL in a way that tricks Drupal's form API into misinterpreting the cached value and executing some code contained within it. The first request is the one that will be sanitized by the fix in Drupal 7.58. The second is what you're seeing in the log here. (The additional fix in Drupal 7.59 adds additional sanitization for both). The random value is the cache key, known in Drupal parlance as the form build ID.

I guess an exploit of CVE-2018-7602 might look similar, although the announcement seems to indicate this one isn't exploitable by an unauthenticated user, and in any case details weren't public at the time.

John Morahan
  • 1,971
  • 2
  • 10
  • 9
  • You are right that there are many requests like this about 3-4/day, each one with a different last argument in the URL, and a different xxx in the answer as shown on the page. Is the attacker gaining some inside info with these many theme-tokens (xxxxx in my above sample)? Or maybe it's just an automated attack? I do not fully understand what you mean by first and second...In my logs I see this type of URL being called 3-4 times a day, and every time I get 3-4 errors. – MMT Apr 21 '18 at 19:25
  • The attack is in two parts. The first part requests a page with a form, usually the password reset form, setting up the exploit, and extracts the generated form build ID (which is the random value you're seeing). The second part submits that value back to the file ajax URL to actually run the prepared exploit. If it's happening a lot, it's probably either automated or coming from multiple attackers, or both - there's rather a lot of this going around at the moment. – John Morahan Apr 21 '18 at 19:48
  • Actually the requests you asked about [here](https://security.stackexchange.com/questions/184273/drupal-7-username-attempt) are the first part :) – John Morahan Apr 21 '18 at 19:51