Exploit Monday – A few Interesting ones to be aware of

Datetime:2016-08-22 23:49:53          Topic: PHP  JSONP  Test Engineer           Share

This weekly report is to discuss some of the more interesting vulnerabilities that have been found and to make sure that you patch appropriately.  If there is not a patch available make sure to check for signatures or patterns that you can use to build content for your compensating security controls. 

1  Adobe Flash Update

https://bugzilla.redhat.com/show_bug.cgi?id=1117588

All versions of Flash on all operating systems will recieve an update from Adobe. This update will fix a vulnerability that can be used to take advantage of your flash player to perform CSRF (cross-site request forgery attacks). If you have not received an update, it would be best to manually grab the update from Adobe and apply it as soon as possible.

Technical Details:

A longer and full explanation from the author is available at  http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ . The problem is mostly due to callback exposures on large websites like Facebook and Google. JSONP allows a user to control a callback variable with a sniffed content-type. This sniffed content-type can be Flash with a simple object tag. Now, the problem was that only alphanumeric data could be passed through this callback. In order to get around this, zlib deflate and adler32 checksum hacking was used to convert any flash file to an alphanumeric stream capable of being injected into the JSONP callback.

With being able to control Flash data on the JSONP callback victim domain, an attacker can setup a flash file and an open crossdomain.xml to allow a full two-way communication with the victim domain. This can allow exfiltration of data back and forth breaking same-origin policy on any affected domains.

2  Patch: PHP unserialize SPLArrayObject/SPLObjectStorage type confusion

https://bugzilla.redhat.com/show_bug.cgi?id=1112154

A bug has recently been opened to the public that deals with user input passed into the unserialize() function. This can cause previously unexploitable unserialize object insertion vulnerabilities to become exploitable (such as WordPress without frameworks like Zend). Not only that possibility, but this allows a local privilege of escalation vulnerability from a vhost to the privilege of the PHP interpreter. Assuming the unserialize() function is not disabled in shared environments, this can lead to compromise of the box itself from a restricted vhost. An update for PHP stable has not yet been released, so in order to patch this vulnerability it would be best to grab the newest snapshot directly from the source at  https://snaps.php.net . Testing branches of Linux distros will also use non-stable versions that may contain this patch. The testing branches were released two days ago and should be fixed in 5.5.3+/5.4.4-14+.

Technical Details:

For starters, I have a blog post on how to write exploits for unserialize vulnerabilities. Before we continue, it would be best to read and understand how you would normally remotely exploit these types of vulnerabilities.

This is available at:

http://turbochaos.blogspot.com/2013/06/exploiting-exotic-bugs-unserialize-post.html

An exploit has been privately released in the PHP bug report for local exploitation, so it is likely available in some circles. However, enough information is available to construct an exploit with enough time. The testing PoC branch addition for regression test shows an example:

‘x:i:1;O:8:”stdClass”:0:{},N;;m:s:40:”1234567890123456789012345678901234567890″‘

The vulnerability deals with object storage and array objects not validating the unserialized form is an array. The patch is:

-       if (!php_var_unserialize(&pmembers, &p, s + buf_len, &var_hash TSRMLS_CC)) {

+       if (!php_var_unserialize(&pmembers, &p, s + buf_len, &var_hash TSRMLS_CC) || Z_TYPE_P(pmembers) != IS_ARRAY) {

So we see the IS_ARRAY validation has been added to the check. With this knowledge the PoC sets a 40 bit string as the array value. This string is actually not random, it attempts to look like a fake hashtable and on destruction of the fake hashtable, an attackers own destructor will run. This allows RIP/EIP and EDI/RDI control (rip for hashtable and rdi for constructor). Now a heap spray could be utilized to land good data in the heap pointer of RDI. More information on abusing this type of vulnerability can be found in one of Esser’s older presentations:

http://www.slideshare.net/i0n1c/syscan-singapore-2010-returning-into-the-phpinterpreter

3  OpenCart Object Insertion Vulnerability

http://karmainsecurity.com/KIS-2014-08

An unauthenticated object insertion (PHP unserialize) vulnerability was found in OpenCart’s handling of attacker controlled POST values. The vulnerability affects versions <= 1.5.6.4 and public exploit code was released. The exploit code released used the vulnerability to conduct SSRF (server-side request forgery) that allowed the attacker to use a vulnerable server as a port scanner. An exploit could be made dangerous if third party plugins implement their own magic function such as __wakeup and/or __destruct that could be used to an attackers advantage. For more information on this type of exploitation, please read my blogpost on the subject:

http://turbochaos.blogspot.com/2013/06/exploiting-exotic-bugs-unserialize-post.html

The exploit is most dangerous when combined with recently released information on abusing the way arrays are handled in the unserialization object handling process. Three days ago I posted about SPL ArrayObject / SPLObjectStorage type confusion flaw that could lead to currently unexploitable (aside from DoS/DDoS that can be performed from any object insertion vulnerability such as this one) vulnerabilities being exploitable for remote code execution. That bug report is at:

https://bugs.php.net/bug.php?id=67492

Therefore PHP versions under 5.5.3 and 5.4.4-14 (current unstable versions) could use this vulnerability for remote code execution. While PoC code is made available for local exploitation, a remote exploit abusing this vulnerability is definitely possible.

It is suggested to patch the issue as soon as possible. The developers do not feel the current threat rating is high enough to alert customers, so it would be best to reach out to users of OpenCart urging them to upgrade if you are in a shared hosting environment. Even if the attacker does not possess a way to abuse the SPLArrayObject bug, the vulnerability still can be used as a denial of service against anyone using OpenCart or as a zombie box for a port scanner.





About List