Computer security is a precarious business both from a product development and administrative standpoint. Operating system vendors are forced to constantly patch their software to keep consumers protected from the latest digital threats. But which operating systems are the most secure? A recent report by Symantec hints that Windows currently presents fewer security holes than its commercial competitors.1 To that, a typical consultant would respond "well, that depends," as security auditors generally take such statements with a grain of salt. It depends on the configurations of the hosts, the breadth of the included binaries and the scope of what "commercial competitors" entails. Differing opinions on this interpretation lead to different conclusions. SecurityFocus, for instance, shows that various overall vulnerabilities surged in 2006 while ISS (Internet Security Systems) reports that operating system specific exploits declined.2,3

The summarized coverage of 2006 vulnerabilities by SANS showed the most prevalent attack vectors were not directly against the operating systems themselves.4 However, this article approaches the operating system as an entity in and of itself for analysis of only the vulnerabilities of core features. As such, vulnerability scans were conducted against 2006's flagship operating systems in various configurations to determine weakness from the moment of installation throughout the patching procedure. From Microsoft, testing included Windows XP, Server 2003 and Vista Ultimate. Examinations against Apple included Mac OS9, OSX Tiger and OSX Tiger server.5 Augmenting Apple's UNIX representation, security tests were also performed on FreeBSD 6.2 and Solaris 10. Rounding up the market share, Linux security testing included Fedora Core 6, Slackware 11, SuSE Enterprise 10 and Ubuntu 6.10. Before delving into the specifics of the vulnerabilities, it is helpful to understand the security scene of 2006.Hacking and Zero Day

The nature of malicious computer hacking has changed over the years, but one variable remains somewhat fixed in terms of availability and prediction - attack and penetration. Passive attacks have almost completely changed their genre while active attacking relies on a simple basic premise: the host computer is vulnerable no matter how security conscious the end user is. As the demand for underground, professional hacking rises, the need to build and maintain a network of zombie hosts requires more than relying on users to infect their system. Active attacks are a necessity for this Internet subculture and require close attention to the latest, and most longstanding, remotely accessible vectors.

Which leads into Zero Day bug disclosure, a hot topic in security circles.6 Many security researchers argue that disclosing Zero Day vulnerabilities forces vendors to hasten patching, thereby shortening exposure time. Vendors counter with the argument that immediate disclosure without patch development time creates an exposure window through which consumers are needlessly put at risk. The term Zero Day Exploit is certainly real, meaning that almost as soon as a vulnerability is exposed, the exploit code is released into the wild. Tools like Metasploit make automating such tasks even easier.7 It is almost too obvious how 2006 became the year such subversive techniques became so widespread.Evolution of 2006

Hacking into computers is a practice that predates the Internet. The past decade of interconnectivity between the masses has merely hastened the pace. Furthermore, during the Internet's infancy, connected hosts were limited in number and tended to reside in the realm of academics, science or computer professionals. Even with modem-only access through such relics as Prodigy and AOL, Internet growth boomed in the late 90s. Today's ubiquitous broadband and common network-ready appliances has further accelerated growth. All of these new hosts create a remarkably large sandbox for hackers to toy with and hide in.

Script kiddies were (and still are) an embarrassment to the hacking community, but the "anybody can hack" tools used by script kiddies pushed the development of more powerful, all-encompassing and fully automated hacking tools. Countless hackers and miscreants were using automated tools to constantly probe and penetrate the millions of computers left online 24/7. By 2004, the average unprotected computer was compromised in less than a minute, sometimes as quickly as twenty seconds. Very often just after a fresh installation, a host can be compromised by an automated tool before the real user even had a chance to log in for the first time.8 Rootkits were the buzzword of 2005 despite their long history. Sony BMG's ill-famed rootkit fiasco from their DRM protected audio CDs brought the term into the general public's eye. The very nature of a rootkit to evade detection and remain dormant until needed essentially drove the software behind the zombie networks of 2006.9

In 2006, the usual menagerie of vulnerabilities and attacks were ever present. E-mail viruses, websites hosting malicious scripts, credentials phishing and network worms continued to make their rounds. An enterprising niche, however, adapted concepts from every realm of software maliciousness to add a new twist to an old practice. Where automated tools left off in the past, professional robot networks (aka "bot-nets") picked up the slack. The route to infection followed one of the typical, aforementioned mainstream attack vectors. Once captured, the code utilized rootkit techniques to remain hidden from the more sophisticated and layered software packages that finally became more commonplace on home networks. Herein lies the twist. In the past, compromised computers were typically used as zombie gateways through which focused attacks were launched anonymously against targets for private information, corporate secrets, etc. They were also used as relay machines for e-mail spamming to keep the delivery source dynamic in an effort to thwart spam detection. In 2006, the compromised hosts became a network of distributed computers with downloadable controls to make it act as a single, massive attack system.10 These bot-net services were offered for sale, typically for launching monstrous "Denial of Service" attacks or to perform advanced penetrations where each attack comes from a different network segment to facilitate NIDS evasion.11Testing for Remote Exploits

The exploits of 2006 were made possible mostly through remote vulnerabilities. A large number of systems were, of course, compromised through the actions of their users. This study will examine the weaknesses inherent in the operating systems themselves by focusing merely on the remotely exploitable attack vectors. Removing the user actions from the equation reveal which operating systems are the most susceptible to attacks.Operating System Share of 2006

Estimated Operating System market share for 2006

Availability is a critical factor in directing a hacker's effort. When one operating system dominates the pool, it presents a more lucrative target because exploit code stands a better chance of succeeding. Measuring the market share of operating system usage is a difficult prospect and the statistics vary widely depending on the source. Various techniques for gauging operating system share include:

Microsoft Windows constitutes the bulk of world's operating systems with nearly 90% of the market while Apple's OS X and Linus Torvald's Linux share the remaining 10% with a smearing of alternative operating systems.12,13 These numbers represent all classes of network hosts, both workstations and servers alike, and are composited from rough 2006 estimates. Regardless of their accuracy, it's very easy to see why Microsoft products are targeted; an automated attack on it has a larger volume of targets through which to succeed.Testing Procedure

Each operating system was scanned several times to determine risk at various stages of deployment. First, a vulnerability scan was performed during the installation phase of the operating system. While the operating environment present may not represent the binaries being installed, a successful attack during installation could subvert the operating system prior to its first boot. An second scan was made following the initial boot, to portray the default vulnerabilities in an "as shipped" condition. Additional scans were made on an as needed basis to demonstrate the weaknesses of vendor released patch versions.

Many operating systems ship with a variety of services, servers and daemons enabled by default. To level the playing field, commonly used services were enabled when prompted by the installer or following the initial reboot. Services were chosen in terms of those commonly found on the Internet to provide actual functionality (like POP3, FTP or HTTP). Additional operating system services were enabled to determine the degree of vulnerability they pose (like login, uucp or finger) even though they are not commonly used on production systems. No intentional configurations were made to any server. This ensures service binaries will be tested in an "as shipped" default configuration.

Tests were based solely on on remotely accessible, active attack vectors against non-configured, default services. As shown in previous years, those few seconds between enabling a server and applying a configuration may be all that is necessary for an attacker to take ownership of the host. As configurations are dynamic and different per application, the testing of various modules was not performed. For example, a vanilla Apache installation may check out fine during these tests but it may become vulnerable once the mod-ssl package or any other package/configuration is applied to extend its functionality. Furthermore, application testing was not performed. Holes were not examined in the browsers or commonly used document readers. Attacks of those nature are passive and rely on a user "doing something" to perform the infection. This study in operating system vulnerabilities limits the scope to remotely accessible servers in default configurations only.Nmap

The Network Mapper, nmap, was used to test for completeness.14 By comparing the quick output produced by nmap against the detected services of Nessus, it can be concluded whether or not all remotely accessible weaknesses were scanned. Nmap is a significantly powerful tool in its own right, however, for these sandbox tests, the IP address of the target was already known. Therefore, nmap's true penetrable capabilities were not required.

Nmap version 4.20 was utilized for the scanning by settings flags for no host ping, connection via three-way handshake, well known ports, operating system fingerprinting and service identification.15 As most operating systems do not feature any layered security during these preliminary phases, it was not necessary to attempt firewall or network intrusion device evasion tricks. Scan results will not include ports identified as filtered. The following command was issued to scan each system:

nmap -P0 -sT -F -O -A 192.168.1.5Nessus

In 1998, Renaud Deraison presented the Internet community with Nessus. He designed Nessus to be a publicly extensible, remote assessment tool. The freely available NASL plug-in scripting language enabled Nessus to quickly keep pace with the latest vulnerabilities and therefore offered a direct challenge to the far more expensive, commercial packages.16

Nessus version 3.0.4 build 2G142 was used for conducting vulnerability scans against the various operating systems. On January 1, 2007, the Nessus engine was updated with every plug-in available in order to test operating systems against a common set of known vulnerabilities from 2006.

The server was configured with the following changes from Nessus' "default scan policy":

Originally codenamed Whistler, Windows XP was unveiled on the 25th of October, 2001. The operating system shipped on a single CDROM and raised the bar above previous system requirements; recommended machines needed a 300Mhz CPU with 128MB of RAM and 1.5GB of hard drive space for a successful installation.17 The installer automatically enables the network interface just after the administrator password is defined. Nmap was able to identify the system as Windows and Nessus further identified UDP port 137 open, although no vulnerabilities to the system were present.18

PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 1025/tcp open msrpc Microsoft Windows RPC

The latest service pack can be installed in many ways - using a factory Windows XP SP2 CDROM, slipstreaming the service pack into a custom rolled CDROM or simply running the Microsoft downloadable service pack executable.19 The latter method will be used for these tests, as the original edition represents the raw factory release. Immediately following reboot, the system was scanned again before applying the service pack.20

The Nmap scan was followed by a Nessus vulnerability scan which was able to identify several flaws in Windows XP of a serious nature. There were many features that permitted remote service enumeration of the host, but, while good for system analysis, these do not allow system subversion. On the other hand, XP was vulnerable to a variety of remote attack vectors allowing remote code execution.

* Nessus: The Messenger service is vulnerable to a buffer overrun where a hacker can execute code with local system privileges. * Nessus: The Task Scheduler is vulnerable to executing arbitrary code remotely. * Nessus: UPnP is enabled and responsive by default which carries a host of implications in itself. * Nessus: The NetBIOS name service suffers from a memory disclosure weakness. * Nessus: Arbitrary code can be executed through malformed NTLM packets to a buggy ASN.1 library. * Nessus: The LSASS service has a flaw allowing an attacker to execute code with SYSTEM privileges. * Nessus: The SMB service allows login via NULL session. * Nessus: The Server service is subject to a buffer overflow allowing arbitrary code to be executed with SYSTEM privileges. * Nessus: The SMB service is susceptible to denial of service that remotely crashes the system.

With Microsoft's Service Pack 2 installed, Nmap discovered that every port was filtered due to the default firewall now in place. Likewise, Nessus was unable to identify any risks. Despite the firewall, the XP system responded to UDP requests to port 137 to NBTscan requests. To test the binary patchwork, the firewall was intentionally disabled to determine what risks are present in the event of firewall failure or evasion.21 Service Pack 2 was released in August 2004, meaning there are still eighteen months of patches since the last major Microsoft release.

PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds

* Nessus: The Server service is subject to a buffer overflow allowing arbitrary code to be executed with SYSTEM privileges.

After testing Service Pack 2, one more round of patches were applied using Windows Update. Each patch was inspected to confirm only those issued from 2006 and earlier were applied to the system. Only patches from the critical selection were installed while ignoring functionality upgrades. Upon rebooting, the patched Windows XP system did not exhibit any remotely accessible vulnerabilities (even with the firewall disabled).22Microsoft Server 2003

Windows Server 2003 has 50 million lines of code with a lineage dating back to the late 1980s.23 The NT project aimed to move Microsoft from an OS/2 based platform into a pure environment for 32bit Windows applications. Server 2003 represents an "industrial strength" genesis of Microsoft's efforts to converge the many variants of Windows. Officially released in April of 2003, Windows Server 2003 ships in a variety of different editions.24,25

For vulnerability testing, Microsoft Server 2003 Enterprise Edition was subjected to Nmap and Nessus scans. Server 2003 enables the network device shortly after the first dialog boxes are configured during setup. Nmap identified the system only as a Windows operating system but was unable to isolate an exact fingerprint match. Nessus further identified that port 137 listened for UDP packets to the default NetBIOS-NS service and identified one remote vulnerability.26

PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 1025/tcp open msrpc Microsoft Windows RPC

* Nessus: The NetBIOS name service leaks actual memory contents when responding to malformed packets.

Immediately after rebooting the system for the first time, nmap identified additional services running on Windows Server 2003. The operating system fingerprint was still identifiable only as a Windows operating system to Nmap. Nessus identified three critical vulnerabilities for remote exploitation.27

* Nessus: The ASN.1 library is vulnerable to arbitrary code execution when fed carefully crafted packets. * Nessus: Arbitrary code may be executed with SYSTEM privileges via the LSASS service's DsRolerUpgradeDownlevelServer function. * Nessus: A heap overflow in the Server service allows arbitrary code execution and also allows an attacker to capture segments of the host memory space.

After logging into Windows Server 2003, the server was assigned roles. Unlike the UNIX systems which required simply enabling the application, Windows Server 2003 required configuring via built-in wizards. To maintain a sense of neutrality for configuration, servers were setup by simply clicking "NEXT" whenever possible. The configuration of the file server required selecting a folder which resulted in sharing the "My Documents" folder from the Administrator's account. While enabling IIS, the FrontPage Server Extensions and ASP.NET options were also selected. The mail server only required a name for its configuration, for which omninerd.com was provided. Remote Access was configured to permit Dial-Up or VPN access. While configuring the Active Directory domain, the controller was set up for a new domain in a new forest and given the name omninerd.com. The wizard indicated that Terminal Services were automatically reconfigured to only allow administrative logins. The DNS server offered an option of forward lookup zones, forward and reverse lookup zones and root hints only. The forward lookup zone option was selected for simplicity. Configuration of the DHCP server required, at a minimum, defining an IP scope for which 10.0.0.0/255 was chosen. The Terminal Services, Streaming Media Server and WINS were installed without special configuration.28

* Nessus: The ESMTP MAIL Service, Version: 6.0.3790.0 allows attackers to execute arbitrary commands with privileges equal to the mail server process. * Nessus: The WINS server responds to a crafted packet by executing arbitrary code. * Nessus: The DNS server is vulnerable to Cache Snooping attacks which allow a third party to ascertain what hosts have recently been resolved.29 * Nessus: A man in the middle attack is possible against the Terminal Services Remote Desktop Server. * NOTE: All of the previously noted vulnerabilities following installation are still present.

In March of 2005, Service Pack 1 was released for Windows Server 2003. The service pack constitutes a roll-up of hotfixes along with a variety of operating system enhancements. Notable features include the Windows Firewall from XP's Service Pack 2 and a PSSU (Post Security Setup Update) to secure the system during the transition period while patches are being applied.30 After installing the service pack, Nmap identified every port as before plus one additional RPC port. Nmap also identified the TCP/IP fingerprint as matching more systems than just Windows OS.31 Nessus identified only three remotely accessible issues, but they were rehashes of earlier vulnerabilities.32

PORT STATE SERVICE VERSION 1027/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0

* Nessus: The DNS server is vulnerable to Cache Snooping attacks which allow a third party to ascertain what hosts have recently been resolved. * Nessus: A man in the middle attack is possible against the Terminal Services Remote Desktop Server. * Nessus: A heap overflow in the Server service allows arbitrary code execution and also allows an attacker to capture segments of the host memory space.

Twenty-one months of patches lie between the service pack's release and the close of 2006. The system was updated one more time using Windows Update to apply all the critical updates dated from 2005 and 2006. Upon rebooting, Nmap found no new open ports other than those identified in previous scans. A Nessus scan revealed that only the DNS cache snooping and Terminal Service man-in-the-middle vulnerabilities still remain.33Microsoft Windows Vista Ultimate

Vista began life in 2001 as a project named Longhorn that was scheduled for release in 2003. Plagued by feature creep, Longhorn became quagmired in development until the project "restarted" using the Server 2003 codebase. In its new incarnation, Longhorn aimed to improve Windows security following years of public distaste with exploitation.34 Feature creep again began to plague Longhorn whereupon many of the highly touted features were dropped in order to meet release dates.35

Officially released in November of 2006, Vista was made available to manufacturers and MSDN subscribers. In January 2007, the public had access to the many versions of Vista.36,37 During installation, the network card was activated, however, the TCP/IP stack was protected by a filter. The only way to detect Vista's presence was by examining the ARP tables to identify an IP address was in use by the test machine. In order to identify any Vista services present, it was necessary to disable the default firewall after booting into the system for the first time. After disabling Vista's firewall, Nmap was able to identify three open ports for Windows networking and correctly fingerprinted the system Windows Vista.

PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 445/tcp open netbios-ssn

With the firewall disabled, Nessus was able to query the system for its exact time via the ICMP timestamp request. Null sessions are enabled by default allowing for SMB login. No further remote vulnerabilities presented themselves. 38 Using Windows Update, several patches were available, however, all were dated in 2007 indicating the shipped version of Vista is the most recent edition at the close of 2006.Apple Mac OS Classic

Apple released OS 9 in October of 1999.39 The software came standard with Apple computers or on a single CDROM. During installation, the setup program enabled the network adapters immediately. Nmap identified the installer as running a variant of Apple Mac OS 7.X, 8.X or 9.X.40 A Nessus scan against the installation was not performed as not a single port was found open. Following the first reboot, the system prompted to enable file sharing and additionally activated the wireless card. While adhering to the principle of not configuring the services, every available remote connection was enabled over TCP/IP to include file sharing and personal websharing. Nmap identified the system as Mac OS even though the actual fingerprint included the string i386-apple-darwin8.8.1. Nessus identified several weaknesses as well.41

PORT STATE SERVICE VERSION 80/tcp open http Apple Personal Websharing httpd 427/tcp open svrloc? 548/tcp open afpovertcp?

* Nessus: The TCP/IP stack responds to packets from a multicast address (known as a spank attack) which allows Denial of Service through network saturation or stealth scans.42 * Nessus: The web server tested positive for an Oracle9i crash through an incorrectly crafted, long URL.

Version 9.2.2 was the last patch released by Apple in December 2001. At this point, support for what became known as "Classic" ceased. However, "Classic" remains embedded within OS X as an environment emulator. After patching, more ports appeared during the Nmap scan than before despite no further configurations. Nessus also identified additional vulnerabilities following the patching.43

PORT STATE SERVICE VERSION 80/tcp open http Apple Personal Websharing httpd 548/tcp open afpovertcp?

* Nessus: The system can be crashed through a "land" attack, where a packet's return port and address are identical to the destination port and address.44 * Nessus: The web server is vulnerable to an infinite HTTP request loop resulting in a server crash. * Nessus: The web server can be crashed through an HTTP 1.0 format string value in the header request .

NOTE: The previous two vulnerabilities are still present on the patched system.Apple OS X 10.4 Server

OS X Server actually predates the consumer edition of OS X by nearly two years. After Cheetah was unveiled in 2001, the server edition's release schedule was altered to follow shortly after the regular releases.45 OS X is based upon a variety of technologies, but draws heavily from BSD UNIX and its parallel development in the open source realm Darwin.

OS X Server installs from a single DVD. The network interface is enabled the moment the installation software starts. During installation, Nmap fingerprinted the setup TCP/IP stack as OS X 10.3 or 10.4 and identified an open SSH port. Nessus did not identify any external vulnerabilities.46

PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 3.8.1p1 (protocol 1.99)

The second phase of installation prompted for services and configurations. Minimal adjustments from default were selected in order to maintain configuration neutrality. Directory usage was defined as "Standalone Server". The additional services Apple File Service, Apple Remote Desktop, FTP, iChat, Mail, NetBoot, Network Time, QuickTime Streaming, Software Update, Web (to include WebDAV and Weblog), Windows File Service, Xgrid Agent and Xgrid Controller were then enabled. After rebooting, the Server Admin utility was used to confirm that selected services were enabled and running.47 A quick Nmap scan identified the operating system as between OS X 10.3.9 and 10.4.7 with several open ports and Nessus identified remote vulnerabilities.48

* Nessus: The OS X version was identified as older than the current 10.4.8 meaning the system has vulnerabilities in the binaries: AFP Server, Bluetooth, CFNetwork, Dashboard, Flash Player, ImageIO, Kernel, launchd, LoginWindow, OpenLDAP, Preferences, QuickDraw Manager, SASL, Security Agent, TCP/IP, WebCore, Workgroup Manager. * Nessus: The Directory Services could be remotely shut down by making excessive connections to the server. * Nessus: The DNS server is vulnerable to Cache Snooping attacks. * Nessus: The web server reveals the existence of user accounts by querying against UserDir. * Nessus: The web server is vulnerable to an infinite HTTP request allowing an attacker to exhaust all available resources.49 * Nessus: The web werver crashes when issued a long argument to the Host: field on an HTTP request. * Nessus: The JBoss server allows information disclosure about the system configuration. * Nessus: The Streaming server allows remote code execution because OpenLink is vulnerable to buffer overflows on two crafted URLs: GET AAA[....]AAA and GET /cgi-bin/testcono?AAAAA[...]AAA HTTP/1.0.

Apple released the 10.4.8 patch for OS X Tiger in September 2006. While correcting many security issues and providing several upgrades, remote vulnerabilities still exist. Nmap identified the same open ports as before (some versions were updated) and correctly identified the system as OS 10.4.8 Tiger. A Nessus scan revealed that many of the original vulnerabilities still exist.50

* Nessus: The DNS server still allows Cache Snooping. * Nessus: The web server allowed downloading the source code of scripts on the server (specifically files served by weblog feature). * Nessus: The web server (port 80, 8080, 8443) allows for username enumeration because the 'UserDir' option is enabled. * Nessus: The web server (port 8080) has HTTP TRACE enabled allowing for a potential cross-site scripting attack. * Nessus: The SSL Coyote service on port 8443 is vulnerable to a format string attack on the method name allowing remote execution of code or Denial of Service. * Nessus: The web server (port 80, 1085) accepts unlimited requests making the system vulnerable to Denial of Service attacks that consume all available memory. * Nessus: The web server (port 80) crashes when issued a long argument to the Host: field on an HTTP request.

The final patches of 2006 were applied through Apple's Software Update. Nmap did not identify any version changes for services on the detected ports, although Nessus continued to identify remotely accessible vulnerabilities.51

OS X 10.4 was released on a single DVD-ROM. During installation, the network was live from the moment the system powered up. During the first phase, the system responded to only ICMP queries. Nmap was able to fingerprint the TCP/IP stack as belonging to either OS X or FreeBSD. Only after booting the system for the configuration phase was Nessus able to identify security issues. Although the issues were not remotely accessible, Nessus was able to determine the version of OS X and therefore enumerate the problems based on its internal database.52

By default, Apple OS X does not have its built-in servers enabled. For testing the standard binaries, Personal File Sharing, Windows Sharing, Personal Web Server, Remote Login, FTP Access, Apple Remote Desktop, Remote Apple Events and Printer Sharing were all enabled through the Preferences tool. Although OS X features a robust implementation of IPFW (Internet Protocol FireWall), it was not enabled.53 After enabling the services, Nmap identified the freshly opened ports and Nessus found only a user enumeration vulnerability in the HTTP server.54

* Nessus: The web server permits user enumeration through evaluating the time response to fail on particular queries.

Apple released 10.4.8, the last major patch for Tiger in September 2006. Upon rebooting the system, Nmap largely detected the same services present that existed prior to the patching with the exception of various filtered ports and an upgrade to the 4.2 edition of SSH. The final patches of 2006, available through Software Update, did not present a differing remote vulnerability footprint than the 10.4.8 update.55,56

* Nessus: The SSH service is subject to a PAM timing attack allowing for user enumeratin. * Nessus: The web server allows user enumeration through an HTTP response timing issue.

FreeBSD 6.2

FreeBSD was born in the 1993 as a derivative of 386BSD and 4.3BSD-Lite from U.C. Berkeley.57 The operating system was intended to bring the power of BSD UNIX to the x86 platform but has expanded to include ports for the additional architectures Opteron, Athlon64, EM64T, ARM, IA-64, PC-98 and UltraSPARC.58 It continues to be developed by the various teams throughout the Internet community.

Version 6.2 of the FreeBSD system was released on 26 December, 2006.59 The core installation comes on two CDROMs. While installing, the FreeBSD system does not enable the networking hardware by default. Only with the administrator's permission will selected interfaces be activated. Once enabled, the FreeBSD 6.2 system did not yield itself to any known vulnerabilities. An Nmap scan revealed no open ports and fingerprinted the host as a variant of FreeBSD.60 Nessus revealed only that ICMP responds to queries for the localhost time.61

During the installation phase, a variety of FreeBSD's stock services were enabled. These included FTP, SSH, telnet, shell, login, finger, ntalk, TFTP, POP3, IMAP4, SMB and NFS. These services were selected as they represent daemons that offer commonly used network features and are directly supported by the installation disc without requiring user configuration. No further configurations were made to the FreeBSD system beyond installing every binary and enabling the aforementioned services.

Upon rebooting the FreeBSD system, the chosen services from the installation were activated. During the scan, the FreeBSD console printed a variety of IPFW log messages regarding excessive traffic on the ports. By default, IPFW is enabled but is not configured for any security measures.62 An Nmap scan fingerprinted the system as FreeBSD 6.x (FreeBSD 6.1-RELEASE through 6.2-BETA3 (x86)) and revealed open ports.

Following the nmap port scan, Nessus was used to conduct a vulnerability assessment of FreeBSD in its operational state.63 Nessus identified the same services and daemon banners that were detected by Nmap. None of the service binaries exhibited any vulnerabilities to remote exploits.Solaris 10

In 1992, Sun introduced the first version of Solaris with the intent of phasing out the SunOS project.64 The original version of Solaris is based on UNIX System V Release 4 which demonstrated a shift from the BSD code base used for building SunOS. Originally, SunOS was designed to operate using Motorolla processors on Sun's propriety hardware. Sun shifted to the SPARC architecture in 1985 for its workstations and the operating system followed suit.65 In a broad move, Sun expanded Solaris to support the x86 environment, allowing their operating system to operate on non-Sun hardware. Support was nearly pulled in 2002, but the x86 architecture survived and remains a mainstay in the Solaris package. Released in the beginning of 2005, Sun claims that Solaris 10 is the world's most advanced OS because it is "the most efficient, secure, and reliable operating system ever built."66

The core of Solaris 10 comes packaged in a single DVD-ROM or as a series of several CDROMs.67 For installation purposes, the "Enable Remote Services" and "Entire Distribution" options were enabled to install the entire, default package of binaries equating to roughly four gigabytes. Immediately upon entering the configuration screens, Solaris prompted for enabling the network adapters. After enabling ethernet, an Nmap scan revealed zero open ports but did fingerprint the operating system as Sun Solaris 10|8|9.

When the Solaris 10 system went live, a variety of services were already present and enabled on the operating system. Using Nmap, a complete list of default servers and remote procedure call entry points were identified in addition to fingerprinting the system as a variant of Solaris. The Nessus scan revealed four immediate security holes.68

* Nessus: The SMTP server did not respond to HELO but did respond to EXPN and VRFY commands which allow an attacker to discover delivery addresses and recipient names. * Nessus: The SNMP server is configured with a default community name that reveals too much information remotely. * Nessus: The SMTP server on port 587 is susceptible to a buffer overflow when a long argument is passed in the MAIL FROM command which may permit remote code execution or denial of service. * Nessus: The rpc.snmpXdmid command in the RPC service is vulnerable to a heap overflow allowing remote attackers to obtain a root shell. * Nessus: The rpc.cmsd command in the RPC service is vulnerable to an integer overflow allowing remote execution of arbitrary code with root privileges.

Fedora Core 6

Red Hat Linux first appeared on the Internet as a Beta version on Halloween of 1994. Seven months later in 1995, Red Hat Linux became an official distribution.69 Red Hat's approach to development differed from other distributions. Development on the Red Hat distribution was made entirely in-house based on community feedback while open development, called the Fedora Linux Project, paralleled it. This pattern continued until 2003 when Red Hat merged the projects, establishing Red Hat Enterprise Linux and the Fedora Core Project.70

In October 2006, Fedora Core released version 6 of the distribution as a downloadable DVD-ROM image.71 During installation, the Fedora GUI prompted for options to which Office & Productivity, Software Development and Web Server were selected while Fedora Extras were not. When prompted for a detailed customization, the DNS server, FTP server, Legacy servers, Mail server, MySQL server, Network Servers, News server, PostgreSQL server , Printing server, Web server and Windows File Servers were all enabled. During this phase, Nmap was unable to identify any open ports and could not fingerprint the operating system. Nessus did not turn up any remote vulnerabilities.

After the first reboot, the network card came on-line for a final stage of installation configurations. Fedora's installer prompted for security configurations on the firewall whereupon ports were opened for FTP, Mail, NFS, SSH, Samba, HTTPS, telnet and HTTP. No changes were made to the default SELinux policies.72 Nmap could not identify the operating system, guessing incorrectly Sun Solaris 10. Unlike other Nmap scans which took only seconds, this scan lasted for 26 minutes and resulted in numerous filtered ports which is behavior indicative of a default firewall. A Nessus scan against Fedora 6 during the configuration process revealed no direct vulnerabilities to the host itself.73

PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.3 (protocol 2.0)

Despite the previous configuration prompts, the chosen servers were still not enabled. All servers were activated using the GNOME GUI. Nmap was able to identfy the open ports, but continued to misidentify the fingerprint as a Solaris system. Nessus found no remote vulnerabilities on the Fedora system.74

Slackware emerged onto the Linux scene in 1993 as Patrick Volkerding's project, first appearing as a posting in the comp.os.linux newsgroup.75 During the early years of Linux, distributions tended to vary widely with little regard towards standardization. Slackware took the approach of maintaining a very "BSD-like" file organization and naming convention. Additionally, while other distributions opted for including bleeding edge binaries, Slackware tended to lag in binary versions by choosing more stable and patched releases. Furthermore, Slackware tended to not include a plethora of packages, opting instead to fit the entire distribution on as small a footprint as possible.76 Slackware is predominantly an x86 based distribution, although ports have been made to other architectures.

Version 11.0 of Slackware was released in October of 2006.77 The distribution comes as three base CDROMs, three source CDROMs or one compilation DVD-ROM.78 Networking configurations are made during the installation, but the actual network interface is not activated during this phase. Slackware's installation menus also prompt for which services to enable in addition to the defaults (which include SSH and Sendmail). Using the installer menu, the Bind DNS, CUPS print, Apache web, MySQLd database, RPC (NFS) and Samba servers were also enabled.

Immediately upon rebooting the Slackware system, an Nmap scan identified the system as Linux 2.4.X and determined the running services:79

Slackware 11.0 supports more "out-of-box" services than those prompted for during the installation. For consistency of binary testing, the /etc/inetd.conf file was manually edited to enable basic UNIX services and servers. Additional servers include FTP,80 telnet, shell, login, ntalk, POP3, IMAP2, uucp, tftp, bootps, finger, and NetBIOS.81 Aside from enabling the services, no configurations were made to the servers themselves in order to test them in a default setting. Nmap was used again to determine the additional service visibility:

PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.0.5 21/tcp open ftp? (NOTE: This was an extra scan against Professional FTP) 23/tcp open telnet Linux telnetd 79/tcp open finger Linux fingerd 80/tcp open http Apache httpd 1.3.37 ((Unix)) 110/tcp open pop3 Openwall popa3d 139/tcp open tcpwrapped 143/tcp open imap UW Imapd 2004.357 513/tcp open login? 514/tcp open tcpwrapped 540/tcp open tcpwrapped

The Nmap port scan was followed by a Nessus vulnerability assessment of Slackware 11.0 in the operational state.82 Nessus was able to identify the same services and daemon banners (although with a little more detail) than were detected by Nmap.

* Nessus: The Very Secure FTP server permitted anonymous connections by default.83 * Nessus: The telnet server is susceptible to the TESO buffer overflow when given excessively large "are you there" commands which could lead to remote root access. * Nessus: The DNS server is vulnerable to Cache Snooping attacks which allow a third party to ascertain what hosts have recently been resolved

Suse Enterprise 10

SuSE began life as S.u.S.E. (Software- und System-Entwicklung), a German translation of Slackware back in 1992. The system continued to be based upon Slackware while pulling elements from RedHat and Jurix distributions until becoming unique in its own right by 1996.84 Novell completed an acquisition of SuSE in 2004 attempting to leverage their position to force out competition.85 Much like RedHat, SuSE now exists as the parallel work of the OpenSUSE project consisting entirely of open source projects and Novell's SuSE Enterprise which includes proprietary applications.86

SuSE Linux Enterprise ships on a single DVD from Novell.87 The network card was detected during the configuration phase of installation but the system prompted before enabling it. SuSE's network setup included a firewall configuration that is enabled by default. Nmap identified the system as Linux 2.6.x and only located one closed port. Strangely, Nmap fingerprinted the SuSE installer as Slackware 11.0, indicating the distribution still draws heavily from its Slackware roots. Nessus found no open vulnerabilities during the installation phase of SuSE.88

PORT STATE SERVICE VERSION 113/tcp closed auth

SuSE did not officially reboot following the second phase of the installation. Rather, the system restarted running services and then allowed for a user login. Services were enabled using the control panel, which installed binary images from the installation DVD. DHCP, DNS, HTTP (with modules for PHP, Perl, Python and Ruby), LDAP2, NFS, NIS, Samba, Slp and TFTP were installed with port openings in the firewall for each. With the servers enabled and access through the firewall opened, Nmap identified the system as Linux 2.4.22 along with the appropriate ports for the services. A subsequent Nessus scan for remotely accessible vulnerabilities detected minor issues.89

* Nessus: The web server was configured by default with TRACK method support allowing a cross-site scripting attack. * Nessus: The DNS server is vulnerable to Cache Snooping attacks which allow a third party to ascertain what hosts have recently been resolved.

Ubuntu 6.10 Desktop/Server

In October of 2004, the first version of Ubuntu was released as a distribution fork from the Debian project.90 Ubuntu adopted a philosophy of regularly scheduled releases (six months), moderately long run support (eighteen months) and ultimately that it should "just work." As such, Ubuntu is tied to GNOME releases, includes the latest editions of free binary packages and updates itself via the Internet. Using the Debian code base, Ubuntu works on a variety of architectures including x86, AMD64, Sun UltraSPARC, PowerPC and OpenPower.91

Version 6.10 was released in October 2006 as a single CDROM image.92 Ubuntu utilizes the LiveCD notion for an environment and enables the network device immediately, even before the installation GUI appears. However, a preliminary Nmap scan against this configuration reveals there are no remotely accessible network services available on the machine. The Ubuntu installer only responds to an ICMP ping. Additionally, the TCP/IP stack did not reveal its fingerprint for system identification. Even after rebooting the system, Ubuntu's Edgy desktop edition did not present any remote entry points into the system. A quick check with netstat -l revealed that all socket activity on the system was limited to localhost UNIX streams. A quick Nmap scan identified the Ubuntu system as having no open ports and could only fingerprint the system as Linux 2.6. Nessus was unable to identify any vulnerable risks to the host in the default configurations.

Installing the server edition of Ubuntu 6.10 revealed the same installation environment only without the GUI. The system was only visible on-line to an ICMP ping but did not reveal any open network ports. Ubuntu's server edition prompted for installing a DNS server and LAMP server (Linux Apache MySQL PHP). While useful, these services would not fully comprise the needs of a Linux server. Following a reboot, the CUPS, SMB, SSH, and VSFTPd services were added using apt-get. Although this deviates from the standard of testing only shipped binaries, Ubuntu relies on remote packages to fit the entire release onto a single CDROM. Despite having to manually add the servers, no further configurations were made. Nmap identified the kernel as linux 2.6.x and estimated the distribution to be either Ubuntu or Debian. Nessus was then used to scan the vulnerabilities present on the Ubuntu server.93

* Nessus: The Apache2 server was configured by default with debugging enabled and TRACK method support allowing a cross-site scripting attack. * Nessus: The DNS server is vulnerable to Cache Snooping attacks which allow a third party to ascertain what hosts have recently been resolved.

Closing

While there are an enormous variety of operating systems to choose from, only four "core" lineages exist in the mainstream - Windows, OS X, Linux and UNIX. Each system carries its own baggage of vulnerabilities ranging from local exploits and user introduced weaknesses to remotely available attack vectors.

As far as "straight-out-of-box" conditions go, both Microsoft's Windows and Apple's OS X are ripe with remotely accessible vulnerabilities. Even before enabling the servers, Windows based machines contain numerous exploitable holes allowing attackers to not only access the system but also execute arbitrary code. Both OS X and Windows were susceptible to additional vulnerabilities after enabling the built-in services. Once patched, however, both companies support a product that is secure, at least from the outside. The UNIX and Linux variants present a much more robust exterior to the outside. Even when the pre-configured server binaries are enabled, each system generally maintained its integrity against remote attacks. Compared with the Microsoft and Apple products, however, UNIX and Linux systems tend to have a higher learning curve for acceptance as desktop platforms.

When it comes to business, most systems have the benefit of trained administrators and IT departments to properly patch and configure the operating systems and their corresponding services. Things are different with home computers. The esoteric nature of the UNIX and Linux systems tend to result in home users with an increased understanding of security concerns. An already "hardened" operating system therefore has the benefit of a knowledgeable user base. The more consumer oriented operating systems made by Microsoft and Apple are each hardened in their own right. As soon as users begin to arbitrarily enable remote services or fiddle with the default configurations, the systems quickly become open to intrusion. Without a diligence for applying the appropriate patches or enabling automatic updates, owners of Windows and OS X systems are the most susceptible to quick and thorough remote violations by hackers.