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)

WhiteHat's trustmark program as a game changer

I am a trustmark hater, I admit it; this should surprise no one.
I have labored long and hard over this post, but I believe it to be relevant and important.

WhiteHat Security, the genesis of Jeremiah Grossman's vision for web application security, has instituted a trustmark program.

Carefully branded a Security Certification Program, this offering seeks to raise the bar on the trustmark concept, a game changer if you will.
On one hand, this won't be hard to do.
As I have in the past, I could rail against the dime a dozen, pseudo-fraud programs that are nothing but conversion gimmicks designed to drive sales through falsely gained consumer confidence. They can all take their Nessus scanners and bugger off.

Instead, I'd like to describe why I think WhiteHat Security can shed new light and standards on this concept.
1) Reputation: WhiteHat Security has always been a premier brand in the realm of web application security. This is indisputable. Their scanning engine, their business model, their personnel are all geared to the cause; they are expert in this field.
2) Value of the service: I know first hand how much WhiteHat labored over the process of offering a Security Certification Program, i.e. how to do so without falling into the same lameness all the others so readily exhibit. This program is not about conversions first, security second. The certification is only offered to WhiteHat Sentinel customers. While there are no guarantees, if you are Sentinel customer, the statistical likelihood of your exposure to web application security flaws goes down exponentially should you choose to fix the flaws they discover. I know this not due to whitepapers or marketing claims, but from experience.
3) Lack of arrogance or false claims: A trustmark that reads "Website Security by WhiteHat Security" is not claiming to be Hacker Safe, Hacker Proof, or Hacker Free. Clicking the trustmark leads you to the following:
"This site employs WhiteHat Sentinel, WhiteHat Security's industry-leading website security solution. To help address concerns about safeguarding your confidential data from security breaches and hacker attacks, the "Website Security by WhiteHat Security" mark appears only on sites that use the WhiteHat Sentinel Service."
No BS, no hype, no false claims of grandure or impenetrability, just simple facts.
4) Jeremiah Grossman: Jeremiah knows this business better than anyone. As a business man he was driven to consider adding a Security Certification Program by customer demand. Whether we like it or not, customers like trustmarks seals, and benefit from them, no matter how lame a trustmark program may be. Customers using Whitehat Sentinel are paying for the privilege, this is not $250 a year scam with no value other than false confidence. Jeremiah's reputation is inherent to the success of this program. He is well aware of the pitfalls, and I know he has the integrity to ensure its value as a real security-first offering.

I expect WhiteHat Security to manage this program from the perspective of an industry standard-bearer, as their first customer has indicated.
Should the rest of the wannabes and posers in the trustmark game raise their standard to this level, I'd have less to talk about.
Good luck and godspeed, WhiteHat, the industry needs your continued integrity in this space.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)