본문 바로가기
AhnLab 보안in

안전하게 이메일을 확인하는 방법(1)_이메일 조작

by 보안세상 2020. 4. 7.

2009.03.20

 

다양한 이메일 조작 방법과 확인 요령(상)

 

보안시스템을 무력화하는 가장 효과적인 방법 중의 하나인 이메일에 대하여 알아보도록 하자.

편리하고 빠른 커뮤니케이션의 수단으로 사용되는 이메일은 편리하긴 하지만 대신 보안 문제를 자주 일으킨다. 보안이 강화된 시스템 환경에서도 이메일과 관련된 보안사고가 빈번하게 발생하는 이유는 왜일까?

이는 편지, 소포와 같은 개인메시지 전달 시스템이 주는 아는 사람이 보냈을 것이라고 하는 무의식적 안도감에서 비롯된다. 또한 문제가 생기더라도 메시지를 타인에게 보이고 싶어하지 않기 때문이기도 하다.

메일시스템에 대한 방역 및 악의적 목적의 메일 송신을 차단하는 기법들은 많이 나와있지만 보안시스템이 갖는 치명적인 부작용인 오탐과 미탐에서 자유로울 수 없는 것이 현실이다.

*오탐(false positive): 보안제품에서 정상을 비정상으로 인식함을 의미
*미탐(false negative): 보안제품에서 비정상을 정상으로 인식함을 의미

이번 글에서는 악성코드, 피싱, 스팸 등 이메일의 부작용 등을 알아보고 이를 통하여 이메일을 열기 전 악성 이메일을 판단하고 피해갈 수 있는 방법에 대해 2회에 걸쳐 알아본다.

 

먼저 메일은 어떻게 작성되고 배달되는지 간략한 예를 통해서 보도록 하자.

 

[그림1. 명령을 통한 메일 발송법 및 수신된 메일의 예]

 

메일은 위와 같은 command 명령을 통하여도 발송할 수 있으며 보내는 사람, 받는 사람, 내용물, 우편소인(header)으로 편지와 유사하게 구성됨을 알 수 있다. (명령: telnet [mail server address] [port])

* 메일의 전송에는 메일서버간의 제어명령과 사용자의 메일데이터 부분으로 구분된다.


위 그림에서와 같이 간단한 명령만으로도 메일을 보낼 수 있기 때문에 스패머는 MTA 프로그램을 만들어서 메일을 다량의 메일을 발송할 수 있고 악성코드도 내부코드에 MTA 동작기능을 첨가하여 웜메일 등을 발송할 수 있다.

 

또한 보내는 사람의 주소, 받는 사람의 주소는 웹크롤러 등을 통하여 손쉽게 수집이 가능하며 대량의 메일 발송에 사용되거나 악성코드에 감염된 시스템의 경우 침해시스템 내에 존재하는 e-mail등의 주소를 수집하여 감염된 메일발송에 이용된다.

*메일제작명령(송신)을 대신하는 프로그램/메일서버를 MTA(Mail Transfer Agent)라고 한다.
스패머는 Mass Mailer라 불리는 MTA를 사용하여 대량의 메일을 보내며 정상적인 광고메일, DM 발송도 이러한 프로그램을 사용한다.

*웹메일서비스, 아웃룩과 같이 메일을 읽고 쓰는데 사용되는 프로그램을 MUA(Mail User Agent)라고 한다.

 

조작되는 메일의 부분에 따라 어떤 악의적 메일이 되는지 알아보자.

Case 1. 보내는 사람의 조작: 피싱, 스팸 ,악성코드 이메일
Case 2. 받는 사람의 조작: 스팸메일, DoS메일
Case 3. 제목, 내용의 조작: 스팸메일, 피싱메일, 악성코드 이메일

Case 4. 첨부파일 조작: 악성코드 이메일
Case5. 메일헤더 조작: 역추적방해 메일


이번 편에서는 메일의 기본이 되는 Case 1과 Case 2를 먼저 알아보도록 하겠다.

 

Case 1. 보내는 사람(mail from)의 조작

 

메일을 읽다 보면 보내는 사람이 친구 이름의 도용 또는 심지어 본인의 이름과 계정으로 들어오는 메일을 보고 황당하게 느껴지는 경우가 종종 있다. 이러한 메일들의 특징은 보내는 사람 부분을 쉽게 조작할 수 있기 때문이며 보내는 사람이 아는 계정인 경우 의심을 적게 한다는 점을 악용하는 경우이다.

 

그러면 어떻게 보내는 사람이 조작될 수 있을까?

[그림2. 보내는 사람의 조작부분]

 

위의 그림에 흰색으로 표시된 ‘mail from’(*From 1)은 메일서버가 전달받는 명령으로 수신된 메일에 표기되는 ‘보내는 사람’과 일치해야 한다. 하지만 우측과 같이 메일을 볼 때 표기되는 부분은 아래의 ‘From:’(*From 2)에 기재된 내용으로 메일의 헤더를 보지 않고는 판단하기 어렵게 된다. 이에 따라 발신자 ’포스트잇’ postit@spammerl.cox(*From 1)이 보낸 메일은 ‘유성펜’이라는 받는 사람에게는 친근한 ‘지우개’로 표기되며 회신주소 역시 eraser@stationery.cox(*From 2)으로 변조된 상태로 사용자를 속이게 된다.

이는 메일발송의 구조가 header를 구성하는 송/수신 관련 명령과 mail의 내용부분(위 그림에서의 data 명령 뒷부분)이 분리되어 있기 때문에 발생하게 된다.

(* From 1은 서버가 인식하는 데이터, *From 2는 사용자에게 보여주는 데이터가 된다.)

 

이는 편지의 겉봉투에 써진 주소와 실제 내용물에 써진 사람은 다를 수 있다는 것과 같다고 볼 수 있다.

 

[그림 3. 메일의 헤더보기]



위 예제에서 볼수 있듯, ‘보내는 사람’을 신뢰하기 어려운 경우 다음과 같이 메일의 헤더를 확인할 수 있다.

* 아웃룩에서는 ‘파일’->’속성’->’자세히’를 선택, 기타 메일서비스의 경우 ‘헤더보기기능’을 이용

 

확인할 부분:
- ‘Received: from’의 주소가 신뢰할 수 있는 주소인지 확인 한다.
- ‘x-mail-from’의 주소가 자신이 알고 있는 e-mail 주소인지 여부 및 회송이 가능한지 확인 한다.

*그림 3에서 보내는 사람은 spammer.cox(*From 1,From 2)에서 발송하고 있으며 stationery.cox의 이메일 계정(From 3)에서 보낸 것으로 조작되어 있다.

또한 개인메일방역, 스팸 차단프로그램을 사용하도록 하며 웹메일에 접속하여 읽는 경우 주의를 기울여야 한다.

*이러한 경우를 차단하기 위하여 메일서버에는 실제 존재하는 계정인지 체크하는 방식 또는 [ID]@[domain] 중 [domain]의 IP 주소와 메일서버에 접속한 세션의 주소가 일치하는지 체크하는 reverse lookup 기법 등이 있다.

 

Case 2. 받는 사람(rcpt to)의 조작

 

다량의 웜메일 또는 스팸메일이 유입 될 때는 특정회사 전체에 들어오게 되는 경우가 많이 있다. 또한 받는 사람을 자세히 보면 일련의 규칙을 가지고 있는 것을 본적이 있을 것 이다. 주로 스팸메일에서 사용되는 방식으로 특정 도메인의 주소에 무작위로 생성된 ‘받는 사람’ID를 붙이는 방식으로 다음과 유사한 방식으로 전달되게 된다.
 

[그림4. 다중 수신자 및 ‘받는사람’의 조작]



위 그림에서 보면 ‘받는 사람’ 명령 부분에 세 명에게 보내는 명령(rcpt to)이 사용되었고 메일에도 세 명의 규칙적인 수신자가 표기 되었다. 이러한 무작위로 생성된 ID는 생성시 원하는 ID가 이미 존재하는 경우 생일, 좋아하는 숫자 등을 붙여서 생성하는 부분을 응용한 부분도 있다.

 

또한 한 통의 메일로도 대수의 ‘받는 사람’을 생성할 수 있으므로 메일시스템의 부하를 유발하는 DoS메일 공격에도 악용될 수 있다.

 

이렇게 되어 어머니로 가장한 스패머는 삼형제 모두에게 메일을 보낼 수 있게 되었다.

 

 

확인할 부분:
-그룹메일이 아닌 경우 함께 받는 수신자가 정상인지 확인한다.
-수신자가 다수일 경우 a01@x.com, a02@x.com, a03@x.com과 같이 임의로 생성된 경우인지 확인한다.

* 이러한 경우를 차단하기 위하여 메일서버에는 특정 IP에서 한번에 규정치 이상의 메일이 전달되게 되면 차단하는 방법으로 차단하는 기법을 사용한다. 또한 메일 header의 rcpt to가 규정치 이상인 경우도 검출하는 방법을 사용한다.

* rcpt to는 PIPELINE 명령을 제공하는 경우 쉽게 악용되며 각각의 rcpt to를 체크하여 다른 도메인으로 발송하여야 하는 ‘받는사람’ 계정이 존재하는 경우 relay deny를 시키는 방법이 존재한다.

 

다음 편에서는 나머지 케이스를 실제 전달되는 메일서버(SMTP/POP3)의 내부 동작을 통하여 알아보도록 하겠다.@

 

칼럼니스트

안형봉 | 안철수연구소 엔진QA

 

안철수연구소의 시큐리티대응센터에서 엔진QA를 담당하며 병렬테스트시스템, 컨텐츠배포네트워크시스템(CDN) 개발을 진행하고 있다. 현재 "안랩 칼럼리스트"로 활동하며, 일반인들에게 보안 사건, 사고의 원인을 네트워크단에서 해석한다. 최악의 네트워크상태인 곳에서도 안정성과 속도가 유지되는 배포시스템을 설계하는 아키텍트가 되는 것이 목표로 하고 있다. 많은 실무 경험을 통해 학생들에게 보다 생생한 교육을 할 수 있는 날을 준비하고 있다.