CVE-2014-0160 AKA "Heartbleed"란 정확히 무엇입니까? 원인, OpenOS의 OS 및 버전이 취약한 이유, 증상은 무엇이며 성공적인 악용을 탐지하는 방법이 있습니까?
시스템이 영향을 받는지 어떻게 확인할 수 있습니까? 이 취약점을 어떻게 완화 할 수 있습니까? 내 키 또는 기타 개인 데이터가 손상되었는지 걱정해야합니까? 다른 부작용은 무엇입니까?
CVE-2014-0160 AKA "Heartbleed"란 정확히 무엇입니까? 원인, OpenOS의 OS 및 버전이 취약한 이유, 증상은 무엇이며 성공적인 악용을 탐지하는 방법이 있습니까?
시스템이 영향을 받는지 어떻게 확인할 수 있습니까? 이 취약점을 어떻게 완화 할 수 있습니까? 내 키 또는 기타 개인 데이터가 손상되었는지 걱정해야합니까? 다른 부작용은 무엇입니까?
답변:
먼저 , 기절하기 전에이 취약점이 실제로 자신에게 적용되는지 여부를 이해해야합니다. 서버가 있지만 실제로 TLS를 사용하는 응용 프로그램이없는 경우에는이 문제를 해결하는 것이 우선 순위가 아닙니다. 반면에 TLS 지원 애플리케이션 을 보유한 적이 있다면 치료를받을 수 있습니다. 읽어:
CVE-2014-0160, 즉 "Heartbleed"란 정확히 무엇입니까?
그것은 큰 혼란스러운 혼란입니다. 요컨대, 공격자가 시스템 메모리의 특정 부분을 읽을 수있는 OpenSSL 버전 1.0.1 ~ 1.0.1f에서 원격으로 악용 가능한 취약점이 발견되었습니다. 개인 키, 미리 공유 한 키, 암호 및 중요한 기업 데이터와 같은 중요한 데이터를 보유하는 부분입니다.
이 버그는 Google Security의 Neel Mehta (2014 년 3 월 21 일)와 핀란드의 IT 보안 테스트 회사 인 Codenomicon (2014 년 4 월 2 일)에 의해 독립적으로 발견되었습니다.
원인이 무엇입니까?
글쎄, OpenSSL의 잘못된 코드입니다. 여기 에 취약점을 도입 한 커밋이 있고 여기에 취약점을 해결 한 커밋이 있습니다. 이 버그는 2011 년 12 월에 나타 났으며 오늘 2014 년 4 월 7 일에 패치되었습니다.
버그는 더 큰 문제의 증상으로 볼 수도 있습니다. 두 가지 관련 문제는 (1) 잘못된 코드가 코드베이스에 도입되지 않도록하는 프로세스와 (2) 프로토콜과 확장이 왜 그렇게 복잡하고 테스트하기 어려운지입니다. 항목 (1)은 OpenSSL 및 기타 여러 프로젝트의 거버넌스 및 프로세스 문제입니다. 많은 개발자들이 코드 검토, 분석 및 스캔과 같은 관행에 저항하기 만합니다. 항목 (2)는 IETF의 TLS WG에서 논의되고 있습니다. Heartbleed / 프로토콜 복잡성을 참조하십시오 .
잘못된 코드가 악의적으로 삽입 되었습니까?
나는 이것이 정말로 실수인지 나쁜 행위자를 대신하여 약간의 코드가 미끄러 졌는지 추측하지 않을 것이다. 그러나 OpenSSL 용 코드를 개발 한 사람은 코드가 잘못되었다고 말합니다. 참조 그가 의도적으로 삽입 거부 심각한 'Heartbleed와'보안 결함을 도입 남자 .
어떤 OS 및 OpenSSL 버전이 취약합니까?
위에서 언급했듯이 OpenSSL 1.0.1 ~ 1.0.1f에 연결된 모든 운영 체제 또는 응용 프로그램.
성공적인 악용을 탐지하는 방법에는 어떤 증상이 있습니까?
이것은 무서운 부분입니다. 우리가 아는 한,이 취약점이 악용되었는지 여부를 탐지하는 알려진 방법은 없습니다. 이론적으로이 악용을 탐지 할 수있는 IDS 시그니처가 곧 릴리스 될 수 있지만이 문서를 작성할 당시에는 사용할 수 없습니다.
Heartbleed가 2013 년 11 월 초에 야생에서 활발하게 이용되고 있다는 증거가 있습니다. EFF의 Wild at Heart : 2013 년 11 월에 Heartbleed를 사용한 정보 기관이 있었습니까? 그리고 Bloomberg는 NSA가 취약점이 도입 된 직후에이 취약점을 악용했다고보고했습니다. 수년 동안 인텔리전스를 위해 하트 블리드 버그를 악용하기 위해 NSA에서 발표 한 내용 참조 . 그러나 US Intelligence Community는 Bloomberg의 주장을 부인합니다. 레코드의 IC를 참조하십시오 .
시스템이 영향을 받는지 어떻게 확인할 수 있습니까?
시스템에서 OpenSSL을 유지 관리하는 경우 간단히 다음을 발행 할 수 있습니다 openssl version
.
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
배포판이 OpenSSL을 유지 관리하는 경우openssl
명령 또는 패키지 정보 (예 apt-get
: dpkg
, yum
또는 rpm
)를 사용하여 백 패치로 인해 OpenSSL 버전을 확인할 수 없습니다 . 대부분 (전체?) 배포에서 사용하는 백 패칭 프로세스는 기본 버전 번호 (예 : "1.0.1e") 만 사용합니다. 효과적인 보안 버전 (예 : "1.0.1g")을 포함 하지 않습니다 .
패키지가 백 패치 될 때 OpenSSL 및 기타 패키지의 효과적인 보안 버전을 결정하기 위해 수퍼 유저에 대한 공개 질문이 있습니다. 불행히도, 유용한 답변은 없습니다 (distro의 웹 사이트 확인 이외). 백 패칭에 직면 할 때 유효 보안 버전 확인을 참조 하십시오 .
일반적으로 영향을받는 버전 중 하나를 설치하고 OpenLS와 TLS 지원을 연결하는 프로그램이나 서비스를 실행 한 적이 있다면 취약합니다.
취약점을 테스트 할 프로그램을 어디서 찾을 수 있습니까?
Heartbleed 발표 후 몇 시간 내에 인터넷상의 여러 사람들이 공개적으로 액세스 할 수있는 웹 응용 프로그램을 공개하여이 취약점이 있는지 서버를 확인하는 데 사용될 수 있습니다. 이 글을 쓰는 시점에서, 나는 아무 것도 검토하지 않았으므로 그들의 응용 프로그램을 더 이상 공개하지 않을 것입니다. 선호하는 검색 엔진의 도움으로 비교적 쉽게 찾을 수 있습니다.
이 취약점은 어떻게 완화됩니까?
취약하지 않은 버전으로 업그레이드하고 취약한 데이터를 재설정하거나 다시 보호하십시오. Heartbleed 사이트 에 명시된 바와 같이 적절한 대응 단계는 다음과 같습니다.
자세한 분석 및 답변 은 웹 사이트 운영자가 Heartbleed OpenSSL 익스플로잇에 대해 어떻게해야합니까?를 참조하십시오 . 보안 스택 교환에.
내 키 또는 기타 개인 데이터가 손상되었는지 걱정해야합니까? 다른 부작용은 무엇입니까?
물론. 시스템 관리자는 취약한 OpenSSL 버전을 사용하는 서버가 실제로 손상되어 그에 따라 대응 한다고 가정 해야합니다 .
이 취약점이 공개 된 직후 Cloudfare는 서버의 개인 키를 실제로 복구 할 수 있는지 확인하는 문제를 제기했습니다. 도전은 Fedor Indutny와 Ilkka Mattila에 의해 독립적으로 이겼습니다. Heartbleed Challenge를 참조하십시오 .
자세한 정보는 어디서 찾을 수 있습니까?
자세한 내용을 찾는 사람들을위한 링크 덤프 :
공개 이벤트의 다소 자세한 타임 라인은 Heartbleed 공개 타임 라인 에서 확인할 수 있습니다 . 누가 언제 무엇을 알고 있었는지 알 수 있습니다 .
프로그래머이고 OpenSSL의 msg_cb
콜백을 통한 Heartbleed 공격 탐지와 같은 다양한 프로그래밍 기법에 관심이있는 경우 OpenSSL의 보안 권고 2014047 을 참조하십시오 .
Ubuntu는 USN-2165-1 을 발행 했으며 , 업데이트 된 패키지는 이제 아카이브에서 사용할 수 있습니다. 다음 두 명령을 실행하여 수정 사항을 가져 오십시오.
sudo apt-get update
sudo apt-get upgrade
새 릴리스 (1.0.1g)가 포함 된 데비안 패키지를이 목적으로 설정 한 PPA에 업로드했습니다. 이 세 명령은 시스템에 PPA를 추가하고 사용 가능한 패키지 목록을 업데이트하며 모든 것을 업그레이드합니다.
sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade
참고 : PPA는 또한 아카이브에서 패치 된 버전을 사용하는 대신 실제로 새 버전 (1.0.1g)을 실행하려는 경우를 대비하여 Ubuntu 12.04 및 13.10 용 패키지를 제공합니다.
이것은 LTS 버전이며 서버 버전은 여전히 지원되며 보안 업데이트를받습니다. 그러나 heartbleed 취약점은 버전이 1.0.1보다 낮기 때문에 표준 우분투 10.04 설치의 openssl 패키지에 영향을 미치지 않았습니다.
데스크탑 버전의 수명이 다하여 업그레이드 / 다시 설치해야합니다.
Ubuntu 13.04의 지원주기는 매우 짧아 예상치 못한 결과를 낳았습니다. 이미 수명이 다했으며 더 이상 보안 업데이트를받지 않습니다. 오랫동안 업그레이드 되었어야합니다. 여전히 누군가가 사용하고 있다면 지금 처음부터 업그레이드하거나이 쉬운 절차에 따라 비파괴 적으로 13.10으로 업그레이드 할 수 있습니다. http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / 업그레이드 후 시스템은 13.10부터 heartbleed 패치를받습니다.
다른 모든 오래된 우분투 버전의 경우 기본적으로 새로 설치해야 함을 의미합니다.
기본적으로 openssl version -a
빌드 날짜가 2014 년 4 월 7 일 이상인지 확인하고 자세한 내용은 여기를 참조 하십시오 .
OpenSSL에 따라 모든 서비스가 다시 시작되도록하는 가장 좋은 방법은 재부팅하는 것 입니다.
Mon Apr 7 20:31:55 UTC 2014
) 이후에 컴파일 된 것 입니다.
이들은 취약하다. RedHat의 정오표 RHSA-2014-0376에 따르면 패치 된 라이브러리가 있으며 영향을받는 사람은 가능한 한 빨리 업그레이드해야합니다.
작성 당시 CentOS에는 아직 고정 버전이 없었지만 Karanbir Singh의 CentOS-announce에 게시openssl-1.0.1e-16.el6_5.4.0.1
하면 악용 가능한 TLS가 있는 업데이트 된 버전의 openssl ( , 중요한 마지막 네 자리 참고)을 생성 했다고 말합니다. 명령을 사용할 수 없으며, 최종 릴리스시 고정 버전으로 덮어 쓰므로 안전하게 적용 할 수 있습니다.
임시로-고정 된 버전은 아직 모든 거울에 그것을 만든 것 같다,하지만의 주요 저장소에없는 http://mirror.centos.org/centos/6/updates/x86_64/Packages/ 에 대한 유사 (그리고 i686).
편집 : Iain이 말했듯이 이제 C6.5의 정식 패치 버전이있는 것으로 보이며 서둘러 거울 주위로 밀린 것 같습니다. 곧은 yum update
내 서버를 위해 그것을 얻었다; 그것은이다 openssl-1.0.1e-16.el6_5.7
.
이들은 취약하지 않습니다. Red Hat의이 권고 에 따르면 ,
이 문제는 Red Hat Enterprise Linux 5 및 Red Hat Enterprise Linux 6.4 및 이전 버전과 함께 제공되는 openssl 버전에는 영향을 미치지 않았습니다.
CentOS-announce에 Karanbir Singh의 게시물 은 버전 관리에 대해 똑같이 명확합니다.
오늘 당일, CentOS-6.5에서 제공되는 openssl의 심각한 문제에 대해 알게되었습니다.
데비안은 DSA-2896-1을 발행 했으며 패치 된 라이브러리는 여기에서 구할 수 있습니다 . 쉘 스크립트는 여기에 있습니다 .
1. 패치
Apt-get 저장소가 업데이트되었으므로 이제 패치 된 라이브러리를 통해 사용할 수 있습니다 apt-get update && apt-get upgrade
apt-get upgrade libssl1.0.0 openssl
패키지를 수동으로 업그레이드 할 수도 있습니다 (권장하지 않음).
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb
dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb
2. 서버 / 서비스 재시작
최상의 보호를 위해 전체 서버를 다시 시작하거나 서버가 오프라인 일 수없는 경우 필요한 서비스를 다시 시작하십시오.
3. OpenSSL 버전 확인
love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name Version Architecture Description
+++-=======================-================-================-====================================================
ii libssl1.0.0 1.0.1e-2+deb7u6 amd64 SSL shared libraries
wheezy/security
도움이 될 것입니다 apt-get update && apt-get upgrade
. 또는 패키지 만 업데이트하는 대화 형 패키지 관리자를 사용하여 openssl
, libssl1.0.0
, libssl1.0.0-dbg
과 libssl-dev
(시스템에 설치 참조).
OpenSSL 1.0.1e 11 Feb 2013
패치가 1.0.1e-2로 표시됩니다. 확인할 수 있으며 dpkg -l openssl
버전을 표시해야합니다1.0.1e-2+deb7u6
FreeBSD의 보안 팀은 : CVE-2014-0160 (일명 "Heartbleed와")와 관련하여 자문을 발표했다 FreeBSD의-SA-14 : 06.openssl를
FreeBSD 업데이트
바이너리 패치를 통한 FreeBSD 업데이트
i386 또는 amd64 플랫폼 에서 RELEASE 버전 의 FreeBSD를 실행하는 시스템 은 freebsd-update (8) 유틸리티를 통해 업데이트 할 수 있습니다.
# freebsd-update fetch
# freebsd-update install
소스에서 FreeBSD 업데이트
아래 위치에서 관련 패치를 다운로드하고 PGP 유틸리티를 사용하여 분리 된 PGP 서명을 확인하십시오.
# fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
# fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
# gpg --verify openssl-10.patch.asc
루트로 다음 명령을 실행하십시오.
# cd /usr/src
# patch < /path/to/patch
운영 체제 재 컴파일
FreeBSD 핸드북에 설명 된대로 buildworld 및 installworld 사용 .
openssl 포트를 최소 버전 1.0.1_10으로 업데이트하십시오.
라이브러리를 사용하여 모든 데몬을 재시작하거나 시스템을 재부팅하십시오
시스템이 손상된 것처럼 행동하고 모든 SSL 키 및 / 또는 인증서와 잠재적으로 유출 된 정보를 다시 발행하십시오 ( EEAA 보다 일반적인 답변 참조 ).
이 시스템은 취약하지 받는 Heartbleed와의 의 이전의 0.9.x 버전에 의존로, 기본적으로 문제가 있는 OpenSSL 라이브러리 를 제외 설치 하려면 openssl을 포트에서 (위층 참조).
이러한 시스템이 Heartbleed 문제에 취약하지 않은 경우 다른 로컬 취약성 으로 인해 시스템을 더 빨리 업그레이드하는 것이 좋습니다 ( FreeBSD-SA-14 : 06.openssl 및 "FreeBSD 10.0"섹션 위층 참조).
로컬 공격자가 서명 프로세스를 스누핑하고 서명 키를 복구 할 수 있습니다. [CVE-2014-0076]
참고 :
최초의 Heartbleed 권고에는 FreeBSD 8.4 및 9.1이 잠재적으로 취약한 것으로 나와 있습니다. 하트 비트 확장 (기본 FreeBSD openssl 라이브러리 버전 0.9.x) 이 없기 때문에 이것은 사실이 아닙니다 .
필자는 작업하는 여러 어플라이언스에서 사용중인 SSL 버전을 확인하는 것이 불가능하다는 것을 알았습니다. 기술적으로 완화되지는 않았지만 현재 취약한 호스트를 식별 할 수있는 것이 내 목록의 최상위에있었습니다.
FiloSottile의 테스트 모듈을 사용하여 임의의 호스트 및 포트를 검사하는 작은 VM을 구성했습니다 . 미리 살펴보면 코드가 소리처럼 보입니다.
완성 된 VM의 릴리스는 여기에 있습니다 . VMX 형식입니다.
경고의 말
이 스크립트와 VM은 시스템의 현재 상태 만 표시합니다. 과거 어느 시점에서 시스템이 취약한 상태에 있었으며 악용되었을 수 있습니다.
여기에 표시되는 것은 수정해야 할 우선 순위가 높지만 업데이트를 적용하고 모든 키를 변경하는 데 도움이 되지 는 않습니다 .
Amazon Linux (Amazon EC2에서 사용되는 Linux 배포판)
https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/
문제 개요 : OpenSSL이 TLS 하트 비트 확장 패킷을 처리하는 방식에서 바운드 검사가 누락되었습니다. 이 결함은 연결된 클라이언트 또는 서버에서 최대 64k의 메모리를 표시하는 데 사용될 수 있습니다.
영향을받는 버전 : openssl 1.0.1이 설치된 Amazon Linux AMI (Amazon Linux AMI 2013.03 이상) 및 2013.03 이상으로 업그레이드 된 Amazon Linux AMI OpenSSL은 기본적으로 Amazon Linux AMI에 설치됩니다.
영향을받는 패키지 : openssl
문제 수정 : yum update openssl을 실행하여 시스템을 업데이트하십시오. 새 패키지가 설치되면 openssl을 사용하는 모든 서비스를 수동으로 다시 시작하거나 인스턴스를 재부팅해야합니다. 새 패키지의 이름은 여전히 openssl-1.0.1e이지만 CVE-2014-0160에 대한 수정 사항이 포함되어 있습니다.
새로운 패키지 : i686 :
openssl-1.0.1e-37.66.amzn1.i686
openssl-static-1.0.1e-37.66.amzn1.i686
openssl-perl-1.0.1e-37.66.amzn1.i686
openssl-devel-1.0.1e-37.66.amzn1.i686
openssl-debuginfo-1.0.1e-37.66.amzn1.i686
x86_64 :
openssl-devel-1.0.1e-37.66.amzn1.x86_64
openssl-1.0.1e-37.66.amzn1.x86_64
openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64
openssl-perl-1.0.1e-37.66.amzn1.x86_64
openssl-static-1.0.1e-37.66.amzn1.x86_64