EPISODE 3
We suspected the vulnerability could be the result of a compromised redirect or forward from the site.
Turns out it is a classic case of :
First, we reviewed the code for all uses of redirects or forwards (called a transfer in .NET). Next, for each use, we identified if the target URL was included in any parameter values. In some cases it was, but there was validation in place to ensure that the value was a valid site.
Not giving up on the idea, we spidered the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). We looked at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. That is where we found the bug. In one case we were able to change the target and observed that the redirect would allow us to redirect to any site of our choosing.
See, web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Now, without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
We contacted the website operator, but they were unaware that these sorts of attacks could even happen.
How To Prevent Unvalidated Redirects and Forwards?
Safe use of redirects and forwards can be done in a number of ways:
1. Simply avoid using redirects and forwards.
2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe. Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust.
Forensics and log analysis.
Finally, after getting in touch with the website operator we were able to begin a forensics investigation. We look at the logs for the application and looked for the signature of the exploit. Our search led us to an IP address from the lower east side of the city. Looks like it could be your man.
We suspected the vulnerability could be the result of a compromised redirect or forward from the site.
Turns out it is a classic case of :
First, we reviewed the code for all uses of redirects or forwards (called a transfer in .NET). Next, for each use, we identified if the target URL was included in any parameter values. In some cases it was, but there was validation in place to ensure that the value was a valid site.
Not giving up on the idea, we spidered the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). We looked at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such a URL. That is where we found the bug. In one case we were able to change the target and observed that the redirect would allow us to redirect to any site of our choosing.
See, web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Now, without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
We contacted the website operator, but they were unaware that these sorts of attacks could even happen.
How To Prevent Unvalidated Redirects and Forwards?
Safe use of redirects and forwards can be done in a number of ways:
1. Simply avoid using redirects and forwards.
2. If used, don’t involve user parameters in calculating the destination. This can usually be done.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL. Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe. Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust.
Forensics and log analysis.
Finally, after getting in touch with the website operator we were able to begin a forensics investigation. We look at the logs for the application and looked for the signature of the exploit. Our search led us to an IP address from the lower east side of the city. Looks like it could be your man.
Great work! I will get in contact with Ms. Sheraton.
I called Ms. Sheraton back and explained what had happened. The police were able to trace the attack to a specific person who they now had in custody. Case closed.
Oh, Thank You, Mr. Failsafe.
