Hard coded encryption keys and more WordPress fun

Metasploit modules [1, 2]

A few days ago I was chatting with pasv about a recent vulnerability he discovered. Apparently there was demand for Razer Synapse which syncs the configuration for a Razer mouse to the “cloud”. Syncing configurations to the cloud was most likely needed since some of Razer models have so many buttons the mouse has its own full blown number pad on the side. Pasv got bored and did what any good bored security professional does and reverse engineered the Razer Synapse installer. He discovered that the encryption key and IV were hard coded for the “Remember my password” feature (PoC).

The vulnerability was recently fixed before the new year (12/27/12), via an auto-update in the Razer Synapse software but we figure there are probably at least a few configuration files still sitting out there. This vulnerability was very similar to a recent metasploit module @zeknox and I released about Spark IM so it was fairly painless to write up a new module to exploit this configuration.

The credentials are stored within the configuration file “RazerLoginData.xml” which is located in the %AppData%\local\Razer\Synapse\Accounts folder of any user using the software. The configuration file is easily parsed and multiple credentials can be stored in each configuration file so there is a chance of getting more than one username/password combination.

Once the module parses out the configuration file(s) the passwords can be decrypted with the hardcoded key and IV as seen below:

The result is a module that quickly looks through each users profile, parses the config file, and spits out the cleartext credentials. The newer version of the Razer Synapse software alters the configuration file slightly so the module will only try to parse the vulnerable credentials.

Module in Action

Logging to the Database

A pull request for the module has been submitted to metasploit and currently pending acceptance into the trunk. The module is also available on github.

And more WordPress

I also had another module added to metasploit last week related to all of the fun we were having with port scanning through a default WordPress 3.5 site. While the previous module has been working great we felt it would be of more use if you could quickly find vulnerable WordPress installations.

The module only needs RHOSTS and an optional target URI to scan a large number of web services to see if any of them are vulnerable. A HEAD request to the web service will return with the X-Pingback header showing the location of the xmlrpc.php file, which is then used to handle incoming requests to the XML-RPC API.

With the X-Pingback header present a vulnerable blog post is needed to exploit the vulnerability. The WordPress feed page contains links to the latest blog posts so the module will attempt to resolve the URI /?feed=rss2. This will return the location of the feed page which can be parsed to gather the URLs of blog posts to test against.

After parsing out the URLs within link tags the module crafts a POST request and sends it to the URL for the xmlrpc.php file identified previously. The data is simple XML seen below telling the site to use the pingback API. The target is a URL to the loopback address, http://127.0.0.1, and the valid_blog_post is a link to one of the blog posts found.

Upon receiving the POST request the WordPress site will attempt to connect to itself and then respond with XML containing a fault code and string. If the code is anything but 16 it means the WordPress site has made a successful connection and the scanned port is open. If the WordPress site can identify its own port as open, then it is vulnerable.