51

I just looked at my user agent tracking page on my site (archived on Yandex) and I noticed these user agents. I believe they are an attempt to exploit my server (Nginx with PHP). The 1 in front of it is just how many times the user agent was seen in the Nginx log. These are also shortened user agents and not long ones like Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36. I no longer have access to the logs as I presume this occurred sometime in January or February (my oldest logs are in March and I created the site in January).

1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9\x22{${print(238947899389478923-34567343546345)}}\x22
1 Mozilla/5.9\x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9\x22

What exploit was attempted and how can I test to ensure these exploits are not usable?

forest
  • 64,616
  • 20
  • 206
  • 257
Alexis Evelyn
  • 583
  • 1
  • 4
  • 9
  • 2
    Does the user agent start with `()`? If yes, its probably the [ShellShock exploit](https://en.wikipedia.org/wiki/Shellshock_(software_bug)) – Ferrybig Apr 03 '19 at 08:46
  • 1
    @Ferrybig The shellshock exploit has a very particular syntax: (){:;}; is what triggers it. – Nzall Apr 03 '19 at 11:22
  • 1
    A related question is https://security.stackexchange.com/questions/184115/ . – JdeBP Apr 04 '19 at 12:38
  • Anecdotally, I appreciate that the numbers used are "pretty big." I used to get false-positive results from a vulnerability scanner that would add two 3-digit numbers in its math-problem tests. It would then "match" the sum in a substring of _the `Content-Length` header._ – Michael Apr 04 '19 at 13:29
  • In Plesk there used to be a vulnerability that allowed to execute php code that was within logs. This doesn't seem like it, but the vector of attack looks similar – eithed Apr 05 '19 at 13:00

5 Answers5

61

It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.

In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.

My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.

Dan Landberg
  • 3,312
  • 12
  • 17
  • 5
    Note that when re-testing a payload in this way, you don't check that you weren't vulnerable at the time it occurred (when maybe some updates were not yet made): just that you are not vulnerable *anymore*. Your server could still have been compromised - though I don't say it necessary is the case here. – Qortex Apr 04 '19 at 12:59
  • 1
    That there are these particular (apparently unsuccessful) attempts in the log doesn't mean there hasn't been a successful one, which didn't get logged. Notice how some of these potential commands do have `${...}`, others don't, yet others have `\x22` which is quotation mark `"` etc. ­— the server may have been immune to some combinations of quoting/evaluating while vulnerable to others. – Ruslan Apr 05 '19 at 10:08
22

It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.

DarkMatter
  • 2,671
  • 2
  • 5
  • 23
22

The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).

I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.

So I imagine vulnerable websites were doing something like this (pseudo-code):

var userAgent = request.headers["User-Agent"];

var indexOfVersion = userAgent.indexof( '/' );
var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
var versionNumber = eval( versionText ); // <------- this is the vulnerability!
Dai
  • 1,686
  • 1
  • 13
  • 20
3

it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.

If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.

520
  • 723
  • 3
  • 5
1

This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.

Steve Gazzo
  • 11
  • 2