As hard as we try to forget the Equifax breach, it provides endless lessons for information security professionals and researchers. This was yet another case where security basics and good hygiene would have prevented the attack, or at least slowed it down. In the Equifax case, attackers gained access by exploiting a bug in an Apache Struts platform tied to the company. This is exactly the low-hanging fruit that we talk about in security, which attackers can exploit to gain a foothold within a company and cause some pretty severe damage.
The breach quickly turned into a nightmare not just for the company, but for most Americans who had entrusted sensitive financial and personal data to Equifax. It was the perfect setup for a media frenzy — a reported 145.5 million Americans were affected, the public relations response was fairly lackluster and uninformed, and the CEO lost his job — the headlines basically wrote themselves.
It stands to reason that these types of attacks and exploits are happening around the world, every minute of the day, and they just aren’t receiving the same level of exposure that we saw with the Equifax breach.
It’s the onus of every organization to work diligently to secure their corporate infrastructure against attackers. Equifax’s Apache Struts server was vulnerable to a CVE reported back in March, four months before Equifax discovered the intrusion.
Today, we’re going to show you how you might look for suspicious-looking Apache Tomcat servers and either secure them or take them offline to prevent exploitation.
Finding potentially unprotected Tomcat servers
With the understanding that default domain set up pages often indicate an incomplete (and likely insecure) installation, we searched for some of the language you’d be likely to find on default pages once an installation is successful. With that in mind, we chose to search for the following text: “You’ve successfully installed Tomcat. Congratulations”.
There are just over 5 million search results from that query, which are fairly interesting to explore from a research standpoint, but is there a way to determine whether you have any of these insecure servers on your network or your corporate network?
Discover unsecured Tomcat servers tied to your network or brand
To find all of these servers in your corporate network, you’d run that following query and add AND “[company domain]” after to limit the results to just those found in your network.
Here’s an example of what that would look like: “you’ve successfully installed Tomcat. Congratulations” AND “airbnb.com”. We’ve chosen domains associated with bug bounty programs for our examples here.
You can also use the parsed.names field to constrain to only Paypal (or whichever domain you insert). For example: https://censys.io/ipv4?q=tomcat+AND+443.https.tls.certificate.parsed.names%3A+aol.com
What should I do if I find any servers?
If you do find servers within your corporate network, we’d suggest that you:
- Do a bit of legwork to determine who in your organization put the server online. The forward or reverse DNS names might help indicate which group installed this server, other services on the host, or the IP address might help locate the asset, but this can be a bit of a challenge.
- If the person who set up the server is not using it, take it offline.
- If they are using it, go through your normal procedures to lock it down or, if the server isn’t up to your security standards even with extra measures in place, set up a new, secure server for the employee and get them set up on it. This might include firewall rules to prevent remote access to the application server.
- Educate the employee about the security procedures everyone must follow to add new corporate assets to your infrastructure. It’s important here not to place blame or shame this person, who will likely be frustrated and embarrassed to have their mistake pointed out. Try to remain patient and write out the steps for them. If they’re a manager, ensure that their direct reports know these policies as well.
What else can I find in Censys?
We’re always adding to our data sets, but to get started, try searching for Oracle, MySQL, MSSQL, Postgres, MongoDB databases, NGINX and APACHE servers, and IMAP protocols. We plan to keep writing blogs about finding vulnerable hosts, but in the meantime, do a bit of exploring and see what you can dig up.
