Posts Tagged ‘USB drives’
Wednesday, May 15, 2013 @ 04:05 PM gHale
There is a new variant of the Dorkbot worm designed to spread from one computer to the other by abusing Facebook’s internal chat.
Once it infects a device, it is capable of monitoring the victim’s browsing activities, but it’s also capable of stealing their personal information such as usernames and passwords, said researchers at Bitdefender. Moreover, cybercriminals can use it to download additional malicious components onto the infected machine.
This comes as more of a warning to be aware because more manufacturing automation companies using social media for the organizations.
The Dorkbot malware family is most prevalent in the United States, India, Portugal, Romania, Germany, Turkey and the United Kingdom, the researchers said.
To trick users into executing it, the malware poses as a harmless .jpg image file.
Dorkbot, which uses IRC to send and receive data, can also spread via USB drives connected to an infected device.
To protect against this threat, Bitdefender researchers advise users to avoid clicking on suspicious links received via instant messages, even if they appear to come from a friend.
Tuesday, February 26, 2013 @ 02:02 PM gHale
Malicious software downloaded by offshore oil workers incapacitated computer networks on some rigs and platforms, exposing gaps in security.
Some of the infected files — featuring pornography or music piracy, for example — downloaded directly through satellite connections, while other malicious files came aboard on laptops and USB drives infected on land.
Oil rigs, like any major organization or company, have a target on their backs and need to develop a defense in depth program that can ward off or isolate attacks that could injure the network.
“The tide is slowly rising and incrementally making things better, but the exposed area is really so high that it’s not really fast enough to limit the risk,” said Misha Govshteyn, co-founder of Alert Logic, a network security company, in a Houston Chronicle report.
Malware infections have occurred at several offshore rigs and platforms, knocking some offline, security professionals said.
When infected devices connected to isolated networks, the malware spread and created problems. One instance, on a facility in the Gulf of Mexico, caused a system to lock up, Govshteyn said. “They literally had a worm that was flooding their network, and they’re out in the middle of the ocean.”
Other infections have had similarly disruptive effects, though none has involved a malicious attack that has had safety repercussions, security professionals said.
Jack Whitsitt, principal tactical analyst for the National Electric Sector Cybersecurity Organization, said in the same report a typical malware infection on energy infrastructure would likely cause no serious problems. But he said a tailored attack, engineered to target a facility through widely distributed malware, could have dangerous repercussions.
Is that just a scare tactic as many have employed over the years? If companies understand how Stuxnet propagated throughout the industrial control system at the Natanz nuclear enrichment facility in Iran, then it would be very easy to understand how an attacker could get into a system control an offshore platform.
With enough knowledge of a facility like an oil platform, refinery, or pipeline network, a cyber attack that used distributed malware could lead to physical damage, Whitsitt said.
If there is a targeted attack, preventing malware from getting onto a network is almost impossible, but a solid defense in depth portfolio will help focus on the attack and allow the user time to thwart the onslaught.
A Department of Homeland Security update in January said 40 percent of the intentional cyber attacks last year targeted energy infrastructure.
Wednesday, January 2, 2013 @ 12:01 PM gHale
USB drives are a great tool to help automation professional do their jobs, however, they can also be a malware nightmare for an industrial control system (ICS), which is exactly what happed at one power generation facility were security wags found common and sophisticated malware on the ICS.
The discovery occurred after a worker asked the company’s IT staff to inspect his USB drive after experiencing intermittent issues with the drive’s operation, according to a report on ICS-CERT. The employee routinely used this USB drive for backing up control systems configurations within the control environment.
When the IT employee inserted the drive into a computer with up-to-date antivirus software, the antivirus software produced three positive hits. After analyzing the results, officials found one sample linked to known sophisticated malware. Following analysis and at the request of the customer, an onsite team from ICS-CERT went to the facility and started an investigation.
Once onsite, the ICS-CERT team found a handful of machines that likely had contact with the tainted USB drive. They examined the machines and they took drive images for in-depth analysis. ICS-CERT also performed preliminary onsite analysis of those machines and discovered signs of the sophisticated malware on two engineering workstations, both critical to the operation of the control environment.
The team then conducted a detailed analysis and found these workstations had no backups, and an ineffective or failed cleanup would have significantly impaired their operations.
With confirmation the sophisticated malware existed on the two engineering workstations, attention shifted quickly to the remaining eleven operator stations in the control environment. Manual analysis using the known characteristics of the malware revealed no signs of the malicious software on the remaining work stations.
After the onsite visit, ICS-CERT had two primary goals for assisting the organization.
• Identify effective and safe cleaning procedures that could remove the malicious artifacts.
• Identify best practices to prevent and detect future malware infections in this organization’s control environment.
ICS-CERT obtained a number of images and other artifacts for additional offsite analysis. The in-depth analysis of the two engineering workstations was critical in identifying safe and effective malware cleaning procedures. The team developed cleaning procedures in close coordination with the organization’s control system vendor to ensure it would not adversely impact the workstations.
While the implementation of an antivirus solution presents some challenges in a control system environment, it could have been effective in identifying the common and the sophisticated malware discovered on the USB drive and the engineering workstations.
In addition to backing up the engineering workstation configuration files, the USB drive was also transporting malware. A good backup procedure should incorporate best practices for USB usage to ensure malicious content does not spread or end up inadvertently introduced, especially in critical control environments. This procedure should include cleaning the USB device before each use or the use of write-once media such as CDs or DVDs.
The organization also found during the course of the investigation it had no backups for the two engineering workstations. Those workstations were vital to the facility operation and, if lost, damaged, or inoperable, could have a significant operational impact. The recommended practice is to maintain a system of “hot spares” or other effective backups for all critical systems.
Tuesday, March 20, 2012 @ 06:03 PM gHale
Cisco Systems wants to make sure mobile devices get secure, so it is expanding its services to enable companies to manage and secure private mobile devices.
While corporate IT departments have systems in place to ensure desktop security and to prevent data loss over the Internet or through emails, they are now facing the challenge of dealing with devices such as smartphones, tablets, USB drives or laptops that can open the door to malware or data loss.
That’s where Cisco sees growth opportunities for its services, which expanded to enable businesses to provide control over individual access and security, beyond merely connecting outside devices to a company network, the company said.
Allowing staff to use any device they choose is becoming a differentiator for companies seeking to hire young employees but it can become a nightmare for the IT department.
According to a study by the Ponemon Institute, organizations often do not know if and what kind of data is leaving their networks through non-secure mobile devices.
“Fifty-nine percent of respondents report that employees circumvent or disengage security features, such as passwords and key locks, on corporate and personal mobile devices,” the study found.
However, only 39 percent have the necessary security controls to address the risk, and only 45 percent have enforceable policies, the study also said.
Cisco, which allows staff to use their own devices, said earlier this month that staff using personal devices at the company grew 52 percent in the past year to 50,538 from 33,354 in 2010, with iPhones dominating with around 21,000 devices used by employees.
Wednesday, March 16, 2011 @ 09:03 PM gHale
EDITOR’S NOTE: The stage is now set for Stuxnet to infiltrate an industrial control system. Go back in time before anyone discovered the worm and see how it was able to penetrate a system. After understanding that frightening journey, it is easy to see how Stuxnet was one of the most complex and well-engineered worms ever seen. Security professionals Eric Byres, Andrew Ginter and Joel Langill teamed to publish a white paper entitled “How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems.” This is the fourth part in a series of stories detailing just how the Stuxnet worm was able to infiltrate a system, and how automation professionals can keep an eye out for the next type of attack.
By Eric Byres, Andrew Ginter and Joel Langill
Given the well-secured industrial control system, it seems very unlikely a worm like Stuxnet could ever penetrate all the way to the PLCs. Yet clearly it did.
Siemens reported 22 sites that experienced infected control systems and certainly there were other sites, such as those with other vendors’ products (and would not report infections back to Siemens). The goal here is to suggest possible answers to the vexing problem of how the worm made it through to the PLCs.
Part I: Stuxnet attacked the Siemens SIMATIC PCS 7; Why that system?
Part II: How did Stuxnet infect a system?
Part III: A “high security site” targeted by Stuxnet or the Next Gen of Stuxnet-like worms.
Part IV: How Stuxnet infected a minor computer and then got deep inside a control system.
Part V: What should this mean for security of industrial control systems in the future?
Download the complete White Paper at Tofino Security.
Talk to Me: Stuxnet: Joint Operation Nets Victim
To answer that question, let us go one year back in time, to March 1, 2010. Stuxnet has been refined to its mature form, using the shortcut vulnerability rather than common “autorun.inf” trick to propagate via USB drives. No patches exist for the zero-day vulnerabilities the worm uses. No anti-virus signatures exist for the worm. No security researchers know the worm exist. The stage is set.
Now using the following illustration as a road map, we will follow the Stuxnet as it compromises the state-of-the-art high security network we described last week, infiltrates the PLCs and destroys the target industrial process. And as a bonus, at each stage we also will look at alternative pathways the worm could have taken.
Initial Handoff of the Worm
In order to begin its infection of the intended site, Stuxnet’s creators needed to transfer the worm to an unwitting employee who would “carry” it into his or her company. We can only guess at how these handoffs might have occurred, but Stuxnet’s creators had a number of options open to them.
One possibility is that a saboteur working at contractor’s office might have given a target employee an infected USB drive containing technical documents. Or the handoff might have happened at an industry tradeshow, where free USB drives are common give-aways for the distribution of conference materials (in 2009, one of the authors received a “new” USB drive at a major vendor’s tradeshow as a gift — that USB drive was infected with a different worm).
Maybe a USB drive wasn’t used at all. Stuxnet could have been launched toward the victim company through a targeted email attack. The email would contain a special dropper program designed to install Stuxnet when an attached document was opened by the victim. The creators of the recent Night Dragon attacks used infected PDF files to seed their victims.
The initial infection could also occur by a contractor supplying PLC project files deliberately infected. Due to the nature of contractor/client relationships and the need for continuous collaboration, a variety of project files are freely exchanged between team members. These files not only include the PCS 7 project files the Stuxnet worm could piggy back on, but also other potentially vulnerable file formats including drawing, spreadsheet, database and PDF files that future worms could exploit.
Exactly how the initial handoff occurred will never be known. But what we do know (thanks to some excellent analysis by Symantec) is Stuxnet’s creators performed this handoff at least ten times between June 2009 and May 2010. We also know these handoffs were made to at least five separate target organizations. In other words, the owners of Stuxnet continued to introduce the worm until they were convinced it had reached and destroyed its target industrial process. Only Stuxnet’s very public discovery ended these repeated injections of Stuxnet into the victim’s networks.
Infection of Initial Enterprise Computer
Once an employee had an infected USB drive, it would only be a matter time before it was plugged into a workstation and viewed using Windows Explorer, starting the infection process. Since there were no signatures for the Stuxnet worm in March of 2010, the workstation’s anti-virus software would not generate any alerts. The fact the workstation is fully patched is of no help, because the LNK vulnerability on shortcut files has no patch. Nor do the escalation of privilege vulnerabilities the worm uses to gain system-level access on the workstation. The worm was also able to install “rootkit” software that hides the files used by the worm when browsing the infected flash drive. The victim has no chance.
Propagation to other Enterprise Computers
Once on a network, Stuxnet becomes aggressive. Within a few hours, the worm would likely spread to printer servers and file servers on the Enterprise Control Network connected to the compromised workstation. Just how aggressive is illustrated in graphic below which shows a graph of the machines infected from a single successful handoff that occurred on May 11, 2011.
At this point, the worm might lie dormant, infecting new USB flash drives as they are inserted into compromised computers, and waiting for someone to carry such a flash drive (and the worm) to a protected network. Alternatively, it may request new instructions from a command and control server. All personnel carrying and using infected flash drives would be unaware the worm is now on their drives, because the rootkit hides the worm’s files from the user.
Alternative pathways: Some additional alternative paths for infection of the Enterprise Control Network include:
- The employee may have attached an “approved” external drive to an infected machine while visiting a contractor and subsequently brought this drive back into the company network.
- The employee may have connected his or her laptop to a compromised network offsite, and thus infected the laptop and then subsequently connected it to the Enterprise Control Network on his or her return.
- A contractor may have visited the site, bringing and using a compromised external drive on the site network.
- A contractor may have visited the site, bringing and using a compromised laptop on the site network.
- A contractor or employee at another facility may have used a file share at this site over the WAN and so compromised the Enterprise Control Network.
Penetrating the Perimeter Network
Very quickly a large number of the workstations on the Enterprise Control Network would be infected. Almost certainly one of these computers would belong to an employee who would interact with the person who manages the process historian server on the Perimeter Network. Now the worm has a potential path deeper into the network.
For example, as is common in the industry, the manager has a file share configured on his workstation, as do most employees in that group. The control system team uses the shares on their own workstations to exchange large files with each other over the Enterprise Control Network, rather than exchange the files via the space-limited file servers located on the Enterprise Control Network. Of course, only specific domain accounts have access these shares.
Stuxnet uses the domain credentials of the user logged into the compromised machine to send a copy of itself to the manager’s workstation and activates that copy, compromising that workstation. Stuxnet is now ready to make its move deeper into the control system.
In quite a few plants, the historian manager would routinely access the Siemens WinCC Central Archive Server (CAS) historian server from his workstation over a VPN. Typically, the administrator uses the web interface and Siemens OS Client to the historian to access the CAS server. The web interface provides a view of functionality the historian exposes to users, and the OS Client allows the administrator to access advanced features of the historian, used primarily for configuration and administration tasks.
Through the manager’s compromised workstation the Stuxnet worm contacts the local instance of the SQLServer database “client” on the compromised workstation and discovers the OS Clients’ connection to the WinCC database installed as part of all CAS servers. The worm contacts the WinCC SQLServer database on the CAS server and propagates to the CAS server on the Perimeter Network through that database connection. The worm installs itself on the CAS server by manipulating the CAS database contents and stored procedures within the database. The worm now has a foothold on the Perimeter Network.
Alternative pathways: Some alternate paths of infection of the Perimeter Network include:
- At many “real world” sites, companies do not routinely patch Perimeter Network hosts. As a result, any VPN connection from a compromised host on the Enterprise Control Network to a host on the Perimeter Network using common Windows RPC communications is at risk.
- While it does not follow the Siemens security recommendations, it is not unusual for the VPN connections from Enterprise Control Network workstations to the Perimeter Network to not restrict communications to specific ports and hosts. In such cases, any Enterprise Control Network workstation with a VPN connection to the Perimeter Network puts at risk every server or workstation on the Perimeter Network with file sharing enabled or a printer connected.
- A contractor or vendor using a remote access mechanism to provide assistance with the support of hosts on the Perimeter Network may remotely access that network from a compromised laptop or workstation. If the contractor can communicate with any exposed file shares or print spoolers on the Perimeter Network that would permit compromise of those hosts. If the contractor or vendor’s workstation can communicate with any unpatched hosts exposing the MS08-067 vulnerability, that channel also permits compromise of hosts on the Perimeter Network.
- While this does not follow the Siemens security recommendations, site administrators on the Enterprise Control Network sometimes use file shares to exchange information with servers on the Perimeter Network. Such file shares expose the Perimeter Network to compromise.
Propagation to other Perimeter Network Computers
Once the worm has a foothold in the Perimeter Network, it would start aggressively spreading on this virgin network, just like it did on the Enterprise Control Network. Certainly it would attempt to infect any print servers and file servers it could discover. The worm would also identify the WinCC software installed on the Web Navigation and CAS Servers, and would likely infect these local databases. If the Web Navigation Server configuration allows it to use Terminal Services for remote access, there could also be STEP 7 software installed on this host, offering the worm the opportunity to install itself inside the STEP 7 project files.
Closing in for the Kill: Propagation to Process Control Network and Control System Network
Now Stuxnet is only a few hops from its final target. Once the worm has infected the PCS 7 servers in the Perimeter Network, it is trivial to utilize the network connections to the servers located in the Process Control Network. Now it would start moving into the WinCC Servers that connect directly to the PLCs
To make matters worse, once there is an infection in the STEP 7 project files, it is only a matter of time before an authorized user copies a project file to the Process Control or Control System Networks. If an administrator were to copy these files to another plant at another site and use the files there, these STEP 7 project files would lead to compromise of that new site by the Stuxnet worm.
Finally, the WinCC CAS on the Perimeter Network has database connections configured through the ISA server, so the historian server can request historical data from Operator System (OS) Servers on the Process Control Network. The Stuxnet worm can propagate over these connections into these OS Servers and infect all servers on the Process Control Network which expose either print servers, file servers or which have WinCC or STEP 7 software installed on them. STEP 7 is typically on engineering stations, while WinCC is common on operator and engineering stations.
Alternative pathways: Alternative paths for infection of the Process Control and Control System Networks include:
- File shares or print spoolers may have exposure to hosts on the Perimeter Network. Even if a site did not mean to expose such services on the Process Control Network to the Perimeter Network, WinCC components on the Perimeter Network make heavy use of Windows RPC communications to interact with components on the Process Control Network. Print spooling and file sharing use RPC communications. Any path through the Microsoft Internet Security and Acceleration (ISA) firewall that permits remote procedure calls (RPC) communication would permit connections to print spoolers and file shares, regardless if personnel designing ISA firewall rules anticipated such connections. For example, if an OPC Classic server (such as OPC Data Access) on the Process Control Network serves information to an application on the Perimeter Network, that connection exposes the RPC communications path since it is the foundation of the OPC Classic protocol.
- Most servers on the Perimeter Network use database connections to servers on the Process Control Network to acquire data for presentation to enterprise users. If any of those servers or workstations becomes compromised, the worm can propagate over that machine’s database connection to the Process Control Network.
- PLC programming projects routinely carry out on test beds for which security measures are weaker than those applied to production networks. Such test beds may become compromised by removable drives, remote vendors, connections to compromised enterprise hosts or other means. If those infected project files communicate to hosts on Process Control and Control System Networks, the worm compromises those new hosts.
- A contractor or vendor using a remote access mechanism to provide assistance with the support of hosts on the Process Control Network may remotely access that network from a compromised laptop or workstation. If the contractor can communicate with any exposed file shares or print spoolers on the Process Control Network that would permit compromise of those hosts. If the contractor or vendor’s workstation can communicate with any unpatched hosts exposing the MS08-067 vulnerability, that channel also permits compromise of hosts on the Process Control Network.
- Using an infected external drive on any single host on the Process Control Network would compromise that host and the other computers on that network.
The Final Attack
Stuxnet will now be able “smell” its victim and will begin to move in for the kill. Some of the compromised OS and WinCC Servers will manage connections to the S7 PLCs that control the physical process. When Stuxnet discovers one of these, it installs a special driver on the computer, effectively hiding any modified code from administrators or engineers later querying the PLCs. This makes the worm “invisible” once it is on the PLC.
The worm then connects from the servers to all available PLCs and looks for specific models of Siemens PLCs (namely 6ES7-315-2 and 6ES7-417). If it is able to locate one of these two models, it “fingerprints” the PLC by checking for the existence of certain process configurations and strings in the PLC.
If Stuxnet finds what it is looking for in the PLC, it starts one of three sequences to inject different STEP 7 code “payloads” into the PLC. The worm replaces the PLC’s PROFIBUS driver and then significantly modifies the main PLC program block (Organizational Block 1) and the primary watchdog block (Organizational Block 35). As well, depending on which sequence is selected, the worm will inject between 17 and 32 additional function blocks and data blocks into the PLC.
Once the modified logic is running on one PLC, it begins to attempt connection to other PLCs that are infected. These may have been infected through the same STEP 7 system or via a different Engineering Station, WinCC Server or other computer. It then synchronizes an attack sequence in all the PLCs so the attack will occur simultaneously across multiple PLCs.
This attack sequence is designed to radically change the output frequencies of specific Variable Frequency Drives (VFDs) and thus the speed of the motors connected to them, essentially sabotaging an industrial process. At the same time, it plays back previously recorded process data to the WinCC Servers, making the operators believe that all is well in their process, when in fact Stuxnet is tearing it appear.
Lesson: There are many pathways to PLCs
This analysis shows that even at an industrial site using security best practices, there are many ways that an advanced cyber threat such as Stuxnet can move from the outside world, through the various networks and reach the process controllers. In the final installment in this series we will explore what owners, designers and operators of ICS need to consider in order to prepare for the next Stuxnet.
Next: What does the future hold for security of industrial control systems?
Eric Byres, P. Eng., ISA Fellow, is the chief technology officer at Byres Security Inc. (email@example.com); Andrew Ginter, CISSP, is the chief technology officer at Abterra Technologies (firstname.lastname@example.org) and Joel Langill, CEH, CPT, CCNA, is the chief security officer at SCADAhacker.com (email@example.com) and Dept. of Critical Infrastructure Officer with The Cyber Security Forum Initiative (csfi.us).
Monday, November 8, 2010 @ 04:11 PM gHale
As investigations into Stuxnet continue throughout the industry, one of the three pathways the worm uses to infect other computers is via the Local Area Network (LAN) communications inside the control system.
The other two paths come via infected USB drives and via infected Siemens project files.
Eric Byres, chief technology officer at Byres Security, found a way to restrict network-driven infections.
First, Byres said, you need to divide up control systems into security zones. If you are not familiar with the security zones concept, here is a brief overview.
A security zone is a group of assets that share common security requirements based on factors such as control function, operational requirements and criticality. A simple solution is to implement core zones such as:
• Safety Integrated System (SIS) zone,
• Basic Control/PLC zone,
• Supervisory/HMI zone,
• Process Information/Data Historian zone
• IT Networking zone
For additional security and reliability, you can also divide each of these primary zones into sub-zones, based on operational function. Increasing the number of zones progressively restricts the spread of a worm like Stuxnet to fewer computers, reducing risk and clean-up costs if an infection were to occur.
If you feel dividing up your network into zones of assets with similar security requirements based on factors such as control function, operational considerations and criticality is the way to go, and you have done the planning work to map out what the zones are, then you need to install an industrial firewall between the zones and implement rules that block the protocols that Stuxnet uses for infection.
Using the firewall to limit network traffic between zones to only what is needed for the system to operate, begins with deploying security appliances as the conduits between zones.
You can customize each of the security appliances with Loadable Software Modules (LSMs).
Once you load each LSM, each appliance is ready to prevent the protocols that Stuxnet uses from passing between zones. In particular three protocols need managing: Web (HTTP) traffic, Remote Procedure Call (RPC) traffic and, in Siemens systems, MSSQL traffic.
Byres went on to say: Note that I said “managed” and not just “blocked” the three protocols. Unfortunately, Stuxnet uses many of the same protocols as valid system applications, so just blocking these protocols will prevent proper operation of the control system.
Byres prepared an Application Note “Using Tofino to Control the Spread of Stuxnet Malware.” He said he uses the Tofino Industrial Security Solution as the example product for mitigation. “Tofino is our own product, so you know where my bias is. However, no matter what technology is deployed, the concepts I talk about are the same,” he said.
After configuring any security device and firewall it is very important to test to make sure that firewall rules do not disrupt industrial processes.
Preventing the spread of Stuxnet over control networks is key to maintaining safe, reliable and secure industrial systems.
Wednesday, September 8, 2010 @ 06:09 PM gHale
Flash memory infiltrates behind corporate firewalls and connects to the enterprise every day. That threat has been almost invisible for years and even now companies are not able to handle it.
Even the mighty U.S. military is not immune. They confirmed an attack on its systems in 2008 originated with a flash drive plugged into a military computer located in the Middle East. The infection “spread undetected on both classified and unclassified systems, establishing what amounted to a digital beachhead, from which data could be transferred to servers under foreign control,” U.S. Deputy Secretary of Defense William J. Lynn III wrote in a column last month.
The attack became a wakeup call for the Pentagon, which responded by banning USB flash drives for more than a year. The ban finally ended earlier this year.
While companies worry about the software-based security vulnerabilities present in their networks and systems, far fewer have locked down their systems against devices that can steal data or infect the network from behind the perimeter. If you are not sure it can happen, just look at the Stuxnet attack last month.
As part of its reintroduction of USB flash drives, the U.S. military improved its antivirus and malware capabilities, required that flash drives undergo authorization to connect to a computer, and tightened the security of authorized flash drives. The Department of Defense is also reducing its reliance on flash drives, opting for collaborative workspaces and other data-sharing portals.
Businesses have yet to lock down their own employees’ use of flash drives. In a report entitled, “Barometer of Security in SMBs,” antivirus company Panda Security found 32 percent of small and medium businesses cited USB flash drives and other external memory devices as the vector for viruses that infected the victims. In the U.S., almost half of all companies suffered from a virus via a USB flash drive.
The simple fact is if a company wants to remain secure, it has to go about educating its employees. Because USB flash drives can aid productivity, getting employees to abandon them is difficult, as the Pentagon discovered. Instead, using technologies such as encryption, role-based authentication and data-leakage protection can help reduce the threat posed by flash drives.