모니터랩 특수사업본부 윤필용 차장   최근 스마트폰의 높은 보급률로 인해 남녀노소 쉽게 인터넷을 이용하는 시대가 도래했습니다. 인터넷만 된다면 웹이나 앱을 통해 배달, 쇼핑, 뱅킹 등을 간편하고 손쉽게 접할 수 있는 것입니다. 하지만, 이러한 편리함 뒷면에는 해킹이라는 어두운 부분 또한 존재합니다. 이에, 웹 침해사고가 발생했을 때 분석하는 방법 및 조치방안에 대해 알아보도록 하겠습니다.   – 목차 – 1. 개요 2. 분석절차 3. 조치방안

개요

웹 서버의 경우 대외적으로 서비스를 제공해야 하기 때문에, 관련 프로토콜인 HTTP, HTTPS의  80, 443 포트로 서비스를 합니다. 이에, 네트워크 보안 인프라 차원에서는 최상단에 방화벽을 도입하여, 내부로 유입되는 인바운드 정책에 80, 443만 허용하고 그 외의 포트는 차단하도록 설정 및 운영하는 것이 일반적입니다.

이처럼, 웹 서비스 포트들이 외부에 열려있기 때문에 해커들은 방화벽에서 허용되어 있는 웹을 통해 취약점을 찾아서 공격하기 시작하였습니다. 해커의 공격목적은 시기별로 변화하고 있는데, 인터넷이 활성화되기 전인 2000년도 초반만 하더라도 해커 개개인의 과시 용도였으나, 근래의 해킹사례를 보면 개인정보유출, 랜섬웨어 등과 같이 금전적인 이득으로의 변모하고 있는 추세입니다. 아래는 최근 이슈가 되었던 해킹 사고들 입니다.

• 옥션 해킹 사건 (2008년 02월)
  • 피해 규모 : 1,000만 건 이상의 개인 정보 유출
  • 웹을 통해 웹 서버 해킹 후 DB 서버에 접속하여 개인 정보 유출
• 네이트 (SK컴즈) 해킹 사건 (2011년 07월)
  • 피해 규모: 3,500만 건 이상의 개인 정보 유출
  • 알집 업데이트 서버 해킹으로 해당 웹을 통해 내부 PC가 감염됨
    -> 감염된 내부 PC로부터 DB 서버 접속이 이루어져 개인 정보 유출
• EBS 해킹 사건 (2012년 05월)
  • 피해 규모: 200만 건 이상의 개인 정보 유출
  • 웹사이트 게시판 취약점을 통한 웹 서버 해킹 (웹을 통한 웹쉘 업로드) 공격으로 밝혀짐
• 20 사이버 테러 (2013년 03월)
  • 피해 규모: 악성 코드에 의한 주요 금융/언론사의 기업 내부 시스템 파괴
  • 웹사이트 게시판 취약성을 이용한 웹 서버 해킹으로 1차 및 2차 C&C(명령제어) 서버를 확보
    -> 동시에 악성코드를 통해 목표 기업의 내부 PC를 감염 시킴
    -> C&C 서버를 통해 감염시킨 내부 PC에 내부 정보 수집을 위한 추가 악성코드를 배포
    -> 업데이트 관리서버를 감염시켜 파괴. 악성코드를 배포하여 기업 내부 시스템을 파괴함

위 사례 모두 웹을 통한 침해사고였습니다. 이와 관련하여 금융감독원에서는 개인 정보의 보호 조치 기준을 권고가 아닌 의무사항으로 구체화하고 있으며, 기준 위반 시 법률에 따른 형사처벌이나 행정 처분이 부과될 수 있도록 개인정보 보호법을 개정하였습니다.

2012년에 고지된 개정판 해설서에서는 웹방화벽을 직접적으로 언급하여 침입 차단/탐지 시스템 도입의 필요성을 강조하고 있습니다. 아래는 관련 법률 조항입니다.

웹을 통한 침해사고 유형에는 여러 가지가 있으나, 해당 시간에는 2가지 유형(웹쉘업로드, 악성코드삽입)에 대해서 다뤄보도록 하겠습니다. 언급되는 웹방화벽의 경우 자사에서 공급하고 있는 AIWAF를 기준으로 작성하였습니다.

2. 분석절차

침해사고 발생 시, 관련 데이터 및 정보 수집을 통해 침해원인을 분석 하는 것이 중요합니다.

언제 어떻게 침해사고를 당했나요?

• 정보 및 데이터 수집
• 고객 및 관련자와의 협의를 통해 육하원칙에 해당하는 정보 수집
  • 침해 파일 수집
  • 침해 당한 서버정보( IP / OS / 어플리케이션 )
  • 침해 당한 도메인 및 URL 정보( www.monitorapp.com, index.html )
  • 과거 유사 사례 여부
  • 웹 로그
  • OS 이벤트로그···

• WAF 정보 수집
  • 최근 한달 간 로그 수집
  • 보호대상 웹서버 리스트 내보내기
  • 감사로그 내 SW/HW Bypass 정보 확인
  • GUI를 통해 해당 기간 시스템 로그 수집
• 웹 서버와 WAF의 시간 정보에 대해 확인

수집된 정보 및 데이터 기반으로 분석 진행

WAF로그 및 웹 로그에 의심되는 로그가 없을 경우

• 정말 웹으로 공격이 들어 왔는가?
  • 로그가 없다, 의심할 것도 없다.
  • 해커가 로그를 삭제했는가? WAF 로그도?
• 침해사고는 다양한 통로가 있으므로 다른 경로를 확인할 수 있도록 고객 및 관련자에게 가이드 해야 한다.

1. ex) 감염된 개발자 PC / FTP 서비스 / 파일 공유 서비스··

• 재 공격 가능성이 있다면 웹으로 공격이 들어오는지 검증 하기
  • WAF 상단의 네트워크에 탭 스위치 or S/W 미러링을 통해 패킷덤프 서버 임시 구축
  • WAF 정책 보안도 강화 및 웹 로깅 강화

3. 조치 방안

먼저, WAF에서 차단할 수 있는 부분과 어플리케이션 취약점에 대해서의 구분이 필요합니다. 아래는 파라미터 검증이 취약한 사이트의 예시이며, 이 경우 권한 없는 사용자 이더라도 값만 바꾸게 되면 타인의 게시글을 삭제할 수 있습니다.

이 예시의 경우에는 보안장비 기준으로는 정상요청이기 때문에, 차단하지 않고 웹 어플리케이션까지 도달하게 됩니다. 즉, 보안장비가 아닌, 웹 어플리케이션에서의 인증관련 시큐어코딩을 해줘야만 조치가 가능한 부분입니다.

아래는, 잘 알려진 공격형태 몇 가지에 대해 웹서버 및 WAF에서의 조치 방안에 대해서 다뤄보겠습니다.

• A1:2017-Injection (인젝션)

웹 애플리케이션에 강제로 SQL 구문을 삽입하여 내부 데이터베이스의 데이터를 유출, 변조 가능하며, 관리자 인증을 우회할 수도 있습니다. 먼저 공격자는 웹 애플리케이션이 데이터베이스로 전달하는 인자를 찾아냅니다. 악의적인 SQL 명령어를 주의 깊게 인자로 삽입하여, 공격자는 웹 애플리케이션이 악의적인 질의를 데이터베이스로 전달하도록 조작할 수 있습니다. 이 공격 기법은 수행하기 어렵지 않으며 해당 취약점을 찾아주는 다양한 툴들이 지속적으로 발전해나가고 있습니다.

• 어플리케이션 내의 대응 방안
  • 웹 서버나 웹 애플리케이션에서 입력값 검증을 수행하여 악의적인 구문 삽입을 방지할 수 있습니다. 웹 애플리케이션이 해당 기능을 수행하는데 필요한 권한 이상으로 권한을 갖지 않도록 설정합니다.
  • 파라미터에 쿼리가 보이지 않도록 내부 어플리케이션을 구현하여야 합니다.
• WAF 대응 방안
  • SQL 인젝션 정책에 대해, 예외처리는 최소한으로 유지하고 차단모드로 운영합니다.
  • 패턴업데이트는 항시 최신버전으로 업데이트하여 운영합니다.

• A3:2017-Sensitive Data Exposure (민간한 데이터 노출)

다수의 웹 어플리케이션과 API는 금융, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않습니다. 해커는 신용카드 사기, 신분 도용, 개인정보 매매 등과 같은 악의적인 행위를 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있습니다. 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으므로 이에 대한 조치가 반드시 필요합니다.

• 어플리케이션 내의 대응 방안
  • 주민 등록번호, 외국인등록번호, 카드번호, 사업자등록번호, 법인등록번호, 전화번호, 이메일, 은행계좌번호 양식, 주소와 같은 개인정보가 유출되는 것을 발견하면 페이지 전체를 차단하거나, 개인정보 부분의 일부만 가려서 출력할 수 있습니다. 특수한 목적으로 개인정보가 필요할 경우에는 주의하여야 합니다.
  • 정보통신법이 변경되었음에 따라, 개인정보에 대해서 암호화를 진행 하셔야 합니다.
• WAF 대응 방안
  • 개인정보에 대해서, 부득이 하게 외부로 노출 시, 특정 자릿수가 노출되지 않도록 설정 하셔야 합니다.
  • SSL 등록 시, 복호화 기능이 지원됨에 따라, 동일하게 개인정보 노출을 방지할 수 있습니다.

• A5:2017-Broken Access Control (취약한 접근 통제)

각 기능별로 사용자에 대한 권한을 부여해야 합니다. 만약 제한이 제대로 적용되어 있지 않을 경우, 해커는 이 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있습니다.

• 어플리케이션 내의 대응 방안
  • 대외 오픈 자원을 제외하고 기본 정책은 차단으로 운영해야 합니다.
  • 특정 사용자에게 권한을 허용하기 보다는, 소유자만 권한을 갖게 해야 합니다.
  • 웹 서버 상의 디렉토리 리스팅 기능을 비활성화 하고 중요데이터 나 백업파일들이 웹 루트에 존재하지 않게 운영해야 합니다.
  • 접근통제에 실패한 경우 로깅해야 하고, 반복적으로 실패할 경우 관리자에게 알림이 전송되어야 합니다.
• WAF 대응 방안
  • 메소드는 GET, POST만 사용하도록 설정하되, WebDAV 이용 시, 해당 도메인에 대해서만 최소한으로 허용하도록 설정합니다.
  • 디렉토리 접근, 리스팅 시도에 대해 차단하도록 설정합니다.
  • 요청 확장자에 대한 Positive/Negative 정책을 세워서, 불필요한 요청 시도에 대해 차단하도록 설정합니다.