Joomla vulnerabilities & responsible disclosure: when being pwned is a positive

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. :-)

Thank you, Almas, much appreciated and keep up the good work at http://www.hackingsec.in/.
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:
202.152.201.176 - - [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.

DEFCON preview: Netgear RP614 CSRF attack video

To give you a sense of what Mike Bailey and I will be covering at defcon 17 this Saturday at 11am, I thought I'd give you a little taste courtesy of a Netgear RP614v4 router that suffers from cross-site request forgery (CSRF) vulnerabilities, as well as persistent cross-site scripting (XSS) issues.
See OSVDB advisory 54885 for further specifics. BTW, please support OSVDB!

The short version:
The Netgear RP614v4 web-based administration interface allows users to perform certain actions via HTTP requests without performing any validity checks to verify the requests. This can be exploited to perform administrative actions or conduct script insertion attacks e.g. when a logged-in administrator visits a malicious web site.
The sad truth of the matter is this, while I don't have access to the whole Netgear product line, the reuse the same firmware codebase across multiple devices.
Thus, in all likelihood, there are numerous Netgear devices vulnerable to this issue, if not all.
The same holds true with Linksys devices, which we'll cover in detail at DEFCON.

As you will see, the approach is simple, and too often effective.
1) Miscreant crafts email utilizing well proven social engineering methodology.
2) Victim follows orders and, while authenticated to vulnerable device, clicks on that damned link.
3) Vulnerable device does not perform any validity checks to verify the requests made via the attacker's web page lurking behind the link in the email.
4) Vulnerable device fails in whatever fashion it's told to.

As exhibited in the video I've created for your viewing pleasure, I force the admin session to enable remote management (disabled by default) and change the remote management access port to 6667 for old time's sake. If, as it so often is, the admin account is left to default password, game over. Or, in many cases, you can also force a password change via CSRF as well.
Any function the firmware provides can be forced via a victim admin's session; that which is exhibited here is but a single examplar.
Tokens, people...tokens!

The video, as promised:
Lo-fi (5.63 MB MP4)
Med-fi (53.9 MB WMV)
Hi-fi (73.4 MB AVI)

Hope to see you at DEFCON; please say hi if you're there on Saturday.
I'll be easily spotted in jeans and my white Certified Application Security Specialist (ASS) golf shirt.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Congratulations to the Open Security Foundation

I was thrilled when I read that the Open Security Foundation (OSF) was named as SC Magazine's 2009 Editor's Choice Award recipient.
I simply can't think of a more deserving bunch.
Congratulations and well done!
OSF is the parent organization for the OSVDB and the DataLossDB.
Their accolades reminded me that OSF is a a 501(c)3 nonprofit, public foundation and as such, benefits from donations. I've been a Network for Good user for a year or so, and it occurred to me that I'd rather have donations made to OSF via my badge than any other organization.
People occasionally try to pay me for helping them out via Holisticinfosec.org; I tell them I'm paid well enough at my day job and writing gigs, and that they should instead donate to my preferred organization.
OSF is that preferred organization, please donate via my badge or straight through OSVDB, if so motivated. I just did; I'd be honored if you'd do the same.
Again, congratulations OSF!

del.icio.us | digg | Submit to Slashdot

#8 of the Top Vulnerability Discoverers of 2008

When, towards the end of 2008, I noticed the total count of vulnerabilities I'd disclosed and posted climbing past 50, I didn't imagine the effort would merit ending up as 8th on the list of Top Vulnerability Discoverers of 2008, as determined by Gunter Ollmann of the IBM ISS Frequency X Blog.
I am both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.
1) While I appreciate being on this list I must say that the caveat offered as part of Gunter's post is valid: "cross-site scripting vulnerabilities in a commercial shrink-wrapped application count for the same as a remote root vulnerability on a default Windows service."
My work has focused entirely on vulnerable web apps to date, and truly qualifies as low hanging fruit when compared to the findings of the likes of Luigi Auriemma. I am reminded of Wayne and Garth...I'm not worthy. My hat is off to Luigi, as it has been for quite awhile.
2) Gunter has, in the past, stated that he "wants companies to stop acknowledging an alias or pseudonym for any researcher that discloses a vulnerability - even if they came to you directly. “Use real names only,” he adds." Amen. The use of stupid, h@x0r nicknames lacks credibility and flies in the face of what I believe our core mission should be: find, advise, and promote repair of vulnerable software on behalf of users and consumers who may fall victim to its exploit. Disguising this mission in some self-perceived leetness-by-nomenclature denigrates the essence of this work. Courage, my friends...be true to yourselves and the cause.
3) Gunter has further indicated that he wants "software vendors to stop acknowledging companies and researchers who buy and sell security vulnerabilities." I must agree entirely here as well. I'd no sooner sell a vulnerability for profit than I would exploit it for personal gain.
4) Finally, the fact that, with relative easy, I discovered and reported what the Frequency X report indicates is 53 unique web application vulnerabilities in 2008 is really testament to what a sad state of affairs the development process is for so many of these vendors (not all, but many).
My plan for 2009, in addition to continuing this effort in earnest, is the promotion of the use of the Security Development Lifecycle (SDL). I believe that weaving the SDL mindset into software development is essential to preventing the flaws we vulnerability researches enjoy pointing out.
More to come, to be certain.
Cheers, and thank you, Gunter.

del.icio.us | digg | Submit to Slashdot