금번 쿠키 변조를 통한 Mass SQL 인젝션 공격으로 인해 현재까지도 많은 분들이 고군분투하고 계신 것으로 알고 있다.(주변에서도 비명소리가 끊이질 않는다…-_-) 이미 침해사고가 발생하고 나서의 조치야 백업 파일로 해당 DB를 복원한다거나 삽입된 악성코드만 삭제하는 스크립트 등을 통해 어렵지 않게 처리할 수 있지만, 또 다시 Mass SQL 인젝션 유입된다면 어떻게 할 것인가?

최소한 동일한 수법으로는 침해사고가 발생하지 않도록 미리 예방 조치를 취해 두는 것이 필요하다.

 

1. 웹 방화벽 룰에 '.cn'을 등록해 보는 것은 어떨까?

---

최근 쿠키 변조를 통한 Mass SQL 인젝션으로 삽입되는 악성코드들을 쭈욱~ 살펴 본 결과, 도메인이 모두 '*.cn'이라는 공통분모를 가지고 있음을 확인하였다. 따라서 웹 방화벽 룰에 '.cn'을 등록한 후, 로그를 살펴 보는 것은 어떨까? 물론 '.cn' 뿐만 아니라 '.cn'을 아스키코드로 변환한 '2E 63 6E', '2E636E', '%2E%63%6E'도 함께 등록해 주어야 하겠다. 결론적으로 웹 방화벽 룰에 추가되어야 하는 키워드들은 다음과 같다.

- .cn
- 2E 63 6E
- 2E636E
- %2E%63%6E

정상 동작이 차단될 수 있으니 적용 직 후에는 정기적으로 웹 방화벽 로그를 확인해 주는 것이 반드시 필요하다.(솔직히 이 룰도 완벽한 차단 방법이라고는 할 수 없겠지만…)

 

2. sysobjects 테이블의 'select' 권한을 조정해 보자!

---

현재까지 공개된 Mass SQL 인젝션의 코드들을 살펴 보면 대상 DB의 세부 정보를 획득하기 위하여 sysobjects 테이블과 syscolumns 테이블을 반드시 까보기 마련이다.(이 시스템 테이블에서 획득한 정보를 토대로 대량 DB 변조가 가능해 진다.) 따라서 최소한 sysobjects 테이블의 select 권한만이라도 해제한다면 Mass SQL 인젝션에 대항하기 위한 근본적인 해결 방법 중 하나는 얻을 수 있지 않을까?

sysobjects 테이블의 select 권한을 해제하는 방법은 다음과 같다.

MSSQL 2000 시리즈의 경우, '엔터프라이즈관리자'로 DB 서버에 접속 - 해당 DB 선택 – 테이블 항목 선택 – 'sysobjects' 테이블에서 오른쪽 버튼 클릭 후, '속성' 선택 – '사용 권한' 버튼 클릭.

자, 여기까지 정상적으로 진행했다면 화면에 '개체 속성' 창이라는 것이 떠있을 것이다. 여기서 'public'에 'select' 권한이 녹색 마크와 함께 허용으로 설정되어 있는 것이 확인될텐데 이 부분을 클릭하면 아래 그림과 같이 빨간색 표시와 함께 액세스 권한이 차단된다.(여기서 한 번 더 클릭하여 권한이 아에 해제된다.)

# 말로 풀어서 설명하는게 어려워서 그렇지 직접 해보시면 어렵지 않게 처리하실 수 있을 겁니다.

MSSQL 2005 시리즈 이상의 경우, 방법은 MSSQL 2000 시리즈의 경우와 크게 다르지 않으나 'sysobjects' 테이블이 테이블 항목에 있지 않고, '뷰' – '시스템 뷰' 항목에 위치하고 있다. 이해를 돕기 위해 아래와 같이 스크린샷을 첨부한다.

# MSSQL 2008 서버에서 캡쳐한 화면입니다… 권한 해제 방법은 MSSQL 2000 시리즈의 경우와 동일하므로 큰 문제는 없을 겁니다.

그럼, 한가지 고민하게 되는 부분이 있다. 온전하게 설정되어 있는 'sysobjects' 테이블의 'select' 권한을 해제했는데 뭔가 문제가 발생할 수 있지 않을까!? 실제로 웹사이트에 DB를 연동하는 부분에 있어서는 큰 문제점이 없다. 만일 사용자가 직접 작성한 프로시저가 'sysobjects' 테이블을 참조하지 않는다면 말이다.(사실 이럴 가능성는 거의 없다고 봐도 무방하다.)

단, 사용자가 관리자로부터 발급 받은 SQL 계정으로 EM이나 쿼리분석기 등을 접속했을 때는 시스템 확장 프로시저가 정상 작동하지 않으므로 문제가 발생할 수 있다.(클라이언트들을 대상으로 호스팅 서비스 등을 제공하고 있다면 발생할 수 있는 문제다.)

즉, sysobjects 테이블의 권한 해제 설정은 별도의 계정 없이 관리자가 단독으로 DB 서버를 관리하고 있을 경우, 충분히 고려해 볼만한 사항이겠고, 만일 별도의 SQL 계정을 클라이언트에게 발급하여 DB 서버 권한의 일부분을 할당해 주고 있다면 해당 클라이언트와 협의 하에 처리하는 것이 가장 현명한 방법이 아닐까 싶다.

태그: sql injection, sql 인젝션, Webknight, 보안, 웹나이트

본 글은 2008년 10월 21일 화요일, 오후 3시 13분에 등록되었으며 About Windows Security 카테고리에 등록된 글입니다. 아울러 본 글의 댓글은 RSS 2.0으로 구독할 수 있으며 기존의 트랙백을 해제하거나 신규로 트랙백을 추가할 수 있습니다.