Critical security update to Flarum core (v1.6.2)

Darkle

An impressive proof of the commitment and capability of Flarum developers! 💪

CyberGene

Glad you fixed it. Do you know if it was actively exploited and how? How can we check if someone exploited our forum? What else do we need to do, e.g. check which setting, change passwords, permissions, etc.?

ping

CyberGene I'm from CyStack, the team who reported the vulnerability to Flarum. I guess this vulnerability has not been widely exploited in the wild because if it happens, it is easy for everyone to know it and report it to the community.

The serious problem is that this vulnerability is extremely easy to exploit, anyone can create a Discussion and attach the payload to it. Then any user (including the Admin role) accessing the discussion link can have cookies stolen, and of course, their account will be taken over control afterward. This means that every setting in Admin Dashboard can be stolen (SMTP credentials, email API token, AWS tokens if integrating AWS S3, Pusher token...)

I strongly recommend that quickly take a look at your Discussion title in your forum. If it has not been upgraded to the latest version and the titles contain HTML tags like <img src=x onerror=> then it means the forum has been exploited. Please quickly change the admin password, change tokens in the Admin settings, and recommend your users change their passwords

Vadim_RUNN

Just upgraded. No issues. Thanks!

pierres

No doubt XSS is critical, but would it be really that easy to steal cookies? These are currently set to HttpOnly and SameSite=Strict.

You could still use this easily for CSRF; doesn't have Flarum any mitigations for this? (at least for really critical user interactions)

rob006

pierres No doubt XSS is critical, but would it be really that easy to steal cookies? These are currently set to HttpOnly and SameSite=Strict.

This! In general I feel that Flarum is very "generous" when it comes to CVSS - previous XSS got 10/10 score, although POC was about search, so AFAIK this was non-stored XSS and user had to click malicious link to trigger it.

davwheat

pierres You could still use this easily for CSRF; doesn't have Flarum any mitigations for this? (at least for really critical user interactions)

We have mitigations to prevent CSRF, but there ultimately is nothing we can do in some cases.

A malicious payload could make a request to any endpoint, which would include the HttpOnly cookie, and the CSRF token can easily be fetched through the global app.session object.

It's pretty easy to perform an attack, really.

clarkwinkelmann

pierres would it be really that easy to steal cookies?

I haven't tried stealing cookie, but other attack methods targeting admins would be to use a REST API call to change the password of any admin user to a value known by the attacker, promote an account you already control to administrator, or change the SMTP server so you can receive password reset emails. You could then demote existing admins to slow their reaction, as it will require accessing the server and manually revert roles in the database.

At least it should be pretty obvious that a discussion (or nickname!) contains something malicious before clicking on it from the discussion list or user directory.

I would say the best way to disguise an attack would have been through the server-side title XSS, because you could close the <title> tag early, so that even a link preview in an external client or search engine wouldn't show any HTML/javascript. But again you would see the full title as soon as you open the page so you could still notice something might have been wrong.

rob006

davwheat We have mitigations to prevent CSRF, but there ultimately is nothing we can do in some cases.

Changing password/email, or any admin/unrecoverable action could be hidden behind sudo mode. That would reduce XSS like this to minor annoyance in most cases.

Wellwisher

Just curious why are the update code instructions given here (in this topic) different to the ones listed in the Flarum updating docs?
I followed update instructions in this topic and when I visited my test instance, my forum wanted my flarum database password again.

Once I entered the DB password, everything was fine and the upgrade was successful.

Just want to make sure that's normal?

davwheat

Wellwisher

Yes, that's normal. It's just an oversight from our point of view.

The database password step you performed on the web is equivalent to running php flarum migrate on the command line.

Wellwisher

davwheat I learn everyday, thank you to the person sharing the security concern and flarum dev's for patching it. 🐊