OK, so a while back (a few weeks ago) I got a malicious word document from a friend of a friend of an enemy. I though it would be kind of fun to dig into it and see what’s in it. I’ve also been wanting to do a post on something related to malware. So, two birds, one stone. Let’s do this.
I present to you, an analysis of the August information stealer (and associated dropper). August is a fairly new information stealer that has recently had a few articles/blog posts written on it. See: https://www.proofpoint.com/uk/threat-insight/post/august-in-december-new-information-stealer-hits-the-scene
This post is more about the process of analyzing the sample, rather than the conclusions drawn from the analysis. I have a copy of the original sample available for people to follow along.
When looking through WordPress plugins, I noticed that a lot of developers seem to have issues using AJAX securely. They frequently don’t use nonces at all, they leak nonces to people they shouldn’t, and they forget to check the user’s capabilities. At first, going after the low hanging fruit (AJAX issues) of the low hanging fruit (WP plugins) was kind of fun, but it started to get boring pretty fast so I wrote a script to do it for me.
When an attacker leaves behind malicious PHP after a successful compromise, they typically make some attempt to obfuscate their code. While the title of this post is “PHP Backdoor Obfuscation Techniques”, these methods are also used to obfuscate other code as well, sometimes even in a poor attempt to protect legitimate code from reverse engineering and modification. I’ve been working in an environment with a large number of LAMP servers for several years now, and I’ve seen a lot of malicious PHP. Here are some of the more common (and a few less common) obfuscation techniques I’ve seen.
Wordfence v5.2.3 suffers from multiple vulnerabilities including 2 stored XSS, insufficient logging of requests, being able to bypass the throttling feature (designed to limit scraping) and being able to bypass the exploit detection feature. All of these appear to be the result of a lack of understanding of PHP superglobals.
And we’re back. Check out Part 1 if you haven’t yet. Much like before, developers of these plugins have not been contacted in advance. These vulnerabilities were trivial to find and as you can see from these vulnerabilities and others that have been disclosed in the past few months, popular =/= secure. More vulnerabilities will be posted as time permits.
This post contains information on vulnerabilities for 7 (at least somewhat) popular wordpress plugins. All of these vulnerabilities were trivial to discover (and are trivial to fix). The state of wordpress plugin security is very sad indeed. None of the developers were contacted in advance of this post (except where otherwise noted). Additional vulnerabilities will be posted as time permits.
There are several cross site request forgery vulnerabilities in the Disqus WordPress Plugin, version 2.77. Let’s start with the technical details, then I’ll get to the commentary.
Three settings in the admin interface lack nonces. By exploiting this you can activate or deactivate the plugin, and import or export comments between your wordpress database and disqus. Example URLs:
These are all just simple GET requests. There is nothing terribly interesting in the plugin’s code related to this. It is just the simple lack of a nonce (for GET requests).
There is a (relatively minor) stored XSS vulnerability in WP Photo Album Plus (WPPA) 5.4.5. WPPA maintains its own error log. When this error log is viewed through the web interface, its output is not sanitized. Regular users that have the ability to upload files to photo galleries can cause arbitrary data to be written to the log file. An easy way to demonstrate this is to upload a zip file containing a file named:
<img src="ff" onerror="alert('xss');">
When you try to import the contents of the zip file, it produces an error containing the malicious file name that is logged. Things aren’t escaped properly on the upload/import pages either, resulting in the js running after the import attempt. The lack of proper sanitization on these pages results in a reflected XSS vulnerability as well, but with double and single quotes escaped with backslashes, so you may need to fiddle with it a bit to get it to do something useful.
http://wptestbox1.dev/wordpress/wp-admin/admin.php?page=wppa_import_photos&zip=<img src="ff" onerror=alert(0);>.zip