Every business has an Internet connection. Usually a firewall separates internal devices from the public Internet. Traffic typically flows from inside to outside to visit websites, send email, watch videos, and generally consume content.
In some cases, there is a valid reason to allow a device on the Internet to connect to a system inside your network. If a business hosts an email or web server, certain ports may be forwarded to the internal system to allow connections from external sources. Care must be taken to ensure that systems allowing public connections are securely configured and protected.
In other cases, internal systems and/or specific services running on those internal systems should never be publicly accessible. What could happen if that were the case? It is important to know that automated systems and people (good or bad) constantly scan Internet connected devices. This is where opportunity exists for bad actors to take advantage.
There are many ways to discover system information without ever connecting directly to the device itself. No hacking involved; simple discovery tools. This process of enumeration and discovery can lead to the development of an attack profile. It can also help to identify network administration practices within an organization. (Are the firewall rules valid? Are systems patched and up to date?)
What can connected device search engines tell us? Here are some examples:
- Host names (often many when certificates are involved)
- Open ports
- Geolocation
- Operating system type and versions
- Application type and versions
- Internal IP address information
- Vulnerability information based on reported version numbers
- Usernames
- OS login screen images
- Business names are often easily discoverable
Let’s take a look. All of these results come from searches limited to the Minneapolis / St. Paul metro area. Geolocation is not 100%, but it is often close.
Exposing any Microsoft client or server system service port is just plain bad practice. Examples: RPC (TCP 135), SMB (TCP 445), NetBIOS (UDP 137,138; TCP 139), LDAP (TCP 389), Global Catalog (TCP 3268). Exposing these to the Internet is asking for trouble. Yet, we see plenty of examples:
How about Remote Desktop Protocol? Do you have strong encryption enabled? Is MFA implemented? Is there a valid certificate on the system, or is it possible to carry out a man-in-the-middle attack?
What does your patch management strategy look like? Here is an Exchange server that is several cumulative updates behind:
Likely internal IP address and hostname (blurred). Computer likely not a domain member:
Here are systems with ‘VMware’ somewhere in the connection response. What’s troubling is that some of these results allow direct access to an ESXi host login page. Bad actors are a username and password or vulnerability exploit away from owning a whole system.
Reported ESXi version on a random system:
Recommendations
- Create an inventory of systems to understand management lifecycle and functions
- Review firewall rules periodically to ensure only truly necessary external to internal mappings exist
- Keep systems up to date
- Use tools like Shodan or Censys to understand your exposure