FULL DISCLOSURE: Data Collection in the Process of BotNet Takedown

[softworkz 3341]

2 hours ago, darkassassin07 said:

ScripterX was just an available tool the attacker used. It in it of itself wasn't compromised/modified, it just perhaps unwisely had too much power to manipulate the underlying system (download+execute files/payloads to the server).

 

Embyhelper.dll was the actual 'compromised' (built as a virus, by/for the attacker) plugin being called out as a virus in that thread.

Very good answer. I have nothing to add  

[softworkz 3341]

3 minutes ago, justinrh said:

Encrypted or hashed?

Hashed and salted.

3 minutes ago, justinrh said:

Is it correct to say that the passwords are sent in clear text from the client to the server?  (assuming on a non-TLS connection)

Like with any other forms based web authentication. That's why TLS is so important.

[justinrh 175]

1 minute ago, softworkz said:

Like with any other forms based web authentication. That's why TLS is so important.

Thanks.  Now with this vulnerability, even TLS encryption would not have changed anything, I suppose.  The attacker still would have been able to intercept the pwd when it reached the Emby server?

[pwhodges 1534]

True - that's why it has now been dealt with.

Paul

[chef 3749]

Interesting stuff.

I'm definitely thinking about how it could be done. 

How did they get the helper plugin on the machine? That's the interesting part...

I'm trying to think about that, and I'm not seeing the vulnerability right away.

I only know how to break wifi passwords if I wanted and boot devices off their wifi connection to connect to my laptop instead, I don't yet understand header hacks, or cookie stealing.... 

I realize this is all a pain in the butt, and I am in no way glorifying this kind of behavior...  but it is also very interesting that the person knew enough to infiltrate and set up a botnet remotely. 

 

 

 

 

 

[pwhodges 1534]

17 minutes ago, chef said:

I'm trying to think about that, and I'm not seeing the vulnerability right away.

The vulnerability together with an admin account they could enter without password (because Emby thought they were local) got them logged in as an admin.  They could then install from the catalogue an innocent plugin called Scripter-X which has the capability of downloading arbitrary files - everything followed from that.  So it's clear that they know Emby well to be aware of the plugin as well as the attack opening..

Paul

[MBSki 1025]

10 minutes ago, pwhodges said:

The vulnerability together with an admin account they could enter without password (because Emby thought they were local) got them logged in as an admin.

Does that mean setups that requires a pin or password for the admin account could NOT be affected?

[andrewds 98]

2 minutes ago, MBSki said:

Does that mean setups that requires a pin or password for the admin account could NOT be affected?

 @softworkzhas said they have no instances so far of that happening. If you have all accounts hidden while connecting remotely, but visible locally, then those local accounts would have been visible to the remote attacker. But, if they're password protected it's likely the attacker would move on to softer targets in this context rather than spend time trying to brute force the password.

[MBSki 1025]

7 minutes ago, andrewds said:

 @softworkzhas said they have no instances so far of that happening. If you have all accounts hidden while connecting remotely, but visible locally, then those local accounts would have been visible to the remote attacker. But, if they're password protected it's likely the attacker would move on to softer targets in this context rather than spend time trying to brute force the password.

Got it, thanks. 

[chef 3749]

56 minutes ago, pwhodges said:

The vulnerability together with an admin account they could enter without password (because Emby thought they were local) got them logged in as an admin.  They could then install from the catalogue an innocent plugin called Scripter-X which has the capability of downloading arbitrary files - everything followed from that.  So it's clear that they know Emby well to be aware of the plugin as well as the attack opening..

Paul

I've seen programs like ProxyChains 'spoof' ips that looked like 192.168.x xx, even though the address is a public address. 

So, if the service was only looking for subnet ips to auto login then maybe that was it. Along with the expected headers for login. 

In any case, it's a shame the person spent the time to write it. 

The good hackers usually find the vulnerability, and give companies a time frame to port a fix before releasing the information publicly.

The good ones don't ever actually utilize what they find. 

It's too bad really, obviously the person has a skill and understanding that could be used for good, not to disrupt. 

 

 

[andrewds 98]

1 minute ago, chef said:

 The good hackers usually find the vulnerability, and give companies a time frame to port a fix before releasing the information publicly.

I understand the sentiment but the vulnerability was disclosed by @psein open forum over 3 years ago. Not meant to be a defense of the attack, but this isn't a case of the company not simply being given time. They have also repeatedly acknowledged their fault in it.

 

 

[softworkz 3341]

8 minutes ago, andrewds said:

15 minutes ago, chef said:

 The good hackers usually find the vulnerability, and give companies a time frame to port a fix before releasing the information publicly.

I understand the sentiment but the vulnerability was disclosed by @psein open forum over 3 years ago. Not meant to be a defense of the attack, but this isn't a case of the company not simply being given time. They have also repeatedly acknowledged their fault in it.

I think his statement was about hackers in general not about the events preceding this incident.

Also I can recognize a wide-spread misconception here: We cannot take it for granted that this incident would have been prevented by fixing that vulnerability. It might have been just the easiest way. 

This is in no way meant to be an excuse, though. I'm rather heading into the opposite direction: It would be wrong to assume that this is the one and only big hole and after closing it, it would be all good again. There's more work to do for us in terms of tightening security.

[TMCsw 123]

2 hours ago, chef said:

How did they get the helper plugin on the machine? That's the interesting part...

In this case they used scripterx but they probably could have done the same with webhooks or a DVR postscript

Edited May 29, 2023 by TMCsw

[rbjtech 4304]

On 28/05/2023 at 09:54, andrewds said:

Excellent, thanks so much for sharing this. Hopefully not from your setup?

No,no - this vulnerability would have had to pass many more perimeter layers before even hitting my public IP.. (I hope lol).   These were from a private discussion thread but as they are public, I saw no problems sharing them on here.

Edited May 29, 2023 by rbjtech

[rbjtech 4304]

21 hours ago, darkassassin07 said:

It's always worked perfectly for me.

My server is behind an nginx reverse proxy with some pretty similar config to the pinned one in this forum category.

I'll check my setup, it may be something else - my internal proxy is in a different security zone but even without using the proxy (ie my 'mobile' wifi vlan for example - which is just routed/allowed via the f/w) just shows the emby vlan g/w address.   The internal proxy is used for all sorts of stuff, mainly to remove the need for 'ports' - emby being one of them - but for me, that still shows the g/w address, but it's not typically used as it serves no purpose as most local traffic from the clients is on that same emby(iot) vlan anyway.    Anyway, not a big issue and I'll get around to resolving it one day .. haha. 

Edited May 29, 2023 by rbjtech

[softworkz 3341]

There's most likely a third version (or even more).

I just didn't want to add another step to the instructions for affected users, asking them to provide samples of the malware dll.

But for occasional readers: If you have an EmbyHelper.dll with a different hash than these two:

https://www.virustotal.com/gui/file/0ae4f9ca1906d7fa6e7b4d43c32dee52d281d615de451a67e2407c0e6a32dc2b?nocache=1
https://www.virustotal.com/gui/file/037b9b3e43ab4876b4c3b7b08303833cc10c93ec11be38e4ef394a3f840eeb2c?nocache=1
(just post the dll to virustotal.com, to see) 

Please send it to me via PM!

Thanks

[rbjtech 4304]

21 hours ago, darkassassin07 said:

Yes. I'm just confirming how things are currently functioning vs how they were prior to this weeks snafu. The comment I replied to seemed to be saying it's always reported a lan ip as the ip of the gateway/proxy, but that's not been my experience previously.

I would like to see this header still being used to report what the client ip is, just not used as part of the authentication requirements (to decide if the client is lan/wan). Perhaps as a seprate line? Or a tooltip? I'd prefer to still see what ip a client has signed in from/reported via that header at a glance of the dashboard regardless of whether it's lan/wan. But it's a pretty minor thing as long as WAN ips still show up. If I really need to I can correlate proxy logs with emby logs 

Agree - unfortunately the security model of lan (trusted), wan (untrusted) is very wrong - and it will take some time before this gets addressed.  Every client needs to be untrusted until it's authenticated - even on the same lan - it's that simple.

[adrianwi 238]

On 28/05/2023 at 00:53, softworkz said:

The situation is not as bad as it might seem to you now.

We want to phase out accounts without password and the "don't require password in local network" altogether.

But of course that won't happen without an appropriate replacement. We want to eliminate accounts with empty passwords, but we don't want to take away the ability for users to log on without entering a password. It will just be done in a different way.

The only little inconvenience that might affect you could be that passwordless admin accounts are tightened first, maybe before the alternative is available, but you'll likely be able to control this a bit by delaying server updates.

In summary, there's nothing bad for you to expect and no reason to get upset right now..

Admin accounts should always require a password, and have an option for MFA

User accounts should require a password to be set, but it should only be enforced for remote access, and optional for local access.

Simple

 

 

[MBSki 1025]

7 minutes ago, adrianwi said:

Admin accounts should always require a password, and have an option for MFA

Agree. MFA would we a great add.

[rbjtech 4304]

14 minutes ago, adrianwi said:

Admin accounts should always require a password, and have an option for MFA

User accounts should require a password to be set, but it should only be enforced for remote access, and optional for local access.

Simple

 

 

The concept of lan/wan as security zones is outdated and flawed.  All clients should need to Authenticate every time (ZeroTrust), it's how they do this which needs to change - and using a 'token/device' based approach like pretty much every other piece of modern s/w out there needs to be adopted.   This will also allow for multi-user remote usage, because the 'location' becomes irrelevant - if you have a valid token on the device (because you authenticated once and chose to save the token), then you get to login.  Admins should probably have some addational control options, such as having a TTL or MFA as you say.

Edited May 29, 2023 by rbjtech

[rbjtech 4304]

9 minutes ago, MBSki said:

Agree. MFA would we a great add.

MFA would have made no difference what-so-ever in this vulnerability - the password was simply bypassed because of decisions made elsewhere ...

Edited May 29, 2023 by rbjtech

[MBSki 1025]

6 minutes ago, rbjtech said:

MFA would have made no difference what-so-ever in this vulnerability - the password was simply bypassed...

In this case maybe, but it would still be a good add for protection against future vulnerabilities.

[rbjtech 4304]

Just now, MBSki said:

In this case maybe, but it would still be a good add for protection against future vulnerabilities.

Sure - not denying that - but as has been my stance on the MFA threads in this forum, MFA is of zero use if you can simply bypass it.   A bit like having a lock, keypad entry and retina scan on your front door, but the front window is wide open ...  

[softworkz 3341]

Nothing against the principle of MFA, but what's ultimately annoying is that the big players are pretending to be concerned about your security, but the sole reason why they are asking for your phone numbers is for making you and your data more identifiable and relatable...

[Painkiller8818 203]

One important question, so lets say you have a password/PIN protection, and a hacker tries to gain access, does emby has the ability for a lockout policy? EG 3 failed tries in 5 mins and locking the account for x mins or permanently?


Because even if you have a Password and someone really wants to hack you, this is really simple with bruteforcing a PIN or using a dictionary attack for more complex passwords. Using the GPU for this will allow to try 60K+ passwords a second and having wordlists with 20GB+ can have a lot passwords.

So maybe some kind of lockout policy for security would be great.

Thanks

Edited May 29, 2023 by Painkiller8818
grammatically correction