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

[Dwight Engen]

On Wed, 25 Dec 2013 18:54:57 -0500
"Michael H. Warfield" <mhw at WittsEnd.com> wrote:

> [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 agree that using known, weak default passwords is asking for trouble
and I think your suggestions are a big improvement. Some of the
usability problems could be overcome if we would standardize that all
templates support ssh authorized_keys injection (ala what the ubuntu
template already can do) but maybe we should look at what cloud-init
does as well for comparison.

> 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