XMPP Service Operators - 2021-12-10

Somebody working with apache and/or log4j ? Have a look about CVE2021-44228 Will kill my weekend 😕

Confirmed that Tigase is not vulnerable, but I haven't looked into Openfire

yeah, we don't use log4j

I thought people switched to logback ages ago, apparently not

Thinking is dangerous (?) 🤣

~thinking~ that people upgraded ages ago is always a dangerous assumption ✏

TheCoffeMaker, there I fixed it ;)

lol

Openfire apparently vulnerable: https://discourse.igniterealtime.org/t/openfire-4-6-5-released/91108

That will be fun. There are a lot of poorly-maintained Openfire installations around...

openfire still works?

when I try to open the client it just is a blank white window

The log4j vuln is already being abused in wild

Yeah, just leave company after 16h of work, colleags will stay. My turn will be tomorrow again. There are pictures of hacking Amazon and other big players, seems to be a big impact. Each jar which will use log4j and open a port will possible be attack-able

I guess we could exploit the openfire bug to upgrade openfire for them

Not the first time such a suggestion has been made about Openfire :P

Though it's been a while

https://twitter.com/cyb3rops/status/1469343827228086278 accurate

Has Openfire a bad record?

The biggest one was the failure to check the username of password changes. In XMPP you send a <username>youruser</username><password>new-password</password>, but Openfire didn't check that the username was your username

So you could set any user's password, including the default 'admin' account

Which in turn could be used to log into the web admin that it served by default

That's awesome

Combine that with the numerous web interface flaws and the fact that many Openfire admins just run it as root (or Windows equivalent), and... yeah

Actually the main npm registry just had the same bug

https://twitter.com/kikta/status/1469388635954978822 love it

Oops wrong MUC my bad (still relevant but unintended)

java?

> in the case of Minecraft, attackers were able to get remote code execution on Minecraft servers by simply pasting the malicious string into the chat box. Everything is just broken.. We always have to remind ourselfs.

Probably relevant for those worrying about jog4j: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Huhu I vaguely recall there's a lot of java into Ubiquiti firmware...

That's gonna be fun.

I've never seen a vuln that is so critical and so easy to exploit. Compared to this, Heartbleed was rocketscience and more limited in it's impact. We're gonna be veeeery busy with this one for the next months...

In fairness Heartbleed was quite a bit more widespread, as the "market share" of OpenSSL is quite large, covering most things that do TLS

Many systems don't run Java services, and those that do don't necessarily run log4j (of the 2 publicly-accessible Java services I admin, neither use log4j)

I really want to have a centralized password/login management across my xmpp server, dovecot imap, INN nntp, and ssh unix system

is ldap the way to do that?

i'm not familar with ldap

LDAP is probably the best way to do that, yes... everything supports it

can confirm

also, is there a way with such a centralized login system to only allow certain users or groups access to say, xmpp servce, ssh shell accounts, imap, and network news?

Is there any good resources you can point me to for getting started with it then?

at least understanding the system

you can use groups and ldap filters to limit access to certain groups

if i'm understanding right, ldap isn't used alone. it's part of a large openldap+kerberous+session tickets system yes?

tom: I do that with accounts in a SQL database

I've done that before with a sql database and a python library

but it becomes a bit trickey when you want to use existing software, or not just validate passwords but have things like session tickets and only allow access to some systems

Nginx, prosody, dovecot, postfix, nextcloud etc etc all use the same user+pass

ij, no idea why looks normal from my side

Each account has a Boolean column that grants/denies access to each service

but then how do you handle other attributes, like homedirectory, unix user groups,

gecos

nicknames

allowed email FROM addresses

tom: I use postfixadmin which handles all that, I added the other columns for XMPP and http etc later

> The biggest one was the failure to check the username of password changes. In XMPP you send a <username>youruser</username><password>new-password</password>, but Openfire didn't check that the username was your username > So you could set any user's password, including the default 'admin' account > Which in turn could be used to log into the web admin that it served by default 😳

Same exact bug https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/#security-issues-related-to-the-npm-registry

does anyone know of a good guide for getting started with openldap central authentication?