웹사이트 변조 해킹의 방어에 대한 약간의 팁...

최근 여기저기에서 2005년의 악몽이 떠오르는 듯 합니다. WebKnight를 부랴부랴 설치하고 점검을 하는 등 많은 대책을 하고 있지만, 일부 시스템은 이미 설치해도 늦은 것으로 예상됩니다.

 2005년의 웹공격은 "SQL Injection -> SQL서버에서 웹서버 콘트롤 -> 웹사이트에 변조 페이지 심기"이란 순서로 이뤄졌습니다만, 이번의 공격은 조금 더 세밀하고 콘트롤하기 어렵습니다. 과거 2005년도에 이용했던 방법 이외에 중간중간의 루트로 몇가지가 더 추가되었습니다. 정리하니 다음과 같은 부분들이 되는군요.


1. 원격 툴의 설치 부분

역대 대부분의 원격 툴은 특정 프로그램(예:servany.exe로 nc.exe를 등록)을 서비스에 등록되는 것이 일반적이였습니다. 그러나 최근의 형태는 서비스에 등록시키지 않습니다. 드라이버로 설치시킵니다. 얼마전 바이러스나 스파이웨어가 루트킷의 형태를 띠어가고 있다는 내용이 해킹의 현실화된 방법으로 등장하고 있습니다.

참고자료 : 루트킷을 공격 루트로 가지는 강력한 Storm 웜 정보

 문제는 이러한 툴이 설치되면 어지간한 백신으로는 처리가 불가능하며, 설치된 이후에는 완벽하게 알아내기 전에 제거도 불가능하며, 관리자가 직접 발견해서 지워야 하지만, 발견은 현실적으로 대단한 난이도를 가진 작업입니다.

해결책 :
다음 폴더를 점검해보시기 바랍니다.

• C:\WINDOWS\system32
• C:\WINDOWS\system32\dllcache
• C:\WINDOWS\system32\drivers
• C:\WINDOWS\system32\wbem
• C:\WINDOWS\system32\spool\drivers

2. 페이지 변조 부분

 1번에서 언급한 원격 툴의 경우는 그래도 (어디까지나) 운이 좋다면 발견해서 지울 수 있습니다. 하지만, 한번 당하면 페이지의 변조는 계속 발생합니다. 잘 보면, 특정 주기를 갖고, 특정 서비스와 연동되어 보이며, 외부의 어떤 접속도 없는데도 불구하고 페이지의 변조가 발생합니다. (대부분의 경우 랜선을 뽑아도 변조가 됩니다)
 
 이러한 경우를 대부분이 윈도우의 특수 폴더에 해당 소스가 위치하고 있습니다. 이 폴더들은 탐색기에서는 모든 내용을 잘 보여주지 않습니다. 이는 윈도우에서 레지스트리 수정을 통해 제한적으로 보여주기 때문이며, 이를 완전히 보기 위해서는 명령 프롬프트(cmd.exe)를 이용해야 합니다.

해결책 :
다음 폴더를 점검해보시기 바랍니다.

• C:\WINDOWS\Fonts
• C:\WINDOWS\Tasks
• C:\Documents and Settings\NetworkService\Local Settings\Temp
• C:\Documents and Settings\LocalService\Local Settings\Temp
  
• 웹서버에 웹가드의 설치 (다운로드 : http://www.viruschaser.com/main/customer/VCArchive_Dt.jsp?no=410&vno=23&stype=&scon=&page=3&noticeType=D)

* 참고 :  웹가드의 경우 과거의 단순 해킹으로 인한 변조에는 대응하기란 상당히 효과적이였지만, 현재의 루트킷 수준의 툴이 적용된 이후에는 어느 프로세스가 접근했다는 아주 간단한 기록을 남기는데에만 도움을 줍니다.

3. 네트워크 점검 부분

 대부분의 경우 윈도우의 보안패치는 다 올라가 있으며, 네트워크 단에 방화벽이 하나 있습니다. 하지만, 서버와 서버 끼리는 모든 통신이 다 가능한 것이 대부분입니다. 따라서 숙주가 되는 메인 서버를 분리해내는 작업이 필요하며, 이 작업은 윈도우 방화벽과 같은 어플리케이션으로 사용할 수 있는 프로그램을 사용하셔야 합니다.

해결책 :

• 별도의 응용 프로그램으로의 방화벽 설치
• 보안 업데이트 및 내부의 보안 설정 강화
• 회사 내부와 서버의 통신 부분의 분리

4. 정상적인 접근의 방어

 과거의 SQL Injection이 주로 Querystring의 변조에 의해 이뤄졌다면, 현재는 Cookie를 통한 SQL Injection과 병합한 공격이 주를 이루고 있습니다. 따라서, 보다 강력한 필터링 적용이 필요한 시점입니다. 심각한 경우 SSL을 통해 이뤄지므로(OpenSSL을 사용하는 경우에 해당됩니다) IDS에서도 이를 발견하기란 매우 어려운 것이 실정입니다.

 이에 따라 WebKnight를 적용한다 할지라도 WebKnight의 기본 설정만으로는 조금 부족한 면이 있습니다.

해결책 : 

• Cookie SQL Injection 필터링 강화
• SQL 서버에서 사용하지 않는 모든 Stored Procedure를 사용금지로 변경
• SQL 서버와 통신상 웹서버의 분리

 대충 이 정도로 정리가 가능합니다만, 실제로 이러한 모든 부분을 찾기란 쉽지 않습니다. 더구나 대부분 제로데이웜과 유사하게 사이트마다 적용한 방법이 다르므로 조금 고생을 많이 하셔야 할겁니다. 또한 변조된 파일의 날짜와 시간은 이미 얼마든지 다를 수 있게 할 수 있으므로, 반드시 모든 파일, 모든 시스템을 점검하시기 바랍니다.

 위의 과정을 거쳐도 모든 것이 다 해결되는 것은 아니지만, 그래도 잠시나마 대처할 수 있는 시간을 버는데에는 도움이 됩니다.

http://ntfaq.co.kr/3925