정보유출·디도스 공격 모두 악성코드 악용
보안통제 준수하려는 의식과 실천이 중요해
[보안뉴스= 임채호 KAIST 초빙교수] ‘스턱스넷(STUX.NET)’은 2010년 7월에 드러난 악성코드다. 공장자동화 등에 쓰이는 독일 지멘스(Siemens)사의 SCADA/PLC라는 부품을 공격했다. SCADA/PLC는 일종의 임베디드 시스템인데, 관리자 PC로 제어된다. 스턱스넷은 먼저 관리자의 PC에 침입하고 이를 경유해 SCADA/PLC에 들어가서 내장된 소프트웨어를 교묘하게 변경해 실제 시설의 성능은 떨어뜨리지만 마치 정상 동작하는 것처럼 관리자 PC에서는 보이도록 했다. 스턱스넷은 여러 버전의 윈도우 OS의 잘 알려지지 않은 약점을 이용했고, 각국의 기존의 백신을 분석하여 탐지 당하지 않도록 매우 뛰어난 기술로 제작되었다.
신종 악성코드 유입경로
스턱스넷은 독일 지멘스 SCADA/PLC에 침투하기는 하는데, 특정한 벤더에서 공급한 특정한 행동을 하는 시설에만 피해를 주도록 제작되어 있었다. 스턱스넷은 핀란드 모 제조사와 이란의 모 제조사가 공급한 시설의, 특정 회전수 범위의 모터를 제어하는 시스템에만 피해를 주었다. 피해를 주는 방법은 모터의 회전수를 가끔 크게 낮춘 후 원상 복귀함으로써 회전수가 잠시 떨어졌다는 것은 관리자 PC에서는 알 수 없도록 한 것이었다. 이란의 핵 시설, 구체적으로 말하면 우라늄을 농축하기 위해 원심분리기를 가동하는 시설이었다.
.jpg)
그 시설이 하필이면 그 벤더가 공급한 시스템으로 원심분리기의 모터를 제어해 하필이면 그 회전수로 돌리고 있었기 때문이었다. 이게 우연일 수 있을까? 미국이 가장 꺼려하는 이란의 핵 시설이 스턱스넷에 당한 것이 말이다. 보안전문가들은 스턱스넷을 미국이 만든 목표를 찾아가서 정교하게 파괴하는 ‘사이버 유도 미사일’로 보고 있다. 미국이 도청뿐만 아니라 사이버 해킹을 통한 ‘실력 행사’ 능력도 엄청나다는 것을 보여준 사건이다.
◇악성코드와 USB 감염
그런데 사실은 핵 원심분리기 등 SCADA 관련 시설은 운영에 필요한 모든 정보 업데이트는 USB를 이용할 수밖에 없다. 소문에 의하면 스턱스넷 악성코드를 담은 고급 USB가 이란 핵발전소 출근길에 뿌려두었고 누군가 관리자가 이를 주워 사용하다 감염되었다고 한다. 악성코드가 포함된 USB의 무분별한 실행이 이란에는 재앙을, 미국에는 외교전의 승리를 안겨준 것이다. 2014년 발생한 카드3사 개인정보유출 사건도 범인이 규정을 넘어선 USB에 의한 개인정보 유출사건이 아니던가?
원자력발전소를 운영하던 한수원은 협력업체 등과 함께 북한에 의해 해킹을 당했지만, 원자력발전소는 침입당하지 않았고 앞으로도 그럴 것이다. 왜냐하면 원자력발전소를 운영하는 SCADA/PLC 시스템은 인터넷과는 연동되지 않았고 앞으로도 마찬가지다. 만약 원자력 발전소는 믿을만한 운영업체가 USB로 업데이트한다면 완벽한 검증과정을 거칠 것으로 보인다.
주요시설의 통제 시스템은 국가가 운영하는 원자력, 철도, 공항 등에만 해당하는 것이 아니다. 삼성전자, SK 등의 반도체 공장이나 컴퓨터 도움이 필요한 FA(Factory Automation) 공장이 인터넷에 곧장 연결이 되어 운영된다면 큰 문제가 발생한다. 기업의 업무지속성(Continue)을 해칠 가능성이 큰 것이다. 보안의 목표 중 가용성(Availability) 유지가 가장 큰 목표인 것이다. 필자의 경험에 의하면 인터넷에서 고객의 요청을 받아 컴퓨터를 제조하는 업체가 악성코드의 일종인 웜 공격을 받아 공장 가동을 멈춘 사고를 지원한 바 있다. 중요 제어시스템을 인터넷 연결하고 연동한다는 것은 매우 위험한 것이다. 아예 물리적인 접속을 하지 않고 USB 등을 이용한 수동적인 운영만이 정답이다.
◇스피어피싱 이메일과 악성코드 감염
한수원 사태 때에는 주로 스팸성 이메일에 악성코드를 첨부하여 보내고 사용자가 속아서 클릭을 유도한 것이다. 소위 ‘스피어 피싱(Spear Phishing)’이라고 한다. ‘스피어 피싱’이란 조직 내의 신뢰받는 특정인을 대상으로 ID 및 패스워드 정보를 요구하는 일종의 피싱 공격이다. 회사의 인력 부서나 기술 부서에서 직원들에게 이름 및 패스워드 업데이트를 요구하는 것처럼 스피어 피싱 행위가 행해진다. 해커는 이로부터 데이터를 획득해 네트워크에 잠입할 수 있다. 또는 사용자로 하여금 스파이웨어가 수행되는 링크에 클릭하도록 유도하는 스피어 피싱도 있다.
.jpg)
2000년대 초반, 국가 기반기술을 다루는 중요 연구소의 연구원이 악성코드가 첨부된 이메일을 받은 적이 있었다. 만약 그가 그 이메일의 첨부파일을 무심코 클릭했으면, 연구소의 모든 기밀이 해킹당했을 것이다. 다행히 그는 클릭하지 않고 이를 보안담당자에게 보고했고, 연구소는 무사할 수 있었다. 하지만 이 사건은 국가의 중요한 연구기밀이 새어나갈 수 있었던 아슬아슬한 위기였다. 사건 이후로 정부에서 망 분리 사업을 시작했다. 공무원들이 사용하는 PC를 업무용과 인터넷용으로 나누어 업무용 PC에는 아예 인터넷이 안 되도록 한 것이다.
◇랜섬웨어 악성코드와 침투전략
2015년 발생한 악성코드 중 랜섬웨어(Ransomware)가 있다. 인터넷 사용자의 컴퓨터에 잠입해 내부 문서나 스프레트시트, 그림파일 등을 암호화해 열지 못하도록 만든 후 돈을 보내주면 해독용 열쇠 프로그램을 전송해 준다며 금품을 요구하는 악성 프로그램이다. ransom(몸값)과 ware(제품)의 합성어로 컴퓨터 사용자의 문서를 ‘인질’로 잡고 돈을 요구한다고 해서 붙여진 명칭이다. 랜섬웨어에 감염될 경우 파일이 복잡한 알고리즘으로 암호화돼 파일을 열어도 내용을 알아 볼 수 없다. 주로 이메일, 소셜네트워크서비스(SNS), 메신저 등을 통해 전송된 첨부파일을 실행하면 감염되며, 웹사이트 방문을 통해 감염되기도 한다. 백신 프로그램으로 악성코드를 없애도 암호화된 파일은 복구되지 않아 ‘사상 최악의 악성코드’라고 불린다. 해커들은 파일을 열 수 있게 해준다는 조건으로 돈을 요구하는데, 기한이 지나면 액수가 더 올라가고 파일을 복구할 수 없게 할 수 있다고 협박하기도 한다.
그런데 모 언론에 의하면 2015년 랜섬웨어 감염자수가 5만 3천명, 피해액수 천억, 해외 유출 피해액수 3백만 달러라고 예측했다. 2016년 예상 감염자수는 15만명, 해외 유출 금액 9백만 불, 피해금액 3천억원을 예측한다는 것이다. 악성코드 피해는 매우 심각하다. 암호화된 컴퓨터와 파일을 해제(복호화)하기 위한 대가로 지불하는 비트코인이다.
랜섬웨어는 기존 보안기술을 무력화하고 급속하게 확산시킬만한 툴을 개발하고 있으며, 사용자의 허술한 데이터관리 허점을 노린다. 또 추적 불가능한 금전거래 방식으로 수익을 얻고 있다. 이러한 랜섬웨어 방어를 위한 최선의 해법은 데이터 백업으로 알려졌다.
2015년 3월 이후 국내에서 랜섬웨어에 가장 많이 감염된 경로는 인터넷(67%)으로 나타났다. 취약한 인터넷 사이트에서 접속만으로도 감염되는 ‘드라이브바이다운로드(Drive-by-download)’를 통한 사례가 가장 많았다. 그 다음으로는 이메일 첨부파일이 25%이며, P2P(파일공유)를 통한 감염은 8%로 집계됐다.
◇악성코드 유입 경로
그렇다면 현재 신종악성코드는 어떻게 우리에게 전달되는가? 만약 USB가 아니라면 무려 10년이 넘도록 적들의 침투전략에 의해 우리의 컴퓨터를 감염시켰나 알아보자.
그림 3은 해외 컴퓨터백신 업체인 Kaspersky에서 2009년에 발표한 자료를 참조한 것이다. 2006년 악성코드를 배달하는 수단이 전자우편에서 웹 서비스가 4배 이상 증가된 내용을 보여주고 있다. 웹을 매개로 하는 내용은 다음 기고에서 다룬다.
.jpg)
웹 Drive by Download 개념
◇3.20 사이버테러 악성코드
2013년 3월 20일 2시 10분경 KBS, MBC, YTN 3개 방송사와 신한은행, 농협, 제주은행 3개 은행의 전산망이 마비되었다. 피해 방송사들은 직원들 PC와 내부 전산망 접속이 되지 않아 방송 제작 업무에 막대한 차질을 빚었다. 직원들이 종이를 들고 뛰고, 현장에 나간 기자들이 온라인 기사 송고를 못해 문자 메시지를 보내고, 팩스를 찾아 헤매는 등 대혼란이 벌어졌다.
비슷한 시간, 농협과 신한은행 서버에도 문제가 생기기 시작했다. 신한은행의 모든 전산이 마비되어 창구 거래, ATM 거래가 중단됐다. 신한은행의 계열사인 제주은행도 모든 거래가 중지됐다. 농협도 내부 전산망을 차단해 모든 거래를 중지시켰다. 은행 전산망이 복구되는 2~3시간 동안 이용자들의 불편이 극에 달했다.
이날 피해 대상이었던 KBS, MBC, YTN 방송사와 신한은행, 농협, 제주은행 이렇게 총 6개 회사가 보유한 약 3만 2천 대의 PC가 일시에 오작동을 일으켰다. 또한 1만 6천여 대의 CD/ATM 기기가 손상됐다. 웹 서버도 피해를 입어 PC에 저장된 방송 데이터와 은행 데이터가 지워졌다. 이 모든 시스템이 정상 복구되는 데는 무려 1개월이 걸렸다.
피해 비용은 얼마나 될까? 단순히 3만2천대 PC의 하드디스크 복구비용만 수십억원 규모다. 사고 이후 KAIST 정보보호대학원이 연구한 결과에 따르면, 시스템 복구비용과 매출이익 손실이 포함된 ‘직접적 피해액’이 약 1,361억 원에 달했으며, 생산효율 저하, 데이터 손실, 예방을 위한 투자비용 등이 포함된 ‘간접적 피해액’은 약 6,600만원으로 추정되었다. 그리고 이미지 손상, 신뢰도 추락, 주가 하락, 법적 보상비 등으로 인한 ‘잠재적 피해액’은 약 7,310억원으로 총 피해액은 약 8,672억 4900만원에 이르렀다.
공격자들은 2012년 6월 이전부터 공격을 준비했다. 그들은 악성코드로부터 정보를 수집하고 공격 지령을 내리는 C&C 서버(Command & Control Server)를 확보하기 시작했다. 해커들은 직접 명령을 내리면 추적을 당하기 때문에 C&C 서버를 만들고 이를 경유해 공격하는 것이 보통이다. 따라서 C&C 서버가 공격 경유지가 된다. 공격자들은 이후 국내의 웹 서버를 해킹하여 악성코드를 유포했다. 피해 기관별로 진행 상황은 조금씩 다르나, 2012년 6월부터 2013년 1월까지 내부 PC 감염이 완료됐다.
악성코드에 감염된 기관 내 PC들이 공격자가 준비한 C&C 서버에 접속하여 내부 전산망의 정보를 보고하고, 추가 악성코드를 다운로드했다. 악성코드에 감염된 PC 중 중요 포인트의 PC들이 2차 C&C 서버에 접속했는데, 이를 통해 공격자가 기관의 망 분석을 끝낸 것으로 보인다. 각 기관들은 직원들 PC의 바이러스 백신을 기관의 업데이트 서버에서 중앙 관리하여 자동 설치하도록 하고 있었다. 이런 백신 업데이트 서버도 해커가 장악했다.
.jpg)
공격자들은 2013년 2월 이전 기관의 전산망 특성에 따라 맞춤형 악성코드를 개발한 것으로 보인다. 2013년 2월 1일, KBS.exe라는 추가 악성코드가 다운로드된 것이 발견됐다. 2월 1일부터 3월 15일까지의 기간 중 기관별로 추가적인 다운로드가 있었던 것으로 추정된다.
사건 발생 20일 후인 4월 10일 중간 조사결과 발표에서는 북한 정찰총국 소행으로 추정된다는 결론이 내려졌다. 그 근거로 다음과 같은 세 가지 사실이 제시됐다. 첫째, 북한 내부에서 국내 C&C 서버에 수시 접속, 장기간 공격을 준비한 점이다. 2012년 6월 28일부터 북한 내부 PC 최소한 6대가 1,590회 접속하여 금융사에 악성코드를 유포하고 PC 저장자료를 절취 및 공격했다.
둘째, C&C 서버 49개 중 22개가 과거 사용했던 경유지와 동일한 점이다. 지금까지 파악된 국내외 C&C 서버 49개(국내 25, 해외 24) 중 22개(국내 18, 해외 4)가 2009년 이후 북한이 대남 해킹에 사용한 걸로 확인된 인터넷 주소와 일치했다. 셋째, 악성코드 76종 중 30종 이상을 재활용한 점이다. 북한 해커들만 고유하게 사용중인 감염PC의 식별번호(8자리 숫자) 및 감염신호 생성코드의 소스프로그램 중 과거와 동일하게 사용된 악성코드가 무려 18종에 달했다.
또한, 사건 발생 8개월 후인 12월 5일, 금융감독원은 3.20 사이버 테러와 관련해 농협 및 신한은행 등의 문제점과 조치결과를 발표했다. 농협(중앙회, 은행, 생명보험, 손해보험)은 방화벽 보안 정책 및 백신 업데이트 서버를 부적절하게 운영한 점 등이, 신한은행과 제주은행은 관리자 계정 관리 부적정 및 백신 업데이트 서버 관리 소홀이 지적됐다.
공격자는 3월 15일 홍콩에서 악성코드를 배포하는 도메인을 등록했다. 본격적인 공격을 개시한 시점으로 볼 수 있다. 3월 17일에 iMBC.exe, SBS.exe 등의 악성코드가 다운로드되는 상황이 발견되어 국내 보안업체 빛스캔의 보안 경고가 나오기도 했다. 이 시점에서 각 기관의 바이러스 백신 업데이트 서버에는 악성코드가 들어가 있었다. 3월 17일부터 20일 사이, 각 기관의 백신 업데이트 서버는 조직 구성원들의 PC에 일제히 백신 업데이트를 실시했는데, 이때 악성코드가 전 기관의 PC에 감염됐다. 감염된 악성코드는 미리 설정된 공격시간을 기다렸다.
3.20 사이버테러가 시사하는 내용은 다음과 같다. 첫째, 백신에 의한 방어책은 공격자가 신종 악성코드 유포 후 탐지, 분석하고 업데이트하는 대응 시간이 길어진다는 구조적인 문제가 있다. 신종 악성코드가 유포되는 시간이 30-40분이라는 점을 생각하면 백신 업데이트 시간은 큰 문제다. 신종 악성코드가 사이버테러의 주된 공격인 상황에서 백신에만 의존하는 국내 조직과 정부의 사이버 보안 대책은 심각한 맹점을 드러낸다. 웹을 통한 악성코드 유포를 빨리 탐지하는 기술을 추가로 활용하는 방안이 요구된다. 사실 이러한 기술은 이미 정부에서 개발되어 운영되고 있다.
또한 3.20 사이버 테러에선 백신 업데이트 서버가 탈취된 것이 가장 큰 문제였다. 보안업체의 업데이트 서버가 악성코드의 숙주가 되어버린 것이다. 이 과정에서 금용기관 등의 잘못이 있었지만, 백신업체의 관리상 잘못도 분명 있었다. 이는 그동안 백신업체의 일상적인 작업에 보다 치밀한 보안관리가 필요함을 뜻한다. 이 사건에서 백신업체들은 그들 자체가 해킹 당하지는 않았다고 하나, 앞으로 더 보안을 강화해야 할 것이다. 백신업체의 보안에 구멍이 뚫린다는 것은 곧 온 국민의 PC에 구멍이 뚫린다는 의미이기 때문이다.
마지막으로 보안의식의 문제다. 금융감독원 자료에 따르면 업무를 수행하는 금융업체 실무자들이 기본적인 보안원칙을 지키지 않았다는 점을 알 수 있다. 일례로 서버에 접속하는 관리자들이 PC에 서버 사용자계정과 비밀번호를 저장하고, 자동 로그인 기능을 썼다. 이러면 PC가 해커에게 넘어가는 순간 서버도 해커의 손에 떨어진다는 얘기다. 아무리 좋은 보안제품을 사용하고, 아무리 근사한 보안정책을 세워도 이렇게 안이한 보안의식이 바뀌지 않는다면 모든 예방책이 무용지물이다. 주어진 보안통제를 지켜야 한다는 의식과 실천이 중요하며 조직은 보안통제 준수율로 조직의 보안성과가 나타나는 것이다.
◇Drive By Downloard(드라이브 바이 다운로드) 동작
2009년 모 공무원은 “클릭해야 악성코드에 감염되는 것 아닌가?”라고 이야기한 바 있었다. 아마 이메일에 첨부된 악성코드 감염만을 고려했던 것 같았다. 당시에는 주로 이메일로 감염된다고 알 수도 있겠다. 하지만 그림 5에서 유입경로 년도를 보면 당시에도 주된 유입경로가 웹이었다. 안타까운 일이었다. 북한이 주로 이메일 감염방식을 이용하므로 그랬다고 할 수 있다. 당시에는 국내 백신업체도 그랬다. 하지만 누가 봐도 10만개의 좀비PC 생성은 이메일 감염으로는 불가능하다.
.jpg)
그렇다면 악성코드나 피싱을 제공하는 Drive By Downloard 사이트가 얼마나 있을까? 이 대답은 구글이 제공하고 있다. 구글은 전 세계 10억개 URL을 분석해 매주 보고를 보여주고 있는데, 약 10만개 악성 URL을 보고한다. 그리고 악성 URL은 수시로 바뀌고 있다.
.jpg)
◇ DBD에 의한 악성코드 감염 경로 분석
이메일에 의한 악성코드 감염 경로는 여기에서의 주된 관심사가 아니다. 어차피 피해기관의 메일 서버 하나의 경로에서 분석 및 탐지할 뿐이다. 그림 7에서 어떤 도메인의 일반 사용자가 악성코드 감염 후 2차, 3차 감염되는 모습을 보이고 있다.
.jpg)
웹 서버 취약성으로 감염되어 악성 홈페이지가 되는 사이트는 너무나 많다. 그림 7의 사례에는 A, B, C 도메인이 있는데 각 도메인은 서로 신뢰할수록 감염속도가 빠르다. 어떤 기업이든 협력업체가 있고 하나만 감염되면 다른 도메인의 사용자를 감염시킬 수 있고, 또 공격할 수 있다. 결국 이는 악성코드에 하나의 시스템만 감염되어도 주위의 여러 도메인이 위험함을 보여주는 것이다. 이 사실로서 다음 2가지를 분석해낼 수 있다.
- 악성URL을 제공하는 웹 서버가 웹 취약점으로부터 안전해야 한다.
- 인터넷 사용자들이 악성 URL에서 악성코드에 감염되지 말아야 한다.
웹 취약성을 제거하기 위한 비용효과적인 방법은 다음 절에서 논의하지만 조직의 구성원이 악성 URL에서 감염당하지 않으려면 다음 6가지 대책이 필요하다. 만약 이것을 지키지 못하는 기업이 있거나 확인이 불가능하다면 어떤 악성URL 홈페이지 서버들이 있는지 가능한 실시간으로 알 수 있어야 막는다.
.jpg)
비용효과적인 웹 취약성 제거 관리방안
◇웹 서버 취약성 제거의 중요성
앞서 악성URL로 드러난 웹서버 등장을 막으려면 웹 서버가 안전하게 SW가 개발되고 유지되어야 함을 알았다. 하지만 국내 150만개 정도의 운영되는 웹서버 모두가 안전하다고 볼 수 없으며 안전하다가 갑자기 안전하지 못한 상태로 바뀌기도 한다. Google Safe Browsing 환경에서 악성URL 이었다가 수개월 후면 안전하지 않은데도 안전한 URL로 바뀌는 경우가 있음을 제자의 논문으로 증명한 바 있다.
.jpg)
모든 기업은 웹을 통해 고객과 협력업체 등과 커뮤니케이션을 열고 있다. 직원의 악성URL 방문만이 문제가 아니라, 기업의 개인정보 유출 방지나 내부망 침투를 막기 위해서도 웹은 안전하게 운영되어야 한다. 최근 개인정보 유출사고를 일으킨 인기 온라인 커뮤니티 ‘뽐뿌’에 대해 1억1700만원의 과징금이 부과됐다. ‘SQL 인젝션’을 통해 회원 약 196만명의 개인정보가 탈취된 것이다.
SQL 인젝션이란 DB에 대한 질의(SQL 구문)를 조작해 정상적인 자료 외에 해커가 원하는 자료까지 DB로부터 유출해가는 사이버 공격 기법이다. 공격당한 웹페이지는 당초 숫자만을 질의할 수 있도록 돼 있었는데, 숫자 외에 ID, 생년월일, 이메일 주소 같은 개인정보를 질의하는 SQL 구문을 삽입해 실행할 수 있는 취약점을 악용당한 것이다. 문제는 인터넷 서비스 업체들이 DB와 연동되는 웹 애플리케이션을 자주 교체함에 따라 DB 입력 인자의 유효성 점검에 의한 보안 검수가 현실적으로 쉽지 않다는 것이다.
인터넷 보안은 무결성(Integrity) 점검이 필수이다. 서비스나 정보의 수정이 필요하다면 정상적인 절차를 거쳐야 함을 말한다. 특히, 웹 애플리케이션 보안 검수는 웹 코드 수정이 이루어질 때마다 반드시 필요한 보안 검수 과장다. 하지만 ‘뽐뿌’를 비롯해 사실상 많은 기업들이 잦은 애플리케이션 수정으로 보안 검수가 현실적으로 어려운 실정이다. 또한 협력업체를 통한 공격이 있을 수 있으므로 대기업은 많은 협력업체에 대한 웹 취약점도 분석해야 한다. 또한 기존의 SDLC(Secure Development Life Cycle) 방식은 즉각적인 검수조사, 즉각적인 재 코딩, 재 검수 등이 이루어지지 않으므로 서버 개수나 잦은 수정에 엄청난 시간과 노력 등의 비용이 요구된다.
◇웹 서버 취약성
2005년 하반기에 가트너(Gartner)가 전체 1000여개 가량의 웹사이트를 상용 웹 애플리케이션 스캐너(Web application scanner)를 이용해 점검한 결과이다. 이에 따르면 98% 가량의 웹 서비스들이 개발된 웹 코드의 문제점으로 보안 취약점을 가지고 있음을 알 수 있다.
.jpg)
온라인 커뮤니티 ‘뽐뿌’ 사고와 2011년 발생한 현대캐피탈 사건에서 볼 수 있듯이 대규모 개인정보 유출이 웹 취약점으로 이루어지는 경우가 대다수다. SQL인젝션, 블라인드 SQL인젝션 등이다. 많은 금융기업 및 인터넷 기업을 고려한다면 큰 문제이다. 다음 표 4에서 웹 중요 공격 분포도가 나타난다.
◇웹 보안 문제점 평가 방법 및 QA(Quality Assurance) 방안
현재 운영 중인 웹 서버가 문제점이 있는지 평가(Assessment) 하는 방법은 먼저 안전함 웹 코딩 방법을 사용해야 한다. 이후 △소스코드 보안평가(Source Code Audit)를 통해 소스코드의 신택스 점검(매우 큰 하중) △스캐너(Attack Scanner)를 이용해 공격자가 하듯 점검할 수 있다.
그런데 웹 서버를 운영하는 조직마다 평가하는 환경이 달라져야 하는 것은 사실이다. 웹 비즈니스가 중요한 인터넷 기업은 많은 웹 업데이트가 있으며, 또한 그렇지 않은 기업도 다량의 웹 서버가 존재한다. 그래서 QA 절차로서 SDLC(Secure Development Life Cycle)을 표준 절차로 이용한다. 이는 평가를 받지 못한 웹 개발 소프트웨어는 서비스를 개시하거나 운영될 수 없다는 절차다.
사실 SDLC는 시스템 구현과정에서 개시, 분석, 설계, 구현, 유지 및 폐기단계에 필요한 보안절차를 규정하는 것이다. 위험한 상태로의 전이는 사업부 개발자의 신규 웹 코딩 이후 나타날 수 있다. 따라서 서비스를 개시하려면 필히 검수과정을 필히 거쳐야 하는 것이다. 웹 비즈니스가 많고 서버 수가 많은 인터넷 기업은 필수적인 절차이지만 노력과 비용에 민감하다. 자체적인 보안 위험 뿐 아니라 정부의 법적 요구사항(Compliance)도 민감한 문제다.
◇어떤 웹 보안취약점을 점검해야 하는가?
정부는 OWASP Top 10을 강제적으로 점검해야 한다는 규정을 ISMS(Information Security Management System)에 두고 있다. 하지만 개인정보 유출 등 취약점 권한 획득 정도를 기준으로 취약점을 평가하는 방법이 요구되는데, 이는 가트너가 제시한 것과 같은 내용이다. 중요도에 따는 등급의 분류는 △정보시스템 정보획득 △개인정보 획득 △정보시스템 통제로 분류하고 5가지 취약점을 필수적으로 점검해야 한다고 제시했다.
◇웹 취약성 점검 대상 및 점검 방안
웹 취약성 대상을 정의하는 것이 중요하다. 중요한 웹 문제점을 알고 개선하기 위해서는 알게 된 웹 취약성을 수정하기 위하여 개발자의 디버깅(Debug)이 필수이다. 그러므로 중요성 우선순위에 따라 점검 빈도수에 따라 점검 비용을 알 수 있다. A등급만을 점검할 경우 장점을 보이면 다음과 같다.
1) 개인정보 유출 등, 중요한 점검만을 할 수 있는 중요한 취약성 집합이다.
2) 공격적인 스캔 점검이 아니므로 웹 서버 운영 중에도 점검이 가능하다.
3) Crawring 점검으로 스캔 점검과 달리 법적인 점검 문제가 없다
4) 국내 운영 중인 전체 웹 서버 취약성 점검이 가능하다.
5) 25%의 우선순위는 떨어지는 점검은 점검 주기를 길게 하여 비용효과성을 높일 수 있다.
◇웹 취약성 QA 절차의 비교분석
SDLC 검수에 의한 프로세스에서 ①사업부서 신규 사업 요구 ②개발 부서에서의 검수 요청 ③보안부서의 검수 및 결과 통보 ④사업부에 완료 통보 ⑤검수된 웹 코드 게재 등의 절차를 가지게 된다. 이 방법은 매우 일반적인 검수방식이지만, 보통 조직은 외부와의 커뮤니케이션으로서 웹을 많이 이용할 수밖에 없으므로 인터넷비즈니스에 종속적인 조직은 신규 웹 애플리케이션의 출현 뿐만 아니라 기존 애플리케이션의 수정도 자주 있으므로 성능과 소요비용이 큰 문제로서 나타난다. 요구부서의 절차와 상관없이 보안검수부서가 능동적으로 검수하여 빠른 시간내 검수가 이루어져 외부에서의 해킹 침투를 가장 적극적인 방법으로 개선할 수 있다.
◇비용구조 분석
조직의 비용 산출을 위한 웹 애플리케이션 취약점 분석 트랜잭션을 분석하는 공식을 정의한다. 소요비용 산출은 서버대수(페이지 수량, 점검회수) 및 인건비이다. 점검회수는 웹 애플리케이션의 중요도에 따라 달라진다. 예를 들어 개인정보를 가진 DB와 연계된 애플리케이션 등은 매일 점검이 필요할 것이다. 각 취약점의 산술적 집합으로 트랜잭션을 가정했다. A는 5개 취약점, B는 25개(OWASP Top 25), C는 50개로 가정한다. 취약점 분석 결과에 대한 디버깅은 SW인건비가 된다. A경우 디버깅에 반나절이 걸리므로 SW개발자 하루 인건비의 절반인 5만원으로 가정했다.
검수 비용 = ∑ ( {Scan}, #Server(혹은 #Page), 점검 회수, 인건비)
- {Scan} ; A, B, C Zone 점검방식 점검 개수
※ 가정 : A Zone ; 5, B Zone : 25, C Zone : 50
- #Server(혹은 # Page) ; 대상 웹 서버(페이지) 개수, 혹은 점검 회수
- 인건비 ; 300만원 MM, 개발자의 코딩 오류 디버깅 비용
[글 _ 임채호 KAIST 초빙교수, KAIST 전산학과 정보보호 전공(hlim@kaist.ac.kr)]
보안통제 준수하려는 의식과 실천이 중요해
[보안뉴스= 임채호 KAIST 초빙교수] ‘스턱스넷(STUX.NET)’은 2010년 7월에 드러난 악성코드다. 공장자동화 등에 쓰이는 독일 지멘스(Siemens)사의 SCADA/PLC라는 부품을 공격했다. SCADA/PLC는 일종의 임베디드 시스템인데, 관리자 PC로 제어된다. 스턱스넷은 먼저 관리자의 PC에 침입하고 이를 경유해 SCADA/PLC에 들어가서 내장된 소프트웨어를 교묘하게 변경해 실제 시설의 성능은 떨어뜨리지만 마치 정상 동작하는 것처럼 관리자 PC에서는 보이도록 했다. 스턱스넷은 여러 버전의 윈도우 OS의 잘 알려지지 않은 약점을 이용했고, 각국의 기존의 백신을 분석하여 탐지 당하지 않도록 매우 뛰어난 기술로 제작되었다.
신종 악성코드 유입경로
스턱스넷은 독일 지멘스 SCADA/PLC에 침투하기는 하는데, 특정한 벤더에서 공급한 특정한 행동을 하는 시설에만 피해를 주도록 제작되어 있었다. 스턱스넷은 핀란드 모 제조사와 이란의 모 제조사가 공급한 시설의, 특정 회전수 범위의 모터를 제어하는 시스템에만 피해를 주었다. 피해를 주는 방법은 모터의 회전수를 가끔 크게 낮춘 후 원상 복귀함으로써 회전수가 잠시 떨어졌다는 것은 관리자 PC에서는 알 수 없도록 한 것이었다. 이란의 핵 시설, 구체적으로 말하면 우라늄을 농축하기 위해 원심분리기를 가동하는 시설이었다.
▲ 그림 1. STUX.NET 개요(출처: IAEA)
그 시설이 하필이면 그 벤더가 공급한 시스템으로 원심분리기의 모터를 제어해 하필이면 그 회전수로 돌리고 있었기 때문이었다. 이게 우연일 수 있을까? 미국이 가장 꺼려하는 이란의 핵 시설이 스턱스넷에 당한 것이 말이다. 보안전문가들은 스턱스넷을 미국이 만든 목표를 찾아가서 정교하게 파괴하는 ‘사이버 유도 미사일’로 보고 있다. 미국이 도청뿐만 아니라 사이버 해킹을 통한 ‘실력 행사’ 능력도 엄청나다는 것을 보여준 사건이다.
◇악성코드와 USB 감염
그런데 사실은 핵 원심분리기 등 SCADA 관련 시설은 운영에 필요한 모든 정보 업데이트는 USB를 이용할 수밖에 없다. 소문에 의하면 스턱스넷 악성코드를 담은 고급 USB가 이란 핵발전소 출근길에 뿌려두었고 누군가 관리자가 이를 주워 사용하다 감염되었다고 한다. 악성코드가 포함된 USB의 무분별한 실행이 이란에는 재앙을, 미국에는 외교전의 승리를 안겨준 것이다. 2014년 발생한 카드3사 개인정보유출 사건도 범인이 규정을 넘어선 USB에 의한 개인정보 유출사건이 아니던가?
원자력발전소를 운영하던 한수원은 협력업체 등과 함께 북한에 의해 해킹을 당했지만, 원자력발전소는 침입당하지 않았고 앞으로도 그럴 것이다. 왜냐하면 원자력발전소를 운영하는 SCADA/PLC 시스템은 인터넷과는 연동되지 않았고 앞으로도 마찬가지다. 만약 원자력 발전소는 믿을만한 운영업체가 USB로 업데이트한다면 완벽한 검증과정을 거칠 것으로 보인다.
주요시설의 통제 시스템은 국가가 운영하는 원자력, 철도, 공항 등에만 해당하는 것이 아니다. 삼성전자, SK 등의 반도체 공장이나 컴퓨터 도움이 필요한 FA(Factory Automation) 공장이 인터넷에 곧장 연결이 되어 운영된다면 큰 문제가 발생한다. 기업의 업무지속성(Continue)을 해칠 가능성이 큰 것이다. 보안의 목표 중 가용성(Availability) 유지가 가장 큰 목표인 것이다. 필자의 경험에 의하면 인터넷에서 고객의 요청을 받아 컴퓨터를 제조하는 업체가 악성코드의 일종인 웜 공격을 받아 공장 가동을 멈춘 사고를 지원한 바 있다. 중요 제어시스템을 인터넷 연결하고 연동한다는 것은 매우 위험한 것이다. 아예 물리적인 접속을 하지 않고 USB 등을 이용한 수동적인 운영만이 정답이다.
◇스피어피싱 이메일과 악성코드 감염
한수원 사태 때에는 주로 스팸성 이메일에 악성코드를 첨부하여 보내고 사용자가 속아서 클릭을 유도한 것이다. 소위 ‘스피어 피싱(Spear Phishing)’이라고 한다. ‘스피어 피싱’이란 조직 내의 신뢰받는 특정인을 대상으로 ID 및 패스워드 정보를 요구하는 일종의 피싱 공격이다. 회사의 인력 부서나 기술 부서에서 직원들에게 이름 및 패스워드 업데이트를 요구하는 것처럼 스피어 피싱 행위가 행해진다. 해커는 이로부터 데이터를 획득해 네트워크에 잠입할 수 있다. 또는 사용자로 하여금 스파이웨어가 수행되는 링크에 클릭하도록 유도하는 스피어 피싱도 있다.
▲ 그림 2. 거짓 정보로 악성코드를 유도하는 사례
2000년대 초반, 국가 기반기술을 다루는 중요 연구소의 연구원이 악성코드가 첨부된 이메일을 받은 적이 있었다. 만약 그가 그 이메일의 첨부파일을 무심코 클릭했으면, 연구소의 모든 기밀이 해킹당했을 것이다. 다행히 그는 클릭하지 않고 이를 보안담당자에게 보고했고, 연구소는 무사할 수 있었다. 하지만 이 사건은 국가의 중요한 연구기밀이 새어나갈 수 있었던 아슬아슬한 위기였다. 사건 이후로 정부에서 망 분리 사업을 시작했다. 공무원들이 사용하는 PC를 업무용과 인터넷용으로 나누어 업무용 PC에는 아예 인터넷이 안 되도록 한 것이다.
◇랜섬웨어 악성코드와 침투전략
2015년 발생한 악성코드 중 랜섬웨어(Ransomware)가 있다. 인터넷 사용자의 컴퓨터에 잠입해 내부 문서나 스프레트시트, 그림파일 등을 암호화해 열지 못하도록 만든 후 돈을 보내주면 해독용 열쇠 프로그램을 전송해 준다며 금품을 요구하는 악성 프로그램이다. ransom(몸값)과 ware(제품)의 합성어로 컴퓨터 사용자의 문서를 ‘인질’로 잡고 돈을 요구한다고 해서 붙여진 명칭이다. 랜섬웨어에 감염될 경우 파일이 복잡한 알고리즘으로 암호화돼 파일을 열어도 내용을 알아 볼 수 없다. 주로 이메일, 소셜네트워크서비스(SNS), 메신저 등을 통해 전송된 첨부파일을 실행하면 감염되며, 웹사이트 방문을 통해 감염되기도 한다. 백신 프로그램으로 악성코드를 없애도 암호화된 파일은 복구되지 않아 ‘사상 최악의 악성코드’라고 불린다. 해커들은 파일을 열 수 있게 해준다는 조건으로 돈을 요구하는데, 기한이 지나면 액수가 더 올라가고 파일을 복구할 수 없게 할 수 있다고 협박하기도 한다.
그런데 모 언론에 의하면 2015년 랜섬웨어 감염자수가 5만 3천명, 피해액수 천억, 해외 유출 피해액수 3백만 달러라고 예측했다. 2016년 예상 감염자수는 15만명, 해외 유출 금액 9백만 불, 피해금액 3천억원을 예측한다는 것이다. 악성코드 피해는 매우 심각하다. 암호화된 컴퓨터와 파일을 해제(복호화)하기 위한 대가로 지불하는 비트코인이다.
랜섬웨어는 기존 보안기술을 무력화하고 급속하게 확산시킬만한 툴을 개발하고 있으며, 사용자의 허술한 데이터관리 허점을 노린다. 또 추적 불가능한 금전거래 방식으로 수익을 얻고 있다. 이러한 랜섬웨어 방어를 위한 최선의 해법은 데이터 백업으로 알려졌다.
2015년 3월 이후 국내에서 랜섬웨어에 가장 많이 감염된 경로는 인터넷(67%)으로 나타났다. 취약한 인터넷 사이트에서 접속만으로도 감염되는 ‘드라이브바이다운로드(Drive-by-download)’를 통한 사례가 가장 많았다. 그 다음으로는 이메일 첨부파일이 25%이며, P2P(파일공유)를 통한 감염은 8%로 집계됐다.
◇악성코드 유입 경로
그렇다면 현재 신종악성코드는 어떻게 우리에게 전달되는가? 만약 USB가 아니라면 무려 10년이 넘도록 적들의 침투전략에 의해 우리의 컴퓨터를 감염시켰나 알아보자.
그림 3은 해외 컴퓨터백신 업체인 Kaspersky에서 2009년에 발표한 자료를 참조한 것이다. 2006년 악성코드를 배달하는 수단이 전자우편에서 웹 서비스가 4배 이상 증가된 내용을 보여주고 있다. 웹을 매개로 하는 내용은 다음 기고에서 다룬다.
▲ 그림 3. 악성코드 유입경로
웹 Drive by Download 개념
◇3.20 사이버테러 악성코드
2013년 3월 20일 2시 10분경 KBS, MBC, YTN 3개 방송사와 신한은행, 농협, 제주은행 3개 은행의 전산망이 마비되었다. 피해 방송사들은 직원들 PC와 내부 전산망 접속이 되지 않아 방송 제작 업무에 막대한 차질을 빚었다. 직원들이 종이를 들고 뛰고, 현장에 나간 기자들이 온라인 기사 송고를 못해 문자 메시지를 보내고, 팩스를 찾아 헤매는 등 대혼란이 벌어졌다.
비슷한 시간, 농협과 신한은행 서버에도 문제가 생기기 시작했다. 신한은행의 모든 전산이 마비되어 창구 거래, ATM 거래가 중단됐다. 신한은행의 계열사인 제주은행도 모든 거래가 중지됐다. 농협도 내부 전산망을 차단해 모든 거래를 중지시켰다. 은행 전산망이 복구되는 2~3시간 동안 이용자들의 불편이 극에 달했다.
이날 피해 대상이었던 KBS, MBC, YTN 방송사와 신한은행, 농협, 제주은행 이렇게 총 6개 회사가 보유한 약 3만 2천 대의 PC가 일시에 오작동을 일으켰다. 또한 1만 6천여 대의 CD/ATM 기기가 손상됐다. 웹 서버도 피해를 입어 PC에 저장된 방송 데이터와 은행 데이터가 지워졌다. 이 모든 시스템이 정상 복구되는 데는 무려 1개월이 걸렸다.
피해 비용은 얼마나 될까? 단순히 3만2천대 PC의 하드디스크 복구비용만 수십억원 규모다. 사고 이후 KAIST 정보보호대학원이 연구한 결과에 따르면, 시스템 복구비용과 매출이익 손실이 포함된 ‘직접적 피해액’이 약 1,361억 원에 달했으며, 생산효율 저하, 데이터 손실, 예방을 위한 투자비용 등이 포함된 ‘간접적 피해액’은 약 6,600만원으로 추정되었다. 그리고 이미지 손상, 신뢰도 추락, 주가 하락, 법적 보상비 등으로 인한 ‘잠재적 피해액’은 약 7,310억원으로 총 피해액은 약 8,672억 4900만원에 이르렀다.
공격자들은 2012년 6월 이전부터 공격을 준비했다. 그들은 악성코드로부터 정보를 수집하고 공격 지령을 내리는 C&C 서버(Command & Control Server)를 확보하기 시작했다. 해커들은 직접 명령을 내리면 추적을 당하기 때문에 C&C 서버를 만들고 이를 경유해 공격하는 것이 보통이다. 따라서 C&C 서버가 공격 경유지가 된다. 공격자들은 이후 국내의 웹 서버를 해킹하여 악성코드를 유포했다. 피해 기관별로 진행 상황은 조금씩 다르나, 2012년 6월부터 2013년 1월까지 내부 PC 감염이 완료됐다.
악성코드에 감염된 기관 내 PC들이 공격자가 준비한 C&C 서버에 접속하여 내부 전산망의 정보를 보고하고, 추가 악성코드를 다운로드했다. 악성코드에 감염된 PC 중 중요 포인트의 PC들이 2차 C&C 서버에 접속했는데, 이를 통해 공격자가 기관의 망 분석을 끝낸 것으로 보인다. 각 기관들은 직원들 PC의 바이러스 백신을 기관의 업데이트 서버에서 중앙 관리하여 자동 설치하도록 하고 있었다. 이런 백신 업데이트 서버도 해커가 장악했다.
▲ 그림 4. 3.20 사이버 테러 관련 기간 악성코드 의심 파일과 관련된 악성링크의 차단 수치 (출처:트라이큐브랩)
공격자들은 2013년 2월 이전 기관의 전산망 특성에 따라 맞춤형 악성코드를 개발한 것으로 보인다. 2013년 2월 1일, KBS.exe라는 추가 악성코드가 다운로드된 것이 발견됐다. 2월 1일부터 3월 15일까지의 기간 중 기관별로 추가적인 다운로드가 있었던 것으로 추정된다.
사건 발생 20일 후인 4월 10일 중간 조사결과 발표에서는 북한 정찰총국 소행으로 추정된다는 결론이 내려졌다. 그 근거로 다음과 같은 세 가지 사실이 제시됐다. 첫째, 북한 내부에서 국내 C&C 서버에 수시 접속, 장기간 공격을 준비한 점이다. 2012년 6월 28일부터 북한 내부 PC 최소한 6대가 1,590회 접속하여 금융사에 악성코드를 유포하고 PC 저장자료를 절취 및 공격했다.
둘째, C&C 서버 49개 중 22개가 과거 사용했던 경유지와 동일한 점이다. 지금까지 파악된 국내외 C&C 서버 49개(국내 25, 해외 24) 중 22개(국내 18, 해외 4)가 2009년 이후 북한이 대남 해킹에 사용한 걸로 확인된 인터넷 주소와 일치했다. 셋째, 악성코드 76종 중 30종 이상을 재활용한 점이다. 북한 해커들만 고유하게 사용중인 감염PC의 식별번호(8자리 숫자) 및 감염신호 생성코드의 소스프로그램 중 과거와 동일하게 사용된 악성코드가 무려 18종에 달했다.
또한, 사건 발생 8개월 후인 12월 5일, 금융감독원은 3.20 사이버 테러와 관련해 농협 및 신한은행 등의 문제점과 조치결과를 발표했다. 농협(중앙회, 은행, 생명보험, 손해보험)은 방화벽 보안 정책 및 백신 업데이트 서버를 부적절하게 운영한 점 등이, 신한은행과 제주은행은 관리자 계정 관리 부적정 및 백신 업데이트 서버 관리 소홀이 지적됐다.
공격자는 3월 15일 홍콩에서 악성코드를 배포하는 도메인을 등록했다. 본격적인 공격을 개시한 시점으로 볼 수 있다. 3월 17일에 iMBC.exe, SBS.exe 등의 악성코드가 다운로드되는 상황이 발견되어 국내 보안업체 빛스캔의 보안 경고가 나오기도 했다. 이 시점에서 각 기관의 바이러스 백신 업데이트 서버에는 악성코드가 들어가 있었다. 3월 17일부터 20일 사이, 각 기관의 백신 업데이트 서버는 조직 구성원들의 PC에 일제히 백신 업데이트를 실시했는데, 이때 악성코드가 전 기관의 PC에 감염됐다. 감염된 악성코드는 미리 설정된 공격시간을 기다렸다.
3.20 사이버테러가 시사하는 내용은 다음과 같다. 첫째, 백신에 의한 방어책은 공격자가 신종 악성코드 유포 후 탐지, 분석하고 업데이트하는 대응 시간이 길어진다는 구조적인 문제가 있다. 신종 악성코드가 유포되는 시간이 30-40분이라는 점을 생각하면 백신 업데이트 시간은 큰 문제다. 신종 악성코드가 사이버테러의 주된 공격인 상황에서 백신에만 의존하는 국내 조직과 정부의 사이버 보안 대책은 심각한 맹점을 드러낸다. 웹을 통한 악성코드 유포를 빨리 탐지하는 기술을 추가로 활용하는 방안이 요구된다. 사실 이러한 기술은 이미 정부에서 개발되어 운영되고 있다.
또한 3.20 사이버 테러에선 백신 업데이트 서버가 탈취된 것이 가장 큰 문제였다. 보안업체의 업데이트 서버가 악성코드의 숙주가 되어버린 것이다. 이 과정에서 금용기관 등의 잘못이 있었지만, 백신업체의 관리상 잘못도 분명 있었다. 이는 그동안 백신업체의 일상적인 작업에 보다 치밀한 보안관리가 필요함을 뜻한다. 이 사건에서 백신업체들은 그들 자체가 해킹 당하지는 않았다고 하나, 앞으로 더 보안을 강화해야 할 것이다. 백신업체의 보안에 구멍이 뚫린다는 것은 곧 온 국민의 PC에 구멍이 뚫린다는 의미이기 때문이다.
마지막으로 보안의식의 문제다. 금융감독원 자료에 따르면 업무를 수행하는 금융업체 실무자들이 기본적인 보안원칙을 지키지 않았다는 점을 알 수 있다. 일례로 서버에 접속하는 관리자들이 PC에 서버 사용자계정과 비밀번호를 저장하고, 자동 로그인 기능을 썼다. 이러면 PC가 해커에게 넘어가는 순간 서버도 해커의 손에 떨어진다는 얘기다. 아무리 좋은 보안제품을 사용하고, 아무리 근사한 보안정책을 세워도 이렇게 안이한 보안의식이 바뀌지 않는다면 모든 예방책이 무용지물이다. 주어진 보안통제를 지켜야 한다는 의식과 실천이 중요하며 조직은 보안통제 준수율로 조직의 보안성과가 나타나는 것이다.
◇Drive By Downloard(드라이브 바이 다운로드) 동작
2009년 모 공무원은 “클릭해야 악성코드에 감염되는 것 아닌가?”라고 이야기한 바 있었다. 아마 이메일에 첨부된 악성코드 감염만을 고려했던 것 같았다. 당시에는 주로 이메일로 감염된다고 알 수도 있겠다. 하지만 그림 5에서 유입경로 년도를 보면 당시에도 주된 유입경로가 웹이었다. 안타까운 일이었다. 북한이 주로 이메일 감염방식을 이용하므로 그랬다고 할 수 있다. 당시에는 국내 백신업체도 그랬다. 하지만 누가 봐도 10만개의 좀비PC 생성은 이메일 감염으로는 불가능하다.
▲ 그림 5. Drive by Download 방식 동작 개념도
그렇다면 악성코드나 피싱을 제공하는 Drive By Downloard 사이트가 얼마나 있을까? 이 대답은 구글이 제공하고 있다. 구글은 전 세계 10억개 URL을 분석해 매주 보고를 보여주고 있는데, 약 10만개 악성 URL을 보고한다. 그리고 악성 URL은 수시로 바뀌고 있다.
▲ 그림 6. 구글이 제공하는 악성 URL
◇ DBD에 의한 악성코드 감염 경로 분석
이메일에 의한 악성코드 감염 경로는 여기에서의 주된 관심사가 아니다. 어차피 피해기관의 메일 서버 하나의 경로에서 분석 및 탐지할 뿐이다. 그림 7에서 어떤 도메인의 일반 사용자가 악성코드 감염 후 2차, 3차 감염되는 모습을 보이고 있다.
▲ 그림 7. DBD에 의한 악성코드 감염 개념도
웹 서버 취약성으로 감염되어 악성 홈페이지가 되는 사이트는 너무나 많다. 그림 7의 사례에는 A, B, C 도메인이 있는데 각 도메인은 서로 신뢰할수록 감염속도가 빠르다. 어떤 기업이든 협력업체가 있고 하나만 감염되면 다른 도메인의 사용자를 감염시킬 수 있고, 또 공격할 수 있다. 결국 이는 악성코드에 하나의 시스템만 감염되어도 주위의 여러 도메인이 위험함을 보여주는 것이다. 이 사실로서 다음 2가지를 분석해낼 수 있다.
- 악성URL을 제공하는 웹 서버가 웹 취약점으로부터 안전해야 한다.
- 인터넷 사용자들이 악성 URL에서 악성코드에 감염되지 말아야 한다.
웹 취약성을 제거하기 위한 비용효과적인 방법은 다음 절에서 논의하지만 조직의 구성원이 악성 URL에서 감염당하지 않으려면 다음 6가지 대책이 필요하다. 만약 이것을 지키지 못하는 기업이 있거나 확인이 불가능하다면 어떤 악성URL 홈페이지 서버들이 있는지 가능한 실시간으로 알 수 있어야 막는다.
▲ 표 1. DBD 방지 6가지 대책
비용효과적인 웹 취약성 제거 관리방안
◇웹 서버 취약성 제거의 중요성
앞서 악성URL로 드러난 웹서버 등장을 막으려면 웹 서버가 안전하게 SW가 개발되고 유지되어야 함을 알았다. 하지만 국내 150만개 정도의 운영되는 웹서버 모두가 안전하다고 볼 수 없으며 안전하다가 갑자기 안전하지 못한 상태로 바뀌기도 한다. Google Safe Browsing 환경에서 악성URL 이었다가 수개월 후면 안전하지 않은데도 안전한 URL로 바뀌는 경우가 있음을 제자의 논문으로 증명한 바 있다.
▲ 그림 8. 구글 Safe Browsing 악성 URL 문제점
모든 기업은 웹을 통해 고객과 협력업체 등과 커뮤니케이션을 열고 있다. 직원의 악성URL 방문만이 문제가 아니라, 기업의 개인정보 유출 방지나 내부망 침투를 막기 위해서도 웹은 안전하게 운영되어야 한다. 최근 개인정보 유출사고를 일으킨 인기 온라인 커뮤니티 ‘뽐뿌’에 대해 1억1700만원의 과징금이 부과됐다. ‘SQL 인젝션’을 통해 회원 약 196만명의 개인정보가 탈취된 것이다.
SQL 인젝션이란 DB에 대한 질의(SQL 구문)를 조작해 정상적인 자료 외에 해커가 원하는 자료까지 DB로부터 유출해가는 사이버 공격 기법이다. 공격당한 웹페이지는 당초 숫자만을 질의할 수 있도록 돼 있었는데, 숫자 외에 ID, 생년월일, 이메일 주소 같은 개인정보를 질의하는 SQL 구문을 삽입해 실행할 수 있는 취약점을 악용당한 것이다. 문제는 인터넷 서비스 업체들이 DB와 연동되는 웹 애플리케이션을 자주 교체함에 따라 DB 입력 인자의 유효성 점검에 의한 보안 검수가 현실적으로 쉽지 않다는 것이다.
인터넷 보안은 무결성(Integrity) 점검이 필수이다. 서비스나 정보의 수정이 필요하다면 정상적인 절차를 거쳐야 함을 말한다. 특히, 웹 애플리케이션 보안 검수는 웹 코드 수정이 이루어질 때마다 반드시 필요한 보안 검수 과장다. 하지만 ‘뽐뿌’를 비롯해 사실상 많은 기업들이 잦은 애플리케이션 수정으로 보안 검수가 현실적으로 어려운 실정이다. 또한 협력업체를 통한 공격이 있을 수 있으므로 대기업은 많은 협력업체에 대한 웹 취약점도 분석해야 한다. 또한 기존의 SDLC(Secure Development Life Cycle) 방식은 즉각적인 검수조사, 즉각적인 재 코딩, 재 검수 등이 이루어지지 않으므로 서버 개수나 잦은 수정에 엄청난 시간과 노력 등의 비용이 요구된다.
◇웹 서버 취약성
2005년 하반기에 가트너(Gartner)가 전체 1000여개 가량의 웹사이트를 상용 웹 애플리케이션 스캐너(Web application scanner)를 이용해 점검한 결과이다. 이에 따르면 98% 가량의 웹 서비스들이 개발된 웹 코드의 문제점으로 보안 취약점을 가지고 있음을 알 수 있다.
▲ 표 2. 웹 취약점(2005, 가트너)
온라인 커뮤니티 ‘뽐뿌’ 사고와 2011년 발생한 현대캐피탈 사건에서 볼 수 있듯이 대규모 개인정보 유출이 웹 취약점으로 이루어지는 경우가 대다수다. SQL인젝션, 블라인드 SQL인젝션 등이다. 많은 금융기업 및 인터넷 기업을 고려한다면 큰 문제이다. 다음 표 4에서 웹 중요 공격 분포도가 나타난다.
◇웹 보안 문제점 평가 방법 및 QA(Quality Assurance) 방안
현재 운영 중인 웹 서버가 문제점이 있는지 평가(Assessment) 하는 방법은 먼저 안전함 웹 코딩 방법을 사용해야 한다. 이후 △소스코드 보안평가(Source Code Audit)를 통해 소스코드의 신택스 점검(매우 큰 하중) △스캐너(Attack Scanner)를 이용해 공격자가 하듯 점검할 수 있다.
그런데 웹 서버를 운영하는 조직마다 평가하는 환경이 달라져야 하는 것은 사실이다. 웹 비즈니스가 중요한 인터넷 기업은 많은 웹 업데이트가 있으며, 또한 그렇지 않은 기업도 다량의 웹 서버가 존재한다. 그래서 QA 절차로서 SDLC(Secure Development Life Cycle)을 표준 절차로 이용한다. 이는 평가를 받지 못한 웹 개발 소프트웨어는 서비스를 개시하거나 운영될 수 없다는 절차다.
사실 SDLC는 시스템 구현과정에서 개시, 분석, 설계, 구현, 유지 및 폐기단계에 필요한 보안절차를 규정하는 것이다. 위험한 상태로의 전이는 사업부 개발자의 신규 웹 코딩 이후 나타날 수 있다. 따라서 서비스를 개시하려면 필히 검수과정을 필히 거쳐야 하는 것이다. 웹 비즈니스가 많고 서버 수가 많은 인터넷 기업은 필수적인 절차이지만 노력과 비용에 민감하다. 자체적인 보안 위험 뿐 아니라 정부의 법적 요구사항(Compliance)도 민감한 문제다.
◇어떤 웹 보안취약점을 점검해야 하는가?
정부는 OWASP Top 10을 강제적으로 점검해야 한다는 규정을 ISMS(Information Security Management System)에 두고 있다. 하지만 개인정보 유출 등 취약점 권한 획득 정도를 기준으로 취약점을 평가하는 방법이 요구되는데, 이는 가트너가 제시한 것과 같은 내용이다. 중요도에 따는 등급의 분류는 △정보시스템 정보획득 △개인정보 획득 △정보시스템 통제로 분류하고 5가지 취약점을 필수적으로 점검해야 한다고 제시했다.
◇웹 취약성 점검 대상 및 점검 방안
웹 취약성 대상을 정의하는 것이 중요하다. 중요한 웹 문제점을 알고 개선하기 위해서는 알게 된 웹 취약성을 수정하기 위하여 개발자의 디버깅(Debug)이 필수이다. 그러므로 중요성 우선순위에 따라 점검 빈도수에 따라 점검 비용을 알 수 있다. A등급만을 점검할 경우 장점을 보이면 다음과 같다.
1) 개인정보 유출 등, 중요한 점검만을 할 수 있는 중요한 취약성 집합이다.
2) 공격적인 스캔 점검이 아니므로 웹 서버 운영 중에도 점검이 가능하다.
3) Crawring 점검으로 스캔 점검과 달리 법적인 점검 문제가 없다
4) 국내 운영 중인 전체 웹 서버 취약성 점검이 가능하다.
5) 25%의 우선순위는 떨어지는 점검은 점검 주기를 길게 하여 비용효과성을 높일 수 있다.
◇웹 취약성 QA 절차의 비교분석
SDLC 검수에 의한 프로세스에서 ①사업부서 신규 사업 요구 ②개발 부서에서의 검수 요청 ③보안부서의 검수 및 결과 통보 ④사업부에 완료 통보 ⑤검수된 웹 코드 게재 등의 절차를 가지게 된다. 이 방법은 매우 일반적인 검수방식이지만, 보통 조직은 외부와의 커뮤니케이션으로서 웹을 많이 이용할 수밖에 없으므로 인터넷비즈니스에 종속적인 조직은 신규 웹 애플리케이션의 출현 뿐만 아니라 기존 애플리케이션의 수정도 자주 있으므로 성능과 소요비용이 큰 문제로서 나타난다. 요구부서의 절차와 상관없이 보안검수부서가 능동적으로 검수하여 빠른 시간내 검수가 이루어져 외부에서의 해킹 침투를 가장 적극적인 방법으로 개선할 수 있다.
◇비용구조 분석
조직의 비용 산출을 위한 웹 애플리케이션 취약점 분석 트랜잭션을 분석하는 공식을 정의한다. 소요비용 산출은 서버대수(페이지 수량, 점검회수) 및 인건비이다. 점검회수는 웹 애플리케이션의 중요도에 따라 달라진다. 예를 들어 개인정보를 가진 DB와 연계된 애플리케이션 등은 매일 점검이 필요할 것이다. 각 취약점의 산술적 집합으로 트랜잭션을 가정했다. A는 5개 취약점, B는 25개(OWASP Top 25), C는 50개로 가정한다. 취약점 분석 결과에 대한 디버깅은 SW인건비가 된다. A경우 디버깅에 반나절이 걸리므로 SW개발자 하루 인건비의 절반인 5만원으로 가정했다.
검수 비용 = ∑ ( {Scan}, #Server(혹은 #Page), 점검 회수, 인건비)
- {Scan} ; A, B, C Zone 점검방식 점검 개수
※ 가정 : A Zone ; 5, B Zone : 25, C Zone : 50
- #Server(혹은 # Page) ; 대상 웹 서버(페이지) 개수, 혹은 점검 회수
- 인건비 ; 300만원 MM, 개발자의 코딩 오류 디버깅 비용
[글 _ 임채호 KAIST 초빙교수, KAIST 전산학과 정보보호 전공(hlim@kaist.ac.kr)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
김태형기자 기사보기
[2024-11-14] .jpg)
.jpg)
