올 1월달 해킹 동향 및 SQL 익젝션 복구 및 대응방안 자료이다. 모든 자료는 인터넷침해사고대응센터(http://www.krcert.or.kr)에서 발췌함 (아래 링크 다운로드 가능함)


해킹사고 항목별 자료이다. 홈페이지변조가 전월대비 140% 증가한 상태이며, 27%를 차지했다.


’09년 1월 KISA에서 처리한 해킹사고는 1,579건으로 전월(1,127건)에 비하여 40.1% 증가하였다.
- 해킹사고 항목별로 전월대비 증감을 파악한 결과, 스팸릴레이, 홈페이지변조는 각각 101.0%, 140.7%,
증가하였으며, 피싱경유지, 단순침입시도, 기타해킹은 각각 13.3%, 17.5%, 16.8% 감소한 것으로 나타났다.
- 스팸릴레이(39.1%)가 차지하는 비율이 가장 많았고, 홈페이지변조(27.0%), 기타해킹(17.5%), 단순침입
시도(12.3%) 및 피싱경유지(4.1%) 순이었다.


해킹사고를 피해 기관별 분류한 결과 개인이 67.2%로 가장 많이 차지했다.

해킹사고를 피해 기관별 분류한 결과, 기타(개인), 기업, 대학, 비영리의 순으로 나타났다. 기관별로 분류한 결과 기타(개인)이 차지하는 비율이 67.2%로 가장 높았으며 뒤를 이어 기업이 차지하는 비율이 29.0%로 나타났다.
※ 침해사고관련 IP가 ISP의 유동 IP(주로 개인용 컴퓨터)인 경우는 기타(개인)로 분류함


국내 피싱 경유지 사이트의 기관유형별 자료이다. 가장 많은 곳은 기업으로 44.6% 이다. 중요한 것은 비영리기관이 18.5% 나 차지하고 있다는 거다. 피싱 경유시 시스템에서 이용된 포트는 TCP/80 포트가 93.8% 차지했다고 한다.


국내 피싱 경유지 사이트의 기관유형별로는 기업 29건(44.6%), 비영리 12건(18.5%), 개인/기타 9건 (13.8%), 교육 5건(7.7%) 순으로 집계되었다. 홈페이지가 없거나 Whois 정보에 ISP 관리대역만 조회되는 경우인‘ISP서비스이용자’유형은 10건(15.4%)으로 나타났다.



이번 2009년 1월호 특집으로 나온 "자동화된 SQL Injection 공격을 통한 악성코드 대량 삽입사고 분석" 자료이다.

“SQL Injection 공격”은“악성 SQL문 주입공격”으로도 불리며, 홈페이지와 데이터베이스가 데이터를 주고 받을 때 적절한 입력값 검증을 하지 않아 공격자가 주입한 SQL 명령문이 실행되면서 발생한다. 이러한 SQL Injection 공격은 지금도 계속해서 지속되고 있고, 데이터베이스에 악성코드가 삽입된 사고 사례도 분석된 바 있었다.1) 그리고 과거의 SQL Injection 공격 목적이, 홈페이지의 인증우회나 내부정보 유출이었던 것과는 달리, 최근 홈페이지에 대량의 악성코드를 삽입하기 위한 목적으로 SQL Injection 공격을 사용하는 유형으로도 나타났다. 그 결과 2007년 말부터 시작되어 2008년 한 해 동안 수많은 홈페이지를 대상으로 악성코드를 대량으로 삽입하는 형태로 확산되었다. 이러한 사고의 특징으로는, 게시판 게시물 등에 악성코드가 대량으로 삽입되고 자동 삽입 스크립트를 사용하므로 손쉽게 악성코드를 대량 삽입하며, 악성코드 삽입 과정에서 데이터의 손실 또는 유실 발생 등이 있다


복구 및 대응 방안

복구방법

• 1) 데이터베이스 백업본을 사용한 복구
  침해사고가 발생하기 이전의 백업본이 있다면 그 백업본을 이용하여 복구하는 것이 가장 빠를 것이다. 그러나 실시간으로 갱신되는 데이터베이스의 특성 상 핫백업과 같이 백업도 실시간으로 이루어지고 있다면 다행이지만, 대부분의 경우 백업된 시점이후의 자료 유실이 불가피하다.
  
  
• 2) 복구 스크립트 사용
  지금까지 발견된 악성코드 삽입 사고는 아무리 많은 레코드에 악성코드가 삽입 됐더라도 특정 악성코드 유포지(URI)를 담고 있었기 때문에“UPDATE”SQL 명령문을 사용해도 충분히 복구 할 수 있다. 그러나 실제 적용 전에는 반드시 시험을 거친 후 적용해야 한다.
  
  
• 3) 일괄복구 스크립트 사용
  컬럼단위의 복구 스크립트는 복구대상 컬럼이 많은 경우, 적지 않은 시간이 필요하기 때문에 악성코드 삭제를 더 빠르게 수행하고자 한다면 일괄복구 스크립트를 참조하여 적용한다.

대응 방안

• 1) 동적 SQL사용 지양
  데이터베이스와의 연동 부분에서는 동적 SQL을 더 이상 사용하지 말고 저장 프로시저를 사용해야 한다.7) 8) 저장 프로시저를 통해 데이터베이스 연동을 구현한다면, 이미 프로시저 내부에서 입력값에 대한 자료 형 검증이 이루어진다. 또한 해당 프로시저의 내부에서만 영향을 끼치기 때문에 보안측면 에서도 더욱 더 안전하고, 성능이나 유지보수 측면에서도 대단히 효과적이다.
  
  
• 2) 안전한 웹 사이트 설계와 구현
  SQL Injection 취약점은 입력값 검증 절차 문제에 기인하므로, 개발단계에서부터 반드시 모든 입력값에 대해 적절한 검증절차를 설계하고 구현해야 한다.
  
  
• 3) 웹 서버 보안 강화
  IIS 웹 서버에서는 기본적으로 웹 서비스의 오류가 발생 할 때, 자세한 오류 메시지를 접속자에게 표시 하게 되어 있다. 그러므로 이 설정을 변경하여 공격자가 오류 메시지를 통해 유용한 정보를 수집할 수 없도록 수정해야 한다.
  
  
• 4) 웹 방화벽 활용
  윈도우즈의 IIS 환경이라면 URLScan9)이나 공개웹방화벽 WebKnight10)를 활용하여 보안수준을 향상시킬 수있다. 특히 WebKnight의 경우는 KrCERT/CC의 공개웹방화벽 안내 페이지11)에서 각종 가이드와 표준
  정책 및 기술지원도 제공 하고 있다.
  
  
• 5) 웹보안 취약점 점검
  설계와 구현에 있어서 안전한 개발 절차에 따라 개발되었더라도 존재할 수 있는 보안 문제들을 점검하고 진단 하는 과정이 필요하다.
  특히 SQL Injection의 경우는 프로그램 소스 상에서 입력값 검증이 적절히 이루어졌는지 점검(White box test) 해 보고 웹 취약점 점검 도구를 병행하여 점검(Black box test)해 본다면 더욱 더 안전한 웹 서비스 운영이 될 것
  이다.