This tweet from Daniel (@DaniSQL) is a perfect example of this.

An old application that isn’t being used anymore is still available on the Internet facing web farm.  Because this application isn’t being used any more it wasn’t on any lists of deployed applications, so when security audits were done it wasn’t seen as it wasn’t listed as an active application.  However it was apparently able to provide a hacker with a way into the database because it was still connected to a SQL Server instance and it was susceptible to SQL Injection.

The solution to this problem is sadly easy, remove the web based application from the web farm as the application isn’t being used anywhere.  It’s a lot easier than fixing the application, and a whole lot cheaper (10 minutes of a system administrator’s time versus weeks or months of a developers time).

I urge you to audit the applications and websites which are deployed to your web farms, especially the Internet facing web farms and see what’s on there.  When you audit them, don’t audit them against the list of what’s there.  Actually dig into the IIS config of each and every server (yes I’m well aware that doing this sucks) and actually see what’s configured on each machine.  If you don’t know if an application is actually being used ask around.  If it isn’t, remove it (or at least stop the site in IIS) so that you don’t have to worry about scripts breaking into your database and updating your data.

Now thankfully this current attack which is going around is just updating data, but it could easily enough be changed by the attacker to gather data as well, so do yourself a favor and protect yourself.

Denny

Where Should I Be Encrypting My Data being presented by me

SQL Server 2012 Security for Developers being presented by Andreas Wolter

The Evolution of Security in SQL Server 2012 being presented by Don Kiely

SQL Injection: From Website to SQL Server being presented by Mladen Prajdić

There are a couple of other sessions that mention security in the abstract, but based on these abstracts I’m guessing that security won’t be mentioned very much during the actual sessions.

Denny

P.S. Don’t forget about my free SQL PASS 2012 First Timer’s webcast coming up on October 17th, 2012 at 1pm Pacific / 4pm Eastern.  You do need to sign up for the session, which is FREE so get signed up.  Even if you have attended the SQL PASS summit before, this is worth it as there are some big changes in how PASS will be laid out at the convention center this year.

I’m pleased to be able to announce that the 2nd edition of Securing SQL Server is going to be available soon.  It’s just been made available for pre-order on Amazon.com.  The second edition comes in at about 350 pages (according to Amazon, I don’t actually have a copy of it yet) while the first edition came in at about 270 pages so there has been a LOT of material added to the book.

While a lot of the new information is focused on SQL Server 2012, there is also a lot of new material which relates to older version of SQL Server including chapters on SQL Server Analysis Services and SQL Server Reporting Services, information on Instant File Initialization, EXECUTE AS, Database Firewalls, SAN Security, Actual Data Security (no idea how this got missed the first time around, but that’s to Brent Ozar for pointing it out).

As far as the SQL Server 2012 information you’ll find updated information about the SHA2 hashing algorithms, Securing AlwaysOn Availability Groups, Security and SQL Server Clustering, Security and Contained Databases and a lot more.

If you already have a copy of the 1st edition I encourage you to take a look at the second edition as well.  I know that it’s really soon for a second edition of a book (the first edition just came out February 2011, but this new edition comes on the release of SQL Server 2012.

Hopefully you pre-order you copy today.

Denny

P.S. Yes this edition will be available for the Kindle as well, that takes a little time.  As soon as I know that it’s been posted for the Kindle (usually happens a little after Amazon gets the physical books) I’ll post another announcement here.

P.P.S. If you visit my SecuringSQLServer.com site I’ve updated everything there for the new edition.  You can always find the old edition listed on the Other Books page on that site or on the Books page on mrdenny.com.

In a nutshell it appears that they were relying on a RAID1 array as the database backup.  While we see this all the time in small database shops as noted on /. this site has been up since 2002 and had an Alexa page rank of 106,881 with 14k monthly visitors (according to Quantcast).  For a site so large to be making such a simple mistake is just unacceptable.

I can guarantee you that if I see a DBA resume listing journalspace.com as a prevous place on employment I’ll have to think more than twice about bringing them in.

As it says on the website the business is closed, they are going to be selling the domain name and any trademarks off to the highest bidder.

As DBAs we need to remember that the companies that we work for (or consult for) live and die by our mistakes.  If for example I were to do this same thing and we were to suffor the same fate at Awareness Technologies (my employer) I would be responsible for about 80 people being out of work.

This reminds me of a similar situation that happened when I worked for GameSpy.com.  The development team insisted on having full rights to all the production databases so that they could troubleshoot issues without having to wait for me to give them rights.

We were in the middle of deploying our new backup solution because the file server that we used to backup to couldn’t hold all the database backups any more.  Everyone had been informed that some databases weren’t being backed up while we got the new system up and running and that extreme care needed to be taken while working in the databases.

A few days later a developer comes to me asking me to restore the database with all the news articles in it back into production.  I inform him that we don’t have a backup of that database as it is one of the ones that we weren’t backing up while going through the transition.  I then ask why he needed it restored.

Apparently he thought that he was connected to the development database and truncated the table with all the articles that the site authors had written for the last several years.  Needless to day, the developers lost their access to the production databases that day.  It took the editors two or three days to get the current stories back into the system from the Microsoft Word copies that they used to do the initial story writting.

Fortunately in my story we were able to recover from the problem without much loss in revenue.  The folks at journalspace.com were not so lucky.  Not only will what ever employees they had be out of work, but all the work of the countless bloggers who blogged on that site have lost everything they wrote, some of them I’m sure for years.

This also points out the massive amount of trust that we as bloggers must have in the companies which host our blogs on our behalf.  We can only hope that they backup the databases which hold our blogs regularly so that none of what we write is lost.

I won’t begin to speculate what happened to the database over at journalspace.com, they do a pretty good job of that within the message saying that the site is gone.  What I will do is say that I agree, there was most probably a human element involved which brings up database security and SQL Injection protection.  If there was a human involved (again there probably was) I would assume that additional database security and protection against SQL Injection attacks would have prevented this from happening; although I guess if you aren’t going to backup the database having everyone with right access to the database isn’t that much of a leap.  I would be curious to go through the web server logs from the time of the data loss to see if it was an injection attack or an employee logging into the database directly.

A few hours (or possibly minutes) worth of changes to the database configuration could have kept this very popular site up for many more years to come.  It is a shame that they won’t be with us any more, they will be missed around the intertubes.

This was also talked about by Brent Ozar umong others.

Denny

So I threw this code together to clean up the data. This code will clean all the character and uni-code columns in all the user defined tables in the system. You’ll need to be dbo or sysadmin to run this without error. If you have TEXT or NTEXT columns it will through an error for those columns. Cleaning TEXT and NTEXT columns is a little more complex as you can’t use the REPLACE function on a TEXT or NTEXT datatype.

DECLARE @sql NVARCHAR(4000)
DECLARE @InsertedValue NVARCHAR(1000)
SET @InsertedValue = 'The Script tags which were inserted'
DECLARE cur CURSOR FOR
  	select 'update [' + sysusers.name + '].[' + sysobjects.name + ']
  		set [' + syscolumns.name + '] = replace([' + syscolumns.name + '], ''' + @InsertedValue + ''', '''')'
  	from syscolumns
  	join sysobjects on syscolumns.id = sysobjects.id
  		and sysobjects.xtype = 'U'
  	join sysusers on sysobjects.uid = sysusers.uid
  	where syscolumns.xtype in (35, 98, 99, 167, 175, 231, 239, 241, 231)
  OPEN cur
  FETCH NEXT FROM cur INTO @sql
  WHILE @@FETCH_STATUS = 0
  BEGIN
  	exec (@sql)
  	FETCH NEXT FROM cur INTO @sql
  END
  CLOSE cur
  DEALLOCATE cur

Hopefully you find this useful. If you need code for TEXT or NTEXT columns just post a comment and I’ll throw something together.

This code will work on SQL 2000 and up (it’ll probably work on SQL 7 as well, but I don’t have a SQL 7 machine to test against).

Denny

Denny