Lessons learned: UN edition

[the grugq]

Hey,


This is a nice article on information that can be learned from a UN
document on terrorists / drug traffickers. It is interesting to note
that every use of steganography failed. This is mostly likely because it
was used as an encryption mechanism (it isn't) rather than as a data
hiding mechanism (which public tools aren't).

http://www.hacker10.com/other-computing/u-n-report-reveals-secret-law-enforcement-techniques/

The original document is here:
http://www.unodc.org/documents/frontpage/Use_of_Internet_for_Terrorist_Purposes.pdf

I haven't reviewed the whole thing yet (wading through paragraphs on how
VoIP is hard to detect because it doesn't generate forensic call logs is
tedious). There are a lot of details on LEO capabilities.


Cheers,

--gq

[Ian]

Re Point 194, the more sophisticated agencies (or sophisticated individual investigators of lesser agencies) are placing a much bigger emphasis on grabbing people while logged in. Seems to be a message that's getting through to more domestic law enforcement sources. Not necessarily caught in the act, but caught with the clam-shell open, so to speak. Thoughts about some sort of Dead Man's Switch? In each account I read there's obvious lag time between the arrest and when the techs get the hardware. Can't decide whether some kind of idle monitor would be more trouble than it's worth, in practice. Not to melt everything down, but just to move to a more secure process.

-ic

[the grugq]

I think the key is actually to setup the environment such that having
access to the "open box" is not sufficient to recover evidence.

My recommendation for this (outlined briefly in the Russian version of
my OPSEC slide deck) is to have the operational environment set up on a
remote host. This box (lets call it $HOME) is only accessed via a Tor
hidden service. The device used to access the $HOME box is only a "dumb
terminal" with nothing on it except the required software, i.e. urxvt +
ssh. If the feds kick down the door they capture a device that can ssh,
plus a Tor hidden service address, an ssh key... and thats it. Nothing
else is actually available for them to recover.

Access to the $HOME box requires a passphrase (to unlock the ssh key),
and the physical location of the $HOME box is unknown (and probably in a
remote jurisdiction). The sshd can be configured to aggressively
terminate links that are slow, and the local access device can be
configured to provide a hostile environment to LEO. For example, the
/bin/ls can be a shell script that calls "shutdown -h now". Anything
they do locally on the machine will terminate their access.

I think this is a more robust solution as there is nothing that can fail
open. I'm currently working on building an operations box (the dumb
terminal component) based on an mk802, or similar cheap ARM linux box
(e.g. ODROID). This box only has to provide X, urxvt, and ssh. The
RaspberryPi is, unfortunately, too underpowered to work well.


Cheers,

--gq

[the grugq]

(CC'ing the list because I think thats what you intended)

This is an interesting option I wasn't aware of. It is in line with what I recommend, so I am all for it.

Where is the new version of Liberte that can be customized for my operations platform? :)


--gq


On Dec 20, 2012, at 06:43 , Maxim Kammerer <m...@dee.su> wrote:

> On Thu, Dec 20, 2012 at 12:26 AM, the grugq <theg...@gmail.com> wrote:
>> Access to the $HOME box requires a passphrase (to unlock the ssh key),
>> and the physical location of the $HOME box is unknown (and probably in a
>> remote jurisdiction).
>

> Once you are talking about a thin client, then there is no need for
> unattended operation, which is risky, since you assume that the
> attacker is not aware of the safeguards. Just use a
> boot-media-is-present watchdog functionality, as e.g. present in
> Liberté Linux (and later ported to Tails), and have the media
> connected to you via a chain or something similar. When the media is
> extracted, the system performs an emergency shutdown, and RAM is
> wiped. Otherwise, attackers can just open the unattended laptop and
> put its memory into a portable freezer for further investigation in a
> lab. Even if you use things like encrypted memory (PrivateCore),
> attackers can still apply pressure if you and the thin client are
> separated (not necessarily torture — e.g., refuse of cooperation could
> carry a legal penalty).
>
> I have actually read about such setups being used in Russian
> companies, where it was (is still?) customary to have various LE
> agencies burst into your office and seize all equipment because your
> competitor paid more money to local officials. E.g., all accounting
> and development servers would be in another room in the same building,
> belonging to a different company, and employees would have tokens on
> them, that would lock the workstation when disconnected from it.
>
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte

[Maxim Kammerer]

On Thu, Dec 20, 2012 at 1:53 AM, the grugq <theg...@gmail.com> wrote:
> (CC'ing the list because I think thats what you intended)

In case the current behavior is not intentional, IIRC Google Groups
have a setting for having default reply go to list.

> Where is the new version of Liberte that can be customized for my operations platform? :)

Real soon now! :) I like your ideas very much (already subscribed to
the newsletter), so build system will soon have an option to include
Perl & Python, and a notion of profile to select build type.

[Jason A. Donenfeld]

> > boot-media-is-present watchdog functionality, as e.g. present in
> > Liberté Linux (and later ported to Tails), and have the media
> > connected to you via a chain or something similar. When the media is
> > extracted, the system performs an emergency shutdown, and RAM is
> > wiped.

This is pretty clever, made me laugh. I remember a scene from a
horrible 90s film about a teenager in his room in his house who had a
laser beam near his desk that would turn off his screen when his mom
came in. The 90s aside, doing this via USB key is actually kind of
feasible. I can't imagine ever actually using this but I whipped up
something in a couple of seconds that uses inotify to monitor a device
node for deletion, and then halts the machine:

http://git.zx2c4.com/knock-knock-token/tree/knock-knock-token.c

In order for this to be actually useful for more than being a teenager
in your parents home, you'd want to implement a secure memory wipe, as
Maxim said, to prevent against cold boot attacks. Patches for this are
welcome, if someone wants to integrate secure_delete [1], or whatever,
into the short program.
[1] http://www.thc.org/download.php?t=r&f=secure_delete-3.1.tar.gz

On that note, are there any actual documented cases of criminals or
law enforcement or whomever bringing "portable freezers" to an arrest
& computer seizure? I can't even imagine this happening in film.

[Maxim Kammerer]

On Thu, Dec 20, 2012 at 3:22 AM, Jason A. Donenfeld <Ja...@zx2c4.com> wrote:
> I can't imagine ever actually using this but I whipped up
> something in a couple of seconds that uses inotify to monitor a device
> node for deletion, and then halts the machine:
>
> http://git.zx2c4.com/knock-knock-token/tree/knock-knock-token.c

Here is a way of doing the same with udev:
https://github.com/mkdesu/liberte/blob/master/src/usr/local/src/udev-watchdog.c

> if someone wants to integrate secure_delete [1], or whatever,
> into the short program.
> [1] http://www.thc.org/download.php?t=r&f=secure_delete-3.1.tar.gz

That package contains "smem", which is designed to wipe RAM. It
doesn't work that well (wiping all RAM from userspace is notoriously
hard), so it's probably better to use kernel's "memtest=<n>" option
(but note that it's limited to LOWMEM on 32-bit kernels).

> On that note, are there any actual documented cases of criminals or
> law enforcement or whomever bringing "portable freezers" to an arrest
> & computer seizure? I can't even imagine this happening in film.

I don't think it ever happened, because you would need a well-equipped
lab nearby (with many different laptop models to accomodate for
various RAM types). It's much easier to copy all RAM via Firewire
SBP-2 interface (actual Firewire port in the machine is not
necessary).

[the grugq]

>
>> On that note, are there any actual documented cases of criminals or
>> law enforcement or whomever bringing "portable freezers" to an arrest
>> & computer seizure? I can't even imagine this happening in film.
>
> I don't think it ever happened, because you would need a well-equipped
> lab nearby (with many different laptop models to accomodate for
> various RAM types). It's much easier to copy all RAM via Firewire
> SBP-2 interface (actual Firewire port in the machine is not
> necessary).

I know there are evidence suitcases with integrated battery packs / UPSs to keep desktop systems up while they are transported to the lab. With the UN's guideline for "capture the laptop open" this seems a likely scenario. The people on the scene keeping the system alive long enough to get it back to a lab for analysis.

I've also read that it is now typical that a forensic office on the scene will use Ctrl-Alt-F1..Fn to try to access open consoles in case the screen saver is activated. Perhaps having a burn trigger on Ctrl-Alt-F3 for "silently wipe memory and shutdown" is a good idea?

On that note, would we agree that it is best practice to run a laptop without the battery so it is easier to pull the plug for an emergency shutdown?

In the book Kingpin, they make clear that when the door is kicked in, it is too late to do anything like triggering a process on your computer. Since the main point of keeping a computer on is to maintain state, if the state is stored on a $HOME box the local thin client is much more likely to be powered off when not in use. Generally, an all around safer means of operating.


--gq

[Maxim Kammerer]

On Thu, Dec 20, 2012 at 4:07 AM, the grugq <theg...@gmail.com> wrote:
> I know there are evidence suitcases with integrated battery packs / UPSs to keep desktop systems up while they are transported to the lab.

I wonder how they manage switching the power source of a live desktop.
An expert electrician on team?

> I've also read that it is now typical that a forensic office on the scene will use Ctrl-Alt-F1..Fn to try to access open consoles in case the screen saver is activated.

If one wants to prevent breaking out of screen lock, Zap / VTSwitch in
X need to be disabled, and also SysRq / PowerOff events should be
taken care of while lock is active:
https://github.com/mkdesu/liberte/blob/master/src/etc/X11/xorg.conf.d/99-nozap.conf
https://github.com/mkdesu/liberte/blob/master/src/etc/acpi/default.sh
https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/sysrq

> Perhaps having a burn trigger on Ctrl-Alt-F3 for "silently wipe memory and shutdown" is a good idea?

You can be extreme and assign such trigger to just pressing anything
except Shift, Enter, and printable characters. :)

[the grugq]

> You can be extreme and assign such trigger to just pressing anything
> except Shift, Enter, and printable characters. :)

Actually, that isn't extreme. If the screen lock is on, then there is no reason to type anything else. Seems totally reasonable to me. :)


--gq

[Justin Seitz]

> I know there are evidence suitcases with integrated battery packs / UPSs to keep desktop systems up while they are transported to the lab.

I wonder how they manage switching the power source of a live desktop.
An expert electrician on team?

I wonder this myself, it would be interesting to know how they would do this without disrupting power.

For me, I think hobby electronics (i.e. the advent of the Arduino) is where serious kill switches can be created cheaply, and easily. Riding lawnmowers for example have kill switches when you hop off them (simple switch in the seat). For freedom fighters to employ the same kind of techniques, the cost is minimal, the barrier to entry is low, and the effectiveness is high. 

[the grugq]

Forwarded message:

Can't send to list anonymously so going straight to you two. Forward on
if you want

On 20/12/2012 02:25, Maxim Kammerer wrote:> On Thu, Dec 20, 2012 at 4:07

AM, the grugq <theg...@gmail.com> wrote:

>> > I know there are evidence suitcases with integrated battery packs /
UPSs to keep desktop systems up while they are transported to the lab.
> I wonder how they manage switching the power source of a live desktop.
> An expert electrician on team?

Wiebe Tech have two demos of their hotplug devices on youtube

basic - https://www.youtube.com/watch?v=erq4TO_a3z8
advanced - https://www.youtube.com/watch?v=-G8sEYCOv-o

[Maxim Kammerer]

> Wiebe Tech have two demos of their hotplug devices on youtube
>
> basic - https://www.youtube.com/watch?v=erq4TO_a3z8
> advanced - https://www.youtube.com/watch?v=-G8sEYCOv-o

Thanks, the advanced presentation is exactly how I imagined this task
would be accomplished — by disassembling the socket, or by splitting
the wire (a bit disappointed that the presenter didn't get an electric
shock to his bare hands immediately after saying “So I do know how to
do this”, but oh well). But the basic method for extension cords is
probably applicable in most household cases — didn't think of that.

[gric]

Hi people,

> I wonder this myself, it would be interesting to know how they would do
> this without disrupting power.

Here is an example of a dedicated device with demo videos.

https://www.wiebetech.com/products/HotPlug.php

The principle is basically the same than with any UPS, it takes
over quickly (probably about 5 ms) when it detects that you removed the
original power source.

Mechanically, it seems to works in many cases:
With a power strip, it is very easy to inject power by plugging a new
cord in. And if you are directly plugged into the wall, they use some
kind of clamp that allow them to inject power by slightly pulling
the plug, but they can also remove the socket from the wall or just
split the wires with a cutter.

It is possible to differentiate the power from a wall outlet and from a
portable UPS, or detect the takeover moment, but it is rather complex
and bulky and as a physical device, the detection system would be quite
exposed. You would have to put it inside the power supply, and it would
prevent the use of any inverter or legit UPS.

Interestingly they also offer a USB HID device that slightly giggle the
mouse to prevent the computer from going to sleep. A long enough use
is rather easy to detect by software. Or you can just use udev to turn
the computer off if any unknown USB device is plugged in - seems
reasonable for an operational machine.

[Justin Seitz]

I would assume that you could put a clamp-on current transducer in place that would detect that slight ripple when they switch to UPS. It would have to be external, but combined with a fallback mechanism (you break the 'loop' in the clamp, or an accelerometer to show that someone is giggling the cable). 

This would make it exceedingly difficult for them to manipulate your power supply in any way, especially if your power cable should never theoretically move. Again, an Arduino and $20 in parts would solve this I think.

--
Whatever you say, say nothing.

[Justin Seitz]

Do you have any papers or anything on using the SBP-2 interface? 

[Maxim Kammerer]

On Thu, Dec 27, 2012 at 4:48 PM, Justin Seitz <justin...@gmail.com> wrote:
> Do you have any papers or anything on using the SBP-2 interface?

I guess that the Wikipedia article is a good start:
http://en.wikipedia.org/wiki/DMA_attack