[conspire] Finding hidden cameras; the lying-USB-device problem

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Tue, 9 Apr 2019 14:01:29 -0700
From: Rick Moen <rick at linuxmafia.com>
To: skeptic at linuxmafia.com
Subject: Re: [skeptic] To be fair, she totally lacked a wristwatch with a
	built-in rocket launcher...

Quoting Dave Palmer (dwpalmer at earthlink.net):

> The lawyer for the Chinese woman nabbed at Mar-a-Lago with:
> 
> >four cellphones, a thumb drive containing malware,
> ...
> >five SIM cards, nine USB drives, yet another cell phone, and a
> >signal detector that could scan an area for hidden cameras,

For the record, what is called here a 'signal detector that could scan
an area for hidden cameras' refers to a cheap plastic widget with a
couple of AA cells that typically includes (1) an LED or laser light
that one can play around a room trying to get a bounced glint from a
camera lens, and (2) an RFI detector gadget seeking WiFi or Bluetooth
signals.  

The latter inherently suffers both false positives and false negatives,
triggering on many devices that are small RFI emitters but are not
hidden camera, and also failing to report camera devices that may be
present and maybe even active but not currently transmitting.  The
former can be approximated by just getting and waving around (away from
human eyes, please) a laser pointer.  

Oh, almost forgot, (3) seeking suspicious infrared-light sources to find
cameras that rely on IR emitters.  (I hear that you typically will not
be able to find a lens glint from an IR-driven camera, because typically
there's an IR-transparent black plastic cover over the lens.)
https://counterespionage.com/infrared-bug-detection-tscm/

Of course, any of these detectors (including the 'professional' meaning
cheap plastic ones) ought to be tested against known-working example
devices, before you believe they're useful.



>> According to testimony presented Monday, Yujing Zhang's hotel room
>> had a signal detector and additional suspicious possessions in it.
>> The malware she carried may have been able to infect computers as
>> soon as it was plugged into a computer.

There are some subtle distinctions, here, that are (predictably) getting
bulldozed by reporters.  (I used to joke that the reporter assigned to
the IT beat is whoever in the newsroom was the best touch-typist.)  

First thing:  A USB mass storage device _per se_ cannot trigger the
running of code just because you attached it and the operating system
mounted one or more filesystem ('partition') on it.  There have been
operating systems in the past, such as early releases of 
MS-Windows 95 (https://en.wikipedia.org/wiki/Autorun.inf), many decades
ago, that had the misfeature that if a certain filename were present on
a mountable filesystem, that if found would be run as a program by the
OS.  This was an OS-design bonehead error, quickly corrected after
(predictably) douchebags immediately took advantage of it to autorun
malware.[1]

Second thing:  My qualifier of 'storage device _per se_' reflects a very 
problematic aspect of USB:  During that standard's design, no measures
whatsoever were taken to prevent USB devices from lying to the host system's 
USB controller chip, and thereby getting accepted as something they're
not supposed to be.  For example, security researchers have produced an
endless string of USB devices that are on the surface of things USB
flash drives, printers, or even just cables that also include hidden
circuity that make them _also_ say to the host computer's USB controller
chip 'Hi, I'm a USB HID = human interface device.  Please enable me to
send your host computer command input', and the USB controller chip says
'Okie-dokie, you're now cleared to be a keyboard.' And then the USB
device hidden circuitry's firmware sends HID input like 'Hey, run this
program on my mass storage portion.'

So, it's been notorious for almost a quarter-century that you cannot
trust a USB device to be even the USB _class_ that it appears to be, and
there's a dizzying array of defined USB device classes:
https://en.wikipedia.org/wiki/USB#Device_classes

Moreover, the mischievous USB device need not even have had additional
circuitry added, technically.  It turns out that USB devices have
essentially no protection against code overwriting their firmware with
replacement code that in addition to its normal functions will now
attempt to do nasty things on host computers (typically as HID
instructions).
https://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/

There are non-default, you-have-to-buy-or-build-one hardware tools to
defang USB for concealed HID functionality, for example
https://globotron.nz/products/armadillo-hardware-usb-firewall .

Meanwhile, smart users over the past 23 years of USB history simply know 
that a USB device of unknown provenance and history cannot and should
not be trusted.  E.g., the only USB devices I permit to be plugged into 
my server are my own keyboard and my own external backup drive, both of
which I physically guard.

Anyway, if you believe the news story, yes, apparently one Secret
Service agent was a bit of an idiot.  If Secret Service uses the same
forensics methods as FBI, the standard way to treat a suspect's USB
device is to bag it in an evidence bag and take it straight to a
dedicated lab where it can be probed properly.


[1] Well, partially corrected.  It's still supported on DVD and CD
types, which remains a bonehead OS-design element that MS-Windows users
should IMO hasten to disable on their machines.

Nothing quite as boneheaded ever was present on MacOS, though 
there were viruses such as nVIR that, if executed, installed themselves
into the system file on any Mac-formatted mass storage device including
floppy disks, such that the virus code would then get executed on any 
Mac that attempted to _boot_ from the disk.  However, merely inserting
and mounting the disk did not run code.

In 1998, Apple came close to MS-Windows 95's bonehead error, though:  
PowerPC Macs equipped with release 2.0 of Apple QuickTime would activate
QuickTime whenever an HFS- or HFS+-formatted CD-ROM was loaded and
mounted and search its root directory for a hidden application file
called 'DB" with creator '????' and type 'APPL' and, if found, run that
code.  This was immediately taken advantage of as the hook for a bit of
worm code called AutoStart 9805.  As with the Win95 gaffe, the idiot OS
coders wished to make inserted disks automagical.  Too right they did.


----- End forwarded message -----