Running RISC OS servers in 2018: is it secure?

posted in: Software | 6

Over the years, the blog has featured a few articles on running Internet-facing services on RISC OS, from web servers (WebJames and HTTPServ) to VNC and Samba shares. While those articles did go a little into the security of running those services on RISC OS in this day and age, they didn’t cover what you can expect if you open up your WebJames or Samba instance to the wider Internet.

While browsing the ROOL forums I came across a discussion about how secure it really is to run servers on RISC OS in this day and age – considering how old the majority of server applications are for RISC OS, and how creaky some parts of RISC OS’ networking stack are. That got me thinking, how secure really is it to run services that you care about on RISC OS, or maybe a service that you don’t particularly care about (e.g. a Samba share you never use) but it’s running on a system that you do want to protect.

So to understand what kind of threats there are out there today and how relevant it is to RISC OS, it’ll be first worth going over what the threat landscape is today for Internet-facing servers in general and how sophisticated (or not) threat actors are with their attempts to steal or break your cyber-stuffs.

Password attacks

So unsurprisingly the vast majority of attacks against servers on the Internet are attempts to guess their password, and a huge quantity of those are not very sophisticated at all. This is mainly down to it being so easy to get into systems on the Internet with incredibly weak passwords (if they even have one). Password cracking tools such as Hydra and John the Ripper do allow for complicated ways of getting at people’s passwords other than just going through a list of widely used passwords, but realistically, attackers just don’t need to go to that level of effort.

The Mirai malware, which enslaves Linux systems all over the world, took down a large portion of the world’s most popular websites for a while in 2016 through an enormous Denial of Service attack on DynDNS – a DNS provider that supports services such as Netflix, Twitter and GitHub – in turn taking those websites down. Mirai achieved this through scanning the entire Internet (it’s quicker and easier than you think) and attempting to login to the Telnet service at each IP address armed with a small set (about 20 or so) of default usernames and passwords that are known to be distributed with popular Internet-connected appliances such as CCTV cameras and Network Attached Storage (NAS) drives – ‘admin’ and ‘password123’ type stuff for the most part. After logging into these systems via Telnet, the malware would then get the infected machines to launch Denial of Service attacks at a target all at once.

To give you an idea of the kind of password login attempts an average server might see on the Internet. A server I administer received just under 18,000 login attempts via the SSH protocol in September, which boils down to about 235 unique IP addresses attempting on average 76 login attempts. This in itself shows that attackers generally aren’t trying every possible password connection to break into your system, instead their plowing through a list of common usernames and passwords. Below is an excerpt of the SSH access logs so you get an idea of the kind of behaviour to expect in a password attack.

Nov 20 15:09:48 Plankton sshd[46342]: Failed login for invalid user admin from 194.61.XX.XX port 55962  
Nov 20 15:43:54 Plankton sshd[47108]: Failed login for invalid user service from 194.61.XX.XX port 55962  
Nov 20 17:33:11 Plankton sshd[49591]: Failed login for invalid user monitor from 194.61.XX.XX port 55969  
Nov 20 18:10:33 Plankton sshd[50444]: Failed login for invalid user guest from 194.61.XX.XX port 50669  
Nov 20 18:49:03 Plankton sshd[51313]: Failed login for invalid user support from 194.61.XX.XX port 50669  
Nov 20 19:25:06 Plankton sshd[52182]: Failed login for invalid user test from 194.61.XX.XX port 50711  
Nov 20 20:01:25 Plankton sshd[52990]: Failed login for invalid user debian from 194.61.XX.XX port 50712  
Nov 20 20:39:15 Plankton sshd[53853]: Failed login for invalid user service from 194.61.XX.XX port 50712  
Nov 20 21:16:33 Plankton sshd[54720]: Failed login for invalid user ubuntu from 194.61.XX.XX port 57006  
Nov 20 21:54:46 Plankton sshd[55569]: Failed login for invalid user user from 194.61.XX.XX port 57006  
Nov 20 22:34:53 Plankton sshd[56508]: Failed login for invalid user ubnt from 194.61.XX.XX port 57006  
Nov 20 23:16:28 Plankton sshd[57460]: Failed login for invalid user pi from 194.61.XX.XX port 63389

So with all that in context. If you want to password-protect content on your RISC OS web server, Samba or VNC server – just set a reasonably secure password and don’t reuse that password elsewhere. This website lets you see roughly how long it might take for someone to brute-force crack your password, once you get to 8 characters or longer, a password containing a mix of uppercase and lowercase letters as well as numbers and special characters is pretty tricky to crack – most attackers would move on.

That said however, if someone with enough knowledge and determination is for some reason targeting you specifically, then you might want to stop using passwords to authenticate altogether. As far as I’m aware, this will mean you’ll need to use a non-RISC OS solution for Samba, VNC etc. as I’ve not come across a RISC OS application that supports key-based authentication yet.

Encryption attacks

If your server is going to be handling any data you don’t want others getting their grubby mitts on, for example your family photos or maybe a website visitor’s form submission, then you’ll want to be using a server solution that utilises encryption when receiving and sending data. Intercepting data being passed across the Internet using a protocol that doesn’t use encryption, for example HTTP, is trivial with the right tools.

Unfortunately for us, there are no VNC, Samba or Web server programs for RISC OS that support encryption – this includes HTTPserv and WebJames, which are HTTP only web servers.

That said, if you want to run a web server that only serves free software you’ve written to its visitors, or just some information that you don’t mind anyone seeing, then hosting it on RISC OS isn’t a terrible option.

An example of this would be my Raspbery Pi at home, it runs a WebJames instance that consists of one webpage that links to other services on my local network (my file server, media server etc.), so if someone was to sniff that connection, all they’d be able to see is links to other services, but there’s no real data being passed across.

Denial of Service

Denial of Service (DoS) attacks were making the news quite a lot a few years back but they’re still a popular method of attack today, especially for people with very limited computer skills looking to create some damage. A notable attack from the last few years was the time Sony’s Playstation Network went belly up on Christmas Day due to their servers being flooded by enormous amount of bogus traffic in order to ensure that no genuine users could log onto the online gaming network.

Coupled with RISC OS server applications being more susceptible to DoS attacks than most modern servers, the threat of huge amounts of data flooding your server to stop you or others from gaining access for a little while is a real possibility. Although it does raise the question of why, unless there’s a particular reason why someone would want to take your server down for a period of time then this isn’t something I’d be too worried about.

Vulnerability exploitation

Vulnerability exploitation is a very real threat to all web-facing servers around the world. New flaws that can be exploited into remotely exposing private data or allowing attackers to take access of the system in questions are occurring all the time. These are generally fixed by software vendors in the form of software updates once they’ve been made aware of a particular vulnerability.

There are some quite old and easy-to-exploit vulnerabilities that will be lurking in Samba and probably VNC server applications for RISC OS right now due to the age of the software or protocol versions they’re based on.

In the case of Samba, the latest version for RISC OS is 2.0.2-19990209, versions of Samba 3.6.3 and lower suffer serious security issues but given that RISC OS is an entirely different beast to the Unix/Linux and Windows systems that these exploits are designed for, I find it very unlikely that Samba on RISC OS will be exploitable unless someone goes to the extent of researching then coding a RISC OS specific exploit – incredibly unlikely unless you’ve seriously pissed off a nation state or something.

To sum up

So in the grand scheme of things, if you want to run a server from a RISC OS system and you don’t have any data that could be damaging to you or others should it fall into the wrongs hands, then there’s not really any huge red flags in your way. The possibility of someone exploiting the server software to get into your computer is incredibly small, and providing you don’t cheese off a load of teenage online gamers, then you’re probably not going to fall victim to a DoS attack either.

6 Responses

  1. Levi

    Yes, the main defense against attack on RISC OS is the obscurity of the platform. I do wonder, with the rise of ARM chips in NASes and routers, and the sheer number of Raspberry Pis that have been sold, how unusual an attack that breaks out of the client and runs raw code on an ARM 32-bit CPU is these days. And also, a lot of older attacks don’t even need to bust out of the client; they exploit flaws in the C/C++ code that the server is running in a compiled form.

    I do have to ask though, how many of these services do you actually need facing out to the internet? Not many of us are still using a modem to dial up, and if you’re using an ADSL router they’re usually configured run a DHCP server and a local network on the house side of things, so unless you’ve explicitly forwarded ports to your RISC OS machine, it shouldn’t be directly attachable. SMB/CIFS and Telnet servers are not really meant to be on the open internet in this day and age, but running them on your household network for local users is still a valid use.

    If you do want to have a public facing server, I’d say using RISC OS for the task is probably not the best OS to use. Setting up and configuring a linux server or something is not really something to go into in a forum comment like this though.

    • DOates

      Executing code on a CPU is always a local attack so the risk is low but it surely is a possibility considering how many ARM powered devices there are now

      • Sion

        DOates – I wouldn’t say it’s always a local attack, there are have been instances in the past of code executing on a CPU as a result of infecting a machine at OS-level via a remote exploit first.

        Levi – I probably wasn’t too clear in the article but when I talk about exposing a server to the Internet I was referring the service itself rather than the machine running it – so opening a port on a firewall or exposing the entire system through a DMZ entry. (Although it is worrying that it’s 2018 and if you port-scan the Internet for port 445, you’ll find thousands of Windows computers plugged direct into a modem with no firewall!)

        I do agree that in a lot of cases, running a RISC OS server on the Internet is not a great idea these days, but I’d argue there are still use cases where it makes sense. An example is I have a load of media files in a Samba share, and occasionally I pull files from it remotely across the Internet. While I do understand that the files are passing over in clear text, they’re also not very important files – if I’m honest I couldn’t care less if someone runs Wireshark somewhere and realises I’m trying to watch endless episodes of Breaking Bad.

        Of course there are better options out there for even that specific use case, but at the end of the day I’m a RISC OS nutcase/hobbyist and prefer to run things on RISC OS even if it doesn’t make an awful lot of sense to do so.

  2. Jared

    An issue I have with this is its difficult to set a strong password with the software options available on RISC OS

    VNC restricts you to 8 characters when setting the password, trivial to brute force

    • Chris Williams

      Have you tried brute forcing an 8 character password? If it’s complicated enough it can take months or even years to crack.

      • levi

        Using something like diceware, I commonly use multiple word passwords with variable word separators to set my passwords. That results in passwords mostly longer than 8 characters, but much easier to remember than 8 random ascii characters.

        8 random ascii character gives you 7.2e15 possibilities to bruteforce out. Even four words with a standard word separator using diceware words (each of some 46k possibilities) beats that, and I commonly use a little more than that, and use five different passwords on my computers* and remember them all, plus different ones for each website that I sometimes have to decrypt one of my files to remember.

        * Two machines, therefore two login accounts, one ssh key password to connect from one to the other, one just to get the machine I’m using encryption on to boot, and one to get to my password reminder sheet. All easy to remember, fairly quick to type, and I type them right about 80% of the time first off I reckon.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.