Chapter 13
In This Chapter
Examining Linux hacking tools
Port scanning Linux hosts
Gleaning Linux information without logging in
Exploiting common vulnerabilities when logged in to Linux
Minimizing Linux security risks
Linux hasn’t made inroads onto the enterprise desktop the way that Windows has, but Linux still has its presence in practically every network nonetheless. A common misconception is that Linux is more secure than Windows. However, more and more, Linux and its sister variants of UNIX are prone to some of the same types of security vulnerabilities, so you can’t let your guard down.
Hackers are attacking Linux in droves because of its popularity and growing usage in today’s network environment. Because some versions of Linux are free — in the sense that you don’t have to pay for the base operating system — many organizations are installing Linux for their web servers and e-mail servers in hopes of saving money and having a more secure system. Linux has grown in popularity for other reasons as well, including the following:
In my own security assessment work, I’m not seeing many glaring Chrome OS-based vulnerabilities (yet), but I am seeing weaknesses in Mac OS X, especially as it involves third-party software that can be exploited by malware and even tools such as Metasploit. I see such flaws more often when performing authenticated scans so make sure you’re doing those as well.
Based on what I see in my work, Linux is less vulnerable to common security flaws — especially as it relates to missing third-party patches for Adobe, Java, and the like — than Windows. When comparing any current distribution of Linux, such as Ubuntu and Red Hat/Fedora, with Windows 7 or Windows 10, I tend to find more weaknesses in the Windows systems. Chalk it up to widespread use, more features, or uneducated users, but there seems to be a lot more that can happen in a Windows environment. That said, Linux is certainly not flawless. In addition to the password attacks I cover in Chapter 8, certain remote and local attacks are possible against Linux-based systems. In this chapter, I show you some security issues in the Linux operating system and outline some countermeasures to plug the holes so you can keep the bad guys out. Don’t let the title of this chapter fool you — a lot of this information applies to all flavors of UNIX.
Vulnerabilities and attacks against Linux are creating business risks in a growing number of organizations — especially e-commerce companies, network and IT/security vendors, and cloud service providers that rely on Linux for many of their systems, including their own products. When Linux systems are hacked, the victim organizations can experience the same side effects as their Windows-using counterparts, including:
You can use many Linux-based security tools to test your Linux systems. Some are much better than others. I often find that my Windows-based commercial tools do as good a job as any. My favorites are as follows:
www.kali.org
) toolset on a bootable DVD or .iso image filewww.gfi.com/products-and-solutions/network-security-solutions/gfi-languard
) for port scanning, OS enumeration, and vulnerability testingwww.netscantools.com
) for port scanning, OS enumeration, and much moreNexpose (www.rapid7.com/products/nexpose
) for detailed port scanning, OS enumeration, and vulnerability testing
A tool such as Nexpose can perform the majority of the security testing needed to find flaws in Linux. Another popular commercial alternative is offered by Qualys (www.qualys.com
).
https://nmap.org
) for OS fingerprinting and detailed port scanningwww.tenable.com/products/nessus-vulnerability-scanner
. for OS fingerprinting, port scanning, and vulnerability testingMany other Linux hacking and testing tools are available on such sites as SourceForge.net (http://sourceforge.net
) and freecode.com (http://freecode.com
). The key is to find a set of tools — preferably as few as possible — that can do the job that you need to do and that you feel comfortable working with.
You can scan your Linux-based systems and gather information from both outside (if the system is a publicly-accessible host) and inside your network. That way, you can see what the bad guys see from both directions.
Linux services — called daemons — are the programs that run on a system and serve up various services and applications for users.
The vulnerabilities inherent in your Linux systems depend on what services are running. You can perform basic port scans to glean information about what’s running.
The NetScanTools Pro results in Figure 13-1 show many potentially vulnerable services on this Linux system, including the confirmed services of SSH, HTTP, and HTTPS.
In addition to NetScanTools Pro, you can run another scanner, such as Nexpose, against the system to try to gather more information, including a server running SSL version 3 with weak encryption ciphers, as shown in Figure 13-2.
Keep in mind that you’re going to find the most vulnerabilities in Linux and Mac OS X by performing authenticated vulnerability scans. This is particularly important to do because it shows you what’s exploitable by users — or malware — on your systems. And, yes, even Linux and Mac OS X are susceptible to malware! You’ll want to run such scans at least once per year or after any major application or OS upgrades on your workstations and servers.
Figure 13-3 shows the absolutely amazing feature in Nexpose that allows you to actually test your login credentials before kicking off a vulnerability scan of your network.
What’s the big deal about this feature, you say? Well, first off, it can be a whole lot of hassle to think you’re entering the proper login credentials into the scanner only to find out hours later that the logins were not successful, which can invalidate the scan you ran. It can also be a threat to your budget (or wallet, if you work for yourself) if you’re charged by the scan only to discover that you have to re-scan hundreds, even thousands, of network hosts. I’ve been down that road many times and it’s a real pain, to say the least.
The Windows-based NetScanTools Pro also has the capability to determine the version of Linux that’s running, as shown in Figure 13-5.
Although you can’t completely prevent system scanning, you can still implement the following countermeasures to keep the bad guys from gleaning too much information about your systems and using it against you somehow:
http://sourceforge.net/projects/sentrytools
), a local agent such as Snare (www.intersectalliance.com/our-product/snare-agent
), or McAfee Host Intrusion Prevention for Server (www.mcafee.com/us/products/host-ips-for-server.aspx
) that ties into a larger security incident and event management (SIEM) system that monitors for and correlates network events, anomalies, and breaches.When you know which daemons and applications are running — such as FTP, telnet, and a web server — it’s nice to know exactly which versions are running so you can look up their associated vulnerabilities and decide whether to turn them off. The National Vulnerability Database site (http://nvd.nist.gov
) is a good resource for looking up vulnerabilities.
Several security tools can help uncover vulnerabilities in your Linux systems. These tools might not identify all applications down to the exact version number, but they’re a very powerful way of collecting system information.
Be especially mindful of these common security weaknesses in Linux systems:
Many web servers run on Linux, so you can’t overlook the importance of checking for weaknesses in Apache as well as Tomcat or other applications. For example, a common Linux vulnerability is that usernames can be determined via Apache when it doesn’t have the UserDir directive disabled in its httpd.conf file. You can exploit this weakness manually by browsing to well-known user folders, such as http://www.your~site.com/user_name or, better yet, by using a vulnerability scanner, such as AppSpider (www.rapid7.com/products/appspider
) or Nexpose, to automatically enumerate the system. Either way, you may be able to find out which Linux users exist and then launch a web password cracking attack. There are also ways to access system files (including /etc/passwd) via vulnerable CGI and PHP code. I cover hacking web applications in Chapter 15.
Likewise, FTP is often running unsecured on Linux systems. I’ve found Linux systems with anonymous FTP enabled that were sharing sensitive healthcare and financial information to everyone on the local network. Talk about a lack of accountability! So, don’t forget to look for the simple stuff. When testing Linux, you can dig down deep into the kernel and do this or that to carry out some uber-complex exploit, but it’s usually the little things that get you. I’ve said it before, and it deserves mentioning again, look for the low-hanging fruit on your network as that is the stuff that will get you into the most trouble the quickest.
The following tools can perform more in-depth information beyond port scanning to enumerate your Linux systems and see what others can see:
netstat –anp
List Open Files (lsof) displays processes that are listening and files that are open on the system.
To run lsof, log in and enter this command at a Linux command prompt: lsof. There are tons of options available via lsof –h, such as lsof –I +D /var/log to show which log files are currently in use over which network connections. The lsof command can come in handy when you suspect that malware has found its way onto the system.
You can and should disable the unneeded services on your Linux systems. This is one of the best ways to keep your Linux system secure. Like reducing the number of entry points (such as open doors and windows) into your house, the more entry points you eliminate, the fewer places an intruder can break in.
The best method of disabling unneeded services depends on whether the daemon is loaded in the first place. You have several places to disable services, depending on the version of Linux you’re running.
If it makes good business sense — that is, if you don’t need them — disable unneeded services by commenting out the loading of daemons you don’t use. Follow these steps:
ps -aux
The process ID (PID) for each daemon, including inetd, is listed on the screen. In Figure 13-7, the PID for the sshd (Secure Shell daemon) is 646.
vi /etc/inetd.conf
Or
/etc/xinetd.conf
Move the cursor to the beginning of the line of the daemon that you want to disable, such as httpd (web server daemon), and type # at the beginning of the line.
This step comments out the line and prevents it from loading when you reboot the server or restart inetd. It’s also good for record keeping and change management.
To exit vi and save your changes, press Esc to exit the insert mode, type :wq, and then press Enter.
This tells vi that you want to write your changes and quit.
kill –HUP PID
If you don’t have an inetd.conf file (or it’s empty), your version of Linux is probably running the xinetd program — a more secure replacement for inetd — to listen for incoming network application requests. You can edit the /etc/xinetd.conf file if this is the case. For more information on the usage of xinetd and xinetd.conf, enter man xinetd or man xinetd.conf at a Linux command prompt. If you’re running Red Hat 7.0 or later, you can run the /sbin/chkconfig program to turn off the daemons you don’t want to load.
You can also enter chkconfig --list at a command prompt to see what services are enabled in the xinetd.conf file.
If you want to disable a specific service, say snmp, enter the following:
chkconfig --del snmpd
TCP Wrappers can control access to critical services that you run, such as FTP or HTTP. This program controls access for TCP services and logs their usage, helping you control access via hostname or IP address and track malicious activities.
You can find more information about TCP Wrappers from ftp://ftp.porcupine.org/pub/security/index.html
.
Linux — and all the flavors of UNIX — are file-based operating systems. Practically everything that’s done on the system involves the manipulation of files. This is why so many attacks against Linux are at the file level.
If hackers can capture a user ID and password by using a network analyzer or can crash an application and gain root access via a buffer overflow, one thing they look for is what users are trusted by the local system. That’s why it’s critical to assess these files yourself. The /etc/hosts.equiv and .rhosts files list this information.
The /etc/hosts.equiv file won’t give away root access information, but it does specify which accounts on the system can access services on the local host. For example, if tribe were listed in this file, all users on the tribe system would be allowed access. As with the .rhosts file, external hackers can read this file and then spoof their IP address and hostname to gain unauthorized access to the local system. Attackers can also use the names located in the .rhosts and hosts.equiv files to look for names of other computers to exploit.
The highly-important $home/.rhosts files in Linux specify which remote users can access the Berkeley Software Distribution (BSD) r-commands (such as rsh, rcp, and rlogin) on the local system without a password. This file is in a specific user’s (including root) home directory, such as /home/jsmith. A .rhosts file may look like this:
tribe scott
tribe eddie
This file allows users Scott and Eddie on the remote-system tribe to log in to the local host with the same privileges as the local user. If a plus sign (+) is entered in the remote-host and user fields, any user from any host could log in to the local system. The hacker can add entries into this file by using either of these tricks:
This configuration file is a prime target for a malicious attack. On most Linux systems I’ve tested, these files aren’t enabled by default. However, a user can create one in his or her home directory on the system — intentionally or accidentally — which can create a major security hole on the system.
Use both of the following countermeasures to prevent hacker attacks against the .rhosts and hosts.equiv files in your Linux system.
A good way to prevent abuse of these files is to disable the BSD r-commands. This can be done in two ways:
A couple of countermeasures can block rogue access of the .rhosts and hosts.equiv files:
chmod 600 .rhosts
chmod 600 hosts.equiv
You can also use Open Source Tripwire (http://sourceforge.net/projects/tripwire
) to monitor these files and alert you when access is obtained or changes are made.
The Network File System (NFS) is used to mount remote file systems (similar to shares in Windows) from the local machine. Given the remote access nature of NFS, it certainly has its fair share of hacks. I cover additional storage vulnerabilities and hacks in Chapter 16.
If NFS was set up improperly or its configuration has been tampered with — namely, the /etc/exports file containing a setting that allows the world to read the entire file system — remote hackers can easily obtain remote access and do anything they want on the system. Assuming no access control list (ACL) is in place, all it takes is a line, such as the following, in the /etc/exports file:
/ rw
This line says that anyone can remotely mount the root partition in a read-write fashion. Of course, the following conditions must also be true:
This remote-mounting capability is easy to misconfigure. It’s often related to a Linux administrator’s misunderstanding of what it takes to share out the NFS mounts and resorting to the easiest way possible to get it working. If someone can gain remote access, the system is theirs.
The best defense against NFS hacking depends on whether you actually need the service running.
In Linux, special file types allow programs to run with the file owner’s rights:
SetUID and SetGID are required when a user runs a program that needs full access to the system to perform its tasks. For example, when a user invokes the passwd program to change his or her password, the program is actually loaded and run without root or any other user’s privileges. This is done so that the user can run the program and the program can update the password database without the root account being involved in the process.
By default, rogue programs that run with root privileges can be easily hidden. An external attacker or malicious insider might do this to hide hacking files, such as rootkits, on the system. This can be done with SetUID and SetGID coding in their hacking programs.
You can test for rogue programs by using both manual and automated testing methods.
The following commands can identify and print to the screen SetUID and SetGID programs:
find / -perm -4000 –print
find / -perm -2000 –print
find / -perm -2 -type f –print
find / -name ".*"
You probably have hundreds of files in each of these categories, so don’t be alarmed. When you discover files with these attributes set, you need to make sure that they are actually supposed to have those attributes by researching in your documentation or on the Internet, or by comparing them to a known secure system or data backup.
You can use an automated file modification auditing program to alert you when these types of changes are made. This is what I recommend — it’s a lot easier on an ongoing basis:
ftp://ftp.cerias.purdue.edu/pub/tools/unix/scanners/cops
), finds files that have changed in status (such as a new SetUID or removed SetGID).RPC and other vulnerable daemons are common targets for buffer-overflow attacks. Buffer overflow attacks are often how the hacker can get in to modify system files, read database files, and more.
In a buffer overflow attack, the attacker either manually sends strings of information to the victim Linux machine or writes a script to do so. These strings contain the following:
If an attacked application (such as FTP or RPC) is running as root (certain programs do), this situation can give attackers root permissions in their remote shells. Specific examples of vulnerable software running on Linux are Samba, MySQL, and Firefox. Depending on the version, this software can be exploited using commercial or free tools such as Metasploit (www.metasploit.com
) to obtain remote command prompts, add backdoor user accounts, change ownership of files, and more. I cover Metasploit in Chapter 12.
Three main countermeasures can help prevent buffer-overflow attacks:
Enable another access control mechanism, such as TCP Wrappers, that authenticates users with a password.
Don’t just enable access controls via an IP address or hostname. That can easily be spoofed.
As always, make sure that your systems have been updated with the latest kernel and software updates.
Some Linux vulnerabilities involve the bad guy actually being at the system console — something that’s entirely possible given the insider threats that every organization faces.
If an attacker is at the system console, anything goes, including rebooting the system (even if no one is logged in) by pressing Ctrl+Alt+Delete. After the system is rebooted, the attacker can start it in single-user mode, which allows the hacker to zero out the root password or possibly even read the entire shadow password file. I cover password cracking in Chapter 8.
Edit your /etc/inittab file and comment out (place a # sign in front of) the line that reads ca::ctrlaltdel:/sbin/shutdown -t3 -r now, shown in the last line of Figure 13-9. These changes will prevent someone from rebooting the system by pressing Ctrl+Alt+Delete. Be forewarned that this will also prevent you from legitimately using Ctrl+Alt+Delete.
For Linux-based laptops, use disk encryption software, such as WinMagic (www.winmagic.com
) and Symantec (www.symantec.com
). If you don’t, when a laptop is lost or stolen, you could very well have a data breach on your hands and all the state, federal, compliance, and disclosure law requirements that go along with it. Not good!
You can assess critical, and often overlooked, security issues on your Linux systems, such as the following:
You can do all these assessments manually — or better yet, use an automated tool to do it for you! Figure 13-10 shows the initiation of the Tiger security-auditing tool (www.nongnu.org/tiger
), and Figure 13-11 shows a portion of the audit results. Talk about some great bang for no buck with this tool!
Alternatives to Tiger include Linux Security Auditing Tool (LSAT; http://usat.sourceforge.net
) as well as Bastille UNIX (http://bastille-linux.sourceforge.net
).
Ongoing patching is perhaps the best thing you can do to enhance and maintain the security of your Linux systems. Regardless of the Linux distribution you use, using a tool to assist in your patching efforts makes your job a lot easier.
The distribution process is different on every distribution of Linux. You can use the following tools, based on your specific distribution:
Commercial tools have additional features, such as correlating patches with vulnerabilities and automatically deploying appropriate patches. Commercial tools that can help with Linux patch management include ManageEngine (www.manageengine.com/products/desktop-central/linux-management.html
), GFI LanGuard (www.gfi.com/products-and-solutions/network-security-solutions/gfi-languard/specifications/patch-management-for-operating-systems
), and Dell KACE Systems Management Appliance (http://software.dell.com/products/kace-k1000-systems-management-appliance/patch-management-security.aspx
).
3.136.18.218