[서버보안] 서버 내에서의 명령어 통제 (실행) 기술 동향

Posted by taeho Tae-Ho
2014.08.22 10:55 정보보호

수년 전 발생했던 농협 전산망 해킹사고와 320사태 그리고 신용카드 3사의 엄청난 개인정보 유출사고에서 가장 핵심적인 취약성은 바로 "서버내부의 명령어에 대한 실행 통제 불가" "서버에 Telnet, SSH 접속 시 2차 인증 부재"다.


사실 서버가 해킹당하는 경우 위의 두가지 이슈가 가장 핵심적인 보안 취약성임에도 최근까지는 대부분 네트워크 수준에서 침투를 막지 못했다는 결과로 귀결시켜 조직 내부의 서버에 대한 보안이슈가 발생하는 것을 피해갔던 것이 사실이다.


하지만 2013년 금융감독원의 금융감독규정이 개정되면서 서버에 대한 접속 시 2차 인증 의무화와 서버 내에서의 위법행동 발생 시 즉각적인 조치가 가능한 수단 강구라는 항목이 추가되었다.


금융감독원-IT금융감독규정제14조금융감독원-IT금융감독규정제14조

[금융감독원 금융감독규정 제14조 9항과 10항]


이에 따라 금융기관들의 움직임이 바빠지고 있는 듯 하다. 지금까지는 시스템관리자들의 고유 권한으로써 장애발생 가능성을 이유로 신성불가침???의 영역처럼 여겨져 명령어의 사용에 대해 제약을 두지 않았으나 대형 보안사고의 주요 취약성으로  "서버내에 접속한 사용자/개발자/관리자/엔지니어에 대한 명령어 실행 통제 미흡"이 언급되기 시작하였고 결국 금융감독지침에 구체적으로 명령어 사용에 대한 통제 항목이 포함되었다.


서버내의 명령어 실행 통제를 위한 세가지 기술 동향


서버 내에서의 명령어 실행...더 나아가 서버 내의 중요 파일에 대한 읽기/수정/삭제 등을 통제하기 위한 다양한 기법의 솔루션이 이미 존재하고 있다. 그리고 이러한 명령어 실행을 통제할 수 있는 솔루션 들은 크게 3가지 정도의 제품군으로 분류될 수 있다.


1. 게이트웨이 방식의 서버접근제어(SAC) 기법


이 방식은 서버에 접근하는 모든 사용자가 프락시형태의 게이트웨이 장비를 통해 Telnet/SSH 접속을 하게 되고 게이트웨이 장비에서 서버로 전달되는 명령어를 분석하여 통제하는 방식이다. 

하지만 이 방식은 우회접속이나 서버와 서버간의 직접 접속 등을 통제하지 못하기 때문에 사실 거론의 대상이 되어서는 안되는 방식이다. 흔히 서버에 별도의 통제 SW를 설치하지 않아도 되고 장비하나만 도입하면 되기 때문에 수년전까지 선호되던 방식이나 최근 여러 감독기관의 보안감사에서 우회접속과 콘솔을 통한 직접접속에 대한 통제가 불가능한 사실이 알려지면서 명령어 통제기술로는 부적합하다는 것이 일반적인 평가다.


많은 SAC 솔루션 개발사에서 다양한 방법을 통해 이러한 단점을 극복하려 노력하고 있으나 워낙 해결하기 어려운 기술적문제가 많아 단시간내에 제대로 된 명령어 통제 기능을 수행할 것으로 기대하긴 어렵다.


2. TTY 복제 및 쉘(Shell : ksh, csh 등) 교체 방식의 명령어 통제 기술


게이트웨이 방식과는 달리 서버에 직접 응용수준에서 동작하는 보안SW를 설치하는 에이전트 방식의 명령어 통제 기법이다. 사용자가 Telnet, SSH를 접속하면 TTY라 부르는 터미널 디바이스를 할당받는데 보안SW가 하나의 TTY를 더 할당받아 TTY와 Shell 사이에 끼워 넣어 화면에 입출력되는 명령어를 가로채어 통제하는 방식이다.

또 하나의 방식은 /etc/passwd에 사용자마다 지정되는 shell을 보안SW 개발사에서 만든 shell로 변경하는 방식이다. 


이 두가지 응용수준에서 동작하는 명령어 통제 방식의 공통점은 Shell로 전달되는 키보드를 통해 입력된 명령어를 가로채 검사한다는 점이다. 이 방식은 게이트웨이 방식보다는 장점이 많고 통제할 수 있는 영역이 넓기는 하지만 응용수준에서 동작하기 때문에 역시나 우회하거나 통제하지 못하는 명령어 실행이 많을 수 밖에 없다. 


예를들어 알리아스가 설정된 명령어의 실행이나 쉘스크립트 혹은 다른 명령어 내에서 위험한 명령어를 실행하는 행위를 통제할 수는 없다. 간혹 쉘스크립트를 파싱하여 분석하여 통제한다고 하나 스크립트를 2중, 3중으로 작성하거나 스크립트가 아닌 실행파일로 만들어 그 실행파일 안에서 명령어를 실행할 경우 쉽게 통제가 뚫리는 취약성을 갖고 있을 수 밖에 없다.


또한 명령어는 사용자 쉘에서만 실행되는 것이 아니다. 앞에서 언급된 대형 보안사고에서와 같이 사용자가 직접 실행하지 않고 백신업데이트 서버나 시스템관리소프트웨어 등 다양한 소프트웨어가 실행하여 발생된 사고도 많다.


때문에 게이트웨이 방식보다는 우월하나 여전히 제대로 된 명령어 통제를 수행할 수 없는 것이 사실이다.


3. 운영체제 커널 수준에서의 명령어 통제 기술


서버내에서 명령어의 실행이나 파일에 대한 수정은 최종적으로 운영체제 커널의 시스템콜을 호출하게 된다. 운영체제의 커널에 동적으로 로드될 수 있는 커널모듈을 만들어 아래 그림처럼 시스템콜 테이블과 실제 시스템콜 루틴 사이에 끼워넣어 모든 파일에 대한 실행/수정/삭제/생성 등을 검사하는 방식이다.

SecureOS의 Security Kernel (RedCastle)SecureOS의 Security Kernel (RedCastle)


이 기술은 이미 1990년대 후반부터 세계적으로 사용되기 시작하여 국내에서는 2000년 초반대에 안정적인 동작을 보장하는 솔루션이 출시되기에 이르렀다. 


이 커널수준에서의 사용자 추적과 명령어 실행통제 및 파일에 대한 수정/삭제의 통제는 보안소프트웨어가 커널에 로드되는 점 이외에는 단점보다는 장점이 더 많은 것이 사실이다. 우회접속에 대한 우려와 알리아스, 심볼릭링크, 콘솔접속에 의한 명령어 실행은 물론 다중 레벨 스크립트와 서비스대몬 및 명령어 내에서 실행하는 명령어에 대한 추적과 통제도 완벽하게 수행된다.


마무리


이렇듯 서버 내에서의 명령어 통제에 대한 문제를 해결하기 위한 솔루션은 이미 시장에 넘쳐난다. 다만 어떤 솔루션을 선택하느냐의 문제다. 서버에 커널 수준에서 동작하는 소프트웨어를 설치하기 부담스럽다면 쉽게 우회할 수 있는 취약성이 있더라도 느슨한 통제를 수행하는 솔루션을 선택하면 되고 명령어 통제라는 이름에 걸맞는 제대로 된 명령어 통제를 구현하고 싶다면 커널 수준에서 동작하는 명령어 통제 솔루션을 선택하면 된다.


관련포스트 : http://blogger.pe.kr/401

신고
이 댓글을 비밀 댓글로
  1. 좋은 솔루션이 개발되고 사용되어져야 겠네요~
    • 국산 소프트웨어도 좋은 제품이 많이 개발됩니다...하지만 기업 경영에 대한 ceo들의 잘못된 가치관과 합리적이지 못한 의사결정 그리고 정에 이끌려 공평하지 못한 조직관리가 그 소프트웨어 기업들을 죽입니다. 게다가 끝없는 갑질과 하도급은 성장가능성 높은 sw기업을 두번 죽이죠.. 그 속에서 개발자들은 반복되는 야근과 밤샘 코딩으로 세번 죽습니다... 정말 안타까운 일입니다..
  2. 답글에서 공통된 마음이 듭니다 3번 죽이는 일을 아무렇지도 않게 반복하는 윗분들이 많습니다
    • 출근중이시군요...^^ 맞습니다.우리나라에 경험 많은 개발자가 없는 이유중 하나죠..다들 혹사 당해 개발업무를 떠나기 때문이죠. 그래서 하지 않아도 될 시행착오의 무한루프에 빠지고 맙니다.

인터넷 공유기 해킹과 파밍을 통한 금융사기 시도 (2014.05)

Posted by taeho Tae-Ho
2014.05.27 12:48 정보보호

엄청나게 많은 가정과 소규모 매장에서 사용중인 인터넷 공유기가 해킹을 당하기 시작했다. 지금까지 비교적 공유기에 대한 해킹시도가 많지는 않았다. 하지만 인터넷에 접속되어 있는 모든 컴퓨터와 컴퓨터에서 실행중인 프로그램들은 해킹에서 자유로울 수는 없다.


최근 브라우저에서 네이버에 접속하면 생뚱맞게도 금융감독원을 위장해서 보안카드 정보를 빼내려는 시도가 빈번하게 발생하고 있다. 금융기관의 인터넷 뱅킹에 접속한 것도 아닌데 말이다.



버젓이 포탈의 액티브엑스 콘트롤을 가장하여 악성프로그램을 설치하려고 한다. 아..지겨운 ActiveX 콘트롤... 그래서 크롬이나 파이어폭스를 써야 한다.



공유기를 해킹하면 몇몇 공격이 가능할 거으로 예상된다.


아마도 먼저 DNS 쿼리 요청을 가로채는 DNS Spoofing을 통해 파밍이 가능할 것이다. 파밍공격을 시도한다면 www.naver.com 이 입력될 경우  자신들이 미리 준비한 IP로 바꿔치기(DNS Soofing) 하여 위와 같은 페이지를 보여줄 것이다.


또 하나의 예상할 수 있는 공격은 패킷 스니핑에 의한 트래픽변조 공격이다. 이 트래픽 변조 공격은 DNS 스푸핑이 아닌 ARP 스푸핑을 이용하거나 게이트웨이인 공유기의 관리자 권한을 얻어 단순한 스니핑(Sniffing)을 통해 특정 웹사이트로 향하는 HTTP 프로토콜의 패킷을 가로채 웹페이지의 중간에 위 화면에서 보이는 팝업창을 띄우고 악성프로그램을 다운로드 하게 하는 Script를 삽입한다.


이러한 공유기 해킹에 의한 파밍이나 피싱 공격은 컴퓨터나 인터넷에 대한 지식이 부족한 사용자에게는 치명적인 피해를 줄 수 있는 공격이다. 


공유기가 공격을 당해 발생하는 앞의 해킹은 공유기 자체의 취약점으로 인해 발생하는 것이기 때문에 제조사에서 공유기의 운영체제를 패치하여 해결하여야 한다.  그리고 아래와 같이 공유기 제조사들은 신속하게 보안취약성 패치를 진행하고 있다. 



하지만 불특정 다수의 사용자들에게 일일히 연락을 취해 패치를 권고하거나 자동으로 패치를 해줄 수 없기 때문에 앞으로도 이러한 피해는 지속적으로 발생할 것으로 보인다. 결국 사용자가 책임질 수 밖에 없는 것이다.


신고
이 댓글을 비밀 댓글로
  1. 보안이 참 문제네요...
    • 나의 중요한 정보가 다른 사람과 연결되어 내 허락없이 유출될 수 있는 통로가 컴퓨터와 통신의 발전으로 엄청나게 다양해졌죠. 기업도 마찬가지구요. 그래서 보안은 생활의 일부가 되어야 하는데 아직 사람들의 보안 마인드는 초보적인 수준에 그치고 있는게 현실입니다. 당연히 보안 기술에 대한 이해도도 낮구요.

DOS 및 DDOS 공격 유형의 변화와 대응 방안 (KISA-2012)

Posted by taeho Tae-Ho
2014.05.24 09:50 정보보호

서버보안의 일을 하다 보면 주로 서버에 로그온 하는 자연인(부서/직급/이름으로 식별가능한 실제 사람과 서버에 접속할 때 입력하는 계정(ID) 그리고 로그온한 세션에서 실행한 명령어(Command)와 해당 명령어(Command)가 접근한 파일 그리고 파일에 접근할 때의 권한(읽기/생성/수정/삭제/실행) 관계를 다루는 일을 하게 된다.


때문에 주로 서버관리자, 개발자, 응용프로그램 운영자 및 외부 인력의 서버 내에서의 작업을 어떻게 통제하고 작업 및 행위에 대한 감사기록을 어떻게 남길 것인가에 대한 컨설팅을 하게 된다. 그리고 그러한 서버에 대한 접근통제와 파일 및 명령어에 대한 접근/실행의 통제 그리고 감사 증적자료의 확보는 대부분 개인정보보호법이나 정보통신망 이용촉진 및 개인정보보호에 관한 법률, 그리고 금융기관의 경우 금융감독원의 규정에 대한 컴플라이언스 기준으로 이루어진다.


사실 이런 관리적 보안에 대한 업무는 운영체제와 데이터베이스 그리고 몇몇 시스템 소프트웨어에 대한 지식과 전체적인 시스템을 어떻게 구축하고 개발하고 운영하는지에 대한 노하우만 있다면 이를 바탕으로 위험관리 절차에 따라 정책을 수립하고 서버보안SW를 통해 구현하면 된다. 

이 일을 하기 위해서는 깊은 지식보다는 넓은 지식이 필요하고 프로젝트 및 시스템 운영에 투입된 엔지니어, 관리자, 운영자, 개발자, 오퍼레이터와의 커뮤니케이션 능력이 더 중요하다고 할 수 있다. 그리고 다양한 분야의 기술자 들을 아우르기 위한 충분한 경험은 더욱 중요한게 사실이다.


하지만 DOS 및 DDOS 그리고 웹해킹 및 APT 공격에 의한 서버에 대한 공격의 방어는 조금 이야기가 달라진다. 물리적인 네트워크 구성과 OSI 7 Layer 중 2,3,4,5 계층(TCP/IP)에 대한 심도 있는 이해와 운영체제 측면에서의 프로그래밍에 대한 지식 그리고 애플리케이션서버에 대한 지식이 필요하다. 그 중에서도 DOS 및 DDOS 공격의 급격한 트렌드의 변화는 특정 애플리케이션의 프로토콜에 대한 정확한 이해가 필요하다.


예전의 DOS와 DDOS 공격은 주로 TCP/IP 프로토콜의 취약성을 공격하는 형태가 주를 이루었다. ICMP 프로토콜의 취약성을 공격하는 SMURF 공격, Ping of Death 공격이 그랬고 UDP의 취약성을 공격하는 Tear Drop 공격 그리고 TCP의 3-way handshake 취약성을 파고드는 Syn Flooding도 TCP/IP의 취약성을 공격하는 대표적인 사례였다. 그 외에도 무수히 많은 TCP/IP 취약성 공격이 있으나 현재는 대부분 네트워크 장비의 설정을 변경하는 것으로도 충분히 방어가 가능하게 되었다.


그래서 해커들은 더 이상 TCP/IP 프로토콜에서만 취약성을 찾고 있지는 않다. TCP/IP에서 벗어나 보다 더 상위레이어(L7)에서 취약성을 찾기 시작했고 가장 대표적인 애플리케이션 레이어의 프로토콜인 HTTP 프로토콜의 취약성을 공격하기 시작했다.


대표적인 HTTP의 취약성을 악용하는 DOS/DDOS 공격은 다음과 같은 것들이 있다.


● HTTP Get Flooding

● Slow HTTP Post Attack

● Slow HTTP Header Attack

● Slow HTTP Read Attack


이러한 공격들은 주로 HTTP 프로토콜을 통해 클라이언트의 Request 와 그 Request를 처리하는 웹서버 사이의 통신 세션의 수에 제약이 있다는 점을 이용해 해당 세션의 처리를 지연시킴으로써 웹서버가 더 이상 클라이언트의 Request를 받아들이지 못하도록 하는 공격을 수행하는 것이다.


이 공격에 대한 자세한 원리와 분석방법 그리고 대응 방안을 명시한 KISA(한국인터넷진흥원)의 자료(2012년)를 첨부한다. 그 양이 꽤 많고 심도있게 이해해야하기 때문에 포스트에 모든 것을 쓰기는 좀.... 어렵다. 두고 두고 꾸준히 읽어봐야할 자료인 듯 하다.


KISA_DDoS공격대응 가이드.pdf


신고
Tags
이 댓글을 비밀 댓글로

스니핑(Sniffing)을 위한 5가지 공격 방법

Posted by taeho Tae-Ho
2014.05.17 12:39 정보보호

과거의 Dummy Hub 환경과는 달리 스위칭 허브 환경에서는 단순히 스니핑 툴을 실행한다고 해서 패킷 스니핑이 되지 않는다. 이는 스위칭 허브(스위치)의 각 포트에 접속된 장비들의 MAC 주소를 캐싱하여 프레임(2계층의 데이터 단위)을 목적지 포트(스위치의 물리적 포트)로만 보내주기 때문이다. 즉 스위치에 접속된 컴퓨터는 수신될 즉 목적지 MAC 주소가 자신으로 되어 있는 프레임만 수신되기 때문에 다른 컴퓨터로 전송되는 프레임은 수신되지 않는다. 


하지만 다음에 설명되는 기법들을 사용하면 스니핑을 할 수 있다.


1) Switch Jamming


스위치의 MAC Address Table을 모두 채워서 스위치가 더미허브처럼 모든 프레임을 스위치의 모든 포트로 전송(브로드캐스트)하도록 만들어 스니핑이 가능한 환경을 만든다. 공격자는 MAC Address Table을 모두 채우기 위해 변조한 MAC 정보를 담고 있는 ARP Reply 패킷을 계속해서 스위치에게 전송한다.


2) ARP Spoofing


공격자가 스니핑하고자 하는 희생자 호스트에게 호스트가 통신하는 상대방의 MAC 주소를 자신의 MAC 주소로 위조한 ARP Reply 패킷을 희생자에게 지속적으로 보내면 희생자의 ARP Cache Table에 희생자가 통신하고자 하는 호스트의 MAC 주소가 공격자의 맥 주소로 변경되어 스니핑이 가능하다.


3) ARP Redirect


공격자가 자신이 게이트웨이(라우터)인 것처럼 MAC주소를 위조한 ARP Reply 패킷을 브로트캐스트하여 네트워크에 연결된 모든 호스트의 MAC 어드레스 테이블의 게이트웨이 MAC 주소를 공격자의 MAC 주소로 변조하여 모든 통신을 스니핑을 하는 공격 기법이다. 


4) ICMP Redirect


앞의 공격은 모드 ARP 캐시테이블을 변조하는 공격이지만 ICMP 리다이렉트는 L3(네트워크 레이어)의 라우팅 테이블의 게이트웨이 주소를 변조하는 공격이다. 공격자는 라우터에서 호스트 또는 라우터간의 라우팅 경로를 재설정하는 ICMP 리다이렉트 메시지를  희생자에게 전송하여 희생자 호스트의 라우팅테이블을 변조하여 스니핑을 가능하게 하는 공격기법이다.


5) Switch의 SPAN/MONITOR포트를 이용하는 방법


특별한 공격을 수행하지 않고 스위치의 포트미러링이 가능한 Monitor 포트에 노트북이나 컴퓨터를 접속하여 물리적으로 스니핑을 가능하게 하는 방법이다.



신고
이 댓글을 비밀 댓글로
  1. 잘 보고 갑니다~

소프트웨어 개발 보안 가이드 (시큐어 코딩)

Posted by taeho Tae-Ho
2014.05.08 20:47 정보보호

해커들의 공격 기법은 끊임없이 진화한다.


"실력 과시"와 "금전 획득" 등 해킹의 고전적인 목적 이외에도 개인과 개인, 조직과 조직, 더 나아가 국가와 국가간의 범죄, 이권 다툼, 전쟁의 수단으로 해킹(사이버 공격, 사이버 테러)이 이용되면서 다양한 소프트웨어와 시스템의 취약점이 끊임없이 발견되고 공격받고 있다.


그로 인해 소프트웨어나 웹사이트를 개발하는 개발자들의 발등에도 불이 떨어졌다. 사용자 인증과정이나 전송되는 데이터의 무결성과 암호화에만 신경쓰면 되었던 "소프트웨어 개발 보안"이 소프트웨어의 개발 전 과정과 시작에서 종료까지의 모든 소스코드상에 보안의 개념이 적용되기 시작하였다.


이러한 소프트웨어의 개발과정에서 적용되는 보안 기법을 "시큐어코딩(Secure Coding)"이라고 한다.


2012년 9월에 안행부(KISA)에서 발간한 시큐어코딩 가이드가 소프트웨어의 개발 시 지켜야할 시큐어코딩 지침을 담고 있다.


소프트웨어(SW) 개발보안의 정의


이 시큐어코딩 가이드에 보면 소프트웨어 개발 보안을 다음과 같이 정의하고 있다.


"SW 개발 과정에서 개발자의 실수, 코드의 논리적 오류 등으로 인해 SW가 갖고 있을 수 있는 보안취약점(vulnerability)의 원인, 즉 보안 약점(weakness)을 최소화하는 한편, 사이버 보안 위협에 대응할 수 있는 안전한 SW를 개발하기 위한 일련의 보안활동을 의미한다.


넓은 의미(광의)로는 SW 개발생명주기(SDLC : Software Development Lifecycle)의 각 단계별로 요구되는 보안활동을 모두 포함하며, 좁은 의미(협의)로는 SW 개발 과정 중 소스코드 구현단계에서 보안 약점이 발생하는 것을 배제하기 위한 "시큐어코딩(secure coding)" 을 의미한다."


위의 정의에서는 잘못된 코딩에 의한 "보안 약점"이 "취약점"의 원인이 된다고 서술되어 있다. 이는 소스코딩 시 보안을 고려하지 않는 코딩이 "약점"이 되고 이 "약점"이 "보안취약점"의 원인이 된다는 의미다. 보안을 고려하지 않고 코딩을 한다해서 무조건 "취약점"이 내재되지는 않는 사실을 반영하고 있는 듯 보인다. 


아래 취약점 목록에도 있지만 "입력데이터 검증"을 하지 않는다 하여 무조건 취약점이 있는 것은 아니기 때문에 입력값 검증을 하지 않는 것은 "약점"이고 이 "약점"으로 인해 특정 입력값을 넣었을 때 권한의 탈취 또는 다른 명령어를 실행할 수 있거나 정보가 노출되면 그 "약점"은 "취약점"이 된다는 것이다.


시큐어 코딩의 정의에서 "약점"이라는 개념을 적용한 것은 아마도 소스코딩을 하면서 어떤 코드에서 "취약점"이 발생할지를 미리 예상하는 것이 매우 어렵기 때문이라고 생각된다. 사실 입력값 검증을 하지 않아도 되는 경우도 있고 에러 처리를 별도로 해주지 않아도 되는 경우가 있지만 어느 로직은 하지 않아도 되고 어느 로직은 해야하는지를 판단하는 것 보다는 일괄적으로 시큐어 코딩을 습관화하여 적용하는 것이 보다 효율적이고 보안 강화 효과가 크다고 보여진다.


시큐어코딩이 적용되어야 할 7대 취약점


  취약점

 내용

 입력데이터 검증 

및 표현

프로그램 입력값에 대한 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식 지정으로 인해 발생할 수 있는 보안 약점

※ SQL 삽입, 자원 삽입, 크로스사이트 스크립트 등 26개 취약점

 보안 기능

보안 기능(인증, 접근제어, 기밀성, 암호화, 권한관리 등)을 적절하게 구현하지 않았을 때 발생할 수 있는 보안 약점

※ 부적절한 인가, 중요정보 평문 저장(또는 전송) 등 24개

 시간 및 상태

동시 또는 거의 동시 수행을 지원하는 병렬 시스템, 하나 이상의 프로세스가 동작하는 호나경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안 약점

※ 경쟁조건,, 제어문을 사용하지 않는 재귀함수 등 7개

에러 처리 

에러를 처리하지 않거나, 불충분하게 처리하여 에러 메시지에 중요 정보(시스템 등)가 포함될 때 발생할 수 있는 보안 약점

※ 취약한 패스워드 요구조건, 오류 메시지를 통한 정보 노출 등 4개

코드 오류

타입 변환 오류, 자원(메모리 등)의 부적절한 반환 등과 같이 개발자가 범할 수 있는 코딩 오류로 인해 유발되는 보안 약점

※ 널 포인터 역참조, 부적절한 자원 해제 등 7가지

캡슐화

중요한 데이터 또는 기능성을 불충분하게 캡슐화하였을 때, 인가되지 않는 사용자에게 데이터 누출이 가능해지는 취약점

※제거되지 않고 남은 디버그 코드, 시스템 데이터 정보누출 등 8개 

 API 오용

의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안 약점

※ DNS Lookup에 의존한 보안결정, 널 매개변수 미조사 등 7개


링크


보다 자세한 시큐어 코딩 가이드는 이곳(안행부전자정부국)을 방문해 다운로드 받으면 된다.




신고
이 댓글을 비밀 댓글로

[보안사고사례] KT 고객 정보 1200만건 유출 - 범죄의 재구성 (2014.03.06)

Posted by taeho Tae-Ho
2014.03.07 10:01 정보보호

또 한건의 대형 개인정보 유출사고가 발생했다. 그런데 해도 해도 너무한다. 이렇게 쉬운 방법으로 거대 통신사의 고객지원 웹사이트가 뚫리다니.... 지금껏 얼마나 많은 해커가 이 통신사의 개인정보를 무단으로 해킹해 유출시켰을지 모른다고 생각하니 참 한심하다 못해 어이가 없다. KT는 보안사고로 개인정보가 유출된 뒤 채 2년도 안돼 또 초대형 개인정보유출사고의 주범이 되는 불명예를 뒤집어 쓰게 되었다.


지금 KT 올레닷컴 사이트의 요금조회 페이지는 굳게 걸어닫혀 있다. 물론 죄송하단 안내 페이지는 열려있다.




굳게 닫혀있는 요금조회 및 개인정보 조회 페이지..



사실 KT 홈페이지가 해킹을 당해 1200만건의 개인정보가 유출되었다고 해서 "설마 올레 닷컴" 웹페이지일까 싶었다. 올레닷컴은 사실상 전국민이 사용하는 요금조회 및 개인정보 조회가 가능한 웹사이트다. 거의 전국민이 사용자다. KT는 유선과 무선의 통신서비스를 하고 있고 유선과 무선의 모든 고객과의 대화창구가 바로 "올레 닷컴"이다. 


그런데 올레 닷컴에 접속해 보니 단번에 "아.. 올레 닷컴이 뚫렸구나.."라는걸 알 수 있었다. 아래의 메뉴들은 모두 접속이 불가능했다.




그렇다면 해커는 어떤 방법으로 올레닷컴에 접속해서 개인정보를 빼내간 것일까..??


경찰에서 발표한 바에 의하면 그 방법은 다음과 같다고 설명하고 있다.



해커들은 파로스 (Paros)라는 프로그램을 이용했다고 한다. 내 눈을 의심했다. paros는 웹 개발자들이 즐겨 사용하는 디버깅 도구이다. 그리고 이 디버깅 도구인 파로스를 이용해 "웹 브라우저에서 웹서버로 전송되는 데이터는 변조가 가능하다"라는 웹 취약점에 대한 공격 방법은 초보 개발자들도 알고 있는 "상식"이기 때문이다.


설마 KT가 그렇게 초보적인 공격에 조차 무방비인 상태로 올레닷컴 웹사이트를 그 오랜 시간동안 운영해 왔다는 말인가?

한심하다 못해 어이가 없어 할말을 잃을 지경이었다. 도대체 몇년 전 보안사고로 인해 새로 투자한 그 많은 돈은 어디로 갔단 말인가?  송소희양을 불러 "어이~없~소~~오~~ 어이~없~소~~~~"를 외치게 하고 싶다.


일부 언론에서 paros를 마치 강력한 해킹툴인 것 처럼 소개하고 있지만 paros는 주방도구인 "칼"과 같은 도구다. 개발에 사용하면 훌륭한 디버깅 도구로서 개발자들의 필수 소프트웨어이고 해킹에 사용하면 해킹을 도와주는 도구가 되는 "그냥 프로그램"일 뿐이다. 


어찌됐든 Paros를 이용하여 해킹을 시도한 과정을 도식화 하면 다음과 같다.



해커의 해킹 과정을 위의 그림을 기준으로 설명하면 다음과 같다.


1. 해커는 올레 닷컴에 로그인 한다. 이때도 물론 남의 계정을 쓰지 않았을까 싶다.


2. 요금조회 및 개인정보 조회 페이지에서 로그인한 계정의 정보를 조회한다.


3. 해커는 미리 paros를 동작 시켜 웹브라우저에서 KT의 서버로 가는 요청(Request)을 가로채도록 설정(proxy)하고 paros에서 요청 (http request (get or post))을 가로채 요청 내에 있는 고객번호를 엉뚱한 고객번호로 변조한다. 경찰에 의하면 이 고객번호는 9자리의 번호로서 해커들은 무작위로 변조해 응답이 오는지를 확인했다고 한다.


4. paros에서 변조된 고객번호는 KT 서버로 넘어가 DB 에서 조회된다.


5. 응답은 웹브라우저로 전송된다. 이때 로그인한 고객 계정의 정보가 아니라 해커가 paros에서 변조한 고객번호의 정보다. 즉 피해자의 이름, 전화번호, 계좌번호 등이 되겠다.


6. 해커는 이과정을 자동화하는 간단한 프로그램을 작성해 매일 수만에서 수십만건씩 개인정보를 빼냈다.


사실 이런 방식의 해킹은 서버보안 관련 업무를 하고 있는 나로서도 참 난감할 수 밖에 없다. 웹페이지와 서버에서 구동되는 응용프로그램 소스코드 상의 취약성을 이용해 서버내의 파일이나 명령 등을 조작하지 않고 정삭적인 경로를 통해 정보만 빼내는 기법이기에 어찌할 도리가 없는 것이다. 서버보안 뿐만 아니다. 이러한 공격은 방화벽, 침입탐지시스템, DB보안솔루션, 웹 방화벽 등 다양한 보안장비를 갖추고 있어도 막을 도리가 없는 것이 현실이다. KT가 이런 보안 시스템을 도입하여 운영하고 있지 않았겠는가..?? (서버보안은 없는 걸로 알고 있지만...&nbs


해법은 개발자들이 시큐어코딩을 생활화 하는 것이다.


이런 공격에 대한 대응 방법은 웹페이지와 서버측의 조회 애플리케이션 소스 내부적으로 취약성을 제거하는 방법 밖에는 없는 것이 현실이다. 그래서 많은 보안 관련 단체나 정부 기관에서는 개발자들이 준수해야할 여러 프로그래밍 보안 기준들을 제시하고 있다.


그것이 바로 Secure Coding 이다. 여러 검색엔진에서 "시큐어코딩" 혹은 "secure coding"을 검색해 보면 다양한 자료들이 쏟아져나온다. 


그리고 이미 정부에서는 시큐어코딩의 중요성을 인지하고 수년전부터 관련 컨퍼런스를 개최하는 등 방안 등을 수립하고 자체적으로 시큐어코딩 가이드 등을 제시하고 있다. 이와 관련하여 정리가 비교적 잘되어있는 블로그를 소개한다. (관련 링크)


신고
이 댓글을 비밀 댓글로

USB 보안 프로그램 사용하기

Posted by taeho Tae-Ho
2014.03.01 11:32 정보보호

이동식 저장매체 중 하나인 USB 메모리에 공인인증서나 ISP 인증서 그리고 개인정보가 담긴 파일들을 보관하여 갖고 다니는 경우가 많다. 하지만 USB 메모리를 분실했을 경우에 대한 대비는 제대로 하지 못하고 있는 경우는 많지 않다. 어떤 방법으로 USB 메모리 내의 파일을..USB 메모리를 분실해도 습득한 사람이 보지 못하게 할 수 있는지 모르는 경우도 많다.


내 경우에는 USB Safe 라는 유료 프로그램을 쓴다. 아무래도 무료 프로그램보다는 사용이 비교적 편리하고 부가적인 기능도 지원하기 때문에 사용하고 있지만 1년 단위로 약간의 돈을 내야하기 때문에 사용을 망설이는 사람들도 많다.


그런데 최근에 꽤 쓸만한 프로그램을 찾았다.


바로 True Crypt라는 파일 암호화 프로그램이다. USB나 PC 양쪽 모두에서 사용할 수 있고 안정성도 꽤 훌륭한 듯 싶다. TrueCrypt를 PC에 설치하거나 USB 메모리에 압축을 해제하고 사용할 수 있다. USB 메모리를 여러 PC에 설치한다면 USB 메모리에 압축을 해제한 뒤 PC에 연결한 뒤 USB메모리에 있는 True Crypt를 실행하면 암호화된 파일들을 읽고 쓸 수 있다.


다음 웹페이지에서 안정버전을 다운로드 받을 수 있다. 꼭..홈페이지에서 받도록 하자. 암호화한 다는 이야기는 민감한 개인정보일 가능성이 높기에 혹시라도 악성코드가 포함된 프로그램을 설치하면 안되므로 꼭 홈페이지에서 다운로드 받자.


httpd://www.truecrypt.org/downloads 로 가서 다운받는다.



다운로드 받은 TrueCrypt를 실행하면 아래 화면처럼 라이센스 동의 절차가 진행된다.



두가지 설치방법이 있다. 일단 USB 메모리에 설치하여 이동 중 사용이 편리하도록 해야하므로 Extract를 선택한다. 나중에 PC에 Install로 추가로 설치해도 된다. Install로 설치할 경우 PC의 HDD에 암호화된 공간을 만들 수도 있다.





내 경우는 기본적으로 D: 드라이브가 표시되었다. Browse 버튼을 눌러 USB 메모리를 선택해야 한다. 당연히 USB 메모리를 먼저 꼽아 두어야 한다.



이동식디스크(USB 메모리임)를 선택한다.




USB 메모리에 True Crypt가 해제되었다고 나온다.




USB 메모리에 True Crypt를 설치하면 다음처럼 두개의 파일이 보인다. 



먼저 TryeCrypt Format.exe를 실행한다.

그리고 Create an encrypted file container 를 선택하고 Next 버튼을 누른다.



다음 화면에선 Standard TruCrypt volume 을 선택한다.



암호화한 파일들을 저장할 컨테이너 파일을 선택한다. 이 파일은 Volume으로 인식되어 드라이브로 마운트 된다.

여기서는 MyUsb라는 이름으로 지정했다. 나중에 확인하면 이 이름으로 커다란 파일이 하나 생성된다.



암호화 방식을 선택한다. AES는 미국방성에서 표준으로 제정한 256bit 키를 사용하는 대칭키 암호화 알고리즘이다. 다른 방식도 있는데 AES가 가장 안정적이고 충분히 강력한 보안성을 제공하므로 그냥 선택해도 된다.


해쉬(hash)는 데이터 및 키의 무결성을 검증하는 기법을 제공하는 알고리즘이다. 마찬가지로 기본값을 선택해도 충분하다.



생성할 암호화된 파일 저장공간의 크기다. 암호화할 보안영역의 크기라고 보면 된다. 다만 FAT32에서는 4G보다 작아야 한다. 더 큰공간을 원한다면 여기서 중단하고 USB메모리를 NTFS로 다시 포맷한 뒤 처음부터 다시 진행해야 한다.



암호화 키를 지정한다. 비밀번호다. 20자리 이상의 비밀번호를 권장하고 있다. 난 그냥 9자리로 했다.



암호가 짧다고 경고창이 뜬다. 20자 이상 지정하는 것이 안전하다고 하는데 그냥 무시했다. 예를 누르면 무시하고 진행하

는 것이다. 이 비밀번호는 보안영역(암호화 영역)을 드라이브로 마운트 할 때 매번 입력해야 하므로 잊어버리면 보안영역에 저장한 파일들과는 영원히 작별~하게 될 수 있으므로 잊어버리면 안된다.



생성하는 보안영역(암호화되어 저장되는 영역)을 포맷할 옵션을 선택한다.



보안영역을 초기화한다. 꽤 시간이 오래걸린다. 인내심을 갖고 기다리자.



보안영역의 초기화가 완료되었다.



종료하고 나가면 USB 메모리에 아래와 같이 지정한 크기만큼의 커다란 파일이 하나 생성되어 있다. 이 파일이 이제 개인적인 파일들을 암화화하여 저장할 파일이다. 이대로는 사용할 수 없고 다음의 과정을 진행해 이 파일을 드라이브로 마운트하여야 한다.



이제부턴 보안영역을 사용하기 위해서는 매번 TrueCrypt.exe를 실행해야 한다.

현재 컴퓨터에서 사용하지 않는 드라이브 레터(드라이브의 번호라고 보면 됨)를 보여준다. 아무거나 하나 선택한다.

그리고 아래에서 "Select File..."을 눌러 앞에서 생성한 보안영역의 파일을 선택해주어야 한다.





아래 화면처럼 드라이브레터(F:)와 보안영역 파일(MyUsb)를 선택한 뒤 "Mount"버튼을 누른다.



그러면 비밀번호를 누르라고 나온다. 보안영역을 생성할 때 20자리 이상으로 권장했던 비밀번호를 입력한다.



비밀번호가 맞다면 F: 드라이브로 마운트 시켜주고 크기와 암호화 알고리즘 등을 보여준다.



내컴퓨터에서 탐색기를 열어보면 MyUsb라는 보안영역 파일이 F: 드라이브로 연결되어 파일을 저장할 수 있다.

이 상태에서는 TrueCrypt 프로그램을 종료해도 계속 사용할 수 있다. 다만 사용을 모두 마친 뒤에는 가급적 다시 TrueCrypt.exe.를 실행하여 "Dismount"를 해주는 것이 데이터 손상을 막을 수 있는 가장 확실한 방법이다.



즐거운 보안 생활이 되길 바란다.


신고
Tags
이 댓글을 비밀 댓글로

스미싱에 대처하는 방법

Posted by taeho Tae-Ho
2014.02.26 16:30 정보보호

요즘 스미싱이라는 기법을 통해 스마트폰을 악성코드에 감염시키고 개인정보를 유출하거나 소액결제를 유도하는 사이버공격이 극성을 부리고 있다. 초기엔 "무료쿠폰"과 같은 공짜 상품을 미끼로 내세우더니 점차 "청첩장", "돌잔치" 등 초대장으로 바꾸고 이젠 "민방위훈련"까지 스미싱에 악용하고 있다.


스미싱이란 무엇인지 알아보면...


SMS 및 카카오톡 등의 문자메시지를 이용해 악성코드의 설치를 유도하는 공격기법이다.


해커들은 다음과 같이 문자메시지(SMS)를 이용하여 처음보는 URL을 보내 터치하도록 유도한다. 아래의 경우 도메인 주소가 toh.info 다.



일단 문자메시지나 카카오톡으로 의심스런 도메인의 URL을 받았다면 두가지 방법을 이용해 확인할 수 있다.


확인방법 1.


먼저 PC의 브라우저에서 접속해 본다. 가능하다면 인터넷익스플로러 보다는 크롬이나 파이어폭스를 이용하는 것이 더 안전하다.



위처럼 뭔가를 설치하라고 나온다거나 apk 파일을 다운로드받으라고 한다면 그냥 삭제하기 바란다.

조금 더 확인해보자면 메시지에 나온 "민방위"와 같은 단어로 플레이스토어에서 검색해보기 바란다. 적어도 플레이스토어에 있는 앱이라면 직접 다운받지 말고 플레이스토어에서 다운로드 받아 설치해야 비교적 안전하다.



확인방법 2. 


만약 위의 방법이 불안하다면...   도메인 주소를 확인하는 것이 더 확실하다.


다음과 같이 도메인주소를 확인할 수 있는 웹사이트로 이동한다.


주소는 http://whois.krnic.or.kr 이다.

이 사이트는 한국인터넷진흥원에서 운영하는 사이트이니 안심하고 접속해도 된다.



그리고 위 화면처럼 SEARCH 창에 문자메시지로 날아온 URL 중에서 앞의 한자리를 빼고 입력한 뒤 SEARCH 버튼을 누른다.


앞에서 처럼 kr.toh.info 라는 URL이라면 toh.info 만 입력한다.


검색하면 아래와 같이 결과가 나온다... 그런데 뭔가 이상하다.


도메인 등록자 주소를 보면 "넌 민방위 대상자야" 라고 문자를 보낸 사람이 미국에 산다. -.-  말이 되는가? 그것도 마이애미에 산다. 마이애미는 미국 플로리다의 주요 관광도시다. 언제 우리나라 민방위 본부(?)가 미국 마이애미로 이사를 갔을까 싶다.


스미싱이나 피싱으로 의심되는...아니... 문자메시지든 뭐든 하여튼 처음보는 URL이 전달되었다면 절대 클릭하지 않기를 바란다. 설사 그것이 아는 사람일지라도 클릭이나 터치하여 뭔가를 스마트폰에 설치하는 순간, 개인정보는 빠져나갈 수 있고 내가 하지도 않은 소액결제가 이루어질 수도 있다.



신고
이 댓글을 비밀 댓글로

APT 방어 시스템 구축 방안과 네트워크 기반 APT 방어솔루션에 대한 오해

Posted by taeho Tae-Ho
2014.02.22 13:42 정보보호

최근 가장 뚜렷한 보안 이슈는 APT 공격이다. 보안관련 뉴스만 봐도 얼마전까지는 DDOS 공격에 대한 이슈가 더 많이 눈에 띄었으나 최근엔 APT 공격에 대한 위험과 방어 대응체계에 대한 이슈들이 훨씬 많다. 



이 기사에서 볼 수 있듯 기업 전산실이나 공공기관 전산실에 근무하는 정적인 업무를 수행하는 담당자들의 보안 지식은 조금은 부족한 경우가 많다. 다른 분야와 달리 "보안"분야는 어느 한두가지 기술적 지식만으로는 기술이슈에 대해 제대로 이해할 수 없는 경우가 많다.


정보보안에 대해 각 이슈마다 정확하게 이해하고 적절하게 대응하기 위해서는 다양한 운영체제(windows, linux, Unix 등등)와 네트워크 (OSI 7 Layer, TCP/IP, UDP, ICMP 등등) 프로토콜 그리고 데이터베이스(Oracle, SQL Server 등등)는 물론 시스템소프트웨어(백업, 작업스케줄러, 시스템/네트워크 관리SW, 클러스터 SW 등등)와 웹서버, 웹애플리케이션서버, 형상관리SW 등등 다양한 기술적 요소는 물론 PKI, LDAP, SSO, 암호학 등에 대한 어느정도 심도있는 이해가 필요하다. 그래야만 다양한 분야에 박학~다식~한 수많은 해커들의 공격에 대응할 수 있기 때문이다.


보안업계에서 우스갯 소리처럼 떠도는 이야기중에 이런 이야기가 있다. 


A : 흔히 메인프레임이라는 시스템이 보안이 가장 잘되어 있다고 이야기하는데 메인프레임이 보안에 강한 이유가 

      뭔지 아는가?

B : 메인프레임의 아키텍쳐가 보안을 잘 고려하여 설계되었기 때문 아닌가?

A : ㅎㅎ 천만에~~ 전혀 아니네...

B : 그럼 왜 메인프레임이 보안에 가장 강하다고 하는데??

A : 그건 바로 메인프레임에 대해 제대로 알고 있는 해커가 없기 때문이라네.


나의 경우도 메인프레임에 대해서는 거의 모르는 문외한이다. 경험이 거의 없기 때문이다.  나같은 사람이 메인프레임의 관리자 권한을 일정시간동안 획득할 수 있다고 해도 할수 있는게 없다. 내 눈앞에 엄청난 돈이 되는 정보를 얻을 수 있는 화면과 키보드가 주어져도 모르기 때문에 정보를 빼낼 수 없는 것이다.


얼마 전 업무 때문에 메인프레임의 보안솔루션인 RACF에 대해 공부하면서 알게된 사실 중 하나가 RACF 관리자와 메인프레임 시스템 관리자의 권한이 제대로 분리되지 않으며 RACF를 우회할 수 있는 기법들이 오픈시스템만큼이나 다양하게 존재하고 있다는 사실을 알게 되었다. 그만큼 메인프레임의 보안에도 헛점이 많지만 그것을 알고 있는 사람이 거의 없을 뿐이라는 사실을 알게 되었다.


APT 공격은 공격 대상이 되는 시스템이 있는 기업/기관의 운영체제와 네트워크, 서버에 대해 충분히 이해하고 있어야만 성공할 수 있다. 해커들은 대부분의 APT 방어 기법에 대해 이미 정확하게 이해한 상태에서 오랜시간 지속적으로 끈질기게 공격을 하기 때문에 특정 보안솔루션을 도입했다고 해서 막을 수 있다고 생각하는 것은 APT 공격에 대한 가장 큰 오해다.


APT 공격에 의한 보안 사고 사례





최근 몇년간 발생한 가장 대규모의 APT 공격에 의한 보안사고 사례다. 어찌보면 가장 최근에 발생한 3개 신용카드사 개인정보 유출사고도 APT와 유사한 사례라 볼 수 있다. 사실 APT 보다는 위의 KT 고객정보 유출사고와 같이 내부자에 의한 정보유출사례에 더 가깝지만 넓은 의미에서 APT 공격의 범주에 포함시켜도 무리가 없을 듯 싶다. 원격에서의 악성코드 유포나 내부 침투 단계 유형만 다를 뿐 서버에 침투하여 정보를 빼내가는 형태가 APT와 유사하기 때문이다. 자동화된 도구를 이용해 원격에서 수행하였는가 아니면 내부에 직접 사람이 침투하여 정보를 유출시켰는가만 다른 정도다.


APT 공격의 단계결 공격 과정

위의 그림에서 볼 수 있듯 APT 공격은 네트워크 보안솔루션이나 백신, 서버보안SW와 같은 단일 솔루션으로는 완벽하게 통제가 불가능한 다양한 공격기법들의 집합체다. 즉 단순한 공격기법들이 고도로 발달한 포인트 보안 솔루션들의 등장으로 인해 성공가능성이 현저히 떨어지자 기술적 공격기법과 사회공학적 기법 그리고 제로데이 취약성 공격 및 분산공격 등과 같은 다양한 공격기법을 동원해 수많은 보안솔루션들의 탐지/차단 기술들을 우회하여 공격하는 것이다.


그런데 APT 방어 솔루션이라고 네트워크 단에 장비하나 추가로 설치한다고 APT 공격을 막을 수 있다고 생각하는 것이 오해가 아닐까?


최근 유행하는 APT 공격 방어 기법


최근 "APT 공격 방어 솔루션"이라는 타이틀을 달고 출시되는 여러 제품들이 있다. 가장 대표적인 것이 파이어아이(FireEye)와 맥아피의 MATD라는 솔루션이다. 이 솔루션들은 공히 어플라이언스 형태로 네트워크의 길목에 설치되는 게이트웨어 형태의 제품이다. 


이런 제품들의 가장 큰 장점이자 단점은 제로데이 취약성을 공격하는 악성코드를 탐지할 수 있다는 것이다. 왜 장점이자 단점인가 하면 정확도가 떨어지기 때문이다. APT 공격의 첫단계인 침투단계에서 가장 흔히 이용되는 침투 기법이 바로 인터넷에 접속가능한 내부망에 설치된 PC에 원격제어 및 정보유출이 가능한 악성코드(멀웨어)를 감염시키는 것이다.  파이어아이나 MATD는 내부망으로 다운로드 되는 파일을 샌드박싱 기법에 의해 장비내의 가상머신에 올린 뒤 실행시켜본다. 그래서 이 두 장비의 스펙에 보면 가상머신을 몇개까지 동시에 구동하여 악성코드를 탐지할 수 있다는 문구들이 나오는 것이다. 하지만 이런 기법으로는 "다운로드 된 파일이 악성코드일 가능성이 몇퍼센트다" 라는 불확실한 정보를 제공할 수 밖에 없다. 게다가 이러한 샌드박싱 탐지 기법이 나오자 마자 해커들은 파일을 여러개로 분리하여 감염시킨 뒤 분리된 모든 파일이 감염되었을 때 비로소 활동을 시작하는 새로운 기법의 감염경로를 만들 정도로 자동화된 악성코드 탐지는 불가능에 가까운 상황이다.


샌드박싱 이외에도 정적 분석, 동적 분석 등 자동화된 제로데이취약성 탐지 기법들이 동원되지만 여전히 오탐의 가능성이 너무 높은 것이 단점이다. 때문에 장점이자 단점이라는 결론에 도달할 수 밖에 없는 것이다.  그리고 이러한 방어기법을 가진 솔루션은 APT 공격에 대한 방어 솔루션이 아니라 APT 공격의 침투단계에서 악용되는 공격기법 중 하나인 제로데이 취약성 공격을 탐지하는 수준의 탐지솔루션이라고 보는 것이 더 정확하다 하겠다.


APT 방어 시스템 구축


앞에서 설명한 여러 이유로 인해 APT 방어 시스템은 특정 솔루션을 도입하여 네트워크 길목에 설치하는 것으로 구축할 수 있는 단순한 시스템이 아니다. 앞에서 언급한 다양한 APT 공격 단계별 방어 시스템을 구축하여 유기적으로 운용하는 것이 가장 효과적인 APT 방어 시스템이라고 생각해야 한다.


그리고 현시점에서 추가적으로 구축할 수 있는 APT 방어에 가장 효과적인 기술은 3 가지가 있다.


  • 제로데이 취약성 공격 방어를 위한 Whitelist 기반의 백신 및 PC/서버 무결성 검사 및 방어 기술
  • 내부 서버 인프라 침투를 방어하기 위한 2 Factor/2 Channel 인증 기술
  • 서버 내의 중요 데이터 및 파일(명령) 실행을 통제하기 위한 2 Factor/2 Channel 승인 기술


이 세가지 기술이 적용된 APT 방어 시스템의 구성은 아래 그림과 같다.



제로데이 취약성 공격을 통해 원격에서 내부망에 침투 거점을 막기 위해서는 Whitelist 기반 악성코드 감염 방지 기술이 필수적이다. 지금까지의 백신이 블랙리스트 방식이고 최근 평판기반 악성코드 분석기술이 적용되기 시작했으나 평판기반 악성코드 분석 기술도 완벽할 수 없는 보안기술이다. 때문에 강력한 Whitelist 기반 실행파일 실행 통제기술과 중앙관리 기술이 필수적이다. 이렇게 하지 않으면 APT 공격의 침투단계를 완벽하게 차단하는 것은 불가능하다.


또한 내부에 해커가 침투하여 거점을 생성하고 지속적인 모니터링을 통해 내부 서버에 대한 접근권한을 얻더라도 서버에 접속하지 못하도록 하기 위해 2 Factor/2 Channel 인증기술을 적용하여야 한다. 이 기술은 원격에서 서버에 대한 접근 IP, ID, password를 획득하더라도 부가적인 추가 인증(PKI인증서, OTP번호, ARS(전화)인증을 받아야만 서버에 접근할 수 있기 때문에 서버의 장악을 차단할 수 있다.


만약 이마저도 뚫렸다 하더라도 2 Factor/2 Channel 인증시스템과 서버보안SW를 연계하여 중요 데이터 파일에 직접접근하거나 다운로드 받으려 할 때 또는 실행을 통제해야 하는 위험 명령어를 실행하고자 할 때 상급자에게 ARS 승인을 받아야만 하도록 강력한 보안 인증/승인 기술을 적용함으로써 내부 서버 인프라에 대한 거의 완벽한 APT 공격 방어가 가능하다.


신용카드 3개사의 개인정보 유출 시 KCB 직원은 바로 이 마지막 방어 단계에서 통제가 이루어졌어야 한다. 서버에 접근 권한을 주더라도 실제 데이터파일을 다운로드 받지 못하도록 또는 다운로드 받기 위해서는 제3자의 승인을 받아야만 하도록 하고 다운로드 받은 사실을 확인하여야 하며 다운로드 받은 해당 노트북 및 지참한 USB 메모리 등 이동식 저장소에 대한 검사 등이 수행되었어야 한다.


하지만 이러한 완벽한 APT 방어 시스템 구축은 무척 어렵다. APT 방어 시스템 구축의 가장 큰 걸림돌은 바로 조직 내부의 구성원들이다. 업무 수행의 불편함으로 인해 보안정책수립에 대한 거부감이 클 수 밖에 없기 때문이다. 이는 우리나라 특유의 "빨리~빨리~"문화와 보안보다는 서비스 수행이 우선이라는 사고방식 때문이다.


결국 IT 시스템의 보안에 대한 제대로된 인식이 수립되지 않는 이상 서버를 건드리지 않는 네트워크 기반의 포인트 솔루션 도입으로 보안을 강화하려는 한계를 극복할 수 없다. 하지만 이미 해커들은 수많은 공격루트를 통해 내부망의 서버 인프라를 장악하는 기법에 대해 정확하게 파악하고 있고 실제로 공격을 감행하고 있다.


언제까지 서버를 이대로 방치할 것인가?


관련 포스트 보기

맥아피 MATD 솔루션 세미나 참관기

APT 공격의 단계 및 단계별 공격 기법


신고
이 댓글을 비밀 댓글로

신용카드사 개인정보 유출 사태 (KB, 농협, 롯데, 2014년 )

Posted by taeho Tae-Ho
2014.02.06 10:16 정보보호

2014년 1월 또 한번의 초 대형 보안사고가 발생했다. 이번엔 신용카드사에서 보유하고 있는 신용카드 발급 고객의 개인신상정보와 신용등급, 결제계좌정보 등의 비교적 고급정보 그리고 심지어 일부 고객의 경우 카드번호와 발급일자까지 유출된 것으로 보인다.


내 경우도 다음과 같이 "나도 알지 못하는" 나에 대한 정보가 유출되었다고 나온다. 과연 계속 이 금융사를 "주거래" 은행과 카드사로 이용해야할지를 심각하게 고민하게 만든다.





본격적으로 카드3사의 개인정보 유출사고를 살펴보기 전에 과거의 개인정보유출 보안사고 이력(?)을 한번 보고 넘어가자. 인터넷에서 대충 검색해도 아래 그림처럼 엄청난 양의 개인정보 유출사고 사례를 접할 수 있다.


출처 : http://zalhae.blog.me/30183768858


하지만 이런 많은 개인정보유출사건 중에서도 이번 신용카드3사의 개인정보 유출사고가 심각하게 다루어져야 하는 이유는 단순 개인정보 뿐만 아니라 금융정보까지 함께 유출되었다는 점에 있다. 게다가 이번 개인정보 및 금융정보의 유출이 소위 말하는 해커의 "해킹"에 의한 것이 아니라는 것은 금융사 내부의 모든 구성원이 마음만 먹는다면 얼마든지 개인의 금융정보에 접근하여 "계좌 조작"까지도 가능하다는 매우 치명적인 "위협 시나리오"가 현실로 나타날 수 있다는 것을 의미한다는 점에서 과거처럼 조용히 넘어가서는 안된다는 것을 시사한다. 하지만 사고 이후 금융당국과 정부의 대처는 호들갑만 떨 뿐 소문난 잔치에 먹을 것 없다는 속담을 떠올리게 하고 있어 안타깝기만 하다.


신용카드3사 개인정보/금융정보 유출 시나리오


이번 신용카드3사의 개인/금융정보 유출사고는 모든 금융기관 아니 모든 기업/공공기관의 공통적인 보안 위협인 "개발/운용의 외주"가 불러온 사고라고 볼 수 있다. 신용카드사들은 금융당국의 요구로 "신용카드 불법사용 탐지"를 위해 KCB라는 회사에 외주를 주어 시스템을 개발하고 있다.

그 과정에서 필수적으로 테스트가 필요한데 이때는 실제 신용카드 거래정보를 이용해 테스트를 진행할 수 밖에 없다. 당연히 KCB의 개발담당자는 "당당하게" 테스트를 위해 실제 고객 정보를 요구했고 카드사 IT담당부서에서는 데이터의 접그을 허용해주었다.


이를 바탕으로 아래 그림에 이번 사고 시나리오를 재구성해 보았다.

카드사 개인정보 유출 시나리오


하지만 여러 금융사의 전산실을 드나들어 본 경험을 바탕으로 할 때 의구심이 드는 것은 과연 KCB의 개발자가 어떻게 개인의 노트북을 소지하고 게다가 USB를 연결하여 개인정보를 유출했는가 하는 점이다. 솔직하게 이 점은 현재까지도 이해가 되지 않는다.


그 이유는 다음과 같다. 매우 기본적인 보안 수칙이다.


1. 대부분의 금융사는 이미 개인의 업무용 노트북을 어떠한 경우에도 금융전산네트워크에 접속하도록 허용하지 않는다.

2. 설사 접속하도록 하더라도 USB차단/블루투스 차단, 와이파이차단 등의 기능을 하는 보안SW를 노트북에 설치하여 USB사용을 차단한다.


1번과 2번의 규칙을 준수하지 않았다는 것은 사실 상상하기 힘들다. 이 보안규칙을 지키지 않았다면 이는 책임소재가 분명하기 때문에 대부분의 금융기관에서 비교적 철저하게 준수하고 있기 때문이다.


만약 위의 보안정책을 따르고 있었다면 어떠한 경로를 통해 데이터가 유출될 수 있을까? 이경우의 정보유출 경로는 바로 "서버"다.


요즘의 서버들은 대부분 USB포트를 갖고 있다. 윈도서버는 물론이고 리눅스, Unix 서버도 USB 포트를 갖고 있는 경우가 대부분이다. 서버 운영체제의 지식을 조금만 갖고 있다면 1. 서버에 USB 메모리를 꼽고 2. 마운트를 한 뒤 3. 서버의 DB에 있는 데이터를 파일로 저장한 뒤 4. USB로 복사하면 쉽게 유출이 가능하다. 그리고 이러한 방법은 엔지니어나 내부자에 의해 종종 사용되고 있다.


서버에서의 정보유출 차단을 위한 방안


앞에서 언급한 것 처럼 "개발"이나 "운용"을 위해 내부 IT 부서 직원이나 오퍼레이터 혹은 외부 업체의 직원에게 서버에 Telnet, FTP 등의 방법으로 로그온할 수 있는 권한을 부여하는 경우가 많다. 하지만 Unix/Linux/Windows 서버는 어떠한 계정으로라도 서버에 로그온만 할 수 있다면 해킹이라고 하기에도 유치한 쉬운 방법으로 수퍼유저(root, Administrator) 권한을 얻을 수 있다.


그렇기 때문에 RedCastle과 같은 SecureOS 솔루션을 설치하여 보안대책을 수립해야 한다.


1.  IP , 계정, 시간, 서비스종류(telnet,ftp)조합에 의해 로그온을 통제.

2. 로그온통제에 추가하여 AuthCastle 등을 통한 2중인증(ID/Password + OTP/PKI/ARS) 적용

3. DBA 계정 및 root 계정 등 으로 로그온했다 하더라도 데이터베이스에 접근할 수 있는 명령어 및 실제 데이터가 

   저장된 데이터파일에 접근을 차단.

4. root 계정에서 db관리자 계정(oracle, db2)으로 패스워드 없이 Switch User 하지 못하도록 차단

5. setuid 및 간단한 코딩을 이용해 db관리자 권한 및 수퍼유저 권한 획득 차단

6. 백도어 등 설치를 통한 Bind Shell 등의 차단 (사용하지 않는 통신포트 Bind 차단)

7. 서버내에서의 Race Condition, FIFO Attack, 스니핑 등을 탐지하거나 차단할 수 있는 보호대책 적용

8. 운영체제의 설정파일, 응용프로그램의 설정파일 및 바이너리 파일에 대한 위변조 차단

9. 임시디렉토리에서의 실행(execute) 통제 및 크론탭 파일 등에 대한 무단 위변조 차단

10. 응용프로그램 네에 하드코딩된 ID, 비밀번호에 대한 유출 방지 대책


몇몇 보안대책만 나열해 보았지만 이러한 보안대책을 권고하고 구현해주는 보안컨설팅업체는 아직까지 보지를 못했다. 그만큼 서버내에서의 내부자 및 외부용역업체 개발자/엔지니어에 대한 행위 통제를 수행하는 경우는 아직까지 거의 없다. 그리고 이러한 보안대책을 "제대로~" 구현할 수 있는 솔루션도 RedCastle과 같은 SecureOS 외에는 없다고 봐도 무방하다.


일부 게이트웨이 방식의 제품이나 보안쉘 방식 혹은 PAM에서 가로채는 형태의 제품이 있기는 하나 사실 반쪽자리 솔루션일 뿐이다. 관리자 권한(root)을 얻는다면 간단하게 우회가 가능하기 때문이다.


10년 가까이 서버보안 업무를 하고 있지만 서버에 대한 제대로된 보안 정책을 수립하고 구현한 기업이나 공공기관은 손가락에 꼽을 만큼 찾아보기 어려운 것이 현실이다. 그나마 몇 안되는 고객사의 보안정책 수립과 구현에 기여했다는 것이 소중한 기억으로 느껴지는 것이 현실이다.


내가 서버보안업계에서 은퇴(?)하기 전에 과연 "제대로 된" 서버의 보안대책을 구현하는 것이 보편화될 지 궁금하다.



신고
이 댓글을 비밀 댓글로
  1. 헐... 저도 이 머나먼 땅에서 다 털렸어요 ㅠ
    더 화나는건 거소증 만들어 따끈따근한 새 주민번호를 만들었는데 그게 털렸다는 ㅠ
    뭐 이런 일이 있나 싶어요.
    저도 유니센터님 링크 걸고 갑니다 ㅎㅎ