|
|
자유게시판입니다. 아무 글이나 올려 주세요. 
|
|
11
버그트럭 커뮤니티 내부적으로 보안 관련 종사자들의 의견을 이제는 점차 밖으로 드러내어야 한다는 분위기가 일어 서고 있습니다. 원래 보안쪽 방면 사람들이 외부적으로 드러 내려고 하지를 않는 경향이 있는데 지금은 어쩔 수 없는 상황인 것 같고, 저도 거기에 동참할 수 밖에 없다는 생각이 들었습니다.
첫 테이프를 끊은 김휘강님의 글 : http://blog.hksecurity.net/2009/04/1.html
ActiveX 같은 것도 얘기해 보고 싶지만, 저보다 더 전문가 분들이 많이 있으므로 저는 제가 알고 있는 것 중심으로 얘기를 해 보도록 하겠습니다. 참고로 본 글에는 제가 가지고 있는 지식, 지식을 습득하게 된 배경, 오픈웹과의 입장 차이, 그리고 개인적으로 다분히 격한 감정적인 느낌이 포함되어 있음을 우선 말씀드립니다.
[SSL은 무엇인가?]
SSL은 현재 인터넷 통신에 있어서 암호 통신에서 가장 많이 사용되어 지는 암호화 기법중의 하나입니다. 암호 알고리즘이 수학을 바탕으로 고안이 되고, 관련 모듈들이 배포가 되고, 여러 업체, 여러 서비스에 적용이 되면서 점차 그 것이 확산이 되게 되었습니다. 게다가 SSL은 모든 소스가 공개가 되어 있고 오픈소스이기 때문에 다양한 플랫폼에서 구현이 가능하게 됩니다. 이렇게 오픈소스로 많은 개발자/개발업체로 하여금 쉽게 접근할 수 있도록 한 것도 SSL이 널리 보급되게 된 중요한 요인중의 하나로 볼 수 있습니다.
[SSL은 표준인가?]
SSL이 표준이냐 아니냐를 얘기하기 이전에 우선 "표준"이란 무엇인가를 먼저 정의할 필요가 있습니다.
원래 TCP/IP 는 미국방성에서만 사용되던 방식이었습니다. 처음에는 외부 공개도 되지 않았었죠. 그런데 지금은 거의 "표준"으로 자리 잡고 있습니다. VLan을 나누는데 사용되어 지는 VLan Tag도 원래는 Cisco 장비에서만 사용되던 기법이었습니다. 그런데 지금은 VLan Tag 사용 방식이 거의 표준 방식으로 사용되어 지고 있습니다. 그런데 왜 그러한 것들이 "표준"이 되었을까요? 그것은 바로 오랜 시간을 두고 널리 확산이 되었기 때문에 그렇습니다.
"시간이 지나서 전문가들이 모여 위원회를 만들어 빵굽기를 하고 RFC문서에 등재를 해야먄 표준이다"라는 것보다 "많이 사용되면 표준으로 인정을 받게 된다"라는 것이 더 현실적이고 적합한 말일 것입니다. 만약에 SSL이 나오기 이전에 한국에서 먼저 훌륭한 암호화 기법이 고안이 되고 확산되었더라면 그것이 전세계 표준으로 자리 잡았을 것입니다.
SSL 암호 기법은 현재 웹분야(HTTP over SSL)뿐만 아니라, VoIP 분야(SIP over TLS), 또한 자체 제품(Network Appliane, C/S 기반 Application)에서도 많이 사용되어 지고 있습니다. 결론적으로 현재 SSL 은 "표준"으로 불릴만한 충분한 자격 요건을 갖추고 있습니다(물론 지금은 SSL과 관련된 무수히 많은 RFC 문서가 존재합니다).
참고로 오랫동안 VoIP 통신에서 표준 터줏대감으로 자리잡고 있는 H323 프로토콜은 이제 SIP에게 자리를 물려 주고 있고 지금은 찬밥 신세로 전락하고 있습니다. "표준"이기 때문에 좋은 것이 아니라 "좋은 것"이기 때문에 표준이 되는 것입니다.
[SSL 지식 습득 배경]
저는 "어떻게 하면 안전하게 데이터를 송수신할 수 있을까?"에서 시작한 것이 아니라 "어떻게 하면 이 암호를 풀 수 있을까?" 라고 하는 정 반대된 개념에서부터 SSL에 관심을 가지기 시작하였습니다. 패킷을 잡으면서도 처음에는 그냥 "암호화가 되어 있구나" 정도였지 예전에는 그것이 SSL 기반인지도 몰랐었구요, 점차 시간이 지나면서 그것이 SSL이었음을 알게 되었습니다.
SSL을 본격적으로 공부를 한 것이 제작년 초부터였습니다. 술자리에서 같이 프로젝트를 진행하는 사람과 우연히 SSL 얘기를 나누게 되었는데 알고 보니 예전에 국내 모 기업에서 SSL 핵심 모듈을 담당했었던 엔지니어였더라구요. 짧은 몇시간이었었지만 책 몇권 읽는 것보다 더 많은 정보를 얻을 수 있었습니다. 아무튼 그렇게 해서 SSL에 대해서 본격적인 관심을 가지게 되었고 공부를 하기 시작하였습니다.
평소 "백문이 불여일견"보다는 "백견이 불여일타"라는 생각을 가진 저는 오픈소소를 인터넷에서 다운받아서 소스를 분석을 하기 시작하였습니다. 이런 저런 API와 내부 구조를 살펴 보면서 SSL에 대한 지식을 습득하게 되었고, 거기에서부터 "SSL을 우회할 수 있는" 방법을 알아 내게 되었습니다.
SSL분석을 시작했을 때부터 SSL 데이터를 분석(스니핑하여 내용을 알아 내기)까지 그리 오랜 시간이 걸리지 않았습니다. 프로그램을 만들고 나서 바로 그 엔지니어(SSL 전문가)에게 보여 줬더니 놀라더라구요. 어떻게 이렇게 금방 SSL을 뚫을 수 있나구요. 사실 알고 보면 별거 아니고, 외국에서는 이미 예전부터 알려 져 왔었것인데 말이죠.
그 이후로 많은 SSL 우회 기법에 대한 프로그램들과 자료들을 관심을 가지고 분석을 했습니다. 그 결과 "SSL은 충분히 훌륭한 암호화 기법이지만 100% 신뢰해서는 안된다" 라는 결론을 내렸습니다. 다른 많은 회의, 발표 등에서 이 점을 항상 강조했었습니다.
그러다가 저의 발표가 국내 보안서버 보급에 지장을 줄 수 있다는 이유로 다른 이들과 입장 차이( http://www.youtube.com/watch?v=tSRtQiDfd90 )가 발생했고, 인해 정부 기관 관계자들과 일부 마찰이 있었던 것도 사실입니다. 동영상 기록으로 다 남길 수가 없어서 그렇지 거의 협박 수준이었던 적도 있었습니다.
그런데, 뭐랄까... 이러한 사실(SSL은 100% 믿어서는 안된다를 얘기하는 것)이 오픈웹 입장에서는 "웹의 표준화에 이경문이라는 사람은 반대를 하는 사람" 라고 단정지을 수도 있겠다는 생각까지 듭니다. 해석은 여러분에게 맡기겠습니다.
[오픈웹]
얼마전부터 오픈웹의 글들이 눈에 띄기 시작했습니다. 웹의 표준화에 특정업체를 거론하면서 도덕적인 문제를 일삼고 있는데, 처음에는 좀 의아한 정도로만 보였었습니다. 버그트럭에서도 이 얘기가 이슈화되기 시작하였고, 저도 관심을 가지고 해당 사이트를 보게 되었죠. 시간이 갈수록 보안업계 전에의 심기를 충분히 건드릴 수 있는 자극적인 얘기들이 나오기 시작했었고, 보안업계에 직접 몸을 담고 있지 않은 저는 중간자의 입장에 있을 수 있다고 스스로 생각하고 조심스럽게 접근을 해 보게 되었습니다.
그런데, 돌아 오는 얘기는 가관이었죠. 흑백논리로 아군과 적군을 구분해서 싸움만 야기하고 서로 비난만 할 뿐이었습니다. 이후 몇몇 댓글과, 이에 전후하여 다른 사이트들에서 이슈화가 되기 시작하였고 마찰이 일어 나게 됩니다. 악플러들이 이유없이 싫은 소리를 해 대는 것은 무시할 수 있다고 쳐도, 소위 말하는 지식인들까지 이런 모습을 보여 주고 있으니 안타까울 뿐입니다, 오픈웹 진영도 그렇고 보안쪽도 그렇고... 둘다 똑같습니다. 저 또한 그러한 논쟁속에 있음을 스스로 인정하겠습니다. 지금 이렇게 글을 쓰는 것도 그러한 연유에서입니다.
결국 지금 얘기는 잘못 되어 있는 상식을 바로 잡을 수 밖에 없는 형편이 되었습니다. 허나 지금의 얘기(잘못된 부분을 바로 잡는 얘기)마저도 "웹의 표준화에 반하는 얘기"로 전락될 수 밖에 없는 실정입니다. 그래도 이젠 할 말은 해야 겠군요. 솔직히 남의 글 하나하나에 토를 달는 것을 정말 싫어 하지만, 지금은 어쩔 수 없는 형국입니다.
---------------------------------------- 일부발췌 ----------------------------------------
보안업체가 해명해야 할 한국인터넷 뱅킹의 특이점
http://openweb.or.kr/?p=1073
3. 기술적 논의
https 접속에 대한 여러 “공격의 가능성”이 있을 수 있다는 논의는 하등 새로운 것이 아닙니다. 그러나, 이런 공격은 서버, 클라이언트, 프록시 중 어느 하나 또는 그 이상이 이미 공격자에게 완벽하게 장악된 상황을 전제로 가능한 시나리오에 불과합니다. 그 경우에도, 고객과 은행간에 오가는 메시지의 내용을 공격자가 읽어 볼 수 있다는 것은 아니고, 고객이 은행사이트에 접속했다고 착각하고 입력하는 값을 공격자가 받아 볼 수 있다는 것입니다. 고객이 비밀번호 등을 입력하고 “확인”을 누르면, 그 값이 공격자에게 전달되고, 고객의 화면에는 “거래량 폭주로 잠시 장애가 있습니다” 는 따위의 안내 메시지가 뜨도록 조작할 수 있다는 것입니다.
그러나, 이런 것은 그저 시나리오에 불과합니다. 실제로는 https 접속을 우회하기 위하여 ARP Spoofing 이니, MIM 공격이니 일부러 어려운 공격 방법(그리고 발각될 위험이 더 큰 공격방법)을 채택할 필요가 없이, 훨씬 쉽고 간편한 방법으로 마찬가지 효과를 거둘 수 있습니다.
그리고, 한국식의 플러그인 보안접속 방법은 이렇게 어렵게 https 보안접속을 우회하는 방법을 고안할 필요조차도 없습니다. 고객과 은행간의 접속이 그냥 http 로 이루어지기 때문입니다.
https 가 위험할 수 있다고 어쩌구 저쩌구 어려운 말을 계속 해대는 국내 보안업체 관계자는 마치 자기 집 대문은 활짝 열어두고, 이웃집 창문의 방탄 유리창도 100% 안전하지는 않다고 계속 말하는 것과 같습니다.
---------------------------------------- 일부발췌끝 ----------------------------------------
>> 이런 공격은 서버, 클라이언트, 프록시 중 어느 하나 또는 그 이상이 이미 공격자에게 완벽하게 장악된 상황을 전제로 가능한 시나리오에 불과합니다.
SSL MITM Attack은 특정 호스트를 장악하는 것이 아닙니다. "장악"이 어디에서 나온 얘기인지 모르겠네요. DNS spoofing을 하기 위해 호스트의 host 파일을 변경하는 방법이 있기는 한데, 제가 말씀드린 SSL MITM Attack 기법은 그런 것과는 관련이 없고, 순수 네트워크 영역에서만의 공격을 얘기하는 것입니다. Attacker가 통신 주체(서버, 클라이언트)를 건드리지 않고 이루어 낼 수 있다는 것이고, 장악같은건 애시당초 하지도 않습니다.
>> 고객과 은행간에 오가는 메시지의 내용을 공격자가 읽어 볼 수 있다는 것은 아니고, 고객이 은행사이트에 접속했다고 착각하고 입력하는 값을 공격자가 받아 볼 수 있다는 것입니다.
무슨 말씀이신지요? SSL MITM Attack 원래의 목적이 양단 호스트간의 송수신 내용을 알아 내는 것입니다. 피싱(가짜 웹사이트로의 유인)이나 키로거와 헷갈리면 안됩니다. 개념 자체가 틀립니다.
>> 고객이 비밀번호 등을 입력하고 “확인”을 누르면, 그 값이 공격자에게 전달되고, 고객의 화면에는 “거래량 폭주로 잠시 장애가 있습니다” 는 따위의 안내 메시지가 뜨도록 조작할 수 있다는 것입니다.
할 말이 없습니다. 제가 얘기하고 있는 것들을 피싱으로 이해하고 있군요. SSL MITM Attack이 무엇인지 제대로 이해를 하지 못하고 있다는 것을 단적으로 보여 주고 있는 말입니다. http://snoopspy.springnote.com/pages/589686 의 "sniffing - cipher text login" 하고 "funny story by changing packet" 동영상을 참고하시기 바랍니다.
>> ARP Spoofing 이니, MIM 공격이니 일부러 어려운 공격 방법(그리고 발각될 위험이 더 큰 공격방법)을 채택할 필요가 없이,
ARP spoofing은 정보보호와 관련 교과 과정에 들어 가는 아주 기초적인 기법입니다. ARP spoofing이 발각될 위험이 크다는 말의 근거는 무엇인가요? 피싱이 발각되기 쉬운 것이죠. 헷갈리면 안됩니다.
>> https 가 위험할 수 있다고 어쩌구 저쩌구 어려운 말을 계속 해대는 국내 보안업체 관계자
앞뒤 정황상 저를 두고 한 얘기이군요. 최대한 쉽게 얘기를 하려고 했던 것을 어려운 말로 받아 들였다면 뭐 어쩔 수가 없겠구요, "어쩌구 저쩌구", "어려운 말을 해 대는"라고 들었을 때 과연 어느 누구가 기분이 좋을 수 있을까 하는 생각을 해 보게 됩니다.
조롱의 의도가 전혀 없이 친밀감 있게 표현하려 했었던 저의 글에 대해서, 김기창 교수님 나름대로의 해석에 의한 답변을 보고 나서, 성인군자가 아닌 이상 허탈한 실망감을 느낄 수 밖에 없었고 이에 대한 답변을 해 봅니다.
---------------------------------------- 일부발췌 ----------------------------------------
http://openweb.or.kr/?p=1061#comment-24018
By 이경문 — 2009.04.01 @ am8:17
youknowit 님 / 음… PKCS라는 것이 있었군요. 몰랐었습니다(사실 제가 보안을 정식으로 공부한 적이 없고, 전부 야메로(술자리)에서 어깨 넘어 배운 것이라 기초가 부족합니다) 좋은 정보 감사합니다. 시간 날때 한번 검토해 보도록 하겠습니다. 그나 저나 여기 저기 글 올리고 읽고 하느다 다들 잠은 제대로 주무셨나 모르겠네요. ㅎㅎ
http://openweb.or.kr/?p=1073#comment-24033
By youknowit ? 2009.04.01 @ pm12:58
이경문/
“PKCS라는 것이 있었군요. 몰랐었습니다”라는 말씀은 물론 만우절을 맞아서 쓰신 우아한 “농담”이라고 생각합니다.
그러나, 감독관청, 보안 업체, 금융권 IT 담당자 분들 중에는 실제로 PKCS 가 무엇인지 모르는 분들도 있습니다.
그리고, “ssl 이 위험하다”는 주장(대부분은 술자리에서 어깨넘어로 들은 말)을 퍼뜨리는 분들은, 국내 업체들이 사용하는 별도 플러그인 중에도 ssl 방식으로 보안접속을 구현하는 제품이 다수 있다는 사실도 알지 못하고 아무렇게나 말씀하시는데 불과합니다.
물론, 이것이 한국의 현재 수준입니다.
---------------------------------------- 일부발췌 ----------------------------------------
PKCS라는 용어를 몰랐었던 것은 사실입니다. 그때 PKCS 얘기해 주셨을 때 거짓말 하나 보태지 않고 정말로 고맙다는 생각을 했었습니다. 비아냥거리거나 그런 심정은 전혀 없었습니다. 진심입니다.
술자리에서 배워서 죄송하구요, 원래 제가 책상에 앉아서 공부하는 스타일이 아니고 여기 저기 돌아 다니면서 사람들 만나면서 공부하는 스타일입니다. 이해해 주시기 바랍니다.
플러그인으로만 국한시키지 마시기 바랍니다. Web(HTTP, 교수님께서 얘기하는 플러그인이라고 하는 것), VoIP(SIP), 각종 네트워크 기반 제품들... 분야는 무궁무진입니다.
제가 하는 일 중의 하나가 특정 업체의 SSL(or TLS) 기반 제품의 통신의 내용을 분석(감청)할 수 있는 모듈을 제공하고, 동시에 해당 제품에서 SSL을 올바르게 사용할 수 있도록 보안상의 컨설팅을 하는 일련의 서비스를 의뢰를 받고 해 주는 것입니다. 분석(감청) 성공하는 시점에 계약서에 도장 찍고 선금 받습니다(불법 의뢰나 단가 맞지 않은 프로젝트는 제외).
전부 다는 아니지만 대부분은 분석(감청)에 성공했었습니다. 인증서 확인 절차 거치지 않아서 뚫리는 것 말고도 별별 경우가 다 있습니다. SSL에서 제공되는 모든 기능이 다 활용된다면 뚫는 것은 매우 힘들게 되지만, 실제적으로 모든 SSL 기능을 철저하게 이용하는 경우는 없습니다. 그래서 case by case로 "귀사 제품에서는 이 정도 레벨 까지 SSL에서 제공되는 기능을 활용하시는 것이 좋을 듯 합니다"라고 조언을 해 줍니다. 참고로 현재 웹서버와 웹클라이언트간에 사용되는 일반 SSL 통신은 그 적용 정도(SSL의 보안 기능을 얼마나 엄격하게 적용했느냐)가 중간쯤 됩니다. 이건 저 개인적인 판단입니다.
아무튼 현업에서 SSL 많이 사용되고 있는 거 당연히 잘 알고 있구요, 제가 직접 만드는 프로그램 안에서도 지금 SSL 쓰고 있습니다. 알아도 당연히 제가 더 많이 압니다. 매일 이런 것 공부하고 연구하는 사람이 누구로부터 "SSL이 최고이다"라는 얘기를 들었을 때 웃음이 나올 수 밖에 없음은 당연하지 않을까요? 수준을 우습게 보지 마십시오.
그래도 처음에는 어떻게 해서든지 도움을 주려고 했었는데, 그 이후의 반응을 살펴 보니 결국에는 저를 비롯한 많은 사람들이 오픈웹의 적으로 전락해 버렸네요. 애시당초 마음이 싹~ 없어 질 수 밖에 없었습니다. 제가 의도적으로 의견의 표출을 강변하게 하는 이유는, 이렇게 하지 않는 이상 오픈웹의 주장에 제대로 대응하지 못한다고 판단을 해서입니다.
마지막으로 국내에서 대한민국의 인터넷 미래를 걱정하는 이들이 오픈웹만 존재하는 것이 아님을 알아 주셨으면 좋겠습니다.
|
|
|
|
본 사이트에 대한 모든 저작권은 이경문에게 있습니다. All rights reserved
to GilGil |
|
|
