The incident happened more than a decade back, should be in 1998 or 99. At that time I was a consultant to a popular online news portal, I got a call from their CTO. Their Systems’ Engineer was sick and being hospitalized, they need to urgently update some code and no one in the office has their production SQL Server credentials (username and password). They had a password management system but that master password (or the paper notebook which had the password) was also with the Engineer who was bed-ridden and unreachable. He asked can I help?. I don’t do magic or I was good at guessing passwords, but I said I will come over and see what could be done.
After spending few fruitless hours trying various things, it hit me to check how secure was their ASP front-end code. Within minutes I figured it was not, they were not doing Input validation and the code was prone to SQL Injection code attack. The first time someone would have thanked the developers responsible for being irresponsible to have left open a serious security bug in their code. After this deduction, it took few minutes to execute SQL Server “xp_cmdshell” command, followed by Windows Server command “NET USER”. These commands allowed me to add a new user “VENKAT” and insert the user into Windows Administrator group. Voila!
xp_cmdshell 'NET USER VENKAT /ADD'
xp_cmdshell 'NET LOCALGROUP ADMINISTRATORS VENKAT /ADD'
Now, in my case, it turned out to be a blessing, but having it is a very dangerous security threat, you should ensure you don’t check your code and servers for SQL Injection attacks. Fortunately, Microsoft has blocked by default the XP_CMDSHELL command from SQL Server 2005, you need to explicitly turn it ON if you need it for any valid reasons, which frankly I see none.
SQL Server 7.0