On August 20, 2008, a tragic accident occurred involving a Spanair MD-82 aircraft. The aircraft failed to gain altitude, rolled to the right, and crashed into the ground, killing 154 people. The investigation after the accident discovered that the pilots failed to extend the flaps and slats prior to takeoff, creating an improper takeoff configuration. This critical error is the primary cause of the accident and was a result of the pilots failing to follow the published pre-takeoff checklist. The investigation also noted that the takeoff warning system (TOWS) failed, which normally issues an audible warning to the pilots if the aircraft is departing in the improper takeoff configuration. This warning is meant to supplement the takeoff checklist procedures in the event the pilots inadvertently forgot one of the steps on the checklist. The combination of the failed TOWS alert and the pilots’ failure to follow the pre-takeoff checklist resulted in the aircraft attempting takeoff in an improper configuration.

Exactly two years later on August 20, 2010, a Spanish paper published the following article:

ELPAIS.com: The computer scoring Spanair aircraft failures had virus (English Translation by Google Translate)

The article reports that malware was installed on the TOWS system of the accident aircraft and implies that it may have been a contributing factor or the cause of the accident.

A TOWS failure is not uncommon to MD-80 series aircraft and has been blamed in other fatal accidents, including Northwest Flight 255 in 1987. As a result of Northwest Flight 255, McDonnell Douglas issued an update to their checklist procedures, including a change requiring pilots to check the TOWS system prior to takeoff. This change was published to all U.S. operators of MD-80 series aircraft, but was not available in the crashed Spanair aircraft. This omission is noted in a safety recommendation issued by the NTSB (National Transportation Safety Board):

http://www.ntsb.gov/recs/letters/2009/A09_67_71.pdf (PDF)

As noted by the NTSB, the Spanair MD-82 checklist included a daily check of the TOWS system, but not prior to every takeoff. This procedure differs from the checklist issued by McDonnell Douglas in 1988 and that is used by U.S. carriers.

As the Spanair flight was preparing for departure, the Ram Air Temperature (RAT) probe was reporting an abnormally high temperature. The aircraft returned to the gate and maintenance personnel discovered that the RAT probe heater, which is only supposed to be operated in the air, was incorrectly operating on the ground. The maintenance personnel pulled the circuit breaker for the RAT probe heater and cleared the aircraft for flight, not noting the reason the RAT heater was improperly operating on the ground.

The MD-80 series aircraft contain a relay that powers the TOWS system when the aircraft is on the ground and redirects that power to the RAT heater when the aircraft is in the air. The NTSB’s tests determined that a failure in this relay could cause a failure of the TOWS system with no warning. This means the TOWS system has a single point of failure. If there was a problem with this relay, it could potentially send power to the RAT probe heater instead of the TOWS.

Based on this evidence, I believe the malware discovered on the TOWS is irrelevant to the accident in every way. The finding is interesting and proves that malware can exist on these systems, but does not seem to be a contributing factor to the accident. When the ground crews disabled the RAT probe heater, they failed to detect the malfunctioning relay, which was sending power to the RAT probe heater instead of the TOWS. With no warning that the TOWS system was not receiving power and no check of the TOWS by the pilots, the aircraft began its takeoff roll in an improper configuration with no warning.

The investigation leaves the probable cause of the accident as human error. It is ultimately the responsibility of the pilot in command for a safe flight and, while these systems enhance safety, they are not responsible for operation of the aircraft. The failure of the TOWS can be considered a contributing factor to this tragedy, but in my opinion the malware is not relevant to the TOWS failure or the accident. The official report on the accident is due in December 2010, which will reveal the probable cause and contributing factors to the accident.

Publicly, SecureWorks has long recommended using a separate computer dedicated exclusively to online banking, online retail purchases, account management, and other financial transactions. This would be a computer other than the one used for activities like surfing the web, “window shopping”, email, and social networking. The idea is to protect the system that you use to manage money from common exposures to threats that seek to break into bank accounts and steal your identity.

Direct from manufacturers, many computers come with the latest service pack pre-installed and automatic updates for the operating system, major applications, and security software turned on by default. The computer you dedicate to financial transactions should be placed behind a firewall. Most already are, even if you don’t know it, since practically all home routers include a robust stateful packet inspection (SPI) firewall by default. I suggest turning off this computer’s wireless connection and connect it via cable to one of the standard Ethernet ports on the home router, since there are fewer security pitfalls this way, and the point is not to let the system roam around. The temptation to use the dedicated system for riskier activities when the regular computer is being repaired is the most difficult pitfall to resist. Only turn on the system when it’s necessary to conduct transactions that involve financial or sensitive personal information, and turn it off when finished.

Recently, some security experts have recommended using a “live CD” to accomplish virtually the same task. A live CD is a self-contained, read-only operating system and user environment on a separate, removable disc (usually a CD or DVD) that you can use to boot a computer without using the system already installed on the hard drive. Booting from a live CD is something I recommended back in 2006. It basically substitutes your existing computer system for another. However, the concept of “separate physical computers” is easier to explain, and could mean better compliance with the practice by the average user.

Tech savvy people understand the idea of using a live CD: it offers a read-only, presumed-good base operating system and user-environment that can be used to perform sensitive operations like transferring money between accounts, applying for student loans, or buying a new computer online. Many might already use a live CD on a regular basis. It’s even possible to create a live CD with active defenses against some forms of spoofing and ARP poisoning, but in reality, most people can’t or won’t do that.

For the average user to use a live CD, they might have to configure their computers to boot from CD or a USB device instead of the hard drive, or the live CD might not have network or display drivers for their hardware. Some wireless devices and video cards required drivers that are not open source, are encumbered by patents, or otherwise not freely distributable legally. This is a problem for both Linux-based live CDs and Windows PE (pre-execute environment) live CDs. Additionally, Windows PE requires building a disc and copying files that may (and technically probably do) constitute an unauthorized copy under the Windows license. People who have used Windows for years may also find the different arrangements of user interface objects and how to interact with them to get the result they expect to be troublesome.

Some of the advice regarding the adoption of live CDs targets those who have never used a Live CD and are interested in learning how. That is definitely not the average user. The average user is not going to use a live CD until it’s handed to them free of headaches, especially not as long as individual financial liability is as limited as it is or until after their identity is actually ruined.

Neither of these configurations — separate computer or live CD — protect the user from phishing or social engineering (used solely in about 50% of attacks), or network-based attacks such as rogue DCHP servers, ARP poisoning, and rogue proxies. It won’t protect anyone against the breach of a bank system or a retailer’s point-of-sale, but those are not under the control of the end user.

Live CDs reduce the overall risk, but for a very small subset of users. Other, larger risks stem from issues not addressed by a live CD. The separate computer configuration is even easier to justify given the low cost of adequately equipped used systems, devices like netbooks, and brand-new economy desktops. Many people have an old computer that might fit the bill, but even if you have to purchase a system for this, the cost will almost certainly be lower than the impact of an act of account takeover fraud. Using a separate computer exclusively for financial transactions is easier to understand, comes with fewer pitfalls, and appeals to a much larger user base. The fewer victims, the better.

The Space Weather Enterprise Forum was held on June 8, 2010, at the National Press Club in Washington, DC. NASA, The National Aeronautic and Space Administration (NASA) and the National Oceanic and Atmospheric Administration (NOAA) are the two U.S. agencies that track space weather in near-earth space and are the stars of this conference. “Space weather” is a term covering a number of phenomena primarily related to the interaction between solar activity and a planet’s geomagnetic field. An example is a solar flare that launches charged particles against the earth’s magnetic field, resulting in beautiful auroras at extreme latitudes and broadband interference with high-frequency radio communication.

What does this have to do with information system security? The information security triad is the protection of confidentiality, integrity, and availability (CIA). Space weather has everything to do with availability.

NASA warns that the sun will soon become much more active over the next couple of years, perhaps enough to cause geomagnetic storms of unprecedented strength, or to damage and disable the electrical and electronic systems on which modern civilization depends. The press conjures images of a doomsday scenario: emergency services, the financial infrastructure, electrical power generation and distribution, aviation and marine systems, satellite navigation, newer automobiles, home computers, and the Internet may all be rendered useless in a space weather event.

These disasters could theoretically happen. However, even Dr. Richard Fisher, the director of NASA’s Heliophysics division with 20 years at the agency, admitted that it was unlikely.

Space weather events have undesirable effects on electronics systems every day. The doomsday scenario is based on the convergence of a normal maximum in solar activity (which happens about every eleven years) with a solar “super storm” that typically occurs only a few times over the average human lifespan. “Space weather forecasting is still in its infancy,” admits Thomas Bogdan, director of NOAA’s Space Weather Prediction Center. There have been a number of large variations in typical solar cycle activity that have run counter to predictions, but the solar cycle is relatively regular and easy to predict compared to the solar super storms.

High Frequency (HF) radio operators depend on solar activity to energize the earth’s ionosphere so that long-range communications are possible. Some layers of the atmosphere stay energized for continuous communications, but some unusual (and very exciting) radio propagation occurs when solar storms energize the Es or “sporadic E” layer. Because of these phenomena, HF radio operators, including amateur radio operators or “hams”, track many dimensions of solar activity on a constant basis to determine which frequencies, modes, and directions are best suited for long-range radio communication.

The same space weather that could impact the systems mentioned in this article also cause Sporadic E energizing. Hams track solar weather, specifically sunspots, solar flares, CMEs (coronal mass ejections), and their affect on the A and K indices, for example, using web sites like these:

http://www.solen.info/solar/
http://www.hamqsl.com/solar.html

How good is recent solar activity prediction? Hams who specialize in tracking Solar Cycle 27, the current activity cycle, report disappointment. The general consensus for cycle 27 is low average activity, and peak cycle 27 activity well below that of recent cycle peaks, despite predictions to the contrary.

Recent solar activity peaks have been very high. Carbon-14 measurements show that modern maximums are above the Medieval Maximum that lasted for nearly 300 years. If it is truly a cycle, we should be expecting an average decrease. Even though the cycle will hit its peak in the next few years, the peak is likely to be a relatively weak one compared to others in the electronic age.

The key to the doomsday scenario is the combination of a relatively high cycle peak with a solar super storm, in which the Sun’s temperature reaches more than 10,000 degrees Fahrenheit and produces large amounts of magnetic and charged particle flux. The problem is that these storms are not predictable. Solar activity is directly proportional to electronic and communications problems: the more activity, the more probems. If the storm and high peak activity concide, this would be an exceptional — and exceptionally unlikely — case that could cause an exceptional number of problems.

While a solar “super storm” caused telegraph outages in 1859, most modern electronics are designed, tested, and sent to market in a time of historically high solar activity. While miniaturization and the nanometer processes used to manufacture modern computer chips could make some systems more vulnerable to such storms, there have also been improvements in circuit design, materials, grounding, and shielding that offset such vulnerabilities. These are important elements in modern system design, especially for critical infrastructure, military and defense, and especially in an age of exotic weapons such as tactical electromagnetic pulse (EMP) “bombs”. These design improvements eventually trickle down to consumer electronics, so your personal MP3 player is much less likely to stop working during a solar storm than a CB Radio from the 1970s.

Preparative measures are your best line of defense, including improved grounding, shielding, and other circuit protection mechanisms, as well as planning which backup systems and alternative methods are required during an outage. In a business continuity context, space weather is a natural disaster scenario similar to pandemic flu or a hurricane.

Space weather events are not a negligible threat. Like tornados, accurate prediction is difficult until the last minute, and there is no way of avoiding them once they happen. But in a world of limited resources, its significance in daily operations and the likelihood of an impact to vital information systems is small compared to the threats we face every day: software vulnerabilities, a lack of access controls, and criminals and fraudsters.

The SecureWorks CTU^SM is closely monitoring a 0-day vulnerability in multiple Microsoft Windows operating system releases. The vulnerability lies in how Windows handles hcp:// URLs, used to access help documents. An attacker may create a malicious hcp:// URL and distribute it to victims via an HTML web page, e-mail message, document, or a variety of other attack vectors. Successful exploitation of this vulnerability may allow an attacker to execute arbitrary commands, which may result in total system compromise. This vulnerability is an excellent example of a blended threat: leveraging several vulnerabilities of a lesser severity to accomplish an attack of greater severity.

The original discloser reports that Windows XP and Windows Server 2003 using Internet Explorer 8, Mozilla Firefox, and Google Chrome are affected. Microsoft has reported that Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 are not vulnerable to this attack. Microsoft has released Microsoft Security Advisory 2219475 discussing the details of this vulnerability.

When invoked using an hcp:// URL, Windows Help Center uses a whitelist to only allow certain help documents and parameters. An error in the MPC::HTML::UrlUnescapeW() function bypasses this whitelist, permitting access to any help documents on a system. Combined with a known DOM-based (Document Object Model) cross-site scripting (XSS) vulnerability in sysinfomain.htm, hcp:// links may be created that launch arbitrary commands when visited on a vulnerable computer, although a warning dialog box displays to the victim before the command can launch.

Figure 1. Warning dialog to allow command execution.

Figure 2. Successful execution of calc.exe.

The warning dialog may be suppressed when the exploit is placed in an IFRAME in an .ASX file containing an HtmlView element. This approach is advantageous to a potential adversary, because viewing a malicious web page or e-mail may be all that is required to successfully exploit the vulnerability. Other methods of suppressing the warning dialog box may also exist. Proof of concept code is available at the following site:

http://seclists.org/fulldisclosure/2010/Jun/205

An unofficial hotfix has been released by the original discloser; however this patch may be bypassed as it does not properly correct the underlying vulnerability. At this time, there is no official patch available. Disabling the HCP protocol handler is the recommended mitigation, but doing so will impact some legitimate Windows Help Center functionality. This mitigation may also be pushed to multiple clients using Group Policy.

Before modifying the registry, the CTU recommends you export a copy of the HCP registry hive so it may be restored later if needed.

1. Click Start, and then click Run.
2. Type regedit, and then click OK.
3. Expand HKEY_CLASSES_ROOT, and then highlight the HCP key.
4. Right-click the HCP key, and then click Export.
5. Export the registry hive to a local file.
6. Right-click the HCP key, and then click Delete.

References:

• http://www.microsoft.com/technet/security/advisory/2219475.mspx
• http://lock.cmpxchg8b.com/b10a58b75029f79b5f93f4add3ddf992/ADVISORY
• http://blogs.technet.com/b/msrc/archive/2010/06/10/windows-help-vulnerability-disclosure.aspx
• http://secunia.com/blog/103

Recent rumors that the Internet is doomed are just as overblown as all the rest, except perhaps when AOL started letting its users onto the Internet – a fate from which the Internet never really recovered. The current rumor relates to DNSSEC (also known as Domain Name System Security Extensions), which cryptographically signs DNS results. This is done to prevent DNS cache poisoning and similar spoofing attacks. A number of sources have reported that the root DNS servers will begin signing responses this Wednesday, May 5, 2010. The concern is that after DNS responses are signed, they will be larger than normal DNS packets. To make things more concerning, older versions of the DNS specification state that DNS responses will never be larger than 512 bytes. There may be a large number of legacy firewall rules that still enforce this restriction. If the larger packets trip one of these rules, they will be discarded.

The good news is that only one Root DNS server, J, will be changed on May 5. DNSSEC support has been rolled out to all root servers. May 5 actually marks the end of this rollout process that began in January 2010. Even then, the changes that occur on May 5 are just a test. This is known as the DURZ rollout. DURZ stands for Deliberately Unvalidatable Root Zone – it’s a fake key that cannot be used to validate the zone. The actual root key has not been created yet. ICANN has solicited applications from individuals to become trusted community representatives to verify the creation of the root key and its use to sign the root zone.

All the other root servers are already serving signed zones, but only if you ask for it. According to RFC 3225, the response will only be signed if the DO (DNSSEC OK) flag is set. As long as your resolver or client doesn’t set this flag, you shouldn’t see any difference.

It’s not a bad idea to test if DNSSEC works in your environment. You can do this by using DNS-ORAC’s reply size test tool, or simply using dig. If you add the argument “+dnssec” to a dig query, then it will turn on the DO flag. Please note these tests are to verify if a firewall or other device will block large packets. The tests will not tell you if your DNS resolver software is capable of supporting DNSSEC.

For Example:

Normal (none) DNSSEC Query:


user@prompt$ dig edu @199.7.83.42

;; Query time: 29 msec
;; SERVER: 199.7.83.42#53(199.7.83.42)
;; WHEN: Mon May 3 14:22:30 2010
;; MSG SIZE rcvd: 292



Query with DNSSEC OK flag set:


user@prompt$ dig +dnssec edu @199.7.83.42

;; Query time: 27 msec
;; SERVER: 199.7.83.42#53(199.7.83.42)
^[[A;; WHEN: Mon May 3 14:22:23 2010
;; MSG SIZE rcvd: 486


The signed response includes the RRSIG ( Resource Record Digital Signature) record, which contains the signature itself. If you make a dig query with +DNSSEC set and you see a response that includes an RRSIG, you will likely be able to use signed zones without a problem. Furthermore, because the DO (DNSSEC OK) flag is not set by default in the majority of DNS clients you shouldn't experience any odd behavior with this change.

This week we saw the proceedings of the 3rd USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET ‘10). Past years had seen the release of plenty of novel and groundbreaking research, so expectations were high.

A group of researchers from I.N.R.I.A. in France published an impressive paper on new techniques for identifying and tracking users of the BitTorrent protocol titled, “Spying the World from Your Laptop: Identifying and Profiling Content Providers and Big Downloaders in BitTorrent” (Abstract, Full paper, Slides). From their website, I.N.R.I.A. is the French national institute for research in computer science and control.

In the paper, the researchers describe a series of experiments they performed to identify and profile BitTorrent users. In particular, the researchers tested methods to indentify two important classes of BitTorrent user: “Content Providers” and “Big Downloaders”.

A content provider is a user who provides the initial seed (i.e., complete copy) of a particular item of content (e.g., a video file). The researchers report that they were able to successfully identify the content provider for 70% of contents monitored by their system. Their findings conclude that relatively few content providers insert most of the content. Of the top 20 content providers identified, half were using the IP addresses of machines hosted by two French and German providers. However, further analysis showed that the content providers were probably not French or German nationals, and further, that the nationality of a content provider is difficult to extrapolate from the physical location of the computer they use.

Like many networking technologies, the BitTorrent protocol may be used both legally and illegally (e.g., to illegally share copyrighted content). While parties using BitTorrent for illegal purposes obviously have a vested interest in avoiding identification, legitimate users also have reason to be concerned by these findings. With a better understanding of the ease at which they may be identified and tracked, legitimate users may want to weigh the privacy risks involved in sharing their content over BitTorrent.

Last night and this morning, a number of people received an email that looks like this:

The message contains a file called “doc.pdf”. That file was, of course, malicious in nature. It used the PDF Launch vulnerability to echo commands into a batch file and then run the Emold downloader trojan. Let’s take a look at the code.

This code sample uses cmd.exe to write text to a file called script.vbs. The code then executes script.vbs and batscript.vbs.

Let’s look at how script.vbs ends up:

When the code executes script.vbs, the VBS file opens doc.pdf and looks for the tags “SS” and “EE” to mark the beginning and end of a section of the pdf. It extracts that section, manipulates the text, and then writes the result to batscript.vbs.

Next, let’s look what’s in the tagged section of doc.pdf that ends up in batscript.vbs:

The array stored in b is actually an obfuscated executable file that is stored in game.exe. After running game.exe, this script (executed in batscript.vbs) cleans up after itself by removing game.exe, batscript.vbs, and script.vbs.

Game.exe is the Emold trojan. Emold is a generic downloader that can be used to install any number of second stage trojans. It can be identified by the presence of the C:/Program Files/Microsoft Common/svchost.exe file, the “software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\explorer.exe” registry key, and because it (currently) phones home to jademason.com.

Adobe has stated that the Launch functionality is a feature, not a bug. Adobe is looking into the issue, but has not said what action, if any, it intends to take to mitigate the danger. Their post on this issue does include directions for turning off this functionality.

Last week, embattled former U.S. Governor of Illinois Rod Blagojevich filed a motion to subpoena President Barack Obama. The motion had some of the allegations against the President redacted. The redaction was done simply by superimposing black bars over some of the text. The obscured text could be retrieved simply by pasting it into another document. This fact was quickly discovered and reported in the media.

This example is just one of many redaction failures that have made headlines. While not many are as salacious as a legal document accusing a sitting president of wrongdoing, many important documents have been exposed in this fashion. In December 2009, the Transportation Security Administration (TSA) released a sensitive security manual that incorrectly redacted information, including images of authorized identification for federal agents.

Many non-technical users are unaware of the correct ways to redact documents. Luckily, the National Security Agency (NSA) is here to help. The NSA, the lead U.S. Federal agency for cybersecurity, has published a guide called Redacting with Confidence: How to Safely Publish Sanitized Reports Converted From Word 2007 to PDF. While the guide is specific to the document formats listed in the title, its advice is applicable to many kinds of documents. The first page of the guide even mentions that superimposing black bars over material to be redacted is one of the most common mistakes. It’s also easy to refer non-technical users to this guide — “just tell them to Google for NSA and redaction” — it will be the first hit.

Your web browsers by default trust many organizations you’re probably not familiar with. Many are located in countries overseas – some in not so friendly areas of the world. But what diligence has your organization done on these companies, if any? This may represent a security hole that doesn’t show up in your risk assessments.

A Certificate Authority (CA) is an organization or system which has the ability to digitally sign SSL certificates. These are the governing bodies of the SSL encryption that is used nearly everywhere on the web for transferring sensitive data securely. By default your browser trusts CAs like Microsoft, GoDaddy and others. Without these trust relationships you’d have to manually configure them or hit “OK” every time you went to a SSL site. So default Trusted CAs are a good thing.

But that means these organizations are trusted implicitly with the security of some of your organization’s most protected online transactions. What due diligence have you done on these providers that your browser trusts? Have you determined the sufficiency of their SAS 70 report? Do you know whether or not they report to you any data breaches which may have affected your confidential transmissions? Do you really want to explicitly trust foreign-owned companies with any information that may interest their government?

For some organizations this may be “tin foil hat” material. For others, though, this may pose a real security risk. If you’re interested in learning more about this kind of thing there is plenty of material published on SSL Certificate attacks. If these are combined with more traditional attacks such as DNS poisoning, man-in-the-middle, ARP spoofing and others, they could become a very real threat to your organization.

On March 5, 2010, Energizer and US-CERT announced that some consumer Energizer DUO USB battery chargers had shipped with a malicious software trojan. The hardware device is used to charge Nickel Metal Hydride (NiMH) batteries from both a wall outlet and USB connection. The charger includes Windows software to allow the user to view the battery charging status when connected to a PC via USB. This software was found to contain malware.

Here is the ThreatExpert report for a sample of this trojan with an MD5 of 3f4f10b927677e45a495d0cdd4390aaf

The installer software places a file named "usbcharger.dll" in the applications directory and "arucer.dll" in the Windows system32 directory.

The trojan modifies the registry by adding itself to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key.

The trojan also spawns a listener on port 7777/tcp. This is a bit curious, because widespread firewalling and NAT have pushed the authors of backdoor trojans to adopt a connect back or reverse shell approach. A listener on 7777/tcp would only typically be accessible within the local network, and even then only after the trojan has punched a hole in the host firewall found on more recent Windows platforms.

The capabilities of this trojan include the ability to:

• List directories
• Send and receive files
• Execute programs
• Delete files

The decompiled .dll that is installed indicates the origins may be Chinese:

--a-- W32i   DLL CHS    1.0.0.1  shp   28,672 05-10-2007 arucer.dll
Language        0x0804 (Chinese   (PRC))
CharSet         0x04b0 Unicode
OleSelfRegister Disabled
CompanyName
FileDescription Arucer DLL
InternalName    Arucer
OriginalFilenam Arucer.DLL
ProductName     Arucer Dynamic Link   Library
ProductVersion  1, 0, 0, 1
FileVersion     1, 0, 0, 1
LegalCopyright  ???? (C) 2006
LegalTrademarks

A mutex name also suggests a possible Chinese origin:

liuhong-061220

The purpose of the backdoor and how it was included in the distributed software was not disclosed.

The disclosure from Energizer was soon followed by another report of compromised consumer electronic equipment. On March 8, 2010, Panda Security’s Research blog reported that they had received a new Vodafone HTC Magic with Google’s Android OS that was infected with Butterfly Bot (a.k.a. Mariposa). In addition, it was reported that the handset contained Conficker and a password stealer identified as "Lineage". The infected Vodafone handset was reported to be an isolated incident, however Panda subsequently reported that Spanish security outfit S21sec had also obtained a compromised HTC Magic handset directly through Vodafone’s website. Vodafone has recently confirmed shipping at least 3000 handsets with Mariposa.

Of course, this is not the first time consumer electronics devices have reached consumers with malicious software. Digital music players have shipped with Windows viruses. New hard drives come with trojans. Digital picture frames get bundled with trojans. Compact discs intentionally sold with rootkits. It is important to remember that any device or removable media could be used to store malicious code.