"If it is on the internet, they will find it". I assume that this has been said many times before by professional Penetration Testers, but it is very important to act this way when you’re brave enough to put something on the web for people to use. Just because it isn’t indexed by the ubiquitous search engines, doesn’t mean that someone out there won’t stumble across your service, or even runs their own crawler that finds it, so it is important be vigilant when your service is deployed, or you could be in for a nasty surprise. With the sheer amount of disclosed breaches, many from large, established organisations like airlines, retail, spyware (yes the spies got spied on) and even forums, we all need to obsess about security.\n\nSo what can happen when you are vulnerable to executing user defined commands on computers that you manage? You shouldn’t be exposing an interface that allows for this, but normally this is an inadvertent side-effect of a procedure which performs another task, like signing in or querying a database. What tends to happen is input validation is poor, and untrusted input (i.e. anything that comes from the internet) is handled directly on the machine you control. This means that a few special characters and commands added after the acceptable part of the input can cause VERY BAD THINGS TO HAPPEN.\n\n*N.B. This is very common in server-side scripting languages such as PHP and CGI, where input parameters are taken from requests and passed directly to server OS functions and the result returned to the user. If you have to execute these kind of commands, YOU NEED TO BE VIGILANT.\n\nI recently blocked a slew of these kind of attacks, all of which were trying to exploit a vulnerability in a (non-existent) login.cgi script. All variants attempted to use this vulnerability to download a payload from an externally hosted server, and then execute on the machine for whatever nefarious purpose(s). Out of curiosity, we decided to fire up a disposable, isolated machine and delve deeper to see what was going on.\n\nOn investigation, most of these rogue servers had been had been taken down, but I was able to obtain a couple of malicious payloads to inspect (before the machine hosts were taken down). In all cases, the initial infection [ATTEMPT] (payload delivery, modification and execution) was performed in the query string for the login.cgi script, using parameters assuming non-existent/poor/broken input sanitisation.\n\n[ATTEMPT_1]\n\n[ATTEMPT_1] is quite straightforward, where the payload itself is a binary file called kohan.mips. Using the permissions afforded by the vulnerable application, this is downloaded to the /tmp directory (standard in Linux-based environments), having read/write access by default (i.e. it cannot currently be executed). The attacker then rectifies the lack of execution by updating the file permissions to 777 for everyone and then subsequently runs the malware using a command shell. Pretty basic, but potentially VERY deadly depending on what function this malware performs (probably doesn’t email all family members suggesting that they have a good day). Information on this nasty seems scarce at the time of writing, and running it within a controlled environment alongside monitoring software was outside the scope of this investigation. Searches suggest that kohan.mips is a variant of the Mirai Trojan, which if true means it is derived from malware used to recruit vulnerable IoT devices into a bit network and weaponize them to deny services through request flooding. Think of it like a cult of computers, ready and willing to do their leader’s bidding!!!\n\n[ATTEMPT_2]\n\n[ATTEMPT_2] Downloaded Script\n\n[ATTEMPT_2] is definitely quirky to say that least (by quirky I mean insidious). The infection is the same as [ATTEMPT_1], but the content of the payload is an executable script with multiple commands rather than an executable binary. I have provided a quick summary of each command below.\n\nFirstly, it defines a (seemingly random) name for the command shell that it intends to run server side. It then defines a list of potential applications to download and execute on the server, as well as their location, which funnily enough is actually a different machine from the one that served the malicious script, which suggests a hacker network of some kind. Once the configuration is finished, it loops around the applications, attempting to download them one by one and run them using a local copy of the command shell with the random name. The truly evil bit is the process substitution line, which uses standard output (program output) as the input to the process being executed on the server. This means that not only is the attacker able to control the machine, they are also able to listen to other command output! There is the potential here for control and snooping, leading to attacks on other servers and full-on data breaches. Nasty stuff!\n\nOnce completing the investigation, I subsequently destroyed the infected machine. These findings highlight just how important it is to remain vigilant when it comes to security, and in light of this, I would recommend the following:\n\nDisable (ideally don’t compile in) directory listing capabilities, as it can allow attackers to learn about your site and quickly find weaknesses.\n\nDisable (ideally don’t compile in) modules that you do not use, in this case CGI cannot be run if CGI isn’t there.\n\nBlock unnecessary file extensions from requests, if you aren’t using .cgi/.php/.jsp, these shouldn’t be able execute.\n\nRemove example/unused code as vulnerabilities in these can be used to exploit your system.\n\nDO NOT RUN APPLICATIONS AS root/admin, instead create a new user+usergroup who’s sole responsibility it is to run your application.\n\nReview permissions on you server and use least-privilege to ensure that running user can do just-enough.\n\nThink of all user input as untrustworthy, and perform validation on the server. User interfaces can be trivially skipped, so any validation there is only for user benefit. Attackers most likely won’t even use your shiny User Interface! There are better tools, such as OWASP Zap and the Burp Suite.\n\nSanitise your inputs, and restrict characters to only those that are needed.\n\nAvoid where possible using client input as the input for command shells and definitely don’t pass unsanitised client input. This is also a common attack vector for SQL injection attacks.\n\nCentralise all log information.\n\nACTUALLY read your logs, as they can be very explicit.\n\nTake care and all the best. Si.