Checking for user-agent header SQL injection vulns

As I analyze various web applications in the name of fun or fortune, I am sometimes treated to those little reminders that result in a "doh!".
Such was the case when I was assessing the latest release of the Avactis Shopping Cart.
I'd just installed the latest free version (1.9.1). Typically, after finding a flaw in an vendor's offering, I sign up for their new release notices, and had recently received one from Avactis.
When last I'd visited said shopping cart I'd spotted a couple of XSS bugs in the checkout.php script for version 1.8.1 and earlier. I admit that at the time I did not do as robust review of the application as I might now; in all likelihood the following bug was present when the XSS bugs were disclosed in September 2008.

With a fresh version installed thanks to the reminder, I fired up Firefox with Tamper Data, and started poking around. With Tamper Data, as we've discussed before, any web form input parameters/variables are subject to your manipulation.
I habitually work from the right side of the Tamper Data UI wherein POST parameters reveal themselves.
There I sat, happily walking through the app, when the bell went off.
"Hey, Russ, don't forget to fuzz the header values too!"
Cross-site scripting and SQL injection specific to cookie values is certainly not unheard of but you may need to refer to a checklist to always remember to probe them for vulnerabilities.
In my case, this was even more true of the user-agent string value.
Not all apps are written to capture the user-agent data, but you can easily understand why shopping cart providers would make use of such information.
What's the point? Remember to investigate the user-agent header for issues too.
It can be a simple as appending a single tic on the end of the user-agent string and submitting it, as seen in Figure 1.


Figure 1

The results were immediate and revealing. In case you wondered what my typical user-agent entry looks like, Figure 2 will enlighten.



You can see that we've caught the query executed by /var/www/avactis/avactis-system/modules/reports/report-collectors/report_data_visitors_stat_collector.php, specifically SELECT_WEB_ROBOT_ID, and the result.
Which, in turn, clearly justifies the rapid and responsive patch provided by the vendor. I submitted the finding to Secunia on October 10th and the vendor posted the patch on October 12th; Secunia Advisory SA41764 was released as q result on October 14th.
A hearty "Well done!" to the Avactis team for that turnaround.

A quick diff of report_data_visitors_stat_collector.php from version 1.9.1 build 8356 as installed on October 9th and the patched version downloaded today is seen in Figure 3.


Figure 3

The tale is quickly told, and it's a good move by the Avactis dev team.
Begone ye damned addslashes()!
Note that the dev yanked use of the addslashes function on lines 49, 157, 238, and 318; addslashes() is a subject to circumvention, mysql_real_escape_string() is recommended.

See how much we can learn when remembering to be more thorough?

I must say, if I hadn't recently renewed my status as a certified Application Security Specialist, I might have missed this vulnerability altogether.
And I definitely would have missed out on the additional benefits such as photo opportunities with app sec glitterati (taken at the recent BlueHat). ;-)



Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

AppRiver: SaaS security provider sets standard for rapid response

On July 28th I was happily catching up on my RSS feeds before getting ready to head of to Las Vegas for DEFCON when a Dark Reading headline caught my eye.
Tim Wilson's piece, After Years Of Struggle, SaaS Security Market Finally Catches Fire, drew me in for two reasons.
I'm a fan of certain SaaS Security products (SecureWorks), but I also like to pick on SaaS/cloud offerings for not shoring up their security as much as they should.
The second page of Tim's article described AppRiver, the "Messaging Experts" as one of some smaller service providers who have created a dizzying array of offerings to choose from.
That was more than enough impetus to go sniffing about, and sure enough, your basic, run-of-the-mill XSS vulnerabilities popped up almost immediately.

Before...


After...


Not likely an issue a SaaS security provider wants to leave unresolved, and here's where the story brightens up in an extraordinarily refreshing way.
If I tried, in my wildest imagination, I couldn't realize a better disclosure response than what follows as conducted by AppRiver AND SmarterTools.
Simply stunning.

Let me provide the exact time line for you:
1) July 28, 9:49pm: Received automated response from support at appriver.com after disclosing vulnerability via their online form.

2) July 28, 9:55pm: Received a human response from support team lead Nicky F. seeking more information "so we can look into this".
(SIX MINUTES AFTER MY DISCLOSURE)

3) July 28, 10:27pm: Received a phone call from Scott at AppRiver to make sure they clearly understand the issue for proper escalation.
(NOW SHAKING MY HEAD IN AMAZEMENT)

4) July 29, 6:35am: Received an email from Scottie, an AppRiver server engineer, seeking yet more details.

5) July 29, 8:51 & 8:59am: Received a voicemail and email from Scottie to let me know that one of the vulnerabilities I'd discovered was part of 3rd party (SmarterTools) code AppRiver was using to track support requests.
(MORE ON THIS IN A BIT)

6) July 29, 2:08pm: Received email from Steve M., AppRiver software architect, who stated that:
a) "We deployed anti-XSS code today as a fix and are using scanning tools and tests to analyze our other web applications to ensure nothing else has slipped through the cracks. We do employ secure coding practices in our development department and take these matters seriously. We appreciate your help and are going to use this as an opportunity to focus our development teams on the necessity and best practices of secure coding."
b) "Regarding XSS vulnerabilities you detected in the SmarterTrack application (the above mentioned 3rd party tracking app) from SmarterTools, one of our lead Engineers and myself called them this morning explaining the vulnerability and requesting an update to fix the problem. We also relayed to them that a security professional had discovered the vulnerability and would be contacting them to discuss it further."
(I AM NOW SPEECHLESS WATCHING APPRIVER HANDLE THIS DISCLOSURE)

NOTE: Less than 24 hours after my initial report, the vulnerabilities that AppRiver had direct ownership of were repaired.

7) July 29, 4:17pm: Received an email from Andrew W at SmarterTools (3rd party tracking app vendor) who stated "thank you for pointing this out to us... we will be releasing a build within the next week to resolve these issues."
(CLEARLY STATED INTENTIONS)

8) August 4, 8:02am: Received another email from Andrew W at SmarterTools who stated "we plan to release our next build tomrrow morning. (Wednesday GMT + 7) I will let you know as soon as it becomes available for download on our site."
(CLARIFYING EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

9) August 5, 9:37am: Received another email from Andrew W at SmarterTools stating that "a new version of SmarterTrack is now available via our website. (v 4.0.3504) This version includes a fix to the security issues you reported."
(DID EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

10) The resulting SmarterTools SmarterTrack vulnerability advisory was released yesterday on my Research pages: HIO-2009-0728

I must reiterate.
This is quite simply the new bar for response to vulnerability disclosures.
It is further amazing that such a process was followed by not one, but two vendors.
I am not a customer of either of these vendors but can clearly state this: if I required services offered by AppRiver and SmarterTools, I would sign up without hesitation.

AppRiver and SmarterTools, yours is the standard to be met by others. Should other vendors utilize even a modicum of your response and engagement process, the Internet at large would be a safer place.
Well done to you both.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

WebCollab - Billy Goat security goodness

A quick shout-out to the WebCollab team for a transparent and quick turnaround on security fixes for vulnerabilities I reported through Secunia.
They were prompt, communicative, and thorough in their review, claiming that "this is the first publicly notified issue with WebCollab in more than six years of releases."
I truly appreciate teams who openly address their methodology, the change log, and the core issues.
Well done and thank you, WebCollab. Yours is a model I wish others would adopt.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

#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