Message-ID: <CY1PR20MB0156E880191C790A105680A4D0490@CY1PR20MB0156.namprd20.prod.outlook.com>
Date: Sat, 28 Jan 2017 01:40:06 +0000
From: Daniel Elebash <danelebash@...mail.com>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Subject: Re: [FD] Digital Ocean ssh key authentication security risk --
 password authentication is re-enabled

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@...lists.org> on behalf of Daniel Elebash <danelebash@...mail.com>
Sent: Friday, January 27, 2017 12:00 PM
To: fulldisclosure@...lists.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/

Powered by blists - more mailing lists