보안정보

전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.

침해사고의 재구성 – 스팸 메일의 진실 (해결편)

2017.04.04

23,641


보안관제센터 보안분석팀 김지우

 


침해사고의 재구성은 실제 발생했던 침해사고 기록을 각색하여 한 편의 에피소드처럼 다루는 장으로 사건편과 해결편이 한 묶음이다. 
이를 통해 침해사고 발생 시 어떠한 부분은 점검하고 확인해야 하는지 침해대응 방법에 대해 다뤄보고자 한다.



1. 사건 줄거리

OO회사에 근무하는 김과장은 회사 메일계정으로 의문의 메일을 받게 되어 메일을 스팸처리 했다. 그러나 메일이 계속 수신되어 회사메일을 사용하지 못할 정도로 스팸메일을 받게 되자 회사 보안담당자인 나보안씨에게 연락을 하게 된다.
김과장은 나보안씨에게 회사차원에서 스팸메일을 처리해 달라고 요청하였고, 나보안씨는 스팸메일들을 스팸메일차단시스템을 이용해서 차단하지만 엄청난 양의 스팸메일이 발송되는 현상이 지속되었다. 
나보안씨는  혹시나 하는 마음에 메일서비스와 관련된 서비스 전반을 확인하였으나 이상한 점을 발견하지 못해 이번 사건을 단순한 스팸메일 공격으로 결론을 내리고 스팸메일차단시스템을 이용하여 차단하는 방식으로 조치하였다.


[그림 1] 사건에 대해 고민중인 나보안씨


2. 사건 재분석

TIP : 사건 재분석과정은 기술적인 이야기를 담고 있으므로 이해가 잘 안되실 경우 마지막 페이지의 문제풀이를 먼저 읽고 난 후  읽어 주시기 바랍니다.

1) 메일 헤더 분석

보통 스팸이나 바이러스 메일 등은 송신자와 수신자를 수시로 바꿔 전송되기 때문에 메일헤더를 제대로 이해하지 못하면 어디에서 전송된 메일인지 알 수 없다. 즉, 발신자의 메일 주소는 쉽게 위조할 수 있기 때문에 메일 열람 시 확인할 수 있는 메일주소가 아닌 메일 헤더 분석을 통해 메일의 전송경로를 추적해야 한다.

메일 헤더는 메일 발송자에서 시작하여 각 서버를 거쳐 최종적으로 수신자에게 오는 동안의 과정을 기록하며, 일반적으로 메일 헤더에서 가장 주목해야 할 부분은 바로 Received: from 부분이다. Received는 각각의 MTA(Mail Transfer Agent)가 릴레이(relay)를 하면서 하나씩 추가되는데, 메일 전송 경로를 추적할 때 맨 하단에서 거꾸로 하나씩 올라가면서 역추적하는 방식을 사용한다. 

헤더

정의

부연설명

To

받는 사람

수신자의 메일주소
위조가 가능하며 본인이 수신한 메일에 다른 사람의 주소가 적혀 있어도 단지 그렇게만 보일 뿐 실제로는 본인에게 전송된 메일이 맞음

From

보낸 사람

발신자의 메일 주소
위조하는 경우가 많아 신뢰할 수는 없음

Cc

참조

참조자의 메일주소

Bcc

숨은 참조

숨은 참조자의 메일주소

Subject

제목

메일 제목

Received

전송된 경로

실제로 메일이 전송된 경로를 뜻함
Received 라인이 여러 줄이 보일 때도 있고 한번 보일 때도 있는데 가장 아래쪽에 보이는 라인이 처음 메일을 발송한 곳이며 위로 올라갈수록 거쳐온 메일서버를 보여줌

Return-Path

반송 주소

발송된 메일이 반송될 때 어떤 주소로 반송될 것인지 지정하는 것인데,대개 별도로 지정하지 않으면 발신자의 메일주소가 자동입력 됨
그러나 스팸 발송자의 경우 전혀 관계없는 메일 주소를 지정하여 선의의 피해자가 발생하는 경우가 있음

Reply-To

회신 주소

수신자가 회신을 했을 때 누구에게 발송될 것인지 지정하는 것으로 대부분 별도로 지정하지 않으면 발신자의 메일주소가 자동입력 됨

Message-ID

메시지 ID

메일 서버에서 메시지를 외부로 보내며 붙이는 일련번호

Date

발송 시간

발송 시간

MIME 헤더

 

메일에 사용된 MIME Type을 표기 해주는 부분

X- 헤더

 

제 멋대로 붙인 헤더
X-’라는 문자열로 시작하는 헤더(clamav, spamassassin)

[표 1] 메일 헤더의 정의

이제 김과장이 받은 메일의 헤더를 분석해보자.



[표 2] 김과장이 받은 메일의 헤더정보

김과장이 수신한 메일의 경우 From 헤더를 통해 발송자의 전자우편 주소가 ‘Mail Delivery System '임을 알 수 있으며 그 위쪽으로 Received 헤더가 2개 존재함을 확인할 수 있다.
보통 Received 헤더의 형식은 다음과 같은데,



Received 헤더가 김과장이 받은 메일처럼 여러 개 있다면 가장 아래 있는 것이 직접 메일을 보낸 컴퓨터에 대한 정보라고 할 수 있다. 가장 아래의 Received 정보 중 'from' 정보는 발송자가 메일발송을 한 컴퓨터 IP를 뜻하며 'by’ 정보는 발송자가 메일 발송에 사용한 메일서버를 뜻한다

아래서부터 위쪽으로 Received 헤더를 해석해보면, 'from [123.123.123.123]’ 에서 'by xx1.com’ 메일서버로 메일이 수신되었고 이어서 ‘from xx1.com’ 에서 ‘by mail.test.com’로 메일이 수신되었음을 알 수 있다.
이 모든 정보를 종합해보면, ‘Mail Delivery System ‘가 ‘123.123.123.123’이라는 호스트이며 xx1.com라는 메일서버를 통해 메일을 전송하였고 mail.test.com 메일서버로 수신되었음을 의미한다. 

이는 나보안씨가 스팸메일 차단시스템에 등록한 정보와 일치함을 알 수 있다. 

IP

송신자

제목

123.123.123.123

MAILER-DAEMON@xx1.com

Mail Delivery Failure

234.234.234.234

MailMaster@xx2.com

failure notice


[표 3] 스팸메일 차단시스템에 등록된 차단패턴


그렇다면 나보안씨가 간과한 것은 무엇일까?

메일 내용을 다시 한번 살펴보면 “553 blocked Using Master Spam Pattern”라는 문구와 함께 스팸 패턴이 발견되어 차단되었으니 원인을 해결하고 싶으면 발송자의 메일 담당자에게 연락하라는 내용이 적혀져 있다. 즉, 메일은 스팸 차단에 대한 회신메일 임을 알 수 있다.



[그림 2] 김과장이 받은 메일의 본문


이럴 경우 의심해 봐야 하는 것은 2가지로 첫 번째는 사용자가 실제 스팸메일을 발송하여 발생한 회신 메일 일 경우와 두 번째는 사용자가 실제 보내지 않은 메일에 대한 ‘가짜’ 회신메일 일 경우이다. 

사용자가 스팸메일을 발송한 경우는 김과장이 스스로 스팸메일을 발송하거나 사용자 계정정보가 유출되어서 타 사용자에 의해 악의적인 목적으로 사용되었을 가능성을 말하고, ‘가짜’ 회신메일의 경우는 일반적인 스팸메일 공격으로 판단할 수 있다. ‘가짜’ 회신메일과 같은 스팸메일 공격은 나보안씨가 수행한 것과 같이 스팸메일 차단솔루션을 통해 차단하는 것이 일반적이라고 볼 수 있다. 

그러나 김과장과 같은 경우 사용자 계정을 통해 스팸메일이 발송된 경우의 수를 반드시 염두에 두고 메일과 관련된 시스템을 전반적으로 점검 한 후 이상이 없을 때 스팸메일로 판단하고 차단솔루션을 통해 조치해야 한다. 
하지만 나보안씨는 이 부분을 간과하고 스팸메일 차단솔루션을 통한 조치부터 수행하였다.




2) 보안시스템(IPS, 방화벽) 분석

나보안씨는 혹시나 하는 마음에 네트워크 구성에 따라 보안시스템과 메일서버를 조사하였지만 별다른 징후를 찾지 못하였다. 보안시스템에서 나보안씨가 간과한 부분은 무엇일까?

네트워크

명칭

IP

시스템 정보

비고

사용자 망

김과장 PC

172.16.1.10

Windows 7

 

DMZ

파일서버

192.168.1.11

Windows 2012

 

메일서버

192.168.1.12

Centos 6.4

 

Web 서버

192.168.1.13

Centos 6.4

Webtob

WAS 서버

192.168.1.14

Centos 6.4

JEUS


[표 4] 네트워크 내 시스템 정보


나보안씨가 확인한 방화벽 정책을 풀이해 보면 다음과 같다.

∙ Rule ID(31) : 사용자망(172.16.1.0/24)에서 파일서버(192.168.1.11)로의 SMB(139,445) 포트 접근 허용
∙ Rule ID(32) : 사용자망(172.16.1.0/24)에서 모든 네트워크로의 접근 불가
∙ Rule ID(33) : 모든 네트워크에서 Web 서버(192.168.1.13)로의 HTTP(80) 포트 접근 허용
∙ Rule ID(34) : 모든 네트워크에서 메일서버(192.168.1.12)로의 모든 포트 접근 허용
∙ Rule ID(35) : 모든 네트워크에서 모든 네트워크로의 모든 포트 접근 불가

이 가운데 메일서버(192.168.1.12)와 관련된 정책은 Rule ID(34) 임을 알 수 있다.

Rule ID

출발주소

도착주소

서비스

프로토콜

행위

31

172.16.1.0/24

192.168.1.11

139, 445

TCP

Allow

32

172.16.1.0/24

Any

Any

-

Deny

33

Any

192.168.1.13

80

TCP

Allow

34

Any

192.168.1.12

Any

-

Allow

35

Any

Any

Any

-

Deny


[표 5] 방화벽 정책 중 일부


보통 메일서버의 경우 모바일 연동 등을 이유로 Mail 서비스와 관련된 포트(25, 587 등)에 대해 모든 네트워크(Any)로부터 불특정 다수의 접속을 허용하는 경우는 많지만 이처럼 모든 포트(Any)에 대해 접근을 허용할 경우 불특정 다수가 Mail 서비스뿐만 아니라 시스템에서 활성화된 모든 포트에 접근이 가능할 수 있다. 


실제로 IPS 탐지 내역을 보면 외부 IP(218.49.112.67)에서 Telnet과 SSH 서비스에 대한 비인가 접근 시도가 수 차례 있었음을 확인할 수 있다. 

출발주소

도착주소

시도횟수

공격명

차단여부

218.49.112.67

192.168.1.12

3

Telnet Login Fail

O

218.49.112.67

192.168.1.12

4

Secure Shell Brute Force

O

218.49.112.67

192.168.1.12

4

Secure Shell Brute Force

O

218.49.112.67

192.168.1.12

4

Secure Shell Brute Force

O

218.49.112.67

192.168.1.12

3

Telnet Login Fail

O


[표 6] IPS 탐지로그 중 일부


IPS에서 비인가 접근 시도에 대한 탐지는 별도로 등록하지 않을 경우 기본 정책에 의해 발생하는 경우가 대부분인데 보통 오탐을 방지하기 위해 일정시간(8초~2분) 내에 3~4회 이상 반복 접근 시도 시 차단하고 이벤트가 발생하도록 임계치가 설정되어 있다. 

그런데 만약 이 규칙에 탐지되지 않을 정도로 공격을 수행한다면 어떻게 될까? 

예를 들어, 2분 내에 3회 이상 Telnet 접근 시도 시 이벤트가 발생한다고 가정했을 때 2분 동안 총 2번만 접속한다면 이벤트가 발생할까? 당연하게도 IPS에서는 이벤트가 발생하지 않는다. 그 이유는 정책 탐지기준을 만족하지 않기 때문이며 이를 근거로 산술적으로 생각해 봤을 때 1분에 1건씩 60분 동안 60번의 접속시도를 하더라도 보안시스템이 탐지하지 못한다는 이야기가 된다. 무차별 대입공격(Brute Force)은 단순하고 간단한 공격이지만 보안시스템에 탐지되지 않고 지속적으로 공격한다면 언젠가는 공격 목적을 달성할 수 있는 효과적인 공격이 될 수 있다.

그렇다면 나보안씨가 간과한 점이 IPS 정책의 임계치일까? 정답은 ‘아니다’이다.
임계치는 오탐을 방지하기 위한 최소 기준으로 설정된다. 위의 예와 같이 IPS만 운영한다면 미탐의 가능성은 있을 수 있지만 다른 보안시스템(방화벽)의 로그를 SIEM과 같은 통합보안관제시스템과 연동하여 모니터링하고 있다면 보완할 수 있다. 

문제의 근본적인 원인은 방화벽에 있다. 방화벽에서 메일 서비스와 관련된 포트만 접근을 허용하였다면 비인가 포트에 대한 접근 시도를 하지 못했을 것이기 때문이다. 이 부분은 보안시스템의 정책관리가 잘못될 경우 더 큰 문제를 야기할 수 있다는 걸 보여준다.




3) 시스템 로그 분석

마지막으로 나보안씨가 확인한 메일서버의 로그를 보면 기록된 데몬 이름을 통해 Sendmail 로그임을 알 수 있다.

 
Sendmail의 로그형식은 로그 발생시간, 호스트 이름, 데몬 정보, 메시지 필드로 나누어지며 메시지 필드는 특별한 지시자를 통해 내용을 구분하는데 지시자에 대한 정의는 아래의 표와 같다. 



지시자

정의

from

발신자 주소

size

메시지의 바이트 크기

class

메시지의 등급(우선순위), 낮을수록 우선순위가 높음

pri

시작 메시지의 우선순위 등급

nrcpts

aliasing forwarding을 고려해서 생신 수신 메시지의 개수

msgid

메시지 식별자(메시지 헤더에서 추출)

proto

수신 시 사용된 프로토콜(ESMTP or UUCP)

relay

메시지를 전달한 머신의 이름

to

콤마로 분리된 수신자 리스트

delay

메시지 발신에서 수신 시 까지 걸린 시간

xdelay

메시지 전송 시도에 걸리는 시간(일반적으로 접속시간)

mailer

메시지를 전달하는 mailer의 이름

stat

메시지의 전달 상태

ctladdr

배달물을 보낼 수 있는 자격을 가진 사용자의 이름

dsn

Delivery Status Notification의 약자로써 배달 생태 통지를 의미


[표 8] 메시지 필드 지시자

또한 메일로그를 자세히 살펴보면 시간만 다를 뿐 같은 형태의 로그가 반복됨을 알 수 있다. 


[표 9] 메일서버 로그

Sendmail 로그라는 점과 반복된 행위에 대한 로그라는 점을 알게 되었으니 이제 메일로그 중 1개를 해석해 보자. 



먼저 첫 번째 라인을 해석해 보면, “X월 0일 00시 00분 00초에 기록되었으며 메시지를 전달한 머신은 218.49.112.67이고 KIM 이라는 계정으로 PLAIN 인증하였다.”라는 뜻이 된다. 해당 라인에는 앞서 언급하지 않은 지시자(AUTH, authid, mech, bits)가 추가로 있는데 이는 아래의 그림과 같은 SMTP 서버 인증이 이루어질 때만 발생하는 메시지 필드 지시자로 따로 외울 필요는 없다.



[그림 3] SMTP 서버 인증



다음 두 번째 라인을 해석해 보면, “X월 0일 00시 00분 09초에 기록되었으며 KIM@mail.test.com 사용자가 176 byte의 메시지를 1개 보내며 메시지를 전달한 머신은 218.49.112.67 이다.”라는 뜻이 된다.


마지막 세 번째 라인을 해석해 보면, “X월 0일 00시 00분 33초에 기록되었으며 메시지를 받는 사용자는 ct@xx1.com이며 메시지를 발송하는데 걸린 시간은 32초이고 메시지 전송 시도에 걸린 시간은 25초이다. 메시지를 전달한 머신은 xx1.com [123.123.123.123]이며 정상적으로 완료되었다”라는 뜻이 된다.

이를 종합해 보면 김과장 PC(172.16.1.10)는 내부 사용자 망에 위치하고 있으므로 외부에서 누군가(김과장 본인 또는 악의적인 공격자)가 외부 IP(218.49.112.67)를 통해 메일서버(mail.test.com)에서 KIM 사용자로 인증 받았으며 이후 KIM@mail.test.com 이름으로 ct@xx1.com 에게 메일을 반복적으로 전송하였음을 확인할 수 있다. 즉, 메일을 먼저 발송한 측은 김과장 메일(KIM@mail.test.com)이며 이를 스팸으로 판단한 보안시스템에서 회신 메일을 보내오고 있는 상황임을 알 수 있다. 

나보안씨가 메일서버의 로그 분석을 좀 더 세심하게 했었다면 위의 분석과 같은 결과를 얻을 수 있었겠지만 그렇지 못했고 만약 악의적인 공격자가 메일서버에서 인증이 성공했다면 공격에 의한 정보탈취 가능성이 있기 때문에 김과장의 계정정보만 탈취된 것인지 아니면 시스템이 장악된 것인지 추가 조사했어야 했다. 





3. 문제풀이


1) 나보안씨가 내린 결론은 올바른 것일까요? 
아니요. 올바르지 않습니다.
나보안씨가 내린 결론은 단순 스팸메일 공격이었으나 메일 로그 분석결과, 김과장 메일(KIM@mail.test.com)을 누군가가 인증하여 메일을 반복 전송하고 있었고 이를 스팸으로 판단한 타 기관 보안시스템에서 회신 메일을 보내오고 있는 상황이었습니다. 이는 공격에 의한 정보탈취 가능성이 있기 때문에 김과장의 계정정보만 탈취된 것인지 아니면 시스템이 장악된 것인지 추가 조사 및 조치가 필요합니다.

2) 나보안씨가 놓친 부분이 있다면 어떤 것들이 있을까요?

나보안씨가 간과하거나 소홀했던 부분은 3가지로 다음과 같습니다.

① 사용자에 의한 스팸메일 발송 가능성
이번 사건과 같은 회신메일은 진짜와 가짜의 가능성이 있기 때문에 메일이 지속적으로 수신되고 있다면 메일서버의 사용자 계정이 악용되어 외부로 스팸메일을 발송하고 있진 않는지 점검해야 합니다.

② 방화벽의 미흡한 정책설정
메일서버 인증이 성공했다는 것은 공격에 의한 정보탈취 가능성이 있기 때문에 무차별 대입을 통해 일반사용자의 계정정보만 탈취된 것인지 아니면 시스템이 장악된 것인지 파악해야 하는데 이처럼 방화벽 정책이 Any로 열려 있다는 것은 외부에서 내부로의 접근 통로가 많다는 것이고 그만큼 많은 취약점 공격을 통해 시스템 장악도 가능할 수 있다. 이와 같은 이유로 정책설정 시에는 중복된 정책이 없는지 정책의 우선순위가 잘못되진 않았는지 주의를 기울여야 합니다. 

③ 로그 분석
로그가 남기는 정보는 장애가 발생하거나 침해 사고 발생 시 그 원인을 추적하는데 많은 도움이 됩니다. 로그에 남는 정보가 어떠한 일에 대한 기록인지 판단할 수 없다면 이는 시스템의 리소스만 낭비하는 거라 볼 수 있으므로 평소에 주기적으로 시스템 로그를 분석하여 공격을 당한 흔적이 있는지 파악할 필요가 있습니다.