Breaking FluidNexus before Breakfast

by T. Goodspeed, M. L. Patterson, E. Saitta, and three bottles of Club Mate

## Introduction

The following is the story of how a few neighbors who were waiting for
breakfast broke the security of FluidNexus, a short messaging service
that runs through Bonjour and Bluetooth to allow for communication
when cellular networks are cut during protests. It uses a naive
broadcast model for message passing, which, while practical for the
narrowly understood purpose--keeping communication links active when
network infrastructure becomes unusable--is extremely dangerous in the
much more loaded context for which it is intended.

FluidNexus is directly marketed toward activists and dissidents,
particularly those within regimes that might attack such a messaging
service or its users.  The product is fine as a fashion accessory or
as a toy, but in practice it is worse than useless. It is so
horrifically insecure as to get its users killed. Furthermore, the
FluidNexus author has proven worse than unresponsive--indeed, outright
belligerent--when confronted with the dangerous flaws in his design
and implementation, and thus it behooves us to respond publicly and
adamantly to his new-media hipster douchebaggery before his software
puts anyone's life or liberty at risk.

We would like to emphasize that these results really were found before
breakfast, and that patching the issues we highlight here will not be
sufficient to repair FluidNexus as a product. It is hopelessly
insecure and cannot be repaired without a complete rewrite by an
author who understands security. The only responsible move on the
FluidNexus implementer's part is to withdraw his application from the
Android Market, cease distribution to end-users, and subject the
design and implementation to extensive community review before
republishing.

## Motivation

It is our intent to be neighborly, and normally we would not bend an
implementation over without the courtesy of a reach-around like this
before discreetly taking the developer aside and explaining the issues
we found. However, after airing her concerns over Twitter, one of the
authors discovered that the FluidNexus developer is an ignorant douchebag,
as evidenced by the following remarks:

@FluidNexus: ``@maradydd I look forward to it, and an explaination why
plaintext is 'criminally irresponsible' in a broadcast model.''

--Because all broadcast models are obviously created equal, especially
  where protests are concerned.

@FluidNexus: ``@Dymaxion I guess the twitter activists in syria and
egypt should be chastised for sending tactical info over twitter
too.''

--Because designing and deploying a brand-new communication system is
  exactly the same scenario as people on the ground devising uses for
  tools they already had available.

@FluidNexus: ``@Dymaxion You can look at the code.I'm not a crypto
researcher but nothing identifiable is sent nor saved, excepting what
you put in the msg''

--And thus the implementer had absolutely no responsibility whatsoever
  to consult with the crypto or privacy communities before deploying
  his tool on an unsuspecting userbase. If you believe this, we have a
  lovely bridge to sell you, and can arrange a package deal with a
  tower if you're interested. We looked at the code, and we are
  telling you now, you are leaking much more identifying data than you
  think you are.

@FluidNexus: ``@Dymaxion And any participation in protest carries
risk. We can't remove that through crypto. I submit it's better to
have this out there rather than waiting until we have the perfect
system.''

--Translation: The implementer has never bothered to familiarize
  himself with the past decade-plus of cypherpunk literature
  explaining the hazards inherent in deploying sensitive
  communications software in politically dangerous situations where
  people can and do end up on the wrong end of a gun just for speaking
  their minds.

At http://fluidnexus.net/blog/post/5: ``Are we to hold the designers
of TCP/IP responsible for the imprisonments and deaths of people
because the designers didn’t include crypto by default?''

--Of course not, because TCP/IP wasn't *designed and advertised for a
  known-hostile environment*.

``As far as we are aware there are no relevant trust models for doing
encryption within a broadcast model''

--How about Paul A. Karger's master's thesis, ``Non-Discretionary
  Access Control for Decentralized Computing Systems''? You might also
  know it as the very first paper listed on AnonBib,
  http://www.freehaven.net/anonbib. It was written in 1977. See also
  Feamster et al, ``Thwarting Web Censorship with Untrusted Messenger
  Delivery'', 2003; Wright et al, ``Defending Anonymous Communication
  Against Passive Logging Attacks'', 2003; the entire literature on
  private information retrieval, especially Sassaman et al, ``The
  Pynchon Gate: A Secure Method of Pseudonymous Mail Retrieval'',
  2005; Bauer et al, ``BitBlender: Light-Weight Anonymity for
  BitTorrent'', and many more. If the FluidNexus implementer was not
  aware of possible trust models for secure broadcast communication,
  it is because he never looked. (These papers do not address
  broadcast trust models using that exact terminology, but they
  contain applicable principles from which to derive one. Grep is not
  enough; this sort of research requires reading and understanding.)

## A Morning's Worth of Vulns

FluidNexus functions by passing short messages over an RFCOMM
Bluetooth link or a TCP Bonjour socket.  Messages are stored locally
(in the user's home directory on a PC, or on the SD card on an Android
phone) in an unencrypted SQLite3 database, and they are transferred as
cleartext with the encryption--if any--being the responsibility of the
Bluetooth socket.


Bonjour connections occur without pairing, and even though they are
intended for use over local Wifi networks, there doesn't appear to be
anything to prevent them from leaking into the cellular data network.
Therefore, a police state could easily ask the telephone company to
packet sniff all EDGE and 3G data connections for Bonjour
advertisements of the FluidNexus service.  It could also actively
participate in this service, giving it full visibility of a network
that was only intended to run with local proximity.


The software also allows for messages to be forwarded to the world at
large through the Nexus, a Python web service.  The Nexus API also
attempts to prevent HTML injection by stripping HTML tags from POSTed
messages, but it does so with a regular expression, perhaps because
Beautiful Soup was too complicated.

The Nexus API documentation conveniently indicates that updates to the
Nexus timeline are sent via HTTP POST, and "will be controlled by
OAuth", but are not currently. The source code (Networking.py:484)
suggests that the author has attempted to restrict public-timeline
posting to users who have already registered with the site and
authenticated via OAuth, by requiring a message nonce and an (empty)
private key (neither of which are mentioned in the API documentation),
but this is the lowest of hurdles for spammers and forgers.  There is
no attempt whatsoever to prevent antagonistic users from posting
facetious public messages designed to direct eager protesters into the
welcoming arms of a kettle or police van. Furthermore, attempting to
post a public message from the desktop client, even without a login
token, indicates that this code is never even executed--the warning
message that a valid access token is required (Networking.py:469)
never appears in the log.  Posting public messages simply does not
work.


The Bluetooth service runs over RFCOMM to all devices which are paired
and advertising the service by name.  Messages can be fetched or
freely inserted by any paired device, and they will then be repeated
through the network.


There is nothing to prevent the insertion of thousands of messages or
the editing of previously published messages to include fraudulent
information.  That is, a message of ``Martians have landed at
Jannowitzbruecke.'' could easily be edited to be ``The TARDIS has
landed at Jannowitzbruecke.'' with nothing to indicate which message
is older or which was inserted after the fact.  This could even be
automated through the Bonjour cellular network, causing all cellular
phones to be infected with the fraudulent message.


Further, the default messages are explicitly antagonistic to
authority.  Every time a new user joins the network, the following
messages are broadcast, making any user of the software--EVEN AN
INNOCUOUS ONE--appear to be a dissident.

[SAMPLE MESSAGE] Run against Bush in progress (just went through times sq).  media march starts at 7, 52nd and broadway
[SAMPLE MESSAGE] Video dispatch. Federal agents trailing activists at 6th Ave and 9th St. Situation tense.
[SAMPLE MESSAGE] CT delegation @ Maison (7th Ave. & 53rd).  Outdoor dining area.  Try to get people there.


Additionally, the ownership of a message is attributable when the
client's database is dumped.  On an Android phone, *any* application
with access to the SD card can dump the database in this way, making
trojans trivial to implement.  Further, this database column does
nothing to benefit the users of the software, putting them at risk for
no reason.

pro% sqlite3 ~/.FluidNexus/FluidNexus.db
SQLite version 3.7.4
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select title from messages where mine;
Run
Martians know cryptography!
Things change.
Evidence against me.
sqlite>

## Conclusions

Just because you as a toolsmith care a lot about your cause does not
guarantee that the tools you write will be fit for purpose.  If you
are confronted with the fact that you did not, in fact, have a
sufficient depth of knowledge to be doing the work you've attempted to
do, the only acceptable response is to put aside your ego, acknowledge
the situation, and work to repair it before people die.

Please withdraw Fluid Nexus from the Android Market and stop
distributing the application to end-users until the design has been
vetted and corrected.

As security and privacy researchers, we are extremely sympathetic to
the need for censorship-resistant communications, especially in
locations such as Egypt, Tunisia, and San Francisco. As hackers, we
also appreciate and even encourage n00bs getting involved in the fight
for unfettered speech. However, n00b enthusiasm untempered by an
appreciation for the lessons that the remailer, onion-routing and
cryptography communities have spent the last two decades discovering
is arrogant to the point of active hostility toward activists whose
personal safety depends on fault-tolerant, Byzantine-tolerant,
unforgeable and secure communication.

We bitch-slap you because we care.