May 8, 2015
Markus Wulftange

CVE-2015-0935: PHP Object Injection in Bomgar Remote Support Portal

This was originally posted on blogger here.

Serialization is often used to convert objects into a string representation for communication or to save them for later use. However, deserialization in PHP has certain side effects, which can be exploited by an attacker who is able to provide the data to be deserialized.

This post will give you an insight on the deserialization of untrusted data vulnerability in the Bomgar Remote Support Portal 14.3.1 (US CERT VU#978652, CVE-2015-0935), which is part of Bomgar’s appliance-based remote support software. It covers details on the weakness of Deserializion of Untrusted Data (CWE-502) in PHP applications in general, as well as specific details on the vulnerability and its exploitation in the Bomgar Remote Support Portal 14.3.1.

Note that this post is not about the various bugs in the implementation of the unserialize function itself (see for example Sec Bug #67492, Sec Bug #68594, Sec Bug #68710, and Sec Bug #68942), but about the exploitation on the application level.

Summary

Description from US CERT VU#978652:

Bomgar Remote Support Portal version 14.3.1 and possibly earlier versions deserialize untrusted data without sufficiently verifying the validity of the resulting data. An unauthenticated attacker can inject arbitrary input to at least one vulnerable PHP file, and authenticated attackers can inject arbitrary input to multiple vulnerable PHP files. When malicious data is deserialized, arbitrary PHP code may be executed in the context of the PHP server process.

Vulnerability Details

The PHP function unserialize allows the creation of arbitrary object constructs of any class with arbitrary attributes of almost arbitrary types without any validation. During the deserialization, the lifetime of an object, and the interaction with the object, several methods, including so-called magic methods, may get called using these arbitrarily definable attributes. An attacker may be able to utilize the functionality provided within these called methods to his benefit. For more information on deserialization in PHP, have a look at Serialization in the PHP Internals Book and Writing Exploits For Exotic Bug Classes: unserialize() by Stephen Coty of Alert Logic.

In Bomgar Remote Support Portal 14.3.1, unserialize is called several times with user provided data, among them there is one which can be called by an unauthenticated user.

Exploitation

The most challenging part of exploiting such a vulnerability is finding appropriate classes with effects beneficial for an attacker. Therefore, it solely depends on the available classes. If there are no classes with beneficial effects available, it is not exploitable.

Fortunately, there is at least one in Bomgar Remote Support Portal 14.3.1!

One way to exploit this vulnerability is by utilizing the Tracer class. It is used to write stack trace information to a log using a Logger instance, which wraps an instance of PEAR’s Log class. By using a Log_file instance as an instance of Log, it is possible to write the arbitrary data <payload> to the arbitrary file <destination>.

A corresponding serialized representation of such an object construct may look like this (\0 represents a NUL byte):

O:6:"Tracer":1:{s:12:"\0Tracer\0_log";O:6:"Logger":1:{s:13:"\0Logger\0_logs";a:1:{s:0:"";O:8:"Log_file":4:{s:9:"_filename";s:13:"<destination>";s:11:"_lineFormat";s:9:"<payload>";s:7:"_append";b:0;s:4:"_eol";s:0:"";}}}}

Writing the data to the specified location is triggered by the log method call in the destructor of the Tracer class.

And this is what happens behind the curtain:

  • unserialize creates an instance of the Tracer class, the Logger class, and the Log_file class with the following structure (only relevant members are shown):
  object(Tracer)#1 (1) {
  ["_log":"Tracer":private]=>
  object(Logger)#2 (1) {
    ["_logs":"Logger":private]=>
    array(1) {
      [""]=>
      object(Log_file)#3 (4) {
        ["_filename"]=>
        string(13) "<destination>"
        ["_lineFormat"]=>
        string(9) "<payload>"
        ["_append"]=>
        bool(false)
        ["_eol"]=>
        string(0) ""
      }
    }
  }
}
  • At the end of the runtime of the request, PHP calls the destructor __destruct of our Tracer object, which eventually calls the log method of the Log_file class with the following behavior:
    • The file specified in _filename gets opened in write mode, if not already opened (line 285-287)
    • The format of the line to be written to the log is specified by _lineFormat, i. e. our (line 293-295)
    • The log line gets written to the specified log file (line 303)

By injecting a Tracer object as specified, arbitrary data can be written or appended to an arbitrary file.

Additional Information on Exploitation

If the document root location of the web server is unknown, one can utilize PHP’s autoload functionality, which allows the inclusion of a '*.php’ file from any location as long as the path can be expressed in a class name with ‘_’ instead of ‘/’.

For example, the deserialization of the following object representation would result in the local file inclusion of ‘/tmp/poc.php’:

O:8:"_tmp_poc":0:{}

The exploitation can then be performed with two serialized objects:

  1. Writing a PHP payload to a known location like ‘/tmp/poc.php’ using the Tracer object structure as mentioned above.
  2. Loading and executing the written PHP payload using an object with the class name like ‘_tmp_poc’ as mentioned above.

Most of the vulnerable unserialize calls are only accessible after successful authentication. However, one is accessible without prior authentication; this requires a particular access token but can also be retrieved without authentication. I leave this as a challenge to the reader. ;-)

Course of events and ‘cooperation’ with Bomgar

The whole process of the disclosure of this vulnerability took longer than expected: The initial report submission of the vulnerability to US CERT was on 2014-11-14. They instantly replied that they wanted me to first contact Bomgar directly. So I wrote an e-mail to info@bomgar.com, asking for a contact person for a confidential disclosure of the vulnerability details. After one week without any reply, I asked US CERT on 2014-11-23 to do the coordination.

Fast-forward: on 2015-02-12 I got an answer from US CERT, stating that they have established a contact at Bomgar. This was already 90 days after the initial report.

Immediately after that, I got contacted by Bomgar, asking me how I intended to use the vulnerability information. My reply was that I wanted to write this very blog post, which should contain details on the vulnerability and its exploitation in Bomgar Remote Support Portal 14.3.1. Since an exploitation of this kind of vulnerability depends on the available classes and their functionality, I wanted to show some source code snippets of the involved classes and methods. However, Bomgar insisted on not having any copyrighted source code published and also asked me to remove any explicit details on how to reach the unserialize function calls, especially the one accessible without authentication.