Posted on Tuesday, 14th May 2013 by Michael
Four of the most helpful Outlook Web Access Rules you will want for your Web Application Firewall
Over the last few years a new client of mine has been battling a never ending battle against human stupidity and system compromise. It seems that no matter how much training the client provides to their users that at least a few times a year they have several employees fall victim to phishing attacks. These attacks could lead to compromise of additional systems depending of the access the user has and the remote solutions the client has, denial of service through spamming and black listing, loss of revenue due to the loss of ability to email, possible loss of sensitive data depending what was in the compromised user’s mail box, countless hours of IT staff time to remediate and resolve the chaos the attack caused and so on.
To help combat the non-human element in this article we are going to address ways to combat the steps attacker takes to leverage the credentials once they have gained them in order to send more phishing attacks and stay hidden. The rules below assume that you are serious about security and have your WAF in bridge mode where it has the ability to reset a TCP handshake then block the attacker IP. If you are in other modes you are basically going a race condition against the attacker to try to reset his / hers packet. In my opinion the best solution for deployment of the WAF is in bridge mode between the firewalls DMZ interface (because being security pros you don’t let your developers put internet facing servers inside your network) and the DMZ switch. The reason I do not say outside the firewall is that you will have a lot more traffic hitting the WAF that has nothing to do with the WAF increasing the load on it and the tuning required. Trust that your firewall administrator has done their job and limited access to the web servers to 80 and 443 and trust the WAF admin to protect them against web based attacks.
The first rule is very simple. If you do not have employees overseas there is no reason for non US IP addresses to access your Outlook Web Access site, nor is there a reason for mobile phones to try to synch to outlook while not in the US. To combat against this most WAF (Web Application Firewalls) has the ability to do Geo Location based on IP and block access to the site and its content. If your WAF does not have this ability it is simple to add it in most cases. It would be as simple as creating a list of non us based IP ranges and adding them to a deny list. To find the ranges a simple Google will turn on several versions of it and then verify the accuracy against Arin.net or another source. In the event you do have non us based employees I suggest that access to OWA or the full outlook application is provided by through another means such as Citrix that is protected by two factor authentication. This will provide the ability to continue business and decrease the ability for someone to use the harvested credentials to send my phishing attacks / spam.
The second rule is to limit the ability to edit rules in OWA. This could have negative effects to your organization so it is important to monitor this rule for a bit to see how much legit traffic you see for employees adding or modifying rules in OWA to deal with mail. The reason why we added this rule is that one of the first things the spammer does is to add rules to hide their work. They will have all inbound emails go to trash to hide responses and bounce backs as well as several other rules to cover their tracks. While monitoring this over a months’ time we only had 1 employee ever actually setup rules in OWA and not in the actual Outlook application. This rule was a little tricky to setup as we had to determine what URL’s were being accessed. To do this I used Burp Web Proxy to create man in the middle and tested adding rules as an attacker would. This allowed me to watch what URLS were accessed so I knew what ones I would need to add.
Block access to:
/ecp/RulesEditor/
/ecp/?rfr=owa&p=RulesEditor/
To make sure they can’t alter the URL or find a way around it add the above using a regex statement if you’re WAF allows it.
Once again blocking this does not mean that you are causing a bottle neck for work to get done. Remember above if they need that capability via remote access they can always access your two factor Citrix solution.
The third rule is used to block some of the most common tools they used to automate the process. One of the tools I noticed that was almost 99.9% of the time associated with the spam attacks was Crazy browser. There should never be an occasion where any employee is using this browser to access your system. The reason they use Crazy Browser is it allows them to script the attacks using built in functionality without having to install external plugins into their browsers. I don’t want to go into great detail on this rule as this is mostly used by script kiddies and is so simple to block. I don’t want to give them a heads up on how easy it is to circumvent. Though if you are monitoring your logs you will see how easy it is to create the rule to block it. This goes for any tool that shows in the logs.
The final rule is to limit the number of senders that can be emailed through OWA. How often does someone in your organization need to use OWA to send email to several hundred users at once. In most cases if they do need to they will all be internal and most likely associated with a distribution group which will still work with this rule in place. This rule basically looks at the recipient URL parameters for a key parameter and gets the page response back from server. This allows you to see all the recipients of the mail. Through several tests we were able to determine an acceptable number of recipients through the size of the response page.
The URL parameter you will want to search on is:
“ns” with the value of “RecipWell” and “ev” where the value does not equal “GetCache”
Then you will want to see if the page response is greater than 8000 bytes. If it is then you will want to block it.
There are many other rules you will want to add as your WAF learns the structure of your OWA and you determine what is normal and not normal. These rules are base rules that I have been able to come up with after watching the clients WAF for several weeks and working with them through two Phishing / spam attacks as well as the cleanup process. Using these rules they have seen a huge decrease in attacks as the WAF instantly starts blocking the malicious traffic allowing them to quarantine and remediate faster without causing outages to their business. Though the WAF is doing its job it is still important for further end user training as well as disciplinary action against those that continue to fall victim to phishing attacks.
Posted in Blog | Comments (0)