Killing Schrödingers Cat

This post is about the so called FoxAcid/QI system apparently

used by an agency to exploit browser sessions.

I first read about FoxAcid in an article by Bruce Schneier,
who made the distinction between Man in the Middle (MiM) and
Man on the Side (MoS) attacks. Although, if
properly implemented, the referenced slide
shows a setup where no packet race exist (therefore a MiM),
there seem to be use-cases for MoS attacks.

I am only discussing HTTP/HTTPS case here, as for VPNs etc,
you clearly need MiM and the aim of FoxAcid seems to
be the exploitation of web browser client sessions.

Deploying MiM on the backbone requires quite large and expensive (both financially and technically) setups. In most cases you require the coop of the ISP or someone who made the firmware of
the routers along the path. Nevertheless, if possible, MiM is clearly
the way to go, as it allows to intercept and 'handle' encrypted
communication channels. MoS on the other hand fails to
'handle' SSL connections, as its not possible to spoof
a HTTP redirect into the session.

But MiM is easy to detect and hard to deploy
in foreign networks in the large scale,
since you basically try to add a new router
(or even transparent-proxy) to the network infrastructure.

So you have some kind of lightwight-MiM, called MoS.
Since most connections will be either HTTP or
initiated by HTTP, even if 'upgraded' to HTTPS later on,
MoS buys you a lot of benefit.

MoS does not require to deploy new router hardware,
firmware or routes to be added to the running configuration.
It works by simply plugging the MoS-box to a port that
mirrors all packets seen for 'diagnostic purposes'.

You need a second, normal uplink plug, in case the mirror
port does not accept packets for sending, but thats doable.
I am not familar with backbone routers and their mirror port
capabilities, but I guess thats easily done.

The MoS attack can then act upon seen SYN packets
(completing the handshake) or seen GET requests. The later
requires to track the connection and therefore synchronous routes
back to the client (to see the SYN|ACK). The former does not,
but then in turn does not allow to redirect to the expected
location in some cases, as its missing the Host:
information from the client request.

I implemented both cases here. At least this is how I
would implement a QI/FoxAcid framework, there might be
different ways. However, acting in a packet-race (you
cannot modify replies) leaves not too many options.
It can be easily tested in your home (W)LAN and the
FoxAcid will show you by color which requests it
intercepted:

The captured GET request is sent Base64-encoded (green) to the
FoxAcid server, which uses this info (blue) to properly reconstruct the path and Host: parameters.The red part
is sent to the client in order to exploit and redirect
the browser to the original destination afterwards.
(No, I am not using this browser and the green part is smudged
in order to prevent accidental info-leaks as I cannot
read Base64 on the fly, but its the Base64 encode of the blue
part.)

MoS is also interesting if you have capabilities of
breaking 3G or 4G (or wifi) crypto in realtime, since it allows
you to spoof the replies to the sending station directly,
circumventing the network structure entirely (in opposite
to deploying a MiM somewhere behind the BTS/AP or
replacing them). If you are on foreign ground that might
be easier with good RX/TX equipement and a laptop rather than
to setup and integrate a whole BTS on the roof top of an embassy. :)

sshttp IPv6 trickery

During last hackweek, I added IPv6 support to
sshttp. Courtesy of IPV6_TRANSPARENT in recent Linux
kernels, it works as you know it from IPv4.

Beside that, it's now also possible to add IPv6 backends
to the frontend reverse proxy which is part of lophttpd,
and to run it on an IPV6 address to the outside.

lophttpd seccomp trickery

Hey guys, you know what?

I added seccomp sandbox to lophttpd. It is an experimental
Linux-only feature, enabled by -DUSE_SANDBOX compile time switch.

I really should add that feature to the frontend reverse
proxy too as well as getting in touch with FreeBSD's
capsicum in order to support multiple platforms.

The benefit is that, even if lophttpd already runs unprivileged
in a read-only chroot, the impact of potential RCE vulnerabilities is even more restricted. The sandbox also
covers the OpenSSL code, so it is not necessary to use
SSL privilege separation any longer.

To my knowledge lophttpd is the only webserver that supports
seccomp sandbox.

Additionally, I removed any EC or RC4 based cryptography from
the SSL code. Basically what you get now is RSA+AES+SHA
which is believed to be a cipher secure from NSA unlike
NIST based ciphers or probably ECC entirely, not just with
the NIST curves.

PrivSeb trickery

During recent anual 743c PrivSeb conference meeting, I ported
some of my tools to Android. Some of them require root
and some have been ported to work as shell user.

The former allows to bridge out interfaces so you can use
your tools as-they-are locally in the lab to access devices that
appear somewhere on a remote smartphone. The benefit
is obvious.

The later tool is a sshd-like management
for devices. I yet need to figure out some details for
mass administration and stronger theft-protection.

We also enjoyed discussing good old times, tried
to estimate how exploit development on Android will be
in future and exchanged some SHA hashes for the good. :)

After that, the (meanwhile well established part of the Con)
outdoor event Race-Condition was fun too. I might publish
some pictures of that later this year.

Ported tools wont be published, yet if you want to discuss
feel free to send me an email.

Portshell crypto trickery

I re-polished some of my old tools and imported them
to github. This time it was psc.

The port-shell crypter (psc) allows you to 'upgrade'
previously unencrypted sessions, no matter whether
its a multi-hop SSH session, a portshell without a tty,
telnet, rlogin or minicom.
It gives you a full pty with end-to-end encryption.

You can also use it as a kind of two-factor authentication
with SSH, if you add psc-remote as shell inside
/etc/passwd or use OpenSSH's ForcedCommand option.

Tunnel trickery

I just added fraud-bridge to my github. It was worth
coding even if there exist a lot of DNS and ICMP
tunneling tools.

Features:

o tunneling of TCP-connections, keeping TCP-state
o via DNS: on UDP or UDP on IPv6
o via ICMP or ICMPv6
o HMAC (MD5) protecting of tunnel content
o transparently patching announced TCP-MSS to prevent
  fragmentation or DNS packet splitting
o using EDNS0 extension for DNS-tunneling to achieve good
  througput (larger DNS TXT-replies fit into one reply, honouring
  announced MSS)
o cope with bind9 limits/quota and still having good latency
  for interactive sessions and good throughput
o once started as root, continues to run as unprivileged user
  inside a chroot

If you want to know how a fraud-bridge looks like, check
current blog entry picture, taken during one of my lost-places
tours.

OpenSSL PrivSep trickery

During this years hackweek, I implemented a
OpenSSL PrivSep. It's far from complete, but it features most
of the SSL functions you need to run a SSL server
or client. It also features the seccomp sandbox,
so all the dirty SSL handshake and protocol/parsing is done
in a confined process.

I used my research webserver project, lophttpd to
demonstrate on how it works.
Basically you just include two header files,
provide a callback named privsep_init() and tell
the PrivSeped process, which is started at the
time you call any of the OpenSSL init functions,
when to actually drop the privileges with
SSL_privsep_ctrl(PRIVSEP_DROP_PRIV). And thats it.

You can copy the *.c and *.h files from the sslps
git repo to the lophttpd dir and make -f Makefile.sslps
Do not mind the warnings about the redefinitions
of certain OpenSSL macros, they need to be replaced
in order to proxy all the SSL_ functions to the
confined process.

Fear my drawing skills and have a look at the whole picture
so its easier to understand :)

Nirvana trickery

We miss you Kurt, your music is an endless source of
power for creating the 90's exploits.

YEAAAAAAAAAAAAAA\x41\x41\x41\x41\x41\x41\x41YYYYYYY! (at 2:22 !!)

CLONE_NEWUSER trickery: CVE-2013-1858

Recent kernels (3.8+ something) introduced a feature called
user-namespaces (user-ns, CLONE_NEWUSER flag)
in which you can have your own UID 0.
Think of it as a container solution, so you can
set up compartments on a host. A nice thing,
but it has some security implications. In particular
if you mix this feature with CLONE_FS, which means
that the file-system state is shared between the
containers (e.g. processes). You suddenly get this:

The problem here is that parent and child share the
FS info (the chroot in this case), but only the child
has got its own user-ns. Since it has the
capability to do the chroot() in its own user-ns,
it will succeed doing the chroot() syscall but due to
CLONE_FS, it will also affect the parent.
Parent however stays in the init user-ns (the user-ns
that is default upon boot and the namespace where you
want to have root).
Getting a rootshell from inside a user controlled chroot
with help from outside processes is straight forward.

The xSports can be found here.

Update:
A CVE has been assigned (CVE-2013-1858) and a patch was made.

c25k problem solved

Although the c10k problem is not really a problem in
Computer Science anymore, I successfully solved the
c25k problem (and I am not talking about exploit prices)
for myself.

lophttpd can handle even more connections on a commodity PC,
single core, without connection drops. If your network equipment 
is just good enough (GBit patch cable!:)

I added a new -s switch that lets you experiment with different
scheduling strategies if the TCP send buffers start to fill.
Nevertheless, as poll() will not report a POLLOUT revent
if the TCP send buffer is full, the none stragegy should just be fine. 
Other strategies are minimize (reduce chunksize to minimum)
or suspend (temporarily remove client from POLLOUT list, if
TCP send buffer has data from last send). In particular the
suspend strategy may be of interest, as it reduces the
amount of poll events that the kernel needs to check for.
However, I could not measure any real benefit. Probably one
reason more to say that c10k is not a problem anymore since
quite a lot of time.

Interestingly: lophttpd, if under load, can even utilize
more than 100% CPU:

lophttpd caching trickery

I added 404-caching to lophttpd, in the hope that
it will result in overall speedup if a lot of clients
try to fetch non-existing files (favicon.ico etc.)

The key for the cache is the first line that is sent,
so once we see this request again, we dont need to parse the
entire header, decode the pathname and stat() it before we send
the error reply. Good, eh?

Valentine pam_fprintd trickery

Anyone can give your finger by spoofing DBUS signals
to pam_fprintd, effectively bypassing fprintd authentication.
Tested with fprintd 0.41.
darklena is the PoC and the authors have been informed.

Its probably about time to check dbus-glib usage or usage
of DBUS signals in privileged code in general.

[Update:] successfully tested on a vanilla FC16 setup with
fprintd installed from repository and SELinux target config
left as-is: