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 11 hours ago

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

Thu, 2015-01-29 21:41

A heap-based buffer overflow vulnerability in glibc (CVE-2015-0235) was announced this week.

It seems as though all new vulnerabilities need to have catchy marketing names so this one was dubbed "GHOST" which was derived from the vulnerable glibc function name - "GetHOSTbyname()".

Vulnerability Notes

Here are the key points thus far: 

  • The vulnerability affects all versions of glibc from glibc-2.17 and lower
  • The bug was patched in glibc-2.18 in May 2013, but was not marked as a security bug so the fix did not make it into many common Linux distributions like SUSE and Ubuntu until much later.
  • To our knowledge, this is not currently being exploited in the wild
  • Qualys has not released any PoC code but they plan to release a Metasploit module in the near future. 
  • Qualys was able to remotely exploit a mail server running Exim mail software but it’s unclear what other software might be vulnerable. (They are working on a metapsloit module specifically for the Exim exploit)

Regarding other Linux server software Qualys wrote:

"to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,

nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,

pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,

vsftpd, xinetd."

Wordpress XML-RPC Pingback Vector 

It has been speculated that the XML-RPC pingback functionality in Wordpress installs may be vulnerable to remote exploitation.  We decided to run some tests to see if it is in fact vulnerable.  We previously did a blog post outlining how the Wordpress XML-RPC "pingback" functionality could be abused by attackers to force unsuspecting websites into participating in DDoS attacks.  To summarize, in that attack, the attacker sends an XML request to the "/xmlrpc.php" script:

The YELLOW highlighted data is a WordPress "Patsy Proxy" site while the ORANGE highlighted data is the DDoS target/victim website.  In this scenario, the XML-RPC "pingback" code in PHP is using the gethostbyname() function call on the ORANGE highlighted data so that it can resolve it to an IP address for the remote request it will send.  This is the exploit vector we chose to focus on for GHOST testing.  

Modifying Input for GHOST Vulnerability Testing

Instead of sending a normal sized URL in the XML pingback.ping method body, we need to send a large one.  Here is a Ruby PoC script


The script takes command line arguments for the size of payload that you want to send.  During our testing in SpiderLabs Research, we identified different size ranges that worked on different platform/versions of glibc, php and wordpress.  After sending the attack payload, we have seen the HTTP process responds with the following:

  • 500 HTTP Response Status code with php-cgi
  • No HTTP Response with mod_php

There are errors in the Apache error_log file when the process crashes:

This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability.  Here is the glibc and php version information for the two systems we used during this test:

Recommendations Install glibc Patches

Example for Ubuntu Linux Distributions:

sudo apt-get clean sudo apt-get update sudo apt-get upgrade

And don't forget to reboot! 

Disable XML-RPC

It is possible to disable the XML-RPC process altogether if you do not want to use it.  There are even plugins that will disable it.

Disable Pingback Requests

You may also disable the pingback feature by adding the following to your functions.php file:

WAF Protections

By using a WAF, you can identify initial pingback XML requests on your Wordpress site and look for attacks.  The Trustwave WAF has a profiling and learning engine called "Adaption" that is able to identify these types of anomalies vs. normal user traffic.  We have also added rules to our commercial SpiderLabs ModSecurity rules package to identify this specific PoC attack vector.

Monitor Your Logs

When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc...) that will indicate a problem.  Organizations should be vigilant in monitoring their logs and following up on an anomalous errors. 


I would like to thank my fellow SpiderLabs Research colleagues who helped with testing and the content of this blog post:

  • Robert Rowley
  • Christophe De La Fuente
  • Chaim Sanders
  • Felipe Costa
  • Jonathan Claudius
  • Karl Sigler


Categories: web server

[Honeypot Alert] Wordpress Wp Symposium 14.11 - Unauthenticated Shell Upload Exploit Attempt

Tue, 2014-12-30 12:58

Our web honeypots picked up some exploit attempts for the recently released vulnerability in the WP Symposium Plugin. WP Symposium is described as:

WP Symposium is a plugin for WordPress, that will turn a WordPress site into a Social Network. And you can choose which features you want to activate, and customise them to achieve your social network features.

Uses of WP Symposium are limited only by your imagination, but some examples of how people are already using it include:

  • Social networks for those who live or work together (colleges, clubs, etc…).
  • Internal “intranet”s for a business or company.
  • Dating sites, including those for niche groups of people.
  • A social network supporting products and services.
  • A social network for particular hobbies/interests (music, films, etc…).
Wordpress WP Symposium 14.11 Shell Upload Vulnerability

 WP Symposium allows user to upload different types of files and it has a preconfigured list of allowed extensions:

These restrictions are applied to the /wp-symposium/server/file_upload_form.php page, however there are other pages that are not protected such as:

  • /wp-symposium/server/php/index.php
  • /wp-symposium/server/php/UploadHandler.php
  • /wp-symposium/mobile-files/server/php/index.php
  • /wp-symposium/mobile-files/server/php/UploadHandler.php

Exploit-DB has a vulnerability entry with Proof of Concept Python exploit code:

Honeypot Exploit Attempt

Here is an example exploit attempt that was captured by ModSecurity WAF:

[24/Dec/2014:20:05:21 --0600] VJtw4cCo8AoAADHxgygAAAAF 50576 XXX.XXX.XXX.XXX 80
POST /wp-content/plugins/wp-symposium/server/php/index.php HTTP/1.1
Host: honeypot
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------259392320121592
Content-Length: 92562 --f29bb312-I--
uploader%5fuid=1&uploader%5fdir=%2e%2fsymposium&uploader%5furl=http%3a%2f%2fhoneypot%2fwp%2dcontent%2fplugins%2fwp%2dsymposium%2fserver%2fphp%2f --f29bb312-J--
4,91960,"_privacy.php","<Unknown ContentType>"

The attacker attempted to upload a PHP file called "_privacy.php".  This file has various PHP backdoor code which allows the attacker to send HTTP commands through request variables.  It also contains a version of the WSO webshell:

Action Items Update WP Symposium  

If you can not update, then you need to manually update the UploadHandler.php script.  Update the following line from this -

// Defines which files (based on their names) are accepted for upload:
'accept_file_types' => '/.+$/i',

To this -

// Defines which files (based on their names) are accepted for upload:
'accept_file_types' => '/.(mp4|doc|docx|ppt|pptx|xls|xlsx|txt|pdf|gif|jpe?g|png)$/i', Use a Web Application Firewall (WAF)

Both of Trustwave's WAF products (TW WAF and ModSecurity) can protect your sites from PHP file uploads.

Categories: web server

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.


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

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

Categories: web server