[liberationtech] Auditing of Auto-Update of software commonly used by Human Rights Defenders

[Jed Crandall]

Hi all,

Sorry to jump in awkwardly into this thread without quoting, but I don't
know how else to reply in digest mode.

Regarding MitM attacks, we looked at this a couple of years ago and got
too depressed to continue.  Our campus was forcing people to install a
"policy key" that used Blowfish (i.e., non-symmetric) encryption to
update itself with admin privileges.  This was fixed in a pretty stupid
way that made exploitation still pretty easy, and then finally fixed in
a slightly less stupid (but still pretty stupid) way where the vendor
basically gave all their customers their private key.  Then we took a
look at Java, figuring that it was installed by everyone, everywhere.
It also had a MitM vulnerability in its software updates.  So we
published a workshop paper...

http://www.cs.unm.edu/~crandall/foci2012asymm.pdf

...and then gave up and moved on to other things, because finding MitM
vulnerabilities for software updates is apparently too easy of a problem
to be considered academic research.

We toyed around with the idea of developing some network scanning rules
to count updates on a campus network and perform some kind of triage
process where the most common updates for our campus were assessed to
find the most likely binaries that would have poor update practices
(e.g., by doing some dynamic analysis to answer questions like, does
this binary even bother to do any crypto at all?).  Get in touch with me
if you're interested in discussing that more.

Note that Stuxnet exploited a poor update process on Microsoft's part
and FinFisher did the same for Apple, so the big vendors are not immune
to this problem.

Also wanted to point out these papers, in addition to The Update
Framework that someone else mentioned:

http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
http://usenix.org/events/hotsec06/tech/full_papers/bellissimo/bellissimo.pdf

Jed