In this years Advent of PHP Application Vulnerabilities (APAV), we examined 36 critical security issues which were detected in 19 different PHP applications by our code analysis solution RIPS. In our final post, we would like to summarize what we learned during this thrilling advent time. We reveal how the affected vendors reacted to our reportings behind the scenes. Was it right to publish all these sensitive issues? What conclusions can we draw about the security state of PHP applications from our findings?

Vulnerability Types

We presented a multitude of critical security issues found in widely-used open-source software. All issues were detected by our innovative static code analysis tool RIPS and were presumably missed by other tools throughout the past years. In our calendar posts, we focused on interesting rather than easy to exploit samples and straight-forward issues in order to demonstrate the vast possibilities that attackers have for exploiting a web application.

The first diagram depicts the distribution of all issue types described in our blog posts over the past advent days. We scanned in total ~3.8 million lines of code which comes down to an average of 224,000 lines of code per project. RIPS was able to scan each project with less than 2 minutes of analysis time. The following diagram shows the overall distribution of detected security vulnerabilities. The top most detected issues were cross-Site Scripting (~40%) and SQL injection (~20%), followed by file related security issues.

Vulnerability Origins

A technical analysis of the detected issues revealed that the subtlenesses and characteristics of the PHP language play a major role in the root cause of security vulnerabilities. With its strong dedication to the PHP language and its variety of features, RIPS was able to spot these weaknesses in thousands of code lines within seconds.

A common weak point of developers seems to be the usage of arrays. We saw several issues related to unsanitized array keys or faulty loops involving arrays. Likely, some developers are unaware of the fact that also array keys can contain malicious payloads. Further, arrays cannot be easily concatenated into markup and thus need additional parsing which can introduce security bugs. For SAST tools, the data flow analysis through arrays is challenging but highly important for a precise analysis. In the end, most of the user input is received through the superglobals $_GET and $_POST which are arrays as well.

The second conspicuousness in vulnerable code was the misplacement of security mechanisms. When input sanitization was not completely forgotten, it was sometimes not sanitizing all relevant data. Other applied security mechanisms did not match to the markup type or not to the specific markup context. Even when a suitable security mechanism was chosen, it could be bypassed or completely removed in some cases. RIPS was only able to validate the utilization of these mechanisms correctly due to its context-sensitive analysis. With the help of this technique, the markup context can be fully reconstructed and parsed, such that the right decision can be made about the validity of applied security mechanisms.

Furthermore, we demonstrated repeatedly that vulnerabilities with a lower severity should not be disregarded in any way. In almost all cases, it was possible to construct a chain of several security issues that ultimately lead to the most critical vulnerability type: remote code execution. The attacker’s options for a combination seem to be endless. We presented escalations via cross-site scripting, cross-site request forgery, file uploads, PDF files, image files, plugins, and even emails.

Why Publishing Vulnerabilities is Important

We strongly believe that the release of relevant details of a critical vulnerability is crucial - under certain circumstances. First and foremost, the vendor must be informed and a patch has to be available. This is the only way to protect the affected software’s users. As soon as a fix with a security label is released, bad guys start having a look at the patched code lines in order to examine the vulnerability. From there, the vulnerability is very easily spotted and building an automated exploit is only a matter of writing a few lines of code. For our blog posts, we decided not to release any exploit code that could be abused in a copy and paste manner. An example of the changed code lines for our reported command execution vulnerability in Roundcube is given below. The affected file, line number, and the vulnerability type is instantly visible.

program/lib/Roundcube/rcube.php

16921693

-   $sent = mail($to, $subject, $msg_body, $header_str, "-f$from");
+   $sent = mail($to, $subject, $msg_body, $header_str, '-f ' . escapeshellarg($from));

In this specific case, we detected a vulnerability that was overlooked since 3.5 years. A 0day exploit might have been available for a long time and many Roundcube servers may have been already compromised. By announcing a critical vulnerability and spreading word about its severity, users hopefully become aware and patch their installations. Thus, we believe that our information is not of help to attackers but rather to the unaware users.

Furthermore, the documentation of an issue helps the community to understand what went wrong and how to avoid the issue type in the future.

I was reading https://blog.ripstech.com/2016/roundcube-command-execution-via-email/. We don't do escaping of the fifth argument to mail() either. Our sanitation functions should prevent any evil mail addresses (Possibly someone could make something evil using the ! character, but its not clear if that is possible), but we should also just escape that similar to any other shell command.

For example, MediaWiki which powers the likes of wikipedia.org and many other, found exactly the same issue in their codebase after our release. Learning from previous mistakes - even if they are from different developers and projects - is very important to be able to grasp the security issues that can arise in web applications. Also the popular Zend Framework released a security advisory two weeks later about a similar issue in the zend-mail component.

Vendor Reactions

Nobody is happy about getting called out on his mistakes. Surprisingly, almost all vendors reacted very quickly and professionally upon our request and were able to produce a fix only a few days after the initial contact. This is very impressive and was not expected when preparing for this calendar. Unfortunately, this has to be taken with a grain of salt. Although the response time was quick, some vendors treated the reported security issues with a low priority and postponed the release of a fixed version. This potentially puts the software’s users and their data at a greater risk, especially when a fix is available but not released immediately. We have shown time and time again during the APAV that even trivial security vulnerabilities can escalate pretty quickly. Nevertheless, we would like to thank all affected vendors once again for their great effort and collaboration.

The State of PHP Application Security

Undoubtedly, attacks against PHP applications are happening every day. In this year’s brief advent period, we observed multiple attacks against our honeypot and witnessed a website defacement. The attack surface of PHP applications is pervasive. Our automated analysis of dozens of PHP applications showed that the security level of many popular open-source projects is unsatisfactory. While the top 5 PHP projects receive security reviews from larger communities and motivated researchers, other open-source applications lack proper security audits. Even worse are the proprietary applications of companies whose private source code is built under more time pressure and which were never assessed for security vulnerabilities. Admittedly, spotting all subtle issues in thousands or millions lines of code manually requires strong security expertise and is time intense. Hence, we added a couple of posts to our advent calendar that demonstrate how a precise SAST tool can help in warning about security issues automatically during development and in fulfilling compliance requirements for a safer development.

We wish all our readers a pleasant, relaxed, and safe holiday season!