Blog

Nov 10, 2015 By Jean-Paul Bergeaux In Blog

How Phishing Sites Use ‘Reverse Proxies’ and Why You Should be Worried About It

Many IT savvy folks are too careful to get caught by phishing Emails, but most also believe that even if they do get caught, they would never fall for a phishing site.  Paying close attention to the details will protect them.

Not so fast.

The cyber-criminal and cyber-espionage groups have gone high tech and are now using Application Delivery Controllers (probably virtualized versions) to “reverse proxy” legitimate sites without the owners’ knowledge.  And this is giving the bad guys clever new ways to steal usernames and passwords for unimpeded access bank accounts and sensitive corporate and government data.

For those not familiar with Application Delivery Controllers, it’s a valuable tool for businesses to streamline, improve and protect their web content and applications.  (That last part about “protect” is  ironic, given this new vulnerability.)  Here’s how it works:

Untitled

Figure 1: From Wikipedia

Enterprises use reverse proxies to do things such as:

  • Load balance web traffic between multiple web servers of the same content
  • Secure Remote Access
  • Intelligent compression
  • Caching
  • Break and inspect SSL traffic (catch that?)
  • Application delivery firewall

There is one more thing that a reverse proxy can do that is important:  Substitute content.  Let’s say you have a home-grown application that has millions of lines of code.  Your organization wants to make a change to that logo or a string of text quick and fast, but the original code was not written optimally to accomplish this.  You can use a reverse proxy to replace content with a simple script.  “Request is X, return to user Y instead.”

So let’s recap.  Bad actors are standing up reverse proxies that front legitimate websites without the owners’ knowledge, a capability that allows them to do things such as break and inspect SSL encryption and substitute content.  Again, it must be emphasized, the original server will have NO IDEA this is going on.  In addition, the users who accidentally hit these sites will get the correct site, be able to log in as normal with their username and password, and even be able to use their two-factor authentication when enabled.

The only difference is that the bad actors can replace intended content with their own content for profit, break the Search Engine Optimization rules, and—most worrisome—break and inspect the traffic to log usernames and passwords at will.

How might bad actors use this for cybercrime? As one example, they could target users of a specific website by sending them an Email that looks very legitimate and comes from an Email address that looks authentic, but contains a link to their reverse-proxy front of the site.  Banking sites, of course, would be the most common targets, being the juiciest.  In such a case, when the recipients hit the link, they will get their bank site just like they expected. They log in, just like expected, review their account (or whatever is requested in the Email), and then log out.  Nothing bad seems to have happened, no malware has been introduced, and the user just logged in and logged out.  Then sometime soon after, their account is empty.  Gone.

The most effective cyber-espionage use of this technique is to use the content replacement feature to either make configuration changes or add malware to the user’s computer.  Either way, if successful, the bad actor then uses that to gain access to the compromised system for data exfiltration.

There is one footnote to this issue.  With the advent of external cloud usage in the Federal Government space, and the public knowledge of what agencies are using what cloud services, cyber-espionage can be accomplished by using the same SSL break and inspect for cloud applications.  This includes the AWS isolated GovCloud and even the vaunted C2S, if the bad actor could get inside the direct network traffic flow.  If bad actors can somehow get a Federal Government user to use their proxy instead of directly accessing the cloud application, then they can capture and log the activities live, or capture the login and password for direct access.

The bottom line: This is a severe threat that should be monitored for.


MORE POSTS