Security breach in Discourse forum with SSO


#1

Hello, we’ve recently setup a Discourse forum with SSO.
Now one of our users claims to be a hacker and I believe it’s actually legit.
He has given me screenshots of the user database which matches exactly with the Discourse database.
So he has emails from all our users and ip addresses.
The reason it must be from Discourse is because our own database stores different IP addresses and doesn’t have flag_level.

I’d like to get in contact with a developer or someone experienced so that the security issues can be resolved.
It really shouldn’t be possible for anyone to hack into the forum to access private data from all users.

The image on the right is the one the hacker sent us and the one on the left is from the data explorer on our site. (we just installed that to find out of it came from the forum it wasn’t installed before)
I blurred most of it but as you can see the stuff that isn’t blurred matches with the forum.
– screenshot removed (no longer relevant) –

It’s either the forum itself or SSO but there’s obviously a security breach and I really hope an expert can contact me so that it can be resolved.


(Jeff Atwood) #2

What version of the software are you at? It is quite important to stay on the current release or very near to it.


#3


(Jeff Atwood) #6

Oh my bad, I read that as 1.7 beta2. You’re right, it is up to date :wink:

You need to follow the advice here:

You should also check the Admin, Logs for staff actions to determine if there are any unusual staff actions there. To be able to download the database they would need to

  • have SSH access to your server

or

  • become an admin on your site

#7

Alright, for the password reset will it work with our SSO login though?


(Jeff Atwood) #8

How did you implement SSO? Perhaps @sam or @tgxworld can advise on that because I’m not sure how that FAQ changes with SSO in the mix, exactly.


#9

This is my SSO implementation.
I’ts pretty basic but I followed all the instructions and should be good.
I’m no expert on it either and also not an security expert for PHP so if there’s something wrong with this I’d like to know.


(Jeff Atwood) #10

In the meantime look at /admin/logs/staff_action_logs closely, db download would definitely have been logged.


#11

We only have 3 admins from which 2 haven’t really done anything on the forum and the other is me.
And the system user too.
But I can’t find anything in the logs that I haven’t done it’s mostly customization actions.


#12

I also exported the log and searched for ‘export’ or anything like that and no results at all.
The data the hacker has provided seems to be live data because all the IP’s match exactly with the ones logged in Discourse.


(Jeff Atwood) #13

I just checked and we only log the creation of new backups as “backup operation”. If you have existing scheduled backups in /admin/backups, simply downloading a backup from there is not explicitly logged. But it is only possible by an admin, for sure.

The log for the download would be in your nginx logs, of course.

(cc @zogstrip I think db downloads should be forced through a redirect link so we can log them.)


#14

Hm we run the forum in a CentOS VPS and I can’t really find the nginx logs.
The directory /etc/ngynx doesn’t exist and there’s nothing with ngynx in /var/logs

EDIT: Found the ngynx logs but can’t really find anything useful in there.
Any specific things I should be looking for?


(Sam Saffron) #15

SSO is only as safe as

  1. your secret SSO encryption key in site settings, leak that and it is bad news
  2. your internal login implementation. if people can log in to parent site then then can log in to Discourse.

I suggest you review the parent site providing SSO and investigate if you have unauthorized access there or a bug in your internal auth implementation.


(Claas Aug.) #16

I notice that the site does not use HTTPS. If you ever access your forum via an unencrypted Wifi network, anybody near you may read your session token and/or read the login data of the SSO site, if it doesn’t use HTTPS either (which it doesn’t).

PS: Actually, your site redirects from HTTPS to HTTP:

curl -i https://forum.***.io
HTTP/2 301
(...)
location: http://forum.***.io/

#17

Only me and a few other developers could know the key.
The SSO page needs to know the key too obviously but I doubt that anyone could find the key on our SSO page.

I posted my SSO page above, do you see anything wrong with that?
I assume if there would be an issue with SSO it would be within the authentication itself and not the SSO page.

We haven’t really been able to find anything we spit through a lot of stuff to find out how the hacker got the private data.
And then we checked the forum and found the data match.
But now we have to figure out how he got the data from the forum obviously.


Yeah we had to do that for our main site because it’s for a game which uses websockets and quite a lot of people were experiencing issues when we used https for websockets.


#18

Alright, sorry for the trouble guys.
Managed to talk some more to the hacker and he has given me all information how he did everything.
And it turns out he managed to get the password of one of the other admins and download the backup with that account.

It’d be nice if you can add it to the logs so it’s easier to detect this kind of stuff.
Maybe even put a option to send notification to all admins if a backup is being downloaded.


(Sam Saffron) #19

We have some logging, system user will notify user that it created the backup. You can look at those messages. But … there is no logging each time a backup is downloaded.

We should expand the backups page to display IP address, time and admin name whenever any backup is download.

Additionally I feel we should be somewhat more restrictive with admin accounts, when admins login from a new IP we should send an email to said admin notifying them that a new IP accessed the account. This would at least alert us much much earlier of stuff like this. In a hyper secure mode each new IP should be vetted.


#20

Yeah sound great.
It’s obviously our fault that this happened but it could happen to any site so some extra security and logging wouldn’t harm anyone.


(Jeff Atwood) #21

Step zero is to log the downloads of the backups for sure @zogstrip can you take that for Monday? We should backport that to 1.7 as well.


(Régis Hanol) #25

I added log of both download and destroy operations (and backported it to 1.7)