SQL Injection 공격이 여전히 활발하게 들어오고 있습니다. 최근에는 MSSQL이건 Oracle이건 가리지 않는 속성을 보여주더군요. 요즘의 SQL Injection공격은 DB를 변조하는 방식으로 진행되었지만, 아직도 일부 SQL Injection 공격은 여전히 시스템 장악을 목적으로 사용됩니다. 가장 대표적인 공격이 바로 xp_cmdshell 이겠지요.

xp_cmdshell와 같은 명령어는 잘쓰면 좋지만, 아무나 사용할 수 있다면 최악의 상황으로 이어질 수 있습니다.

type c:\boot.ini 대신에 del c:\boot.ini를 했다면?

 이러한 공격을 막는 방법으로 서버에 도달하기 이전에 웹방화벽에서 필터링을 하고, 웹소스 레벨에서 필터링을 하고, DB에서 적절한 권한 부여라는 모든 단계를 거치는 것이 좋습니다. 이 방법을 모두 동원할 수 없다 할지라도, 적어도 두개 이상의 방법을 선택하여 진행하여야 안전하다고 할 수 있습니다.

  • 웹방화벽이 완벽을 말할 수 없는 이유는 학습하는데 걸리는 시간이 있기 때문이며(WebKnight와 같이 지능형 장비가 아닌 경우는 패턴 추가하기 전까지는 답이 없습니다),
  • 웹소스 레벨의 필터링은 개발자의 실수가 있을 수 있기 때문이며,
  • DB에서의 권한 부여는 기본값 그대로 쓰기에는 충분히 위험하기 때문입니다.

 위에 나열한 3가지 필터링할 수 있는 부분 중에서 어느 한 곳만이라도 확실히 막기만 한다면, 웹 취약점을 이용한 공격은 생각보다 많이 막을 수 있습니다, 그 중에서 DB의 권한 제어를 위해 금지 또는 조심해야 할 확장 프로시저는 다음과 같은 형식으로 제어할 수 있습니다.

USE master
DENY  EXECUTE  ON [master].[dbo].[xp_availablemedia] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_dirtree] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_fileexist] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_fixeddrives] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_getfiledetails] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regaddmultistring] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regdeletekey] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regdeletevalue] TO [guest] CASCADE 
DENY  EXECUTE  ON [master].[dbo].[xp_regread] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regremovemultistring] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regwrite] TO [guest] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_subdirs] TO [guest] CASCADE

DENY  EXECUTE  ON [master].[dbo].[xp_availablemedia] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_dirtree] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_fileexist] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_fixeddrives] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_getfiledetails] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regaddmultistring] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regdeletekey] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regdeletevalue] TO [public] CASCADE 
DENY  EXECUTE  ON [master].[dbo].[xp_regread] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regremovemultistring] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_regwrite] TO [public] CASCADE
DENY  EXECUTE  ON [master].[dbo].[xp_subdirs] TO [public] CASCADE

USE msdb
REVOKE ALL ON dbo.mswebtasks FROM public
REVOKE EXECUTE ON sp_add_job FROM public
REVOKE EXECUTE ON sp_add_jobserver FROM public
REVOKE EXECUTE ON sp_add_jobstep FROM public
REVOKE EXECUTE ON sp_enum_dtspackages FROM public
REVOKE EXECUTE ON sp_get_dtspackage FROM public
REVOKE EXECUTE ON sp_get_sqlagent_properties FROM public
REVOKE EXECUTE ON sp_start_job FROM public

 위에 있는 쿼리는 SQL 서버에 쿼리 분석기로 연결한 후 한번 실행해주면 간단하게 할 수 있는 부분입니다만, 실제 서버에 바로 적용하면 돌이킬 없는 상황이 되버릴 수도 있습니다. 특히 스케줄 부분에 대한 확장 프로시저를 건드리기 때문에 복잡한 구성을 가진 SQL 서버라면 적용시 장애로 이어질 수도 있습니다.

 더구나, 위에 있는 쿼리를 실행한다고 해서 서버가 완벽하게 보호되는건 아닙니다. SELECT 나 UPDATE 같은 쿼리를 통해서 DB의 내용 자체를 변조하는 공격을 막을 수는 없기 때문입니다. 

 

출처 : http://www.ntfaq.co.kr/4307

Posted by 시스템매니아
,