{{Header}} {{#seo: |description=Hardware Threat Minimization: Webcams, Microphones, Speakers (Audio Output Devices) and Wireless Devices. Speaker = Microphone. Speakers can be turned into microphones! |image=Hardwareminimize.jpg }} {{physical-mininav}} [[File:Hardwareminimize.jpg|thumb]] {{intro| Hardware Threat Minimization: Webcams, Microphones, Speakers (Audio Output Devices) and Wireless Devices. Speaker equals Microphone. Speakers can be turned into microphones! }} {{Anchor|Microphone}} = Microphones = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = Advanced adversaries already have specialized implant plug-ins which can [https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ take over the computer's microphone] and record nearby conversations. The implant is called CAPTIVATEAUDIENCE, while the webcam equivalent is called GUMFISH. https://www.wired.com/2014/03/webcams-mics / }} == Eavesdropping Risk == === Computers and Notebooks === It is recommended to check whether the computer or notebook has a microphone. Microphones are often built-in and go unnoticed. In most cases it is advisable to disable the microphone for security reasons. If {{project_name_workstation_long}} is ever compromised by malware, an adversary could eavesdrop through the microphone. One attack vector is the use of [https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ spam emails which contain malware]. Similarly, keyboard acoustic side channel attacks can use the audio leakage from keyboard typing to infer the words up to a certain degree of accuracy. https://fc16.ifca.ai/preproceedings/21_Anand.pdf Researchers continue to improve the accuracy of various techniques and attack vectors like feature extraction and classification, keyboard geometry and triangulation. Another eavesdropping risk concerns mechanical HDDs. Researchers have discovered that maliciously modified firmware is able to record Positional Error Signal (PES) data that registers minute disturbances in the platter with internal sensors; high-quality recordings of sounds like human speech could be reconstructed from this information. This attack has several limitations: https://www.extremetech.com/electronics/287324-researchers-turn-hard-drives-into-covert-listening-devices # An attacker needs to physically tamper with the targeted equipment. One possible method is hardware interception during shipping. # Sounds near the hard drive must be rather loud: * To identify human speech a 75dB minimum level is necessary, which is equivalent to a noisy argument within a few feet of the HDD. * To identify music that is playing, a 90dB level is required -- this is as loud as a lawnmower. While the SSD alternative avoids this threat, it has the drawback of uncertainty when encrypted volume headers are deleted or encryption passphrases are changed. === Phones Smartphones Smartwatches Tablets and similar Devices === Above described risks also apply to touch screen devices like smartphones and tablets. https://www.schneier.com/blog/archives/2019/04/recovering_smar.html Joanna Rutkowska, security researcher, founder of Qubes OS, removed all microphones and cameras from her smartphone (iPhone) in year 2014 and posted a photo, see [https://twitter.com/rootkovska/status/547496843291410432 @rootkovska (on twitter.com)] ([https://nitter.net/rootkovska/status/547496843291410432 nitter]). See also specifically [[Mobile_Phone_Security#Mobile_Devices_Hardware_Risks|Mobile Devices Hardware Risks]], [[Mobile_Phone_Security#Best_Practices|Mobiles Best Practices]] and generally [[Mobile Phone Security]]. === VMs === * speakers: The attack paper [https://arxiv.org/ftp/arxiv/papers/1611/1611.07350.pdf SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit] does not apply to VMs. The abstract notes:
It's possible to manipulate the headphones (or earphones) connected to a computer, silently turning them into a pair of eavesdropping microphones – with software alone. The same is also true for some types of loudspeakers. This paper focuses on this threat in a cyber-security context. We present SPEAKE(a)R, a software that can covertly turn the headphones connected to a PC into a microphone. We present technical background and explain why most of today’s PCs and laptops are susceptible to this type of attack. We examine an attack scenario in which malware can use a computer as an eavesdropping device, even when a microphone is not present, muted, taped, or turned off. We measure the signal quality and the effective distance, and survey the defensive countermeasures.
 While it might be possible to retask virtual sound devices with software too, the malware still cannot access the soundcard settings of the host unless there is a VM escape; QEMU developers have also concluded that no risk is posed to the host. It should be noted that virtual soundcards also have optional, half-duplex modes that make audio input impossible. https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04754.html https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04899.html https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04906.html https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04904.html * HDDs: Regarding the eavesdropping risk of mechanical HDDs, note that above mentioned attack does not apply to VMs where disk devices are emulated. == Disabling or Removing Microphones == === On the Host === For best security, external microphones should be unplugged. If the microphone is built-in and the user decides to disable it, there might be a BIOS option available. Suitably skilled users can also attempt to remove built-in microphones, although this is more difficult. The drivers for the sound card can also be disabled, which prevents all output/input audio: * Linux hosts: the names of the drivers can be found in /proc/asound/modules. To blacklist them, create a file in the /etc/modprobe.d folder containing install (module) /bin/true, for example install snd_hda_intel /bin/true. * Windows hosts: the drivers can be disabled from the Device Manager. The microphone can also be muted on Linux by running alsamixer and entering "M" on the microphone channel. === Inside VMs === By default, microphones that are connected to the host are made available to virtual machines like {{project_name_long}} (except for [[KVM|{{project_name_long}} for KVM]] and [[Qubes|{{q_project_name_long}}]], see further below). Disabling microphones on the host as per above chapter would be more secure. == Select Use of Microphones == [[Multiple Whonix-Workstation|Multiple {{project_name_workstation_short}}]] should be used for: * Making Internet calls. * Conducting {{whonix_wiki |wikipage=VoIP |text=Voice over IP (VoIP) }}. * Any other microphone use inside {{project_name_workstation_short}}. In this way, the microphone is used in select {{project_name_workstation_short}} and not all. The microphone should be unplugged after use. For {{whonix_wiki |wikipage=VoIP |text=Voice over IP (VoIP) }} purposes, audio pass-through capability may need to be enabled for the respective hypervisor. The following section documents how to get audio working on [[Download|supported platforms]]. Expand for further information:
=== KVM ===
[[KVM]] by default emulates a line-in/line-out in the virtual sound device, meaning microphone passthrough to guests is enabled if it is turned on for the host.
=== VirtualBox ===
[[VirtualBox]] has access to the host's microphone by default. Access can be disabled by either muting it on the host or alternatively From VirtualBox 5.2 it is possible to enable/disable VM guest access to the host's microphone on the command line. https://www.virtualbox.org/ticket/12026 When the VM is stopped, run. {{CodeSelect|code= VBoxManage modifyvm audioin off }} Or when the VM is up and running, use. {{CodeSelect|code= VBoxManage controlvm audioin off }}
=== Qubes ===
From Qubes R4, the desktop panel icon ("Q") is used to attach or detach microphones to select VMs: https://www.linuxjournal.com/content/whats-new-qubes-4 Functionality is gradually being shifted from Qube Manager to standalone tools. Left-click "Q" → Assign the microphone to select VM
= Speakers = == Eavesdropping Risk by Speakers == The attack paper [https://arxiv.org/ftp/arxiv/papers/1611/1611.07350.pdf SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit] clarifies why there is a need for a strong warning against speakers. {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = Speakers can be turned into microphones. * Speaker '''=''' Microphone * All devices that can produce sounds '''=''' Microphone A speaker is approximately on the technical level the same or very similar to a microphone. Any speaker (a device that produces any form of audio output) can be abused as a microphone. }} {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = Computers, notebooks, phones, smartphones, smartwatches, tablets and similar devices most times contain both, microphones and speakers which can be abused for eavesdropping. A user intending to reduce all risks of spionage, needs to consider the * microphones * speakers * cameras of all of these devices. }} == Profiling Threat == Newer methods of advertisement tracking can link multiple devices via ultrasound covert channels. This technique works by playing a unique sound inaudible to human ears which is picked up by the microphones of untrusted devices. Watermarked audible sounds are equally dangerous, which means that hardware incapable of ultrasound is an ineffective protection. https://www.schneier.com/blog/archives/2015/11/ads_surreptitio.html There are multiple ways inaudible beacons can be used for surveillance, including to de-anonymize users of the Tor network: https://en.wikipedia.org/wiki/Cross-device_tracking#Ultrasonic_tracking_2
* The first is ''media tracking'': audio from the user's television may be detected by the microphone in the user's mobile device, allowing malicious actors to gain access to what the user is watching––particularly if it is salacious. Advertisers can similarly gain insight into what a user typically watches. In both scenarios, a user's real-world behavior is linked to their online identity and used for tracking. * Another form of tracking permitted by ultrasonic tracking is ''cross-device tracking'', which enables a user's profile to be connected across multiple devices based on proximity. This form of tracking, in linking different devices, can help advertisers show more targeted ads or open individuals to attacks by malicious actors. * ''Location tracking'' is yet another privacy concern. Indeed, ultrasonic signals can convey location information via a location identifier, often placed in stores or businesses. * Lastly, this new ultrasonic tracking poses a threat to users of Bitcoin and Tor because it ''de-anonymizes'' a user's information, since ultrasonic signals associate the user's mobile phone with the Bitcoin or Tor account.
Researchers have also demonstrated that air-gapped computers in the same room can exchange data via ultrasonic waves, whether they are equipped with earphones, headphones or passive speakers. Contrary to the expectations of most computer users, microphones are not required. In fact speaker-to-speaker communication was used to transmit data between computers up to nine meters away from one another. In the case of headphones, data could be exchanged up to a distance of three meters. [https://arxiv.org/pdf/1803.03422.pdf MOSQUITO:Covert Ultrasonic Transmissions between Two Air-Gapped Computers using Speaker-to-SpeakerCommunication] It is also possible to issue hidden, ultrasonic voice commands with speech recognition systems like Siri or Google in order to control other systems. For example proof-of-concept attacks using "DolphinAttack" included activating Siri to initiate a FaceTime call on iPhone, manipulating the navigation system in an Audi vehicle, and activating Google Now to switch the phone to airplane mode. [https://arxiv.org/pdf/1708.09537.pdf DolphinAttack: Inaudible Voice Commands] Interested readers are suggested to view the following demonstration videos: * [https://www.youtube.com/watch?v=ZD8CNxYe5dk MOSQUITO: Jump air-gaps via speaker-to-speaker communication] * [https://www.youtube.com/watch?v=j1FfVK6sj4I Your phone is LISTENING to you - ultrasonic cross-device tracking] == Countermeasures == Countermeasures can be categorized into hardware and software considerations. Obvious physical countermeasures include utilizing computers that are speaker-less and microphone-less. This may require physically removing microphones, speakers and the beeper which is very difficult. Many users are incapable of opening their notebooks, but desktop computer hardware is easily accessed. Those at high risk should also avoid the use of headphones, earphones or simple earbuds because this eliminates the risk they can exploited by malware and converted into eavesdropping microphones or data exfiltration tools. If this is not feasible in the circumstances, then prefer always connecting headphones instead of using passive speakers. It is also advisable to have (air-gapped) computers in strict physical isolation and not in close proximity to other computers or electronic devices. Other devices should always be considered potential eavesdropping, profiling or even data exfiltration threats. In the worst possible scenario, other devices may even be able to issue commands that affect functioning on the primary device used for privacy/security activities (although research shows devices must be in close proximity; around one meter). Software countermeasures include completely disabling audio hardware in the UEFI/BIOS settings. This can prevent malware from accessing operating system audio codecs. The downside is audio hardware will be completely unusable. If possible, also disable the beeper in UEFI/BIOS settings. Advanced Qubes users can disable speaker output for AppVMs by default by either: https://github.com/QubesOS/qubes-issues/issues/2724 * Utilizing a [https://github.com/3hhh/qubes-callbackd simple daemon (qubes-callbackd)] to react to Qubes OS events (VM started etc.) with configurable commands; or * Configuring [https://github.com/3hhh/qubes-terminal-hotkeys/blob/master/util/qubes-pactl hotkeys (via qubes-pactl)] to mute/unmute dom0 and all AppVMs. = Webcams = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = Webcams pose a serious [https://www.wired.com/2014/03/webcams-mics/ spying] [https://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam-images-internet-yahoo risk]! }} Webcams on infected machines can be used to take snapshots, record video or eavesdrop using the built-in microphone. [https://arstechnica.com/information-technology/2018/08/researchers-find-way-to-spy-on-remote-screens-through-the-webcam-mic/ Recent research] reveals that even remote screen views can be accurately determined via webcams, due to "content-dependent acoustic leakage from LCD screens." This is a novel acoustic side-channel attack variant that relies on neural networks and the "coil whine" audio emissions from electronic components that power the LCD display. Always check if the computer or notebook has a webcam; one might be built-in, but have gone unnoticed. Check the computer's datasheet and operating system hardware manager to be sure. It is recommended that (external) webcams are disabled or removed, unless there are immediate plans to use it inside {{project_name_workstation_short}}. Once a webcam session has finished, it should be disabled and preferably unplugged straight away. If the webcam is built-in, check whether it can be disabled with a BIOS setting. Suitably skilled users can attempt to remove built-in webcams, although this may be difficult. As a stop-gap measure, the webcam can always be covered with thick adhesive tape or a cap, so long as it is opaque. If a BIOS option is unavailable or it is impossible to physically disable the webcam, then the webcam drivers should be disabled: * Linux: a file must be added to the /etc/modprobe.d folder that contains blacklist uvcvideo. This blacklists the webcam driver from loading. * Windows: the webcam driver can be disabled from the Device Manager. = Wireless Input Devices = Avoid using wireless keyboards and mice because most send data unencrypted. Even if this was not the case, the robustness of the cryptography involved in proprietary products cannot be verified. A local adversary up to 100 meters away can sniff keystrokes and inject their own, allowing them to take over the machine. https://www.schneier.com/blog/archives/2016/03/security_vulner_6.html https://www.schneier.com/blog/archives/2016/08/security_vulner_7.html = Advanced Threats = While most users are capable of minimizing the threats posed by microphones, speakers, webcams and wireless input devices, this presupposes that the underlying hardware has not itself been compromised. In recent years researchers have focused on the risks posed by hardware trojans, which involves (quote modified from original source to clarify): https://en.wikipedia.org/wiki/Hardware_Trojan
...malicious modification of the circuitry of an integrated circuit. A hardware Trojan is completely characterized by its physical representation and its behavior. The payload of an HT is the entire activity that the Trojan executes when it is triggered. In general, malicious Trojans try to bypass or disable the security fence of a system: It can leak confidential information by radio emission. HT's also could disable, derange or destroy the entire chip or components of it. Hardware Trojans may be introduced as hidden "Front-doors" that are unknowingly inserted during the design process of a computer chip in the schematic files. This can be done by compromising the machines of chip architect firms. This method is more difficult to detect than searching for extra malicious chips added during the manufacturing phase. Relying on pre-made application-specific integrated circuit (ASIC) semiconductor or intellectual property cores (IP Core) that have been purchased from a non-reputable source, or inserted internally by a rogue employee or state sponsored spying and espionage, exposes end consumers to supply chain attacks.
The implication is that virtually any purchased hardware, particularly from non-reputable sources, could have hardware trojans that might cause data/password leaks, allow remote attackers access and extraction of cryptographic keys. While physical inspection, destructive testing by comparing manufactured chips to a "golden chip", functional testing and built-in tests can help to identify hardware trojans, this is costly and only feasible for technically competent individuals or agencies. https://en.wikipedia.org/wiki/Hardware_Trojan#Detection Recent research suggests that advanced hardware trojans may not be detectable by existing means if they are implemented below the gate level: * [https://www.iacr.org/archive/ches2013/80860203/80860203.pdf Stealthy Dopant-Level Hardware Trojans] * [https://archive.ph/eGWI7 archive.ph]
Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against “golden chips”.
In this case researchers demonstrated that "Dopant-level hardware trojans" could break any key generated by Intel's secure RNG design while still passing the functional Intel testing procedure and the NIST random number test suite, as well as creating hidden side-channels to leak out secret keys from a side-channel resistant SBox implementation. While military, corporate and government entities are most likely to be targeted by stealthy hardware trojans, this illustrates that virtually no hardware is safe from determined and well-funded adversaries. It is also a cautionary tale against relying exclusively on any hardware RNG for generating secrets. For most people the only practical countermeasure against hardware trojans is considering the manufacturing source of computer equipment. For example, it is inadvisable to purchase devices from Chinese original equipment manufacturers (OEMs) due to suggestions that manufacturing subcontractors previously added hardware trojans to server motherboards. https://www.usni.org/magazines/proceedings/2021/april/hardware-trojans-and-supply-lines https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies = See Also = {{physical-mininav}} = References = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]