<img src="//pixel.quantserve.com/pixel/p-_JKXxuL8SR7wu.gif?labels=_fp.event.Default" style="display: none;" border="0" height="1" width="1" alt="Quantcast">
blog-banner.jpg

Next-Gen CASB Blog

How to Patent a Phishing Attack

By Nat Kausik | October 1, 2015 at 10:00 AM

Yesterday, someone sent me a link to a TechTarget article on US Patent 9,137,131 to ask what I thought about it. The article made some bold claims atop the SAML standard, so I thought I would take a look at the patent application to learn more. 

The patent application left me quite puzzled. A key security aspect of the SAML standard is that a user only enters his password into a trusted identity provider. Third parties must defer authentication to the trusted identity provider and confirm authentication via a "SAML assertion" that is signed by the identity provider. Full details of the SAML flow are depicted in the diagram from Wikipedia included above. 

And yet, US Patent 9,137,131 "Network traffic monitoring system and method to redirect network traffic through a network intermediary" teaches that in their invention, a user must enter his password into a proxy, which then passes the credentials on to the identity provider. To wit, here is the top-level claim of the patent with the highlighted text indicating the crux of the invention.

What is claimed is:

1. A network traffic monitoring system for redirecting network traffic between a client device and a cloud service, the system comprising: a monitor proxy server configured as a network intermediary between the client device and a federated identity provider and between the client device and the cloud service, the monitor proxy server being designated by the cloud service to receive a redirected login request, the redirected login request being a login request originated from the client device and destined for the cloud service for accessing the cloud service, the login request being redirected by the cloud service to the monitor proxy server as the redirected login request wherein the redirected login request identifies the cloud service, the monitor proxy server being configured to provide, on behalf of the client device, a login credential including a password of the client device to the federated identity provider in response to the client device being redirected to the monitor proxy server by the cloud service and to receive from the federated identity provider a redirect response including an identity assertion or token generated by the federated identity provider upon user authentication, the redirect response containing a redirect web address to the cloud service, the monitor proxy server being configured to rewrite the redirect web address to the web address of the monitor proxy server, the monitor proxy server further being configured to rewrite a response web address in network communications between the cloud service and the client device to the web address of the monitor proxy server, wherein network traffic between the cloud service and the client device is routed through the monitor proxy server after user authentication by the federated identity provider.

In short, the patent is all about breaking the security of the SAML standard via what is essentially a phishing attack.This is certainly not a patent that is going to be infringed upon by any serious security product. The logs retained by the proxy might well carry users passwords in the clear, and the security and handling of the logs are now a serious vulnerability. Secondly, training users to enter their credentials into a proxy guarantees a breach via phishing.  

A primary cause of recent high profile breaches is proxy phishing.  For example, in the case of the Anthem Breach and the Premera Breach, employees entered their work credentials into a proxy operated by hackers, which captured user credentials, and then logged the user on to the actual application. As with any proxy phishing attack, the Anthem attack mimicked normal application behavior and went unnoticed for a long time. In another example, in the JPMorgan Breach, employess entered their JPMorgan credentials into a third-party site, which was compromised. In all three breaches, employees had not been trained to enter their corporate credentials ONLY into their corporate IDP.  In fact, the risks of proxy phishing drove the Google Safe Browsing initiative to great lengths to automatically detect such phishing attacks, offering an API that is used by all leading browsers to prevent users from entering credentials into proxies. Unfortunately, all bets are off if a customer explicity purchases a product embodying the invention of this patent thereby authorizing phishing attacks on his own users.  Caveat Emptor, the cure is worse than the disease!

Prefer a solution with transparent, agentless redirection without the phishing attack? Take Bitglass for a test drive.

Start My Free Trial