미국시간으로 2014.4.7일 OpenSSL HeartBeat 취약성에 대한 발표가 있었습니다. 또한 패치도 있었으나 문제의 심각성과 여파에 대해서 제대로 인지를 못하는 것 같아서 facebook 에 올렸던 내용을 묶어서 하나의 단락으로 올립니다.
취약성 개요:
https://www.openssl.org/news/secadv_20140407.txt
OpenSSL Security Advisory [07 Apr 2014]
========================================TLS heartbeat read overrun (CVE-2014-0160)
==========================================A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS
입력값에 대한 경계체크가 안된 관계로 연결된 클라이언트나 서버에 대해 64k에 해당하는 메모리 값을 계속 읽어 올 수 있다는 부분입니다. 이 문제만 보았을때는 특별한 이슈가 없을 수 있으나,이 취약성이 네트워크에서의 암호화 전송 상당부분을 담당하는 OpenSSL에서 발생된 문제라는 점에서는 심각한 문제가 발생 될 수 있습니다. Private key가 노출 될 수 있기 때문이죠. 이 문제의 심각성은 다음 예시로 대체.
왜 치명적인 문제인가?
애플이 인증서가 있죠? https 라고 뜨잖아요.
애플은 Private Key를 가지고 있고 사용자가 웹서비스 접속시 Public key를 받습니다.
그리고 사용자가 통신을 할때 Public key를 가지고 암호화를 해서 애플로 전달하면 애플은 자신이 가진 Private key를 가지고 복호화를 하게 되죠. 이게 초기의 키 교환 부분인데..
기업의 웹서버에서 인증서를 발급 받아 이용한다는다는 것은 각 인증서 마다의 Private , Public 키 세트를 가진다는 거죠.
여기에서 가장 중요하게 지켜야 할 것이 Private 키입니다 이게 만능열쇠 이니까... 그러나 OpenSSL 취약성을 이용하여 메모리 정보를 계속 읽어오게 되면 결국에는 Private 키 정보까지도 알아낼 수 있다는 거죠. 그렇게 되면 애플로 접속하는 모든 암호화된 통신들을 열 수 있는 열쇠가 되는거죠.
그냥 암호화가 아니고 평문으로 볼 수 있는 상태라고 해야 하나?
이런게 전 세계의 66% (Apache + Nginx 사용비율) 서비스에서 가능성이 있다고 생각해 보세요. 그리고 이름만 대면 아는 대부분의 유명 서비스들에서 발생 될 수 있다면 이건 .심하게 말하면. 재앙이죠.
개인의 정보라는게 암호로 지켜지지 않으니..
문제는 웹서비스뿐 아니라 이메일, VPN 등등 모든 부분에 이용 비율이 높다는 점!
문제는 심각성을 제대로 인지하지 못하고 있다는 점이라 할 수 있겠죠. 또한 패치가 나와서 문제가 없다는 측면은 다릅니다. 사실 이 취약성이 몇년전 부터 알려져왔고 한국시간으로 4.8일에 공개되었다는 점을 본다면 그 이전의 영향력은 비교하기가 힘들 것으로 보입니다. 패치의 문제를 벗어나는 순간이 되겠죠.
"신속히 패치가 나온다 하여도 전체 서비스에 적용하는 것은 신속하게 되기가 어렵습니다. 연결된 구조와 의존 관계등을 면밀히 고려하지 않으면 또 다른 장애와 직결되는 문제들이 있을 수 있거든요.
단일 서비스의 경우에는 바로 해결 할 수 있으나 연결된 서비스나 연동 서비스가 많을 경우는 패치 적용 부터가 난감한 이야기죠. 게다가 서비스 중지도 해야 하는 것이구요.
취약점은 이번에 공개가 된 것뿐이지만 만약 공개 되지 않았다면? 이런 전제를 하면 문제는 상당히 심각해 집니다. 이런 유형들이 얼마나 많을지는 생각하기도 어려운 상황이구요.
현실의 위험은 상당히 큰 수준으로 존재하고 있고 사용자 PC 단위 이외에도 서비스 영역에서도 언제든 문제가 발생될 수밖에 없는 부분이라는 것을 보았을때는 전체 구조는 다른 방향으로 변화해야겠죠."
Private Key 노출 가능성 확인된 이후 바로 작성한 글은 다음과 같습니다.
XP 종료 따위가 문제가 아니라, 전체 암호화 트래픽을 스노든이 NSA 평문 접속하듯이 할 수 있는 OpenSSL 취약성이 진짜 긴급 대응을 해야 하는 것 아닌가? 이건 지금 당장 발생 되고 있는 긴급한 이슈인데~ 그것도 거의 모든 트래픽들 다수가 영향을 받는데.
최근 PoC 코드들까지 모두 양산된 모양 .
OpenSSL 의 heartbeat bound check 미비로 인해 64k 분량의 정보들이 덤프로 채워져서 마구 노출된다는 이야기. 암호화 되어야 하는 서버와 클라이언트간의 통신이 그대로 풀린 상태로 노출된다는 것. 영향 받는 곳들 매우 많을 곳으로 예상됨.
64K 정보 내에서 Private key를 뽑아 내면 암호화는 그대로 풀려지는 것이고 , 아니라면 정보를 64k 씩만 계속 뽑아내도록 하면 필요한 정보들은 계속 받을 수 있는 것들이고~~ 오래갈 문제.
서비스 운영 중인 곳들이 대부분인데, 중단하고 해야 할 텐데.. 시간은 오래 걸릴 것이고 그러다 보면 정보노출 범위는 계속해서 확대될 것으로 보임. ( 컴파일해서 언제 라이브러리 적용 하노? 이건 정말 몇 년에 한번 할까 말까 한 일을 며칠 사이에 다 해야 하는 상황인 듯 ) 어떻게 보면 오래된 OpenSSL 버젼은 괜찮다고 하는데 라이브러리 구성에 따라서 다른 것들 이다보니~~ 답은 없다. 확인 해 보는 것이 필요!
상업용 서비스나 OpenSSL 이용해서 SSL이나 TLS 암호화 구성하는 라이브러리 이용하는 모든 곳들은 점검이 필요함.
저기 금융권이나 통신 , 메시지 , SNS 업체들 모두가 필요할 듯.
* 어디 있더라? OTP 에 SSL만 쓰면 안전하다는 분들은?
상세 취약성 관련 내용
아래는 보안권고문 - Dependency 관계로 업그레이드 여의치 않으면 핫빗 안 쓰도록 옵션 주고 다시 컴파일 하랍니다. 허허 이 이야기는 서비스 중지 시키란 이야기죠.
https://www.openssl.org/news/secadv_20140407.txt
*참고로 SSL + OTP 로 개인에게 설치되는 공인 인증서를 대체 할 수 있다는 Opennet의 경우에도 웹서비스의 인증서에서 핵심인 Private Key 유출 가능성을 가지고 있었습니다.
결론:
결론에 대한 내용과 제 생각은 올린 글로 대체 합니다.
냉정하게.. OpenSSL Heartbeat 을 이용한 Private key 유출 가능성이 가지는 심각한 문제성에 대해 모른다면 ..어디 가서 해킹이네, 보안이네 안다고 하지 마라.! 전문가라고도 하지 말고.. (기술적 보안 분야에서 )
그리고 어제 밤에 단순 패치 인줄 알다가, 내용 확인하고 진땀이 흘러서 급하게 썼는데 .. 참나~ 자격증도 없지만 씨사나 씨습 자격증이나 학원에서 공부한 학생들도 Private key (이건 개인이 가지는게 아님) 가 유출되면 어떤 문제가 발생될 지는 알겠다.
생각들 해야 할 듯. 전 세계 66% 이상의 서비스들에 대해서 투명창으로 내부를 다 들여다 볼 수 있는 ..집집마다의 열쇠들을 도둑이 모두 가질 수 있다는 가능성을.. 이미 가졌을 수도 있고~
보안서버? 암호화? - 이런 건 기업에서는 어쩔 수 없이 당할 수 밖에 없다. 그러나 체계가 잡힌 조직이라면 영향력 파악 , 대응 절차, 실행 , 관찰 프로세스로 나간다. 그냥 대충 땜빵들 하고 업데이트 했으니 끝났을꺼라고 하지만 취약성은 이미 몇 년전에 나온 거구.. 공개만 어제 된 것일뿐. 그 사이 뭔 일이 있었을까?
해킹 ? 보안? 전문가? 헐..
파급력은 커녕 위험성 평가도 제대로 안되는 판국에 무슨 대응이란 말인가? 사안이 인지도 안되면 그 다음은 없는 거나 마찬가지다.
국가는 떠나서 일개 기업이나 단체에서라도 파급력과 영향력을 파악하고 대응방안과 신속한 실행을 해야 하는데 그걸 누가 해야 하는가? 기업내에서도 "현재 운영 중인 서비스 잠시 중단 해야 합니다" 라고 말도 못 꺼내는 입지라면 하나 마나다.
진짜 전문가와 전략가는 이 순간에 경영을 위협하는 심각한 리스크를 인지해야만 한다. 그리고 결단을 하고 실행을 해야 한다. 근데 우리나라에 있는 CIO나 CSO , CISO 분들 중에 이럴 분들이 있을까?
답은 잘 아실 듯.
*참고로 우리는 이런 심각한 상황을 맞이 했음에도 불구하고 XP 종료 대응이라는 이벤트만 했을 뿐이다.
- 바다란
===== 추가 ======
대응:
단순 패치 참고 - http://yisangwook.tumblr.com/post/82056087918/openssl-heartbeat-heartbleed
기업이나 서비스의 상황을 살펴 보면 단순한 패치로 문제가 해결되기 어렵습니다. 1차적으로 SSL 이용하는 부분에서 OpenSSL 사용유무 확인 및 패치는 기본 적용
1. SSL 버젼 확인 - 패치 적용 , 기본
2. 업그레이드 불가한 곳은 OpenSSL 연결 패키지 Heartbeat 옵션 제거후 재컴파일 및 사용
3. 대외 서비스의 경우 ( 중요도가 높거나 사용자가 많은 곳) 서비스 SSL 인증서 재발행 필요
4. 전체 IP 대역에서의 443 포트 활용 및 SSL 활용 유무 체크
- SSL Heartbeat 취약성을 이용해 메모리 값을 불러 올 수 있는 진단 프로그램 전체 활용
5. 보안 제품 , VPN , 메일 등등 모든 제품에서의 SSL 옵션 사용하는 곳들도 동일하게 확인
* 이 과정에서 서비스들이나 네트워크들의 간헐적인 중단이 될 것입니다. 또한 보안 장비들도 거의 모든 장비들이 SSL 지원을 하고 있으니 그 부분들도 모두 체크를 해 보셔야 됩니다.
*서버의 메모리 값을 읽어 간다는 것은 메모리내에 풀려진 모든 값들을 어떻게든 가져갈 수 있다는 것이 됩니다. 그래서 가장 우려하는 Private key도 유출될 가능성이 높다는 것이죠. 현재는 취약한 서비스들 ( 생각보다 휠씬 더 많습니다. )에서는 세션정보 , 평문으로된 ID/Password 연결 정보등이 노출이 되고 있는 상황임을 염두에 두세요.
현재 상황은 private key 유출은 확인 되지 않았으나 정보들은 유출 되고 있는 상황입니다. 또한 로그들도 안 남는 상태라 문제는 심각하죠.
[Mark Loman (@markloman)] Do not login to Yahoo! The OpenSSL bug 'heartbleed' allows extraction of usernames and plain passwords!
'Security Indicator > Insight' 카테고리의 다른 글
한노총,우정노조,화학노조 악성코드 유포 (APT 침입 대응 필요) (0) | 2014.05.16 |
---|---|
망분리 맹신하다 당한 국가 기반망 - 해상관제망에 외부침입 흔적 (2011년) (0) | 2014.04.28 |
"LTE급 재앙과 광대역 피해가 온다."- 유.무선을 동시에 공격 (0) | 2014.03.20 |
2012년 티켓몬스터 악성코드 유포-탐지내역 (0) | 2014.03.07 |
[컬럼] “좀비PC 1대가 대형유통업체를 벼랑으로 몰다!” (0) | 2014.02.26 |