Are Your Web Server’s Private Directories Leaking Publicly?

Most cybercriminals are looking for the easiest way to gain access to systems. They typically follow a standardized playbook, with only minor variations depending on the environment they’re targeting.

This means they generally won’t invest much time in a secure target when they could easily pursue a dozen insecure ones instead. However, the most vulnerable entry point into a protected computer system often lies with its user.

However, when dealing with highly organized ransomware operations like Ransomware-as-a-Service (RaaS) models like LockBit, BlackCat, and Qilin, they operate like a business. Groups like these train affiliates and distribute documentation or dashboards to enforce a constituent attack methodology.

Regardless of which side of the sophistocation spectrum cybercriminals operate on, behind every system is a person, and human nature is the greatest weakness in a company’s security chain.

Years ago, I worked for a cybersecurity service that offered data protection, cloud security, and threat management. Most companies rely on services like these so they can focus on running their business. However, depending on a third party to cover up a company’s poor security posture is not a reliable strategy for keeping data private and bad actors out.

What if I told you that cyberthreats can uncover exposed web server directories that have been overlooked by those responsible for maintaining server integrity, using nothing more than the Google search engine?

Gaining Open Authentication via Google

Google’s advanced search operators are special commands that you can enter into the Google search bar to search the web with a fine-tooth comb for specific results. These operators can help you search specific websites and domains for specific files, keywords, and even uncover exposed data that wasn’t meant to be indexed.

Here are some examples of what Google can reveal:

• Intitle: “index of” “upload” - This will allow you to uncover publicly exposed directories on web servers that reference upload folders.

• inurl:/uploads/ - This searches for URLs that contain the path /uploads/, which usually indicates a public facing file upload directory.
• Intitle:”index of” “Parent Directory” “wp-content/uploads” - This query is targeted to find publicly accessible file directories on WordPress sites with an open medial upload folder.
• site:example.com inurl:files/ - This operator searches only within a specific domain (in this case, example.com) for URLs that have the path /files/.

As with anything that serves a legitimate purpose, it can also be repurposed by cybercriminals to gain access to sensitive files, event logs, and configuration data, potential gateways into local systems for lateral movement and broader data theft campaigns.

In this example, a hacker using the alias xloadsec compromised a Ricoh MP C307 multifunction printer’s web interface, giving the person the ability to remotely manage the printer connected to a local network, simply to discovering the unprotected device using a Google dork.

Utilizing these advanced search operators allows bad actors to access webcam feeds thought to be private, unprotected CCTVs that allow full control over the camera, to web-based UI’s for controlling industrial control systems.

When NASA’s Local Network Was Almost Got Hacked

Years ago, my group and I discovered a major security leak involving NASA’s VPN endpoint exposed on one of their subdomains. It showed their Cisco VPN profile configuration file and NASA’s entire configuration setup, used at Ames Research Center in California’s Silicon Valley.

We found this by simply searching Google.

For example, it revealed their publicly exposed VPN gateway server, including the Group name, the custom port used for VPN tunneling into NASA’s local network, a decryptable VPN group password, and other configurations. This is a perfect example of why it’s not a best practice to store .pcf or .ovpn config files in public directories.

If we wanted to escalate our findings into an attack campaign, we could have shifted over to credential stuffing attacks after a little research into their username templates. Since most U.S. government agencies use predictable naming templates (John Doe = j.doe, jdoe) with equally crackable passwords, this could have led to internal access into NASA’s protected networks.

This is a matter that was brought to the attention of NASA by the Dallas FBI Field Office back in 2009 when I was under investigation for hacking into a Clinic, including NASA’s Jet Propulsion Laboratory, and the Dallas Police Department. NASA had concluded that no internal systems were compromised.

And it all started from a Google search, which indexed a single piece of leaked information. This is just one attack vector that companies and organizations should think about when they consider their cybersecurity posture in a world filled with hackers.