When Vendor Practices Put Security at Risk

Back in the 1950s, when a reporter asked the infamous robber "Slick" Willie Sutton why he robbed banks, the man reportedly replied, "Because that's where the money is."

For cyber criminals, the thought process is much the same as Slick Willie's. Attackers realize they can steal troves of data—or in Willie's case, money—by targeting the places where multiple companies stash their backups. After all, why target just one company if you can get a bigger payoff?

Many enterprises rely on third-party vendors for services like backups and monitoring, but they may not realize whether those vendors have adequate security practices—or worse, are phoning home data. Recently, I met with an ExtraHop customer to check up on this. We started by looking at detections in ExtraHop Reveal(x), aka the unusual behaviors and potential security risks uncovered by machine learning techniques and rule-based monitoring.

Drilling into Detections

One of the handy features of detections is the ability to drill directly into the transaction records associated with a specific detection. We clicked through to dig into the details about some credentials sent over HTTP, as seen in the screen capture below.

The green filter (top left) allows a Reveal(x) user to drill down into the transaction records associated with a detection. In this case, Credentials Sent Over HTTP.

One client/server pair got our attention. The client sending credentials is a production database server and the server receiving the credentials is an internet asset hosted at BackupLivesHere[.]com. Not the real site name. We made that up—just know it was similar.

We confirm there isn't any encryption—no internet protocol security tunnel or VPN between the database server and BackupLivesHere[.]com. We continue looking further.

We add a filter to isolate when credentials are sent to BackupLivesHere[.]com. The transaction happens every three hours like clockwork. That sort of consistency screams scheduled task or cron job. Could it be an automated process somebody configured and forgot about?

Explore the Packets

We use ExtraHop to search and view the packets associated with the three-hour transaction of shipping credentials to BackupLivesHere[.]com. What's killer about this is there's no more 10-second capture, filtering PCAP files, waiting, filtering, waiting, searching, repeating. While PCAP download is restricted to administrative users to ensure maximum data privacy and security, it's a huge timesaver to view only the packets of the single transaction we care about from SYN to FIN.

Two aspects stand out:

1. The user_account is not a company email address. It's a personal address. Remember, this is a company-owned resource backing up company information.
2. The password is shockingly guessable. It's also in the RockYou password leak and part of a standard set of passwords an informed attacker will use in a password guessing attack.

We should mention that properly encrypted usernames and passwords are never exposed in Reveal(x) as a security precaution—but back to the customer.

Shadow IT (someone acting without the knowledge and better judgement of the company's experienced IT pros) is an extremely common challenge. Security and IT teams have to be on the lookout for not only insider threats, but insider security risks stemming from unauthorized use of technology vendors. With the help of network visibility, this company was prepared to effectively sniff out shadow IT using subpar vendors. So far they found:

• company asset (database server)
• sending backups over the internet
• using a non-company email address
• password sent in the clear
• password on widely used list of common passwords

I'm curious about BackupLivesHere[.]com

A quick nmap of BackupLivesHere[.]com turns up some interesting findings:

$ nmap URL_REDACTED
Not shown: 995 filtered ports
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
990/tcp open ftps
8088/tcp open radan-http

Hmm...FTP? A simple netcat command will check.

$ nc IP_REDACTED 21
220 Microsoft FTP Service

Yup... FTP. And it's probably a Windows server.

We peek at the HTTP headers and see:

Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319

Smelling more and more like a Windows machine.

What does Shodan know? https://www.shodan.io/host/IP_REDACTE

21 is File Transfer Protocol

25 is mail

80 is web

135 … holy crap! We'll come back to this.

443 is Secure Sockets Layer

990 is FTP over SSL

3307 is …

Wait a minute.

The default port for MySQL is 3306 and 3307 is next door. I wonder if they are using a non-standard port for MySQL?

% nc IP_REDACTED 3307
[binary junk]
MySQL_native_password

Somebody thought they were being clever and moved MySQL to a non-standard port, but the internet found it. Closer inspection of the banner reveals it's MySQL 5.7.26.

Version 5.7.26 of MySQL was released in April 2019 and there are vulnerabilities for this particular version of MySQL.

Even if patched, leaving your MySQL instance exposed to the internet is absurdly bad practice. It's not careless; it's negligent. And, since Shodan knows about this, the bad guys know about this.

Let's go back to port 135. That's Microsoft RPC, the service most people associate with remote management. As a rule of thumb, exposing MS-RPC to the internet is asking for trouble.

Exposing Third-Party Security Risks

We now know that we had uncovered a case of shadow IT sending database backups to a third-party service provider that looks to have a horrible security posture. This issue hits close to home for many security professionals who can easily be unaware of improper internal security practices—but this team had the tools and foresight to proactively seek out these risks.

This underscores the importance of both knowing where data is going, and understanding the security protocols of the vendors that house it. Otherwise, you may leave the door open for bad actors to begin exfiltrating. To paraphrase Willie Sutton, why break into one database server when you can steal the backups from multiple companies by breaking into their backup provider?