Thursday, May 21, 2015

weakdh trickery

Now, that the TURMOIL slides make sense, I adjusted my own
projects. The good news is that I always used to generate
unique DH params (I wonder so many ppl apparently didnt -
there is no real benefit to use hard coded values, except to Eve!?)
in my projects during or before build. So it should be
quite hard for a Nation State Adversary to break that.

For lophttpd and crashd, I removed 512 and 1024 bit DH params
support and use 2048bit instead. opmsg always supported
2048bit (and higher), but the default was 1024. So I changed
the default to 2048 bit. Existing personas can be "upgraded" by
using the --newdhp switch. I was thinking this switch
may just be used in rare cases, but now it turns out it
was the right decision to design opmsg protocol with easy
DH params re-creation in mind. SUCCESS! DH keys that are
already "in flight" cant be upgraded, but may be used
as before (taking the 'weaker' 1024bit into account) even
after upgrading to 2048bit DH params.

Unfortunally, 2048bit keys come at the cost of a longer key
generation process. This may take a couple of minutes.
If thats too much for you, you are free to change your default
DH params len to 1892 or whatever your level of secrecy
demands.

Thursday, May 7, 2015

opmsg trickery

Given the recent crypto discussion, mass surveillance and
cyber jokes in general, I uploaded a new project to my github.
It was about time.

I wonder whether our gov is equally toast/bad in other fields,
or if I just get pointed to it because I have some background
in this field and am blind to all the other failures where
I am missing the knowledge. (SIGILL//NOPORN)

Update:
The first review round is over and it seems like opmsg
concept found some friends. I got some recommendations
which were incorporated in the git. Thats new:

- fixing insufficient hashing of persona key to
  detect tampering of RSA keys during transit/import
  (RSA's e value was simply not part of the hash and it now is)
- removing OFB cipher modes in favor of CTR and GCM modes (AES)
- adding option to allow linking of personas (see README)
- adding cygwin support

It is incredibly hard to review your own code; so thanks to
myself. While I buy the OFB arguments, I am not sure if its
a benefit to add ECC support for personas. ECC is mostly based
on curves with parameters chosen by NIST. The same NIST that is
suspected of putting backdoors in crypto standards
(slides), even more in standards that use ECC to generate
randomness! Knowing this, why should I trust any parameters 
chosen by them? You can argue that suite-B, the NSA approved 
standards for protecting US gov infra, is unlikely to contain 
backdoors for themself and that this would be a tough bluff
to do so just to read Putin's email. But given the additional
implementation cost (maybe I should crowdfund it?) for
little benefit or even "badfit" this seems not worth the effort.



Thursday, April 23, 2015

C++11 bailout trickery

Is someone C++11 guru enough to make a statement whether
the following C++11 code is correct? In particular on
whats happening on line 24, as the lambda should not
harvest the memory structures (scope?).
To me, everything looks OK. If thats the case, it would ease
a lot of cleanup routines on error returns from functions.
Please leave a comment.

Sample C++ code


Wednesday, March 25, 2015

troubleshooter trickery






Demo of SELinux disable on a Fedora 21 default desktop. A full writeup can be found here.

Thursday, January 8, 2015

U2F trickery


In the last post I promised to stop threat analyzing. So here
is some dev again which I already started developing back
in 2014 and where I finally found some time to finish.
Its a small U2F stack with the APDU framing code based
on Googles U2F reference code. After reviewing a lot of other
U2F code (sigh!), I found this reference code comprehensive enough to be usable for myself and for PAM code.
It also builds on Darwin, but I didnt have time to test it
there.



Friday, December 19, 2014

QI for the win

Now that we officially know that 3G can be broken and that
it makes sense to place particular (passive) hardware on the
roof top of embassies (the cellar is already stuffed with
torture equipment and you have better gain at the roof),
my threat analysis here was correct. In particular the
last paragraph should be repeated, as you can start sending
your QI before the victim packet is even close to the
target if you just captured the SYN packet on air.
As a bonus, you dont need to deploy evil hardware in the
target network.
Nevermind, I am not going to torture you with more threat
analysis posts. There are enough of them. :)


Thursday, December 11, 2014

sshttp tproxy trickery

I updated sshttpd to allow muxing of HTTP(S)/SSH
to whole subnets. Until recently, the setup was
per single host. Now you can run it via -T on your
gateway and Layer5-switch your whole internal net.





Thursday, October 30, 2014

lophttpd fucks the POODLE

Not just because they are ugly but also because lophttpd
never was affected by POODLE, since SSLv3 was
disabled for a reason in favor of TLSv1. I think about dropping
TLSv1 too and just allowing TLSv1.1+ in future.

To my knowledge lophttpd is also the first webserver
utilizing Linux seccomp sandbox.

I also added SO_REUSEPORT support today, since Google
told us that when handling c10k, their processes
are un-evenly distributed across the cores (what the hell
are they doing there?)
lophttpd wins again, since even without SO_REUSEPORT,
such problem never existed for you:





which shows running it on 4 cores, handling c10k. Could
there be a smaller footprint?


Update:

After carefully reading the commit for the Linux kernel
that introduced SO_REUSEPORT, I came to the conclusion that
for Linux there was an entirely different reason to introduce
it than there was for 4.4BSD at the time. According to the
git commit message, uneven distribution among the cores
only happen when the "number of listener sockets bound to a
port changes (new ones are added, or old ones closed)".
So its clear that it never affected lophttpd and it "leaks"
interesting info about the architecture of the google
webserver, why it had such problems before the patch
and which kernel they are using. OSINT for the win.
(Such architecture where new listeners are created or removed
do not make much sense to me anyway, so there are some
questions left.)

So in theory, I could remove SO_REUSEPORT again but I will
leave it as is for now, in case more webserver instances
are started later. Note that it doesn't make sense to have
more lophttpds running than there are cores on
your machine. I do not support hyperthreading yet, so
-n 0 is what you want, if you have such heavy load at all.

sshttp btw also uses the same multi/single-thread architecture
without SO_REUSEPORT (yet).




Monday, October 13, 2014

trusted bootloader RCE trickery

So you are safe, because you updated your bash, run your policy in enforcing mode, enabled NX and ASLR and boot using a cryptographically signed shim bootloader.

Well, you actually failed by the first step.

Here is why:





Even if thats hard to believe, but there might be
remotely exploitable buffer overflows in your secure
bootloader. The 90's party of today just happen
downstairs. Bootloaders make use of UEFI network stacks
to implement PXE and PXEv6 and sometimes fail to do so:





The issue however is not so severe because a lot of UEFI
firmwares fail to verify what they get via PXEv6 anyway,so
delivering an overflow payload is overkill. :)
Thats actually why you see 'schlimm' debug output in
secure mode in the PoC demo screenshot at all.

There were some twists necesarry to actually achieve *ptr = value
as seen above, mainly due to protocol specifics. If you are interested, we can discuss this privately.

Thursday, August 7, 2014

Some new stuff on github

I updated some of my github stuff recently.

First, I added SNI support to lophttpd for better supporting
virtual hosting with TLS. Its straight forward to use. Please
refer to the updated README.

Next, I pushed my POSIX realtime AIO implementation for
Linux to github. The glibc aio implementation is creating
an own thread for each aio_read/write that you submit,
not utilizing the kernels io_ syscalls. Clearly, for a large number of AIO contexts this performs badly to not at all.
I am using the io_ syscalls and an event-fd to get
notified about operations that became ready. I also
made sure that it works on Android. :p