This afternoon, I noticed some strange heavy load on our Postgres database. After some initial investigation, it was discovered that a server misconfiguration left our Postgres database open to the internet since late January 2018.
Why was the e-mail notice sent from gmail address? At first I thought it was fake.
Good question!
I sent them en-mass from the official public Haiku, Inc. email. Gmail requires outbound smtp emails to come from gmail.com (and will even go as far as modifying the from address to ensure you aren’t spamming from them).
I could of sent it from baron/maui directly on haiku-os.org, but GDPR best practices dictate that communications around data security incidents come from official channels of the corporate entity.
I also wanted to ensure delivery occurred and the emails didn’t get flagged as spam since they’re pretty important… gmail has a good track record of not getting classified as spam.
Some emails (based on last session age)
Can you clarify on this - what kind of session age was affected?
I didn’t get any e-mail, btw.
Trac was not configured with usernames + passwords directly stored in the database, however, Trac stores “session information” in the database.
The session table looks like this (X’s added for obvious reasons)
sid | authenticated | last_visit
XXXXXX1ccXX5ae | 0 | 15295XXXX
XXXXXX889XXX3e6 | 0 | 15295XXXX
XXXXXX8af7XX9e50 | 0 | 15295XXXX
MrUsername | 1 | 14467XXXX
Those seem like users navigating the site, unauthenticated shows a random id, while authenticated show a username.
That table isn’t too bad, but we have another table named “session_attribute” which has all the sessions and their actions. These are the actions of anonymous users (not so bad), but also the actions of authenticated users. In the example below, a new user had a verification email sent to them to register a new account:
myusername | 1 | email_verification_sent_to | myusername@myemail.com
I’m not 100% sure on how far these session tables go back, in theory, sessions should be cleared out, but Trac seems to preserve them indefinitely for some reason.
Direct emails were only sent to those individuals where password hash information was leaked along with emails or usernames since that is a sizeable breach of PII (Personally Identifiable Information) which could be exploited. I’m depending on public notifications for everything else (mostly what was leaked from Trac).
I should take a moment to mention that Trac has a LARGE number of fake spam accounts (and fake spam session data) stored in it. A lot of the data within the session table is completely and absolutely fake that was populated by spammers over years.
The session tables are obviously handled by Trac alone - the PHP interpreter has no business there. And judging by the column names in the “session” table, the data is not supposed to be cleared out, but left there for future visits.
But you can safely remove the data belonging to unauthenticated users if it’s older than 30 days. That will surely clear up lots of rows in the table, especially if you have many users.
Given that Trac is written in Python, I guess it’s unlikely that a PHP interpreter would have anything to do with it.
Oh, right. I assumed the project’s language incorrectly. 
Anyway, the rest of the comment stands - the old unauthenticated sessions and their data can be safely removed. They’re useless anyway, so I wonder why Trac doesn’t clean it up and even allow the admins to configure the maximum age for the sessions.