12.2 Remote Attacks | Security Warrior

< Day Day Up >

This section covers remote network attacks on Unix systems. Due to the vast range of such attacks, we've correlated the attack data to TCP/UDP port numbers , for your convenience. While legends tell of hackers who penetrate machines with no open ports (such as via a bug in a sniffer or even in a TCP/IP stack itself), the vast majority of network attacks come through a TCP (more often) or UDP (less often) port of a known network service.

We'll briefly describe the security relevance of the ports. If you are reading this book, we assume you already know how to use an advanced port scanner such as Nmap to discover open ports. By sending various packets to open ports, you can tell open (return ACK) ports from closed (return RST) or filtered (return nothing or RST) ports.

We will categorize the attacks on Unix systems into several classes. Our categorization is inspired by the ICAT (http://icat.nist.gov) attack classification.

So, what dangers might lurk on a port?

Weak authentication: If an attacker can guess the password and access the service running on this port, the risks are obvious. No authentication also presents a trivial example of weak authentication.
Plain-text service: Allows sniffing authentication credentials using tools such as tcpdump . Additionally, TCP session hijacking attacks (taking over a running session) and command injection (where the attacker inserts his own command in the running TCP session, bypassing the authentication stage) are possible. Tools are available for the above attacks.
Known vulnerabilities: A large realm of weaknesses exists, such as buffer overflows, heap overflows, format string attacks, user input validation errors, race conditions, and other software flaws. The most dangerous of these holes are "remote root" ”i.e., they provide an attacker with a remote shell running with "root" privileges on a Unix system.
DoS threat: A service can be used to flood the network or crash the system. In this category we will also list the services that can be abused to degrade the performance of a service or the entire system.
Information leak: Using such a port, attackers may be able to learn information about the operating system, running software or other bits important for the attack.

Next, we will look at common ports and investigate how they may be (and have been) attacked . The information below was collected from various vulnerability databases (shown in the "References" section) and from our own security research.

12.2.1 TCP

This section covers attacks against popular Unix TCP services. This is not an exhaustive treatise on Unix network attacks, as they are too numerous to be covered here. Also, the attack landscape changes with blinding speed.

TCP port 1 (destination)

The TCP Port Service Multiplexer used this port (described in RFC 1078). Among Unix vendors , only SGI implemented it. The services presented a security risk described in CERT Incident Note IN-98.01. Using this service, attackers are able to identify SGI machines (which used to ship with default passwords on several accounts). Risks: information leak.

TCP port 2 (source)

Another CERT Incident Note, IN-99-01, describes a scanning tool called "sscan" that used to send a TCP packet (with the FIN flag set) from source port 2. Sscan is a port scanner and OS identifier. Risks: information leak.

TCP ports 3, 4,and 5 (source)

The sscan tool sends a packet with source port 3 (with FIN and ACK flags set) in order to identify the target operating system. Risks: information leak.

TCP port 7 (destination)

This is the famous Unix echo port. It can be used for the echo-chargen local denial-of-service attack. Today, it is mostly disabled (from inetd.conf ) or blocked by firewalls. More details are provided in the vintage CERT advisory "UDP Port Denial-of-Service Attack" (http://www.cert.org/advisories/CA-1996-01.html). Risks: DoS.

TCP port 9 (destination)

This service has no security relevance. Everything sent to this port goes nowhere. These days it is mostly disabled (from inetd.conf ).

TCP port 11 (destination)

The systat service provides information about running services over the network (historical). Today, it is mostly disabled (from inetd.conf ), since this service is a large security risk (it leaks critical information). Risks: information leak.

TCP port 13 (destination)

The Unix daytime service provides the time of the day over the network (no surprises here). Red Hat Linux 6.2 had a denial-of-service vulnerability because of unclosed network sockets in the daytime service (Red Hat advisory RHSA-2001:006-03). This denial-of-service condition will crash all network services. Risks: DoS.

TCP port 17 (destination)

Unix quote-of-the-day. No security relevance; today, this is mostly disabled (from inetd.conf ).

TCP port 19 (destination)

Chargen (character generator). Used to be used for local denial-of-service together with echo. Nowadays mostly disabled (from inetd.conf ) or blocked by firewalls. Risks: DoS.

TCP ports 20 and 21 (destination)

This is the FTP data (port 20) and command channel (port 21). Risks: information leak, known vulnerabilities, weak authentication, plain text service, DoS. There are plenty of risks here:

Anonymous FTP servers with upload capability: Malicious parties can use these servers to store illegal software or media, thus incurring liability upon the owner.
Buggy FTP daemons: FTP network services (which first appeared in an RFC in the 1970s) have their share of bugs. Almost every implementation of an FTP server has had bugs. If you search for "FTP server bugs " in an online exploit database, hundreds of entries pop up. For example, exploits against WU-FTPD (by Washington University) have been rampant. Default installs of Red Hat Linux Versions 7.0, 7.1, and 7.2 with FTP enabled were wide open. To find all vulnerabilities for your FTP daemon, query the bugtraq database (currently hosted on SecurityFocus.com) or the NIST ICAT database.
Sniffers: FTP uses a plain-text protocol, thus transmitting usernames and passwords in the clear, which makes them vulnerable to sniffers.
Denial-of-service attacks: Using the FTP server, attackers can upload files and cause a denial-of-service condition. This risk is especially high if anonymous uploads are allowed. Depending upon how the Unix server is configured (disk partitioning), some systems might become unstable if system partitions fill up.

TCP port 22 (destination)

Secure Shell (SSH) was plagued by security problems in earlier versions. Both commercial (SSH) and free (OpenSSH) versions had critical remote vulnerabilities. You can still see scans for those versions performed by automated tools, configured to detect and exploit various old versions of Secure Shell. The bugs that were rampant in SSH code allowed anything from local denial-of-service attacks to a full-blown remote root compromise.

While invulnerable from sniffing, SSH can be used to brute force the authentication credentials (provided that password-based authentication is enabled). Secure Shell server software might also take steps to make password guessing more difficult (such as by increasing the delay between allowed attempts), but it still remains possible. Risks: known vulnerabilities, weak authentication.

TCP port 23 (destination)

The telnet protocol, which uses port 23, had its share of critical bugs. For example, "Multiple Vendor Telnetd Buffer Overflow Vulnerability" allowed attackers to take over a machine running the telnet server.

In addition, telnet presents risks of sniffing (unencrypted user and root passwords), brute forcing (remote password guessing), and unauthorized remote root logins.

telnet is a popular choice for login guessing attacks. While root logins are usually disallowed over telnet, one can still try to guess a regular user's password by repeatedly trying various username and password combinations, using a dictionary. Some default system usernames (abundant on older Unix versions, such as SGI IRIX and HP-UX) can also be tried for access, in case the accounts have interactive login privileges.

In addition to the above, default telnet banners ^[1] as shipped with most Unix variants usually disclose the system version (for example, Linux 2.4.7-12) and local name . The latter might shed some insight on the possible system role, increasing its appeal to the attacker. Risks: information leak, known vulnerabilities, weak authentication, plain-text service.

^[1] Messages shown to the user before a network login prompt.

TCP port 25 (destination)

The SMTP protocol server ”most often a sendmail, qmail, or postfix email server ”occupies this port.

The famous Morris worm of 1988 used a vulnerability in an early version of sendmail (the debug command) to get access to servers. Remote root bugs, while rare, have occurred in the history of various Unix mail programs, some more often than others.

Other attacks on port 25 include spamming and unauthorized mail relaying (sending email messages to third parties using somebody else's email server). Spamming may be classified as a DoS attack of sorts, as it denies access to legitimate email to its recipients and may overload and crash the email server.

Denial-of-service attacks and unprivileged remote access attacks are also possible, provided the mail server is configured with mistakes. sendmail, for example, uses an extremely confusing configuration file, and dangerous mistakes are common. For example, some sites allow the unrestricted sending of messages to programs. This functionality can be abused to execute commands on a victim's system.

SMTP is usually plain text and can be sniffed. However, it presents a smaller risk, since email is akin to public information anyway (transmitted in plain text end-to-end). Risks: information leak, known vulnerabilities, plain-text service, DoS.

TCP port 53 (destination)

While the Domain Name Service (DNS) usually runs on port 53 UDP, port 53 TCP is also reserved by it for zone transfers and other bandwidth-heavy DNS operations. Most of the known attacks against DNS have used the UDP component of the name resolution service.

DNS servers such as BIND used to be fraught with critical root-level vulnerabilities. In fact, exploiting holes in BIND DNS software was the most common attack on a Unix system in 1999-2000, due to some easy-to-use exploits against it. Critical bugs in BIND continue to be discovered , and some say that due to its complexity such behavior can be expected for the near future.

DNS queries also might disclose important information about the target network, such as via zone transfers (discussed in detail in Chapter 8).

As a plain-text service, DNS can be sniffed. However, this presents no risk, as DNS information is public.

DNS also presents unique risks for service abuse. DNS spoofing can be considered a known and inherent (unless future DNSSEC is implemented) weakness in the service. Risks: information leak, known vulnerabilities, plain-text service.

TCP port 69 (destination)

The Trivial File Transfer Protocol (TFTP) is a huge security risk even without bugs, as it allows for unauthenticated file transfers. Most sites do not run it or restrict it on the perimeter.

TFTP is an inherently risky service due to its lack of authentication. To add insult to injury , known vulnerabilities in TFTP implementations may lead to root compromise. TFTP is plain text and thus can be sniffed; and files transferred by TFTP can be captured by the attacker. Risks: information leak, known vulnerabilities, plain-text service, no authentication.

TCP port 79 (destination)

finger (as in "finger john@example.edu") is a classic Unix service to get information about users. At least, that was its design. Now attempts to "learn more about users" are classified as reconnaissance. Few sites run finger nowadays, due to various security concerns. The Morris worm used a remote root exploit in finger to spread back in 1988.

By definition, the finger service presents an information leak risk, revealing information about system's users. finger is plain text and can be sniffed, which might not make sense (as the information is public), but is still available as an option.

Bugs in the finger service might lead to a root compromise since (at least on older Unix systems) the service is running as root. Risks: information leak, known vulnerabilities, plain-text service, no authentication.

TCP port 80 (destination)

Port 80 ”HTTP ”is a world in itself. While talking of port 80 attacks, we could cover SQL injection attacks, web application attacks, CGI abuses , IIS worms, web server and add-on module bugs, webmail abuse, server misconfigurations, and attacks against other services available though port 80.

While Unix web server code has few critical remote bugs, server misconfigurations are still somewhat of an issue for security administrators. It's unrealistic to try to cover attacks against all web applications in this summary chapter: it would require several volumes .

Certain resources on web servers might be password protected. This raises the opportunity for authentication guessing over the Web. Risks: information leak, known vulnerabilities, plain-text service, weak authentication.

TCP port 110 (destination)

Post Office Protocol Version 3 (POP3), which runs on TCP port 110, is a method to retrieve email from a remote server. Together with IMAP and webmail, POP3 is one of the more popular email solutions. Attacks against port 110 are still present in the Internet noise (as detected by our honeypot in Chapter 20). Several popular POP3 daemons (qpopper, wu-imapd, etc.) used to have remote root bugs and exploits circulated in the underground . Port 110 traffic can also be subjected to password guessing (attacks against email passwords) and sniffing attacks.

In addition to POP3, scans for POP2 (an older version of the mail protocol, unused since the 1980s) still occur on rare occasions. Risks: known vulnerabilities, plain-text service, weak authentication.

TCP port 111 (destination)

Portmapper (a Unix Remote Procedure Call service daemon) runs on port 111. Popular RPC portmapper implementations (such as those used by Linux and some Unix flavors) have a gaping security hole: remote root. Over the course of 2000-2001, this was a popular way to break into unsecured Linux servers.

RPC is another universe in itself. RPC portmapper is a gateway to a large number of Unix services running on a dynamically allocated ports managed by the portmapper. These include NIS, NFS, and others. Many of these run with root privileges and thus, if exploited, will yield an attacker root access to the target system. Other RPC services will disclose information about the target system. Risks: information leak, known vulnerabilities, weak authentication.

TCP port 113 (destination)

The authentication daemon (identd) was standard for older Unix systems and is still present (usually disabled) on newer machines. It does not present a traditional security hole, but rather allows a privacy leak. Attackers might be able to use it to determine the user IDs under which network services run. This task can be automated by tools such as Nmap (choose the -I option). Most versions of identd provide the information without any authentication or use only an address-based authentication.

Additionally, some versions of identd (such as the less common cidentd) had known remote holes, providing root access to attackers.

The service is plain text, but the information is public; thus, the sniffing risk is low. Risks: information leak, known vulnerabilities, weak authentication, DoS, plain-text service.

TCP port 119 (destination)

The Network News Transfer Protocol (NNTP) runs on port 119. Few sites run NNTP daemons and thus few people audit their source code. Attacks against port 119 are probably possible, but they are not widespread. However, an NNTP server might be running as root; thus, successfully exploiting the service can give root access.

NNTP servers (such as some older versions of INN NNTP server) with remote holes are not unknown. Some other services can be crashed remotely. The service is plain text, but the information is public; thus, the sniffing risk is low. Risks: known vulnerabilities, plain-text service, DoS.

TCP port 123 (destination)

The Network Time Protocol (NTP), while seemingly innocent, has nevertheless been used for serious network compromise in the past. CERT Vulnerability Note VU#970472 (http://www.kb.cert.org/vuls/id/970472) outlines a well-known remotely exploitable buffer overflow in the NTP daemon. This vulnerability can be exploited over port 123 UDP as well. In spite of this critical hole, there are few scans for port 123 detected in the wild. The reasons are unclear.

While breaking through buggy NTP servers is not as common as FTP and SSH attacks, some of the popular NTP server implementations contain remote root holes. Misconfigured NTP servers will disclose a system time to outside parties due to weak authentication, creating a minor information leak, while others can be crashed remotely. Risks: information leak, known vulnerabilities, weak authentication, DoS.

TCP ports 135-139 (destination)

While Windows file sharing and name resolution are not relevant for Unix, SMB network services (such as Linux's SAMBA) are known to have bugs on older versions. However, the scans against ports 135-139 most likely target Windows machines. For example, the Blaster worm targeted port 135 on Windows machines.

While SAMBA's track record is not as bad as some of the FTP servers, it's had its share of remote root exploits and information leaks. Some versions of SAMBA servers can be crashed remotely. Additionally, nothing stops attackers from trying to guess a SAMBA's server share credentials by brute force. Risks: information leak, known vulnerabilities, weak authentication, plain-text service, DoS.

TCP port 143 (destination)

IMAP is a remote mail access protocol that has more functionality than POP3. Crucial remote root class attacks were discovered in some versions of WU-IMAPD and other daemons. In addition, port 143 can be used to brute force a password if log monitoring is not performed. Also, some IMAP servers can be crashed remotely, causing denial-of-service conditions.

Like POP3, IMAP is a plain text service; thus, email contents and authentication credentials can be sniffed. IMAP (again, like POP) may be tunneled over SSL or SSH to prevent that. Risks: known vulnerabilities, weak authentication, plain text service, DoS.

TCP port 443 (destination)

HTTPS (secure HTTP) runs on port 443. All port 80 information readily applies to port 443. In addition, all port 80 attacks directed to port 443 will be undetectable by existing intrusion detection systems (a great advantage to an attacker) due to encryption. If the same services and web applications are provided over port 443 (SSL encrypted) as well as 80 (plain text), attackers can easily abuse them.

Several popular SSL implementations (such as OpenSSL) were the subject of attacks and even worm outbreaks. It was possible to exploit SSL bugs through the SSL-enabled web server running on port 443. Risks: information leak, known vulnerabilities, weak authentication, DoS.

TCP ports 512-514 (destination)

rlogin and rsh are outdated Unix remote access services. They used to be plagued with bugs and configuration weaknesses. However, they are almost never used today, so attacks such as the "rsh -froot bug" exploit and the "rlogin trust abuse via .rhosts" are largely things of the past. Risks: information leak, known vulnerabilities, plain-text service, weak authentication.

TCP port 515 (destination)

The printer daemon is a famous source of Unix security holes, and root level at that. Linux LPR (actually, all BSD-derived) implementations "boast" a root-level bug that earned its own CVE entry (CVE-2001-0670, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0670). In addition, submitting abusive print jobs and even crashing the print service (effectively a printer DoS attack) is possible for certain printer daemon implementations. We highly recommend that you firewall this port at the network perimeter.

Risks: known vulnerabilities, plain text service, DoS.

TCP port 1080 (destination)

The SOCKS proxy port is the subject of many network scans, although the SOCKS proxy itself does not have known security weaknesses. The reason is simple: misconfigured proxies allow for connection laundering or anonymous connectivity for attackers. Lists of open SOCKS proxies are posted on the Internet for all to use.

Proxies such as SOCKS are not a large risk by themselves . Due to their weak authentication, however, they can be used in attacks against third party sites. Risks: weak authentication.

TCP port 2049 (destination)

The Network File System (NFS) from Sun is configured to use this TCP (and also UDP) port. NFS is the subject of many attacks and abuses. An open NFS port is a likely indication that a system can be accessed to various degrees, but not necessary at root level.

NFS can be abused in a variety of ways. In addition to known vulnerabilities (yes, including root-level), NFS can be manipulated to overwrite files and cause server crashes. In addition, NFS runs in plain text and there are many tools exist to capture files transmitted over it. Risks: information leak, known vulnerabilities, weak authentication, plain-text service, DoS.

TCP port 3128 (destination)

This port is commonly used by the Squid web proxy ( http://www.squid-cache.org ). Similar to the SOCKS proxy port (TCP 1080), this is the subject of many network scans. The reason is simple: misconfigured Squid proxies allow for connection laundering, or anonymous connectivity to web and FTP servers for attackers. Lists of open web proxies are posted on the Internet for all to use.

Proxies such as Squid are not a large risk by themselves, but due to their weak authentication they can be used in attacks against third-party sites. The Squid proxy also has its share of bugs, including critical root level bugs and authentication bypass flaws. Risks: information leak, known vulnerabilities, weak authentication, DoS.

TCP port 3306 (destination)

The MySQL database server, the most popular free open source database solution, is commonly run on TCP port 3306. MySQL server (in addition to having remote root bugs and remote crash options in some versions) can be used to brute force authentication credentials (username and passwords). The service runs in clear text and thus can be sniffed (giving the attacker access to potentially sensitive database contents). Risks: known vulnerabilities, weak authentication, plain-text service, DoS.

TCP port 6000 (destination)

The X Window System (also known as X11, X, X Windows, etc.) uses this port for remote client-server communication. While no public exploits exist, many abuses are possible on misconfigured servers including remote application start, key press logging, and screen snooping. Also, several DoS attacks leading to application crashes can be accomplished via this port. Higher-numbered ports (6001, 6002, 6003, etc.) are also used by the X Window System, in case more displays are configured.

While no major root exploits were made public for the X Window System, many smaller-scale holes, DoS attacks and flaws were discovered. X authentication can also be bypassed to gain system privileges.

While not strictly a text service, X Windows traffic can be sniffed by attackers, possibly granting access to display contents and the input of the victim. Risks: information leak, known vulnerabilities, weak authentication, plain-text service, DoS.

TCP port 6667 (destination)

IRC is a can of security worms, including the possibility of remote penetration, worm and automated attack agents , piracy, copyright violations, and so on. Also, many Trojan programs are set to communicate with their masters via IRC. In fact, several common IRC clients have been Trojaned by attackers; the users' machines are compromised if such a client is used. Another example was the ThreatKrew (TK) bot, which was first discoverd and traced back to its masters by Seth Fogie. Both IRC clients and servers have a history of remote holes actively exploited by attackers. Some servers can be crashed remotely as well. Risks: known vulnerabilities, DoS.

TCP port 7100 (destination)

The X font (xfs) server is used by the X Window System for displaying font configuration. Some remote attack bugs exist for the xfs, especially for Sun, IRIX, and Linux implementations. At the very least, several DoS attacks are possible. Risks: known vulnerabilities, DoS.

TCP port 8080 (destination)

WinGate and other web proxies often use this port, leading to many network scans. The reason is simple: misconfigured proxies allow for connection laundering, or anonymous connectivity for attackers. Lists of open proxies are posted on the Internet for all to use and abuse.

Proxies such as WinGate are not a large risk by themselves, but due to their weak authentication, they can be used in attacks against third party sites. Risks: weak authentication.

12.2.2 UDP

The section covers attacks against some of the Unix UDP services. Although it is not exhaustive, this list emphasizes some classic and recent attacks.

UDP port 53 (destination)

DNS running on this port (also TCP port 53) is the subject of a large number of remote exploits, mostly due to BIND DNS software (see http://www.isc.org/products/BIND/). Unfortunately, it is very difficult to protect against these exploits, since DNS servers must expose this port to the Internet. Here are some examples, spanning all versions of BIND (4.x and up): buffer overflow in DNS resolver functions, remote BIND denial-of-service, denial-of-service vulnerability in BIND 8 via maliciously formatted DNS messages, and malicious modification of DNS records.

DNS servers such as ISC BIND were fraught with critical root-level vulnerabilities. In fact, exploiting holes in BIND DNS software was the most common attack on a Unix system in 1999-2000, due to some easy-to-use exploits against it. Critical bugs in BIND continue to be discovered, and some say that due to its complexity such behavior can be expected for the near future.

DNS queries also might disclose important information about the target network, such as via zone transfers (discussed in detail in Chapter 8) .

As a plain-text service, DNS can be sniffed. However, this presents no risk, as DNS information is public. DNS does present unique risks for service abuse, though. DNS spoofing can be considered a known and inherent (unless future DNSSEC is implemented) weakness in the service. Risks: information leak, known vulnerabilities, plain-text service.

UDP port 123 (destination)

The Unix NTP daemon (ntpd) is used to synchronize time between networked machines and time servers, such as nist.time.gov. Several network attacks are known that can be used against misconfigured and/or vulnerable NTP daemons. Buffer overflows plague ntpd (CVE-2001-0414).

While breaking through buggy NNTP servers is not as common as FTP and SSH attacks, some of the popular NTP server implementations contain remote root holes. Misconfigured NTP servers will disclose the system time to outside parties due to weak authentication, creating a minor information leak, while others can be crashed remotely. Risks: information leak, known vulnerabilities, weak authentication, DoS.

UDP port 514 (destination)

Unix syslog uses UDP port 514 for network log transfers. While the classic BSD-derived syslog implementations have no publicly known security holes, several other implementations are plagued with holes.

Various syslog servers have remote bugs, allowing access to target systems. Additionally, some syslog-specific attacks such as log flooding (DoS) and message spoofing (injecting spurious data) are possible.

syslog messages are sent without authentication or (rarely) with weak address-based authentication. The messages are sent in plain text and can be sniffed to gain important system information such as usernames and (rarely) passwords. ^[2] Risks: information leak, known vulnerabilities, weak authentication, plain-text service, DoS.

^[2] This can occur if a user mistypes the password in place of a username ”it will be logged via syslog.

UDP port 517 (destination)

Port 517 is used by various talk (host-to-host chat) daemons on Unix. Various talkd implementations have remotely exploitable holes and must run as root due to their low port assignments (below 1024). Fortunately, talk is not used very often nowadays.

Buffer overflows plague some of the talk daemons, leading to remote root compromises. Risks: information leak, known vulnerabilities, weak authentication, plain-text service, DoS.

UDP port 2049 (destination)

NFS is configured to use this UDP (and also TCP) port. NFS the is subject of many attacks and abuses. An open NFS port is a likely indication that a system can be accessed to various degrees, although not necessary at root level.

12.2.3 Top Unix Vulnerabilities

The above lists describe some commonly attacked Unix ports. They are not exhaustive, though, and many other ports are being used by custom applications that are just as vulnerable.

How close to real life are the examples in the lists? What ports are being exploited (even as you read this) on the systems deployed on the Internet?

Let's analyze some publicly reported data from SANS (SysAdmin, Audit, Network, Security) Institute (http://www.sans.org) from the last several years . SANS is a nonprofit security research and education organization that conducts conferences and training classes, administers popular security certifications (such as GCIA and GCIH), and also organizes members of the security community to work on various projects of value to everybody.

SANS now compiles a list of "The Twenty Most Critical Internet Security Vulnerabilities," published once a year. SANS collects the most dangerous and commonly attacked vulnerabilities from a worldwide group of contributors (one of the authors of this book included) and then lets them vote on what are the 20 most critical. Nowadays, the list is split into two parts , for Unix and Windows. We will be focusing on a Unix list here. Here is how the recent "Top 20" lists looked .

The top vulnerabilities in Unix Systems in 2002 included:

BIND/Domain Name System
Remote Procedure Calls (RPC)
Apache web server
General Unix authentication (accounts with no passwords or weak passwords)
Clear-text services
sendmail
Simple Network Management Protocol (SNMP)
Secure Shell (SSH)
Misconfiguration of enterprise services NIS/NFS
Open Secure Sockets Layer (OpenSSL)

And the top vulnerabilities to Unix Systems in 2002 included:

Remote Procedure Calls (RPC)
Apache web server
Secure Shell (SSH)
Simple Network Management Protocol (SNMP)
File Transfer Protocol (FTP)
R-Services ”trust relationships
Line Printer Daemon (LPD)
sendmail
BIND/DNS
General Unix authentication (accounts with no passwords or weak passwords)

In 2001, the list was called "Top 10" and combined Unix and Windows. Here are the Unix entries (we have cut out the WIndows entry, leaving only those that are Unix- related ):

BIND weaknesses: nxt, qinv and in.named allow immediate root compromise
Vulnerable CGI programs and application extensions (e.g., ColdFusion) installed on web servers
Remote Procedure Call (RPC) weaknesses in rpc.ttdbserverd (ToolTalk), rpc.cmsd (Calendar Manager), and rpc.statd that allow immediate root compromise
sendmail and MIME buffer overflows as well as pipe attacks that allow immediate root compromise
sadmind and mountd
Unix NFS exports on port 2049, or Macintosh web sharing or AppleShare/IP on ports 80, 427, and 548
User IDs, especially root/administrator with no passwords or weak passwords
IMAP and POP buffer overflow vulnerabilities or incorrect configuration
Default SNMP community strings set to "public" and "private"

Now, at this point, the reader might ask what this has to do with our discussion on Unix attacks categorized by port. The following table demonstrates the relation. Table 12-1 summarizes the entries from the SANS top attack lists by port to show the commonly attacked Unix ports. It will be obvious that some of the ports are true attackers' favorites, while others become important or fade away as a target.

Table 12-1. Most-attacked Unix ports

Unix application	Protocol	Port	Year	Common attacks
BIND	TCP, UDP	53	2001, 2002, 2003	Known vulnerabilities, information leak
RPC	TCP	111+ ^[3]	2001, 2002, 2003	Known vulnerabilities
Apache, CGI	TCP	80,443	2001, 2002, 2003	Known vulnerabilities, brute force, information leak
Unix authentication	TCP	21,22,23+ ^[4]	2002, 2003	Brute force, information leak
Unix clear-text services	TCP	21,23,25,80, 110, 143, 161, 512,513,514+	2003	Sniffing, information leak
sendmail	TCP	25	2001, 2002, 2003	Known vulnerabilities
SNMP	TCP, UDP	161,162	2001, 2002, 2003	Known vulnerabilities,information leak
SSH	TCP	22	2002, 2003	Known vulnerabilities, brute force
NIS/NFS	TCP, UDP	2049	2001, 2003	Known vulnerabilities,information leak
SSL applications	TCP	25,995,443+ ^[5]	2003	Known vulnerabilities
FTP	TCP	21,20	2002	Known vulnerabilities, brute force, sniffing, information leak
R-services ^[6] remote session	TCP	512,513,514	2002	Known vulnerabilities, brute force, sniffing, information leak
IMAP and POP mail retrieval	TCP	110,143	2001	Known vulnerabilities, brute force, sniffing, information leak
LPD	TCP	515	2002	Known vulnerabilities, DoS

^[3] The plus sign indicates that other "ephemeral" ports are also used by this service.

^[4] Various Unix services use remote password-based authentication ”only common ones are shown.

^[5] SSL may be used by many other services, such as SMTP, POP3, IMAP, HTTP, and custom applications.

^[6] Remote login (rlogin), remote shell (rsh) and remote copy (rcp). Today largely historical

Table 12-1 shows the recently attacked Unix ports. Indeed, as indicated by the Unix honeynet research conducted by one of the authors, the observed attack activity closely matches the above table. For example, FTP attacks were subsiding in 2003, while RPC is as popular as ever (due to recent vulnerabilities in Linux systems).

To conclude, it is important to be aware of attacks on various ports on Unix systems ”and some ports are more important for both attackers (better availability of attack tools) and defenders (more bang for the buck for the protection measures).

< Day Day Up >