Security flaw in default Raspbian setup: SSH server enabled and password set to 'raspberry'

[ghost]

In a fresh Raspbian install, the following two factors combine to create a critical security flaw:

• The user is not prompted to set a password on first boot; instead a default password 'raspberry' is automatically set for the primary user 'pi'.
• An SSH server supporting password authentication is automatically enabled.

Clearly, if no configuration changes are made after a fresh install, connecting the Pi to a public network (e.g. wifi) allows any other network user to gain full control of the system, including obtaining superuser privileges via 'sudo', merely using 'ssh pi@raspberrypi' with password 'raspberry'.

In order to fix, please do at least one or preferably both of the following:

• Require that a custom username and password be set manually on first boot.
• Have the SSH server disabled by default.

All other GNU/Linux distributions that I am familiar with (e.g. Debian, Ubuntu) do both of these things. Many Raspberry Pi users are children or beginners to GNU/Linux who have never even heard of 'SSH': for everyone's sake we should be providing a safe and secure system by default.

[spl237]

This is a difficult issue. A lot of Pi users use SSH for debugging crashes and the like which prevent the system being accessed in any other way. And as you correctly point out, a lot of Pi users are beginners to Linux.

However, the same argument - that these users are beginners - which you use for saying that SSH should be disabled or that users should be forced to change a password - is also an argument for not disabling SSH and forcing a password change. The fact that the password is the same on all default Pi installations means that when people forget it (because they haven't needed to use it as their Pi is set up to autologin anyway), it is easy for them to recover. The fact that SSH is enabled by default means that someone who crashes their desktop by injudicious tweaking of a config file has a chance of getting in and sorting it out.

You then need to consider how likely the attack you propose is. The Pi is not fundamentally a portable device - it needs a screen, keyboard and mouse for most uses. So its connection to a public wifi network is unlikely. Even if someone were to connect it to a public network and to have it penetrated in the way you describe, there are few things that an attacker could actually do, even with sudo, which wouldn't be easily solved by flashing a clean copy of Raspbian onto the SD card. People do not often store their bank details on their Pi - it's not a phone or a tablet, where the risk both that a) it may be connected to a public network and b) there is sensitive data on it, are much higher.

So there is a balance to be chosen between adopting the secure approach you propose, or adopting a more forgiving approach for beginners. We have thus far adopted the more forgiving approach, and, given the Pi's target market in education and schools, I don't think the risks of continuing with that approach are outweighed by the inconvenience that follows from locking the system down by default. If someone does want to make their install more secure in either of the ways you propose, we provide a simple GUI tool for doing so. For the time being, we will therefore continue to leave a default password and SSH enabled, but that does not mean we may not change this in future depending on circumstances.

[diederikdehaas]

it needs a screen, keyboard and mouse for most uses

None of my 5 RPi has any of those.

there are few things that an attacker could actually do, even with sudo

sudo su and I'm root, aka as god mode and I can do literally anything I want with it. Making it part of a botnet seems like a good candidate. This is one of the critical things that is SOO wrong with the IoT ... which I believe the RPi is also promoted as being a good device for it.

People do not often store their bank details on their Pi

I (and others) use a RPi for the offline storage of my bitcoins. (And I would never store sensitive data on my phone as it is fundamentally an insecure device)

Not that I will be affected, but I saw a bunch of assumptions which I just debunked. And you probably know what they say about assume :wink:

[XECDesign]

@diederikdehaas Are your pis accessible through SSH with the pi@raspberry credentials? If so, does your user 'pi' have nopasswd sudo enabled? If either of those answers is a no, then I don't think you or anybody else with your use case is affected by this issue.

(I do believe this is an issue, I just don't believe the sky is falling)

[diederikdehaas]

Neither of my Pi's have a pi user and if I use sudo, then it's always with a password prompt. And on important systems, I lock out the use of password for SSH access as soon as possible.

And you're absolutely right that I won't be affected by this, I even said so, but I found the assumptions dangerous and wanted to point that out.

[ghost]

@spl237 I see your point about the balance between security and convenience. May I suggest a possible solution? We could keep the default 'raspberry' password, but disable the SSH server by default and instead add the following feature as a means for recovering after mistakes in editing config files:

PROPOSED FEATURE: If the user holds down a particular key (e.g. F2) at boot time, then the Pi boots into a 'recovery mode' in which it ignores '/boot/config.txt' and goes straight to a minimal text shell, without attempting to load the graphical desktop environment.

The minimal text shell would allow the user to fix their config file and then reboot as normal. When compared with SSH, this feature has the added advantage of allowing the user to recover the Pi without needing a network connection or a second computer in order to do so.

What do you think?

[spl237]

@diederikdehaas If you are running 5 headless Pis and storing bitcoins, you are doing something which is beyond the knowledge of a typical inexperienced user. This activity exposes you to risks to which they are not exposed - but by the fact that you have the knowledge to carry out these activities, you have the knowledge of how to secure your system.

When it comes to making assumptions, one which people who have an interest in cybersecurity tend to make is that other users, while ignorant about security, are also using the Pi for the same sort of things as they are and are therefore in need of the same level of security. This is not, generally speaking, the case.

@robjhen That seems a reasonable compromise, which we can certainly look into the feasibility of implementing in Raspbian. Some form of robust recovery mechanism which restores a booting system while preserving user data is a desirable feature, and SSH is not ideal for this; it's just what happens to be there!

[diederikdehaas]

I know this is in vain and you will assume it won't apply to the RPi ...

Making it part of a botnet seems like a good candidate. This is one of the critical things that is SOO wrong with the IoT ... which I believe the RPi is also promoted as being a good device for it.

... but you may not want to be a part of the list posted on https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/ and another IoT attack which pretty shortly followed it: http://arstechnica.com/security/2016/10/double-dip-internet-of-things-botnet-attack-felt-across-the-internet/ and right on the point comment: http://arstechnica.com/security/2016/10/double-dip-internet-of-things-botnet-attack-felt-across-the-internet/?comments=1&post=32109731#comment-32109731

/me out

[ghost]

I just found the following article, published earlier this month by Splunk, a US-based company that develops security and data monitoring software:

http://blogs.splunk.com/2016/10/07/analyzing-the-mirai-botnet-with-splunk/

This article reveals that the Raspberry Pi's default login credentials are already being targeted on a large scale by botnets.

In this article, the author Anthony Tellez describes how he ran a honeypot to record malicious login attempts to his computer from the internet. He discovered that thousands of these login attempts used the Raspberry Pi's default login credentials. Quoting from the article: "An interesting user account ... being targeted by another IoT botnet is the user pi." Tellez was even able to discover from which countries the Pi-targeting attempts were coming from, observing "there is overlap between the Mirai botnet in Ukraine and this secondary botnet targeting the Raspberry Pi".

Given this new evidence, I would urge the Raspberry Pi devs to reconsider and make fixing this issue a priority.

@spl237 You mentioned that:

connection to a public wifi network is unlikely

This may be true, however it is vital to note that it only takes a Raspberry Pi to be compromised once while on a public network. After that a piece of malware can continue to connect to the internet and perform its function while the Pi is behind a regular firewall or home router. Furthermore, even if a Pi is never put onto a public network, it can certainly be compromised via its default login credentials by another malware-infected computer or IoT device within the local network.

You also wrote:

there are few things that an attacker could actually do

I don't believe this is true at all. For a list of things that an attacker could do please see the security expert Brian Kreb's excellent info-graphic on 'the value of a hacked PC':

https://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/

This list includes making the device part of a botnet as @diederikdehaas has pointed out above. I'm sure you'll agree that yesterday's massive IoT botnet attack on the Dyn DNS provider highlights the severity of this problem.

So, to re-iterate, with respect will you make fixing this issue a priority?

[spl237]

I am currently in the process of writing an application which will run on first boot to prompt the user to change their password. (On discussion internally, disabling SSH by default would be unpopular with those who run Pis headless, as they will be locked out of running new images.)

Frankly, I am doing this in the expectation that it will make very little difference to anything - with most people running Pis behind routers whose default firewall settings should not be exposing the Pi's SSH ports anyway, the chances of an external SSH exploit are slim for the vast majority of users. However, changing from a default password is good practice and is to be encouraged. That said, we are only going to suggest it, not mandate it - it will be up to a user whether or not they opt to stick with the default, and there are certainly cases where it makes more sense for users not to change it.