Hi, We use Hackersafe to scan our network for vulnerabilities and they have found one relating to OWA which I cannot resolve. They say they can't assist as it's a MS product so I hope someone can help. The vulnerability relates to the owaauth.dll file and inserting a redirection parameter to point traffic to a bogus site to gather a users details when they logon to OWA. The details show that they are using the destination parameter to redirect the traffic to their site and the suggested fix is to: 'Remove the parameter that allows redirection from your site. If the parameter is required for operation then construct a list of valid links that the user can be redirected to [Whitelist] and any other links that are specified the user will not be redirected to.' I understand how I can alter the redirection in a asp page (and have done so for the owalogon.asp and logon.asp pages, but how can I do the same for the DLL file? I hope this makes sense but please let me know if more details are required. Thanks

I'm getting this result as well form Hackersafe. It's on our main webpage and there's no redirects anywhere that I can find so I don't know what they're finding as the report is less than informative... Any ideas of where I can look? All the pages on our site are .HTML so I'm stymied.

Is Hackersafe picking up the problem with the owaauth.dll file or something else? Are you using Outlook Web Access with Forms-Based Authentication? Exchange 2003? I have started a support case with MS, but they haven't come back with anything useful yet for this problem.

Actually yes, I just read a little further into the report and my issue is with the owalogon.asp file and we're using FBA and Exchange 2003... How did you fix your ASP files?

I changed two asp files. Firstly, when the user types the URL for OWA, they get the owalogon.asp page, which detects the browser locale and transfers onto the relevant locale folder on your Exchange server. See C:\Program Files\Exchsrvr\exchweb\bin\auth for the list of locale folders. None of my users use anything other than USA so I altered the owalogon.asp file to only redirect to the USA locale folder for the logon.asp, which is the second asp page used to authenticate. The change here is just after the line: redirectPath=Request.QueryString("url") I added the following: If redirectPath="https://FQDN/exchange" Then Else redirectPath="" End If Basically this says that if the redirectPath has been modified from anything other than my OWA server, then reset the redirectPath. The lines after this (beginning redirectPath=Server.HTMLEncode(redirectPath)) reconstruct the correct redirectPath for your connection and prevent the redirection. The main change is in the logon.asp under the USA folder, but if you have other locale's being used, you probably need to change the relevant logon.asp. Once I'd made these changes, I rescanned in Hackersafe but it then said the vulnerability was with owaauth.dll and not owalogon.asp. I couldn't resolve that one so I went to MS to fix it. If you make these changes and rescan, I'd be interested to know if it also picks up the owaauth.dll vulnerability.

I just found this on a different site. Maybe you can do this and it will "resolve" your DLL issue... http://archives.neohapsis.com/archives/fulldisclosure/2005-07/0504.html

Thanks for the link, but what I describe basically does the same thing, prevents the malicious redirection. The problem you'll find with your Hackersafe vulnerability is that they aren't looking at the logon process as a whole, they are just looking firstly at the owalogon.asp (which can be fixed) and then the second scan (once the fix is in place) will pick up on the fact that the redirection can still happen on the owaauth.dll alone. I don't think this is particularly relevant as the owaauth.dll is used 'behind the scenes' by OWA to authenticate and redirect the user, but Hackersafe (and more importantly PCI DSS) see this as an issue. The fix that Hackersafe suggest doesn't really apply to a dll file as unless you can modify the source code, you can't prevent the redirection/destination parameter from being applied.

Did the changes fix the problem with Hackersafe or did it find the dll when you did the rescan?

I also received this vulnerability, I am working on a resolution as well. Let us know if those changes fixed the problem, thanks!

Thanks for your reply. I have opened a case with MS to troubleshoot this but they aren't likely to change the code in the DLL, so the file will remain a 'vulnerability' in itself as it will redirect traffic (but that's its purpose so you can't really complain!) MS have basically said that Hackersafe need to understand the problem in more detail and not just flag it as a vulnerability because in the OWA logon process, if you've hard coded the redirection URL into the asp pages, there is no vulnerability. My next task is to convince Hackersafe!!!

You might want to shoot them the information for the technician you spoke to at Microsoft and paste the conversation you had. This vulnerability has only been recently discovered and most of Hackersafe's scans have a bias towards Apache so they may not be aware that the owaauth.dll can't really be fixed.

Thanks for the advice, I have sent emails to the support dept who originally dealt with this and to my account manager. I don't know how seriously they'll take this, it can be a battle sometimes! Can I ask how you found out about this vulnerability? I can't believe there aren't many other Hackersafe customers out there using OWA who must have the same vulnerability detected. The only solution I can think of is to remove the OWA functionality for external users and implement an SSL based VPN solution which users would have to connect to before accessing OWA, but that's a pain. Do you agree that this isn't a real vulnerability and Hackersafe need to amend their scanning?

If you are using Scan alert this was a false positive. Once you applied the fix tothe logon.aspx file, it did resolve the issue. The problem was that Scan Alert was using the post method when testing for the vulnerability. This is incorrect as they should have been using the get method. I challenged this as a false positive and they aggreed. You may already find that they have removed this off the list.

Thanks for the reply. That's very interesting. I had to restrict the owaauth.dll file in IIS to only local users, so now they have to create a VPN before using OWA. Can you give me some detail on your case so I can refer them to it? Many thanks

Hi WebGuy101, Unfortunately the response I got from ScanAlert was for more information on your case so they can investigate why it was a false positive. I would really appreciate any information you can provide, may the case number if possible so I can pass it on to ScanAlert to rectify the problem I am having with their scans. Regards Tippers

I've recieved a few questions in regards to this. This is the fix and the response the Scan Alert. To check if your OWA is susceptible try the following (fill in your mail server name where applicable and you may need to change it to https): http://mail.yourcompany.com/exchweb/bin/auth/owalogon.asp?url=http://www.google.com To fix: On your OWA server: 1. Navigate to 'C:\Program Files\Exchsrvr\exchweb\bin\auth\usa' (*usa* or which locale you are using) 2. Make a backup copy of logon.asp 3. Edit logon.asp 4. Go to line 54 of logon.asp 5. Hardcode the redirectPath variable to the path you are passing in to the URL, in the case of Microsoft's OWA servers, line 54 of logon.asp should look like: redirectPath = "http://mail.yourcompany.com/exchange/" 6. Close and save logon.asp 7. Click the URL you first tested with Hard-coding the destination/redirect URL prevents users from being able to navigate directly to mapped virtual directories on the OWA server, but if this functionality is required, step 5 could be modified to only allow a virtual directory to be passed (ie. hard-code the protocol and host name before allowing the 'url' parameter to be concatenated). As always this workaround should be thoroughly tested on a non-production system before being promoted to a live production system. Note: there are more logon.asp scripts to modify. The USA folder is chosen based on the language of the browser (en-us). Technically, you should also modify all the other logon.asp pages in all the sub folders (at the same level as the USA folder) This is what was sent to Scan Alert. Please note that at the time, their testing procedure used the post method on the form tag. The server, mail.xxx.com, has been patched per the instructions in the reference archives.neohapsis.com (from the links section in your site) and this fixes the issue you describe in your explanation of the URL vulnerability. However, your testing method still shows the error. In looking at your testing method, it is incorrect for the URL vulnerability that you describe. Why? The reason is that you use the "post" method in your form submission on your test. You must use the "get" method to test the vulnerability that you are describing to append the from inputs to the URL. The Form "post" method, does not append the form inputs to the URL in the form of a querystring, but rather it sends it in the body of submission and therefore cannot be crafted as a malicious URL. Hope this helps. WebGuy

Hi WebGuy, Thanks for your reply. So was your vulnerability with the owalogon.asp file or owaauth.dll? My original vulnerability was with owalogon.asp but I amended the logon.asp file with the hard coding and rescanned with ScanAlert and it came back with a second vulnerability for owaauth.dll. Owaauth.dll just verifies the logon credentials for the OWA user before redirecting to the Inbox/Mailbox of the user. ScanAlert are saying that can be exploited because the owaauth.dll file will also redirect to www.google.com etc. I don't know enough about web pages to understand fully the POST and GET methods and how they work with the owaauth.dll file, but if ScanAlert have dismissed the vulnerability they found for owaauth.dll on your system, I want them to do the same for mine. If the above is true for your case, please can you let me know the ticket number that you logged so they can refer to it and dismiss the vulnerability on my server? Many thanks Tippers

Technically, if you use the post method on a form submitted to the owaauth.dllyou can redirect a user. However, Scan Alert in there description claim that the vulnerability is due to a mailcious URL in an html hypertextlink. The problem with there test is that is uses the post method which can only be used on a web form (information is submitted to the body; they should have been using the GET method that appends theyinformation to the URL via a querystring. Therefore the test is wrong and the user can not be rediected using a just a URL (they would have to be tricked to go to a form on another website first). Hope this helps.

Ok, I think I understand a little better now. In fairness to ScanAlert they only catagorize this vulnerability as a 2 (Medium) which doesn't affect their Hackersafe certification for websites. It is PCI DSS who categorize it as a 3 (High) and causes the PCI scan to fail. I guess if PCI think there is the chance of any suspect activity on a server they will clamp down on it rather than allow it, even if the chances of anything malicious happening are slim. Thanks for your help, my only solution in the end was to restrict access to OWA from internal LAN IP addresses. Basically, OWA is not PCI compliant. And as far as I am aware, this isn't resolved in Exchange 2007 because the owaauth.dll has to be accessible by remote PC's (ie unrestricted IP access) to authenitcate users!

I spoke with ScanAlert (mcafee) today and explained to them how MS does not classify this as a vulnerability and pointed them to secunia alert # 14144 and iss-Xforce alert #19225 which showed there was no vendor fix for this.They said that if we could prove we blocked this vulnerability using an IPS for everyone but them (gotta love whitelisting the tester as part of PCI-DSS compliance) they would mark this as a false positive and show we resolved the issue. We use a tipping point IPS and there was a pre-defined filter (#3519) exactly for this. We are now in compliance.hope this helps you guys.

Thanks for your post, I hadn't thought about looking at the IPS signatures before, glad to hear you found a way to solve the problem. I have a couple of questions though which I hope you can answer. Firstly, can you give me some more detail on the name of the signature within the Tipping Point device as I can't see anything relevant on my Sonicwall. I have sent the question to Sonicwall but thought you might be able to point me in the right direction. Secondly, with this block in place (I presume you've excluded all ScanAlert IP addresses from being detected by this signature but all others are detected?) does it affect the functionality for the end user of OWA? I imagine that it just prevents a user clicking on a link in an email opened via OWA and nothing else, but I'm interested to hear if there is other functionality affected.

Hi Beaker2, I have investigated this solution with our IPS company but they can't figure how it canbe done as all the OWA traffic is SSL encrypted, so the IPS can't see the content of the traffic. Is this the same scenario for you or are you using another method of connecting to OWA? Regards Chris