News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Copy of the Forums database

Started by Magnum, July 16, 2016, 03:49:41 PM

Previous topic - Next topic

Magnum

I can only understand the first two things of the "we know", but do not understand the rest.

I am interested in what those others mean.

QuoteWhat happened

At 20:33 UTC on 14th July 2016, Canonical's IS team were notified by a member of the Ubuntu Forums Council that someone was claiming to have a copy of the Forums database.

After some initial investigation, we were able to confirm there had been an exposure of data and shut down the Forums as a precautionary measure.  Deeper investigation revealed that there was a known SQL injection vulnerability in the Forumrunner add-on in the Forums which had not yet been patched.
What the attacker could access

The attacker had the ability to inject certain formatted SQL to the Forums database on the Forums database servers. This gave them the ability to read from any table but we believe they only ever read from the 'user' table.

They used this access to download portions of the 'user' table which contained usernames, email addresses and IPs for 2 million users. No active passwords were accessed; the passwords stored in this table were random strings as the Ubuntu Forums rely on Ubuntu Single Sign On for logins. The attacker did download these random strings (which were hashed and salted).
What the attacker could not access

We know the attacker was NOT able to gain access to any Ubuntu code repository or update mechanism.

We know the attacker was NOT able to gain access to valid user passwords.

We believe the attacker was NOT able to escalate past remote SQL read access to the Forums database on the Forums database servers.

We believe the attacker was NOT able to gain remote SQL write access to the Forums database.

We believe the attacker was NOT able to gain shell access on any of the Forums app or database servers.

We believe the attacker did NOT gain any access at all to the Forums front end servers.

We believe the attacker was NOT able to gain any access to any other Canonical or Ubuntu services.
What we've done

Cleanup

    We backed up the servers running vBulletin, and then wiped them clean and rebuilt them from the ground up.
    We brought vBulletin up to the latest patch level.
    We reset all system and database passwords.

Hardening

    We've installed ModSecurity, a Web Application Firewall, to help prevent similar attacks in the future.
    We've improved our monitoring of vBulletin to ensure that security patches are applied promptly.
Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org

Raistlin

QuoteWe believe the attacker was NOT able to escalate past remote SQL read access to the Forums database on the Forums database servers.

We believe the attacker was NOT able to gain remote SQL write access to the Forums database.

We believe the attacker was NOT able to gain shell access on any of the Forums app or database servers.

We believe the attacker did NOT gain any access at all to the Forums front end servers.

We believe the attacker was NOT able to gain any access to any other Canonical or Ubuntu services.

I'll give it a shot - if you're still interested..

-->> NOT able to escalate past remote SQL read access...  && NOT able to gain remote SQL write access ....

-Meaning the user-mode (via access control list) for all external users and therefore at incident time (the attack) was set to READ-ONLY
for the database, the attacker could therefore not modify/delete/insert database tables & entries further compromising the forum members
and content of the forum.

-->> NOT able to gain shell access on any of the.... && NOT... && NOT ...

-Meaning the attacker did not compromise the physical local server service (in this case the web-server service - probably Apache) or underlying operating system by
gaining root or privileged access.

It was purely a database design and implementation vulnerability. I believe the attack was possible because of two related reasons.
The interface programmer was possibly lax at verifying and validating input. The web-admin possibly did'nt implement a backup, patch management
and surveillance strategy - that had been documented, policy implemented, tried, tested, modified, informed & more importantly: used.

The lesson - be proactive - concerning anything IT.
   





Are you pondering what I'm pondering? It's time to take over the world ! - let's use ASSEMBLY...

Magnum

Thanks Raistin for the explanation.

Take care,
                   Andy

Ubuntu-mate-18.04-desktop-amd64

http://www.goodnewsnetwork.org