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:
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.Acknowledgments
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
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…).
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:
Exploit-DB has a vulnerability entry with Proof of Concept Python exploit code:
Here is an example exploit attempt that was captured by ModSecurity WAF:--f29bb312-A--
[24/Dec/2014:20:05:21 --0600] VJtw4cCo8AoAADHxgygAAAAF 18.104.22.168 50576 XXX.XXX.XXX.XXX 80
POST /wp-content/plugins/wp-symposium/server/php/index.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------259392320121592
Content-Length: 92562 --f29bb312-I--
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:
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)