Examining Linux hacking tools
Port-scanning a Linux server
Gleaning Linux information without logging in
Exploiting common vulnerabilities when logged in to Linux
Minimizing Linux security risks
Linux — the darling competitor to Microsoft — is the latest flavor of UNIX to take off in corporate networks. A common misconception is that the majority of security vulnerabilities are in the Windows operating system (OS). However, security experts see more and more that Linux and its sister variants of UNIX are prone to some of the same types of security vulnerabilities.
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:
Abundant resources are available, including books, Web sites, and developer and consultant expertise.
Unlikeliness that Linux will be hit with as much malware as Windows and its applications do. Linux excels when it comes to security, but it probably won't stay that way.
Increased buy-in from other UNIX vendors, including IBM and Sun Microsystems. Even Novell stopped development of its mighty NetWare OS and is now focusing on a Linux-based kernel.
Growing ease of use.
Based on what I see in my work, Linux is less vulnerable to common security flaws than Windows. When comparing any current distribution of Linux, such as Ubuntu and Red Hat/Fedora, with Windows XP, Windows Vista, or Windows 7, I tend to find a lot more weaknesses in 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 7, 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 product vendors, and ISPs that rely on Linux for many of their systems. When Linux systems are hacked, the victim organizations can experience the same side effects as their Windows-using counterparts, including:
Leakage of sensitive information
Cracked passwords
Corrupted or deleted databases
Systems taken completely offline
You can use many UNIX-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:
Windows-based SuperScan version 3 (
www.foundstone.com/resources/proddesc/superscan3.htm) for ping sweeps and TCP port scanningNmap (
http://nmap.org) for OS fingerprinting and more detailed port scanningWindows-based LANguard (
www.gfi.com/lannetscan) for port scanning, OS enumeration, and vulnerability testingTHC-Amap (
http://freeworld.thc.org/thc-amap) for application version mappingTiger (
ftp://ftp.debian.org/debian/pool/main/t/tiger) for automatically assessing local system security settingsLinux Security Auditing Tool (LSAT) (
http://usat.sourceforge.net) for automatically assessing local system security settingsQualysGuard (
www.qualys.com) for OS fingerprinting, port scanning, and very detailed and accurate vulnerability testingNessus (
www.nessus.org) for OS fingerprinting, port scanning, and vulnerability testingBackTrack (
www.remote-exploit.org/backtrack.html) toolset on a bootable CD or .iso image file
Hundreds if not thousands of other Linux hacking and testing tools are available on such sites as SourceForge.net (http://sourceforge.net) and freshmeat.net (http://freshmeat.net). 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.
Tip
Scan from both directions so you see what the bad guys can see from outside and inside the network.
Linux services — called daemons — are the programs that run on a system and serve up various services and applications for users.
Internet services, such as the Apache Web server (httpd), telnet (telnetd), and FTP (ftpd), often give away too much information about the system, including software versions, internal IP addresses, and usernames. This information can allow hackers to exploit a known weakness in the system.
TCP and UDP small services, such as echo, daytime, and chargen, are often enabled by default and don't need to be.
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 SuperScan results in Figure 11-1 show many potentially vulnerable services on this Linux system, including remote procedure call (RPC), a Web server, telnet, and FTP.
In addition to SuperScan, you can run another scanner, such as Nessus or LANguard Network Security Scanner, against the system to try to gather more information, including:
A vulnerable version of OpenSSH, as shown in Figure 11-2
The finger service information returned by LANguard Network Security Scanner, as shown in Figure 11-3
LANguard also determined that the server is running rlogin and rexec, the Berkeley Software Distribution (BSD) r-services. Figure 11-3 also shows that LANguard thinks the remote operating system is Red Hat Linux. This information can be handy when you come across unfamiliar open ports.
Figure 11-4 shows various r-services and other daemons that network administrators are notorious for leaving running unnecessarily on UNIX-based operating systems. Notice that LANguard points out specific vulnerabilities associated with some of these services, along with a recommendation to use SSH as an alternative.
Tip
You can go a step further and find out the exact distribution and kernel version by running an OS fingerprint scan with Nmap, as shown in Figure 11-5.
The Windows-based NetScanTools Pro also has the ability to determine the version of Linux that's running, as shown in Figure 11-6.
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:
Protect the systems with either
Disable the services you don't need, including RPC, HTTP, FTP, and telnet. You might very well need some of these services — just make sure you have a business need for them. This keeps the services from showing up in a port scan, which gives an attacker less incentive to break in to your system.
Make sure the latest software and patches are loaded to reduce the chance of exploitation if an attacker determines what services you're running.
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 determining vulnerabilities.
Several security tools can help determine vulnerabilities. These types of utilities 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 known security weaknesses in a system:
Note
FTP — especially if it isn't properly configured — can provide a way for an attacker to download and access files on your system.
Telnet and FTP are vulnerable to network analyzer captures of the cleartext user ID and password the applications use. Their logins can also be brute-force attacked.
Old versions of sendmail — the world's most popular e-mail server — have many security issues.
Make sure sendmail is patched and hardened.
R-services, such as rlogin, rdist, rexecd, rsh, and rcp, are especially vulnerable to attacks.
Many Web servers run on Linux so you can't overlook the importance of checking for weaknesses in Apache, Tomcat, and your specific applications. For example, a common Linux vulnerability is that user names 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 tool, such as WebInspect or QualysGuard, to automatically enumerate the system. Either way, you can find out which Linux users exist and then launch a Web password-cracking attack. There are also numerous ways to access system files (including /etc/passwd) via vulnerable CGI code. I cover hacking Web applications in Chapter 14.
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 hacking Linux, you can dig down deep into the kernel and do this and that to exploit the system but it's usually the little things that get you.
The following tools can perform more in-depth information gathering beyond port scanning to enumerate your Linux systems and see what the hackers see:
Nmap can check for specific versions of the services loaded, as shown in Figure 11-7. Simply run Nmap with the
-sVcommand-line switch.Amap is similar to Nmap, but it has a couple of advantages:
Amap is much faster for these types of scans.
Amap can detect applications that are configured to run on nonstandard ports, such as Apache running on port 6789 instead of its default 80.
The output of an Amap scan of the localhost (hence, the 127.0.0.1 address) is shown in Figure 11-8. Amap was run with the following options to enumerate some commonly hacked ports:
−1makes the scan run faster.-bprints the responses in ASCII characters.-qskips reporting of closed ports.21probes the FTP control port.22probes the SSH port.23probes the telnet port.80probes the HTTP port.
netstatshows the services running on a local machine. Enter this command while logged in:netstat –anp
List Open Files (
lsof) displays processes that are listening and files that are open on the system.Tip
To run
lsof, login and enter this command at a Linux command prompt:lsof -i +M. lsofcan 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) in 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 how the daemon is loaded in the first place. You have several places to disable services, depending on the version of Linux you're running.
Note
If you don't need to run a particular service, take the safe route: Turn it off!
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:
Enter the following command at the Linux prompt:
ps -aux
The process ID (PID) for each daemon, including inetd, is listed on the screen. In Figure 11-9, the PID for the sshd (Secure Shell daemon) is 646.
Copy the PID for inetd from the screen on a piece of paper.
Open
/etc/inetd.confin the Linux text editor vi by entering the following command:vi /etc/inetd.conf
When you have the file loaded in vi, enable the insert (edit) mode by pressing I.
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 comments out the line and prevents it from loading when you reboot the server or restart inetd.
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.
Restart inetd by entering this command with the inetd PID:
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 (www.xinetd.org) — 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.
For example, you can enter the following to disable the snmp daemon:
chkconfig --del snmpd
You can also enter chkconfig --list at a command prompt to see what services are enabled in the xinetd.conf file.
Tip
You can use the chkconfig program to disable other services, such as FTP, telnet, and Web server.
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 download TCP Wrappers from http://itso.iu.edu/TCP_Wrappers.
Note
Always make sure that your operating system and the applications running on it are not open to the world (or your internal network) by ensuring that reasonable password requirements are in place. Don't forget to disable anonymous FTP unless you absolutely need it. Even if you do, limit system access to only those with a business need to access sensitive information.
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. Hackers can also use the names located in the .rhosts and hosts.equiv files to look for names of other computers to attack.
The $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. An .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:
Manually manipulating the file.
Running a script that exploits an unsecured Common Gateway Interface (CGI) script on a Web-server application that's running on the system.
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:
Comment out the lines starting with
shell, login, andexecininetd.conf.Edit the
rexec, rlogin, andrshfiles located in the/etc/xinetd.ddirectory. Open each file in a text editor and changedisable=notodisable=yes, as shown in Figure 11-10.
Enter setup at a command prompt.
Choose System Services from the menu.
Remove the asterisks next to each of the r-services.
A couple of countermeasures can block rogue access of the .rhosts and hosts.equiv files:
Block spoofed addresses at the firewall, as I outline in Chapter 8.
Set the read permissions for each file's owner only.
.rhosts:Enter this command in each user's home directory:chmod 600 .rhosts
hosts.equiv:Enter this command in the/etcdirectory:chmod 600 hosts.equiv
You can also use 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 15.
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. 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:
The NFS daemon (nfsd) must be loaded, along with the portmap daemon that would map NFS to RPC.
The firewall must allow the NFS traffic through.
The remote systems that are allowed into the server running the NFS daemon must be placed into the
/etc/hosts.allowfile.
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. After hackers gain remote access, the system is theirs.
The best defense against NFS hacking depends on whether you actually need the service running.
If you don't need NFS, disable it.
If you need NFS, implement both of the following countermeasures:
Filter NFS traffic at the firewall — typically, TCP port 111 (the portmapper port) if you want to filter all RPC traffic.
Make sure that your
/etc/exportsand/etc/hosts.allowfiles are configured properly to keep the world outside your network.
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:
Programs that are configured for SetUID:
find / -perm −4000 -print
Programs that are configured for SetGID:
find / -perm −2000 -print
Files that are readable by anyone in the world:
find / -perm −2 -type f -print
Hidden files:
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.
Note
Keep an eye on your systems to detect any new SetUID or SetGID files that suddenly appear.
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.
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
Instructions to the processor to basically do nothing.
Malicious code to replace the attacked process.
For example,
exec (" /bin/sh ")creates a shell command prompt.A pointer to the start of the malicious code in the memory buffer.
If an attacked application (such as FTP or RPC) is running as root (certain programs do), this 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 the free Metasploit tool (www.metasploit.com) to obtain remote command prompts, add backdoor user accounts, change ownership of files, and more. I cover Metasploit in Chapter 10.
Three main countermeasures can help prevent buffer-overflow attacks:
Warning
Protect your Linux systems with either a firewall or a host-based intrusion prevention.
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 security patches.
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.
When a hacker 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 hacker 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 Linux password cracking in Chapter 7.
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 11-11. This 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, using disk encryption software such as TrueCrypt (http://www.truecrypt.org) is a must. 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 requirements that go along with it. Not good!
Tip
If you believe that someone has recently gained access to your system, either physically or by exploiting a vulnerability, such as a weak password or buffer overflow, you can use last, the program, to view the last few logins into the system to check for strange login IDs or login times. This program peruses the /var/log/wtmp file and displays the users who logged in last. You can enter last | head to view the first part of the file (the first ten lines) if you want to see the most recent logins.
You can assess critical, and often overlooked, security issues on your Linux systems, such as the following:
Misconfigurations or unauthorized entries in the shadow password files
Password complexity requirements
Users equivalent to root
Suspicious automated tasks configured in cron, the script scheduler program
Signature checks on system binary files
Checks for rootkits
Network configuration, including measures to prevent packet spoofing and other denial of service (DoS) attacks
Permissions on system log files
You can do all these assessments manually — or better yet, use an automated tool to do it for you! Figure 11-12 shows the initiation of the Tiger security-auditing tool (www.nongnu.org/tiger), and Figure 11-13 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 the Bastille Hardening program (http://bastille-linux.sourceforge.net).
Ongoing patching is perhaps the best thing you can do to enhance 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.
Warning
I often find Linux is completely out of the patch management loop. With the focus on patching Windows, many network administrators forget about the Linux systems they have on their network. Don't fall into this trap.
The distribution process is different on every distribution of Linux. You can use the following tools, based on your specific distribution:
Red Hat: The following tools update Red Hat/Fedora Linux systems:
Red Hat Package Manager (RPM), which is the GUI-based application that runs in the Red Hat GUI desktop. It manages files with an
.rpmextension that Red Hat and other freeware and open source developers use to package their programs.up2date, a command-line, text-based tool that's included in Red Hat/Fedora.
Debian: You can use the Debian Package System (dpkg) included with the operating system to update Debian Linux systems.
Slackware: You can use the Slackware Package Tool (pkgtool) included with the operating system to update Slackware Linux systems.
Tip
In addition to Linux kernel and general operating system updates, make sure you pay attention to Apache, OpenSSL, OpenSSH, MySQL, and other software on your systems. They have weaknesses that you probably don't want to overlook.
The open source option for multiple Linux platforms called RPM Package Manager (www.rpm.org) is worth checking out. 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 BigFix Patch Management (www.bigfix.com/content/patch-management) and Lumension Patch and Remediation (www.lumension.com/vulnerability-management/patch-management-software.jsp).