PHParasites: WordPress Malware

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.

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?