본문 바로가기
Previous Research

메일 클라이언트 보안의 이모저모

by _Jay_ 2021. 12. 8.
반응형

2018년부터 미들웨어 전문 기업에 입사한 후 꽤 오랜 시간 동안 메일 클라이언트 개발 부서에서 일을 하였다. 팀에 들어온 후로 메일 클라이언트에서 네트워크나 DB와 관련된 주 기능인 아닌 스펙 문서가 존재하지 않는 바이너리 호환 업무를 맡아서 해왔었기 때문에 그 전까지는 기술적으로 딱히 쓸만한 글이 없었는데, 코로나 사태 이후 랜섬웨어 같은 악성코드가 메일을 통해 감염되는 등 보안 문제가 부각되기 시작하면서 개발 중이었던 메일 클라이언트에도 보안 기능이 필요하다고 본부에 제안을 했고, 해당 기능의 필요성을 인정받아 이에 대한 연구 개발을 하게 되었다.

보통 제품을 개발하는데 있어서 특정 기능을 추가하기 위해 가장 첫 번째로 수행하는 일은, 제품을 개발하는데 참고하는 레퍼런스 제품들이 실제로 해당 기능을 어떤 방식으로 수행하고 있는지 분석하는 것이다. 물론 오픈소스가 아닌 이상 블랙박스 형태로 분석을 진행하기 때문에 내부 구현 등은 대강 짐작할 수 밖에 없고, 설계 단계에서도 제품에 구현된 기존 기능에 영향을 미치지 않도록 해야하기 때문에 대부분의 경우 분석과 설계 단계에 가장 많은 시간을 할애한다.

메일 클라이언트의 여러 보안 기능들 중 첫 번째로 타겟을 잡은 것은, 메일의 첨부파일 내 악성코드를 차단하는 기능으로 다른 제품들은 이 기능을 어떤 방식으로 제공하고 있는지 분석하였다. 메일 클라이언트에서 가장 대표 레퍼런스 제품은 아웃룩이며, 다른 메일 클라이언트인 썬더버드 외에도 네이버나 구글 등의 메일 서버들도 분석을 같이 진행했다.

일단 배경 지식으로 메일 클라이언트와 메일 서버가 어떻게 다른지 모르는 분들을 위해 간단히 설명하자면, 우리가 보통 네이버나 구글 사이트에 로그인해서 사용하고 있는 메일들은 네이버 또는 구글에 존재하는 자체 메일 서버를 이용한다. 이러한 메일 서버를 통해 메일을 주고 받으며, 우리가 웹 브라우저에서 보는 메일들은 회사의 서버에 존재한다고 생각하면 되는데 보통 웹 메일이라고 부르는 것들이 이런 방식이다.

만약 메일 데이터를 회사의 메일 서버가 아닌 자신의 컴퓨터에 저장해서 보고 싶을 때 사용하는 것이 메일 클라이언트인데, 대표적으로 아웃룩이 있으며 네이버 메일 서버에서 메일 클라이언트로 프로토콜을 통해 메일 데이터를 가져올 수 있다. 네트워크를 공부할 때 배우는 SMTP, IMAP, POP3 등의 프로토콜이 여기에 사용된다고 보면 된다. 우리가 보통 사용하는 네이버나 구글의 웹 메일도 있지만, 거의 모든 기업에서는 자체적으로 메일 서버를 구축하여 사용하고 있고, 메일을 웹 브라우저에 접속하지 않고 편리하게 보기 위해 메일 클라이언트에 메일 계정을 연결하여 사용할 수 있다.

 

메일 클라이언트의 대표적인 제품인 아웃룩(Outlook)

 

일반적으로 네이버나 구글 같은 기업은 보안이 워낙 잘되어있기 때문에 대체적으로 exe 파일이나 문서 악성코드에 대해서는 자동으로 차단을 해주고 있다. 아마 자체 개발하거나 특정한 보안 업체의 메일 보안 솔루션을 사용한 것으로 보이는데, 왠만한 중견 및 대기업에서는 대부분 이런 방식으로 메일 서버를 연동하여 구축한다. 하지만 보안까지 신경 쓸 여력이 없는 벤처 및 중소기업에서는 보안 기능이 적용되지 않은 메일 서버를 구축하고 사용하게 되는데 이런 기업이 특히나 악성코드에 쉽게 노출이 될 수 있다.

물론 임직원 PC에 V3나 알약 같은 기본적인 백신 엔진을 설치했다고 할지라도, 최근 악성코드가 기하급수적으로 늘어가고 있고 단순 실행파일형 악성코드가 아닌 매크로를 이용한 문서 악성코드가 유행함에 따라 단순히 엔드포인트에 설치되는 백신만으로는 한계가 있다. 백신 엔진만으로 왜 한계가 있는지 자세한 내용은 다음에 설명하기로 하고, 보안 기능이 적용되지 않은 취약한 메일 서버를 메일 클라이언트에 연결하여 사용했을 때는 무슨 문제가 있는지 설명하겠다.

기업에서 사용하는 메일 서버의 경우 대개 사내에서 업무를 위해 사용되고 있지만 외부에서 메일을 받는 경우도 종종 있는데, 보안 기능이 적용되지 않아 악성코드를 차단할 수 없다면 사용자 시스템은 그대로 감염될 수 밖에 없다. 일단 보안 기능이 적용되지 않은 사내 메일 서버를 사용함으로써 인해 감염이 되는 상황은 논외로 하고, 사내 메일을 집 PC에서 메일 클라이언트로 연결하여 사용하는 시나리오를 생각해보자. 메일 클라이언트의 경우 여러 메일 서버를 연결하여 사용할 수 있는데, 사내 메일 외에도 위에서 언급한 네이버, 구글 같은 메일 서버도 연결하여 사용이 가능하다.

네이버나 구글 메일 서버의 보안이 아무리 잘되어 있어서 해당 메일 서버로 오는 악성코드는 다 막을 수 있다고 하더라도, 보안이 취약한 사내 메일 서버로 오는 악성코드는 막을 수 없어서 해당 메일 클라이언트를 사용하는 PC는 그대로 악성코드에 감염된다. 즉, 아무리 다른 메일 서버의 보안이 좋다 한들 사내 메일 서버 때문에 보안의 수준이 낮아지는 것이다. 여러 메일 서버를 연결하여 사용하는 메일 클라이언트의 특성상 동일한 보안 수준을 제공해야한다고 생각하게 되었고, 이 아이디어를 바탕으로 연구를 진행하였다.

 

보통 메일 클라이언트 보안이라고 하면 대부분 OpenPGP를 이용한 암호화 메일이나 전자서명을 떠올릴텐데, 주로 내가 연구했던 것은 어떻게 메일로 전파되는 악성코드를 효과적으로 차단할 수 있을지에 대한 관점이었다. 사실 연구를 진행하면서 메일 클라이언트 보안에 자체보다는 랜섬웨어나 문서형 악성코드 구조를 더 많이 공부하게 되었는데, 처음 보안에 발을 들이게 된 것도 악성코드 때문이었다. 하지만 기존에 공부했던 윈도우나 모바일 악성코드처럼 코드 레벨을 중점적으로 보는 것이 아닌, 실제 해커들이 상대방 시스템에 침투하고 이익을 얻기 위해 추가한 비즈니스 로직과 악성코드가 점차적으로 진화하는 과정을 보며 이를 효과적으로 차단하기 위한 방법을 위주로 연구하게 되었다.

장기적으로 연구가 잘 된다면 논문이나 특허도 같이 내고 싶었지만, 회사를 다니면서 그러기 쉽지 않았기 때문에 좋은 연구 성과로 남을 수 있도록 노력했었고, 또한 블로그에는 기밀 유출로 문제가 되지 않도록 회사 제품에 구현되는 코드 레벨이나 설계 아이디어는 최대한 배제하고 남들이 생각했을 때 이해할 수 있을 정도로 남겼다. 그래도 이 글을 읽는 모두가 메일 클라이언트 보안이라는 인사이트를 어느 정도는 얻어갈 수 있도록 써보고자 했으며, 다음 글에서는 메일로 악성코드가 전파되어 문제가 되고 있는 실제 사례들에 대해 설명하도록 하겠다.

반응형

댓글