Heartbleed : OpenSSL 버전을 안정적이고 이식 가능하게 확인하는 방법?

GNU / Linux 및 기타 시스템에서 OpenSSL 버전을 확인하는 안정적이고 이식 가능한 방법을 찾고 있었기 때문에 사용자는 Heartbleed 버그로 인해 SSL을 업그레이드해야하는지 쉽게 찾을 수 있습니다.

나는 그것이 쉬울 것이라고 생각했지만 최신 OpenSSL 1.0.1g로 우분투 12.04 LTS에서 문제가 발생했습니다.

openssl 버전 -a

정식 버전을 기대했지만 대신 다음과 같은 결과를 얻었습니다.

OpenSSL 1.0.1 2012 년 3 월 14 일
내장 : 화요일 6 월 4 일 07:26:06 UTC 2013
플랫폼 : [...]

놀랍게도 버전 서한은 보이지 않습니다. 아니 f, 아니 g, 그냥 "1.0.1"과 그게 다야. 나열된 날짜는 취약하지 않은 버전을 발견하는 데 도움이되지 않습니다.

1.0.1 (af)과 1.0.1g의 차이가 중요합니다.

질문 :

• 버전을 확인하는 가장 확실한 방법은 무엇입니까?
• 왜 버전 문자가 처음에 표시되지 않습니까? 우분투 12.04 LTS 이외의 다른 곳에서는 이것을 테스트 할 수 없었습니다.

다른 사람들도이 행동을보고하고 있습니다. 몇 가지 예 :

• https://twitter.com/orblivion/status/453323034955223040
• https://twitter.com/axiomsofchoice/status/453309436816535554

다음과 같은 몇 가지 (디스트로 관련) 제안 사항이 적용됩니다.

• 우분투와 데비안 : apt-cache policy openssl그리고 apt-cache policy libssl1.0.0. 여기에서 패키지와 버전 번호를 비교하십시오 : http://www.ubuntu.com/usn/usn-2165-1/
• Fedora 20 : yum info openssl(트위터에서 @znmeb 덕분에)yum info openssl-libs

이전 버전의 OpenSSL이 여전히 상주하는지 확인 :

• 완전히 신뢰할 수는 없지만 시도해 볼 수 있습니다 lsof -n | grep ssl | grep DEL. Heartbleed : OpenSSL 버전을 안정적이고 이식 가능하게 확인하는 방법을 참조하십시오 . 왜 이것이 당신에게 효과가 없을 수 있는지에 대해.

우분투와 데비안에서 OpenSSL 패키지를 업데이트하는 것만으로는 충분하지 않습니다. 또한 libssl1.0.0 패키지를 업데이트하고 -then-check if가 openssl version -a표시해야 built on: Mon Apr 7 20:33:29 UTC 2014합니다.

OpenSSL을 버전에 표시되는 날짜를 기준으로, 당신이 보인다 되는 이 표시되는 전체 버전을보고.

Open SSL 1.0.1은 2012 년 3 월 14 일에 릴리스되었습니다 . 1.0.1a는 2012 년 4 월 19 일에 릴리스되었습니다.

계속 openssl version -a해서 시스템에 설치된 OpenSSL의 정식 버전을 표시하는 적절한 교차 비교 방법 이라고 주장하겠습니다 . 그것은 내가 액세스 할 수있는 모든 Linux 배포판에서 작동하는 것으로 보이며 help.ubuntu.com OpenSSL 설명서에서도 제안 된 방법 입니다. Ubuntu LTS 12.04는 바닐라 OpenSSL v1.0.1과 함께 제공되는데,이 버전은 뒤에 문자가 없기 때문에 약식 버전처럼 보입니다.

우분투 에는 OpenSSL의 업그레이드 여부에 관계없이 2012 년 3 월 14 일부터 원래 1.0.1 버전 을 계속 반환 하는 주요 버그 가있는 것으로 보입니다 (또는 OpenSSL 패키지 방식). openssl version -a최신 버전의 그리고 비가 올 때 대부분의 것들과 마찬가지로 쏟아집니다.

Ubuntu는 OpenSSL (또는 다른 패키지)로 업데이트를 백 포트하는 습관에서 유일하게 주요 배포판이 아니며, 모든 사람이 인식하는 업스트림 업데이트 및 버전 번호에 의존하는 것보다 속도가 빠릅니다. 문자 버전 번호가 버그 수정 및 보안 업데이트 만 나타내는 OpenSSL의 경우, 이것은 거의 이해할 수없는 것처럼 보이지만 OpenSSL과 함께 패키지 된 FIPS 검증 플러그인 주요 Linux 배포판 때문일 수 있습니다 . 변경으로 인해 트리거되는 유효성 다시 확인에 대한 요구 사항, 보안 허점을 막는 변경 사항까지도 버전이 고정되어 있습니다.

예를 들어, 데비안에서 고정 버전 1.0.1e-2+deb7u5은 업스트림 버전 대신 버전 번호를 표시합니다 1.0.1g.

결과적으로 현재 Linux 배포판 에서 SSL 버전을 확인하는 신뢰할 수 있고 이식 가능한 방법은 없습니다. 모두 버전 번호 체계가 다른 자체 백 포트 패치 및 업데이트를 사용하기 때문입니다. 실행중인 각 Linux 배포판에 대해 고정 버전 번호를 찾아보고 해당 배포판의 특정 버전 번호와 비교하여 설치된 OpenSSL 버전을 확인하여 서버가 취약한 버전을 실행 중인지 확인해야합니다.

진정한 크로스 플랫폼을 원하는 경우 버전 번호에 의존하지 않고 취약점 자체를 확인하십시오.

취약한 것으로 알려진 버전 번호를보고하는 코드가있을 수 있지만 실제 코드는 취약하지 않습니다 . 그리고 그 반대 (조용히 취약한 코드)는 훨씬 더 나빠질 수 있습니다!

OpenSSL 및 OpenSSH와 같은 오픈 소스 제품을 번들로 제공하는 많은 공급 업체는 API 안정성과 예측 가능성을 유지하기 위해 이전 버전의 코드에 긴급 수정을 선택적으로 개조 할 것입니다. 이는 "장기 릴리스"및 어플라이언스 플랫폼에 특히 해당됩니다.

그러나 (자신의 버전 문자열 접미사를 추가하지 않고)이 작업을 자동으로 수행하는 공급 업체는 취약성 스캐너 (및 혼란스러운 사용자)에서 오 탐지를 유발할 위험이 있습니다. 따라서 투명하고 검증 할 수 있도록 일부 공급 업체는 고유 한 문자열을 주요 패키지 버전에 추가합니다. 데비안 (OpenSSL) 및 FreeBSD (OpenSSH에서는 VersionAddendumsshd_config 지시문을 통해 )가 때때로이 작업을 수행합니다.

이 작업을 수행하지 않는 공급 업체는 다른 프로그램에서 버전 번호를 확인하는 많은 직접 및 간접 방법으로 인해 파손 가능성을 최소화하기 위해 그렇게하고있을 것입니다.

따라서 다음과 같이 보일 수 있습니다.

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

$ openssl version
OpenSSL 1.0.1 14 Mar 2012

... 비록 그것이 패치 된 것 :

$ dpkg -l openssl | grep openssl
ii  openssl  1.0.1-4ubuntu5.12  [truncated]

$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr  7 12:37 /usr/bin/openssl

$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748  /usr/bin/openssl

이와 같은 기능을 사용 하면 버전 번호를 신뢰하지 않으면 더 좋습니다 .

불행히도, 이것을 하는 크로스 플랫폼 방법 이 있는지 확실하지 않습니다 . 블로그 게시에서 토론 할 때 고정 버전으로 업그레이드 한 후 Ubuntu 12.04 REMAINS 1.0.1에 OpenSSL 버전이 표시되었습니다.

Ubuntu 12.04의 경우에만 아래 사항이 모두 해당되는지 업데이트했는지 알 수 있습니다.

1. dpkg -s openssl | grep Version 버전 1.0.1-4ubuntu5.12 이상을 표시합니다.
2. dpkg -s libssl1.0.0 | grep Version 버전 1.0.1-4ubuntu5.12 이상을 표시합니다.
3. openssl version -a 2014 년 4 월 7 일 이후의 "구축 날짜"를 표시합니다.

추가 정보는 @danny에게 감사합니다.

다음을 시도해보십시오. ssh가 연결된 암호화 라이브러리 에서 모든 문자열을 추출합니다 . 두 줄 이상의 출력을 생성하지만 필요한 경우 한 줄로 변환 할 수 있습니다.

ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings  | grep OpenSSL

생산

OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014 
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
... 
etc

예 : 젠투에서 등장하기 전에

[ebuild     U  ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" 4,404 kB

위의 명령은

...
OpenSSL 1.0.1c 10 May 2012

후

...
OpenSSL 1.0.1f 6 Jan 2014

흠, 여전히 g.

이 스크립트 중 하나가 모든 서비스를 테스트합니까, 아니면 HTTPS 만 테스트 합니까? AFAIK , PostgreSQL 은 취약하지만 악의적 인 공격이 일어날 때까지는 소문 일뿐입니다.

가 메타 스플로 잇 사용할 수있는 스크립트.

https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a

이것을 입력 하거나 ( GnuWin32 OpenSSL 바이너리 버전 1.0.1.6, 2014-01-14 날짜로 테스트 됨 ) 아래 주석에서 스크립트를 사용할 수 있습니다. 더 정확하고 간단합니다!

s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state

B 유형을 연결하면 취약한 호스트에 표시되며 연결이 끊어지지 않습니다.

B

HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49   ....=.o 5 (0x5))
0000 - 18 03 03 00 3d                                    ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34   .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0   n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f   .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f            .#.w....w.+..
read R BLOCK

이와 비슷한 하트 비트 응답이 나타납니다.

패치 된 호스트에서 아래와 비슷한 응답이 표시되고 연결이 끊어집니다.

B를 입력

HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c   ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56   .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95   .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51   .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6   .~.V..7.@...C...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87   !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47                                    ....G

출처:

• 블로그 게시물 OpenSSL heartbleeds를 테스트하는 방법

이 도구들도 있습니다 :

• https://github.com/titanous/heartbleeder

• http://filippo.io/Heartbleed/

• https://github.com/musalbas/heartbleed-masstest

우분투의 경우 다음을 사용할 수 있습니다.

aptitude show libssl1.0.0 | grep Version

http://www.ubuntu.com/usn/usn-2165-1/ 과 비교 하십시오 . 재부팅 후 (!!!) 확인할 수 있습니다 http://possible.lv/tools/hb.

최신 OpenSSL OpenSSL 1.0.1j로 업그레이드하는 것이 좋습니다.

http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html

이 스크립트는 devcentral에서 발견 되었습니다 .

openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

교체 example.com검사 할 서버의 이름 또는 IP 주소.

"safe"서버가 양호하거나 "server extension "heartbeat" (id=15)"그렇지 않으면 반환 됩니다 .

이것은 버전 번호에 의존하지 않지만 문제를 일으키는 서버 확장명을 나열하므로 라이브러리 버전 shenanigans에 영향을 미치지 않아야합니다.

이것이 작동하려면 실행중인 시스템이 OpenSSL 1.0.1 이상 openssl s_client을 사용해야합니다 .