High-risk ports: The chink in your network armor
A risk-based approach to cybersecurity
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Cybersecurity for Executives
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Security is principally about managing risk. The more commonly exploited and dangerous ports you have exposed to the Internet, the greater your risk because the attacker will have more chances to try to execute a cyber attack. This observation brings me to the next part of my cybersecurity question related to network exposure: How many systems expose administrative access and high-risk ports to the Internet? This is part of my online book: Cybersecurity for Executives.
It is also one of my posts on Network Security.
If you’ve read the books or seen the Lord of the Rings movie you may remember how Bilbo Baggins snuck into the lair of Smaug, the dragon. He discovered one bare, unprotected spot in the dragon’s underbelly. He told others what he saw, and that weakness was eventually used by Bard to slay the dragon. That small bare patch in the dragon’s protective armor is like the administrative port left open on your network. That one hole can provide enough access to take down your organization if it gives access to install malware or take over systems.
What is an Administrative Access?
Administrative access means a user on your systems that can change things that most other people are not allowed to change. It’s an elevated level of access that poses a higher risk if the credentials are abused or stolen. For example, network administrators can open and close firewall ports. Opening ports can leave holes that let attackers in your network and data out. A database administrator can typically access all your data in the database and change permissions to give other people access. Application and operating system administrators may be able to grant access, install software, and change configurations.
The permissions and actions allowed by administrative accounts pose a serious threat if obtained by attackers. If an attacker gets access to do that they can install any malware they want on your system like ransomware, cryptominers, or malware that steals secrets and data. In a recent SANS survey, customers stated that stolen credentials are almost always involved in cloud incidents. I’ll write more about credentials later, but one thing you can do is make it harder for attackers to use these credentials, even if they have them, by ensuring the access to use them is not exposed to the entire Internet.
Often that administrative access is obtained and abused by attackers and gives them elevated privileges on your systems and network. Potentially they get enough access to grant themselves permissions to additional resources and data or create new resources in cloud environments. They may insert code into existing systems, as was the case in the Target Breach. Attackers infiltrated the system and accessed a tool used to install software on the point of sale (POS) systems. Leveraging that tool, they were able to quickly deploy the credit card scraping malware to multiple retail store systems. If attackers get administrative access in your environment, you may be in serious trouble.
Remote Administrative Access
Many times, administrators log into systems remotely. They don’t have a computer monitor connected directly to the network equipment, database server, or web server. They will create a connection to the server using some software that allows them to log in from a different location. That’s very handy for your administrators. They don’t have to drive to the data center. They can work from home. You might even have teams or vendors logging into your systems from different parts of the world from changing network addresses.
In cloud environments like AWS, Azure, or Google Cloud Platform, it is the only way to administer servers. In the cloud, the servers are virtual — meaning they are versions of servers entirely created by software instead of a single piece of hardware for each server. Multiple virtual machines (VMs) can run on one physical hardware server. The only way to access them is to log in over a remote connection since the cloud provider is not going to let you log in to the operating system on a physical server itself (called a hypervisor) because it hosts many different customers’ virtual machines.
Even if your security or IT team tells you that your network is completely locked down, your network administrators, database administrators, or developers may think or argue that they need high-risk ports open to the Internet remotely fix problems in systems. They do need remote access in many cases. However, administrators can set up remote access in a manner that limits who can get to the login screen to use these credentials. The network access can be architected with multiple layers of defense, as discussed previously, to make it harder for attackers to get to these login screens or use these credentials, even if they have access to them.
Backdoors
Administrators sometimes need remote access for legitimate reasons — administering services and responding to incidents that are causing business problems. In many cases, remote connections are allowed and provided by network and security teams in an authorized manner. In other cases, a person or company might try to add a way to connect remotely without telling anybody. This secret access is called a backdoor. It is a way to get into a system that is not known or intended in the approved implementation of networks and software. The main point when deciding if something is or is not a backdoor is whether or not it is unauthorized access.
In some cases backdoors are intentional. An administrator left a service running and created credentials to get into a system at a later time. An administrator could be just trying to make their job easier. In other cases, an individual has a more nefarious purpose, such as stealing data or harming the organization after they leave the company. Many reports exist that expose backdoors in vendor products. Here it becomes tricky — was the backdoor intentional, or was it an accidental inclusion of code with a vulnerability, or credentials left over from testing. It is challenging, if not impossible, to know what the actual motivation was behind the publicly exposed back door in a vendor product. The important thing is to patch these problems quickly. For more on vulnerabilities and patching read: CVEs: Security Bugs that Bite.
Common Administrative Services and Ports
Here are some common types of software that are used to login to systems remotely to perform administrative actions. Refer back to my last blog post if you aren’t familiar with network ports.
RDP: On Windows administrators log into remote systems using RDP, otherwise known as Remote Desktop Protocol. Microsoft built RDP into Windows. It runs on port 3389. You can turn this service off on Windows systems if it is not required. When you log into a Windows machine remotely, you’ll need to put in a user name and password just as you would if you were sitting at the computer. The information sent between the administrator machine and the remote server is encrypted as it travels over the Internet. As noted in my last blog post a recent CVE in the RDP protocol exists and Microsoft says over a million machines may be susceptible to this flaw, dubbed BlueKeep. This type of problem can happen to any remote access protocol, so preventing exposure to the Internet can help in these cases. Unfortunately, if you search in Shodan, you’ll see that many Windows hosts are, in fact, accessible directly from the Internet.
SSH: On Linux, port 22 is used to allow administrators to log in via a service called SSH, which stands for Secure Shell. Like RDP, this protocol encrypts data sent between the remote administrator and server as it traverses the Internet. SSH, when configured correctly, will also require some form of credentials (user name and password or something called an SSH key) to connect to the remote server. An SSH key is simply a long string of characters in a text file. Think of it as a super-long password. Although the password is very long, there are many attackers out there trying to guess these passwords, and they have proven to be successful, sometimes in a matter of hours. If the service is exposed to the Internet and the attacker can guess the password, they can get into the system and do anything those credentials are allowed to do.
Telnet: You might have heard of something called telnet if you read an article about the Chinese company Huwaei potentially leaving backdoors in telecommunications equipment delivered to Italy. The story was originally published by Bloomberg and later largely dismissed by the security and IT community. Telnet alone, as originally designed, is not encrypted over the Internet. That means when you connect to a remote server using telnet, anyone who can intercept the traffic (which is not hard with a bit of technical training) can read the information going back and forth. Additionally, telnet does not check to see when someone tries to connect if they are authorized. It lets anyone connect. That’s why security experts say telnet is not secure. You should stop the telnet service and close port 23 used by this service.
Side note: After publishing multiple suspect stories, Bloomberg cybersecurity reporting has been called into question by a lot of security people via comments on Twitter. That doesn’t mean telnet is ok and backdoors don’t exist. It just means that Bloomberg appears to have been making unsubstantiated claims in some peoples’ opinions. When news articles make claims, always try to find multiple sources before coming to conclusions on the latest cyber-drama. I like to wait a couple of days before forming an opinion in most cases.
Database Administration: Any type of database typically has an administrative port. For example a Microsoft SQL Server database provides administrative access on port 1433 and a MySQL database provides access on 3306. Any type of database will have a port that someone can connect to in order to perform administrative access on the database and those should never be exposed to the Internet. More on data exposed to the Internet and the resulting data breaches in an upcoming post.
Other high-risk ports
The following services are other high-risk ports I want to mention because they are the underlying cause of numerous attacks and ensuring these ports are not available on the Internet may help prevent some top reported threats.
SMB: SMB stands for Server Message Block. This protocol is used for more than administrative access. It is used to connect Windows systems, printers, and file shares. However, SMB has some capabilities which have been long known to be a source of malware when these ports are exposed to the Internet. In fact this was the underlying protocol that was used in the EternalBlue exploit originally developed by the NSA, and was stolen and later released to the world by a group called the Shadow Brokers in 2017. That exploit was the basis for WannaCry and many other types of malware still haunting companies to this day. SMB runs on port 445. Although some internal networks and systems require SMB, attackers should not be able to access this port from the Internet.
Netbios. An older protocol similar to SMB that runs on Windows named Netbios runs on Ports 137–139. These ports also should never be exposed to the Internet as they have been the source of numerous exploits. If you don’t need this service (and many organizations don’t if systems are up to date), shut this service off completely on all systems.
A risk-based approach to locking down your network
Although I’m telling you some of the most problematic administrative and high-risk ports, many others exist that, if exposed to the Internet, could cause similar problems. Additionally, the services above can be reconfigured to run on different ports, so for example SSH could run on port 5000 if an administrator configured it to do so. That’s why it’s critical to have well-trained security and network staff that know how to find and lock down all these ports and anything related correctly. The security team should be able to understand what services are using every open port on your network, why it’s there, and whether or not it is required.
Locking down your entire network, as suggested in my last blog post, will be much simpler in a small company and exponentially harder in a complex enterprise environment. If you need a place to start, start with the administrative and high-risk ports mentioned above and get those locked down. This risk-based approach and is a common strategy in cybersecurity, where the to-do list is longer than the people supporting the organization can reasonably address. Start with these things that are most likely to occur and may cause the most damage. This risk-based approach helps you prioritize and eliminate the highest risks in your environment first.
Locking down administrative ports
To lock down administrative ports but still provide access where needed, companies can do a few different things. One strategy would be only allowing people to access these systems when they are in the office. This approach works for some protocols like SMB. It would also work if a person is in the office or logging into a system in a data center via a private connection, meaning access is only possible from company networks, not the entire Internet.
The problem is that now administrators are working remotely and traveling and need access from wherever they are located. In this case, a different strategy is required because you aren’t going to have a private connection from the local coffee shop to your data center (unless you are Starbucks, perhaps!) For these use cases, you need a way to protect your remote administration services but still allow people to connect from the Internet. You can do that with a VPN (Virtual Private Network), as I wrote about in another blog post.
A Virtual Private Network will protect the traffic as it traverses the Internet by enclosing it in an encrypted tunnel. Information about the systems to which an administrator is connecting and their credentials are less exposed. The devices that provide the VPN connection may still face exposure to the Internet, but people who understand networking and security can manage these points of access and monitored them closely. Then all the other administrative accounts people are creating and logging into are not directly accessible from the Internet and pose less risk. This doesn’t eliminate every attack that involves administrative credentials, but it does reduce a significant amount of risk.
An even better option would be to allow administrative access only it when it is required. An administrator requests access to use a remote administration service, and the systems open the port while they are working to the specific address from which the administrator is connecting. After the administrator is finished working, the port is closed once again. I wrote a blog post about opening up the network on AWS to administer servers only while it was required. Microsoft now offers a similar feature that allows just-in-time access to Azure virtual machines. I am hoping for more services like this from other cloud and network device vendors soon.
Locking down cloud administration
Part of locking down cloud administration has to do with user names and passwords, which will be the topic of a separate blog post. However, you can also lock down network access to many cloud consoles where people log in to use these services. I talk about different ways to do this in my cloud security class. You may want to ensure there is a way to do this for any cloud providers with whom you choose to do business.
When considering cloud administration, remember to protect all types of access, not just the website where people log in to take actions. Cloud services often allow developers to connect to make programmatic changes using a mechanism called APIs (Application Programming Interfaces). These automated means of connection enable systems to take actions on each other via programming code, instead of humans typing in a web form and clicking buttons.
Another common type of tool allows administrators to write commands on the machine they are directly using. Those commands are then sent over the network to make changes in remote systems. These tools are often called a CLI (Command Line Interface). These types of connections will also access a specific port and Internet address and should also be protected from the full Internet access when possible, especially for highly sensitive data and when using administrative credentials.
High-Risk Network Port Lockdown
Now you understand that the administrative access to your network is one of the highest-risks and best places to start locking down your network. Additionally, be aware of the ports malware commonly uses to access systems and try to ensure those are not accessible from the Internet. Given that so many companies are falling victim to breaches due to these common problems, it’s an excellent place to start reducing your overall risk. You can work with your security team to prioritize which ports you want to see in a cyber risk report as high-risk items as there may be others, depending on your business and what systems you use.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2019
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
