First, major kudos and thanks to Almas Malik, @AlmasMalik07, aka Code Smasher, who was kind enough to report to me the fact that my Joomla instance was vulnerable to CVE-2013-5576. His proof of concept was dropped to my /images directory as seen just below. :-)
That said, for all intents and purposes, I haz been pwned. :-(
Diving into the issue a bit:
Joomla versions prior to 2.5.14 and 3.1.5 are prone to a vulnerability that allows arbitrary file uploads. The issue occurs, of course, because the application fails to adequately sanitize user-supplied input. As it turns out in my case, an attacker may leverage this issue to upload arbitrary files to the affected system, possibly resulting in arbitrary code execution within the context of the vulnerable application.
The fact that holisticinfosec.org fell victim to this is frustrating as I had applied the 2.5.14 update almost immediately after it was released, and yet, quite obviously, it had not been successful applied. Be that a PEBKAC issue or something specific to the manner in which the patch was applied (I used the Joomla administrative portal update feature), I did not validate the results by testing the vulnerability before and after updating. The Metasploit module for this vuln works quite nicely, yet I didn't use it on myself. Doh! As a result , as no fewer than three (two hostile, one responsible (Almas)) different entities did so for me after the vulnerability became well known and easily exploitable. As a result of my own lack of manual validation ex post facto, I know have the pleasure of Zone-H, Hack-DB, and VirusTotal entries.
On 20 and 21 AUG 2013, rain.txt was dropped courtesy of RainsevenDotMy and z.txt thanks to the Indonesian Cyber Army. Why the sudden interest from Malaysian and Indonesian hacktivists, other than my leaving such low hanging fruit out there for the taking, I cannot say.
The only bonus for me was the fact that my allowed file and MIME-type upload settings prevented anything but image or text files to be uploaded. As a result, no PHP backdoor shells; I'm thankful for that upside.
The reality is that you should upload files via FTP/SFTP and disable use of the Joomla uploader if at all possible. Definitely check your permissions settings and lock them down as much as you possibly can. Clearly I suck at administering Joomla or we wouldn't be having this conversation. While tools such as Joomla are wonderful for ease of use and convenience, as always, your personal Interwebs are only as strong as your weakest link. Patch fast, patch often: Joomla does an excellent job of timely and transparent security updates.
Following is an example log entry specific to the attack:
184.108.40.206 - - [20/Aug/2013:23:46:44 -0600] "POST /index.php?option=com_media&task=file.upload&tmpl=component&13be59a364339033944efaed9643ff7b=m4okdrsoa26agbebn1g0kmsh72&9f6534d02839c15e08087ddebdc0f835=1&asset=com_content&author=&view=images&folder= HTTP/1.1" 303 901 "http://holisticinfosec.org/index.php?option=com_media&view=images&tmpl=component&fieldid=&e_name=jform_articletext&asset=com_content&author=&folder=" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36"
Recommendations for Joomla users:
1) Update to 2.5.14 and 3.1.5, and confirm that the update was applied correctly.
2) Review your logs from 1 AUG 2013 to date. Use file.upload as a keyword in POST requests.
3) Check your images directory for the presence of TXT or PHP files that clearly shouldn't be there.
4) Take advantage of security services such as antimalware and change monitoring.
5) Monitor search engines for entries specific to your domains at sites such as Zone-H, Hack-DB, and VirusTotal.
6) To the tune of the William Tell Overture: read your logs, read your logs, read your logs, logs, logs.
While I'm bummed that I'm reminding myself of the very lessons I've reminded others of for years, I'm glad to share findings in the context of responsible disclosure and to reiterate the lessons learned.
Thanks again to @AlmasMalik07 for the heads up and PoC.