Monday, April 14, 2008

Proposal For Building Anti-Phishing Tool Countermeasure

Honeypot from http://www.honeyd.org/concepts.php
I recently responded to a student email that asked ideas for building an anti-phishing tool. My initial recommendation was to look at the types of phishing attacks and the potential countermeasures. This is the approach I underdtook when developing a product for ISS (now IBM ISS) called ISS crosscheck back in 1998 which purpose was to adaptively change the counteremeasure (e.g. Realsecure policy) depending on finding a known vulnerability was deceted via the ISS scanner. In application security we need something similar that adaptively detect the attack, in this case the phishing tool being used and then trigger the countermeasure. Phishing threats and countermeasures are very well dealt with in the work done by Aaron Emigh @ Radix labs: http://www.antiphishing.org/Phishing-dhs-report.pdf. Phishing is in an essence a social engineering attack that even if has a common delivery (e.g. malicious link via email) it can take different forms of attack vectors for the phishing "tool" itself: it can be for example a non sophisticated phished site built by registering a fake domain and look alike webpage (you can build one yourself via CGI and very little knowledge required) or a tool that links to the legitimate site URL and exploits a vulnerability such as cross frame scripting (XFS) , cross site scripting (XSS), weak authentication and Cross Site Request Forgery (CSRF). Other forms of phishing might include a phish web proxy to perform a man in the middle attack that connects to the original site (no copy of the original site). Attacks of this nature can break MFA (multi factor authentication) controls such as hardware tokens (One Time Passwords) and they are actually easier to do then the old ones that require re-building the web site in CGIs. The risk associated to this phishing attacks is therefore higher (exploitability risk factor is higher). Phishing attacks that use botnets and MiTM (Man in The Middle) make the IP geolocation and machine fingerprinting techniques used by risk authentication controls (e.g. Cyota RSA) useless from the phishing mitigation perspective. When successfully attacking IP geolocation, the machine perpetrating the attack can be, let say in Rumenia with a remotely controlled botnet proxy that shares the same geolocation or ISP as the victim's machine in the East Bay USA. To successfully attacking device fingerprinting the phisher will reply such fingerprinting information from the phished machine. Attacks of this nature were reported since 2005 in Europe and since 2006 in USA . Current phishing countermeasures can be build in the web site such as strong authentication via PKI. Tricipher http://www.tricipher.com/threats/index.html have developed with the countermeasure for MiTM phishing in mind. Understanding what current web application authentication controls do mitigate phshing is critical as well what the threat is and which countermeasures are effective. For the anti-phishing countermeasure to work need to be capable to identify different phishing tools and that's probably the most difficult task since some of these tools are very sophisticated and complex. Currently, for the most sophisticated forms of phishing tools you can look at Rockphish whose functionality is not well documented apart from some research found here http://www.avertlabs.com/research/blog/index.php/2007/11/page/2/ and here http://www.avertlabs.com/research/blog/index.php/2007/12/ the tool will create new IPs on the flight so that taking down the IPs will not prevent the attack. This represents a challenge from the incident response perspective. In the case of the class of phishing that exploits common web vulnerabilities on the legal site you need first at a tool that can scan for CSRF, XFS, XSS, and weak authentication vulnerabilities. The tool needs to web scan for the target site for web application vulnerabilities that can be used for phishing the site. As a result of this scan a countermeasure consists in implementing input validation, transaction codes, strong authentication. A more sophisticated tool needs to be able to identify the phishing tool itself (the attack) having clues on how operates and how is deployed and configured (domain). Part of the identification might need to perform some protocol analysis to identify proxies, botnets, etc. Eventually out of this phishing attack vector scan you need to be capable to develop a signature of the phsihing tool itself. The tool needs a library (knowledge base) of known phishing sites/tools to create a baseline for which the anti-phishing tool can be used for testing the countermeasure. Unknown phishing tools can be learnt with a honeypot. Finally once the phishing site is identified with the countermeasure you need a tool that can do incident response: in the case of phishing it means try to find a way to take down the site via the register and the IP that the site is hosted to. Taking this further it could also mean to try to counter-hack the phishing site such as finding and exploiting vulnerabilities on the phishing site itself (see Crack the hackers http://www.itp.net/news/516118-i post) such as causing a DDos on the phshing site by exploiting a buffer overflow and other vulnerabilities etc. Some of this phishing tools are build to attack and to defend themselves but they are also prone to security bugs as any commercial software tool. Good resources to start a study of phishing are also the OWASP phishing web page http://www.owasp.org/index.php/and the anti-phishing working group http://www.antiphishing.org/. Maybe this is could be good proposal for a OWASP grant (next Spring of Code 2009) or for some pioneer VC willing to invest in a new security tool. If we take Gartner figures of the billion of $$ lost in phishing, probably investing some hundred thousands in a phishing countermeasures is worth the investement nevertheless just adopting a risk management perspective: if cost of building the tool less than cost of loosing the asset and no tool is available then maybe is worth building one

No comments: