Issue at hand
Not long ago I was spending some quality time with my client’s Application.xml and for some reason the presence of four default modules (base, properties, logging, flvplayback) bugged me.
So I did a quick recon and almost fell out of my chair when I read the
properties module in Wowza API documentation.
properties module exposes the following remotely callable functions:
In other words – this innocent-looking little module, that’s included by default in all examples supplied with default WMS installation, allows you to read and write IClient, IMediaStream, IApplicationInstance, and IApplication properties!
Why should that worry me, you might ask?
Well, do you use
module? Either for securing your player-edge or even
Or, do you perhaps have some
<Properties> in your Application.xml
you wouldn’t want anyone to read? (SQL connection parameters, backend
Then you should be worried.
As anyone can read out (or even re-write) your
secureTokenSharedSecret (and other
properties) as soon as they get RTMP connection.
I alredy reported this problem to Wowza. And while I’m sure they will solve it
in the future releases, I would advise anyone running Wowza Media Server
to disable both
logging modules in their applications unless
they’re actively using them and understand the risk(s).
Update 2017-05-12: The wms-dev.wejn.com instance is shut down, the demo won’t work. But you’re welcome to grab the player and try it against your own instance (if you’re so inclined).
It’d be boring post without a demo. I wrote a fairly straightforward patch to JWPlayer 6.3 that will bypass SecureToken protection on any server it’s allowed to connect to.
If you connect with regular JWPlayer (or any other Flash player) to the following RTMP URL:
you will be required to reply with valid SecureToken response before the video starts playing.
Well, this JWPlayer (modified with the abovementioned patch) works around that problem:
by requesting the
secureTokenSharedSecret AppInstance property from the
server and then decrypting the SecureToken challenge with it.
Note: If the demo doesn’t work, I’ve probably hit the 10 connections limit on my development license. In that case you’ll have to try it against your own wowza instance.
logging modules in your Application.xml
unless you fully understand the risks and absolutely need the
remotely-callable functions these modules expose to Flash clients.
Sure, you can try combating this problem by checking referrer and perhaps even by employing SWF hash. But both checks can be easily worked around (check the source of rtmpdump or mplayer if you need convincing).
As for why should the
logging module be kept out – I’ll leave this to your
darker side to figure out.
- 2013-04-06 Wowza Media Services contacted about this issue
- 2013-04-08 Wowza rep states that this is a non-issue and accuses me of scaremongering
- 2013-04-19 After subsequent rounds of communication, Wowza rep threatens to “reevaluate” my “independent” consultant status if this info disclosed
- 2013-04-27 Contacting Wowza rep with non-public preview of this post including the JWPlayer demo (last shot at responsible disclosure)
- 2013-04-28 Wowza rep responds with more indirect threats, info that this will be resolved sometime in the future and a plea “won’t you please think of the users”
- 2013-04-30 Public release due to vendor’s non-cooperation