Jump to content

Web/uPnp - hacked


Recommended Posts



I'm using dvb recording server on my home media pc. Web server is available from internet ( web server and live stream port is routed to my media pc ). Guest account is disable, and main account has strong password.


Today I've notice that FFmpeg process is running so quick check on web interface / status and see that someone watching something. Unfortunately web interface shows only local ip ( in my case 192.168.1.x - recording server :/ ) and type: liveTV.


Quick check on established connection and see that there is one on dvb web server port Y ( from ).


So WTF ? Connection was from Ireland ( Vodafone ) - I'm living in Poland


I've stopped the server, changed password for more strong that previous one and fired up server. After few second I had the same connection - someone started watching the same channel.


I didn't find any logs, except svcdebug.log ( see below entry ) which are the same when I log into my server using username and password.


Could anyone tell me what is going on ? How is possible to use transcoded stream without using the password ?


Maybe it related with direct stream because using my-extrnal-ip:port/upnp/channelstream/2.ts does not required password to work.



15.11.15 19:00:54.251 FFmpeg av_interleaved_write_frame(): Broken pipe
15.11.15 19:00:54.253 TRecordingEngine ReleaseReference TStreamClient: 1
15.11.15 19:00:54.792 TDVBHTTPClient client doflashstream Preset=3&aspect=16%3A9&ffPreset=medium&maxwidth=&maxheight=&chid=265
15.11.15 19:00:54.792 Converter Start cmd -threads 4 -i "http://192.168.1.xx:zzz/upnp/channelstream/oneaudio/265.ts" -threads 4 -f flv -vcodec libx264 -bufsize 1024k -b:v 1200k -bt 1300k -r 25.0 -map 0:0 -map 0:1 -vf "yadif, scale=min(800\, trunc(iw/2)*2):trunc((ow/dar)/2)*2" -preset medium -tune film -vprofile baseline -level 30 -acodec libmp3lame -ab 192k -ar 44100 -ac 2 -async 1 -y "\\.\pipe\Output{800982BB-84C1-4F3A-B41A-8CCFB071AE09}"
15.11.15 19:00:54.816 FFmpeg FFmpeg version N-75275-gd13a2df Copyright © 2000-2015 the FFmpeg developers
built with gcc 4.9.3 (GCC)
Edited by marianob85
Link to comment

The RS is not designed to be used over the internet.
You should only forward the Web interface port (if at all, I would strongly recommend using a VPN between your router and the remote device instead).

All other ports are without any protection. Everyone who knows your IP address can access them. And there are search engines which allow to search for a special web server version. So it is easy to detect RS installations which are accessible from the internet.

Particularly if your public IP does not change on a daily basis, chances are good that you are listed there. Nowadays scanning all IPv4 addresses is not a real problem anymore (with a real fast connection possible in less than 8 hours).

Link to comment

The username and password are only for the webinterface. The live streams are not protected. So everybody who knows your public ip can access the streams no matter which password was set.

Use vpn or a https proxy

Link to comment

Tjod, Nanohcv,

I've been following the subject of this insecurity for a long time and I was wondering why is the situation like this - why not request username and password and/or something else to authenticate the opposing parity and try to secure a bit this interface?

I know that the perfect solution will be to use some kind of end-to-end secure connection but it'll probably take too much time to develop and support inside DVBViewer/RecService so it might not be worthed while a simple solution might solve 90+% of these abuse cases and be sufficient for the majority of the users.

Here are a couple of ideas which can be used for this "simple solution" that I'm talking about:
1. Add a username and password parameters to the URL. These will be sent in plain text but so are the ones used in the native FTP protocol and it's still better than nothing
2. Add a sessionId or "token" like parameter to the URL which can be acquired from the protected web interface and then be used when accessing the direct/transcoded stream URLs. It'll be perfect if the .m3u playlists and/or direct URLs which we get from the web interface directly contain a valid sessionId/token. These can have pretty long expiration intervals ... like 24 hours or even longer ... or even be fixed and changeable (generated/deleted) from somewhere in the Web interface ... or even without UI - directly in the configuration file of the RS.

In both situation to not affect the integration with other softwares within the local network there could be a rule that recognizes the source of the request (based on simple IP masks) and allow anonymous connection only from the same subnet while the external ones (and probably the IP of the router/gateway) should be rejected if they don't contain the selected security implementation.

And in general if you are worried about backward compatibility with older application you can always make this functionality optional in the RS configuration


What do you guys think? Am I talking nonesense or it might be good enough and easy to implement?

Link to comment

I totally agree with you but it's not in my hand. I think your offers are even better than the actual sittuation and should be easy to implement but in my oppinion they should make it right by implementing ssl with sessionids or something else for the streams.

Edited by Nanohcv
Link to comment

The username and password are only for the webinterface. The live streams are not protected. So everybody who knows your public ip can access the streams no matter which password was set.


Use vpn or a https proxy


It's clear now, but when I was installed RS there was no info that watching is possible without password and honestly I didn't even think about it.

Link to comment


I also think that SSL or other encryption is necessary but the problem is that it might require a lot of work and more importantly will require a lot of changes in the client applications.

On the other hand - it's not like we have to hide some data and it's a big problem that it can be acccessed - after all this is only TV. The problem is that such "leeches" are highjacking our tuners and interfere with our own watching and I think it'll be enough simply to prevent them from beeing able to start the streaming than to protect the content that's being streamed.



I totally agree with you that there should be a very big warning informing the users that opening the service to the internet is not secure.

Link to comment

An "easy" way of protection is publishing the web interface via reverse proxy.

You can do it with a Raspberry Pi/Linux if you use nginx or apache e.g. https://www.nginx.com/resources/admin-guide/reverse-proxy/

Or if you run Windows, you can use IIS and ARR: http://www.myconnectionserver.com/support/tutorials/v90/iisProxy/index.html


All you need is a DNS name for your IP (or dynamic DNS),

The point is to use a DNS name (http host header), here for IIS: https://technet.microsoft.com/en-us/library/cc753195%28v=ws.10%29.aspx

This "host header value" like "mydvbserver4711.no-ip.org" will be bound to your reverse proxy.


So now you need to know the exact DNS name to get access to your DVBViewer streams. Port scanners from "the internet" cannot access.


With a reverse proxy you can even publish it via https, the reverse proxy will terminate the SSL connection and connect via http to recording service.

Edited by esackbauer
Link to comment

Or you can block access to the RS from public networks in the windows firewall. Nonthelss all these counter measures are very awkward and fiddly. We need a better solution. RS developers ought to take this more seriously and treat this one as high priority. I`ve also noticed these "leechers" a lot more frequently. Checking the svcdebug log its mostly FFMPEG logs, which is not used by any of the family.

Link to comment

First of all I would like to remind you of the Recordingc Service terms of use (if you have ever read them):

By using DVBViewer Recording Service you agree to the following terms of use:

DVBViewer Recording Service is provided as a free additional software exclusively for purchasers of DVBViewer Pro. (...) Please note: DVBViewer Recording Service is not part of the official DVBViewer release. Improvements and updates are provided as far as possible. Any claims to support, updates, changes or bug fixes are explicitly excluded for DVBViewer Recording Service, though. You use it at your own risk.

Secondly please remember that the Recording Service is still in a beta state (if it ever leaves it, you will have to pay for it). This altogether indicates clearly that Recording Service is no easy to handle plug 'n play consumer product. It is up to you to use it correctly within its limits, to take care of potential risks and to consider imperfection.

If you can't agree to that, please uninstall the Recording Service and look for some other software fitting your needs.

RS developers ought to take this more seriously

Which developers? Basically there is only one. And it's not his main occupation.

Please remember that the RS inventor and main developer died in 2013, casting into doubt if the Recording Service can be kept alive. Finally I decided to try despite hundreds of thousands lines of undocumented code (plus additional hundreds of thousands lines of undocumented DVBViewer Pro code), and despite the fact that I had almost no knowledge about network technology.

It's a bit better now since I've spent the last two years with learning by doing. Nevertheless I'm no professional in this regard and there are still a lot of things that I don't know.

So I can give the following answer to all that "why don't they" and "they ought to": The main reason for things not getting implemented is lack of time, lack of resources, lack of know how, lack of experience. For example:


In both situation to not affect the integration with other softwares within the local network there could be a rule that recognizes the source of the request (based on simple IP masks) and allow anonymous connection only from the same subnet while the external ones (and probably the IP of the router/gateway) should be rejected if they don't contain the selected security implementation.


I've never dealt with something like this. Which IP masks? How to use them? Of course I can find out, but it requires lengthy internet researches, reading a lot, checking if and how the underlying network libraries are supporting it, learning by trial and error how it must be implemented etc.


Fortunately there are two helpful supporters: Markus, who takes care of the web interface (all that HTML and Javascript stuff), and Tjod who contributes a lot of knowledge about networking and points me in the right direction if necessary. Without them I would be lost. However, both are doing it in there spare time, and there are periods when they have only little time for it. So often enough the question is not "what must be done" but "what can be done at the moment under the given circumstances".


That's how it looks like.. of course security is an important matter (among several other important topics). Currently we are trying to get away from Flash as a permanent security risk by supporting HTML5 / WebM Video in the web interface. And the discussion here has led to an internal check if there are short-term measures that can be taken e.g. disabling internet connections by default in some way. Setting TTL = 1 is under discussion.


However, please don't expect things to happen in the next release or this year... if we would try to work everything out that is important in the RS by some means or other there would be no release for years.


if you want to support the RS development, don't get stuck at the "why don't they" and "they ought to" level. Provide know how, if possible. If you think something should be done with IP masks get more specific. Explain how it works and how they must be used. Provide links, examples, information about potential side effects that must be considered etc. so I don't have to start from zero when dealing with it.


That's all for the moment. Let's get back to work.

Link to comment

Yeah yeah...calm down why dont you ;) Its not like if I did demand a solution on the second, I just meant it should be looked at eventually, but with higher priority (meaning within a year or so instead of 5 for lower priority todo`s). I like everybody else are aware of your situation, so no need for being senisitive about my choosing of words.


Luckily there are many qualified DVBViewer users/programmers that knows their way around networking stuff, that would love to get an opportunity to help you out with this.

Link to comment


I'm very glad that we were able to bring your attention to this topic and I'm really sad that Lars passed away. I must say that RS is a very nice piece of software that made the DVBViewer ecosystem a whole more attractive and I hope you'll continue developing it.

I didn't want my post to sound like whining or accusation - all I wanted was to share some thoughts and if you like one/both of them we can start a discussion with more details. If I remember correctly you are using Delphi for the development of the application and as a fellow Delphi developer I'll try to do some research and try to provide more details to back my ideas. In the mean time I think a big warning should be put inside the Web/UPnP section of the configuration window of the RS just to warn the users that there are security risks with publishing the service ports over the Internet.


About the TTL solution - if it's set to 1 by default but can be increased by the user (so the ones who are willing to risk it ... or have some secure solution which does need TTL > 1) I'm all for it.

Link to comment
  • Create New...