Friday, May 19, 2017

KDE trickery

I published my writeup about CVE-2017-8422 and CVE-2017-8849,
including the PoC for smb4k.

Note, that this helper is most likely not installed by
default on KDE systems. However, other helpers which are
installed by default are affected too, such as kcm_systemd which
could be leveraged to overwrite arbitrary files.

The most complicated thing about the PoC was to setup
a proper Qt/KDE 4/5 build environment; so I decided to
just use dbus-send with a binary blob instead, rather
than creating my own QVariantMap. 



Thursday, May 4, 2017

OpenSSL constant hell





Last week, someone opened a bug for opmsg, saying it
wont compile with recent versions of gcc.
I am happy that I've been noticed about it, since it shows
people are using opmsg. The "bug" however is not within
opmsg, its about the way OpenSSL changes their function
definitions (breaking the API!) in between minor versions
of OpenSSL.

What exactly happened?

In above screendump you see two functions constp() and
constpp(). They will serve as an easy, down-stripped demo.

While with constp() the const char * declaration
by the programmer is more like a promise to the caller
that the data at which ptr points to, will not be written to,
this is different when the type changes to a double
pointer. You can pass char * variables to constp() without
any problem, because constp() just promises you to not modify
the pointee data. It would be allowed to do so for char *
variables, but it confines itself to this promise, which
is good practise to show the user of the API "Hey, we
wont modify your data as you pass it to us." 
There are no problems if you would change a foo(char *) 
declaration to a foo(const char *) because the later declaration 
just promises more to you, and you lose nothing by foo()
making additional promises to you.
The takeaway is: you can pass a char * variable to a
function that wants a const char *. Both foo()
functions are accepting the same type. You can see
this by the compiler accepting the call to constp()
for a char * variable.

Thats different when a double pointer is involved as
with the constpp() function. Here you have to pass
a const char ** because otherwise the pointer value itself could
be assigned a char * by which const objects could be modified.
This would violate the const correctness of the program
and obsolete the const keyword. Thats why the foo(char **)
and foo(const char **) arguments are really different types.
In other words, you cant just add a const keyword to
double pointer function arguments as you could do it
with single pointers. You end up having entirely different
function signatures.

Now, guess what OpenSSL has made with the

DH_get0_key(const DH *dh, BIGNUM **pub_key, BIGNUM **priv_key);

and

RSA_get0_key(const RSA *r, BIGNUM **n, BIGNUM **e, BIGNUM **d);

functions? They "just" added a const to the BIGNUM
double pointers somewhere after the 1.1.0 version
already introduced a new API. Thats a warning for
C11 programs (one that you should not ignore) but even
worse, as you can see in above demo, its an error for
C++11 programs.

So, I had to add a wrapper function for the functions
in question which call the right functions, depending
on the OpenSSL version.


If you want to read more about the double pointer
const topic, its described here.




Thursday, April 20, 2017

drops and free trial

My google-cloud free-trial account will run out soon, so the
bootstrap IP address in the drops README will end up
being non-responsive soon. I am not sure which cloud
provider I will use in future, so I am not signing up
for premium there yet. I am quite happy there wrt stability
and the overall setup; its merely a matter of pricing.

I plan to write some fancy ncurses GUI frontend for drops,
so one can read and write drops messages in mutt-style,
but that can take a while. (I need less ShadowLeaker 90's 0day
that reminds me of old times and more joy starting to learn
ncursesUntil then, someone else has to spend free bonus coins
of his cloud provider to setup drops bootstrap nodes (and
thanks to that anon french guy running that 78* node :)

Wednesday, March 29, 2017

New git signing keys

My previous git signing key expired, so I uploaded a new one. 

I didnt sign all of my github repos with it yet,
but I took the opportunity to polish my optimized dd
repo, adding a useful help and making it fully usable
under the GPLv3.

If you dont do so already, consider signing your
external git repos. Its painless and you will thank me later
in case your external repos will be fucked with.



Thursday, February 23, 2017

sshttp SNI proxy trickery




The sshttp protocol muxer has been updated to support
SNI muxing. When muxing SSH/HTTPS, the ClientHello message
of the TLS handshake may contain a SNI, which is parsed by
sshttpd  and can be routed to an alternative port (rather than to the regular https port specified with -H).
This is of particular interest with the drops p2p network,
as it is using TLS with the SNI of drops.v2.
This way you can hide sshd and drops behind your https server.


Friday, February 3, 2017

Drops trickery

In the past months I have been working on a project
for a distributed p2p messenging platform, featuring
the opmsg format. opmsg is usually attached to emails.
Emails however leave meta data traces such as email addresses and
header content. Not so with drops, which is ready for testing !

As its a p2p network, it lives from participating people.
So even when you dont use opmsg yourself, you can setup
a drops node so the network gets more distributed and
stable.

Its now in beta testing, and some features such as
sandboxing are yet missing.

Dont be worried by the spartanic README, it will get
updated and there will also be a document describing
the techical details.



Monday, December 12, 2016

IPv6 spoofing trickery

Tales of spoofing on BSD based kernels (actually Darwin).

Although OSX setups should mostly be targets of spoofed
packets, there are times when you need to spoof IPv6 packets
from a OSX box.
Unlike with IPv4, there is no such thing as a IP_HDRINCL
socket option that lets you pass arbitrary IP headers
to raw sockets. In fact, there are RFCs on the subject
(RFC3542 and RFC 3493) and the authors put a lot of effort
to specify on how certain flags and details may be modified,
but the end of the story is that, in this way or another,
its not possible to have a handy library function to
generically send a spoofed IPv6 packet on a raw socket on OSX.

man 4 ip6 says:
"Note: Since the checksum is always calculated by the kernel for an ICMPv6 socket, applications are not able to generate ICMPv6 packets with incorrect checksums (presumably for testing purposes) using this API."

I like the presumably for testing purposes part most.
So I had to eventually switch to packet sockets for
my UDP6 sample of libusi++. Its a bit more work to
set it up initially, but after that all the get/set
of source addresses etc. work as expected.






Thanks to the inject function of libpcap, thats easy
enough.Its probably not worth the effort to handle all the
socket options or ancillary data for raw IPv6 sockets just to 
achieve a goal that at the end still has some header-parts un-modifiable.
I did not test it on OpenBSD or FreeBSD, but the manpage
reads more or less the same, so I expect the same problem
exists there too.

Thursday, August 18, 2016

cross-domain ECDH trickery

Once again, opmsg is ahead of the curve, by introducing
what I will call cross-domain ECDH kex.

The idea behind it is straight forward and obvious,
so that I wouldn't claim to be the first who invented it.
Digging the interweb a bit, didnt show quick results,
so I named it cross-domain ECDH without walking to the
library to do more in-depth research about someone else
having different names for it. If there is, feel free
to point me to it.

ECDH is a neat way to do your Key Exchange (Kex). It has
small footprint in speed and size. Its even fast enough
to be done multiple times in a row, without the user really
noticing a slowdown. The drawback of ECDH is that the so called
domain parameters for the curves are chosen by an entity
that you have to trust. Trust by means of: Nobody in the
committee responsible for choosing the parameters would
introduce so called Nobody-But-Us (NOBUS) bits, that
would weaken the resulting ECDH Kex secret.

There are different ways to put trust into the domain
parameters, like using some kind of sane and "well-known"
seedings and algorithms to generate "reproducable" parameters
(like Brainpool is doing). Other curve designers don't mind about
it at all and resemble eat-or-die mentality. This leads
to some kind of flame-war and bashing between the different
cults of ECC evangelists. Nobody knows anything about the NOBUS,
but everyone believes the opposite curve has backdoored parameters.

opmsg puts an end to this war, by allowing users to
specify more than one curve to do the Kex with. Up
to three curves may be specified. The master secret is derived
from the multiple distinct ECDH Kex's which are made. The idea is that in case there are NOBUS backdoors - even within every single curve -
the different backdooring parties would not work together
and share their NOBUS knowledge to each other. They wont
share their knowledge, because a potential NOBUS inside
a NIST curve would be the holy grail that they are never
ever show to someone else, and in particular not to the
party who, lets say, put their NOBUS into the GOST curves.

So, even if each curve that you chose to do your ECDH Kex
would be weak, the overall cross-domain ECDH Kex is secure.
As long as you really choose your curves cross-domain, e.g.
not three of the NIST curves in a row.

This feature is experimental. Please refer to the chapter
in the README which explains the particular config options.
If you are not in this curve flame war, you don't need to
change anything at all. Its all in the compatibility-mix
and you can just as work as before, if you prefer.









Thursday, July 7, 2016

opcoin trickery

A new tool (opcoin) has been added to opmsg's contrib directory,
which allows to convert bitcoin keys to opmsg personas.
You may find convertable public BTC keys in any
BTC (P2PKH) transaction. So you just go to your favorite
blockchain website and search for an address that you know
belongs to a certain person and import their pubkey(s).
The calculated BTC address (match) ensures that its really
the key you want to import and will since then appear
as the personas name inside opmsg keystore.

Voila! Suddenly opmsg became the crypto system with the largest
keybase world wide! One more benefit: you can ensure that a
dedicated persona name is in possession of a private key,
by authenticating them via micro transactions.

Read more details here. 

Thursday, June 23, 2016

Lets feed attacker input to "sh -c", to see what he's doing

This week I published a PoC for CVE-2016-4989 , which is
yet another local root exploit for setroubleshoot, working
out of the box on CentOS/RHEL 6.6, 6.7, 6.8, 7.0 and 7.1.

The underlying vulnerability and exploitation strategy
is very similar to CVE-2015-1815. So the writeup inside
the git almost entirely applies, except that the PoC
may be executed via remote shells (ssh) and that it is
using a helper binary in order to get a SELinux domain
confinement for an unconfined user, triggering the bug
inside setroubleshoot. To my knowledge this is a novel
approach. Its also new that straight-shooter may be
used as a Docker breakout, if run inside a container,
which has running setroubleshoot running on the host.

Out of personal interest: If you like exploits - either
professional, or as a hobby - and demand for
freedom of speech or freedom of expression, try your best
to lobby against the Wassenaar regulation of exploits. The
Wassenaar regulation of exploits is just a vehicle (sold to
you as a privacy win) to cover backdoors and criminalize
bug finding. Any serious exploit coder and researcher I know
is arguing against Wassenaar, and so should you.