Why the silence?

[findingpeace]

Originally Posted by Max Taxable

That's not known for sure. Read paul's posts, what he says is what they know. he never said the customer data is in 3rd party hands.

Doesn't this post from Paul mean customer data is in 3rd party hands?

They then appear to have cracked a mysql user password for the Live DB server, and used it (via adminer) to read the vb.com and vb.org user tables.

Apologies if I'm misreading, but if they read the user tables, then it's also likely they now have the data, right? Even if it's encrypted, that's a little scary to me. I hate the idea of my email address with a bunch of hackers. Freaks me out.

[Max Taxable]

Originally Posted by findingpeace

Doesn't this post from Paul mean customer data is in 3rd party hands?



Apologies if I'm misreading, but if they read the user tables, then it's also likely they now have the data, right? Even if it's encrypted, that's a little scary to me. I hate the idea of my email address with a bunch of hackers. Freaks me out.

Yes thanks for pointing that out, that slipped by me. My apologies. It sure does sound like he is saying that.

[Digital Jedi]

Originally Posted by findingpeace

Doesn't this post from Paul mean customer data is in 3rd party hands?



Apologies if I'm misreading, but if they read the user tables, then it's also likely they now have the data, right? Even if it's encrypted, that's a little scary to me. I hate the idea of my email address with a bunch of hackers. Freaks me out.

Nope, Paul said that they targeted the user tables. The forum. Not customer data. Not the same thing.

[findingpeace]

Originally Posted by Digital Jedi

Nope, Paul said that they targeted the user tables. The forum. Not customer data. Not the same thing.

Well I am a vBulletin customer, and it is my data I get what you are saying though, I'm just being a spaz - at least it's not our credit card or license info.

[Chris8]

But the thing that is essentially concerning me now the most here in this whole mess actually is:
Supposedly if they had access to write/modify files on vb.com and vb.org servers (By the way, isn't it the same server? Or Vb.com is on separate server from Vb.org?) are all downloadable scripts, mods, templates safe? I mean, assuming they had that access they could for example change certain mods or themes code to put vulnerabilities into them so they can hack other websites powered by vbulletin later.

So, ideally if vb staff knows they had such access vb staff should do the diff of all downloadable content against the backups from the time before it happened to make sure people are safe when downloading and installing new content on their forums/servers.
Also I would be more calm if they (you - I guess people in charge/responsible for vb here read this) could make a statement assuring your customers that everything is safe and nothing was modified or if there was anything modified that you took care to fix it.

[Will Watts]

Originally Posted by Paul M

They then appear to have cracked a mysql user password for the Live DB server, and used it (via adminer) to read the vb.com and vb.org user tables.

How did they crack the MySQL password - how is the QA server linked to the live DB?

I'd rather you elaborated on that, with an explanation of "we made a mistake/a config file was left on the QA server/something else etc" rather than leaving the possibility of a vB exploit open. Even if it was only a QA server hacked, how did they then escalate that to the live DB?

[Digital Jedi]

Originally Posted by Chris8

But the thing that is essentially concerning me now the most here in this whole mess actually is:
Supposedly if they had access to write/modify files on vb.com and vb.org servers (By the way, isn't it the same server? Or Vb.com is on separate server from Vb.org?) are all downloadable scripts, mods, templates safe? I mean, assuming they had that access they could for example change certain mods or themes code to put vulnerabilities into them so they can hack other websites powered by vbulletin later.

So, ideally if vb staff knows they had such access vb staff should do the diff of all downloadable content against the backups from the time before it happened to make sure people are safe when downloading and installing new content on their forums/servers.
Also I would be more calm if they (you - I guess people in charge/responsible for vb here read this) could make a statement assuring your customers that everything is safe and nothing was modified or if there was anything modified that you took care to fix it.

If you re-read Paul's explanation, you'll see nothing was modified. vB.org tables were read, not modified. And the only tables read were user tables.

Originally Posted by Will Watts

How did they crack the MySQL password - how is the QA server linked to the live DB?

I'd rather you elaborated on that, with an explanation of "we made a mistake/a config file was left on the QA server/something else etc" rather than leaving the possibility of a vB exploit open. Even if it was only a QA server hacked, how did they then escalate that to the live DB?

Adminer lets you manage database files from one file. I've not used it, but if they had a bunch of cloned databases to look at, it was probably simple reverse engineering.

[Lynne]

The databases are on a different server than the files (typical setup if you have more than one server).

[Will Watts]

Originally Posted by Lynne

The databases are on a different server than the files (typical setup if you have more than one server).

So how did they crack the the live DB MySQL? Was the password listed somewhere on the QA server or do you not know how it was done?

Paul said
"They broke into an old stage server, mainly used by QA for test installs of vB4 & vB5.".

If they broke into the server, the QA DB password could be gleaned by the vB config file. Hopefully it wasn't the same db user and password in use for vB.com or vB.org.

In the past, the QA team has copied the vb.com live database (or parts of it) to one of their servers, and tested installations.

Maybe that was done, and the db userid's/passwords were brought along with them. That would have given them access to the vb.com DB.

But I would think the vb.com DB has restricted access via the hosts table or something.