Erlang Elixir Node Security Flaws

Erlang and Elixir’s distributed node system has another inherent weakness. It’s cookie based.

It’s advised that you don’t run Erlang on internet facing websites.. But with the rise of Elixir and Phoenix this becomes quite complicated.

One of the first problems is that by default the Distributed Node system works in plaintext.
Another problem is that node authentication is cookie based which is deterministically generated.
All nodes share the same cookie. So if a node is compromised, all your systems can compromised. Now, meaning that the attacker knows these things and is an Erlang fan. But we don’t want to take any chances, do we?

Compromised how?

Well, you can run code on the operating system via the :os.cmd() function. You can open a remote shell from within Erlang/Elixir itself. Another way is that you can actually compile code across the distribution via the 1 node.

One security researcher pointed out that you can actually guess a cookie because of the way atoms work in Erlang.

You can view a full talk about the issue here: https://www.youtube.com/watch?v=42k70Y-yTYY
So basically atoms are limited in Erlang (and elixir) he claims to have tested this and that he can guess the cookie atom based on a connection he can make using a node name
This is interesting in 2 ways:
You could guess the cookie by depleting the atom resources
You can CRASH a VM if it tries to recreate all the atoms

Both these things are potentially a problem

Another problem is the usage of the elixir iex --remsh or remote shell option.
Because the way of how the distributed node system works as explained earlier you can have problems on your OWN pc when debugging.
If you connect with your development computer to a compromised node via --remsh you become part of the node, so in theory and practice
the node you’ve connected to CAN run code on YOUR PC.
This means that your private files and even SSH keys can be read.

Ouch, this hurts!

This solution will solve the problems explained earlier except for the `+term_to_binary +`issues which are up to the developers to secure.

My recommendation is to setup a firewall that blocks everything. Setup SELINUX if required.

Then, when starting up any Erlang or Elixir based apps
Define the full name --name yourname@127.0.0.1
BE SURE to put the machine name of the node as 127.0.0.1 (0r 127.0.2.4 or whatever in the 127.0.0.1/8 range) FOR ALL your NODES.
This will make sure that when someone tries to connect to it.. they will be able only if they’re local hosted. I know you might find this  slightly backward but read on.

Whenever a node needs to connect to another node setup a SSH reverse port connection to an low privileged user.
ssh -L4369:localhost:4369 -L39974:localhost:39974 edge@node2.host.example

This sets up a local port on your machine on localhost which then connects to the server and tunnels everything directly. The 4369 port is for the EPDM service on the remote server. You will probably have to setup multiple and different local ports for it since each node has it’s own epdm service on 4369. SSH easily supports this.

Then connect via the local port. This will have 2 benefits.
First, you’ll have encrypted traffic. Second your ports will ONLY be available on the nodes themselves. Two birds one stone. The only downside is that you’ll have to write some scripts to automate the SSH port forwarding. Also take care to implement authentication via public key systems and don’t pass passwords around. This will involve a little bit of overhead but from a security standpoint it’s worth it.

Then whenever you connect to the node, you do it via the local FQDN. Even for debugginv via --remsh you first open a ssh -L connection to localhost AND connect to the localhost port.
The setup of this process can be automated.

Oh and one more thing. If you ARE using Nodes with cookies
Read more on the erlang:set_cookie/2 and/or Node.set_cookie . You can set different cookies for each node.
This will minimize the problem if one node is compromised since the attacker won’t be able to connect to the other ones

At least untill he figures a way to get the cookies of the other nodes.

Don’t use --sname --remsh --name on public facing computers UNLESS you’ve setup your SSH, firewall and other security systems.
Have different cookies
Use ssh for security