On Wed, Jul 8, 2009 at 9:05 AM, David Gerard<dgerard(a)gmail.com> wrote:
2009/7/7 Aryeh Gregor
<Simetrical+wikilist(a)gmail.com>om>:
But really -- have there been *any* confirmed
incidents of MITMing an
Internet connection in, say, the past decade? Real malicious attacks
in the wild, not proof-of-concepts or white-hat experimentation? I'd
imagine so, but for all people emphasize SSL, I can't think of any
specific case I've heard of, ever. It's not something normal people
need to worry much about, least of all for Wikipedia.
Nope. The SSL threat model is completely arse-backwards. It assumes
secure endpoints and a vulnerable network. Whereas what we see in
practice is Trojaned endpoints and no-one much bothering with the
network.
Actually, there is a lot of screwing with the network.
For instance, take the UK service providers surreptitiously modifying
Wikipedia's responses on the fly to create a fake 404 when you hit
particular articles.
I believe it's a common practice for US service providers to sell
information feeds about user's browsing data (believe because I know
it's done, but don't have concrete information about how common it
is). Your use of Wikipedia likely has less privacy than your use of a
public library.
SSL kills these attacks dead.
People whom try to read via Tor to avoid the above mentioned problems
subject themselves to naughty activities by unscrupulous exit
operators. MITM activities by Tor exit operators are common and well
documented. SSL would remove some of the incentive to use Tor (since
your local network/ISP could no longer spy on you if you used SSL) and
would remove most of Tor's grievous hazard for those who continue to
use it to read.
There are some truly nasty things you can do with an enwiki admin
account. They can be undone, sure, but a lot of damage can be done.
They are obvious enough, and have been discussed in backrooms enough
that I don't think I'll do much harm by listing a few of them:
(1) By twiddling site JS you can likely knock any site off the
internet by scripting clients to connect to the sites frequently.
Although this can be deactivated once it was discovered, due to
caching it would hang around for a while. Well timed even a short
outage could cause significant dollar value real damage.
(2) You could script clients to kick users to a malware installer.
Again, it could be quickly undone, but a lot of damage could be caused
with only a few minutes of script placement. Generally you could use
WP as a nice launching ground for any kind of XSS vulnerability that
you're already aware of.
Any of these JS attacks could be enhanced by only making them
effective for anons, reducing their visibility, and by making the JS
modify the display of the Mediawiki: pages to both hide the bad JS
from users and to make it impossible to remove without disabling
client JS. Provided your changes didn't break the site, I'd take a
bet that you could have a malware installer running for days before it
was discovered.
(3) You could rapidly merge page histories for large numbers of
articles, converting their histories into jumbled messes. I don't
believe we yet have any automated solution to fix that beyond "restore
the site from backups".
(4) Any admin account can be used to capture bureaucrat and/or
checkuser access by injecting user JS to one of these users and using
it to steal their session cookie (unless the change to SUL stopped
this, but I don't see how it could have; even if so you could remote
pilot them). With checkuser access you can quickly dump out decent
amounts of private data. The leak of private data can never be undone.
(or, alternatively, you can just MTIM a real steward, checkuser, or
bureaucrat (say, at wikimania or a wiki meetup :) ) and get their
access directly).
These are just a few things… I'm sure if you think creatively you can
come up with more. The use of SSL makes attacks harder and some types
of attack effectively impossible. It should be considered important.