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. :)
Posts
