How to force Emby server to dropout with ease. Happy Trolling!

[jayw654 5]

Emby server has a bug under HTTPS that can be exploited to make the server dropout until the server is restarted. Here’s how to do it

1. Have Emby server up and running with HTTPS enabled with a paid non-self signed certificate.
2. Then using an android phone install the Dolphin browser.
3. Next I verified by doing a connection from the internal network (home internet not Data from mobile carrier) so now simply attempt to connect to Emby server using the HTTPS address of the server. The connection will fail and the server will become confused and dropout. Seems to be some confusion with how Dolphin connects to Emby but even so this is a bad bug as it means any can easily knock out Emby server by sending confusing data.

I believe this will happen even via an external connection to the net but have not tried but I’m telling everyone because I want people to kick everyone’s server offline and have a ball. The point is to get the bug fixed by having everyone complain that the server keeps dropping on them. I tried reporting the issue nicely but was ignored so, Happy Server Trolling!

Edited November 16, 2016 by jayw654

[DAVe3283 7]

Just tried this without any crashes.

• Emby Server 3.0.8500.0 with a HTTPS certificate from StartCom
• Android 6.0 on a E5823 (Sony Xperia Z5 Compact)
• Firefox for Android 49.0.2 - no problems
• Chrome for Android 54.0.2840.85 - no problems
• Dolphin for Android 11.5.11 - no problems

Are you sure the problem isn't something specific to your server / phone? Can you provide exact software versions so we can try and replicate your bug?

Edited November 16, 2016 by DAVe3283

[jayw654 5]

Could be the phone maybe but I can replicate the issue without fail every time. The point is Emby server should be prone to such issues but the phone I'm using is from Sprint and is and LG G3 a bit older but not totally out of date. Using Dolphin 11.5.11 The server version is build 8500 and I was able to replicate the bug on Windows Server 2012 x64 and Windows 10 x64, both were clean installs. ROuter is an Asus rt-AC3200 with latest firmware. The LG G3 is a 32 bit phone so I'm not sure if that may change anything I assume not as you mentioned a couple of phones you tried with were 32 bit as well.

 

However whatever the circumstances it needs to be resolved as the server shouldn't be prone to such a bug, regardless of the circumstances.

Edited November 16, 2016 by jayw654

[gstuartj 40]

Do you have logs? It's helpful to report these issues, but I can't replicate it either, and it can't be fixed without logs to figure out what's going on.

[Luke 42085]

He sent logs to me. I think it is related to either his cert or the redirection he mentioned that is happening. I'm not sure yet though.

[DAVe3283 7]

I have mine published externally through Sophos UTM for authentication, and no problems there either.

 

UTM handles encryption (with the same cert) externally, but still communicates internally over HTTPS.

 

What kind of redirect do you have going jayw654?

 

Sent from my FlashScan V2

[jayw654 5]

no redirect this time its a direct connection, https://www.jpwservices.net the cert is comodo essential which is a very reputable cert provider. but when I was using a redirect it was Xampp but as stated I'm not using any redirect at the moment.

[jayw654 5]

And folks thanks for chiming in to get this resolved I really do appreciate it. If need more info or have any ideas I'm game to getting this issue resolved.

Edited November 16, 2016 by jayw654

[jayw654 5]

Luke I do understand that certs do vary a bit from provider to provider but that said the cert was generated perfectly as I have done this time and time again. So if the cert is varied effect that it is causing an issue its not the cert is how the server is handling the cert. Could be because old ciphers are active as the cert is SHA2, which could very be the issue. I used openSSL v1.0.2j to generate the CSR and Key. I kept the cert basic @ 2048 bit. Now OpenSSL 1.1.0 is out I could try to regen the key and see if that changes anything.

Edited November 16, 2016 by jayw654

[jayw654 5]

luke the logs are accessible again @ https://fileserver.jpwservices.net:446 you should already know the user and pass

[jayw654 5]

You claimed the issue was either my redirect or my certificate for the HTTPS dropout. So anyway I wasn't connecting devices with the redirect address only the direct address of https://www.jpwservices.net so that kills that as a cause. Also I regened my certificate and I was using the wrong intermediate but that is resolved now as well. However, that still isn't the cause of the dropouts as I can still reproduce the error.

 

Also RC4 encryption is enable and that needs to be turned off by default of the server app. Lastly I still would like selectable ciphers and others have requested that as well. I think a good rework and/or update of the HTTPS module you are using will solve a lot of issues as well.

 

Luke if read this I sent this text privately as well with login to view logs.

[Luke 42085]

The .NET SslStream does not support cipher selection, however here is some info that might be of assistance:

 

http://stackoverflow.com/questions/22825663/cipher-selection-for-sslstream-in-net-4-5

[DAVe3283 7]

It sounds like the .NET framework uses the system SCHANNEL cypher suites. So to remove RC4, you can just configure SCHANNEL as desired.

 

There is a lot of reading available online on how to best secure SCHANNEL (which has the side effect of securing Internet Explorer and tons of other programs). Here are some links that might help:

http://robwillis.info/2015/10/hardening-ssl-tls-connections-on-windows-server-2008-r2-2012-r2/

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

https://support.microsoft.com/en-us/kb/245030

 

Sent from my FlashScan V2