Tuesday, October 19, 2010

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)

Saturday, October 09, 2010

toolsmith: The NirSoft Collection



As I mention in this month's toolsmith, I am often reminded of all the tools I have not yet written about but have used on numerous occasions or even forgotten about. Such is the case with the NirSoft tools, particularly those found on the Windows side of the Helix distribution under IR.
Five NirSoft tools resurfaced for me well worthy of toolsmith mention as well as a place in the jumpkit.
Incident handler Kris Thomas used CurrPorts during a PCI DSS-related incident response drill we were conducting and promptly located the fake malicious process I’d seeded on a server as part of the drill.
Light-bulb moment: October's ISSA Journal toolsmith: The Nirsoft Collection is written to help you prevent one of those "doh!" moments. "Oh yeah, I'd forgotten all about that tool."
I'll simply rehash visual results of various tests I conducted for October's article.
Figure 1 is a CurrPorts screen shot taken before infection of the test VM with Backdoor.Win32.Agent.adqt (MD5: 6DBA44B457414593A858A3520A2F2278).


Figure 1

Figure 2 is the same view post-infection with the addition of bonus IPNetInfo results.


Figure 2

OpenedFilesView is exactly what it says it is, open or locked files on a given Windows system.

Figure 3 is an OpenedFilesView snapshot before infection with Backdoor.Win32.Poison.apec (MD5: CB702C3319A27E792B84846D3D6C61AD).


Figure 3

Figure 4 represents OpenedFilesView perspective post-infection where you'll note that the malicious binary has invoked Internet Explorer as we see changes to index.
dat. A quick review of C:\Documents and Settings\...\Cookies\ shows two cookies written to the system dated 9/26/10 for globo.com. Again, a bit of search engine research via site:threatexpert.com globo.com will reveal endless hits on various malicious behavior associated with globo.com, with particular emphasis on Brazilian malware.


Figure 4

Like it's fellow OpenedFilesView, WhatInStartup couldn't be more precise in its naming if it tried. Yep, it identifies what auto-loads when the system starts; always a good place to look for malicious basterds [sic].
Figure 5 is a WhatInStartup baseline screen-shot.


Figure 5

Figure 6 shows WhatInStartup results after a rogua AV (Security Essentials 2010...annoying!) infection; specifically, Trojan.Win32.FraudPack.amgz (MD5: 59C0E80D7F9705D10DA91E01B2763E9A)


Figure 6

Last but not least, NirCmd. This tool is interesting not overtly security-centric but good for pulling up registry entries or killing processes particularly when explorer.exe is hung.
Example: nircmd.exe regedit “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run”

The article is available here, the tools and others are here.
Use these oldies but goodies in good stead.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)