Web Security Blog

Subscribe to Web Security Blog feed
Official Blog of Trustwave's SpiderLabs - SpiderLabs is an elite team of ethical hackers, investigators and researchers at Trustwave advancing the security capabilities of leading businesses and organizations throughout the world.
Updated: 1 day 14 hours ago

ModSecurity Advanced Topic of the Week: Detecting Malware with Fuzzy Hashing

Tue, 2014-11-25 22:41

In the most recent release of ModSecurity v2.9.0-RC1, we introduced a new operator called @fuzzyHash which uses functionality from the ssdeep tool.  This blog post will demonstrate a powerful use-case with ModSecurity which is identifying malware in web attachment uploads.

What is ssdeep (Fuzzy Hashing)?

The ssdeep project gives the following information:

ssdeep is a program for computing context triggered piecewise hashes (CTPH). Also called fuzzy hashes, CTPH can match inputs that have homologies. Such inputs have sequences of identical bytes in the same order, although bytes in between these sequences may be different in both content and length.

A complete explanation of CTPH can be found in Identifying almost identical files using context triggered piecewise hashing from the journal Digital Investigation. There is a free version of this paper available through the Digital Forensic Research Workshop conference, free version of Identifying almost identical files using context triggered piecewise hashing.

There are some usage scenarios in the Quickstart guide and the Forensics Wiki entry on ssdeep.

The best example of practical fuzzy hashing usage is during forensic investigations when malware analysts want to compare unknown files with known malware families.  Even if the files are different, fuzzy hashing can let you know what malware groups it is similar too and to what degree (%).  Here is link to a previous blog post written by my SpiderLabs Research colleagues who analyze malware where they show ssdeep usage.

Detecting Web-based Malware

When dealing with web application defense, web-based malware such as webshells and backdoors are a huge problem.  Here is an example screen shot of a common webshell:

Here is a quick listing of the top categories of web-malware that we identified in a previous Global Security Report:

Attackers can use many different attack methods to get this malware uploaded to a target website including Remote File Inclusion (RFI) attacks but often times there are file uploading flaws in legitimate application software that can be abused.  This is where our use-case of using the new @fuzzyHash operator in ModSecurity comes into play.  

Fuzzy hashing is so useful in this scenario because standard cryptographic hash testing quickly fails as script kiddies are constantly modifying their code.  Granted, most of the code changes are cosmetic as they rip off each other's code and simply rename it or slap their hacker handle on it and give gr33tz to other kiddies.  These changes, however, render normal hash checks (like with md5 or sha1) almost useless.

Install ssdeep

Before turning to ModSecurity, the first step in this process is to install ssdeep on your web server host.  You can install from source or you can use one of the 3rd party OS repositories (example using - $ apt-get install ssdeep).  Once ssdeep is installed, you can then configure ModSecurity.

Create Fuzzy Hash Listing of Malware

We have captured thousands of webshells/backdoors as part of our research efforts in SpiderLabs.  With this archive, we are then able to use ssdeep to create a text file listing of fuzzy hashes.  Here is  a small example -

$ ssdeep -r -b * > webshells-ssdeep.txt ; head webshells-ssdeep.txt ssdeep,1.1--blocksize:hash:hash,filename 24:OV9QJXQILgD9C7SwKjB8y4skRbsL4J7S52eYwsTdhd/4:QQN7SwAEvRbF7S02sTHp4,"529.php" 192:wUYrBEgQugt1Rv/2gptgSCF4iemhwZt4MWRHOE5wbyzvE1EbKUuHFHgXyc:wUYrBAeH5IU0owbWmEb0HFH3c,"AK-74 Security Team Web Shell Beta Version.php" 768:FpT8+vA/F+OxCDy1L8zWHdzD/xMm/f7+CiA:F3Y/EOxCDy140dzDpMif7+bA,"Antichat Shell. Modified by Go0o$E.php" 192:NQtjv0bj7tJ4q89i8V7y+Q7cmSUwNXMEKhsD2O0b6RWUE:Nej2jL4qinVW++cQwNXMLhsDv0w2,"Antichat Shell.php" 768:O0bU4SbqX+4jl7EBNRjal0OC5eVdVIhyTuIqYDvNTbervZWhVZ21wNX2u89VACrn:FbRSbqOMl7WtaK5ejVeI9zNvoWJD899R,"C99madShell v. 2.0 madnet edition.php" 192:NPgGy+ChwSFHkueyE+C/dw1U2Vk+EndG9X5Mf8x6p1PdFrrELtMIfiA7KcMYtv/d:NwhB8hmDDRMIfiA7KbYtv/d,"CasuS 1.5.php" 384:rIwHyY1gNv8yiVnggmS2TgFnGjmufsnoC0WgS+i3UgMGMqm7iF:rnHyegJHmggZ28Fc8oGBM7iF,"CrystalShell v.1.php" 384:FTOCnQnAJsznh9m2mwLTEtltCj2gQgrmUfycqfQNUvhdWQhv05Sh4Z6upKmM:HJwmUmiYXmM,"Cyber Shell (v 1.0).php" 384:GIr8nsnAJ0pncTyZhCmmg7ylEJKiIhyZzVxUdnA6abSczJMc84ZCrczRcmNbQ60x:EJ3yZhCE7y0bZP00Mj6G,"Cyber Shell.php" Compile ModSecurity

During the configure step in building ModSecurity, it will try to identify the proper ssdeep source files installed on your system.

$ ./configure
checking for a BSD-compatible install... /opt/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes --CUT-- checking for libpcre config script... /usr/local/bin/pcre-config
configure: using pcre v8.32
checking for libapr config script... /usr/local/apr/bin/apr-1-config
configure: using apr v1.5.1
checking for libapu config script... /usr/local/apr/bin/apu-1-config
configure: using apu v1.5.4
checking for libxml2 config script... /usr/local/bin/xml2-config
checking if libxml2 is at least v2.6.29... yes, 2.7.8
configure: using libxml2 v2.7.8
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for liblua config script... no
checking for lua install... /usr/local/lib /usr/local/include
configure: using lua v5.1
checking for libcurl config script... /usr/bin/curl-config
checking if libcurl is at least v... yes, 7.24.0
checking if libcurl is linked with gnutls... no
configure: using curl v7.24.0
checking for libyajl config script... /usr/local/bin/pkg-config
configure: using yajl v2.0.5
checking for ssdeep path... -lfuzzy -DWITH_SSDEEP -I/usr/local/
checking for library containing fuzzy_hash_buf... -lfuzzy
checking that generated files are newer than configure... done
configure: creating ./config.status

 After completing the compilation and install steps.  We can now configure the rules.

Adding Fuzzy Hashing Rules

Here is an example rule that can be added to a custom rules file:

SecRule FILES_TMP_CONTENT "@fuzzyHash webshells-ssdeep.txt 90" \ "id:87,phase:request,t:none,block,msg:'Malicious File Attachment Hash Match.'"

Looking at this rule, we see the following:

  • We are inspecting a new variable that we added to ModSecurity v2.9.0-RC1 called FILES_TMP_CONTENT.  This variable will hold the data captured from multipart-form-data file attachment uploads.
  • We are using the @fuzzyHash operator which takes two parameters:
    • First parameter is the path to the ssdeep hash text file we created earlier.  In this example, the file is located in the same directory as this rules config file.
    • Second parameter is the minimum threshold score of similarity between files.  This means that our operator will only match if the file inspect matches at least 90% to a file in our ssdeep fuzzy hash file.
Testing Fuzzy Hash Rule

With these configurations in place, let's run a quick test and simply upload one of the existing webshells we have called "ironshell.php".

$ curl -k -X POST -F "action=upload" -F "file=@./ironshell.php" http://localhost/

 We can then look at the ModSecurity audit log file:


As you can see from the highlighted ModSecurity message data, our fuzzy hashing rule matched with an ssdeep match score of 100.  That makes sense as we have not modified the ironshell.php file at all.  Let's make a few changes:

We can then upload this new webshell:

$ curl -k -X POST -F "action=upload" -F "file=@./ironshell-new.php" http://localhost/

Here is the new alert from the Apache error_log file:

As you can see, the file was still flagged however the match percentage went down to 97%.  Still, this means that we can catch modifications to this ironshell webshell code family!  This makes it much more powerful vs. other exact match hashing checks.

Conclusion

This is a new detection capability recently released in the v2.9.0RC1 release and we need help from the community for testing.  We will soon be adding this functionality to our Trustwave SpiderLabs commercial ModSecurity rules package.  

One note for usage and detection, ssdeep has a default minimum file size of 4096.  This means that really small files will not work correctly with @fuzzyHash.  If you want to test out reducing the minimum size threshold, you can edit the main.c file here:

// We print a warning for files smaller than this size
#define SSDEEP_MIN_FILE_SIZE 4096

Please let us know if you have any issues using this new feature. 

Categories: web server

Setting HoneyTraps with ModSecurity: Adding Fake Cookies

Fri, 2014-10-31 08:59
This blog post continues with the topic of setting "HoneyTraps" within your web applications to catch attackers.  Please review the previous posts for more examples: This blog post will discuss Recipe 3-5: Adding Fake Cookies from my book "Web Application Defender's Cookbook: Battling Hackers and Protecting Users".  These HoneyTrap protections are also included as part of the commercial Trustwave SpiderLabs ModSecurity Rules package.   Recipe 3-5: Adding Fake Cookies

This recipe will show you how to add fake cookies and to alert if the data is ever manipulated.

Ingredients

Cookie Usage

The HTTP protocol has no built in session-awareness.  This means that each transaction is independent from each other.  The application, therefore, needs a method to track who a person is and what actions they have previously taken (for instance in a multi-step process).  Cookies were created precisely for this purpose.  The application issues Set-Cookie response header data to the client web browser.  This cookie data instructs the browser to send back data to the web application on subsequent requests.  For instance, upon an initial request to the Ebay main page you will receive the following response headers:

As you can see, there are six Set-Cookie response headers.  When you make follow-up requests, these headers will now be included within the request headers:

Cookie Manipulation Attacks

Much in the same way that attackers take aim at parameter payloads, they also attempt to alter cookie data that is handed out by the application.  Both parameter and cookie data is evaluated by the application upon each request.  Cookie data may even be an even more attractive target for attackers as this information often controls authorization restrictions.  If an attacker can alter cookie data, they may be able to become a completely new user, be presented with new user interface options or even gain higher privileges within the application.  Due to this modus operandi of attackers, we want to set a honeytrap embedded within the normal application cookies in hopes that we will catch when attackers start to manipulate them.

Adding Fake Cookie Data with ModSecurity

Much in the same way that we added in fake hidden field honeytrap data in Recipe 3-4, we want to do the same with fake cookie data.  There are two implementation considerations:

  1. When to issue the fake Set-Cookie data – we want our cookie honeytrap data to look innocuous so we only want to add it in when the application itself is legitimately issuing Set-Cookie response headers.
  2. What to name the fake Set-Cookie data – since we want our honeytrap data to blend in and look like it belongs, we should try to name our cookie something similar to existing cookie names.

The following ModSecurity/Apache directives addresses these two considerations:

These rules will capture the name of the last Set-Cookie header and then append the “-user_role” text to it.  This is to try and trick the attacker into thinking that this cookie is controlling the user’s role within the application.  For the cookie payload, we put the enticing “Admin:0” data which would lead the attacker into thinking that by changing the 0 into a 1 might enable administrative privileges within the application.  With these rules in place, the new response header data looks like this:

Notice the bolded Set-Cookie response header line holds our new honeytrap cookie data.  Next, on subsequent requests, the client's browser will send back our fake cooke data along with all of the normal cookies: 

Detecting Cookie Manipulations

We next need to add a rule that will catch if the client ever changes this cookie data. 

This ruleset will check to see if the honeytrap cookie name is present and then will alert if the “Admin:0” value is ever altered.  It will also set the malicious_client variable in the IP Collection to let us know that this client is up to no good.

Example Attack

In this example, the attacker has decided to change the honetrap cookie value from a 0 to a 1 in the hopes that this might change their level of access:

This request would then trigger the following ModSecurity event in the normal error log:

Conclusion

HoneyTraps are an extremely valuable defensive technique to use when defending your web applications.  They offer a very high signal-to-noise ratio and allow defenders to quickly zero in on real attackers and take appropriate actions.  Setting fake cookie data is a great way to identify malicious clients.

Categories: web server

[Honeypot Alert] New Bot Malware (BoSSaBoTv2) Attacking Web Servers Discovered

Mon, 2014-09-15 09:00

Our web honeypots picked up some interesting attack traffic.  The initial web application attack vector (PHP-CGI vulnerability) is not new, the malware payload is.  We wanted to get this information out to the community quickly due to the following combined threat elements -

  • Active exploit attempts to upload/install the malware
  • The overall low detection rates among AV vendors
  • The malware is actively being sold in underground forums 

Update - Another security researcher has also seen similar activity in his ModSecurity honeypots back on August 26.  Some of the tactics have changed but the core of the attack seems the same.

We have already discussed the initial PHP-CGI vuln attack/exploit vector in a previous blog post.  What is interesting in these attacks are the actual tools installed if the attack is successful.  Here is the initial screen shot of the attack payloads taken from the ModSecurity audit log file on the honeypot:

We cross referenced this attack with our own IDS alerts from Trustwave MSS team and have seen a definite increase in scanning activity for the inital web application attack vector (PHP-CGI) within the last month:

Keep in mind that exploit vectors and payloads are separate ecosystems.  They are often interchanged with each other.  For example, we often see new PHP command injection vectors used within botnet code that execute or install the same backend malware code.  The initial URL encoded data in the QUERY_STRING decodes to:

The final "auto_prepend_file=php://input -a" data tells php to take the info from the POST payload and append it to any existing code and execute it.  If we look at the complete PHP code in the request body, we see that there are actually 2 different variables that contain base64 encoded data.  

This data is then later decoded and places into temp files and then executed.

What are these files?  If we base64 decode the variable data, we can see that they are in fact ELF binaries that are packed with UPX -

Here is some quick static analysis -

The files are essentially the same, however one is 32-bit and one is 64-bit.  The attacker isn't even bothering with checking the web server OS version... they are just trying to execute both to see which one might work.  Checking this file over on VirusTotal shows that only 4 AV vendor currently detects this file as malicious:


 Note - We have internally verified that Trustwave AV does detect this file as malicious.

 The file contains many clear text URLs that have been associated with Botnet C&C activity:

  • srv5050.co

  • ka3ek.com

  • ircqfrum.com

  • 8rb.su 

Once we see the IRC botnet code, we get a clearer idea of what we are dealing with here:

There are many IRC commands here.  IRC botnet code installs are nothing earth-shatteringly new however most of the variants we capture are written in Perl, PHP, etc...  This one is binary C code.  One interesting tactical note - the destination IRC port on these C&C servers is 53.  This is a smart move from the attacker's perspective as DMZ network firewalls may allow web servers to initiate outbound DNS queries.   

Additionally, we see the highlighted section of code which seems to identify this code as: BoSSaBoTv2.  After some searching, we were able to find that this code is actively being sold on underground forums.  Here are some example screenshots:

Notice some of these features including bundling a Bitcoin Miner program.  This is interesting as this shows another aspect how an attacker is looking to abuse their access to a compromised web server.  They can siphon off local system resources such as CPU and RAM in attempts to create Bitcoins.  Here are some of the commands for downloading and running the Bitcoin miner -

 

We also see on the hacker forum that this malware is for sale at affordable prices:

 

Conclusion

We wanted to get this information out to the community quickly due to the following combined threat elements -

  • Active exploit attempts to upload/install the malware
  • The overall low detection rates among AV vendors
  • The malware is actively being sold in underground forums 

Here are a few defensive steps:

Update Network Firewall Egress Rules

All too often, we see weak or non-existent egress firewall rules.  As an example of why you need them - during our research, we saw the IRC botnet master send down commands to have the malware update itself by downloading a new version -

If you can block outbound connections from your web servers to 3rd party hosts, you can significantly help to reduce an attacker's ability to expand their breach.

Deploy a WAF

Our honeypots picked this up due to alerts from our ModSecurity WAF rules.  The Trustwave WAF also detects these attacks.  Not only will this give you some base protections, but it also provides better logging vs. standard web server log files.  Speaking of web server log files....

Check Your Logs

Review your web server log files to see if you have been receiving these initial PHP-CCI attacks.

Pay close attention to the HTTP Response Status Codes. Anything other than a 404 - Not Found could indicate trouble. 

Categories: web server

[Honeypot Alert] Active Probes for WordPress revslider_show_image Plugin Local File Inclusion Flaw

Wed, 2014-09-03 16:22

A local file inclusion vulnerability in the WordPress Slider Revolution Plugin has been released:

Apparently this vulnerability has been discussed on some underground forums for a couple months but it wasn't until these more main stream websites published data that we saw attackers start scanning for vulnerable sites.  Our web honeypots picked up increased scanning activity today.  Here is an example full audit log dump of the HTTP request from our ModSecurity WAF:

In this attack example, the attacker is trying to access the WordPress config file in the hopes of obtaining sensitive data such as database credentials.

Recommendations Update your WordPress Slider Revolution Plugin

Sucuri Security is seeing similar activity and it also reporting that the developer of this Plugin chose to silently patch this vulnerability.  This did a disservice to the Plugin userbase to be aware of the problem and to prompt updating.  A couple notes:

  • Updating this plugin may need to be done manually if your WP manager does not provide an interface for it.
  • Beware that "disabling' the Plugin may end up being superceded by the Theme and be re-enabled.  You may need to remove it altogether if you can not update it. 
Use WAF Protections

WAFs can be used to help prevent exploitation until you can get your systems updated.  Trustwave's WebDefend WAF would block this attack either through a generic "Directory Traversal Attack" signature or through an anomaly of the learned resource profile.  For ModSecurity WAF, we have added a new signature to our commercial rules feed:

Categories: web server