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)