Cyber Attacks on the Dartmouth College Network

Abstract

We analyze the security of the Dartmouth College campus network. We describe systems and applications in use at the College (and their vulnerabilities) and various intrusion mechanisms used to attack the network. We analyze log data obtained from intrusion prevention and detection systems. We present a number of “case studies”, describing real attacks that have taken place at Dartmouth. Finally, we analyze the human factors involved with maintaining a secure college network.

Introduction

Late on Wednesday, July 24th, 2004, an attacker gained access to eight servers at Dartmouth College including machines storing sensitive information (1). Dartmouth IT staff discovered and corrected the breach within 48-hours, but not before the attacker was able to deploy file sharing software on to the compromised machines and possibly access the sensitive data.
Securing Dartmouth’s network security is no easy task. The Dartmouth community consists of well over 10,000 students, faculty, and staff at its undergraduate and graduate schools, all with varying technical equipment, knowledge, and needs. A “typical client” on the network has access to a tremendous amount of bandwidth, and some machines contain very sensitive data. It’s no surprise that literally thousands of attacks (that we know about) occur against machines on the campus network each day.

Adam Goldstein, IT Security Engineer for Dartmouth’s Computer Services lists five things attackers typically want to do on our network: 1) run websites to host spam links or malware 2) access sensitive data 3) run spam engines 4) use machines as proxies for other attacks 5) obtain full system access for other purposes. To achieve these nefarious ends, attackers typically target systems with out-of-date patches or incorrect configurations or they attempt to “trick” users into running malicious code or revealing sensitive information. In this paper we explore the vulnerabilities in systems and applications in use at the College, the intrusion detection and prevention mechanism in place to thwart attacks, data from several real attacks, and finally, the human factors involved with maintaining a secure college network.

Dartmouth Network Systems and Applications

Wired Network Access

Traditionally, anyone with a computer and a standard RJ-45 network cable could connect to the Dartmouth campus network from one of many wired access points without authenticating. Since February of 2009, the college has begun to implement a new MAC address authentication system in compliance with the Communications Assistance for Law Enforcement Act (CALEA) (6). Each user will need to enter their Dartmouth Name Directory (DND) username and password in order to authorize a machine for one year. A malicious user could trivially circumvent this system. Therefore, this system is only a compliance measure which offers little in the way of security. While this in and of itself is not a problem, some users or even IT staff may inadvertently place their trust in a malicious user solely because that user has a Dartmouth IP address. Library databases are an example of systems which authenticate this way, and the NFS section also contains one such example.

Wireless Network Access

Dartmouth users have access to two wireless networks, a WPA2 Enterprise encrypted wireless network called “Dartmouth Secure” and an unencrypted wireless network called “Dartmouth Public”. “Dartmouth Secure” requires uses to authenticate using a personal certificate issued by the college. Users of “Dartmouth Public” have no access to on-campus network resources. According to our informal bandwidth tests, caps on the public network limit bandwidth to 490 Kbps downstream and 667 Kbps upstream whereas “Dartmouth Secure” users get 1222 Kbps downstream and 7117 Kbps. In spite of the obvious speed differences between the two networks, only half of Dartmouth’s students bothered to switch to the secured network by February of 2008, months after the network became available (7). Due to known vulnerabilities in several widely used Dartmouth applications (see “BlitzMail” below), it is trivial to “sniff ” and capture the network login information for any Dartmouth user careless enough to log in whilst connected via unencrypted wifi.

NFS

An unnamed Dartmouth department utilizes the Network File System (NFS) protocol on all department lab machines. Users can access their home directory from any machine.

According to department administrators, the department’s NFS configuration currently allows a malicious user with physical access to the network (or access to a machine with such) to access and modify the home directories of any department user. The department uses IP rules to authenticate NFS clients. With physical access to the department network and a personal machine, they could alter certain settings to gain full access. The NFS server will assume that user x has been properly authenticated when it communicates with any machine whose IP has been white-listed, including the machine of our malicious user. Hence, the malicious user can view, modify, delete, and create files as if they were any user x.

Several potential solutions to the NFS problem exist: NFS version 4 introduces Kerberos technology which could be used to authenticate users properly before granting them access but the department does not run NFSv4. Alternatively, The Trusted Computing Group’s (TCG) Trusted Network Connect (TNC) protocol would make it much more difficult to “steal” the IP of a department machine and thus render this attack ineffective. Finally, the department could switch to another file system protocol which includes better support for authenticating users.

Department IT staff acknowledge the NFS vulnerability—in fact, they brought it to our attention in the first place—but contend that users who have physical access to the network should be trusted to behave honorably as members of the Dartmouth community.

BlitzMail

Dartmouth developed a proprietary email system named “BlitzMail” in 1987. The system is significantly behind the times: the Windows BlitzMail client transmits usernames and passwords (and of course, emails) without encryption. The credentials of a user of the Windows BlitzMail client are very vulnerable to packet sniffers, particularly for users of the unencrypted wireless network. Using an alternate client would eliminate the issues with unsecured authentication, as the BlitzMail servers support encryption.

Banner Student

The college utilizes a student information system called “Banner Student” developed by SunGard. Students use the system to enroll in courses, access grades, access housing assignments, and change contact information. Administrators and faculty use the system for various administrative purposes. The Banner system is an attractive target for attackers looking to obtain or change sensitive information. The authors discovered a vulnerability in one Banner Student API (described in the Directory Transveral attacks section) which suggests that the system does not validate all of its input and may be vulnerable to attack.

Security Systems

Network Systems

The Dartmouth network uses three main systems to protect the network from a variety of attacks. Two of these systems, a signature based intrusion prevention system (IPS), and an anomaly based IPS system, focus on preventing intrusions. The third system, Snort, provides detection of possible attacks which have circumvented the prevention systems.

Signature Based Intrusion Prevention System

The signature based intrusion prevention system, much like virus software, gets routinely updated attack definitions. Administrators configure this system to block the traffic, or just trigger an alert according to these attack definitions. The system focuses on preventing system compromise attempts, but also catches some malware, spyware, and phishing. In the month of January 2009, it logged 16,975 blocks of email viruses, 16,305 phishing attempts, 9,673 venerability exploit attempts, 4,589 scanning attempts, and also about 35,000 spyware infection attempts and about 30,000 website attacks which were blocked.

Anomaly Based Intrusion Prevention System

The anomaly IPS system looks for odd patterns in order to block attacks but does not use signature detection rules. This system primarily blocks worms, bots, and spam engines, and also defends against denial of service attacks. In January 2009, it blocked 19,061 attacks from 5,491 unique IPs.

Snort

In this paper, the authors used the Snort intrusion detection system (IDS) to gather most of our web attack data. Snort logs suspicious traffic that the intrusion prevention systems do not block. Snort runs on two sensor servers which report to a main database that drives a console named BASE. BASE allows administrators to view, filter, and analyze Snort detections. Snort is a signature based intrusion detection system, meaning that everything captured by Snort is not blocked, but just logged for later analysis. In spite of its passive role, Snort provides invaluable information about suspicious activity on the network which can be used to improve the rules in the IDS systems or inform IT staff about areas that attackers are interested in. In February 2009, Snort logged 26,354 alerts.

Vulnerability Scanning

In addition to these systems, the College also takes a proactive approach to discovering vulnerabilities. IT staff utilize a vulnerability scanner and a specially web console Achilles (developed in house), which helps to organize the results. The security auditing tool tests over 25,000 different vulnerabilities.

Spam filtering technology

The College employs several layers of spam filters in order to identify and drop suspicious email. In this paper we chose not to focus on spam prevention though we do discuss several phishing attacks against Dartmouth users in the Phishing section. See (5) for more information about these technology Dartmouth uses to combat spam.

Server Systems

Some servers run local firewalls and anti-virus software from Symantec. LanDesk keeps Windows machines up to date with patches. Tripwire provides an early-warning of data compromises on some Unix servers. Some servers also use log monitoring tools like Logwatch and LogLogic to detect suspicious anomalies in server logs.

Workstation Systems

The College is able to maintain control over Dartmouth owned systems such as administrative computers, but has less power to impose mandatory updates on machines owned by students and faculty (who can choose to opt-out on Windows and Apple machines they purchase from the college, and must choose to opt-in for other machines). IT Staff use LanDesk to update workstations under college control. Recent malware such as the Conficker worm have left Dartmouth systems relatively untouched (see “Malware” for details) suggesting that the College’s compulsory update practices work well.

Attacks Against Servers

In this section we present data which suggests how attackers gather information about the systems they wish to exploit on the Dartmouth network as well as how they carry out their attacks.

Reconnaissance

Attackers often look for sensitive files such as scripts with known vulnerabilities or files which contain information that can help the attacker identify other potential attack vectors: Snort identified several files which were most sought after by attackers targeting Dartmouth web servers; we list these files in Table 1 (see Appendix A for a complete list):

In the following sections, we describe two general reconnaissance strategies used by attackers:

Directory traversal attacks

In a directory traversal attack, the attacker attempts to use a web server to gain access to files that the webmaster did not intend to share. Dartmouth’s Snort system frequently identifies directory traversal attacks:
The root directory of a particular website often corresponds to a directory within the filesystem of a server—this is almost always the case for websites served by the ubiquitous Apache web server. For example, the content served on www.foo.com might reside in /var/www/ on the filesystem of the foo.com server. An attacker might be interested in obtaining the contents of /var/secrets or /etc/passwd on this machine. In essence, a directory traversal attack allows the attacker to request a page like “www.foo.com/../secrets” or “www.foo.com/../../etc/passwd” to obtain access to
these files. Different escape characters and control sequences make it difficult to distinguish some legitimate directories from illegitimate ones. Web servers that are not updated with the latest security patches may be vulnerable to several directory traversal exploits. Root directory traversal attempts accounted for approximately 24% of the suspicious events logged by Snort, not including requests for “/etc/passwd” and other files where access attempts are tracked explicitly.

Forbidden page access attempts

Many web servers return a 403 error when they receive what they consider to be a “suspicious” request. While requests that result in 403 errors can sometimes be legitimate, they often arise because attackers are attempting invalid HTTP requests in an effort to learn about or exploit the APIs exposed by a given web server. Approximately 33% of the suspicious events logged by Snort were forbidden page access attempts. Please refer to the table in Appendix A for more information about the frequency of these attacks.

Remote File Inclusion Attacks

Attackers often attempt to “trick” a web server or web application into downloading malicious code. If they succeed they often can escalate privileges, access sensitive data, or carry out other dubious intentions. Remote file includes sometimes succeed against improperly configured web servers and poorly coded PHP applications (and other scripted applications) which do not validate their input.

Approximately 1% of the attacks identified by Snort were remote file inclusion attempts (See Appendix A). Most of these attacks target the main Dartmouth web server, and attempt to append query string parameters containing the url of a malicious payload to otherwise valid Dartmouth URLs.

Table 2 lists a number of example requests that attackers performed in various attacks. The payloads in these urls appear to be .txt files, but in reality, they are clear text or obfuscated PHP scripts. We reverse engineer and de-obfuscate one example payload in Appendix C.

Remote Include Attacks on an Institute Site

A notable site which received a number of remote include path attack attempts is a Dartmouth Institute site. This site is running an open source content management system, Joomla! Until recently, it ran an out of date version of Joomla! vulnerable to remote include attacks because of a validation bug (8). The most interesting payload targeting this site is a script which encoded much of its code in base64, and, in addition, which applied character substitution in order to severely obfuscate the nature of the code. See Appendix C for the steps the authors used to derive the plaintext source of this payload. We believe that payloads employ obfuscation to avoid detection by rules based malware detectors. We can personally attest to the fact that obfuscation also makes it difficult for a human to understand the content and intent of the script, which may be a secondary goal of the attackers.

The same writing website was also attacked several other times, in November 2008 and January and February 2009. In both cases the attacker was able to upload a PHP shell on the machine:

In November 2008, Snort logged an alert when it noticed the string ”passwd” in web traffic. An investigation by one of the authors found that attackers had uploaded a PHP shell, accessible to all, onto the machine. A group called the RuSH Security Team apparently developed this shell. The shell allows for attempts at file editing, directory traversal, and MySQL queries. In examining the traffic between the apparent attacker’s IP address and the Dartmouth server, we discovered a variety of packets that indicate attackers attempted to further escalate privileges using the script. In one instance, the attacker attempted to upload a file rst sql.php file (see Appendix B), while another tried to drop all the MySQL tables (see B.2), and a third tried to change the MySQL user permissions to grant themselves root SQL privileges (see B.3). The upload of rst sql.php seems to have failed, and we are unable to verify if any of the other attempts were successful.

The attack in January 2009 occurred when the site was running an older version of Joomla. In addition, the site administrator seems to have left the permissions on a directory (javascripts/) set to world-writable (777). This is probably because the Joomla install directions recommend setting these permissions during installation, but the admin neglected to adjust the permissions after installation (9). In the January attack, the attacker uploaded two shells to the javascripts directory — the “R57” and “‘Mad Shell” shells. We discovered that the R57 shell could read files from the server, including /etc/passwd (10). The signature based IPS system, however, blocked the communication between the remote attacker and the R57 shell so that the attackers were unable to use it.

Other Remote Include Attacks

In our review of Snort data from February 2009, we noticed some other payloads similar to that used to target the  ~writ8 which did not use sophisticated obfuscation seen previously. The authors suspect that these payloads were possible test payloads. We also discovered a simple two-line piece of code used in conjunction with a hacking tool called the “FeeL CoMz RFI Scanner Perlbot” (11). The FeeL CoMz bot implements a number of APIs specifically tailored to allow the attacker to launch a denial of service attack or distribute copyrighted material over IRC (12). As far as we can tell, the attacker was unable to install the bot on a Dartmouth machine. Another site on the Dartmouth web server was also hit by an attack attempting to infect the system with an IRC bot-herder script. This script was written in a combination of PHP and PERL and is capable of port scanning, downloading files, sending email, and launching tcpflood and udpflood attacks. We included a portion of the script and list various tasks it can perform in Appendix D. We believe that the upload of this script was also unsuccessful.

The majority of the web attacks being detected by Snort do not seem to be successful. The main reason for this is because these are un-targeted attacks being performed usually by automated scans. A large number of these attacks seem to be trying to determine if there is a vulnerability, and if so, marking it or reporting it back to the attacker. The few payloads which have been successfully introduced have had limited compromise of information, due to a combination of luck and the stopping of remote shell commands by the signature-based IPS. It is clear, however, that the College would benefit from tighter control of applications such as CMS systems being run on the Dartmouth servers. The proper installation and configuration of these systems, as well as the frequent updating of them, is crucial to maintaining sites which are less likely to be successfully exploited.

Countermeasures to Remote Include Attacks

By applying regular patches to the OS, services, and applications, and by granting the web server read and write access to files and directories on an as-needed-only basis, administrators can minimize the threat posed by remote include attacks. We note that Dartmouth’s IPS systems often prevents many remote include attacks and the IDS system often identifies additional attacks. The network or local logging services often detect suspicious behavior and allow IT staff to identify infected machines. Hence, while remote include attacks pose serious threats to systems on our network, the College is well equipped to identify and prevent many of these attacks.

SQL Password Cracking Attacks

Like web servers, hackers frequently target improperly configured and unpatched SQL servers. An attacker that achieves “root” SQL access6 can often escalate privileges to those of the system SQL user, or worse, to the level of the system root user. At best, an attacker with root SQL access has complete control over the SQL database and all data within it. In the Snort logs for February of 2009, we noticed 122 MySQL root login attempts that were not blocked by Dartmouth’s Intrusion Prevention Systems. In these attacks, a single attacker targeted several MySQL servers on a single subnet in an apparent brute force password cracking attempt. While we don’t know how the attacker discovered the machines, we speculate that if he used nmap to explore the subnet, he would have learned that several machines were running out of date versions of MySQL—one machine was running a version of mysql from 2002 7 — some with known privilege escalation vulnerabilities that allow the root SQL user to obtain system root privileges.

We were perplexed by these attacks because they all occurred on February 2nd between 11am and 12pm and between 11pm and midnight. We suspect that most external SQL login attempts are dropped by the intrusion prevention system before reaching our network. It remains a mystery how one lucky attacker managed to successfully execute 122 login attempts. Because of the small number of attempts, we do not believe that the attacker was able to guess the SQL password and thus compromise any machine. When we began this project, we suspected that we would have the opportunity to analyze data from SQL injection attacks. However, our IDS system did not record a single SQL injection attempt. This means that either the Dartmouth IPS systems are extremely effective at preventing this type of attack, these attacks occur and we don’t hear about them, or these attacks don’t occur against Dartmouth SQL servers (unlikely).

Countermeasures to SQL Attacks

Administrators should avoid the use of easily guessed SQL passwords and ensure that the SQL user accounts used by web applications do not have unnecessary privileges. Firewall settings and SQL user settings can restrict connections to trusted IPs (ideally, “localhost” only) in order to prevent brute force password cracking attempts from machines on the internet.

Attacks on Custom Applications

Intrusion detection and prevention systems are not well equipped to handle attacks against some applications developed in house or purchased by the College which are not widely seen by the security community. In this section, we discuss a vulnerability we discovered in the Banner Student Information System. We speculate that additional vulnerabilities might exist in countless web applications maintained by staff throughout the college.

Banner Student Grade Viewer Attack

Banner Student is an information system storing a plethora of sensitive information that would be valuable to many attackers. Among other things, the Banner Student database stores student grades. The authors discovered a “feature” in a Banner Student APIs which allows a user to obtain their term grades prior to the time when all grades are officially published by the registrar.

The registrar typically waits until after the faculty grade submission deadline before posting grades rather than making a partial list of grades available to students early. While the Banner Student user interface only presents a list of terms for which grades have been published, the server side APIs allow the user to view grades for ANY term. The APIs don’t validate the term requested by the client. A user can submit a request for grades for any term and obtain a valid response with all submitted grades. We speculate that other Banner Student APIs might also fail to validate their input. While we could not formulate a Banner Student API call to do anything more interesting than view our own grades prematurely, we believe that additional vulnerability tests of the faculty and administration APIs (which, we presume, allow sensitive data entry) are in order.

Countermeasures to Custom Application Attacks

There is little that can be done by network or systems administrators to address these highly customized attacks. IPS and IDS systems may provide some protection, but these systems are unlikely to prevent or detect exploits such as the “Banner Student” trick. The onus falls on application developers to write good applications. Security by obscurity may provide a modicum of protection; if attackers do not know much about an application they may have difficulty mounting an attack against it.

Human Factors

In this section we examine the behavior of users on the Dartmouth network and describe how users fall victim to fradulent emails, viruses, and other malware. In addition, we explain our attempt to manipulate some of the humans responsible for ensuring network security by submitting a fraudulent password reset request.

Phishing

Over the years, a number of phishing schemes targeted Dartmouth users. In February 2008, a spammer sent forged a fraudulent message “from” info@dartmouth.edu to 1,000 Dartmouth addresses requesting their network passwords. Twenty people replied to the email, and only some of those actually released their passwords. The people who released the information were all Dartmouth faculty or staff, not students (15). Other phishing attempts have targeted the Dartmouth community, such as a fraudulent email sent in January 2006 which appeared to come from a local bank. This email attempted to steal online account logins (15). Most recently, a well-designed phishing attempt targeted six Dartmouth email addresses all belonging to assistants of high-ranking college officials. The message appeared to come from the Internal Revenue Service and was well written with no typographical errors. The zip file attached to the email purportedly contained a form, but it delivered a password dump utility and a script. When opened, the attachment downloaded and opened a legitimate form from the IRS website in order to prevent the user from becoming suspicious. IT staff became aware of this elaborate phishing scheme when security software detected the password dump utility upon its execution.

Malware: Conficker on Campus

By January 26, 2009, the Conficker worm had spread to over 15 million PCs (16). In spite of its proliferation, machines on the Dartmouth network were relatively immune from the worm. Virus protection updates and system patches were available to protect against this attack such as the November 2008 MS08-067 patch. On January 23, 2009, Dartmouth IT scanned 8,665 live systems and discovered that only 51 were vulnerable to the worm. This shows that the use of LanDesk and other procedures to keep systems updated seem to be working well, with some room for improvement in compliancy.

Managing Human Error

Educated humans are less likely to make mistakes! Staff and students trained to identify suspicious email or websites may be less prone to errors. The evidence presented above suggests that Dartmouth users — particularly students — successfully identify many fraudulent emails and websites.

IT staff should configure machines under their control to apply patches automatically and encourage autonomous users to do the same. Spam filter technology can identify and remove or flag many suspicious emails and IPS and IDS systems can detect and prevent suspicious behavior that arises when users fall prey to malware.

Conclusion

We’ve explored several vulnerabilities in systems and applications in use at Dartmouth College. We’ve noted that access to the wired network is fairly unrestricted. While this in and of itself is not necessarily a problem, systems or persons which rely upon the assumption that users with access to the network are deserving of trust do so at their peril; for example, an unnamed Dartmouth department systems are vulnerable to a trivial attack which allows any user with access to the network to view and manipulate files belonging to other users. We’ve seen how several applications — such as the college BlitzMail client and the student information system Banner Student — suffer from vulnerabilities should be addressed in the future. We’ve seen how enterprise printers with default configuration settings pose a threat to network security and privacy. Sophisticated printers often behave like computers and use of default user names and passwords on these printers makes them attractive targets. In addition, default-configured printers threaten user privacy since many allow an attacker to access printed information.
In spite of these weaknesses, IT staff use tools to effectively identify, prevent, and study attacks. We’ve seen how attackers frequently conduct reconnaissance to identify or explore machines that they later target. At Dartmouth, these reconnaissance efforts are generally easy to detect or prevent altogether. We’ve explored common attacks such as remote file inclusion exploits and brute force password cracking attempts. For the few successful attacks, IT Staff can typically identify an infected machine within hours or days of infection due to the suspicious behaviors it exhibits. Phishing and fraudulent website scams periodically target Dartmouth users. Computer savvy users — students in particular — often identify and avoid these scams. Finally, we’ve examined the behavior of the users on the Dartmouth network and explored the impacts of these behaviors on security and privacy. Most users either faithfully apply updates or benefit from automatic updates pushed by OS, software vendors, or Dartmouth IT.

In summary, while we have identified a number of areas where Dartmouth’s network security is lacking, we are fairly impressed with the extent and demonstrated efficacy of the measures that College’s IT staff (and many of its users) take to prevent, detect, and respond to threats.

Acknowledgements

The authors would like to thank Adam Goldstein for help in obtaining the data needed for this study, and for his invaluable insight on the topic. The authors also extend thanks to Scott Rea and the rest of the Dartmouth Cyber-Security Initiative Team. We are also grateful to Professor Charles C. Palmer for his support as the professor of our Computer Science 38 course for whom we have written this paper. The authors also thank Tim Tregubov and Sergey Bratus for discussing various vulnerabilities and providing their insight.

Appendix

Appendix [PDF]

References

1. Megan Spillane. Hackers crack college servers, access records. The Dartmouth, August 2004. http://thedartmouth.com/2004/08/03/news/hackers/.
2. Dartmouth College. Dartmouth college quick facts. http://www.dartmouth.edu/apply/generalinfo/quickfacts/.
3. Dartmouth College Office of Institutional Research. Dartmouth college fact book: Total staff headcount by job group -fall. https://sites.dartmouth.edu/dujs/files/2020/10/stafftotalinstitution.pdf
4. Dartmouth Medical School. Dartmouth medical school facts & figures. http://dms.dartmouth.edu/about/information/dms_facts.shtml.
5. Adam Goldstein. An overview of information security controls at dartmouth. Slide Presentation, March 2009. (ISTS brownbag, March 9th, 2009).
6. Erin Jaeger. Dartmouth to restrict wired access to internet. The Dartmouth, February 2009. http://thedartmouth.com/2009/02/02/news/internet/.
7. Mat Grudzien. Students rely on public wireless. The Dartmouth, February 2008. http://thedartmouth.com/2008/02/25/news/wireless/.
8. Secunia. Joomla! “mosconfig absolute path” file inclusion. http://secunia.com/advisories/29106/.
9. Unknown blogger. Secure joomla file permissions – linux with apache.
10. Secunia. Php “mb send mail()” and imap functions security bypass. http://secunia.com/advisories/18694/.
11. FeeLCoMz. Fx29phpbot v1.71. http://feelcomz.wordpress.com/2008/09/page/2/.
12. FeeLCoMz. Feelcomz bot source code. http://feelcomz.freehostia.com/botz/fx29bot.txt.
13. Lenz Grimmer. Updated mysql 3.23.53a binaries now available. (Forum posting announcing release of MySQL 3.23.53a. We note that this release occurred in 2002). http://lists.mysql.com/mysql/122484.
14. SunGard Higher Education. Sungard higher education – about us. http://www.sungardhe.com/about/.
15. Kate Farley. Spam e-mails target 1,000 blitzmail users. The Dartmouth, February 2008. http://thedartmouth.com/2008/02/20/news/spam/.
16. Author Unknown. Virus strikes 15 million pcs. United Press International (UPI), January 2009. http://www.upi.com/Top_News/2009/01/25/Virus_strikes_15_million_PCs/UPI- 19421232924206/.