Cloud Security
Published in

Cloud Security

Exponential increases in cyber risk from Internet exposure

How many of your systems are exposed?

In my last blog post, I explained how network traffic got me into cybersecurity. That story helps set the stage for the next in my list of questions for executives to ask security teams: What is the percentage of our systems exposed to the Internet?

If you think about how breaches occur there is almost always some sort of Internet exposure involved. It makes sense then, that reducing Internet exposure reduces risk. Notice that I didn’t say eliminated! Of course a reduction in Internet exposure doesn’t completely stop data breaches, but systems unnecessarily exposed to anyone on the Internet increases the number of ways an attacker can get into your systems. The more chances they have to break in, the more the odds are in their favor. That’s just math. It may not stop the advanced persistent nation-state attacker, but it will remove some options. It will also help limit the spread of automated malware and attacks by script kiddies — people who tack together other people’s code to attack systems that expose blatant vulnerabilities.

Recent trends in cybersecurity have at times suggested that network security is overrated in this day and age of cloud and all things connected. Of course, for things to work, you need to be able to connect. It’s true that things need to be able to communicate, but networks can still be constructed so things will work without introducing unnecessary risk of excessive exposure to the Internet. Creating secure and effective networks does require additional time and skill. Security is not free, but it will likely cost less than a data breach.

Click here to purchase a full copy or the ebook or paperback on Amazon: Cybersecurity for Executives in the Age of Cloud

One article I read suggested identity (verifying who people are and that they are authorized to access a system when they log in) is going to replace network security. Others claim endpoint security (security software you install on your computers like software that blocks viruses) is better or more important than traditional network monitoring and security controls. Those things are important, and there are reasons why you need to use them. However, I hope to demonstrate in these next few posts why network security is still one of the most important parts of a cyber defense strategy. In the end, it is not an either/or decision. You should use a defense in depth strategy — meaning you employ many controls that make it hard for attackers to get in.

You may have already gotten a sense of the importance of network security from my story in my last post. I talked about how I identified the breach using network logs. Limiting Internet exposure made it nearly impossible for the malware to function on my server. Let’s explore this in more detail.

How a Typical Breach Works

There’s a common pattern used by most malware. The first step is to get onto your system. Typically some network traversal is involved. At some point the malware will then “call home” — meaning it makes a connection back to the attacker’s server to let them know they got a victim. Often the malware is designed to allow the attacker to send new commands to the compromised machine such as installing additional software or trying to find and attack other computers it can reach on connected networks.

The attacker’s machine that is controlling the victim computer or device is called a command and control server, or C2 server for short. That C2 server may be controlling one or many computers, network or IOT devices. The victim machines are called bots. A botnet consists of all the devices controlled by a particular attacker.

The Mirai botnet was one of the most infamous and largest networks of infected devices. It compromised 65,000 devices in the first 20 hours. At its peak, it reached about 600,000 devices. At one point it nearly took down the Internet. The malware spread fast because it was a worm, which means it used automated code to find an attack other computers it could reach on the network. This botnet was started by a college student at Rutgers and two of his friends. They owe $127,000 in damages and are serving 5 years of community service as a result. Others have gone to jail for similar cyber-mischief, so they are lucky.

Back when I started learning about cybersecurity, a botnet might have been as simple as a single C2 server or static group of servers. Over time security professionals figured out how to spot attackers on their network by looking for conspicuous traffic in network logs. Firewalls blocked known C2 server network addresses. Attackers got trickier and set up their botnets to connect to changing network addresses and domain names, with new types of malware like Fast Flux that continuously alter the domain name for a C2 server. They leverage other people’s servers to perform attacks and use specialized networks like TOR that make it hard to identify the actual source of the attack. That’s why attributing the attack to a specific entity is challenging and hacking back is not advised as I wrote in a prior post.

Here’s an example of malware that evaded detection by residing where people aren’t looking. Even if people look at the network traffic on their computer or internal network, they often do not inspect the traffic between that network device and their Internet service provider (the company that provides your Internet access). This point is where the VPNFilter malware inserted itself, infecting network devices that consumers use to connect to their Internet provider from manufacturers like Netgear, Linksys, TP-Link, and Mikrotik. A Russian hacking group called Fancy Bear was purportedly responsible for these infections. This malware would “sniff” network traffic, meaning it would inspect the network packets, looking for credentials and private information. Companies, law enforcement, and other organizations worked together in a coordinated effort to stop the spread of this potentially devastating malware.

If you think about how these attacks occur, it all starts with a device connected to the Internet. In many cases, a device must have a vulnerability that the attacker can use to install malware onto the device. I already explained how CVEs are used to infect systems. Software flaws were the root cause of the Equifax breach and Wannacry. However, the initial point of exposure for organizations affected in those breaches was a system exposed to the Internet. What if those systems were not accessible from the Internet and the attacker could not access them? Even if the CVE was unpatched, the systems could not be compromised it the attacker could not connect to the target machine.

Here’s another example showing how network security can help you when it comes to new threats. I talked about this in a presentation I gave at Microsoft Build with Tanya Janca (@SheHacksPurple). Confluence is the name of a product used by a lot of software teams to share information and document their work. The information in this system is almost always information that should only exist within a company, not on the Internet. Many people host this system via a cloud service exposed to the Internet. Developers log in over an encrypted connection. The problem is that when developers access Confluence via Internet, so can anyone else, and any newly discovered vulnerability could be used by anyone to attack the exposed server.

And that is what happened. Luckily it was by someone who let the companies know, not an actual attacker.

A security researcher was able to search for infected systems using Google. A tool called Google Dorks (otherwise known as the Google Hacking Database), uses this idea to help pentesters and attackers find all kinds of things exposed to the Internet that shouldn’t be like passwords and encryption keys. If the Confluence systems had been on private networks, Google wouldn’t be able to reach them and would not have added information about them to search engine results. The security researcher wouldn’t have been able to reach them. Instead, the systems were exposed and resulted in this blog post from Vignesh C., who goes by @pwn_r00t on Twitter, explaining how he hacked over 50 websites in 6 hours.

The New Perimeter

The first aspect of network security I want to explain is perimeter security. That’s right — old school, out of favor, forgotten security at the edge of your network. The perimeter means the edge of your network where it touches the Internet. It is what separates your systems from the rest of the Internet — all the other devices in the world owned by citizens, companies, governments, and hackers. Perimeter security used to be a firewall between your corporate systems in a data center or office building and the Internet. The firewall defined the rules for what would be allowed in and out of your network.

The difference now is that instead of all systems in buildings and on servers you own, the resources you connect to that host your data may be spread out in a distributed configuration on machines maintained by other companies. Your network is a different shape spawning many different locations instead of just one or few you own. You may not be able to put firewalls in other people’s data centers — but you still have a perimeter! If you plan and architect carefully, you can still limit access to systems hosting your data to your private network and disallow Internet access except where it is required.

Some of your systems may be in the public cloud on AWS, for example. People may be connecting from your corporate office to the cloud servers. But these distributed systems are still your systems which you can contain in a private network if you choose. Mechanisms exist for using all types of cloud solutions from a private network. I have a full day of networking in my cloud security class explaining how to do that and other important aspects of network security in the cloud. From an executive point of view, you may not need to know every detail about the network implementation, but you can measure the results — how much exposure you have to the Internet — with a simple network question: What is the percentage of our systems that are exposed directly to the Internet?

Why does any of this matter? Because every system you expose to the entire Internet is open for a malicious actor to attack. Within minutes of connecting a device to the Internet your traffic logs will show connections from devices around the world. These connections may be from attacker-controlled bots and owned by innocent victims that do not realize they are part of a botnet. All these devices are looking for your systems and try to attack them as soon as they are exposed.

Scan, Attack, and Infected Traffic

Attackers are constantly scanning the Internet for machines that are exposed. They try to find devices that expose services to the Internet — things like websites or remote administration capabilities. When they find something running, they can reach from the Internet they can try to attack and get into that system.

Right now there’s a very serious CVE affecting RDP (Remote Desktop Protocol) CVE, which allows administers to make connections to Windows machines from remote locations. As soon as the CVE became public, security researchers and attackers started publishing code online to use that flaw to break into systems. Pretty soon attackers will be scanning the Internet seeking machines exposing that CVE so they can attack them and use that flaw to break into networks.

Your options: Update all the systems running the RDP service (which is likely the majority of Windows machines out there) or block Internet access to that machine and the RDP application— ideally you want to do both, but you’ll need to act fast. A question I ask people when there’s a large-scale vulnerability announced that requires upgrading hundreds or thousands of systems: Is it faster and easier to update all your system software, or block Internet access for that specific flaw? The answer will depend on your environment. In some cases, it might be easier to ensure the RDP service is not accessible from the Internet while you work on patching all the systems.

Since scanning the Internet for exposed, vulnerable systems is one of the primary ways attackers find and initiate data breaches, a lot of security researchers do the same, trying to find machines that are exposed. They create websites and publish information about these systems in an effort to alert people to the problem. There are so many people doing this though that it creates a lot of unnecessary noise, traffic, and congestion on the Internet, so if you are thinking about doing this, please refrain. Use existing websites. Only scan the specific systems you own or have explicit permission to test.

Services like Shodan and will let you search for systems exposed to the Internet. Attackers can also find exposed applications without ever checking systems directly. You can go to Shodan yourself and find out what is open to the Internet on your network. It’s a good idea to review these sites periodically. Be aware that some cloud providers may be blocking the scanners used by these sites from reaching your systems, to protect you by not allowing them to expose that information. The most reliable source is still for you or a pentester to check your devices directly to prevent unnecessary Internet exposure.

Some Internet service providers are known for allowing any type of bad traffic sent by their customers. When I started in security, I blogged about all the bad traffic in my network logs. One of the companies that came up a repeatedly was Hurricane Electric. They are also in the book I mentioned in my last post, Spam Nation. If you monitor your network and check which companies are sending bad traffic your way, you may notice patterns like this where some companies allow a lot of suspicious traffic and websites to reside on their networks. I wrote before about how to determine the source network of Internet traffic. One company I’ve seen a lot in my logs lately is Digital Ocean. A person named Troy Mursch who goes by the handle @bad_packets on Twitter has tweeted about malware hosted on Digital Ocean repeatedly.

Just as in the question over what Facebook and Twitter should or should not allow on their social media platforms, these companies should probably take responsibility to stop blatantly malicious software sent over their networks when the affected party asks them to block it, or report it to law enforcement. This does get tricky however because people don’t want the Internet service providers arbitrarily blocking whatever they want. There is a debate going on about this referred to as Net Neutrality. In some cases, suspicious-looking traffic comes from legitimate security testing, but this testing should occur on private networks and only systems with prior permission.

Protocols, ports, and the exponential problem.

Let’s go a bit deeper with some very basic networking concepts. I’ll keep this as simple as possible.

Computers and devices on networks send data back and forth using protocols. A protocol is like a language. If one person only speaks Portuguese and another only speaks Swahili and they are trying to communicate that’s not going to work out so well. For two computers to communicate, they need to send data back and forth using the same protocol. A protocol is a defined set of rules about how the devices will communicate.

Some protocols communicate using ports. Think of a port like a door in a shopping center. There’s a door that lets you in and a door that lets you out. The doors need to be open in order for you to get or out. The ports on a network need to be open to let data in or out. If a network administrator doesn’t want traffic to go in or out they can close the ports, just like a shopping center could close their doors.

There are 65,535 possible ports software can use to make network connections on a device like a computer or Internet-connected camera. Each port has a number starting with 1. Some ports are usually associated with a particular type of application. As I mentioned in my last blog post, port 25 is typically associated with sending email. Every port that is running software exposed to the Internet is a potential target because more than likely a flaw will be discovered in that software eventually. Attackers are running botnets of hundreds of thousands of infected hosts they can use to scan or attack your Internet-connected systems and ports.

Systems X Ports X CVEs X Attackers = lots of possibilities.

Therein lies the exponential problem. Multiply the number of Internet-accessible ports by all the attackers and their malware infested devices. Maybe even multiple that by all the different types of potentially vulnerable types of software on each Internet accessible machine. An operating system, web server software, and specific components of an application running on that web server may all have a CVE at some point. Take one of those variables out of the equation and reduce your risk. As mentioned in the last post eliminating CVEs is one way to decrease risk. Limiting ports exposed to the Internet is another. The more systems you can remove from direct Internet exposure and the more ports you can close, the more your risk is reduced.

Now that you know what ports are, you could look at the percentage of ports and protocols open to the Internet, as well as systems in general. Of course, some things need to be exposed for systems to function, like a public website that needs to expose port 80 and port 443, but the way applications and networks are architected can limit that exposure. You can access well-designed cloud systems from private networks. If you can’t, you might question whether you want to use that vendor or not for highly sensitive data. You can also put protections in front of your Internet exposed systems and software. Get the percentage over time of what is open to the Internet and try to reduce that percentage to decrease the overall risk.

As noted in my blog post on cybersecurity strategy, making systems generate meaningful reports automatically will help drive the creation and purchase of security systems that are effectively solving business problems. It might be hard to measure your Internet exposure right now, depending on your environment, but look for solutions that help make this possible. If you are running applications on AWS, for example, you can run queries to generate reports with this information fairly quickly. Some third-party solutions may do it for you now — or soon if you ask! In a traditional office or data center look for tools that help you measure Internet exposure. Then try to drive that number down.

Teri Radichel — Follow me: @teriradichel

© 2nd Sight Lab 2020


Want to learn more about Cloud Security?

Check out: Cybersecurity for Executives in the Age of Cloud.

Cloud Penetration Testing and Security Assessments

Are your cloud accounts and applications secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Cloud Security Training

Virtual training available for a minimum of 10 students at a single organization. Curriculum: 2nd Sight Lab cloud Security Training

Have a Cybersecurity or Cloud Security Question?

Ask Teri Radichel by scheduling a call with IANS Research.


2020 Cybersecurity and Cloud Security Podcasts

Cybersecurity for Executives in the Age of Cloud with Teri Radichel

Teri Radichel on Bring Your Own Security Podcast

Understanding What Cloud Security Means with Teri Radichel on The Secure Developer Podcast

2020 Cybersecurity and Cloud Security Conference Presentations

RSA 2020 ~ Serverless Attack Vectors

AWS Women in Tech Day 2020

Serverless Days Hamburg

Prior Podcasts and Presentations

RSA 2018 ~ Red Team vs. Blue Team on AWS with Kolby Allen

AWS re:Invent 2018 ~ RedTeam vs. Blue Team on AWS with Kolby Allen

Microsoft Build 2019 ~ DIY Security Assessment with SheHacksPurple

AWS re:Invent and AWS re:Inforce 2019 ~ Are you ready for a Cloud Pentest?

Masters of Data ~ Sumo Logic Podcast

Azure for Auditors ~ Presented to Seattle ISACA and IIA

OWASP AppSec Day 2019 — Melbourne, Australia

Bienvenue au congrès ISACA Québec 2019 KeynoteQuebec, Canada (October 7–9)

Cloud Security and Cybersecurity Presentations

White Papers and Research Reports

Securing Serverless: What’s Different? What’s Not?

Create a Simple Fuzzer for Rest APIs

Improve Detection and Prevention of DOM XSS

Balancing Security and Innovation with Event-Driven Automation

Critical Controls that Could have Prevented the Target Breach

Packet Capture on AWS




Cybersecurity in a Cloudy World

Recommended from Medium

China Implicated in Prolonged Supply Chain Attack Targeting Taiwan Financial Sector

7 Online Scams you Must Know

What Do You Need to Stream?

#LearnWeb3 with @thedapplist

The 1inch dApp added to Ledger Live

The 1inch dApp added to Ledger Live

What is SOC 2?

OSINT — Sakura (TryHackMe walktrough)

DC-4 : Vulnhub Walkthrough

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Teri Radichel

Teri Radichel

Cloud Security Training and Penetration Testing | GSE, GSEC, GCIH, GCIA, GCPM, GCCC, GREM, GPEN, GXPN | AWS Hero | Infragard | IANS Faculty |

More from Medium

[Some Interesting] Cloud ‘n Sec news: 29th Apr 22

10 Rules for Better Cloud Security

Light Roast 110: Intro to DNS Attack Types

Cyber Security in The Times of Remote Working