3

I am working on a client's PCI compliance. One of the failing items is:

3.1.4. Blind SQL Injection (httpgenericscriptblindsqlinjection)

The offered solutions is simply: "Ensure that the Web application validates and encodes user input before using it in a SQL query."

It appears to be related to OWA as it sites: "Found blind SQL injection on http:///owa/?P=+ADwscript+ AD4alert(42)+ADw/ script+AD4 using method GET"

Does anyone know how to fix this particular issue?

Aegyptus
  • 47
  • 1
  • 5
  • Is the Exchange/OWA install full-patched? – jscott Jul 30 '12 at 23:10
  • Yes, there do not appear to be any available patched for Exchange or SQl on the server in question. – Aegyptus Jul 30 '12 at 23:17
  • 1
    The only result on Google for that SQL injection string is this question. Makes me wonder if something is seriously misconfigured on your machine, or, it's in fact not an OWA problem, but something *else* unsecured on your exchange server. – Mark Henderson Jul 30 '12 at 23:17
  • It would appear to be related to UTF-7 attacks: http://msdn.microsoft.com/en-us/library/dd565635%28v=vs.85%29.aspx - it really looks like you have something else running on your `owa` server... – Mark Henderson Jul 30 '12 at 23:19
  • The string had the IP address before the /OWA, I removed that part. I had just added it to show that it was OWA related. – Aegyptus Jul 30 '12 at 23:19
  • @Aegyptus - that may be a red herring. Is `owa` your SBS 2011 box? – Mark Henderson Jul 30 '12 at 23:27

1 Answers1

4

I think that the term "SQL Injection" is leading you astray here. What they're actually describing is a XSS (Cross-Site Scripting) attack.

You can read about this specific vulnerability here: http://msdn.microsoft.com/en-us/library/dd565635%28v=vs.85%29.aspx

Basically, http:///owa/?P=+ADwscript+ AD4alert(42)+ADw/ script+AD4 is somewhere returning the exact input, totally un-sanitised, on a document that does not specifcy its encoding type.

This means that that code is actually rendered and parsed by your browser as <script>alert(42)</script> which shows a popup "42" when loaded.

This particular script is not very naughty, but you could do some really malicious things to peoples accounts if you redirected them to that URL on your server. Like embedding a nasty JS file from your server that hijacks all inputs on the page, or inserts a virus into the page, etc.

However, I cannot find any indication that OWA has any of these vulnerabilities, so I can only assume that your OWA server is running something else that has this vulnerability.

I just tried this exploit against an Exchange 2010 server we have here and it doesn't do anything. If this is an SBS 2011 machine as your tags seem to indicate, then normally remote access/owa sites only run under the /remote/ folder. Do you have another default IIS application running on the root of the domain?

Mark Henderson
  • 68,823
  • 31
  • 180
  • 259
  • If it's for PCI compliance, it doesn't have to actually "do" anything, its existence is reason enough to cause a failure. Not to take away from anything you said, but I bet the OP's primary concern isn't on whether or not this exploit is actually a real threat, and is instead on passing the stupid audit. – HopelessN00b Jul 30 '12 at 23:29
  • You are correct HopelessN00b, my goal it to pass the audit. I do not have any ISS applications running in the Root of the domain. It does, as of today, redirect from the root to /owa, but that is something that I set up today to address another failed item on the PCI scan list. – Aegyptus Jul 30 '12 at 23:54
  • I think I understand. You said earlier that you deleted the IP address... so what the real URL is `http://example/OWA/?etc` - this is very confusing, as in your question it looks like you're linking to `http://owa/?` which is *very* different. I would probably be opening a support case with Microsoft then, as I don't think anyone here will be able to help you with debugging an alleged vulnerability in OWA. (I say alleged because I suspect that the auditor is just using a one-size fits all approach) – Mark Henderson Jul 31 '12 at 00:02