[lxc-devel] Strawman proposal... Default passwords in templates...

[Michael H. Warfield]

[Holiday is mostly over...  Most of the family has departed to their
homes or other homes.  Grandpa lays back to a late nap - errr -
E-Mail...]

Ok all,

Serge and Stéphane know my background as a security researcher and
expert.  This has been something that has been bothering me for some
time and I think it's time for some serious discussion.

The current container templates create templates with horrible bad
passwords.  Fedora, CentOS, and others create the "root" account with
the password "root".  Ubuntu creates the user "ubuntu" with the password
"ubuntu" with su / sudo authority to superuser.  There are other static
conventions.  All are bad bad BAD!

I recently had opportunity to spin up a couple of CentOS PoC (Proof of
Concept) containers for another project I'm working on.  Now, remember,
I'm a security person and, as such, I have a number of honeypots and
security detection mechanisms in place.  My "interesting days" usually
being with "what just happened" or "what the hell was that" or "it never
did that before".

So it came to pass...  One of those containers tripped some alarms and I
examined it to find that I had neglected to change that password (I was
working on the other container) and it had gotten whacked within one day
(my containers are bridged onto my IPv4 /16 network space).

Ok...  Day just got more interesting now.  Flipped off my "LXC hat" and
flipped on my "security hat".  Let's see what we've got.  We've got some
processes running and burning time like "/etc/atdd", "/etc/lsapd",
"/etc/kysapd" and "/etc/cupsdd".  Hmmm...  Not good...

Cool...  Shut that container down and find some interesting goodies.
Things that relate directly to this:

https://isc.sans.edu/diary/Unfriendly+crontab+additions/17282

Very cool.  Now, I've got the attacker toys and binaries to play with.
I even caught them before ISC did.  :-)  Not so cool for non security
people, though.

What happened...

Shortly after spinning those containers up, one of the frequent ssh
scans came by and busted the root account.  This was confirmed
through /var/log/secure.  Amateurs!  They didn't even clean the logs
behind them.  RANK amateurs!  Geeeze...  Hacker quality control really
has gone to shit these days.

The attacks came from a site in China and the C&C (Command and Control)
was also located in China.  For me, this is nothing.  This is actually a
lot of what I use LXC for.  Set up systems and let them get whacked and
collect new toys for analysis.  I just wasn't expecting it so soon in
this particular one and was due to an oversight on my part in my haste.

The malware seems to be of a DNS amplification attack family for DDoS
I have yet to see any ssh brute force attack that does any further than
lame password attacks.  The attackers are LAZY.  They don't need to do
sophisticated attacks because the stupid attacks still work sooo well.
attacks, which seems kinda crude, as they set themselves up on port
53/udp and started chattering with their C&C servers.  Really kinda
boring stuff.

I have ssh honeypots running continuously and the scans and dain
bramaged simple minded scans with lexicons of only a few hundred
passwords for a few accounts like root, toor, user, plus a few strange
ones I won't mention.  Yes, ubuntu and liveuser are on the use hit list
and, yes, ubuntu/ubuntu is toast.

I have yet to see any ssh brute force attack that does any further than
lame password attacks.  The attackers are LAZY.  They don't need to do
sophisticated attacks because the stupid attacks still work sooo well.

Bottom line is that we have to do SOMETHING better than the bone headed
dain bramaged passwords the templates are currently setting.  We're not
even giving users instructions to immediately change those passwords
(even though it should be obvious).

What I propose to do is to change the Fedora and CentOS templates to
conform to the following convention...  Default root password as
follows:

Root-${Container_Name}-${RANDOM}

Note: Contains one capital, multiple numbers, plus punctuation.

Add a warning that the user should change it to a user selected
password.  Include instructions on how to change it from the host using
chroot.

If they fail to note it down, it can always be changed with a "chroot
{rootfs} ; chpasswd" so there's little loss of control.

Is it secure?  Not really, but security is a process, not a state.

Is it more secure than the current state?  Most definitely.

Is it more of a problem for administrators of the host system?  Yes, but
only trivially so.  It's a PITA to enter but is readily changed from the
container or the host and vastly more secure than the lame passwords
we're using now.

It's not "bad" and highly unlikely to be busted by simple brute force.
Without the attackers having internal knowledge of the container name,
their attack surface is pretty large.  With that knowledge, the profile
is still over a /16 surface (65536 guesses) from the ${RANDOM} variable.

I intend to implement this in the templates I'm working on.  I would
love to hear comments and suggestions from everyone else.  I would
definitely want to see something better in 1.0.  Doesn't have to be
this, but someone needs to come up with something better.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131225/10b6217f/attachment-0001.pgp>