July 8, 2002 at 10:01 am
just thought you guys might be interested...
July 8, 2002 at 10:22 am
Wow, someone is doing there job. I had assumed this was some sort of MD5 or other one way hash, but apparently not.
I guess NT Auth is starting to look better and better.
Thanks for the link.
Steve Jones
July 9, 2002 at 1:02 am
A while ago NGS SOFTWARE also published two very good papers on sql injection (time to ensure that all web pages which link to a database are injection proof!)
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
Steven
July 9, 2002 at 10:18 pm
Reading over the paper, it does look like SQL is using a hash (SHA). The problem is SQL Server records two hashes... one which is upper cased. As a result, that makes a brute force attack that much easier. Once we have a match on the upper case password, it's easy to get the case-sensitive password. It looks like the code they are presenting do a dictionary brute force scan.
BTW, it's much easier to sniff the "encrypted" password as it comes across the network. The method of decrypting it is trivial.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
July 10, 2002 at 9:53 am
I agree with brian, but if you ahve access to sniff. With today's switches being deployed in so many places, it can be difficult for someone in your org or a consultant to sniff the network. However, it might be easier to make an attack on the SQL Server. Another reason to limit access to your SQL Server as well as SET AN SA PASSWORD.
Steve Jones
July 10, 2002 at 10:29 am
Agreed. Sniffing is only an issue for internal folks, who you're already placing a lot of trust in anyway. After all, a domain admin is a domain admin. There is very little he or she can't do.
It looks like the news of the SQL Server password cracking has made it to the Register. There is a writeup now on NTBugtraq. Here is a key point the writer (Barry Dorrans) makes that I failed to mention. In order for the cracking to work, one has to have access to the hashes in the first place. The person has to have sa rights to retrieve the hashes. That means the person has to have access to the sysxlogins table. Being a sysadmin or db_owner of master will give a person the ability to issue a SELECT, but if I have that level of permissions, what can't I do?
As a sysadmin, I can easily export the password out, change it using sp_password (since I'm a sysadmin I don't have to know the old one), log in as the user and do my worst, and then reset the password back. So I already have rights to infiltrate the system under another user account.
The average user doesn't have access to the hashes, a key point. So even if the user can authenticate with the SQL Server, the user can't run the attack unless elevated permissions are granted (ok, now this can be tied in to other attacks, but then we have the scenario I've already described). A user who can't even authenticate is forced back to the same brute force method to begin with.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
July 10, 2002 at 10:40 am
Good point Brian,
Unless you leave your machine unlocked.
Keep in mind that the people you are concerned about in this situation are consultants or others who may wander in your office. You want to prevent them from getting sysadmin level access. If they cannot sniff the network, you are not out of the woods. Ensure someone does not do ANYTHING under your account without you watching. I was recently a consultant at a company (supposedly secure) and they left me alone in the NOC area for 1/2 hour. I could easily have downloaded this table for their SQL Servers. I also could have snagged the RESCUE folder (after updating it) from any server, including a domain controller.
Security is a mindset and a process, not a tool or a set it and forget it.
Steve Jones
July 10, 2002 at 10:48 am
Physical security is an important security domain... and yet it's one of the oft violated ones. I've got a link somewhere where a guy was hired by a company to see if he could get into their secure database.
He walked to the data center, helped some guys get a computer through the door, helped them hook it up, and then looked around and found a console which had a privileged account logged into the database. No one challenged him!
Unbelievable.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
July 10, 2002 at 10:55 am
And typical. People laugh at me, but I never leave a consultant alone. Some junior admins have gotten annoyed because I've had them babysit someone while I had to do something else, but you have to do it. You never know what someone else's agenda is.
This includes developers. I never give them sa access because you never know if any non-admin is going to quit next week/month/whatever.
The same goes for sysadmins, but you have to trust someone. And you change pwds when they leave. ALL of them
Steve Jones
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply