Rtorrent: Hackers exploiting rTorrent to install Unix coin miner have netted $4k so far

[pwpx2]

https://arstechnica.com/information-technology/2018/03/hackers-exploiting-rtorrent-to-install-unix-coin-miner-have-netted-4k-so-far/

[chros73]

Well, there are couple of problems with this article :) , clearly the author didn't/doesn't use rtorrent at all.

A. Short answer:

• don't use network.scgi.open_port
• use network.scgi.open_local instead

# SCGI socket and make it group writeable when rtorrent starts (otherwise apps can't connect to it since it was started by a normal user) (scgi_local)
network.scgi.open_local = /tmp/.rtorrent.sock
schedule2 = chmod_scgi_socket, 0, 0, "execute2=chmod,g+w,/tmp/.rtorrent.sock"

It also has the following good side effect: rtorrent still can be reached even if it's running in a different (completely isolated) network namespace.

B. Longer answer, if network.scgi.open_port is used :

1. rtorrent is used on server (without desktop capabilities)
2. even someone with only a half brain would close the selected port in the host/network firewall (especially in the age of surveillance state)
3. and use ssh, ssh tunnel, etc. to communicate with it

4. (not to mention to drop rutorent web interface, that can have its own issues)

5. rtorrent is used on desktop

6. e.g. malicious JavaScript code could access to it in theory (I haven't tried it) from a modified page

C. Note: article also mentions utorrent. Guys already "played" with it (>= v2.2.1) and this is the fix:

• disable WebUI
• set net.discoverable setting to false

They also stated that there's also an issue with incoming port, but it can "only" crash utorrent and couldn't replicate it all the time.

[chros73]

@pwpx2 : you can comment that post with a link to this issue.

[tinfoilhatgit]

linked in original article but worth its own post ; https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

I guess my question regarding this would this be switched on or off on a standard rtorrent seedbox install, and how would a linux noob check to see if they are affected by the vulnerability.

[rakshasa]

I was asked to comment on this issue by email a couple of days ago, and I'll repeat my response here;

The issue is about poor documentation and not clearly enough warning about the possible issues with using tcp sockets for xmlrpc. Anyone who has access to calling commands in rtorrent has the same access privilege as the user of the rtorrent process.

It seemed obvious to me that this was well known at the time I implemented the feature. Guess some updating of the wiki is in order.

[kannibalox]

While I fully support making people aware of both domain sockets and the fact that anyone with access to XML-RPC can run arbitrary commands, the attack described in the F5 article was against an unsecured ruTorrent instance. Switching to domain sockets would not have helped in that situation.

[chros73]

That's why I mentioned this :)

(not to mention to drop rutorent web interface, that can have its own issues)

[tool-maker]

I suppose one might hope that some mechanism for securing XML-RPC when it is used with a domain socket could be implemented. I wonder if this is not on Tavis Ormandy's To Do list. It seems that Tavis wrote the patch that got applied for Transmission. Maybe he will do it for rtorrent XML-RPC?

Not complaining by the way. rtorrent is an amazing creation. Thank you rakshasa.

And I am not volunteering.

EDIT:

"chros73 commented ...
...
and use ssh, ssh tunnel, etc. to communicate with it ..."

So tunnel it? Then that now exposes the interface on your desktop where you browse. So it should be secure all by itself. This is picky I know. But when we consider security, we are supposed to be picky, right?

[ben-ba]

'network.scgi.open_port' is used.

So if i use rtorrent with rutorrent and the rutorrent site is secured with auth, would this secure?

[pyroscope]

So if i use rtorrent with rutorrent and the rutorrent site is secured with auth, would this secure?

If the rest of your setup does things right, yes, Else, no. And TCP is easier to get wrong.

[ProdigySim]

even someone with only a half brain would close the selected port in the host/network firewall (especially in the age of surveillance state)

I'm not incredibly familiar with XML-RPC in rtorrent, but quite often these web-based protocols are exploited by Cross-Site-Request-Forgery or simple cross-origin XmlHttpRequests. Is it possible that users are getting drive-by exploited through their web browsers in one of these methods?

e.g., even if my XMLRPC interface is on a NAT/firewalled LAN PC, if I share a LAN with it and browse to a malicious website, an attacker can generate web requests to my private IP space.

[pyroscope]

Use UNIX domain sockets for the rtorrent SCGI API, and protect your /RPC2 mounts (if you have one) with basic auth or similar (not just IP-based checks). Proper setups do this anyway and are secure. Everything else is not or can be more easily broken.

Naming /RPC2 something else can be done too, for mitigation if your auth breaks for whatever reason – obscurity sometimes actually helps. Or have no mount at all, and use direct SCGI.

That is all there is to say about this.

[pyroscope]

So tunnel it? Then that now exposes the interface on your desktop where you browse.

A browser cannot "tune in" on your socat pipe connected to ONE process (which is the proper way to do it, and secure). Beside it being raw SCGI which your browser does not even speak. Stop the FUD.

[z0z0z]

Is this secure?

rtorrent.rc

network.scgi.open_local = /var/rsock
schedule = scgi_permission, 0, 0, "execute.nothrow=chmod,\"g+w,o=\",/var/rsock"

lighttpd config

scgi.server = ( "/RPC3000" =>
    ( "127.0.0.1" =>
        ( "socket" => "/var/rsock" )
    )
)

$HTTP["remoteip"] !~ "127.0.0.1|192.168.1.101" {
    $HTTP["url"] =~ "^/rutorrent|^/RPC3000" {
        url.access-deny = ( "" )
    }
}

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd.user"
auth.require = (
    "/rutorrent" =>
    (
        "method" => "basic",
        "realm" => "rutorrent",
        "require" => "user=rtorrent" 
    ),
    "/RPC3000" =>
    (
        "method" => "basic",
        "realm" => "rutorrent",
        "require" => "user=rtorrent" 
    )
)

lighttpd.user file content created with perl script from https://redmine.lighttpd.net/projects/1/wiki/HowToBasicAuth

[tool-maker]

pyroscope commented

"A browser cannot "tune in" on your socat pipe connected to ONE process (which is the proper way to do it, and secure). Beside it being raw SCGI which your browser does not even speak. Stop the FUD."

The post by chros73 talked about using ssh to tunnel. No mention there of socat. With ssh the port will be available as a port on localhost, and so vulnerable to being accessed by Javascript that leverages DNS rebinding. This is at the heart of the problems with Transmission and Utorrent identified by Tavis Ormandy. So a port forwarded via an ssh tunnel should be secure all by itself. This applies to any web or RPC interface, not just rtorrent or rutorrent.

I believe that XML-RPC is based on HTTP. Are you sure that it cannot be accessed by "XMLHTTPRequest()" from Javascript as for uTorrent and Transmisiion as described by Tavis Ormandy in his blog posts?

https://bugs.chromium.org/p/project-zero/issues/detail?id=1524
https://bugs.chromium.org/p/project-zero/issues/detail?id=1447

And the examples of accessing the rtorrent RPC interface in the article at F5 look like HTTP requests:

https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

If you can assure us of that, please try to do it without attacking me.

[chros73]

If you can assure us of that, please try to do it without attacking me.

:) No worries. I see where the confusion comes from.
In theory it can't connect to a local/remote TCP socket (unless other forwarders, broken software, etc is in the chain).

I believe that XML-RPC is based on HTTP. Are you sure that it cannot be accessed by "XMLHTTPRequest()" from Javascript as for uTorrent

It needs a HTTP server somewhere that forwards communication between the client (JavaScript) and the server (rtorrent built with xml-rpc-c). rtorrent doesn't have any, but utorrent does (it's disabled by default)!
That's why you need Apache, Nginx, lighttpd, etc. to use it with ruTorrent, probably for only AJAX operations (JavaScript !), because you can also configure ruTorrent to use the unix domain socket (although I never used ruTorrent myself).

The example in that article uses: http://127.0.0.1/RPC2, it's a local request. It also means the following:

• you have an HTTP server running locally (!)
• and you also have ruTorrent "running" locally (although it's not necessary)
• and probably have rtorrent running locally as well (although it's not necessary)
• and the user browses the internet on the very same machine where the webserver runs!!!

So, how many people surf the net on the same server where the webserver runs???

Let's assume that rtorrent, ruTorrent and webserver run on a different computer than the user surf the net.
JavaScript is a client side language: means it only runs on the client computer, hence it can't connect to an unadvertised resource of a server.
So, if you not just password protect your http://127.0.0.1/RPC2 URL on the server but also restrict access to it only from localhost, then you'll be more safer, again. E.g. using Nginx you can add this into a location directive:

allow 127.0.0.1;
deny all;

And as @pyroscope mentioned, rename the path to something else, just in case, it can't hurt. :)

So, in summary:

• always use unix domain socket, not TCP socket (unless it's absolutely necessary) to be more safe

A. you can use rtorrent-ps with pyrocore command-line utilities instead of rtorrent/ruTorrent:

• you don't need a webserver!
• these 2 run on the same machine: you can use ssh to connect to it

B. if you still want to use rtorrent/ruTorrent:

• run all of them (rtorrent, webserver, ruTorrent) on the same machine
  
  
  
  • protect the SCGI (RPC) web URL with password and restrict access to it only from localhost
  
  
• surf the net on an other machine

Feel free to ask more, I'll answer it if I can. :)

[z0z0z]

@chros73

So, how many people surf the net on the same server where the webserver runs???

I do. I know rtorrent/rutorrent is more common on seedboxes though.

protect the SCGI (RPC) web URL with password and restrict access to it only from localhost

There is so much rtorrent/rutorrent documentation out there that tells people to configure an /RPC2 mount on their webserver, and never says anything about password protecting it or using IP based auth. Even the own rtorrent github wiki on this didn't.

There's tons of people running webservers with port 80 open, and a mount called /RPC2 completely unprotected, because of this.

[chros73]

I do.

:) Me too, I mean almost, I also use rtorrent-ps on a local network (without the need of having a webserver), but browsing on a different computer.

There is so much rtorrent/rutorrent documentation out there

Well, we can't do much about this. It's like buying something or reading the news: you have to take a look at least 3 different one and explore more possibilities/features.
What about the official ruTorrent documentation?

Even the own rtorrent github wiki on this didn't.

Now that's an issue. The WIKI is publicly editable, so feel free to modify it (but only after you have tried out those).

I just went through it quickly: why does it even have webserver config examples when there's no example how to use it??? E.g. the used xmlrpc command doesn't need it at all.

[pyroscope]

E.g. the used xmlrpc command doesn't need it at all.

Yes it does. It's the one provided by xmlrpc-c and that one does not speak raw SCGI. Unless it learned since last time I tried (years ago).

[cy7yz2rj]

The more I read about this the less I seem to understand.

Is there any secure setup for running rtorrent + apache + rutorrent + surfing the web all on the same machine?

[pyroscope]

Is there any secure setup for running rtorrent + apache + rutorrent + surfing the web all on the same machine?

Nginx: https://www.reddit.com/r/seedboxes/comments/81cg0d/securing_rtorrent_against_xmlrpc_abuse/dv34xq1/

[chros73]

It's the one provided by xmlrpc-c and that one does not speak raw SCGI. Unless it learned since last time I tried (years ago).

:D :D :D That's a good one! And you're right:
from xlmrpc manual: "As XML-RPC uses HTTP, this must be an HTTP url. However, if you don't specify a type ("http:") in the URL, xmlrpc assumes an "http://" prefix and a "/RPC2" suffix. RPC2 is the conventional file name for an XML-RPC responder."

Then don't use this just stick to pyrocore utilities that doesn't require a webserver.