:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/10/20 12:24
정말이지 정신없을 때 짠 코드들을 나중에 다시보게 되면,
이게 코드여 낙서여...가 절로 나옵니다. 최적화는 반드시 필요해요! 쓰지도 않는 변수는 왜 이렇게 많이 선언해놨니
14/10/20 12:25
1번의 경우, 제가 저래서 저희 팀 코딩 가이드라인에 "브레이스 없이 블럭문 쓰지 말 것"을 필수로 해놓습니다. 하루이틀 당하는 문제가 아닌데다가, 매크로와 겹쳤을 경우 난리가 났던 경험이 몇 번 있습니다. 예를 들어
#define DO_SOMETHING(X) foo(x);\ bar(x); if (...) DO_SOMTHING(x); 와 같은 경우는 찾기도 힘듭니다. 2번은 충격과 공포 수준이군요. 읽으면서 헛웃음이 계속 나왔습니다. 정말 세상에 믿을 놈 하나도 없네요.
14/10/20 12:29
타이밍 공격은 소름돋네요.
애초에 저걸 해킹에 사용하고자 한다는 발상을 한것 자체가 대단한듯... 예전에 보안수업 들을때 교수님이 한 말이 기억나네요: "보안은 이론적으로 할수없어서 안하는게 아니라, 하면 불편하거나 낭비가 심해서 못하는" 경우가 많다고...
14/10/20 12:31
1번은 뭐 유명한... Ctrl+C,V가 개발자 망신시킨다는 개발자 속담(?) 이야기고
2번은 예전에 원사운드 작가가 그렸던 만화가 생각나네요.... 보안을 위해서라면 혼자 짤걸 둘이 짜라던가... 예전에 사내 시스템 개발하는데 마지막에 보안성 검토를 통과해야 하는데, 점검해보고 지적사항 나오면 고치자, 이러고 있었는데 최적화를 하기 전이었는지.. 여러사람이 왔다갔다 인수인계 받아가며 짜서 그랬는지.. 그냥 A등급 나와서 런칭했던 적이 있었습죠.
14/10/20 12:36
갑자기 생각난 건데 문자열 비교에서는 사람의 뇌가 보안에 더 안전한 알고리즘인 것 같다는 생각이 드네요.
예전에 EBS에서 사람은 두 문자열을 어떤 식으로 비교하는지를 알아내기 위한 실험이 있었는데 사람은 전체 문자열을 모두 비교한 후에 두 문자열이 다른지 같은지를 판별한다고 하더군요. 문자열 비교에 시간이 얼마나 걸리는지 측정해서 알아내는 방식이었는데 문자열 길이가 같으면 다른 문자가 첫번째에 있든 마지막에 있든 판별에 걸리는 시간은 같았다고 합니다. 물론 끝까지 비교하지 않는 방식으로 훈련하면 결과는 달라질 수도 있을 것 같습니다.
14/10/20 12:43
타이밍 공격 부분이 잘 이해가 가지 않습니다.
비밀번호라는 것은 문자열 그대로 저장되지 않고, 해쉬코드 형태로 저장되는 것으로 알고 있습니다. homura의 해쉬는 h,o,m,u,r,a 각각 글자의 해쉬를 순서대로 합친 것과 다를텐데 어떻게 이런 타이밍 공격이 성립하는 건가요? 아니면 제가 알고 있는 것과는 다르게, 위의 두 해쉬값이 같은건가요??
14/10/20 12:55
저건 아마 DB에 저장된 비밀번호를 그대로 비교하는게 아닌가 싶은데요..
요즘은 단방향 암호화를 시도해서 원래 암호 -> 물리적 해독이 아주 어려운 단방향 암호화 -> 암호화된 문자열 저장을 AD나 DB 등을 이용하여 미리 저장 해두고, 해당 암호를 사용자가 로그인시도를 하면 다시 단방향 암호화를 수행 -> 암호화된 문자열을 저장되어 있는 문자열과 비교하여 봅니다. 구현 로직은 다 다르겠지만요. 위의 타이밍 공격은 암호화가 되어 있지 않은 비밀번호 저장방식에 적합할듯 합니다.
14/10/20 12:57
암호화가 되어 있지 않은 비밀번호 저장방식을 사용하는 곳이 얼마나 되는지 궁금합니다.
암호화 없이 비밀번호를 저장한다는 것에서부터 아주 낮은 수준의 보안수준을 자랑(?)하는 곳인 것 같은데요. 그리고, 암호화하여 비밀번호를 저장하는 방식은 타이밍 공격으로부터 완전히 자유로운 건가요?
14/10/20 13:02
추측컨데 관리가 안되어 보이는 오래된 노후화된 사이트, 개인사이트 등은 거의다 암호화가 안되었을 것 같습니다.
보안이라는 것은 비용이 많이 들거든요. 근데 IT쪽에서 비용절감을 한다면 가장 간과하거나 제거하기 쉬운 부분이 보안입니다. 왜냐면 사고 전에는 티도 안나거든요.. 암호화된 문자열은 길이가 충분히 길어집니다... 또한 해당 문자열이 원본 문자열과 거의 상관없도록 변하거든요. 그래서 타이밍 공격이 안먹힐 겁니다. 원본문자열 하나만 바뀌어도 암호화된 문자열의 구조가 달라질거라 윗 글의 타이밍 공격은 먹히지 않을겁니다. 물론 물리적으로 엄청난 시간과 돈과 노력을 들이면 불가능하진 않겠네요.. 예전 2차 세계대전때 암호화된 전문에 대하여 엄청난 천재들이 결국은 해독을 해내는 것을 보면.. 단지 그정도 가치가 있는 암호 해독이 아니니 아무도 안하는 거겠죠.
14/10/20 13:12
저도 궁금해서 좀 찾아봤는데요
wiki 에 보니까 RSA 기반의 SSL 도 깰 수 있음을 보여줬다고 하네요. RSA key의 1비트 갯수에 따라서 암호화하는데 걸리는 시간이 다르다는군요. http://en.wikipedia.org/wiki/Timing_attack 영어를 잘 몰라서 확실한지는 모르겠네요.;;;; 세상에 참 천재들 많아요.
14/10/20 13:40
쉽게 설명하기 위해 평문 비밀번호를 예로 들었지만, 사실 제가 이 공격을 처음 알게 된 것은 세션 아이디 위조 때문이었습니다. 예전에는 웹 브라우저에 쿠키로 세션 아이디만 저장하고 나머지는 서버에 저장하기도 했지만, 이러면 서버 부하가 커지기도 하고 scalable하지도 않기 때문에 요즘은 쿠키로 세션 정보들을 모두 저장하고 해시로 인증하는 'HMAC'(hash-based message authentication code)이라는 방식이 유행하고 있습니다.
해시를 사용하니까 타이밍 공격에서 안전할 것 같지만, 공격자가 해시의 각 글자를 한 땀 한 땀 조립하는 방식으로(..) 조작이 가능합니다. 예를 들어 MD5는 32글자니까 약간 긴 비밀번호로 취급하면 되는 거죠. 이렇게 하면 임의의 세션 데이터에 대한 해시(정확히는 HMAC 코드)를 알아낼 수 있기 때문에, 세션에 저장된 '로그인된 사용자 아이디'를 쉽게 조작할 수 있습니다. 본문에서 언급한 타이밍 공격에서 안전한 문자열 비교 함수가 hmac.compare_digest() 인 것도 이 때문입니다. HMAC 모듈의 'digest'(=해시) 비교 알고리즘이죠.
14/10/20 14:44
전공자가 아니라 정확히 이해하지 못해서 다시 여쭙겠습니다.
h의 해쉬값이 ho 해쉬값의 일부인가요? 아니면 관계가 있나요? 저는 전혀 관계가 없는 것으로 알고 있었는데, 그렇다며녀 각 글자를 한 땀 한 땀 조립하는 방식이 어떤 것인지 이해가 가지 않습니다. h의 해쉬값과 ho의 해쉬값 사이에 겉으로 나타나는(해쉬 암호화 후) 연관성이 전혀 없다면 어떻게 한 땀 한 땀 조립이 가능한지 이해가 잘 되질 않아서요.
14/10/20 14:52
그러니까 이런 식입니다.
세션 데이터로 'username=madoka' 라는 게 있고, 키가 'akemi'라면, 이걸 md5(data + key) 하여 '3cfae4583ce55fafbacbc4dd26e9edc2'라는 해시 기반 서명(HMAC)을 얻습니다. 그리고 웹 브라우저에 쿠키 형태로 'username=madoka'와 'hmac=3cfa...'를 저장합니다. 이때 클라이언트(=해커)가 임의로 저 쿠키를 'username=admin'으로 바꾼다고 해도 조작이 되진 않습니다. 서버에서 해시를 확인하여 거부하기 때문입니다. 그렇다고 해커가 바뀐 데이터인 'username=admin'에 대해 해시 서명을 작성할 수도 없는데, 키를 모르기 때문입니다. 하지만 타이밍 공격은 여전히 가능합니다. 'username=admin', 'hmac=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' 부터 시작해 보면 되죠. 서버가 만족할 때까지 해시 서명을 변화시켜 가면서 공격하면 됩니다. 일반적인 아이디-비밀번호 공격과 달리, 공격자가 브라우저 쿠키를 조작하여 해시를 직접 입력할 수 있기 때문에, '한 땀 한 땀 조립'이 가능한 것이죠. 즉, 공격이 성공했다고 해서 공격자가 비밀번호를 알게 되는 것은 아닙니다. 단지 서버를 속여서 credential을 얻어 낼 뿐이죠.
14/10/20 15:17
아, 이해했습니다. 비밀번호를 알아내는 게 아니라, 해쉬값 자체에 대해서 타이밍어택을 한다는 거군요.
이 정도면 뭐 어쩔 수 없는 수준이군요. 다행인 점은 같은 비밀번호를 사용 중인 다른 사이트는 안전하다는 거고
14/10/20 12:49
저같은 컴알못도 이해가 쉽게 되네요. 결국 현재의 효율적인 방식으로는 비밀번호 길이를 늘려봤자 시간만 걸린다 뿐이지 결국 뚫리겠군요.
재미있게 잘 봤습니다.
14/10/20 12:57
단방향 암호화로 문자열을 치환하는 경우에는.. 패스워드가 짧은 문자열이라 해도 비교할 문자열의 총 길이는 같습니다.
옛날에 비교하던 방식이라면 적용되지 않나 싶네요.
14/10/20 13:07
본문의 타이밍 어택이라 표현하신게 사이드채널 어택의 한 부류죠.
사이드채널 어택은 정말이지 다양합니다. 패스워드가 해시라서 사이드채널 어택에 취약하지 않으리란 생각은 접어두시는게 좋습니다. 본문의 타이밍 어택이라 표현하신 것과 유사한 방법으로 3DES까지 털립니다.
14/10/20 13:14
보안이라는게 창과 방패와 같아서.. 못뚫는 보안은 없다가 정답이라고 생각합니다.
서버실 침입과 같은 물리적 보안부터 해서 네트워크 보안 등.. 단지, 허가되지 않은 사용자에 의한 보안의 무력화 되는 것을 막기 위하여 해독시간을 물리적으로 길게 늘이거나, 비용을 엄청나게 소모하게 하거나 하는 방법으로 발전되어 왔습니다. "해킹으로 얻을 이익 < 암호해독 비용" 예를 들면 암호하나 해독하는데 1000년이 걸리면 아무 쓸모가 없는 거죠. 아니면 얻을 이익은 그 사람 살아 생전에 없을테니깐요. 그래도 뚫는 방법이 존재하다라는 것은 옳은 얘기입니다. 보안이라는 건 허가자에겐 열리고 불허가자에겐 막혀야 하니깐요. 영원히 유일하게 뚫리지 않을 보안은 외부와 영원히 단절된 시스템뿐입니다.
14/10/20 15:23
문과생이 읽고 관련해서 질문하고 싶은 생각에 질문드립니다!
얼마전에 사이트 들어가면서 드는 생각이었는데, 로그인 화면 주위에 보면 <보안로그인>란이 생겨서 체크할 수 있게 있더라구요. "뭐야 체크 하나로 보안유무가 결정된다는 거야? 당연히 해줘야하는거 아닌가?"라는 생각이 들던데.. 본문과 같은 방법으로 보안을 한다는 건가요? 아니면 제 상상력이 막 갖다 붙이는 건가요? ps. 글은 잘 읽었습니다 신기하네요!
14/10/20 16:13
웹 사이트에서 말하는 보안 로그인이란 보통, 사용자 컴퓨터가 서버와 대화할 때 도청이 불가능한 방법으로 대화하겠다는 것입니다. 즉, 아이디와 비밀번호를 도청이 불가능한 방식으로 서버에 전송하겠다는 뜻이죠.
어떤 컴퓨터와 다른 컴퓨터가 통신하려면 여러 개의 중계 컴퓨터를 거쳐야 합니다. 가장 대표적으로, 인터넷 공유기도 일종의 중계기입니다. 내 컴퓨터 -> 공유기 -> 우리 동네 중계기 -> 우리 시/도 중계기 -> 전국 중계기 -> 다른 시/도 중계기 -> 다른 동네 중계기 -> 공유기 -> 서버 이런 식으로 된달까요. 택배랑 비슷하다고 생각하면 됩니다. 그런데 이 과정에서 각 중계기들은 이론상 오고 가는 데이터를 열어서 볼 수가 있습니다. 택배로 따지면 상하차 알바들이 택배를 까서 내용을 확인할 수가 있다는 것이죠. 특히 해커가 중계기 중 하나에 침입해서 자기 편으로 만들어 놓는다면 문제가 심각해질 수 있습니다. 그 중계기가 커버하는 영역이 넓으면 넓을수록 해커가 볼 수 있는 정보도 많아지겠죠. (택배 지역 영업소가 아닌 전국 물류 센터를 장악하면 더 치명적이듯이) '보안 로그인'이란 내가 보내는 데이터를 최종 목적지 이외에는 누구도 볼 수 없도록 암호화하는 것입니다. 사실 웹 사이트의 내용 전체를 이런 식으로 암호화하면 가장 좋고, 실제로 구글이나 마이크로소프트, 페이스북 같은 회사들은 실제로 그렇게 합니다. (그래서 이들 웹 사이트에 들어가 보면 주소가 https:// 로 시작하고 초록색 마크가 뜨죠.) 하지만 비용이 증가한다는 이유로 민감한 데이터에만 암호화를 사용하는 경우가 있습니다. 그게 바로 보안 로그인이죠.
14/10/20 15:26
첫 코드를 한번 찾아 보았습니다. http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c 여기 있네요. 일단 C의 예외처리 기능에 안습을 한번 표하고 나서도 왜 굳이 goto를 쓰는지 모르겠는 코드네요. 같은 구문이 여러번 반복되는데 그냥 함수로 빼고 구조화를 좀만 더 잘했어도 잡을수 있는 버그같은데요.. http://stackoverflow.com/questions/21999473/apples-goto-fail-security-bug 에서도 비슷한 말을 하는군요.
14/10/20 16:15
말씀하신대로 C의 예외 처리 기능은 빈약하기 때문에, 저는 C에서 goto 쓰는 건 필수적이라고 보는 편입니다. 자원 해제 코드를 별도의 함수로 빼는 건, 뭐랄까 시맨틱이 좀 안 맞는 느낌입니다. 자원 할당과 해제는 같은 장소(=같은 함수 몸체)에서 이루어져야 한다고 생각하는데, C에서 해제 코드를 중복 없이 깔끔하게 쓰려면 goto를 쓰는 수밖에 없더군요.
14/10/20 20:40
그런데 어지간한 경우 do while(false)로 우회 가능하거든요. 중간에 loop 들어가고 하는 경우 goto는 뭐 어쩔 수 없을수도 있지만, 위의 경우는 그것도 아니구요.
14/10/20 16:58
요즘은 CPU가 연산하면서 미세하게 초음파를 내는데 이걸 마이크 한 대로 녹음해서 무슨 유닛에서 무슨 연산이 일어났는지, 레지스터에 무슨 값을 저장했는지를 도청할 수도 있습니다. 예제 동영상에서는 마이크 하나와 노트북 한 대로 다른 컴퓨터에 입력된 패스워드를 빼내더군요. 이 정도까지 가 버리면 뭐 막을 수 있는 방법이 없죠. 어쩌면 NSA 같은 곳에서는 이미 이런 기법을 사용하고 있었을지도 모르고...
14/10/20 17:10
이걸 막으려면 동일 CPU n개 이상에서 더미값을 포함한 연산을 '암호화'한 순번으로 교차중복시행하거나, 초음파 수준에서 CPU연산과 동일한 속도로 '능동소음제거(Active Noise Canceler)'를......
에이 가져가 이놈들아 ㅠㅠ
|