File Retrieval Gateway
This was a WSO file download. Some entity at 91.197.19.103 logged in to my honey pot's fake WSO shell and downloaded two, Unix-format (ASCII linefeed end-of-line) lines of text. The get3.php file got downloaded 5 times between 2013-06-26T11:35:16-06 and 2013-06-26T14:22:16-06
Obfuscation
The PHP code had all end-of-line and indentation whitespace removed. Some insignificant token-separating whitespace was removed. For instance, phrases like global$variable; appear regularly, but no human would ever write that code. The code contains no comments. Function names are not encoded or obfuscated.
The obfuscation takes advantage of PHP's non-unique strings: "ABC" and "\x41\x42\x43" lexically equivalent. Almost all string literals in this code get "encoded" by randomly selecting characters to represent with \xNN escapes. Further, the obfuscation uses PHP's variable indirection: $some_var and ${'some_var'} and $another_var = 'some_var'; ${$another_var} all evaluate to the same thing. Obfuscation combined the non-unique strings and variable indirection quite often.
The obfuscation varied use of equivalent ways to reference variables: $xyz, ${'xyz'}, ${'\x78y\x7a'}, etc can all refer to the same variable. The code also liberally uses 1-length arrays instead of scalar variables. Equivalent forms are used randomly, not on any consistent basis. This suggests automated obfuscation.
Run time camoflage
The code contains lists of things that cause it to return an HTTP 404 code, along with a 404 HTML page that it contains.
- List of IP address prefixes to not service, including 127.0.0.1
- List of user agent substrings to not service.
- Requires exactly one GET parameter, value has to have an '_' (underscore) in it.
It returns a 404 error code and some built-in HTML when any requirement fails. Giving a 404 on any 127.0.0.1 IP address probably prevents some human administrators from finding the code when poking around with a browser. Any User-Agent with a substring of "Linux" or "Macintosh" gets a 404, so I presume the miscreants are Windows Fanboys. Most library code that does web spidering will also get a 404, if the library code is honest about the User-Agent.
Action
Ultimately, it does this:
file_get_contents($complicated_url);
The $complicated_url contains one of 3 IP addresses, information about the system on which the gateway code executes, and a file name, which comes to the gateway code in the GET-style URI used to call the gateway.
The gateway returns whatever it fetches from one of the 3 IP addresses (presumably the file named in $complicated_url). It then sends the file back to the caller's computer marked as Mime-type "application/zip" and gives a file name.
I was never able to trigger an actual download from any of the 3 IP addresses, and I never caught anyone calling on it, so I have no idea what files it could gateway.
Coding Style
It depends on file_get_contents() working on URLs as well as local file names. That's a per-site configurable item. At least some sites configure it off, so this gateway won't work everywhere. I suppose the writers are gambling that they'll find a loosely-configured PHP installation, just like they found a WordPress installation with an easily-guessable password.
Similar Gateway
Some days later, the same IP address that sent the obfuscated gateway code, downloaded another gateway program. This new code is not obfuscated, and doesn't try to conceal itself with run-time checks on how it's called or who called it. It does contain the core functions of the obfuscated version. It even names those functions as the obfuscated code does. It does differ in the remote source of the files gatewayed - this gateway gets files from http://78.138.118.125:443/7ntomlfsf.php, which is not one of the 3 URLs in the obfuscated version. Perhaps this program was the base for the obfuscated version analyzed above. Why would the same IP address download both versions?