SBN

Securing and Hardening Linux and Unix Endpoints Against Cyber Attack: Part III

This post is part of a series on securing your endpoints against cyber attacks.
Read: Part I | Part II | Part III | Part IV Coming Soon

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 Cyber Attack, 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 Cyber Attack: Part I

Or, find out how to secure and harden Windows endpoints here: Hardening Windows Endpoints Against Cyber Attack: 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.

Web Sites and Cloud run Linux
Web Sites and Cloud run Linux

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

Linux in Helicopter on Mars
Source https://mars.nasa.gov

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.

What keeps security leaders up at night?

Whether you’re running Windows, Linux, Unix, or Mac OS, attackers will find the weakest link in your cyber security 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.

Common Breach Causes

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 cyber security. 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.

Step 2: Active Reconnaissance – Knocking on the Linux Ports and Doors

I call this active reconnaissance step “knocking on ports to see what you can find”. The ports could be public-facing servers, applications, web servers or *nix endpoints.  This is the first stage in which you are potentially increasing the likelihood of the security team uncovering your activities.

There are many ways to gain a foothold after active reconnaissance, such as finding a vulnerability or misconfiguration on a web server or application. Perform thorough reconnaissance to determine all your options and identify the stealthiest. If you run into a barrier, pivot your attack path—if you’ve done detailed reconnaissance you should have several other attack paths to use.

Scanning and Port Enumeration phase

Now that you have a scope of the endpoints, let’s knock on the Linux ports to see what security risks we find.

One of the most popular scanning and port enumeration tools is nmap (aka Network Mapper), a free open-source utility for scanning, network discovery, and security auditing. In most pen tests it’s my go-to tool for auditing and getting visibility of the network. My nmap guide helps me figure out how to get the right scan and stay stealthy.

Below are a few examples of the default scanning and port enumeration options I use. I start with the quick and easy then gradually move to the slow and detailed. Most often, I start with a very stealthy scan.

The Quick Port Scan—not so stealthy these days

Quick Post Scan
Top Open Port Scan on Target
Top Open Port Scan on Target

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

Full Port Scan

Full Port Scan on Target

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

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.

ttl table
  1. Hostname is SolidState
  2. Web Header Apache/2.4.25 (Debian) which indicates Debian is the most likely Linux variant
  3. 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 listening for connections in your environment. Actively scan and understand the risks of each. Think like a hacker so you see what they see.

Step 3: Linux Service Enumeration—Asking the Right Questions

The next phase is to validate and enumerate the versions of software. I call this “asking the right questions”. Now that I know roughly what’s running on the endpoint, I want to confirm it and then see if there’s anything that might reveal an initial foothold I can exploit. The first port to check is port 80, the Apache webserver.

To do this, I run curl against the IP address:

-i = include the protocol response in the header

Include the protocol response in the header

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.

Apache Web Page for SolidState

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.

IP Port

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

Using netcat to grab banner

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.

Running DirBuster against Web Server
Running DirBuster against Web Server

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:

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

Running SearchSploit for JAMES keyword
Running SearchSploit for JAMES keyword

Some common command options I use with SearchSploit are:

-e = perform 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 the version 2.3.2 for a Remote Command Execution exploit.

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

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

SearchSploit

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

SearchSploit

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 shell code 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 3rd Parties.  Adopt the principle of least privilege and take a zero-trust approach to your 3rd party access policy.  Force 3rd 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.

Coming soon: Part IV of this blog series on March 25!

Don’t leave Unix out of
your PAM strategy

Start with the FREE Unix Privileged
Account Discovery Tool

*** This is a Security Bloggers Network syndicated blog from Thycotic authored by Joseph Carson. Read the original post at: https://thycotic.com/company/blog/2021/03/23/securing-unix-linux-endpoints-against-cyber-attacks-part-3/