메모리 해킹을 통한 신한은행 인터넷 뱅킹 송금액 조작
블로그를 돌아다니가 우연히 [재미있는 글]을 보게되었다.
요약하면 인터넷 뱅킹을 이용할 때 송금 내용을 사용자에게 확인을 시켜주는 과정에서
해당 정보가 메모리에 남게 되고 이 메모리 영역을 조작하면
다른 계좌/다른 송금액을 보낼 수 있게 된다는 내용이다.
웹쪽은 전혀 모르기 때문에 일단 현재 사용하고 있는 신한은행 인터넷 뱅킹 프로그램을 이용해 테스트 해보기로 했다. 준비물은 신한은행 ezPlus라는 인터넷 뱅킹 프로그램과 TSearch라는 메모리 search 프로그램이다.
1. 내 계좌에서 다른 계좌로 메모리에서 찾기 쉬운 금액을 송금을 한다. (ex, 12,345원)
2. 사용자에게 송금 내용이 맞는지 확인하는 창이 떴을때 Tsraech를 이용해 ezPlus에서 사용하고 있는 메모리 영역 중 송금액과 일치하는 data가 있는지 검사한다.
3. 찾아보니 실제 두군데 메모리 영역이 나왔다. 둘다 1원 모자라는 값으로 수정하고 다시 ezPlus로 가서 비밀번호를 입력하고 송금하기를 누른다.
4. 실제 송금 내용을 확인하는 창을 보니 1원 모자라는 금액이 송금이 되었다.
5. 계좌조회를 하니 실제 송금된 내용도 1원 모자랐다!!
세상에!! 내가 쓰는 프로그램이 이렇게 해킹하기 쉽다니..
물론 사용자에게 송금 내용을 확인시키는 창이 다시 나오니 쉽게 잘못됐다는 것은 알 수 있었지만 만약에 외우고 있지 못하는 계좌번호 같은걸 바꾸면 그냥 무심코 넘어 갈수도 있을것 같고 사용자에게 보여주기 전에 원상복구 시키면되니 감쪽같이 다른 계좌에 다른 금액을 보낼 수 있을듯하다.
실제 계좌번호도 바꿔보고 싶었지만 int값이 아닌지 검색이 안되더라..아마 스트링으로 저장되었을듯 한데 이것도 뭐 찾으려고 하면 못찾을 것도 아니니..
방송에도 나오긴 했지만 웹도 허술하고 전용 프로그램도 허술하기는 마찬가지로구나..
-------------------------------
더 찾아보니 완벽한은 아니지만 [해결방법에 대한 글]이 있네요 =)
역시 이쪽 바닥에서 완벽한 방패는 없는 걸까요?
(0) 
(0)
댓글을 달아 주세요
와~ 정말 심각하군요. 조만간 이런 문제를 해결한 제품이 나오겠죠? 불안 불안~
저야 사용자이면서 공격자였기 때문에 손쉽게 가능하긴 했지만(사실 얻은건 없죠 ㅎ) 실제로는 뭔가 좀더 복잡하겠죠..인터넷에서 직접 사용하는 것 뿐만 아니라 은행이나 증권사에서 제공하는 Application도 좀 고민을 해서 만들어야 할것 같네요=)
이야.. 명색이 보안 프로그램이랍시고 나와있는게 메모리 억세스 한번에 뚫린단 말이야? 저런 방식이라면 어짜피 맘먹고 달려드는 시도는 못막았겠지만 최소한의 체크섬도 없었다는게 안타깝다.
그냥 Int 잡아서 메모리를 쓰는게 문제인듯 보통 이런건 값을 나눠서 저장해야 할것 같은데 프로그램을 대충 만든듯..뭐 그것도 맘먹고 어찌될진 모르지만 나같은 해킹에 무지한 사람도 손쉽게 가능하다는게 문제인듯해 ㅎㅎ
값을 나누건 뭘하건 클라이언트에서 하면 절대로 뚫린다. 소프트아이스가 있으면 너도나도 슈퍼해커ㅎㅎ... 신뢰할 수 있는 값(키보드입력)을 신뢰할 수 있는 방법으로 수시로 서버에 보내놓고 비교하는거 말고는 답이 업ㅂ다.
초기 입력값과 나중에 보낸값고 비교를 하면 될것 같기는한데..아무리 생각해봐도 뚫으려면 가능할것 같단 말이지..
근데 입력한 값을 한순간이라도 메모리에 안올리고 서버로 전송할 수 있는건가?
소켓베이스에서 메모리에 안올리고 전송할 수는 없고.. 메모리에 올리는 유무가 중요한게 아니라 메모리를 변경해도 전송되는 값에는 변화가 없도록 하는게 이슈지.
첨에 글을 잘못읽고.. 내부쪽 해킹을 하신줄 알고 놀람을 금치못했는데.. 클라이언트 였군요...
클라이언트에서 돌아가는 모든 프로그램은 메모리 조작 당연히 가능합니다.
보안상에 헛점이라고 하기엔... 좀 그렇네요 ^^;;
그렇게 수정된 데이터가 서버에 전송되서 금융거래가 이루어지니 엄청난 보안상의 헛점이죠. 개발한 사람 시말서 쓰거나 닭집차리겠네요
말씀하신것처럼 메모리 조작이 당연히 가능하다는 것을 아는 개발자가 이에 대한 대비를 안했다는 것은 분명 보안상의 헛점이 맞는것 같습니다. 더군다나 실제 돈이 거래되는 Application인데 저런식으로 동작한다는 것은 문제가 있죠. =)
제가 이제까지 썻던 프로그램중에 메모리 조작을 막아놓은 프로그램은 없었던걸로 아는데...
(제 기준입니다.)
메모리 조작으로 인해서 해당기관에 미치는 영향은 전혀 없기때문에 상관없는게 아닐까요?
실제 서버 해킹이면 난리나겠지요... 하지만 금융기관도 실제 기간계는 서버와의 통로는 따로
있고 내부 네트웤으로연결되어 있어서 해킹이 쉽진 않겠지만요..
외부에서 메모리를 변경하는 것을 막을 수 있는 방법은 없지만 실제 메모리에 data를 올릴때 외부에서 검색이 힘들에 하거나 메모리 값에 대한 validation을 server-side에서 검사하는 프로그램들은 있습니다.
위 방법이 실제 없는 돈을 보내거나 하는 것이 아니여서 문제가 없다고 볼 수도 있지만 사용자가 공격자가 아닌 경우 사용자가 보낸 돈이 전혀 엉뚱한 계좌로 이동될 수 있기 때문에 충분히 문제가 될것 같습니다. =)
실제로 미래에셋에서 제공하는 프로그램은 위의 방법으로 간단히 송금액을 찾을 수는 없더군요=)
여튼 저 같은 생각때문에 보안상에 구멍이 나는걸수도 있겠네요 별거 아니라는 생각에서부터
시작이 될 수 있으니까요...;; 좋은 글 감사합니다 ^^
클라이언트 사이드에서 메모리 수정해서 뚤릴 정도로 개념없게 만드니까 문젠거 같은데..
애초에 ActiveX를 이용해서 쉽게 만드려는 생각 자체가 문제라고 생각해.
물론 ActiveX도 개념있게 만들면 이렇게 클라이언트 메모리 수정하는 정도로 뚫리진 않겠지만..
ActiveX 없이도 인터넷 뱅킹이나 웹에서 결제를 할수 있었으면 하는 모질라 유저의 생각이야.
외국을 바바. (인터넷 뱅킹은 몰겠지만) 결제는 https만으로 구현한 Paypal 가지고 잘만 하잖아.
우리나라 사이트들도 새로 만들 자신 없으면 그냥 Paypal 한글화해서 지원했으면 해.
윗분 말씀 중에 메모리해킹에 액티브엑스와 무슨 관계가 있을까요? 웹이던 전용 프로그램이던 액티브엑스이던 메모리해킹으로 전송되기 직전에 데이터를 변경하는 건데요...제 생각엔 웹의 환경이라면 메모리해킹에 더 쉽게 노출될 겁니다. https는 어차피 전송하는 단계에서 암호화를 거는 것이니까요...
"물론 ActiveX도 개념있게 만들면 이렇게 클라이언트 메모리 수정하는 정도로 뚫리진 않겠지만.."
정도로는 변명이 안되나요?
제 의견의 핵심은 클라이언트 사이드에서 메모리 변조해서 뚫리게 만드니까 문제라는 것이고,,
이것이 IE 메모리를 변조해서 문제가 된다면 그 역시 마찬가지의 문제겠죠.
중요한 것은 이런 데이터는 서버 사이드에서 처리한다면 단순한 메모리 변조로 문제가 발생하지는 않을 것이란 것이었습니다.
"개념 있게" 라고 했던 것도 클라이언트 사이드에서 중요한 정보를 처리하지 않아야 함을 의미하는 것이구요.
Paypal 을 언급한 것 역시 결제 관련 프로세스를 클라이언트에서 처리하지 않는 예를 든 것입니다.
사실 ActiveX 이야기는 사족인 셈이죠.
뭐 흥분한 모질라 유저의 항변이라고 생각해주세요.
Paypal 얘기를 꺼낸 것도 사실 이와 무관하지 않구요.
"결제는 https만으로 구현한 Paypal 가지고 잘만 하잖아."
라고 했던 것은 전송단계의 암호화만을 가지고 (클라이언트 사이드의 도움 없이) 구현해도 결제를 잘 할 수 있다. 라는 뜻이었습니다.
흠..님께서 지적하신 것처럼 ActiveX쪽이 암호화를 안해서 문제가 있고 paypal은 암호화를 하니까 문제가 없다 라는 뜻은 아니었지요.
뜻하지 않게 장문이 되어버렸네요.
개념 원리가 부족한건 사실이군요 =)
보안사랑님의 리플은 연결 블로그도 없고 광고 뉘앙스가 풍겨 삭제했습니다
방금 신한 인터넷 뱅킹 신청하고왔는데
와우 ...... 신기하네요 ,,,,,
전 옛날 고전게임 목숨 올리는 수준으로 티서치 사용하고있었는데
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ