SSL민으로 보안접속이 안전하다는 외국인터넷뱅킹 보안에 대한 재고..
swlee
오픈웹에서 이런 진지한 보안 기술에 대한 논의가 될줄이야...
이왕 시작했으니
보안관계자 분들이 우려하는 최신 해킹기법에 대한 SSL의 한계에 대해서
정확하게 이해하는 것이 필요할 것 같습니다.
아래는 온라인 뱅킹 시스템을 공격하는 악성코드에 대한 경고입니다.
http://www.trustdefender.com/blog/2009/02/28/banking-malware-bankpatc...
BHO 형태로 동작하기 때문에 SSL로는 방어가 불가능 합니다.
내용에도 SSL로 암호화된 HTML 에서도 동작한다는 코멘트가 있네요,,,
이미 2004년에 BHO 로 동작하는 것은 SSL 로 방어가 불가능 하다고 포스팅 되어 있습니다.
http://news.netcraft.com/archives/2004/06/30/hackers_manipulating_int...
"It ultimately installs its keylogger trojan, which scans for https
sessions connecting to URLs of popular banks (including Citibank,
WestPac, Barcklays and HSBC) and then intercepts outbound data from
IE
before it is encrypted using the Secure Sockets Layer (SSL)
protocol."
이런 악성코드에 대항하기 위해서는 아래 4가지 방법밖에는 없을 것 같습니다.
1, IE를 사용하지 않는다.(BHO 가 IE 종속적인 기술이기 때문에)
2. 바이러스 백신 회사가 미친듯이 열심히 일한다.
3. 이런 악성코드에 대한 피해는 감수한다.
4. APPLICATION 레벨에서 방어가 될 수 있도록 ETE 보안접속 모델을 한층 더 강화시킨다..
한가지 재미있는 점은 제가 자료를 검색하면서
온라인 뱅킹 악성코드의 위험과 경고에 대해 포스팅 된 사례가
국내보다는 외국이 압도적으로 훨씬 많았습니다.
국내 인터넷 뱅킹 보안환경이 그나마 선방하고 있다는 느낌입니다.
구글에서 banking malware 로 검색해 보니 어찌나 많은 악성코드가 나오던지,,,
또 재미있는것은 파폭에서 플러그인으로 동작하는 악성코드입니다.
http://blogs.zdnet.com/security/?p=2264
구글에서 FireFox banking malware 로 검색하니 어찌나 많던지,,,
SSL만으로 안전하다는 외국 은행들 보다는
인터넷 뱅킹시 다양한 보안 환경을 알아서 제공하는
국내 은행들이 그나마 나은건 아닐까요?
Taewoo Lee
IE 종속적인 인터넷 뱅킹의 가장 문제는, IE 그 자체 아니라 오히려 Windows가 아닌 환경이겠죠.
은행권에서 깔끔하게 IE를 포기하고 "Banking을 위해서는 보안이 향상된 Firefox, Opera등을 사용하세요"라고 guide할수도 있겠고요.
Firefox malware에 대해서는 제가 잘 몰라서 그럴수도 있는데, 일단 FF Plugin들은 기본적으로 user의 동의(2초간 대기 후 동의버튼 활성화)가 없이는 설치할 수 없는걸로 알고 있습니다. 이 과정을 거치지 않은 플러그인이 작동될 수 있나요?
기본적으로 백신이 깔려있지 않은 console에서는 인터넷 뱅킹을 못 하는게 맞고, 은행들은 고객 편의 차원에서 이러한 백신을 "별도로"제공할수는 있겠지요. 하지만 은행이 "자사가 제공하는 백신을 강제"하는건 좀 이상한 것 같고요.
또한 국내 인터넷 뱅킹이 선방한다고 말씀하셨는데, 금융거래규모나 인터넷 뱅킹의 빈도가 영어권 전체와 국내는 상당한 차이가 있겠지요 ^^;
swlee
현재는 제한적 사용인데.. 전면적 사용까지는 좀더 시간이 걸릴것 같습니다.
전면적 OTP에 드는 비용또한 어마어마해서 쉽지는 않고요..
대응을 한다고 보면
전면적 OTP가 되기 이전가지 가정현실적인 방법은 ETE 보안 접속 기술을
더 강화시키는 것 밖에는 없을 것 같습니다.
외국과의 사례비교는 사실 추정일 뿐입니다.
외국은 단순 계정정보면 OK 이지만
우리는 부가적인 수단및 보안이 강제되어 있습니다.
따라서 외국보다 악성코드가 성공할 확율이 상대적으로 적으며
이로인해 악성코드에 대한 대응은 외국보다 잘 되었다고 예디하는것은
전혀 근거없는 예기는 아닙니다.
FireFox는 자동으로 플러그인이 설치되는 경우는 없다는 말씀은
최신 보안 패치가 되어 있지 않더라도 FIREFOX 에서는 악성코드가 절대
자동으로 설치가 되지 않는다는 말씀인것 같습니다.
만일 그것이 사실이라면..
저는 FIREFOX 유저로 지금 당장 바꾸고..
다른 사람에게도 FIREFOX 를 권하겠습니다.
좀더 자세히 알려 주십시요.
마지막으로 강제하는 문제는 저도 개선의 여지가 있다고 생각합니다.
그렇지만 이문제의 결정권은 은행에게 있을것 같습니다.
해킹 사고 발생하면 책임지는 것은 은행이니까요.,
On 4월10일, 오후1시46분, Taewoo Lee <j...@jemr.net> wrote:
> BHO 문제에 대해서 가장 현실적인 대안은 "가로채봤자 쓸모 없는 값들로 인터넷 뱅킹을 구성한다(OTP 등)"와, 이게 불가능하다면
> "IE를 포기한다"정도가 정답 같네요.
>
> IE 종속적인 인터넷 뱅킹의 가장 문제는, IE 그 자체 아니라 오히려 Windows가 아닌 환경이겠죠.
> 은행권에서 깔끔하게 IE를 포기하고 "Banking을 위해서는 보안이 향상된 Firefox, Opera등을 사용하세요"라고
> guide할수도 있겠고요.
>
> Firefox malware에 대해서는 제가 잘 몰라서 그럴수도 있는데, 일단 FF Plugin들은 기본적으로 user의 동의(2초간
> 대기 후 동의버튼 활성화)가 없이는 설치할 수 없는걸로 알고 있습니다. 이 과정을 거치지 않은 플러그인이 작동될 수 있나요?
>
> 기본적으로 백신이 깔려있지 않은 console에서는 인터넷 뱅킹을 못 하는게 맞고, 은행들은 고객 편의 차원에서 이러한 백신을
> "별도로"제공할수는 있겠지요. 하지만 은행이 "자사가 제공하는 백신을 강제"하는건 좀 이상한 것 같고요.
>
> 또한 국내 인터넷 뱅킹이 선방한다고 말씀하셨는데, 금융거래규모나 인터넷 뱅킹의 빈도가 영어권 전체와 국내는 상당한 차이가 있겠지요 ^^;
>
> 2009년 4월 10일 (금) 오후 1:28, swlee <Bang...@gmail.com>님의 말:
> > 국내 은행들이 그나마 나은건 아닐까요?- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -
Taewoo Lee
그리고 OTP문제는 사실 별거 아닌데.. 지금도 개인용 공인인증서(은행용 사설인증서 말고) 발급받는데 1년에 4400원입니다. 이 인증서가 아니면 다른 인증 거칠때 제한이 있기도 하고요(카드결재 등). 이 비용을 무효화시키고 3-4년 수명의 OTP가 도입된다면 절대비용은 훨씬 줄어들겠죠(제가 기업은행 OTP로 모든 은행에서 사용하고 있는데, 5천원 내고 발급 받았습니다)
아마 어딘가의 로드맵에서 앞으로 모든 인터넷뱅킹은 OTP 기반으로 한다는 걸 얼핏 본 것 같기도 합니다. 김기창 교수님, 혹시 정부 정책중 OTP보급을 위한 특별한 로드맵이 있었는지만 한번 확인해주실 수 있을까요?
이태우 드림
dasony
의 창을 통하지 않고 프로필 디렉토리에 직접 플러그인을 설치할 수 있습니다. 물론 둘 다 사용자의 파일 시스템에 마음대로 접근
할 수 있다는 전제하에 이루어집니다.
swlee님/ 보안접속에 관해서는 SSL만으로 안전하다고 봅니다. (SSL 자체를 우회하는 ssl-strip는 배재했을 때의 이
야기입니다.) 보여주신 악성코드 방식은 보안접속의 범위를 넘어선 것이고, 일단 깔리고 나면 어떤 방법으로도 막을 수 없습니다.
유일한 방법은 해당 악성코드를 막을 수 있는 백신을 사용하는 것이겠지요. 현 인터넷 뱅킹에서 제공하는 ActiveX 기반 백신
을 제공하지만, 해당 은행을 타겟으로 한 악성코드라면 해당 백신이 설치되지 않도록 은행 페이지를 간단히 수정하도록 할 것입니
다. 즉 항상 최신 버전의 백신을 가동하고, 이상한 프로그램을 함부로 설치하지 않으며, 컴퓨터 프로세스를 수시로 점검하고, 제로
데이 공격에 당하지 않기를 기도하는 수 밖에요.
BHO의 이상적인 대응은 OTP라고 하셨지만, 사실 그것도 쉽게 피할 수 있습니다. 계좌이체 페이지에서 사용자가 입금하려는 계좌
번호만 중간에서 바꿔치기 해주면 됩니다. =)
swlee
BHO의 이상적인 대응은 OTP는 아닌것 같습니다. ^^;;
ETE 보안 접속이 그나마 BHO 악성코드의 현실적인 대응인것 같습니다.
BHO로 동작하는 악성코드가 FROM DATA 를 스니핑 하여 획득했을때..
ETE 보안 접속 암호화 모듈을 사용하는 경우라면 암호화된 DATA를 스니핑 하게 됩니다.
사용자가 확인 버튼을 클릭하면
우선 자바스크립트를 통해 ActiveX 보안접속 모듈이 먼저 동작하여
FROM DATA를 DOM레벨에서 암호화 하고
FROM.SUBMIT 명령이 실행되니까요..
물론 사용자가 확인 버튼을 클릭하기 이전
값을 입력하는 단계에서 실시간으로 동작을 할 수 있겠지만
1로 입력되는것이 자동으로 2로 바뀌는데.. 아마 화들짝 놀라서
컴퓨터를 꺼버리지 않을까 하네요... ㅎ
즉 ETE보안 접속을 강화시키면 막을 수 있을 것 같습니다.
어자피 같은 APPLICATOIN 레벨에서 동작하는데..
복잡하고 힘들수는 있지만 악성코드보다 먼저만 동작하게 하면 되니까요~
키보드 보안과 비슷한 싸움이 되겠네요..
그렇지만 솔직히 악성코드가 클라이언트 PC에 깔렸다고 전제를 하면
dasony님 말씀대로 근본적인, 완벽한 대응을 논하는 것은 불가능 할 것 같습니다.
단지 악성코드가 휠씬더 복잡하고 정교하게 만들어져야 하기 때문에
공격은 훨씬 복잡하고 정교해 져야 한다에 만족을 해야 할 것 같습니다.
결국에는 말씀대로 백신과, 사용자 보안의식 강화밖에는 없는것 같네요..
.
구글링해보니 파폭 악성코드가 꽤나 증가하는 추세네요..
그나마 IE는 파폭에 비해 이런 보안 접속 모듈이라도 있으니 다행입니다.
dasony
> 우선 자바스크립트를 통해 ActiveX 보안접속 모듈이 먼저 동작하여
> FROM DATA를 DOM레벨에서 암호화 하고
> FROM.SUBMIT 명령이 실행되니까요..
>
> 물론 사용자가 확인 버튼을 클릭하기 이전
> 값을 입력하는 단계에서 실시간으로 동작을 할 수 있겠지만
> 1로 입력되는것이 자동으로 2로 바뀌는데.. 아마 화들짝 놀라서
> 컴퓨터를 꺼버리지 않을까 하네요... ㅎ
DOM을 직접 조작하여 변수를 조작하는 경우는 SSL에서도 사용자에게 보이는 것은 마찬가지입니다. 오히려 현재 플러그인들이 폼
데이터를 읽어 온 후 폼 내용을 삭제하는 경우가 있어서, 사용자에게 들킬 확률이 적겠지요. 그리고 ETE 접속 모듈이 정확히 어
떻게 동작하는지 알지 못합니다만, 자바스크립트에서 Form Data를 읽어온 후 자바스크립트 내의 변수를 조작하면 쉽게 조작이
되지 않을까요? DOM 내의 값을 굳이 건드리지 않더라도요. 아니 그냥 자바스크립트를 조작해버리면 되겠네요. =)
그런데 이런 얘기 계속하면 보안 전문가 분들이 보고 비웃을까 걱정입니다. ^^; 이런식으로 쫓고 쫓기는 과정을 계속하다보면 시스
템레벨에서 동작할 수 있는 ActiveX가 궁극적으로 더 안전할 수는 있겠습니다. 대신 ActiveX 자체를 대체하면 오히려
더 위험해지겠죠.
Won-Kyu Park
>> 사용자가 확인 버튼을 클릭하면
>> 우선 자바스크립트를 통해 ActiveX 보안접속 모듈이 먼저 동작하여
>> FROM DATA를 DOM레벨에서 암호화 하고
>> FROM.SUBMIT 명령이 실행되니까요..
>>
>> 물론 사용자가 확인 버튼을 클릭하기 이전
>> 값을 입력하는 단계에서 실시간으로 동작을 할 수 있겠지만
>> 1로 입력되는것이 자동으로 2로 바뀌는데.. 아마 화들짝 놀라서
>> 컴퓨터를 꺼버리지 않을까 하네요... ㅎ
>
> DOM을 직접 조작하여 변수를 조작하는 경우는 SSL에서도 사용자에게 보이는 것은 마찬가지입니다. 오히려 현재 플러그인들이 폼
> 데이터를 읽어 온 후 폼 내용을 삭제하는 경우가 있어서, 사용자에게 들킬 확률이 적겠지요. 그리고 ETE 접속 모듈이 정확히 어
> 떻게 동작하는지 알지 못합니다만, 자바스크립트에서 Form Data를 읽어온 후 자바스크립트 내의 변수를 조작하면 쉽게 조작이
> 되지 않을까요? DOM 내의 값을 굳이 건드리지 않더라도요. 아니 그냥 자바스크립트를 조작해버리면 되겠네요. =)
그런 폼 변조를 중간에 차단하기 위한 여러가지 방법은 이미 있지 않나요?
사이트 specific seed (hidden field)를 이용하고, 폼을 1차로 읽은 후에, 폼 변조를 방지하기 위한
체크섬 + 내부 사이트 seed값. 폼이 바뀌면 체크섬과 seed가 모두 영향을 받아서 변조를 탐지할 수 있죠.
체크섬 알고리즘을 사이트 seed와 그때 그때 상황에 따른 몇가지 seed를 조합 하면 짧은 시간 안에는
거의 해독이 안되죠. 은행 사이트가 해킹되기 전에는
>
> 그런데 이런 얘기 계속하면 보안 전문가 분들이 보고 비웃을까 걱정입니다. ^^; 이런식으로 쫓고 쫓기는 과정을 계속하다보면 시스
> 템레벨에서 동작할 수 있는 ActiveX가 궁극적으로 더 안전할 수는 있겠습니다. 대신 ActiveX 자체를 대체하면 오히려
> 더 위험해지겠죠.
>
> >
>
--
온갖 참된 삶은 만남이다 -- 마르틴 부버
swlee
절대 비웃지 않습니다.
저는 사실 비 전문가인 오픈웹 그룹에서
전문적인 보안 기술에 대해 말씀하는 것이 놀라울 따름입니다.
제가 열심히 코멘트를 다는것은 보안 및 보안 기술에 대해서
정확히 이해를 하시는데 도움이 되었으면 하는 바램 때문입니다.
오픈웹을 그동안 지지해왔던 지지자 입장에서 오픈웹이 잘 되기를 바라며
보안에 대한 오해를 없애보자는 의미입니다.
오픈웹의 주장대로 가는것이 어쩌면 한국 IT의 큰 방향을 볼때 바라직할수도 있지만
지금 보안에 대해 가지고 있는 오해와 불신은 잘못되었다고 생각하고 있습니다.
마지막으로 그냥 자바스크립트를 바꾸면 되지 않느냐고 하셨는데..맞는 말이긴 합니다.
그전에 일단 HTML 소스보기를 하면 ETE 암호화 된 형태로 소스가 보일텐데
그것부터 깨서 평문화 시킨다음에 구조를 확인하고 바꾸면 되겠죠 ^^:;
dasony
> 전문적인 보안 기술에 대해 말씀하는 것이 놀라울 따름입니다.
오픈웹 그룹이 보안으로는 비전문가가 주라고 해도 나름대로 웹이나 기타 컴퓨터 분야의 전문가들이 많이 있습니다. ^^
> 마지막으로 그냥 자바스크립트를 바꾸면 되지 않느냐고 하셨는데..맞는 말이긴 합니다.
> 그전에 일단 HTML 소스보기를 하면 ETE 암호화 된 형태로 소스가 보일텐데
> 그것부터 깨서 평문화 시킨다음에 구조를 확인하고 바꾸면 되겠죠 ^^:;
HTML 소스보기를 할 필요 없이 브라우저 DOM을 통해서 access하면 될 것 같습니다. 물론 여기에 몇 단계를 더 넣어서
훨씬 더 힘들게 만들 수는 있겠지요. =)
>사이트 specific seed (hidden field)를 이용하고, 폼을 1차로 읽은 후에, 폼 변조를 방지하기 위한
>체크섬 + 내부 사이트 seed값. 폼이 바뀌면 체크섬과 seed가 모두 영향을 받아서 변조를 탐지할 수 있죠.
>체크섬 알고리즘을 사이트 seed와 그때 그때 상황에 따른 몇가지 seed를 조합 하면 짧은 시간 안에는
>거의 해독이 안되죠. 은행 사이트가 해킹되기 전에는
예, 저도 그 생각을 하긴 했습니다. 체크섬을 언제 어디서 계산하느냐에 따라 달라질 것 같습니다. 체크섬을 계산하기 직전에 변조
하면 되니까요.악성코드가 탑재된 상황에서 변조를 완벽히 막을 수 있는 방법이 있을지 모르겠네요. 하지만 일이 훨씬 복잡해지는건
확실합니다. 현재의 플러그인들은 이러한 일을 하고 있는지 모르겠네요. 언제 정말 날잡아서 인터넷 뱅킹 사이트 하나 잡고 쳐다보
면 재밌겠습니다만, 저도 제 일이 있는지라;;
이제 글을 좀 자제하려고 했는데 재밌는 게 보여서 또 잔뜩 쓰고 말았네요. 이만 저는 퇴근해야겠습니다. 좋은 하루되세요!
Mountie Lee
고객의 정보가 여러 Node를 거쳐가는 경우를 감안하여 발생된것으로 알고 있습니다.
예를 들어 인터넷 결제시에
유저가 결제정보를 상점 서버로 전달하고
상점 서버의 에이전트를 통하여 은행으로 전송하는 경우를 대상으로
E2E 보안이라고 시작되었는데
현재 주로 사용되는 형태는 유저 브라우저로부터 은행으로 직접 전달되는 구조를 대부분 취하고 있습니다.
이때는 SSL이 기존의 ActiveX E2E 보다는 더 낳다는 생각입니다.
ActiveX E2E의 역할을 자세히 들여다보면(실제 자세히 한번 들여다 봤습니다.)
서버와 클라이언트간의 세션 보호역할이상을 하지 않습니다.
우리가 말하는 Application Level에서의 E2E가 현실에서는 적용되고 있지 않기 때문에
SSL이 더 유리하다는 의견입니다.