Are you covering your assets?

Does your company have internal assets exposed to the internet? There is a very good chance that you do.  Many companies have exposed some of their internal assets to the world both intentionally and unintentionally.  For instance, if you run your own mail server, be it MS Exchange or something else, it needs to be somewhat exposed so that it can receive the inbound messages.  There are various methods for “exposing” these services, that can range from directly connecting the server to the public internet (terrible idea) to having them run behind a WAF (web application firewall) or at least NAT’ing only the required ports to a server running in a DMZ, but this is a topic for another post.

Other common things that businesses tend to allow access to are security cameras, firewall web admin pages, remote desktop services, VNC access to various control systems and web servers (this by no means is an exhaustive list).

Many IT admins will expose services for convenience sake while misunderstanding the security implications. They have the impression that they are just a small company with nothing of significance to steal, so no one will target them.  Though that sentiment carries some truth, it does not mean that they will not become a victim by some form of cyber-attack.

Victims can be grouped into 3 very general categories. The self-inflicted, this doesn’t mean that they are doing activities trying to become a victim, rather they are engaging in activities that have a higher risk. These activities include, but are not limited to, installing pirated software (often containing malware), downloading torrents and visiting lude websites.

The next category is the targeted victims. These victims do have something of value and can be targeted for a variety of reason, such as financial gain (of course), politics, terror and so on.  The attackers in these cases can range from individuals to nation-states, and when it comes to the latter, the odds do not favor the target.

The third category, and focus for this post, is the victim of happenstance or drive by.  This category, by far, is the largest in terms of incidents.  These victims are not targeted because of who they are or what they have. They become victims because they are the low hanging fruit.  They have some asset exposed to the internet that they should not have (VNC without authentication) or failed to maintain a resource that is meant for public access (webservers).

Some IT pros still think that there is still not a significant danger in exposing these assets given that there are around 4 billion public IPv4 addresses.  They believe that they are relatively safe because they are a needle in the haystack (security by obscurity). They are confident that no one will stumble onto their public IP, recognize the services running, have knowledge of its vulnerability and have the skills to execute the attack. When taking this view, it seems to make sense to assume that they are relatively safe, but that is not the order that these attacks happen in.

I reality, the path for an attacker to exploited systems is very different. A more common workflow would be that an exploit/vulnerability is discovered, often resulting in a CVE (Common Vulnerabilities and Exposures) being issued.  Scripts are then written to take advantage of these vulnerabilities. The attacker obtains a copy of the scripts and then goes hunting on the internet to find victims to run it against. Of course, there are many variations to this process, but the main idea here is that it the odds of you being attacked at far greater than what the “needle in a haystack” mentality would suggest.

To put this into context, let’s walk through a real-world example of how this process might look. We will start with an older CVE, in this case CVE-2009-1535, which as its numbering suggest is almost 10 years old. This CVE references a vulnerability in “the WebDAV extension in Microsoft Internet Information Services (IIS) 5.1 and 6.0 which allows remote attackers to bypass URI-based protection mechanisms, and list folders or read, create, or modify files”

Now that we know a vulnerability exists, the next step would be to create a tool/script to aid in the execution of it.  We could spend hours crafting our own tool based on the information contained in the CVE and or working knowledge of the target (IIS 6.0), however, the hacker community is constantly writing proof of concept code for these vulnerabilities. For this example, we can simply go and download a verified working Perl script to carry out the attack. This shows that the attacker does not need to have the necessary skill sets or time needed to create the tools to successfully exploit the vulnerability.

At this point we have the what have the “what” and the “how”, but we still need the “who” (the target).  Will billions of IPs on the net, what our chances of randomly finding a web server in 2018 still running IIS 6.0? On our own, the odds are not good. They make the needed in haystack analogy seem plausible, however, with a little help it is actually very easy.

One possible tool that we can use to quickly find our targets is “Shodan is a search engine that lets the user find specific types of computers connected to the internet using a variety of filters. Some have also described it as a search engine of service banners, which are metadata that the server sends back to the client” –

Using a free account, we look for servers running Microsoft IIS 6.0 located in the United States by entering Server: Microsoft-IIS/6.0 country:”US” as our search query.

This should return around 250000 targets, which is still a decent sized haystack, but since we also know that this CVE was issued in 2009 we can narrow down our possible targets even more by looking for those that have not been modified since 2008. To do this we simply add “Last-Modified:”2008“” to our search. This drops our target account way down to only 3500 targets.

Adding the last modified date to the search also limits the results to those whose last change was in that year. To find potentially older targets you will need to search each additional year separately.

Granted in the above example, it is possible to have a patched IIS 6.0 server whose web content has not been updated pre-2009, just as it is possible to have newer content on a system that is not patched. There are also many other reasons why you should not have EOL (end of life) services exposed, but I’ll touch on those in some other post.

As you can now clearly see, security by obscurity doesn’t exist. You will not be a target because of what you have, but rather what you have exposed.  Please take the necessary time to evaluate your systems, make sure they are patched and that you do not have any unnecessary assets exposed. You can also use Shodan to check your public IP address to see what information you are exposing.