Administrace komentářů

Exactly, adding a section like

<Location /RPC2>
    Require local
</Location>

somewhere after where the SCGIMount has been defined should lock access to only local connections.

(The above assumes Apache 2.4. The syntax for Apache 2.2 is slightly different.)

The instructions one finds when searching for rTorrent and XMLRPC are from the rTorrent wiki at GitHub: RPC Setup XMLRPC, and currently do not mention lockdown in any more detail than a tiny remark in the "Other notes" section, saying

Also make sure the /RPC2 location is properly protected.

There is likely a very large amount of vulnerable machines due to these instructions, so it just seems natural that malware writers would look for the /RPC2 endpoint and trying rTorrent commands when scanning the net.

---

If someone wants to check for the vulnerability themselves, having rTorrent listening to RPC requests on localhost/RPC2, one can (on Debian-based systems, at least) install the libxmlrpc-core-c3-dev package which comes with a CLI for sending XMLRPC requests named xmlrpc. You can run this against your local machine:

$ xmlrpc localhost/RPC2 system.listMethods
Result:

Array of 963 items:
  Index  0 String: 'system.listMethods'
  ...

One can even execute arbitrary commands using the execute call:

$ xmlrpc localhost/RPC2 execute ls
Result:

64-bit integer: 0

Not too exciting: however, if one has enabled the execution log one would in that now see the output of the ls command run, so the command actually executed on the local machine. From there it is a small step to do things like:

$ xmlrpc localhost/RPC2 execute -- sh -c "echo 'Now you have a shell and can do what you want in here, like replacing the crontab for the user, ping home, insert ransomware, etc.'"
Result:

64-bit integer: 0

A variation of this was probably what the RPC request noted in the initial post contained. Scary stuff, but if it is locked down to localhost only, things might be OK (beware of shared hosts, though).

If one however get this result even when running against the computer remotely, then it is just a matter of time until someone scans the machine and finds this issue.

With the correct access configuration, a remote call should rather yield something like:

$ xmlrpc $YOUR_HOST/RPC2 system.listMethods
Failed.  Call failed.  HTTP response code is 403, not 200.  (XML-RPC fault code -504)

It is not a bad idea to run rTorrent as a separate less privileged user to mitigate the risk of e.g. losing private SSH keys, being exposed to ransomware, etc.