There are a number of whys to prevent use of XP_CMDShell. A combination of NTFS file permissions and SQL server permissioning is best. I prefer not to drop and have an auth failure - gives visibility of use. Any use of the stored procedure is logged in the eventlog and you can use dumpel to pull out these kind of events to a central server. David Ashwood Global Anti Virus Deutsche Bank +44 (0)20 754 71655 david.ashwoodat_private "Steve Zenone" <zenoneat_private To: <incidentsat_private> .edu> cc: <thompsonat_private> Subject: RE: Windows Systems Defaced 03/05/2002 04:23 Hello, Stephen W. Thompson wrote: |> Have any of you seen similar activity? Any thoughts? | |Yes, we had one that matches most of your details. These |are exact matches: | |> [] Damage occurred around 1600 on 5/1/2002 |BUT=> (approx. 16:00 EDT for us) |> [] Win-popup message with "F---ing University of Rochester" |> -- NOTE: not all systems running IIS |> [] Admins claimed that all systems were patched correctly |> [] Most were running updated and current AV Thank you very much for your reply - it definitely helps! We have been seeing MS-SQL (1433/tcp) attacks that try and execute the following: -----BEGIN SNIPPET----- xp_cmdshell 'echo net send localhost F---ing University of Rochester rebooting... > rochester.bat' xp_cmdshell 'echo del g:\ /f /q /s ^nul 2^>&1 >> rochester.bat' xp_cmdshell 'echo del g:\ /f /q /s ^nul 2^>&1 >> rochester.bat' xp_cmdshell 'echo del g:\ /f /q /s ^nul 2^>&1 >> rochester.bat' xp_cmdshell 'at /delete /y' xp_cmdshell 'echo if exist \inetpub\wwwroot\ type %systemroot%\rochester.html ^ e:\inetpub\wwwroot\index.html >> rochester.bat' -----END SNIPPET----- The above commands were directed to systems that were listening on port 1433/tcp and accessible from the outside. It appears that there were multiple source IPs involved in this attack. At this time, I am not completely clear on how to protect from this attack. What I've researched is that since external functions such as xp_cmdshell, xp_startmail, xp_sendmail, and xp_stopmail present possible security risks, it is recommended to drop such external system functions. Else, deny EXECUTE permission on them to specific users/roles if dropping these procedures would break any of the SQL Server. I haven't tested this - but does anyone on this list know if this is a safe and effective solution? Regards, Steve ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri May 03 2002 - 08:30:41 PDT