Hello, during an external scan it was reported that our Exchange 2010 Outlook Web Access has vulnerable to XSS attack. I was wondering if anyone had a recommendation remediating? It has the latest patches installed for IIS 7.5. I believe it is Exchange 2010 SP1.
I am dealing with exactly the same thing - and am conducting research to determine if we "are"vulnerable. Form what I have found Windows 2008 R2 is not on the vulnerability list when paired up with .Net framework 2.0. and you would think that msft would not leave this vulnerability open in their product...
Josh, have you been able to obtain an answer to your question outside of this forum?
I assume you are referring to Q90780. If this is a correct assumption, you will need to implement the URL Rewrite Module within IIS7 and write a custom URL redirect in IIS7 to deny/reject the specific character string.
http://www.procheckup.com/vulnerability_manager/documents/document_1258758664/bypassing-dot-NET-ValidateRequest.pdf. can be very helpful as well.
Yes Sir, that is what I am referring too -- Exchange 2010 uses .net 2.0. though it appears that 3.5 is supported, though not too sure what the implications are when looking to go this route.
Is there an article you could direct me to? as this may be a simpler and less painful approcah. Your response is much apprecaited.
Would not the following validateRequest="false" from the OWA web.config indicate that "ValidateRequest" is disabled, hence mitigate this form of attack?
c$\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\web.config
<pages enableSessionState="false" enableViewState="false" enableViewStateMac="false" autoEventWireup="false" smartNavigation="false" validateRequest="false" />
We also performed an external vulnerability scan and found the Q90780 on our IIS servers. Do you have any additional details on this URL Rewrite module as IIS administration is very foreign.
From what I gather, the validaterequest=false would actually make an IIS more vulnerable to XSS attacks.. but again, not an Web Admin so getting a crash course on this today.
From what I am understanding - and I to am not an authrotirty on the subject, you are indeed correct.
However the threat can definitely be minimalized if not fully mitigated.
I think it is kind of crazy, as the scan is "appears to be only looking for .NET 1.. or 2, and not for the active vulnerability... as I spent a ton of time on this, and Qualys just accepted my false positive as a reult of validaterequest=false....
Some artciles that may be of help.
Its funny you say that the validaterequest flag set to false was accepted as a false positive by Qualys. Same request by us on our OWA was rejected. Seems like Qualys is very inconsistent with how they are handling this issue.
BTW, Qualys has told us that even 3.5 version of .Net is vulnerable even though MSFT has not acknowledged this and officially listed 3.5 as being vulnerable.
We have recently confirmed with Microsoft that because OWA cannot run with the Validate Request Filter in use, QID 90780 would not apply to an OWA only implementation: "The Microsoft Security Response Center has verified that OWA itself is not vulnerable to these CVE's. If you have any other ASP.NET
applications on the system, you will need to implement defense-in-depth
measures to address the vulnerabilities, but not for OWA." It’s important to note that when submitting this as a False Positive Request to confirm that the Validate Request Filter is disabled, and that there are no other applications on the target device.
In regards to version 3.5 being vulnerable, we have confirmed in our lab that ASP.NET 3.5 (with all service packs) is Vulnerable & Exploitable. The vulnerable component "X-AspNet-Version:2.0.50727" is carried over from Version 2 to Version 3, and so we believe that both Versions are equally vulnerable. If this vulnerable component is detected during a scan, it confirms the vulnerable component is running. A clean install of Version 4 does not include the vulnerable component by default, however caution should be used to ensure any upgrades don’t carry over the vulnerable module.
Additionally, it’s important to note that a “Vulnerable” framework may not be “Exploitable” if secure coding practices were applied at the Web Application Layer. For that reason there are essentially two primary ways to resolve this issue for PCI Compliance:
1-Ensure you are not running the vulnerable component/framework
2-Provide Evidence proving the target application is not Exploitable to Cross-Site Scripting (XSS)
If OWA is shown to be safe from this vulnerability, does this also apply to using ActiveSync to connect with mobile devices as part of OWA?
Josh, Tony and rh1138,
I have sent you all an email with the information that helped us resolve this issue. Please contact me via email with any questions. Thank you.
Could you pleae forward the email to me as well? I am running into the same problems.
Read through this thread, could you please send me also some links regarding this vulnerability?
I have the same issue on outside facing exchange servers we are using.
Hope to hear from you soon. Thank you.