[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [FD] Digital Ocean ssh key authentication security risk -- password authentication is re-enabled
From:       Daniel Elebash <danelebash () hotmail ! com>
Date:       2017-01-28 1:40:06
Message-ID: CY1PR20MB0156E880191C790A105680A4D0490 () CY1PR20MB0156 ! namprd20 ! prod ! outlook ! com
[Download RAW message or body]

After two months of going back and forth with digital ocean I just received a message today \
that they have deployed a fix so you may not be able to replicate the problem.


My main concern is the not notifying customers of this behavior, most likely leaving many \
unaware and vulnerable.


Even though they have fixed this issue which was being set via cloud init, it still leaves \
currently deployed servers with password authentication set to yes.  So hopefully they will \
notify customers to check their ssh config and reset pass auth back to no.



________________________________
From: Fulldisclosure <fulldisclosure-bounces@seclists.org> on behalf of Daniel Elebash \
                <danelebash@hotmail.com>
Sent: Friday, January 27, 2017 12:00 PM
To: fulldisclosure@seclists.org
Subject: [FD] Digital Ocean ssh key authentication security risk -- password authentication is \
re-enabled

Regarding digitalocean.com cloud computing.


PasswordAuthentication is reset to yes in  /etc/ssh/sshd_config when using ssh key \
authentication given the following scenario:


When creating a new droplet from a snapshot where ssh key authentication \
"PasswordAuthentication" in /etc/ssh/sshd_config was previosly set to no, \
"PasswordAuthentication" is reset to yes.


I am not sure how common this scenario is but for me I often create a base snapshot that is \
pre-configured with firewall settings, sudo user, ssh key authentication, various apps, \
hardening etc. that I can then use when spinning up a new server so I don't have to start from \
scratch.  By doing this  I was unaware that PasswordAuthentication was automatically re-enabled \
and that these servers were no longer secure via ssh key authentication only, leaving them open \
to Brute Force attacks.


Steps to reproduce:

Tested using an Ubuntu 16.04 droplet image

1. Create a  new Ubuntu 16.04 droplet and secure it using ssh key authentication
2. Edit /etc/ssh/sshd_config and set PasswordAuthentication no
3. Reload ssh
4. Verify that you can log in using key authentication only, trying via password should be \
rejected. 5. Create a snapshot of this droplet
6. Create a new droplet from this snapshot
7. Open /etc/ssh/sshd_config and PasswordAuthentication will be reset to yes

You will now be able to log in via ssh using passwords instead of key authentication only.


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Fulldisclosure Info Page - Nmap<https://nmap.org/mailman/listinfo/fulldisclosure>
nmap.org
The Full Disclosure mailing list is a public forum for detailed discussion of vulnerabilities \
and exploitation techniques, as well as tools, papers, news, and events ...



Web Archives & RSS: http://seclists.org/fulldisclosure/
Full Disclosure Mailing List<http://seclists.org/fulldisclosure/>
seclists.org
Seclists archive for the Full Disclosure mailing list: A public, vendor-neutral forum for \
detailed discussion of vulnerabilities and exploitation techniques, as well ...




_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/


[prev in list] [next in list] [prev in thread] [next in thread]