MITM공격에 따른 password 노출 취약점 #99

taeguk · 2016-03-17T05:12:48Z

회원가입하는 부분에서 password를 암호화하지 않아 네트워크 상에서 중간자공격을 당할 시, password가 그대로 노출되는 취약점이 있습니다. (로그인, 비밀번호 변경 부분에도 같은 취약점 존재)
해결방법은 sha512같은 단방향 해쉬 알고리즘을 사용하여 password를 암호화한 후 서버로 전송하면 됩니다.
http://pajhome.org.uk/crypt/md5/sha512.html
등을 이용하여 javascript단에서 form 전송 시 password를 sha512로 hash해주면 좋을 것 같습니다.

minhoryang · 2016-03-17T07:30:46Z

@taeguk 헤헤! 우리는 letsencrypt로 https를 걸어버릴 예정이에요!
그래도 sha512가 필요할까요?
https와 cert pin을 건다면?

taeguk · 2016-03-17T07:54:38Z

@minhoryang 제 생각에는 그래도 client단에서 비밀번호는 hash를 해야된다고 생각해요.
Server는 무슨 일이 있더라도 유저의 비밀번호 원문을 알 수 있으면 안되요. https를 사용할 경우, server는 암호화된 유저의 password를 복호화하여 원문을 알아 낼 수 있고 만약 server가 해킹당한 상황이라면 이때 유저들의 password는 고스란히 해커의 손에 넘어가고 다른 사이트에 적용시켜 유저의 피해가 야기될 수 있기 때문이죠~
따라서 애초에 password같은 정보는 그 누구도 원문을 알 수 없도록, client에서 빠져나올 때 hash하는 것이 옳다고 생각합니다...ㅎㅎㅎ

minhoryang · 2016-03-17T07:58:03Z

저희가 전달받은 password는 salt와 pepper가 칠해져 bcrypt로 해슁되어있어요!

회원가입
https://github.com/SGCSRelease/AwesomeTitle/blob/master/user.py#L75
로그인
https://github.com/SGCSRelease/AwesomeTitle/blob/master/user.py#L160-L163

taeguk · 2016-03-17T08:06:23Z

@minhoryang 하지만 server측에서 db에 저장하기 전에 hashing하는 거라서 client와 server가 통신할 때 사이에서 패킷을 감청하면 password 원문을 알아낼 수 있어요!

minhoryang · 2016-03-17T08:14:21Z

그걸 https로 막겠다는거지요! 그래도 안되나요?

taeguk · 2016-03-17T08:18:16Z

@minhoryang https를 해도 Server가 해킹됐을 경우에는 password 원문이 노출되는 것을 막을 수 없어요 ㅠㅠ https는 'hash'가 아니라 '암호화' 이기 때문에 결국 server에서 복호화가 되는데, 이때 서버가 해킹된 상태이면 해커가 틈새를 노려 password 원문을 빼내갈 수 있죠..
https만으로도 보안이 어느정도 강력해질테지만 제일 완벽한 건, client단에서 javascript로 hashing하는 것 같애요~

JimJeon · 2016-03-17T08:55:59Z

당신들.... 넘나 멋져요!!!

minhoryang · 2016-03-17T10:29:39Z

지금 taeguk.reluv.me도 보면 reversed proxy로 .105에서 .104를 바라보게되어있고,
.104는 외부에서 접근이 안되니까 괜찮다고생각해요.
SQLAlchemy는 SQL Injection을, Jinja2는 XSSInjection을 막아줘요. 한번 이쪽을 시도해봐주세요.

minhoryang · 2016-03-17T10:31:39Z

지금은 taeguk이랑 같은 linux를 공유하지만, 실서비스시 (나중에는) 당연히 별도의 vm으로 구분되어있을거에요.
Https 트래픽도, .105에서 http로 까져서 .104에서 서비스하는게 아니라,
.104까지 끝까지 https로 보낼거에요.
진짜 그때는 "서버가해킹됬을때"가 문제가되는거죠.

minhoryang · 2016-03-17T10:32:42Z

JS해싱은, 사실 더 위험한 방식이라고 생각하는데, 우선 표준이 아니구요. 암호화기법자체를 노출하는거라, 해킹 이후에 콜루젼찾기가 더 쉬워요

minhoryang · 2016-03-17T10:33:32Z

다른 클라이언트 이식도 힘들구요.

minhoryang · 2016-03-17T10:34:11Z

JS암호화스크립트를 믿을 수 있는지도 모르겠어요. 적어도 bcrypt는 openssl을 이용하거든요. ssh도 https두요

minhoryang · 2016-03-17T10:35:34Z

서버를 해킹해서 접근할 수 있다면, 제가 노릴건 해싱이아니라 클라코드수정일거에요.

minhoryang · 2016-03-17T10:39:06Z

우리사이트뿐만아니라 다른사이트의 정보까지 순순히 뺃어올 수 있는데요 ㅎㅎ

minhoryang · 2016-03-17T12:39:55Z

http://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side
http://stackoverflow.com/questions/3715920/about-password-hashing-system-on-client-side

taeguk · 2016-03-17T14:16:47Z

음 https를 이용하는 것과 client단에서 javascript hashing하는 것중 어떤게 보안이 뛰어날 지를 비교하려는 것은 아니에요.
단순히 보안 측면에서
지금 코드 < javascript로 password를 hashing하는 것
https < https + javascript로 password를 hashing하는 것
이라고 생각하기 때문에 javascript를 이용해서 password를 hashing하는 게 옳다고 생각해요

taeguk · 2016-03-17T14:19:53Z

어떻게 보면 99%냐 99.9%냐의 얘기같은데,
서버가 해킹당했을 때 해커가 무엇을 할 지 가연성을 따지는 것을 떠나서, 만약 그것이 user의 raw password를 알아내는 것이라고 가정했을 때, javascript로 hashing을 한 경우가 보안이 더 뛰어날 것이라는 점이에요~ 해커가 레인보우테이블을 이용하든 콜리젼을 찾든 해야할 작업이 더 늘어나기 때문에요..

juice500ml · 2016-03-17T15:11:22Z

오.. 오오오... 뭐야 여기..

minhoryang · 2016-03-17T15:44:51Z

음. 우리는 https를 꼭 도입할 거에요. 그래야만해요. 개인정보를 관리하기 때문이에요. 지금은 alpha/beta니까 괜찮은거구요. 나중에 주소록기능을 도입하게 되는 순간, 아니 그보다 전에 https로 넘어갈 거에요.

minhoryang · 2016-03-17T15:45:27Z

https가 필수이기 때문에, 문제는 'javascript로 password를 hashing하는 것'을 할 필요가 있는가? 로 바뀌어요.

minhoryang · 2016-03-17T15:46:23Z

"javascript로 hashing을 한 경우가 보안이 더 뛰어날 것이라는 점이에요"

보안이 뛰어나 지지 않아요. 해커가 더 귀찮아지는 것 뿐이지요.
이는 보안이 뛰어나다고 말할 수 없어요.
고로

"어떻게 보면 99%냐 99.9%냐의 얘기같은데,"

가 아니에요.

반대로 우리가 사용한 js라이브러리의 취약점이 밝혀진다고 가정해보면, 그 때는 보안이 무너진거죠.
(wordpress나 phpmyadmin처럼 많이 쓰는 곳에 공격이 더 자주 일어나는 이유를 생각해보면되요. github에서 그 라이브러리를 사용하는 곳을 찾은다음, 공격을 시도하면 되죠.)

이렇게되면 99%(해커가 우리의 존재를 아느냐) vs 0%(모르느냐)로 바뀌어요.

https + javascript로 password를 hashing하는 것

이 상황에서는 js라이브러리의 취약점이 공개된다면 https의 노력에도 불구하고, 패스워드는 뚤리게 되는거죠.

minhoryang · 2016-03-17T15:51:54Z

그러면 다시 생각해봅시다.

minhoryang · 2016-03-17T16:06:43Z

mitm 문제는 https가 해결해 줄 것.
perhaps
- 서버가 뚤리는 것을 걱정하는 것 보다, 신뢰할 수 없는 JS sha512라이브러리를 안쓰는게 더 쉬움.
  - 차라리 https://www.w3.org/TR/WebCryptoAPI/ 를 써요.
  - http://caniuse.com/#search=crypto

taeguk · 2016-03-17T16:06:46Z

음... 어차피 client <---https---> server 같은 식으로 client(browser)와 server가 통신할때 https를 사용하게 되는 건데, hashing을 하고 안하고의 차이는 client가 server로 넘기는게 raw password 냐 hashed password 냐의 문제기 때문에 만약 js라이브러리가 취약하고 뚫린다고 하더라도 보안성이 hashing을 사용하지 않을 때랑 똑같아 질 뿐이지 더 나빠지진 않아요.
https와 hashing이 사용되는 구간이 서로 완전히 다르기 때문에 hashing이 뚫렸다고 하더라도 https가 뚤리지는 않아요.

minhoryang · 2016-03-17T17:08:47Z

Neither MFC...

minhoryang · 2016-03-17T17:09:16Z

그래서 나온게 Adobe Flash/Silverlight/ActiveX 등이 있습니다.
결국 다 똥이죠.

minhoryang · 2016-03-17T17:10:14Z

그래서 있는 라이브러리를 쓰자는겁니다.

taeguk · 2016-03-17T17:10:19Z

음 근데 잘 믿기지가 않네요. 관련 자료가 있을까요?? ㅠㅠ

taeguk · 2016-03-17T17:10:51Z

근데 제가 소개한 라이브러리가 아닌 다른 걸 쓰더라도 결국엔 javascript library를 써야해요
client에서 동작해야하기 때문에

minhoryang · 2016-03-17T17:17:55Z

못찾겠습니다. 잘못된 주장이라고 생각해주세요.

taeguk · 2016-03-17T17:18:32Z

음..그러면 js가 불안정할 수 있으므로 password hashing같은 critical한 기능을 넣지 말자?? 가 주장이신건가요?? ㅎㅎㅎㅎ

minhoryang · 2016-03-17T17:18:53Z

http://arxiv.org/abs/1502.07373

minhoryang · 2016-03-17T17:19:10Z

우선 네. js를 믿지 않습니다 ㅠㅠ

minhoryang · 2016-03-17T17:20:40Z

그런데 이런 의견들도 있네요
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

WHAT'S A "MALLEABLE RUNTIME"? WHY ARE THEY BAD?

https://tonyarcieri.com/whats-wrong-with-webcrypto

taeguk · 2016-03-17T17:22:55Z

근데 javascript sandbox escaping같은 작정하고 노려진 js엔진 버그나 취약점은 당연히 있는건데 (엔진도 프로그램이니까)
형 말씀대로 잘 알려진 혹은 믿을민한 js hashing library를 사용하면 괜찮은거 아닌가요??

minhoryang · 2016-03-17T17:24:05Z

libsodium이 믿을만한 라이브러리긴 한데요. libsodium.js는 믿을만한 라이브러리는 아니에요.
libsodium.js로 컨버팅 하면서 신뢰성이 사라졌다고 생각해요.

minhoryang · 2016-03-17T17:25:39Z

https://gist.github.com/jo/8619441

minhoryang · 2016-03-17T17:28:28Z

컨버팅된 결과물은, 버전 글리치가 생긴다고 생각하고 있어요.

taeguk · 2016-03-17T17:30:01Z

음 그렇군요... 근데 사실 hash algorithm '구현'은 복잡한 엔지니어링 이슈같은게 물려있는게 아니라 그냥 수학적인 수식을 코드로 옮길뿐인데 버그가 있을 가능성이 거의 없지 않을까요??

minhoryang · 2016-03-17T17:30:45Z

수식을 코드로 옮기면, 느리죠. 그래서 옵티마이즈를 합니다. 문제는 거기서 발생해요. 아 JS는 그보다 조금 더 먼저군요.

minhoryang · 2016-03-17T17:37:05Z

http://j.mearie.org/post/98388202823/telegram
http://j.mearie.org/post/103767495933/high-level-understanding-of-cryptography
http://j.mearie.org/post/109667188208/abstract-and-concrete

minhoryang · 2016-03-17T17:43:32Z

http://crypto.stackexchange.com/questions/10200/is-javascript-rsa-signing-safe

minhoryang · 2016-03-17T17:43:47Z

http://stackoverflow.com/questions/7350885/how-secure-is-javascript-encryption

minhoryang · 2016-03-17T17:48:17Z

자기전에 제가 설득안당하려고하는(?!?) 고집부리는 영역을 좁혀보면

JS안믿는다
로 좁혀지겠네요 ;ㅅ;ㅠㅠ

어? 서버에 raw가 전송되는걸 믿지 않는데 https는 믿으시나요?!

taeguk · 2016-03-17T18:01:21Z

엇 마지막줄이 무슨 뜻이신지 잘 모르겠어요 ㅠㅠ

taeguk · 2016-03-17T18:22:08Z

제 의견을 정리하면 일단 여전히 client단에서 javascript로 password hashing을 하는게 옳다고 판단합니다.
하지만 javascript hash 구현 및 동작이 신뢰가능한지가 실질적인 도입에 있어서 변수가 될 수 있을 것 같습니다.
그래도 저는 도입하는게 옳다고 생각하는게, 만약 rsa같은 경우는 또 모르겠지만 이 경우는 hash라서 만약 미세한 버그가 있어서 hash가 뚫린다 하더라도 보안성이 도입안했을때랑 똑같애지기 때문입니다. (미세할것으로 추정되는 db에 저장되는 해시값의 collision확률 증가를 제외하면) 미세한 버그가 아닌 아예 똑같은 인풋을 넣었는데 그때그때 다른 해쉬값이 나오는등의 엉터리 구현들만 js 라이브러리들에 존재하리라고는 생각하지 않아서요 ㅠㅠ

minhoryang · 2016-03-17T18:24:09Z

다음번에 더 나은 이야기가 될 것 같아요. 저도 계속 생각하고 있을게요.

taeguk · 2016-03-17T18:28:27Z

민호형은 신뢰하지 못하시지만 ㅠㅠ 제가 사용하고 있는 http://pajhome.org.uk/crypt/md5/sha512.html
의 코드만 훏어보더라도 크게 버그가 생길만한 코드가 없어서요 ㅠㅠㅠㅠㅜㅠㅠ

taeguk · 2016-03-17T18:28:58Z

알겠습니다 ㅎㅎ 오래 토론했네요 안녕히 주무세요!!!!

minhoryang · 2016-03-17T18:37:24Z

왜 저를 안 의심해요ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 저부터의심해욬ㅋㅋㅋ
저는... 코드를 훑어보고 버그를 발견하는 능력까진 안되요... OTL

minhoryang · 2016-03-17T18:40:42Z

잘려고 샤워하고왔는데 갑자기 든 생각이
전 password를 완전무결하다고 생각하지 않네요.
그러니까 절대 raw password가 노출될 일이 없다고 생각하지 않아요.
raw password도 노출될 수 있어요.
그래서 시중에 많은 password 관리 툴들이 있지 않을까요. (lastpass, auth0, logmein, keepass, dashlane, 1password, enpass, ...)
저런 툴을 쓰는 사람들은 무엇을 믿고, 저기에 제 password를 맡길까요?

minhoryang · 2016-03-17T18:42:23Z

제 fb password 는 참고로 http로 (아무나) 접속할 수 있는 (저는 외우지 않지만, 링크가 있긴 해요) 1024바이트의 os.random입니다. - _-;; (누가 url에 방문했는지 확인하지도 않아요. 기능도 없고.)

minhoryang · 2016-03-17T18:43:52Z

taeguk added a commit to taeguk/AwesomeTitle that referenced this issue Mar 17, 2016

fixed SGCSRelease#99

9d989b5

taeguk added a commit to taeguk/AwesomeTitle that referenced this issue Mar 17, 2016

fix SGCSRelease#99

f409e25

taeguk mentioned this issue Mar 17, 2016

fix #99 #100

Closed

minhoryang added 새 기능 요청 기존 기능에서의 버그 성지순례 labels Mar 17, 2016

minhoryang closed this as completed Mar 27, 2016

MITM공격에 따른 password 노출 취약점 #99

MITM공격에 따른 password 노출 취약점 #99

Comments

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

JimJeon commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

taeguk commented Mar 17, 2016

juice500ml commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

taeguk commented Mar 17, 2016

taeguk commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016

minhoryang commented Mar 17, 2016