paint-brush
Is this an Ubuntu-based Botnet deploying Tor Relays and Bridges?by@nusenu
156 reads

Is this an Ubuntu-based Botnet deploying Tor Relays and Bridges?

by nusenuApril 12th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

On 2017–03–06 and the day following that, a significant number (57) of tor relays joined the network, they all share the nickname prefix “UbuntuCore”.<br>In March 2017 over 290 such relays joined the tor network. This sparked my interest.<br><strong>TLDR: As a tor user, you do not need to worry about them (yet)</strong>, because they only make up a tiny part of the tor network (current total consensus weight fraction: &lt;0.05%).

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Is this an Ubuntu-based Botnet deploying Tor Relays and Bridges?
nusenu HackerNoon profile picture



On 2017–03–06 and the day following that, a significant number (57) of tor relays joined the network, they all share the nickname prefix “UbuntuCore”.In March 2017 over 290 such relays joined the tor network. This sparked my interest.TLDR: As a tor user, you do not need to worry about them (yet), because they only make up a tiny part of the tor network (current total consensus weight fraction: <0.05%).

Update: As an example, this “UbuntuCore” relay group is about ten times smaller (by consensus weight fraction) than the (currently) biggest group of relays that you — as a tor user — should worry more about (disclosure: I generate these OrNetStats).

New “UbuntuCore” relays per day in March 2017:



By looking into OrNetRadar mailing list archives (non-onion URL) one can see that tor relays named “UbuntuCore”<number> appeared ever since theSnap package “tor-middle-relay” was announced by its developer in May 2016 (2016–05–02).Most (not all) of the May 2016 “UbuntuCore” relays were likely created by the developer testing the package (creating multiple relays on the same IP).

2016–12–10, the “starting” date?







The first time “UbuntuCore” named relays appeared with a suspiciously high geographical diversity was on 2016–12–10 (non-onion URL).Six “UbuntuCore”<number> named tor relays from five different countries (FR, NO, RU, RS, IT) joined the tor network that day.Since 2016–12–10 such relays continued to trickle in (5–9 relays per day, not every day) until it slowed down on 2017–02–06.My guess is that this was caused by a change in the Snap on that day ( — enable-openbsd-malloc).Once this change has been reverted (2017–03–06 17:13 UTC)the (defunct?) “UbuntuCore” relays that were created between 2017–02–06 and 2017–03–06 became functional on 2017–03–06 and caused the spike of “new” relays (my guess).(Note: Snaps apparently get updated automatically on a daily basis, which is good!)


The updated Snap package became available at 2017–03–06T17:45, 10 minutes later the developer updated his relay and all others followed(onionoo data from 2017–03–06 23:00 UTC):
















| first_seen | last_restarted | nickname || 2016–05–31 | 2017–03–06 17:55:20 | UbuntuCore160 || 2017–01–03 | 2017–03–06 18:12:02 | UbuntuCore160 || 2017–03–06 | 2017–03–06 18:13:39 | UbuntuCore161 || 2017–03–06 | 2017–03–06 18:15:12 | UbuntuCore160 || 2017–03–06 | 2017–03–06 18:18:51 | UbuntuCore160 || 2017–03–06 | 2017–03–06 18:22:23 | UbuntuCore160 || 2017–03–06 | 2017–03–06 18:28:37 | UbuntuCore161 || 2017–03–06 | 2017–03–06 18:33:14 | UbuntuCore160 || 2017–03–06 | 2017–03–06 19:18:29 | UbuntuCore160 || 2017–03–06 | 2017–03–06 19:18:30 | UbuntuCore160 || 2017–03–06 | 2017–03–06 19:25:26 | UbuntuCore161 || 2017–03–06 | 2017–03–06 19:30:41 | UbuntuCore160 || 2017–02–08 | 2017–03–06 19:33:50 | UbuntuCore160 || 2017–02–08 | 2017–03–06 19:33:51 | UbuntuCore160 |[…]

How many of theses “UbuntuCore” relays are actually concurrently running?

Running “UbuntuCore” relays per tor network consensus in March 2017:

Time of the Day Pattern: Not operating 24h a Day

I guess these relays are operated on devices that are not running 24 hours a day. So even though Snaps are also for embedded devices (Ubuntu Core target platforms) these deployments might be installed on non-embedded devices since I would expect embedded devices to run all day long — but this is just pure guessing. Most if not all of these relays are located at broadband consumer IP addresses (judging by their reverse DNS records).

What is their overall consensus weight fraction? Tiny!

None of these relays have guard or exit flags. Only two of them have the HSDir flag.

Are these actually Ubuntu-based relays?

I did run these IP addresses against the censys.io service, most IP addresses had no open ports, some possible reasons:

  • these IPs are mostly dynamically allocated (short lived)
  • censys.io scans are performed on a ~weekly basis
  • censys.io scans only a very limited number of ports per IP address


On a limited number of IP addresses censys.io found some open ports (SSH, HTTP, CWMP, Telnet, DNS, FTP, SMTP) and the HTTP/SSH bannersuggest that these are indeed Ubuntu-based systems.

“UbuntuCore” Bridges?

After coincidentally noticing that there are even tor bridges with that nickname pattern I thought that my assumption with the ubuntu snap package was no longer valid — since the snap is for relays only — at least this was my assumption until I found this:



if grep — line-regexp ‘.*[0123]’ “$SNAP_DATA/data/fingerprint” >/dev/null 2>/dev/null; thenset — “$@” — ServerTransportPlugin “obfs3,obfs4 exec $SNAP/bin/obfs4proxy” — BridgeRelay 1fi

In words: If your relay fingerprint happens to end with one of the numbers 0–3 the snap called “tor-middle-relay” does not run a relay but a tor bridge ;)

Do you know more?

So apparently we have a second gang of relays that look like they are created by a botnet (the first being the Windows “default” relays running tor 0.2.4.23). If you have some insides feel free to reach out:

Update: Or via email, PGP key fingerprint:

2792 2EF6 8D88 DDAC 58FA 78B6 5BFB 5EF5 4210 B874

Some additional remarks about the “tor-middle-relay” Snap package

  • it runs tor as root (you should not)
  • it has an auto-expire kill-switch that will become active (if not updated by the developer) 8 months after 2016–08–26 (soon)
  • “ORPort [::]:auto” does not work (tor requires you to manually specify the IPv6 address)
  • the description is a bit misleading and should be updated (relay vs. bridge)

Data

onionoo.torproject.org was the main data source.