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

[Michael H. Warfield]

On Wed, 2014-01-01 at 14:26 -0600, Serge Hallyn wrote: 
> Quoting Michael H. Warfield (mhw at WittsEnd.com):
> > [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

> Lol - I remember setting up a honeypot behind an l2 logging firewall
> around 2001 and trying to get someone to bite by joining all sorts of
> suspect irc channels.  No luck, I was very disappointed.  Anyways,

It helps having a lot of address space like I do.  Most of what I catch
is pure brute force scanning.  Port's 22 (ssh), 3389 (rdp) and 5900
(vnc) get a lot of hits in my darknet / net-telescope.  Sometimes, I see
an ssh scan-the-planet scan come through and check my active VM's where
they seem to "throw the pot at it" when they find an open ssh port.
Very rarely is it anything better than a medium sized dictionary attack,
though.  I set up special ssh honeypots specifically for the Debian weak
ssh keys debacle and never even got a nibble.  That was kind of
disappointing.

Over the holidays, it was lots of laughs watching some clowns (one in
particular in Germany) doing some UDP scan-the-planet scans for port 123
(ntp).  Some dudes were setting up ntp reflection attacks for DDoS.  I'd
see probes to my darknet but I also have a (smaller) grey net (it
responds to pings but it otherwise a null routed network like the
darknet).  In the case of the graynet, they could ping an address and
then tried to get it to send out ntp reflections without even knowing if
an ntp server was there!  WTH?

> > 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.

> Why not purely random?  I also liked the suggestion of putting the
> password in a file under $lxcpath/$lxcname - though chmod 600 owned
> by the calling user, not root.  I prefer not outputting it in
> stdout during create, but am not *strongly* against it.

I'm actually largely against "purely random" passwords, particularly
when we're just trying to defeat a particular attack vector like this,
especially when combined with expiring the password.  I'm not sure
there's really anything significant left on the attack tree we need to
worry about (especially with the current state of affairs) and purely
random passwords are a significant PITA.  I think xkcd had it nailed
here:

https://xkcd.com/936/

I'm open to storing it in a file and, yeah, adding a chown 600 is fine.
Raises and issue though that a number of these templates will only run
as root and have not been adapted for running under a non-priv user.
That's another discussion that I think you and I and others need to
engage in.

> > 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!
> > 

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/20140101/8eb03cf0/attachment.pgp>