‘sql 인젝션’ 태그가 포함된 글 모두 보기

MSSQL, 'sp_replwritetovarbin' 프로시저의 힙 오버플로우 취약점

2008년 12월 26일 금요일, 오후 10시 33분

최근 SK인포섹에서 발표한 자료 중에 MSSQL의 'sp_replwritetovarbin' 확장 저장 프로시저의 힙 오버플로우 취약점을 악용한 원격코드 실행(Heap Overflow Exploit)과 관련된 내용이 있었습니다.(길기도 하지…)

'오버플로우' 라는 대목에서 이미 예견하셨겠지만, 당하면 해당 서버의 최상위 권한을 탈취당합니다. -_ㅠ

제가 알기로는 마소에서는 MSSQL 2005 이하 버전에 대해서는 업데이트를 중단했습니다. 저희 회사에서도 그렇지만 아직은 그래도 MSSQL 2000을 가장 많이 사용하고 있는데… 과연 이와 관련해서 패치가 나올지 모르겠습니다. 참고로 현재 위 내용에 해당되지 않는 MSSQL 버전은 MSSQL 7.0 SP4와 MSSQL 2005 SP3, MSSQL 2008이라고 합니다.

아무튼 SK인포섹에서는 급한대로 'sp_replwritetovarbin' 확장 저장 프로시저의 퍼블릭 실행 권한을 제거하길 권고하고 있습니다.

전 일단 혹시나 몰라서 웹나이트 룰에 'sp_replwritetovarbin' 과 'replwritetovarbin' 부분만 아스키코드로 변경해서 '7265706C7772697465746F76617262696E' 를 추가해 두었습니다. 그리고 그 동안 눈덩이 처럼 쌓여있던 웹나이트 로그를 오랜만에 뒤적여 보았습니다. 동일한 또는 비슷한 공격이 있었는지 확인해 보고 싶었는데 아쉽게도 없더군요. MSRC에서도 Exploit는 웹 상에 공개되었지만 실질적인 공격은 아직 확인된 바 없다고 했었지요.

아무튼 뭔가 찝찝 합니다. 항상 그랬지만 MSSQL과 관련된 Exploit들은 SQL Injection에 힘을 실어 주니까요.

아참! 'sp_replwritetovarbin' 확장 저장 프로시저의 권한을 설정하는 방법은 아래 링크를 참고해 주세요. 제가 굳이 스샷을 찍지 않아도 되겠네요. 잘 정리 되어 있습니다. 물론 영문입니다. 하지만 그림 파일만 보신다면… 후후~ -_-…

http://blogs.technet.com/swi/archive/2008/12/22/more-information-about-the-sql-stored-procedure-vulnerability.aspx

'sp_replwritetovarbin' 확장 저장 프로시저에 대한 퍼블릭 권한을 제거하였을 경우, 대부분 별문제 없으나 업데이트 가능한 구독 설정을 가진 트랜잭션 복제를 사용할 때 문제가 생긴다고 합니다. '구독' 그리고 '트랜잭션 복제' 라고 하니 SQL 서버 두 대를 가지고 트랜젝션 로그 배포 서버와 구독 서버를 설정했던 기억이 어렴풋이 나네요.

일단 일반 SQL 유저 계정으로는 액세스가 불가능 함을 확인하였습니다. 문제는 웹소스에서 DB서버를 액세스 할 때 SA 계정을 사용하는 웹사이트들 입니다. 시한폭탄을 안고 있는 거지요.

태그: , , , ,


About Windows Security 카테고리 | 현재 등록된 댓글이 없습니다. »





웹나이트 설치 후, 반드시 해야 할 일 두 가지만…

2008년 11월 13일 목요일, 오후 3시 39분

중국발 Mass SQL 인젝션 공격이 다시 한 번 주춤하고 있습니다. 실제로 최근 들어 공격 횟수가 급격히 줄어 들고 있네요. 아마 인터넷 상에 퍼져있는 다양한 정보들의 도움으로 웹 서버와 웹 소스의 보안이 강화되었고, 이로 인해 쿠키 변조를 통한 Mass SQL 인젝션 공격도 약발이 다 되었나 봅니다.

음… 하지만 공격 횟수가 단순히 줄어 들었을 뿐이지 일련의 사태들이 완벽하게 종식된 것은 아니기 때문에 서버 관리자 분들의 꾸준한 관심과 관리에는 변함이 없어야 할 것입니다.

최근 '웹나이트'를 비롯한 웹 방화벽에 대한 관심도가 크게 향상되었음은 물론이며 윈도우즈 웹 서버에 기본적으로 웹나이트를 비롯한 웹 방화벽이 설치될 정도로 보안 의식이 강화되었다고 합니다.

사실 웹나이트 외에도 하드웨어 웹 방화벽 장비나 기타 웹 방화벽 상품들이 시중에 많이 나와 있습니다만(따지고 보면 그렇게 많은 것도 아닙니다만…) 아무래도 비용적인 부담 때문에 많은 분들이 웹나이트를 선택해서 사용하고 계신 것으로 알고 있습니다.

서론이 길었네요. 예전 글에서도 누누히 말씀 드렸지만 웹나이트는 설치보다 관리가 몇 배는 더 중요합니다. 본 글에서는 웹나이트 설치 후, 반드시 해야 할 일 중 딱 두 가지만 다시 한 번 보기 좋게 정리해 보았습니다. 도움이 되셨으면 좋겠네요~

* 본 글은 '웹나이트 2.1 버전'과 '윈도우즈 2003 스탠다드 SP2 + IIS 6' 를 기반으로 작성되었습니다.

 

1. 웹나이트 로그를 반드시 정기적으로 확인하세요.

서버 관리자의 주된 업무 중 하나인 로그 확인 및 분석! 웹나이트 역시 정기적인 또는 주기적인 로그 확인이 무엇보다 중요합니다. 웹나이트 2.X 버전부터는 별도의 로그 애널라이저(analysis.exe)가 동봉 되어 있기 때문에 단순히 텍스트 파일을 열어 확인하는 것보다는 한결 수월해졌습니다.

로그 확인의 기본은 해당 로그의 형식 파악입니다. 그럼, 웹나이트에서 남기는 로그의 형식을 알아야 겠죠? 웹나이트의 로그 형식은 다음과 같습니다.

시간 ; 웹사이트 식별자 ; 이벤트 ; 클라이언트 IP주소 ; 사용자 명 ; 이벤트와 관련된 자세한 사항

이해를 돕기 위해 실제 웹나이트 로그를 통해 구분을 나눠보겠습니다.

03:21:39 ; W3SVC1 ; OnPreprocHeaders ; ***.***.***.*** ; ; GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring ; HTTP/1.1 ;  ASPSESSIONIDAQDBDDAD=EDIAJJBAFOHJCEKKEMBNCEJD

1. 시간 : 03:21:39

2. 웹사이트 식별자 : W3SVC1

3. 이벤트 : OnPreprocHeaders

4. 클라이언트 IP주소 : ***.***.***.***

5. 사용자 명 : 내용 없음

6. 이벤트와 관련된 자세한 사항 : GET ; /test/test.asp ; id=37'%20and%20user%2Bchar(124)=0%20and%20"=' ; BLOCKED: possible SQL injection in querystring

로그 마지막에 'HTTP/1.1….' 부분은 크게 염두할 사항이 아니므로 과감히 잘라냈습니다. 위의 예제 로그를 분석해 보면 GET 방식으로 전달 받은 변수값에 SQL 인젝션 코드가 삽입되어 있어 웹나이트에 의해 클라이언트의 접근이 차단된 것임을 알 수 있습니다. 아마 URL을 직접 변조하여 SQL 인젝션을 시도했던 모양입니다…-_-;;

만일 로그 분석을 통해 공격 시도가 확인되었다면 서버 관리자는 공격자의 IP주소를 발췌하여 한국인터넷진흥원(NIDA) WHOIS 페이지(http://whois.nida.or.kr)에서 IP주소의 관리사와 관리자 그리고 제원을 확인해야 합니다.

조회된 정보를 살펴보면 하단에 네트워크 어뷰즈(Network Abuse) 담당자의 연락처와 이메일 주소를 확인하실 수 있을 겁니다. 보통 이 네트워크 어뷰즈 담당자의 이메일 주소로 귀사에서 관리하고 있는 네트워크 자원에서 SQL 인젝션 공격(또는 해킹 공격)이 접수되었다는 내용의 메일을 발송해 줍니다.

메일 내용에는 공격자의 IP주소와 해당 서버의 IP주소, 공격이 확인된 시간과 자세한 로그(웹나이트 로그에서 필요한 부분만 발췌하면 되겠죠?) 등을 반드시 동봉해 주어야 합니다.

만일 공격자의 IP주소를 국내 기관에서 관리하고 있다면 보통 처리 결과에 대한 회신이 1~2주 이내로 도착할 것입니다. 해외 기관에서 관리하고 있을 경우에는 처리 결과에 대한 구체적인 회신은 없을지라도 약 70% 이상 내부적으로 조치가 완료되니 너무 염려하지 마시구요.(참고로 해당 ISP 업체가 막장인 경우에는… 답이 없습니다.)

* 참고로 해외 기관에서 관리하고 있는 IP주소일 경우 한국인터넷진흥원 WHOIS 페이지에서 바로 조회 결과가 출력되지 않습니다. 해당 IP주소에 대한 정보 대신 조회해 볼 수 있는 해외 기관의 웹사이트 주소가 출력되는데. 해당 웹사이트로 이동하셔서 다시 한 번 IP주소에 대한 정보를 조회해 보시기 바랍니다.

이제 가장 중요한 것은 재접근 자체를 원천봉쇄 하는 것입니다. 서버 앞 단에 방화벽 장비 등이 이미 설치되어 있다면 정말 베스트겠죠?(방화벽 장비가 설치되어 있지 않다면 윈도우즈 방화벽, IPSEC, IIS 설정 등으로 차단할 수 있습니다만, 역시 방화벽 장비가 쵝오…!)

만일 로그 분석을 통해 확인된 공격자의 IP주소가 123.123.123.123 이라며 단순히 123.123.123.123 IP주소만 차단할 것이 아니라 C클래스, 즉 123.123.123.0 부터 123.123.123.255 까지 대역 자체를 차단하는 것이 좋습니다.

그 이유는 공격자의 IP주소가 해커의 손아귀에 들어간 흔히 말하는 좀비 서버의 IP주소라면 같은 세그먼트에 연결되어 있는 다른 서버 역시 좀비 서버가 되었을 가능성이 높기 때문입니다. 보통 같은 세그먼트에 연결된 서버끼리는 포트뿐만 아니라 IP 자체를 오픈해 놓는 경우가 많습니다. 포트스캐닝 프로그램만 한 번 돌려보면 손쉽게 다음 타겟을 찾을 수 있지요.

 

2. 새로운 해킹 동향에 대해 관심을 가져주세요.

어떤 분께서 이런 말씀을 하시더라구요. '보안은 곧 관심이다.' 라고요. 저는 이 말에 100배 공감합니다. 새로운 해킹 수법은 이미 그 피해 사례가 확대되기 전에 설이 풀리기 마련입니다. 물론 그 설에는 다양한 정보들이 내포되어 있습니다.

새로운 해킹 수법에 의한 피해 사례는 보통 국내 보다는 해외에서 먼저 발견되는 경우가 많습니다. 보통 일본과 미국 쪽에서 먼저 리포팅 되곤 하는데 영어의 압박이 있긴 합니다만 해석이 불가능 할 정도로 어려운 글들은 아닙니다. 사실 우리가 보안과 관련해서 사용하는 용어들도 영어가 많기 때문에 그나마 위안으로 삼으시면…-_-;;

그리고 이런 정보들이 국내 IT 보안 전문 업체나 해커들에 의해 해석되고, 분석되서 손쉽게 재가공된 정보가 검색될 때도 국내 피해 사례는 그렇게 크지 않습니다.(거의 없다고 봐도 무방할 정도로…) 늦지 않았다는 얘기지요. 이번 쿠키 변조를 통한 Mass SQL 인젝션도 그랬고, 그 이전에 Mass SQL 인젝션도 그랬습니다.

관심을 갖는다면 충분히 사전에 예방할 수 있습니다. 음… 제가 시간 날 때마다 방문하는 웹사이트 몇 군데를 소개해 드릴까 합니다.

- http://www.secureworks.com/research/threats/
- http://www.nchovy.kr/
- http://swbae.egloos.com/
- http://www.krcert.or.kr/index.jsp
- http://www.us-cert.gov

 

이상입니다. 사실 별 내용 없는 글인데… 긴 글 읽어주셔서 대단히 감사합니다. 궁금하신 사항은 댓글로 부탁 드릴게요.

그럼, 이번 주도 무사히 마무리 되길 바라며…

태그: , , , ,


About Windows Security 카테고리 | 5개의 댓글이 등록되어 있습니다. »





웹나이트의 쿼리스트링, 혹시 오해하고 계시지 않습니까?

2008년 11월 11일 화요일, 오후 5시 00분

웹나이트의 설정(Config)을 쭈욱~ 살펴보다보면 쿼리스트링(Querystring)과 관련된 항목들을 심심치 않게 발견할 수 있습니다.

쿼리스트링, 혹시 오해하고 계시지 않습니까?

 

우리는 일반적으로 'SQL쿼리'를 줄여 '쿼리'라고 부르고 있습니다. 따라서 웹나이트의 쿼리스트링을 SQL쿼리로 오인하시는 경우가 있습니다.(한때 저도…-_-)

웹나이트에서 말하는 쿼리스트링이란, HTTP 환경 상에서 도메인 또는 IP주소 뒤에 따라 붙는 부가 정보를 의미합니다. 예를 들어 'http://nice19.net/?page=2' 라는 URL을 보자면 도메인을 제외한 '?page=2'가 쿼리스트링이 되는 것이죠.

우리가 흔히 얘기하는 'GET 값', 그것 입니다.

만일, 웹나이트를 통해 SQL쿼리까지 필터링 된다면 더욱 정밀하고 치밀한 보안 계획을 세워볼 수 있겠지만, 아쉽게도 웹나이트는 SQL쿼리까지는 필터링 되지 않습니다.

웹나이트 룰을 설정하실 때 쿼리스트링은 GET 방식으로 전달되는 정보나 값 정도로 생각하시면 될 것 같습니다. SQL쿼리와는 사실 상 밀접한 관계가 없음을 알려 드립니다.

그럼, 오늘도 칼퇴 할 수 있기를…

태그: , , , ,


About Windows Security 카테고리 | 현재 등록된 댓글이 없습니다. »