I would say that the restriction of "@" as the starting in an email probably needs to be longer and random - think of it as having close to the value of an SA password - if you know it, you can potentially damage the server. It might be an idea to change it periodically, too. Or did I miss something?
Of course, you can edit the rule so it only applies from (a) nominated email address(es), which would help.
On the whole tho, as long as this fits within security policies, it seems like a good inventive way of best using your time - and provides the benefit to the company that you can help resolve the problem quicker - no commuting to the VPN!
I never could get the first script to send an email. I have used scripts similar to this which worked. When I try to execute the stored procedure directly from query analyzer it returns a 0 but does not send an email.
I also did not understand what the Persons.dbf was used for. I did not see it mentioned again.
I shudder to think of the uses this can be put to.
"Here's my new stored procedure that'll make everything run faster, and run my vbs virus all that much quicker "
Useful article though
I agree with your comment: As having simply the "@" symbol as a the starting in an email to activate a script. I actually have a few different symbols in my key phrases that I support. That said, I never give out these special key phrases to anyone, including other administrators.
In regards to editing the rule so it only applies from a nominated group of addresses, you are correct. Currently only my tmobile account email activates the scripts. Thinking back, maybe I should of added some of these thoughts to the main article. I am glad you brought them up, I am sure they will help folks who are looking to implement this in some way to their own system.
I am glad you enjoyed the article, I sure hope it helps folks who really want another tool that will win back some of their personal time, which is the real reason I decided to write the article.
I have only found 2 reasons why the email script would not work, maybe you can check these on your system.
1- SMTP service is not running on the box that is running SQL Server. Turn SMTP on.
2- Port 25 is blocked and preventing email to be sent outside the business LAN. If this is happening, simply send the email to yourself within the LAN using the procedure. This usually will be picked up within the LAN without a problem. Then have a rule forward the email to your 'second' email that you use for your phone, or pager.
I have seen the latter happen often.
Oh... BTW. 'Persons.dbf' was a comment I forgot to exclude. Sorry about that, you can simply ignore that one. My mistake.
Hope this provides an easy fix.
Hi Phill, I have thought about the dark side of the article myself...
But, I also think that if Administration is done properly, which means Domain admins and SQL Admins are different entities that do not share domain passwords, (and of course passwords are changed regularly as part of the business operational tasks, which is what most businesses do at the present time), their would be little to worry about.
I think if anyone has a domain admin password and they are up to no good, they would really not need the use of scripts or SQL Server to cause harm. They would simply go for the jewels of the business directly.
Having a separation between network admins, and SQL admins allows for much of those vb script virus issues to disappear, even if the virus writer (god forbid) was working within the business network already.
I personally don't have network admin rights, I use WMI access only on those machines I personally have rights to, which is proper.
Thanks for bringing this up Phill, I hope this helps people lock down their system properly if they were considering this type of tool to help them win back some of their personal time.
But, I also think that if Administration is done properly, which means Domain admins and SQL Admins are different entities that do not share domain passwords, (and of course passwords are changed regularly as part of the business operational tasks, which is what most businesses do at the present time), there would be little to worry about.
I want to use your example to call an external vbscript and perform a WMI query that return values to my SQL stored procedure for use in a report.
I can call the vbscript, but am unable to get any output values from it. How do I setup my vbscript to return these values, or can you tell me where the disconnect is? I've tried wscript.echo statements and wscript.quit(<insert value here>.