SecureWorks - On the Radar Newsletter - September 2007
Healthcare Security Back in the Headlines Security 101: Rootkits Internet Threat Update: The Emerging Threat of XSS Worms

Healthcare Security Back in the Headlines

With a couple of well-publicized incidents, the release of new attack data and the first audit of a healthcare provider for HIPAA compliance, the summer of 2007 has had a big effect on security awareness in the healthcare industry. Here is a quick summary of the major events:

• On September 6, a former network engineer at a healthcare provider in San Diego was convicted with two counts of intentionally damaging protected computers. After resigning due to what he perceived to be a negative performance review, the engineer accessed the provider’s network, disabled the automatic data backup process that was in place and summarily deleted data on several servers including patient data.
• On August 28, the former employee of a Portland healthcare provider filed a lawsuit alleging his termination was retaliation for reporting an incident to police. While still an employee, his car was broken into and unencrypted media with personal information on 365,000 patients was stolen. He reported the theft and was fired shortly thereafter. The lawsuit seeks $1 million in damages for lost wages and emotional distress. In the course of the investigation it was revealed that the company’s process for managing backup tapes was to place them in the employee’s car.
• On August 16, SecureWorks released data gathered from across our more than 1,800 clients that showed a significant rise in the number of hacker attacks targeting health care organizations (Health Care on the Rise). Our research illustrated that attacks rose 57 percent from 2006 to 2007, going from an average of 5,900 attacks blocked per healthcare client per day to an average of 9,300 attacks blocked per healthcare client per day. This data reinforces the trend of attacks rising across the board as well as the fact that healthcare providers are seen as a viable target by hackers.
• In June, it was reported that the Department of Health and Human Services (HHS) initiated an audit of the data security procedures at Atlanta’s Piedmont Hospital for compliance with HIPAA’s security rules. The first of its kind, the audit has raised both concern and hope that HHS is beginning to actually enforce HIPAA compliance. Since the HIPAA Enforcement Rule went into effect on March 16, 2006, no audits had been performed until now without prior cause. This led to a common perception that HIPAA lacked the teeth to force security improvements in the healthcare industry. As a result, HIPAA compliance hasn’t been a high priority for many healthcare providers. Now that enforcement is starting to happen, some of these organizations are playing catch up to prove their compliance.

Facing increased attack volumes and the possibility of HIPAA audits, healthcare providers should take the summer of 2007 as a sign to get their security program in order (if they haven’t already). The first step is to review and understand the HIPAA security requirements and identify areas of your security program in need of improvement. If you don’t have the expertise in-house to perform an assessment of your security controls in the context of HIPAA requirements, consider engaging an experienced outside specialist (such as SecureWorks).

Security 101: Rootkits

What is a rootkit?
The term “rootkit” is a general description of a set of programs designed to compromise an operating system. Rootkits are stealthier than other forms of malware, concealing files, processes, network connections, registry entries and other indicators that signal the presence of malware on a system. The name “rootkit” comes from its origin in UNIX-based operating system, where the term “root” refers to the most powerful level of access. In most cases, rootkits serve to enable the ongoing use of a compromised system by hiding the activity of other utilities and providing backdoors that the attacker can use to maintain remote access.

Protecting against rootkits
Because they are designed to conceal themselves and other malware, rootkits can be much more difficult to detect than Trojans, worms, spyware and other common forms of malware. A rootkit can rarely be detected by relying on data from a single security or network point. Instead, a defense-in-depth approach that includes active monitoring and correlation of information from multiple security controls, including both network and host-based technologies is required.

Prevention
Before installing a rootkit remotely, an attacker must first compromise a target system’s security. This usually depends on using exploits that take advantage of security vulnerabilities on a target system. Preventative measures, such as patching systems, scanning for vulnerabilities and using well-tuned network intrusion prevention systems will render exploits ineffective and prevent rootkits from being installed.

Detection
Once a system has been infected, rootkits are difficult to detect using traditional host-based security measures such as anti-virus because of their stealth capabilities. Rootkits modify resources upon which all programs on a given system depend, meaning that the operating system that is running cannot be trusted. For example, some rootkits make changes at the kernel level to ensure that common requests made by detection software (such as requesting a list of all running processes) return information that doesn’t disclose the presence of the rootkit and associated malware.

While detecting the presence of a rootkit is more challenging than other forms of malware, it can be done. Software detection tools such as chkrootkit and RootKit Hunter (for UNIX systems), F-Secure’s Blacklight™ (Windows) and RootkitRevealer* (part of the Windows Sysinternals™ toolkit) can be used to identify rootkits on systems that may be infected. Careful analysis of network traffic can also detect rootkits. Communications between the attacker and a compromised system can be detected by monitoring firewall logs for irregular network traffic directed towards or originating from hosts within your network. Network-based intrusion detection systems will also alert you of suspicious network traffic that could indicate the presence of a rootkit.

Response
Any system found to be infected by a rootkit should be immediately taken off the network or quarantined without access to other systems or network resources. Once isolated, the system should be cleaned to remove the rootkit and any malware it is concealing. However, removing a rootkit can be just as difficult as detecting it because rootkits can embed themselves very deeply within a system. The best method of complete removal is to simply save any necessary data files and restore the system using a clean OS image. This method is recommended unless you want to collect evidence for criminal prosecution or to determine the root cause of the incident, in which case you should be prepared to spend a significant amount of time and resources on an in-depth forensics investigation. It’s also not unheard of for an organization to simply destroy the compromised computer.

The Emerging Threat of XSS Worms

by Bonnie Shull, Security Research Analyst

Cross-site scripting, otherwise known as XSS, occurs when a hacker injects malicious javascript into an unvalidated input form on a website. With careful experimentation a special URL can be crafted which will return the user's identity, session, or authentication information when clicked. The attacker then advertises that URL heavily, getting as many people to click through as possible, each one exposing their private data or altering their account in the process. If the website returns unvalidated form input to the page dynamically, as is the case with blog comment fields and bulletin board posts, the user only has to inject his code into the page once. Every subsequent visitor to the page will be affected by the malicious code.

XSS is an almost ubiquitous threat. Statistics from web application vulnerability scanners suggest that at least half and maybe as many as 80% of web applications contain XSS vulnerabilities. These attacks affect all platforms equally, and can't be stopped by up-to-date servers, fully patched end user systems, network firewalls or anti-virus software. The attacks are clean, leaving little record of their occurrence, and even less uniquely identifiable network traffic.

First-generation XSS attacks only affected one user at a time, on one website at a time. The second generation brought us XSS worms. These worms can crawl through a large AJAX enabled website, infecting and affecting every single user.  Because they aren't slowed by platform or browser incompatibilities, XSS worms spread much faster than the more traditional worms we are already familiar with.

The first XSS worm was the now famous MySpace 'Samy' worm.  The worm added users as friends to the author's profile, and caused the victim's profile to display the message "but most of all, Samy is my hero" on their profile. The Samy worm infected over a million MySpace users in less than 24 hours, one of the fastest rates of worm propagation ever seen. Since then, XSS worms have hit other major web service providers such as Yahoo® Mail, Gaiaonline Online®, Orkut, and others. But like Samy, their payloads have not been serious threats.

Some researchers note a common trend among relatively new classes of vulnerabilities – a calm before the storm where benign payloads and proof of concept attacks are the norm before criminal organizations start utilizing the attack vector for serious harm. It seems that we are on the cusp of that transition.

In an attempt to classify and understand XSS attacks, and eventually develop countermeasures against them, researchers have gathered and consolidated information. XSSed.com contains a directory of websites that contain XSS vulnerabilities. Spidering XSS vulnerability scanners have been created. XSS cheat sheets have been developed, detailing every known malicious injection. Unfortunately, the worms may use this information to evolve before we can use it to block them.

A third generation web worm could use these tools to choose an appropriate method of attack for whatever site it might be exposed to. If an end user visits site A which has already been infected by the worm, and is also logged into services B & C in other browser tabs, the worm would be able to cross over to those other services and determine the correct way to infect those sites as well. Because the worm would shift methods depending on its environment, it could frequently re-write sections of its code, becoming polymorphic. A polymorphic web worm would be the biological equivalent of a rapidly mutating virus, making it extremely difficult to detect or detain.  Billy Hoffman and John Terrill of SPI Dynamics led a presentation called "The Little Hybrid Web Worm that Could" at this year's Black Hat convention. The presentation made it clear that the potential for this type of evolution is very real.

XSS vulnerabilities need to be addressed at the source. Web application developers have to be educated about security, and taught how to write safe applications. Businesses have to make web application security a priority, budgeting for developer training and application testing. Security standards are being developed, and the educational ball has started rolling. We are very lucky that these vulnerabilities are easy to eradicate at the source. In time, they may be regulated out of existence.

In the meantime, researchers are working on countermeasure tools. There is work in progress on the development of browser plug-ins to protect the client, and web application firewalls show significant promise by allowing servers to block these type of attacks.  Of the two approaches, the web application firewall is by far the more developed. Web firewalls are very similar to network IDS systems, but they are built to monitor and protect a different environment. Unfortunately, the use of these firewalls is not very widespread. A fully functional browser plug-in does not seem to exist at the present time. NoScript is a plugin available for the Firefox browser which does not allow javascript to be executed. Due to the current heavy dependence on AJAX, use of this plugin can render the internet unusable.

If your company owns a web-based application, you need to spend the time and money to evaluate your security, train your developers, close holes and employ a web application firewall. The time and effort you spend now will save you time and money in the future. If you do not have a web application to manage, security awareness training for your employees and outbound traffic monitoring may give you a slight security edge. If you explain and enforce a business only web use policy your employees will naturally avoid the "bad neighborhoods" of the internet as well as the Web 2.0 services that they use on a personal basis.  Consider the use of the NoScript* plugin if your employee's perform online work that will not be crippled by the lack of AJAX operability, and keep an eye on our blog for advances in client-side XSS prevention.

Editor’s Note: To protect against XSS and other threats, SecureWorks can provide 24x7 monitoring of web application firewalls deployed within a client’s environment. We can also review web-based applications to help you eliminate vulnerabilities that could be exploited by XSS and other threats.

* These tools are the property of other organizations or companies. SecureWorks bears no responsibility for these tools and therefore cannot be held liable for any damages that may result from the use of non-SecureWorks tools. Any express or implied warranties, including implied warranties regarding the fitness for a particular purpose are disclaimed.

All third-party brands and trademarks referenced in the text above belong to their respective owners. SecureWorks’ On the Radar Newsletter is not authorized by, associated with or sponsored by the respective trademark owners.