Weekly Exploit Report - A few interesting ones to be aware of

Stephen Coty is at BlackHat this week, I am sure when he is back he will have some interesting finding to report so look out for his posts next week.

Now onto the Weekly Exploit Report.

This weekly report discusses some of the more interesting vulnerabilities found and provides information you can use to patch your impacted systems 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.

A patch was written last year for a credential hijacking vulnerability in Subversion. While the patch was released a while ago, still popular backdated branches (1.7.x/1.8.x) do not contain this security fix and are still vulnerable. These versions are still released with most major linux flavors as the 1.9 branch is currently not stable.

The vulnerability itself is a MD5 match on a realm name used for source validation. It can only be exploited by getting a client/victim to visit a Subversion repository you own. The most likely attack scenario in this case being a man in the middle attack or geting a developer to check out some new code. For more information on the vulnerability itself, please read the Technical Details section.

Currently there is no backdated patch accepted by either Subversion or linux flavors. In order to patch the issue, you can either manually apply the patches provided in the first link or manually upgrade all Subversion clients to the newest 1.9 Alpha versions. You could also alias SVN to never use cached credentials with –no-auth-cache and deleting all files in ~/.subversion/auth/ that are storing current cached credentials.

Technical Details:

The vulnerability exists in libsvn_subr/config_auth.c in function svn_config_read_auth_data():

71 svn_error_t *

72 svn_config_read_auth_data(apr_hash_t **hash,

73 const char *cred_kind,

74 const char *realmstring,

75 const char *config_dir,

76 apr_pool_t *pool)

77 {

This function takes cred_kind and realmstring and use them to locate cached credentials to be used. These cached credentials are stored, generically, in ~/.subversion/auth/*. The initial search for the proper credentials is done by creating an MD5 hash of the realm string. This can be seen in svn_auth__file_path:

With MD5 collisions being computationally easy to perform and, looking at how the Flame malware took advantage of certification signing timing, does not take long to create and MD5 collision. An attacker would first simply need to know the REALM string they want to collide with, get the victim to connect to their repo (code to checkout or MiTM being easiest), and then serve up a REALM that collides with the target realm. Subversion will happily grab the cached credentials hashed with MD5 and added realm string (original) and send them over to you for validation. The cred_kind structure is:

const char *cred_kinds[] =

168 {

169 SVN_AUTH_CRED_SIMPLE,

170 SVN_AUTH_CRED_USERNAME,

171 SVN_AUTH_CRED_SSL_CLIENT_CERT,

172 SVN_AUTH_CRED_SSL_CLIENT_CERT_PW,

173 SVN_AUTH_CRED_SSL_SERVER_TRUST,

174 NULL

175 };

This validation hash can then be forwarded on to the real REALM to take control of the users account.

iPython notebook software is a web-based IDE that allows easy integration of formulas, graphs, code execution (and output), and etc. in an easy to use format that can be exported to file formats such as PDF. The notebooks are mostly used in educational circles that need to provide an easily digestible format for readers. More information of target scope can be found at: https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks

A vulnerability was recently discovered where the MathJax library could be accessed over an unencrypted session to an external CDN. This library can then be hijacked and replaced/modified by an attacker on the fly. This does require the attacker to be able to manipulate traffic which generally is a man in the middle attack. While the attack doesn’t seem like a huge issue, iPython notebooks have access via Javascript to run commands on the host itself. A simple PoC was given:

IPython.notebook.kernel.execute(“!xclock”)

The ‘kernel’ context here means the iPython notebook kernel and not ring 0 access. However, the attacker does have remote code execution.

The first proposed patch is to bring MathJax library internal so it doesn’t need to access an external resource over a CDN. The second patch idea is to enforce HTTPS when attempting to load the library. However, the first patch won’t fly due to the 40+MB file size and the second patch idea won’t work if the library can be loaded over HTTP at all. The external resource would have to enforce proper HTTPS. Another issue is that iPython notebook is often ran from localhost. In this case, most people do not use valid certificates and just use self-signed certs for cost and ease. If a self-signed certificate is used then remote code execution still exists.

If you are using iPython notebook software, it would be best to block access to the MathJax library locally so it never makes the request. One could also remove the portion of code responsible for bringing in the library. However, both of these options might disable required functionality. Instead, the best bet is to use a HTTPS enforcement plugin like HTTPS-everywhere for Firefox and create a rule to disallow HTTP access. A tutorial on doing this can be found at: https://www.eff.org/https-everywhere/rulesets

One could also setup HSTS (https strict transport security) rules with HTTP headers to also not allow non-https data to be loaded in the origin. Whatever option you go with, the weakest link of not using self-signed certs must be taken care of. This can be cheaply removed by adding yourself as a CA, signing your own certs, and adding the CA to the browser that you use iPython notebook with. A guide on doing this with OpenSSL can be found at: http://www.area536.com/projects/be-your-own-certificate-authority-with-openssl/