자신이 담당한 제품이 MS-SQL을 사용하는 사람은 자알 읽어보시고,
다른 DB를 사용하고 있다면 대충 읽어보시고,
DB랑 전혀 상관없는 분들은 그냥 넘어가시길. ^^
MS-SQL 에서 사용되는 시스템 SP 중에 xp_cmdshell 이라는 녀석이 있습니다.
Windows의 shell command를 실행해 주는 sp 입니다.
그 기능이 워낙에 강력해서 예전에 SQL-Injection 으로 자주 애용되는 넘이라고 합니다.
MS-SQL 2000 당시에는 해당 sp를 이용하여 query를 만들어서 전송하면
Windows 계정을 생성할 수 있는 취약성이 발견되어 난리가 났었다는군요.
간단하게는 취약한 웹사이트에 들어가서, 아이디 란에 xp_cmdshell' 을 이용한 쿼리를 생성해서
로그인을 시도해 주면 알아서 관리자 권한의 아이디를 만들어 낼 수도 있었다는 겁니다.
관리자 권한의 아이디 하나 만들고 나면, 그 사이트는 나리가 났겠지요.
그후 MS 에서는 xp_cmdshell 등의 시스템 SP를 sysadmin 권한을 가진 계정에게만 허용하도록
제한을 걸어서 이 문제를 보완한 것 같습니다.
xp_cmdshell 에 대한 취약성을 이래저래 테스트를 하다보니
저희 제품에서도 비슷한 보안 이슈가 내재하고 있음을 알게 되었습니다.
그 이유는 제품이 사용하는 DB 계정을 'sa'로 기본적으로 사용하고 있었기 때문입니다.
즉, 뷰어에서 요청되는 모든 쿼리들은 sa 권한(sysadmin)으로 실행된다는 얘기입니다.
각종 검색이나 설정 항목 중에서 유효성 검사가 정확히 이뤄지지 않는 항목에서는
여지없이 불충한 쿼리를 만들어서 서버 시스템을 유린할 수 있는 이슈가 있는 것이지요.
문제 제품의 경우에는 우선적으로 로그인 화면이 문제가 되었습니다.
뷰어를 실행하면 로그인 창이 나오는데, 계정 입력시 Key-Down 이벤트에서
특수 문자가 입력되지 않도록 잘 막고 있었습니다.
그런데, 문제는 Ctrl+V 에 대한 처리는 하지 않았다는 것입니다.
아이디 란에 다음 내용을 복사해서 Ctrl+V 합니다.
';exec xp_cmdshell 'del c:\temp\*';--
그리고 그대로 로그인을 시도하면, 해당 아이디는 서버로 전달되고
서버에서 쿼리로 만들어져서 DB에 요청합니다.
예를 들어, 대충 이런 쿼리가 만들어 진다고 칩시다.
select * from tbUser where id='admin';
제가 위에서 입력한 내용을 대응해 보면 심각해 집니다.
select * from tbUser where id='';exec xp_cmdshell 'del c:\temp\*';--';
공란의 id를 공란으로 쿼리한 이후에, xp_cmdshell을 이용해서 c:\ 파일을 삭제하라는
쿼리가 들어간 것입니다!! 뜨악!
이 문제는 로그인 화면 만이 아니라 제품 내부에서 다양하게 악용될 수 있습니다.
예를 들면, read-only 권한의 사람이 들어가서 각종 설정이나 검색 항목에
악의적인 쿼리를 포함할 수 있게 되지요.
물론 유효성 검사가 완벽하다면 예외이긴 합니다만, 어찌 개발자가 완벽을 장담할 수 있겠습니까. ㅠ.ㅜ
이 문제를 원천적으로 막기 위해서
제품이 사용하는 DB 계정에는 sysadmin 권한을 가지지 않도록 주의해야 합니다.
(dbcreator, bulkadmin 권한 정도)
또한 필요하다면 제품 로그인 계정별로 다른 권한의 DB 계정을 사용하도록 해야 할 것입니다.
이건 좀 복잡도가 높나요?
주절주절 글이 길어졌습니다. 필요한 사람들만 알아서 들을지어다. --a
- 2011.10.19 Joshua95
'Programming > Database' 카테고리의 다른 글
DB별 Top N 얻어오기 (0) | 2011.11.29 |
---|---|
[MSSQL] DISTINCT와 GROUP BY의 차이 (4) | 2011.10.21 |
[DB2] DB 백업/복원 관련 커맨드 (0) | 2011.09.20 |
[MSSQL] DB 데이터를 text 파일로 보내기 (2) | 2011.07.19 |
[DB2] 명령편집기에서 db2admin 없이 쿼리하기 (0) | 2011.06.08 |
댓글