Find something in the street and plug it in.

[tom r lopes]

Not quite plug it in but a day or so ago I found a little device on the sidewalk.  A 2x2x3/4 in plastic 

box with an LED and text: REMOTE SENSOR 433 MHz Wireless.  Um, I thought, wonder if you could decode this with an SDR dongle.  

Turns out some one has already done it.  Yay open source!  RTL_433 on Github https://github.com/merbanan/rtl_433 

rtl_433 is in Debian testing and Ubuntu 19.10.  

I installed from github as I run 18.04.  

tom@tom-desktop:~$ rtl_433 -C customary

time      : 2019-10-05 02:51:30
model     : Prologue sensor                        id        : 9
rid       : 222          Channel   : 3             Battery   : LOW
Temperature: 66.38 F     Button    : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-10-05 02:51:30
model     : Springfield Temperature & Moisture     SID       : 157
Channel   : 3            Battery   : LOW           Transmit  : MANUAL
Temperature: 126.1 F     Moisture  : 15            Integrity : CHECKSUM
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-10-05 02:52:26
model     : Prologue sensor                        id        : 9
rid       : 222          Channel   : 3             Battery   : LOW
Temperature: 66.56 F     Button    : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2019-10-05 02:53:22
model     : Prologue sensor                        id        : 9
rid       : 222          Channel   : 3             Battery   : LOW
Temperature: 66.56 F     Button    : 0
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Mine is the Prologue sensor.  After running a couple hours it found another sensor.  I was running the SDR stick without an antenna so maybe it could pick up more.  

You can see an explanation of the protocol in the source: https://github.com/merbanan/rtl_433/blob/master/src/devices/prologue.c

Prologue sensor protocol,
	also FreeTec NC-7104 sensor for FreeTec Weatherstation NC-7102,
	and Pearl NC-7159-675.
	The sensor sends 36 bits 7 times, before the first packet there is a sync pulse.
	The packets are ppm modulated (distance coding) with a pulse of ~500 us
	followed by a short gap of ~2000 us for a 0 bit or a long ~4000 us gap for a
	1 bit, the sync gap is ~9000 us.
	The data is grouped in 9 nibbles
	[type] [id0] [id1] [flags] [temp0] [temp1] [temp2] [humi0] [humi1]
	- type: 4 bit fixed 1001 (9) or 0110 (5)
	- id: 8 bit a random id that is generated when the sensor starts, could include battery status
	the same batteries often generate the same id
	- flags(3): is 0 the battery status, 1 ok, 0 low, first reading always say low
	- flags(2): is 1 when the sensor sends a reading when pressing the button on the sensor
	- flags(1,0): the channel number that can be set by the sensor (1, 2, 3, X)
	- temp: 12 bit signed scaled by 10
	- humi: 8 bit always 11001100 (0xCC) if no humidity sensor is available

[tom r lopes]

Pics https://photos.app.goo.gl/ygRRafkWeNp6r8dh6

[Rick Moen]

Quoting tom r lopes (tomr...@gmail.com):

> Not quite plug it in but a day or so ago I found a little device on
> the sidewalk. A 2x2x3/4 in plastic box with an LED and text: REMOTE
> SENSOR 433 MHz Wireless.

And _you can trust_ random electronic devices you find on the sidewalk
to be what the labeling claims them to be -- except when you should not
trust them at all. Which is, actually, pretty much all the time. ;->

Web search for 'evil maid attack' for reasons why you should probably
think once, think twice, think three times before plugging unknown USB
device into any computer you care about. Or start here:
https://en.wikipedia.org/wiki/Evil_maid_attack
https://en.wikipedia.org/wiki/Juice_jacking#Mitigation
Basically, the big problem with USB is that, by design, it's something
of a Wild West where devices can and do lie about what they are and what
they're about to do. And it's difficult to prevent that, though there
are some partial add-on solutions, e.g.:
http://syncstop.com/
https://www.amazon.com/PortaPow-3rd-Gen-Data-Blocker/dp/B00QRRZ2QM

Nonetheless, have fun with the nifty dongle!

[Rick Moen]

I wrote:

> Web search for 'evil maid attack' for reasons why you should probably
> think once, think twice, think three times before plugging unknown USB
> device into any computer you care about. Or start here:
> https://en.wikipedia.org/wiki/Evil_maid_attack
> https://en.wikipedia.org/wiki/Juice_jacking#Mitigation

On closer examination, the first of those two links doesn't appear to
really address the USB part of this problem at all, and I'm not sure
offhand what's a better link about the general USB problem, though Qubes
OS's page is one starting point:

https://www.qubes-os.org/doc/anti-evil-maid/

And the 'BadUSB' pages:
https://opensource.srlabs.de/projects/badusb (see link 'Introductory
blog post' in particular)

The crux of the problem is that any USB device, if so reprogrammed by a
hostile party, can suddenly start acting like a different USB device
class than it appears to be, and taking actions hostile to the
adminstrator. I believe I've seen a few stabs at a hardware
countermeasure like a dongle you interpose between your computer's USB
port and an outboard device. You set a control on the dongle to permit,
say, only USB HID-class (human interface device, such as keyboard and
mouse) operations. If the device attempts to suddenly say to the host
computer 'OK, I'm actually a mountable mass storage device', the dongle
intercepts that USB instruction and doesn't allow it through. Likewise
if it's supposed to be a scanner, just a USB cable, etc., but upon
connection it says the host computer 'Actually, I'm an HID-class
device.' But I cannot remember where I saw that implemented, or
(actually) if I merely saw the idea discussed but not yet implemented.

To keep informed on these sorts of things, I recommend following Brian
Krebs's 'Krebs on Security' and Bruce Schneier's blog.

[tom r lopes]

Well, Rick, It was a wireless transmitter and not a dongle.  

But in writing the subject line of the email 

I was thinking of the exploit where you scatter USB flash drives with infected files around, say, a 

corporate parking lot.  Then people pick them up and plug into their work computer and open the pdf called 

"Jen's private photos"   

Thomas

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20191007224714.GL6980%40linuxmafia.com.

[Rick Moen]

Quoting tom r lopes (tomr...@gmail.com):

> Well, Rick, It was a wireless transmitter and not a dongle.

Luckily, it indeed _was_ what it was claimed to be on the outside of the
plastic case.

The point is, though, that it's something you found on the sidewalk,
so there was substantial risk, in plugging it into a real computer's
USB port, because it could have been reprogrammed or otherwise modfied
to do literally anything that a USB device may do -- including emulate a
keyboard and 'type' OS commands, invisibly to you.

> But in writing the subject line of the email I was thinking of the
> exploit where you scatter USB flash drives with infected files around,
> say, a corporate parking lot. Then people pick them up and plug into
> their work computer and open the pdf called "Jen's private photos"

This particular scenario is 90% bullshit. To see why, work out the
threat model.

Are you saying the file is opened by a PDF viewer? If so, would that be
a non-sucky PDF viewer program, or would it be Adobe Acrobat Reader aka
Acroread (which isn't part of any Linux distro on account of restrictive
proprietary licensing)? Acroread defaults to executing any embedded
Javascript in an opened PDF (though this extremely dangerous default can
be easily checkboxed to 'off' in Preference). AFAIK, none of the many
much-better and actually open source PDF viewer programs for Linux has
that gross security defect.

If the PDF either lacks embedded Javascript _or_ is opened by a
non-sucky PDF viewer program, then no code execution ensues. Hence, no
'infection'.

(Moral #1: Friends don't let friends install and use Acroread, or at least
discourage them from permitting Acroread to be used as a 'helper'
application to handle public files. Fortunately, Linux users can hurt
themselves in that fashion only by going rather far out of their way to
retrofit terrible proprietary software.)

(Moral #2: By and large, code doesn't run itself. Be skeptical of
claims of mysterious and unexplained code execution causing system
havoc -- tall tales about which emerge frequently from the IT press
uncritically publishing as alleged news coverage press releases from the
AV industry.)

[tom r lopes]

On Mon, Oct 7, 2019 at 7:39 PM Rick Moen <ri...@linuxmafia.com> wrote:

The crux of the problem is that any USB device, if so reprogrammed by a
hostile party, can suddenly start acting like a different USB device
class than it appears to be, and taking actions hostile to the
adminstrator. 

For example the USB Rubber Ducky https://shop.hak5.org/products/usb-rubber-ducky-deluxe 

But you can also put the Raspberry Pi Zero into gadget mode and it can be plugged in and be a

HID device.  (Maybe next Pi meeting someone would like to try)  Though the Zero is small it is 

not small enough to fool anyone.  

 

I believe I've seen a few stabs at a hardware
countermeasure like a dongle you interpose between your computer's USB
port and an outboard device.  You set a control on the dongle to permit,
say, only USB HID-class (human interface device, such as keyboard and
mouse) operations.  If the device attempts to suddenly say to the host
computer 'OK, I'm actually a mountable mass storage device', the dongle
intercepts that USB instruction and doesn't allow it through.  Likewise
if it's supposed to be a scanner, just a USB cable, etc., but upon
connection it says the host computer 'Actually, I'm an HID-class
device.'  But I cannot remember where I saw that implemented, or
(actually) if I merely saw the idea discussed but not yet implemented.

Like a USB condom.  But internet search brings up dongles that protect when plugging 

into chargers.  https://shop.syncstop.com/collections/buy 

But I have seen some USB devices that are also flash drives (with the needed Windows 

drivers.)  There are also some keyboards with integrated touchpads and so would present as 

two HIDs.  

The Raspberry Pi Zero supposedly can be two gadgets at once.  

Then there is the possibility of real maliciousness: USBkiller  

Kinda like the famous etherkiller:   http://www.fiftythree.org/etherkiller/ or the 

BOFH story: http://www.plig.net/bofh/lastbastard.html

USB killer:  https://hackaday.com/2015/10/10/the-usb-killer-version-2-0/ or the true link 

in Russian:  https://habr.com/en/post/268421/

Instructible (build your own)  https://www.instructables.com/id/How-to-Make-USB-Killer-From-Bug-Zapper-Racket-/

I have just been thinking about power on USB because I have a small HDMI display with 

5V input.  And I thought to solder a USB cable instead.  (Most of the time the display can get 

enough juice from the HDMI)  So I was looking at the spec to see if I would need to do 

anything with the data lines of the cable.  Then I thought USBkiller and of course someone 

has already done it.  

Btw I don't need to do anything with the data lines for display power.  It is on the power 

supply side where you have to mess with those lines.  See:  https://learn.adafruit.com/minty-boost/icharging

Thomas