Securing and hardening Linux and Unix endpoints against cyberattack: Part III

How Secure are your Linux Endpoints? An Ethical Hacker’s Guide to Securing and Hardening Linux and Unix Endpoints

Welcome to the next post in our series on hardening and protecting endpoints. In Part I, Hardening Endpoints Against Cyberattack, we covered these important steps to an ethical hack in the preparation and Open Source Intelligence gathering stages:

• Step 0: Pre-Engagement
• Step 1: Passive Recon and OSINT
• Step 2: Active Recon on Windows Endpoints

In this post, I’ll focus on Linux and Unix endpoints, and I’ll cover the Active Recon stage again as results will differ when creating your attack path.

These are the steps to an ethical hack of Linux and Unix endpoints:

Step 1 was covered in Part I of the series

Step 2: Active Recon on Unix and Linux Endpoints

Step 3: Linux Service Enumeration

In our final post, we will cover the final step:

Step 4: Access Exploitation and the Initial Foothold

Again, if you’re interested in the planning, prep, and intelligence stages of an attack (both Windows and Linux), read: Hardening Endpoints Against Cyberattack: Part I

Or, find out how to secure and harden Windows endpoints here: Hardening Windows Endpoints Against Cyberattack: Part II

So, why would I cover Linux and Unix endpoints when most of the world’s desktop endpoints are running Windows?  When I refer to endpoints, I mean all types of endpoints including laptops, desktops, and servers. Linux and Unix have a major role in the world’s computing systems and cloud. Attackers will attempt to gain access into your organization via the easiest path, and that could be either Windows or *nix (notation for both Linux and Unix) endpoints. Therefore, a strong security strategy is one that covers all the possibilities. I’m going to focus on the Linux flavor, however many of these techniques also apply to other *nix OSes.

Operating system (OS) options today are more diverse than they were 10 or 15 years ago. Since the explosion in mobile, tablets, Internet of Things (IoT), and cloud, most systems are based on the Linux and Unix family of operating systems, and of course Apple. Apple runs Mac OS which comes from the Unix family of OSs. You might not see Linux in the foreground, however, you’ll interact with Linux systems almost daily. If you drive a Tesla the in-car entertainment system is based on Linux, your smartphone might be running Android, in-flight entertainment systems most often run Linux, your home router likely enables you to connect to the internet using a Linux system, and when you shop online most of the websites you visit will be hosted on Linux Servers.

Let’s look at some statistics for Linux:

• 29 years old, and created by Linus Torvalds
• Used on only about 2% of desktops
• Runs most of the world’s supercomputers
• Almost all the world’s top domains are powered by Linux
• 85% of all smartphones are based on Linux
• Used for many Internet of Things, such as home automation, security cameras, and entertainment systems

And of course, NASA’s Ingenuity Mars Helicopter is running Linux.  So yes, Linux is flying around Mars.

When it comes to cyberattacks, there are many risks that keep security leaders up at night. To reduce your risk of attack, you must think like an attacker. Understand the techniques they use and implement the appropriate best practices.

Whether you’re running Windows, Linux, Unix, or Mac OS, attackers will find the weakest link in your cybersecurity defenses. It’s important to know the risks of all the operating systems and applications running in your environment.

What are the most common causes of security incidents and data breaches?

Which of the following causes of security incidents are most likely to occur in your environment, and which already have?  Know which security controls you already have in place, and determine which have room for improvement.

Let’s take a journey through the mind of an Ethical Hacker and learn how to exploit Linux and Unix endpoints, and what you can do to improve endpoint protection and reduce your risks.

We covered the planning, preparation, and intelligence stages of an attack in Part I, so now we’ll cover the active reconnaissance step for Linux and Unix.

For the examples and demonstration portion of this post, I’ll be using Hack The Box which is an awesome online platform that enables you to test and advance your skills in cybersecurity. The machine I’m going to be using in this example is SolidState, which is a Linux system with a medium difficulty level. If you have a Hack the Box subscription you can follow along using this as a guide.

The Full Port Scan—may take some time to run. Don’t forget UDP ports

Other common alternatives I use, depending on the type of scan

Linux Port Enumeration Summary and Observations

From the initial scanning and port enumeration on the examples above we can determine the following summary:

What do we know so far?

1. It is a Linux operating system
2. TtL at 63 confirms it is Linux

TtL is known as the Time to Live which is how long it will remain cached for when resolved.  Different TtL results will help indicate which type of operating system is responding.

3. Hostname is SolidState
4. Web Header Apache/2.4.25 (Debian) which indicates Debian is the most likely Linux variant
5. Endpoint is running Apache James Server 2.3.2

Port Summary

• Port 22 – OpenSSH 7.4p1 Debian 10+deb9u1 (protocol 2.0)
• Port 25 – JAMES smtpd 2.3.2
• Port 80 – Apache httpd 2.4.25
• Port 110 – JAMES pop3d 2.3.2
• Port 119 – JAMES nntpd
• Port 4555 – JAMES Remote Admin 2.3.2

This information gives us a few possible areas of risk on the Linux Endpoint. The endpoint is running a web server which might mean potentially misconfigured websites that could allow checking for the OWASP Top 10. It’s running an older version of Apache James Server which could lead to an application vulnerability.  Apache James is an Enterprise mail server, so this Linux endpoint is likely providing an email service.

Guide to Strengthen Your Ports and Doors

TIP# 1: Patch and update your Endpoints. Focus on Remote Code Execution or High-Risk CVEs to prioritize which patches to apply first.

Tip #2: Uninstall or disable unused applications or ports that you do not need or currently use. The fewer applications and services running on the Linux Endpoints the fewer possible options for the attacker to target. And the fewer ports and doors to look through, the more difficult it is for the attacker and the more risks they will have to take, thereby increasing the possibility of the attack being discovered.

Tip #3: Use strong authentication for remote access, such as strong passphrases, multifactor authentication, and privileged access security.  Never let a password be the only security between the attacker and your endpoints.

Tip 4#: Know what ports are running and listen for connections in your environment. Actively scan and understand the risks of each. Think like a cybercriminal so you see what they see.

From the response, it shows the version Apache/2.4.25 (Debian)which again confirms this is a Linux endpoint running Debian. The response is also typical of a company web page which can be shown below.

Use Netcat to grab the banner of each port to check what’s running and the versions of software. This is a good way to double-check what you have returned from the Nmap scan.

-n = numeric results only, no DNS
-v = verbose, add another v to increase the verbosity.

Some of the most used service enumeration tools:

• rpcclient – tool for executing client-side MS-RPC functions
• netcat – powerful network utility
• nbtscan – scan NetBIOS to find open shares
• smbclient – client to talk to SMB / CIFS servers
• Metasploit – Penetration Testing Framework
• WFUZZ – Web Application Fuzzer
• DIRB – Web Content Scanner
• DirBuster – Web Application Directory Brute Force
• GOBUSTER – Web Object Scanner
• NIKTO – Web Vulnerability Scanner

Running DirBuster will help discover any hidden administration pages or directories not listed. Also, check the robots.txt in the root of the webserver for any nuggets.

Unfortunately, running DirBuster did not find any interesting results that could lead to an exploit.

Exploitation Research—Choosing the Attack Path

Once you’ve created a digital blueprint of the target and environment, determine which Attack Path to take. I have my own algorithms and methods I use to determine the best possible options based on the following:

• Do No Harm
• The Speed
• Stealthy Options
• Resources
• Time
• Cost
• Availability

Based on the information you’ve gathered, start researching the possible exploits along with attack paths to the target or goal.

Some of the tools used during this process are:

• Google-Fu
• exploit-db
• Common Vulnerabilities and Exposures (CVE®)
• SearchSploit
• MITRE ATT&CK^®

I will use SearchSploit to identify any known vulnerabilities for Apache James Server 2.3.2

Some common command options I use with SearchSploit are:

-e = perform an exact match

-m = mirror or copy the exploit to the current working directory

-u = check and update the db

-p = copy the path to the exploit to the clipboard

The results from SearchSploit show strong possibilities with an exact match on version 2.3.2 for a Remote Command Execution exploit.

This will enable me to determine my path to the initial access, such as:

• Exploiting Public-Facing Hardware, OS, or Applications
• Phishing
• USB Drops
• Supply Chain and 3^rd Parties
• Weak or Default Credentials
• Through WiFi – Check out this blog: A look behind the scenes of a Wi-Fi Hack: What are the secrets?

We’re going to try and take advantage of the Remote Command Execution Exploit discovered using Searchsploit which will use option 1 above by exploiting an application.

We will use the -m option to mirror the exploit to the local directory:

SearchSploit -m linux/remote/35513.py

First, let’s check the exploit to see what it’s going to perform and how it exploits Apache James Server.

It’s important to understand what exactly the exploit will do, and always do the following before ever running these in your environment:

• Review the exploit and understand how it works
• If shellcode is being used, reverse it to ensure it does not run any malicious activity
• Create your own payloads
• Test it and test it again in an isolated environment to make sure it works as expected
• Change any parameters such as IP, ports, or credentials
• Always reverse the changes you make

How to reduce your attack surface

TIP #1: Run Vulnerability Scans to find misconfigured applications, systems, or unpatched software.  Running periodic scans will help you discover systems the attacker could potentially target for initial access.  Integrate your vulnerability scanner into a Privileged Access Management solution. This will ensure the scan will have the valid credentials to scan systems fully so you get a clearer view of your attack surface.

TIP #2: Patch and Update your Linux endpoints and applications regularly. Remove unused software and get rid of your legacy operating systems and applications.  If you cannot get rid of legacy systems, then put strong locks around them via network access and privileged access controls to limit access to them.

TIP #3: NO WEAK PASSWORDS. Get your employees into the habit of using a password manager, and for business use, a Privileged Access Management solution, so you eliminate default credentials.  Reduce one of the biggest causes of cyber fatigue by automating password rotation, reducing complexity, and integrating SSO and MFA.

TIP #4:  Implement strong Access Controls for Supply Chain and 3^rd Parties.  Adopt the principle of least privilege and take a zero-trust approach to your 3^rd party access policy.  Force 3^rd parties to access via a PAM solution so you know who has been given access, what they’ve been given access to, and why—before they are permitted access.