메모리 해킹 이야기 :: 2007/09/04 13:42


내용이 길어지다 보니 자칫 제가 뭔가 독창적인 아이디어를 내놓고 거기에 대해서 옹호하는 듯한 입장이 된 건 아닌가 하는 생각이 듭니다. 다른 분들을 위해서 거듭 강조하지만 이는 제 개인의 독창적인 생각이 아닙니다. 원 글에도 밝혔듯이 이 또한 해묵은 방법입니다.

원 글의 의도는 메모리 해킹이 새로운 방식이 아니고 보안 관계자들 또한 그 방식에 대해서 인지를 오래전부터 하고 있었다는 것을 알리는데 있었습니다. 또한 제가 제시한 한 가지 방법이 완벽한 대안은 절대 아닙니다. 알려져 있는 한 가지 방법을 제시한 것에 불과합니다.

우선 먼저 부족한 글임에도 고견 남겨주신 Jerry님, 고맙습니다. *^^*
지적하신 부분에 대한 답글을 작성하다 글이 길어질 것 갈아서 새 글로 작성합니다.
읽어 보시고 틀린 내용이나 제가 잘못 이해한 부분이 있다면 지적해 주셨으면 합니다.
논의 과정 중에서 더 좋은 시스템에 대한 아이디어가 나온다면 그 또한 좋은 일이라 생각됩니다.

현재의 인터넷 뱅킹에서의 취약점들은 사용자임과 동시에 공격자인 경우의 문제점을 적극적으로 방어하기가 곤란한 한계점이 분명 존재함니다.
사실 이 문제는 게임에서 가장 큰 이슈가 되고 있는 항목 입니다. 정상적인 게이머들 조차도 게임을 해킹해서 뭔가 더 좋은 아이템이나 레벨업에 걸리는 플레이 시간을 단축하려고 하기 때문이죠. 하지만 인터넷 뱅킹에 이 내용이 적용되는 것은 조금 이상하다고 생각됩니다. 메모리 해킹의 주된 대상이 되고 있는 은행 업무 프로세스는 이체입니다. 이체는 자신의 계좌에서 다른 사람의 계좌로 돈을 송금하는 절차입니다. 이 과정에서 사용자가 공격자인 경우에 얻을 수 있는 것이 무엇인지 궁금합니다.

위에서 언급한 바와 같이 어떤 방식이던지 암호화 구간은 클라이언트에서 사용자에게 해독되는 구간이 반드시 존재합니다. 따라서 언급해 주신 해결 방식은 공격자의 시도를 좀 더 어렵게 만드는 측면은 있겠습니다만, 사용자 입력 구간에 대한 보호와 위변조 여부를 Server 사이드에서 검증하기 어렵다는 문제는 여전히 남으며,
논의에 앞서 제가 지난 번에 소개한 이미지를 전송하는 방법에 관한 내용을 좀 더 세부적으로 적어 보는게 도움이 될 것 같습니다.

서버에서는 그림 열장과 그에 대응하는 키 열 개를 보낸다고 했습니다. 편의상 이미지를 i라 부르고, 키를 k라 부르겠습니다. 서버는 다음과 같은 종류의 데이터를 생성할 겁니다.

원본 숫자 배열: 3, 2, 1, 9, 0, 5, 7, 8, 4, 6
이미지: i0, i1, i2, i3, i4, i5, i6, i7, i8, i9
키: k0, k1, k2, k3, k4, k5, k6, k7, k8, k9

이 데이터 중에서 이미지와 키만 클라이언트로 전송됩니다. 클라이언트 측에서 i0를 누르면 k0가 입력되는 식이죠. i0에는 당연히 3이란 숫자가 기록되어 있을 겁니다. 이렇게 클라이언트에서 입력된 데이터는 서버로 전달됩니다. 서버에서는 원본 숫자 배열을 참조해서 클라이언트에서 보내온 값을 원복 시킬 겁니다. 만약 클라이언트에서 조작된 값이 왔다면 그 조작된 값대로 원복될 겁니다. 서버는 그 값을 재차 클라이언트로 보냅니다. 그러면 클라이언트측에서는 화면에 그 데이터를 표시하고 사용자에게 확인을 받습니다.

이 과정에서 우리가 생각해야 할 부분은 클라이언트에는 해독 과정이 없다는 것 입니다. 클라이언트는 단지 서버로부터 해독된 값을 받고 있을 뿐이죠. 이 과정을 해킹하기 위해서는 사람이 i0를 보고 3이라고 인식한 것처럼 프로그램이 그 숫자를 인지해야 합니다. 하지만 지난 글에도 소개 했듯이 아직도 그 작업은 매우 힘든 일로 여겨지고 있습니다.

해커가 악의 적인 목적으로 특정 계좌가 아닌 단지 입력값을 조작한 경우를 생각해 보겠습니다. 서버에서는 바뀐 데이터를 원복해서 클라이언트로 보냅니다. 만약 해커가 이 데이터를 조작하지 않는다면 사용자는 엉뚱한 계좌가 입력된 걸 보고 취소를 할겁니다. 해커 입장에서는 반드시 이 데이터를 조작해야 하죠. 그런데 중요한 것은 해커는 입력값을 단지 조작만 했을 뿐 그 결과 값이 무엇인지 모른다는데 있습니다. 따라서 결과 값을 메모리에서 수정할 수 없는 상황이 되는 것이죠. 이 상황에서도 해커는 다시 이미지 인식이라는 문제로 돌아가게 됩니다.

이 과정 전반에는 아직 사람과 동일한 능력으로 인식할 수 있는 이미지 스캐너가 존재하지 않는다는 가정이 포함되어 있습니다. 만약 그러한 알고리즘이 있다면 이러한 과정과 논의는 전부 쓸모없는 일이겠죠.

암호화와 난독화
암호화(encryption)과 난독화(obfuscation)의 차이에 대해서 잠시 소개하겠습니다. 암호화란 암호화 과정만 있는 경우를 말합니다. 즉 해독 과정이 프로그램 상에 전혀 없는 경우죠. 반면 난독화는 프로그램 상에 암호화와 함께 해독 과정이 같이 있는 경우를 말합니다. 이 경우는 단지 리버싱을 통해서 암호를 구할 수 있죠.

한가지 예를 살펴보도록 하겠습니다. 패스워드를 입력하는 곳 입니다. 사용자가 패스워드를 설정하면 그것을 저장했다가 비교하는 루틴이라고 해 봅시다.

암호화를 이곳에 적용하면 이렇게 됩니다. 최초 설정시 입력한 사용자의 입력 값을 암호화해서 저장합니다. 그리고 다음 번에 사용자가 로그인하기 위해 입력하면 그 데이터를 암호화해서 원본 값과 비교하죠. 이 과정에는 해독 과정이 없습니다. 따라서 해커가 프로그램을 리버싱한다고 하더라도 원본 암호를 알아낼수는 없습니다.

난독화를 이곳에 적용하면 이렇게 됩니다. 최초 설정시 입력한 사용자의 입력 값을 암호화해서 저장합니다. 그리고는 다음번에 사용자가 로그인하기 위해 값을 입력하면 원본 데이터의 암호를 해제한 다음 그 값을 비교합니다. 이 과정은 해독 과정이 포함되어 있기 때문에 프로그램을 리버싱하면 원본 암호를 알아낼 수 있습니다.

예가 조금 작위적인면이 없지만 대부분의 경우 후자와 같이 처리해 놓고는 암호화를 했다고 합니다. 대표적인 경우가 파일 암호화입니다. 저장할 때 암호화해서 저장하고, 로딩할 때 그것을 해독해서 로딩합니다. 그리곤 암호화를 했다고 하죠. 이 경우에는 난독화가 정확한 표현입니다.

암호화를 한 경우에 그 데이터의 보안성은 코드 복잡도와 함께 암호화 알고리즘의 복잡도에 비례한다고 볼 수 있습니다. 반면 난독화의 경우에는 단순히 코드 복잡도에 비례합니다.

두번째는 그 수많은 사용자를 위한 서비스를 이미지 방식으로 만들면, 서버사이드에서 이미지를 생성하거나, 클라이언트에서 사용자의 입력값을 이미지로 조합하는데, 상당한 시간이 걸릴 것은 분명하며, 이미지 변환을 위한 또다른 ActiveX와 같은 이미지 리더 및 이미지 메이커는 또 다른 비극의 시작일 수 있고, 이미지 방식의 인터넷 뱅킹은 현재의 인터넷 뱅킹 시스템을 엄청나게 확장해야 가능한 시나리오라는 점 입니다. 또한, 저속 인터넷 사용자들의 경우에는 이미지 다운로드 및 업로드를 통해 인터넷 뱅킹을 사용하는데, 상당한 애로를 격을 수도 있다는 점 입니다.
지금의 인터넷 인프라를 생각한다면 그렇게 힘든 일이 아닙니다. 홈페이지에 접속하는 순간 벌써 우리는 엄청난 데이터를 전송받습니다. 홈페이지에 포함된 이미지, 보안프로그램, 플래시 파일 같은 것들이죠. 수 메가에 달하는 이런 것들도 지금 잘 받아서 사용하고 있지 않습니까? 여기에 몇 십 킬로바이트에 불과한 이미지 열 개를 더 받는다고 느려진다고 주장하는 것은 바람직하지 않다고 생각합니다.

또한 이미지 프로그램을 ActiveX 형태로 만들어야 한다고 생각할 필요는 없습니다. Ajax를 사용해서 만들 수 있습니다. 단지 이미지를 읽어오고, 그것을 화면에 배치하고 클릭했을때 키를 입력해 두었다 서버로 전송하는 것은 Ajax를 일주일만 공부한 사람도 만들 수 있을만큼 간단한 내용입니다.



스폰서
글타래

  • 2주간 인기 글
  • 2주간 인기글이 없습니다.
Trackback Address :: http://jiniya.net/tt/trackback/590
  • Gravatar Image.
    Jerry | 2007/09/03 22:58 | PERMALINK | EDIT/DEL | REPLY

    아, 이런 건설적인 토론이 정말 좋네요. ^^

    일단, 게임해킹 방식과 인터넷 해킹 방식은 사실 같은 방식으로 이루어집니다. 게임에서는 게임클라이언트가 있고 이에 대한 공격이 이루어 진다면, 인터넷 뱅킹은 인터넷 브라우저라는 클라이언트가 있고, 이에 대한 공격이 이루어지는 방식이죠. 문제는 현행 인터넷 뱅킹에서 사용되는 브라우저는 거의가 MS의 IE를 통해 이루어지고 있고, 여기서 가장 문제가 되는 부분이 바로 DOM과 BHO 구간이죠. 이 문제 때문에 바로 메모리 해킹이라는 말이 나오게 되는 기술적 근거가 된다고 봅니다. 사용자가 사용자임과 동시에 공격자일 경우 얻을 수 있는 부분은 한마디로 MITM(Man in the Middle) 공격이죠. 사실상 대부분의 인터넷 뱅킹 이나 쇼핑몰 공격 시나리오의 대부분을 차지하는 부분이라고 봅니다.

    언급해 주신 내역은 제 3자가 위조를 하기 힘들다는 시나리오를 기반으로 작성되어서 제가 말씀드린 부분과는 좀 차이가 존재하는 것 같네요. 말씀해신 논지에 대해서는 이해하고 있습니다. ^^

    암호화(encryption)와 난독화(obfuscation)에 대한 내역은 오랜만에 보니까, 참으로 반갑네요. 잘 봤습니다. 궁금한 점 몇가지를 좀 말씀드려 보겠습니다.

    서버사이드에서 생성하거나 판독하는 이미지를 수십K 정도로 가능하다고 하셨습니다만, 이미지 조합을 수십K 정도로 가능할지요? PoC(Proof of Concept) 단계에서는 수십K 정도로도 가능하겠습니다만, 상용 서비스를 전제로 할 때, 수십K 정도의 용량으로 가능하겠는지요? 사용자마다의 Request에 대한 Transaction 처리 및 이미지 생성은 서버에서 이루어지는 것이 맞는지요?

    또한, Ajax라는 기술이 사실상 XML+자바스크립트라고 할 수 있으며, 따라서 모든 스크립트는 판독이나 디컴파일 가능하다는 명제를 고려할 때, Ajax를 통한 구현이 문제라고 보여지지는 않습니다. 다만, 이러한 스크립트 판독이나 디컴파일을 통해 클라이언트에서의 입력값에 대한 공격자(뱅킹 이용자 임과 동시에 공격자인 경우) 공격이 가능하여, 여전히 문제점은 존재한다고 생각하는데, 이 부분에 대해서는 어떻게 생각하시는지요?

    (클라이언트에서 입력값이 있다면, 클라이언트에서도 이미지에 대한 조합이 이루어지고, 클라이언트에서 조합된 이미지가 서버로 전송이 되는 것 아닌지요? 서버에서 내려받은 이미지 폼에 따라 사용자 입력한 값을 소켓 통신으로 서버로 전송한다는 의미이신지요? 제가 이 부분에 대한 상세한 이해가 어려워서... 좀 더 자세한 댓글을 달기 힘드네요. OTL)

    • Gravatar Image.
      codewiz | 2007/09/03 23:56 | PERMALINK | EDIT/DEL

      의견 감사합니다.
      Jerry님께서 말씀하신 MITM 공격이란 것이 공격자가 중간에 스푸핑 따위로 개입해서 패킷을 조작하는 것을 의미하는 건가요? 그리고 사용자가 공격자란 의미가 victim과 attacker가 동일하다는 의미로 이해해도 되는지 궁금합니다. 아니라면 어떤 형태의 공격을 말씀하시는 건지 설명해 주셨으면 합니다.

      만약 위와 같은 형태의 공격을 가정한 것이라면 저는 여전히 의문이 남습니다. 글에서 제시한 것처럼 게임 사용자는 해킹을 통해서 뭔가의 추가적인 이득을 얻습니다(게임 머니, 렙업 시간 단축). 반면에 인터넷 뱅킹의 경우 자신이 자신의 계정을 해킹한 들 무슨 이득을 얻을 수 있는지가 의문입니다. 내지는 어떤 일들이 발생할 수 있는지도요. 제가 그 부분을 정확하게 이해하지 못해서 아마도 Jerry님 의견을 곡해하고 있는듯 합니다.

      ajax 코드가 디컴파일이 되고 공개가 되는 것은 크게 상관이 없습니다. 왜냐하면 해당 코드가 하는 일은 아무것도 없기 때문입니다. 단지 서버에서 값을 받아서 화면에 뿌려주고 클릭하면 그 값을 취합해서 서버로 전송하는 일만 하죠. 이 코드를 분석한들 알 수 있는 것은 아무것도 없기 때문입니다.

      수십 k라고 말씀드린 것은 0부터 9까지 열 개 이미지의 크기가 그정도 될거라고 말씀드린 겁니다. 서버에서는 생성된 이미지를 보관할 필요가 없습니다. 단지 키와 원본 숫자 배열만 저장하면 됩니다.

      클라이언트에서 이미지 조합을 다시 하거나 하지는 않습니다. 클라이언트에서 하는 일은 단지 첫번째 이미지를 클릭하면 첫번째 키를 저장하는 일만 할 뿐입니다. 그리고 그 데이터를 서버로 전송하는 것이죠.

      서버와 클라이언트의 데이터 교환 순서를 살펴보면 다음과 같이 이루어지겠죠.

      서버 => 클라이언트: i0,i1,i2,i3,..i9, k0,k1,k2,...,k9
      클라이언트 => 서버: k3, k1, k2, k5
      서버 => 클라이언트: 1, 3, 5, 8

  • Gravatar Image.
    오스카 | 2007/09/04 09:53 | PERMALINK | EDIT/DEL | REPLY

    제가 있는 회사의 VPN 접속도 말씀하신 것과 동일한 방식으로 로그인을 합니다. 재작년 부터인가 시행했는데.. 보안성은 높습니다만, 언급하신 것처럼... 상당히 귀찮은 방법이죠. ^^ 게다가 일반적으로 생성되는 이미지에 이미지 인식이 어렵도록 마스킹까지 하다보면 시각적으로 인식하기도 어려울 때도 있어서(마스킹도 매 시도 시 마다 달라집니다. 당연히..) 역시나 범용적인 사용에서는 좀 .. ㅎㅎ

  • Gravatar Image.
    Jerry | 2007/09/04 11:13 | PERMALINK | EDIT/DEL | REPLY

    아, 먼저 제가 원본 글을 좀 잘못해석한 부분이 있었습니다. 요즘들어 난독증이 있는지 어제 10번을 넘게 원문을 봤었는데도... OTL

    제가 오해한 부분은 서버에서 보여주는 메시지를 클라이언트에서 조합해서 POST 같은 방식으로 업로드 하는 것으로 잘 못 생각했더군요. (어제 잠을 자는데, 꿈에서 원문 메시지를 잘 못 해석하고 있다는 사실을 이해 했습니다. 믿거나 말거나... 0.o)

    제가 말씀드린 MITM 공격 관련 내역은 공격자가 중간에 스푸핑 따위로 개입해서 패킷을 조작하는 것을 의미합니다. 인터넷 뱅킹은 게임과는 달리 Transaction에 대한 무결성(Integrity)이 가장 중요시 되지만, 게임의 경우에는 높은 가용성(Availability)이 요구되기 때문에 바라보는 관점에 대해서는 다르겠지만, 공격이라는 관점에서 봤을때는 사실 거의 비슷하다고 봅니다. 따라서 인터넷 뱅킹을 사용하는 사용자가 100원을 이체하는데, 뒤 자리에 0을 몇개 정도 더 붙일 수 있다면 파급도가 상당한 것이죠. 게임해킹과 달리 인터넷 뱅킹 해킹은 계정을 획득한다던지가 그렇게 중요한 요소는 아닙니다. 가장 핵심적인 내역은 Transaction에 대한 위변조 가능성 여부라고 보는게 좀 더 정확하지 않을까 싶습니다.

    jiniya님께서 말씀해 주신 내역을 정리해 보면, 현재의 은행 ATM 기계 화면을 인터넷 뱅킹에 적용시켜보자는 것으로 생각됩니다. 좋은 아이디어라고 생각합니다. Random하게 숫자 배열을 바꾸는 ATM 기계도 최근에 등장하고 있습니다만, 보통 금액정도까지는 이해를 해도 계좌번호(이체시)까지 랜덤한 그림으로 선택한다면, 고객 입장에서는 너무 불편해지고, 몇회 정도 실패하다가 보면, 계좌가 잠겨(Locking) 버리는 일도 많아 질 것 같다는 생각도 듭니다.

    사실 인터넷 뱅킹이라는 것이 사용자가 입력한 입력값에 대한 위변조 여부의 문제만 해결한다고 해서 모든 문제가 없어지는 것이 아니며, 말씀해 주신 방식은 확실히 공격자의 자동화(Automation) 공격에 대한 대안은 되겠습니다만, 사용자 입력 나머지 구간의 문제들은 여전히 남아있어, 수작업(Manual) 공격에는 여전히 취약할 수는 있는 것 같습니다. 예를들면, 사용자 입력과 상관없는 사용자 View에 대한 Client to Server Response를 위조한다던지, 키와 원본숫자 배열이 10개이기 때문에 이 조합 상관관계를 수학적으로 풀어낸다던지 하는 일련의 과정을 말씀드리는 것이죠. 대칭되는 값은 몰라도 키를 변조하는 것은 또 가능할 수 있겠구요.

    예전에 한국은행 자료를 보니, 인터넷 뱅킹을 이용하는 목적의 99%가 자금조회와 이체더군요. 말씀해 주신 이미지 방식은 대단히 좋은 아이디어라고 생각하고 있으며, 좀 더 사용자에게 쉽고, 친숙한 인터페이스가 없을까를 고민하게 되네요. 생각해 보니, 기계가 문제가 아니라, 인간과 인간의 Communication에 대한 원리적 문제로 귀결되는 것 같습니다. ^^

    • Gravatar Image.
      codewiz | 2007/09/04 13:38 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.

      100원에 공을 몇 개 더 붙이는 예는 조금 부적절하다고 생각됩니다. 우선 제가 생각한 의도는 다음과 같은 겁니다. 공격자가 100만원을 이체해야 하는데 100원만을 입력하고 값을 조작해서 100만원으로 만든다는 것이죠. 이렇게 이해할 경우에 공격자가 얻을 수 있는 이득은 없다고 보여집니다. 계좌에 돈이 없다면 이체에 실패할 것이고, 돈이 있다면 100만원이 이체될 것이기 때문입니다.

      지적하신대로 사용상의 불편한 점과 수동 공격에 취약하다는 점에는 저도 같은 생각입니다.

      Jerry님 덕분에 제가 미처 몰랐거나 놓쳤던 부분에 대해서 많이 생각해 볼 수 있는 좋은 기회가 된 것 같습니다.

  • Gravatar Image.
    커널0 | 2007/09/04 11:33 | PERMALINK | EDIT/DEL | REPLY

    언급하신 "이미지를 이용 서비스"가
    현재 사용되고 있는 captcha(http://en.wikipedia.org/wiki/Captcha) 같은 걸 의미하시는 건가요?

    지인에게
    '우리나라 게임 중에서 bot detecting을 위해
    중국에서 비슷한 서비스를 해봤더니
    사람보다 BOT가 더 정답률이 높았다'는 얘기도 들었던 적이 있습니다만;;

    • Gravatar Image.
      codewiz | 2007/09/04 13:12 | PERMALINK | EDIT/DEL

      네 노이즈가 없는 이미지에 대한 인식률은 컴퓨터도 상당히 높습니다. 필체 인식도 하는데 숫자 정도 인식하는 거야 쉽겠죠. 하지만 노이즈가 첨가된다면 저는 이야기가 좀 달라진다고 생각합니다.

  • Gravatar Image.
    medjay | 2007/09/04 12:46 | PERMALINK | EDIT/DEL | REPLY

    우선 제안하신 내용과 비슷한 가상키보드 형태의 사용자 입력 보호를 위한 제품이 이미 소개가 되어 있지 않나 싶은데요. 확실 하지는 않지만 얼핏 본듯한 느낌이 듭니다.

    어쨋건 제안한 내용에서 안전성을 입증할 수 있는 핵심은 공격용 프로그램이 이미지를 읽지 못하기 때문에 다라고 보여지는데요. 이미지를 읽지는 못해도 이미지를 클릭했을때 생성되는 Request를 임의 생성해서 보내고 응답을 해석하면 10번의 요청으로 이미지와 매칭되는 숫자를 파악할 수가 있겠네요. 그렇게 파악한 숫자를 이용해 변조 역시 가능하겠군요. 사용자 입력이 완료되면 입력을 리셋하고 공격자가 임의 입력을 생성해 생성해 보내면 될테니까요. 공격 방식이 좀 복잡해졌다 뿐이지 별다른 차이가 없지 않나 싶은 생각이 듭니다.

    그리고 이미지에서 문자나 숫자를 뽑아내는 기술 역시 꽤나 발전한것으로 알고 있습니다만, 외국 게시판에 스팸봇들이 이미 다 이용하고 있지 않던가요.

    말씀하신걸 제대로 이해하지 못하고 썼을수도 있습니다. 그림을 그려서 설명해주시면 이해가 잘 될것 같은데요 :)

    • Gravatar Image.
      codewiz | 2007/09/04 13:16 | PERMALINK | EDIT/DEL

      우선 이미지 인식 문제는 노이즈 첨가 정도에 따라 달라진다고 생각합니다. 노이즈가 첨가된 이미지를 인식하는 부분은 아직도 힘든 분야라고 생각되기 때문입니다.

      그리고 10번의 공격으로 매칭되는 숫자를 파악할 수 있다고 하셨는데 그 부분은 오해가 있었던 것 같습니다. 숫자와 매칭되는 번호는 계속 바뀐다는 것을 전제로 하기 때문입니다. 원본 숫자 배열은 계속 바뀝니다. 고정된 것이 아니죠.

      그리고 제가 원래 썼던 글에도 밝혔듯이 이러한 방식은 몇 해 전에나 제안되던 내용입니다. 지금 적용된 곳이 있을 수도 있습니다. 이 글만 읽으면 자칫 제가 독창적으로 생각해낸 아이디어로 볼 수 있으나 그렇지 않습니다.

  • Gravatar Image.
    snaiper | 2007/09/04 13:27 | PERMALINK | EDIT/DEL | REPLY

    인터넷 뱅킹 사용자 중에 40~50대, 심지어 60대도 있을 수 있는데,
    노이즈가 있는 이미지 처리는 상당히 고심을 해야 하는 선택이 아닐까 싶습니다.

    노안이라 화면에 정확하게 보이는 글자도 잘 안 보인다고 하시는 분들도 많은데...
    노이즈까지 있으면...이게 무슨 글자냐고 항의하시는 분들이 속출할 겁니다.
    하지만 이미지 인식 공격에는 노이즈 만한 것도 없긴 합니다만...글쎄요..
    모든 연령층이 문제없이 사용할 수 있는 방법을 생각해봐야 할 것 같습니다.

    그나저나 인터넷 뱅킹이 이러면...상대적으로 뚫기 어려운...휴대폰 모바일 뱅킹이 대세가 될지도..모르겠군요.

    ps. 그렇다고 이미지에 노이즈 첨가안한다고 하고, 이미지를 계속 바꾸는 식으로 한다고해도..약간 문제가 있습니다. 역시나 고연령대가 문제지요. 화면이 조금만 바뀌어도 상당히 헤메시는 분들도 있습니다.
    은행 서비스가 모든 연령층을 대상으로 하는 만큼...솔루션 선택에도 고심을 해야 할듯 합니다.

    • Gravatar Image.
      codewiz | 2007/09/04 13:42 | PERMALINK | EDIT/DEL

      네 사용상의 불편한 점에 대해서는 저도 백번 동감합니다.

  • Gravatar Image.
    Jerry | 2007/09/04 15:24 | PERMALINK | EDIT/DEL | REPLY

    답변에 감사드립니다.

    위에서 언급한 MITM의 경우에는 자신이 이용자 임과 동시에 공격자라는 예제로 말씀을 드렸습니다만, 차마 말씀드릴 수 없는 다른 방식의 MITM도 존재하는 경우도 있어서 생각보다 인터넷 뱅킹의 위협이라는 것이 게임보다 오히려 파급도가 높을 수 있습니다. 게임의 경우에는 Cyber Money이지만, 인터넷 뱅킹의 경우에는 Real Money라는 점도 가장 큰 차이점인 것 같아요.

    조금만 다르게 생각하면 워낙 아이디어가 좋아서 뭔가 새로운 것이 나올 수도 있다고 봅니다. 저는 시간을 두고 좀 생각해 보려 합니다. 좋은 기회 제공해 주셔서 감사하다는 말씀 드리고 싶네요. ^^

    • Gravatar Image.
      codewiz | 2007/09/05 10:57 | PERMALINK | EDIT/DEL

      저도 제 생각을 정리해 볼 수 있는 좋은 기회가 된 것 갈습니다.

  • Gravatar Image.
    DalKy | 2007/09/04 18:34 | PERMALINK | EDIT/DEL | REPLY

    굳이 어려운 로직을 생각할 필요 없이, 인터넷 뱅킹을 통한 송금시도를 했을 때, 송금 금액과 이채할 계좌번호를 입력한 후에 확인 버튼을 누르면 바로 송금이 진행되게 하는 것이 아닌 서버측에서 모든 송금 전처리를 완료한 후 관련 정보를 그대로 클라이언트에 보여줌으로써 사용자에게 정확한 송금 금액과 이채 대상자를 재차 확인하는 프로세스를 좀 더 강화하는 방법은 어떨까 생각되네요.

    굳이 어려운 알고리즘을 생각하는 것 보다는 문제 해결 자체에 비중을 둔다면 꼭 송금 입력 절차에서만으로...국한지을 필요는 없을 것 같습니다.

    좋은 글 잘 읽고 갑니다.

    • Gravatar Image.
      codewiz | 2007/09/05 10:59 | PERMALINK | EDIT/DEL

      좋은 의견 감사합니다.
      절차를 강화하는 것도 좋은 생각입니다. 결국 복잡한 절차는 해커의 공격을 어렵게 만들기 때문이죠. 바이너리 분석에 대한 대응도 그와 유사한 경향이 있습니다. 복잡한 테크닉 보다도 더미 코드 삽입으로 분석을 어렵게 하는게 더 효과가 좋은 경우가 종종있죠.

  • Gravatar Image.
    peris | 2007/09/05 18:06 | PERMALINK | EDIT/DEL | REPLY

    공격자가 자신의 이득을 위해 한다는 가정이 전제가 되어 있는거 같네요.
    만약 공격자가 그냥 미친척하고(아니면 사회혼란을 위해?;;;) 아무에게서 아무에게로 계좌에 있는 모든 금액을 이체하게 한다면 위의 방식으로는 막지 못할거 같습니다.
    이미지 10개의 조합을 랜덤하게 변경하는 건 문제가 되지 않을테니까요.

    • Gravatar Image.
      codewiz | 2007/09/05 18:13 | PERMALINK | EDIT/DEL

      글 중 내용입니다.

      해커가 악의 적인 목적으로 특정 계좌가 아닌 단지 입력값을 조작한 경우를 생각해 보겠습니다. 서버에서는 바뀐 데이터를 원복해서 클라이언트로 보냅니다. 만약 해커가 이 데이터를 조작하지 않는다면 사용자는 엉뚱한 계좌가 입력된 걸 보고 취소를 할겁니다. 해커 입장에서는 반드시 이 데이터를 조작해야 하죠. 그런데 중요한 것은 해커는 입력값을 단지 조작만 했을 뿐 그 결과 값이 무엇인지 모른다는데 있습니다. 따라서 결과 값을 메모리에서 수정할 수 없는 상황이 되는 것이죠. 이 상황에서도 해커는 다시 이미지 인식이라는 문제로 돌아가게 됩니다.

  • Gravatar Image.
    ㅡ_ㅡmyrootkitinjectioninyourasshole | 2009/11/26 05:01 | PERMALINK | EDIT/DEL | REPLY

    심플즈새끼들도 리버싱책 낸 꼴에 그들 사이트에 실전해킹 얘기하면 그런주제 삼가하라고 손빼기 빌빌대고 본인 블로그에서는 해킹 관련 블로깅할때마다 매번 보안 연관 지어 해명글 주저리 붙여 써야 하는게 싫어서 블로그 폐쇄하고 루트킷닷컴같은 외주 호스팅 포럼에다만 토론하고 ㅡ_ㅡ
    본인 블로그에 중국얘들디도스툴 소스분석한거 올렸다가 어이없는 권고메일만받고 홀리쉩ㅡ_ㅡ
    국내에서 이런 분위기로 해킹을 적의적으로 몰아가니
    중국얘들한테 털려도 고리타분한 보안피플들에게만 취중하니 또 뚫리는거지
    국내에서 클로즈알파마인드 버리고 오픈베타마인드로 해킹을 다뤄야하는데
    요즘 실세가 국내에서 실력파 해커들은 다 중국으로 가서 팀원으로 자리잡고 국내게임뚫는일ㅡ_ㅡㅋ

Name
Password
Homepage
Secret