[sf-lug] SF-LUG meeting of July 18, 2016 and 3 items of note...

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

>     Finally in case you had not heard the Ubuntu servers got hacked
> and no one knew about until the hacker spoke up.
> <http://www.linuxandubuntu.com/home/ubuntu-forums-hacked-here-is-what-hacker-stole>

A few impressions as I read reports about this:


They're talking about site https://ubuntuforums.org/.  Owner/operator of
that site isn't mentioned explicitly in its credits and notices, but a
number of things suggest it's Canonical, Ltd. (including ownership of
the Internet domain, which is explicitly that corporation's).


Site is a Web forum operated using vBulletin, a proprietary developed PHP
application -- not open source.  META tags in the HTML source claim the
site is currently running vBulletin 4.2.2.  (Not a criticism, but I'd
personally have hacked all the PHP to make it claim to be some
hilarously wrong version number, and maybe also some hilariously wrong
software project name.  I should note in passing that the 'v.4.2.2'
string being returned could be deliberately misleading, or accidentally
so.  I just note it's there.) Internet Archive snapshots from before the
breach announcement and all the way back to 2014 _also_ claim it was
running vBulletin 4.2.2., e.g.,
https://web.archive.org/web/20160711074333/http://ubuntuforums.org/ .


In July 2013, there was _also_ a security breach and defacement.  See:
https://web.archive.org/web/20130721004556/http://ubuntuforums.org/announce.html
(I gather that this was right after it opened.)


Before I forget to say it, my sympathies to Canonical, Ltd.  Getting
broken into suxx0rs.


Public notice of the 2016 incident at
http://insights.ubuntu.com/2016/07/15/notice-of-security-breach-on-ubuntu-forums/
credits Jane Silber, Canonical Ltd. CEO, as author.

Ms. Silber states that attackers used a SQL injection attack -- whose
identity she did not specify.  It would be interesting to see a specific
CVE number cited for the vulnerability used -- if they know which one
was used, which maybe they do and maybe they don't.  Public disclosure
says attackers got the contents of the User table (usernames, e-mail
addresses, IPs), and 'hashed and salted random strings'.  Claim is that
no passwords were exposed because forum uses Ubuntu SSO instead of
passwords in the User table.

I'm a little mystified why vBulletin was hashing and salting random
strings and storing them in the User table.  Vestigial code following
hacking in of SSO auth?  Seems odd, and I'd love to see further
explanation of that peculiarity, but I'm sure they're a little busy, and
certainly don't owe me bupkes.


Announcement says 'We brought vBulletin up to the latest patch level.'
It appears that (judging by Wikipedia) each release has not only an
advertised release number but also an unadvertised patch level.  E.g.,
vBulletin 4.0.4 Patch Level 1 would display to the public just
'vBulletin 4.0.4'.  Browsing the vBulletin support forums (which are of
course run using vBulletin, good for them!), it appears that v. 4.x is
no longer developed except for maintenance under support contract, the
most recent 4.x release I see mentioned being 4.2.3.  Flagship version
for new customers is 5.2.x, where 5.x is impliedly a new, not compatible
development branch (to which 4.x can be upgraded).


'We’ve installed ModSecurity, a Web Application Firewall, to help
prevent similar attacks in the future.'  ModSecurity is an open source
Apache httpd module (or IIS, or nginx) that applies a large set of
pattern matches against incoming HTTP requests and prevents processing
of ones deemed nasty in various ways.  It's certainly a good idea for
Canonical's use model, though in an ideal world they'd be able to run
developed Web code that doesn't suck, hence not need to bandaid it
behind a filtering proxy.  But that's the bad reality admins of
developed proprietary PHP codebases are obliged to deal with, every day.
(I am doubly sympathetic, given that.)

Personally, I'm of the opinion that PHP is too big a security menace to 
expose to Internet traffic, not even counting bugs in developed
proprietary PHP apps.


Although Ms. Silber and her IT staff state that password data were not
compromised to the best of their ability to tell -- and there's no
reason whatsoever to doubt this -- it's worth spending a few minutes for
-you- to consider what you would do if there were reason to believe your
user password might have been, or was, compromised.  Because that _does_
happen in some cases.  If you're lucky and the site operator is
conscientious as Canonical appears to be, they'll tell you.  But often
you won't get told.

Most people re-use the same access credentials across many sites
(because human memory can't reliably do the full job, unaided).  In
the event of security breach, this habit really bites people hard.
Sometimes, the user cannot even reliably remember all the places he/she
uses password foo.  This is a big problem.  You should do whatever
prevents you from being that person.

One common aid users rely on is the category of application called
'password manager', which please see:
https://en.wikipedia.org/wiki/Password_manager  The idea in general is
to have a central location you store passwords so you don't have to
remember them all and so you can reliably use strong passwords uniquely
chosen for each separate site, not shared across multiple places.
There are a lot of fine points, but those are beyond the scope of what
I'm writing today.