Назад | Перейти на главную страницу

Heartbleed: как надежно и портативно проверить версию OpenSSL?

Я искал надежный и переносимый способ проверить версию OpenSSL в GNU / Linux и других системах, чтобы пользователи могли легко узнать, следует ли им обновить свой SSL из-за ошибки Heartbleed.

Я думал, что это будет легко, но быстро столкнулся с проблемой на Ubuntu 12.04 LTS с последней версией OpenSSL 1.0.1g:

openssl version -a

Я ожидал увидеть полную версию, но вместо этого получил следующее:

OpenSSL 1.0.1 14 Mar 2012
built on: Tue Jun  4 07:26:06 UTC 2013
platform: [...]

К моему неприятному удивлению, буквенное обозначение версии не отображается. Ни ф, ни г, просто "1.0.1" и все. Указанные даты также не помогают обнаружить (не) уязвимую версию.

Разница между 1.0.1 (a-f) и 1.0.1g имеет решающее значение.

Вопросы:

Другие также сообщают об этом поведении. Несколько примеров:

Некоторые (специфичные для дистрибутива) предложения:

Проверка резидентности более старой версии OpenSSL:

Оказывается, обновления пакета OpenSSL в Ubuntu и Debian не всегда достаточно. Вы также должны обновить пакет libssl1.0.0 и, затем, проверить, если openssl version -a указывает built on: Mon Apr 7 20:33:29 UTC 2014.

Судя по дате, указанной в вашей версии OpenSSL, вы являются увидеть полную версию, отображаемую там.

Open SSL 1.0.1 был выпущен 14 марта 2012 г.. 1.0.1a была выпущена 19 апреля 2012 года.

Итак, я собираюсь заявить, что openssl version -a - это правильный кросс-дистрибутивный способ отображения полной версии OpenSSL, установленной в системе. Кажется, он работает для всех дистрибутивов Linux, к которым у меня есть доступ, и - это метод, который также предлагается в документации OpenSSL help.ubuntu.com. Ubuntu LTS 12.04 поставляется с ванильным OpenSSL v1.0.1, который является версией, которая выглядит как сокращенная версия из-за отсутствия буквы после нее.

Сказав это, похоже, что существует крупный ошибка в Ubuntu (или как они упаковывают OpenSSL), в этом openssl version -a продолжает возвращать исходную версию 1.0.1 с 14 марта 2012 года, независимо от того, был ли OpenSSL обновлен до любой из более новых версий. И, как и в большинстве случаев, когда идет дождь, он льется.

Ubuntu - не единственный крупный дистрибутив, имеющий обыкновение переносить обновления в OpenSSL (или другие пакеты), скорее, чем полагаться на обновления восходящего потока и нумерацию версий, которые все узнают. В случае OpenSSL, где буквенные номера версий представляют только исправления ошибок и обновления безопасности, это кажется почти непонятным, но меня проинформировали, что это может быть из-за Проверено FIPS основные дистрибутивы Linux поставляются в комплекте с OpenSSL. Из-за требований к повторной валидации, которые запускаются из-за любого изменения, даже изменений, которые закрывают дыры в безопасности, он заблокирован по версии.

Например, в Debian фиксированная версия отображает номер версии 1.0.1e-2+deb7u5 вместо исходной версии 1.0.1g.

В результате в это время нет надежного портативного способа проверки версий SSL в дистрибутивах Linux, потому что все они используют свои собственные исправления и обновления с разными схемами нумерации версий. Вам нужно будет найти фиксированный номер версии для каждого используемого вами дистрибутива Linux и сравнить установленную версию OpenSSL с конкретной нумерацией версий этого дистрибутива, чтобы определить, работает ли на ваших серверах уязвимая версия или нет.

Если вы хотите что-то действительно кроссплатформенное, проверьте наличие самой уязвимости, а не полагайтесь на номера версий.

У вас может быть код, который сообщает номер версии, которая заведомо уязвима, но фактический код не уязвим. И наоборот - тихо уязвимый код - может быть еще хуже!

Многие поставщики, которые объединяют продукты с открытым исходным кодом, такие как OpenSSL и OpenSSH, выборочно модернизируют срочные исправления для более старой версии кода, чтобы поддерживать стабильность и предсказуемость API. Это особенно верно для платформ с «долгосрочным выпуском» и устройств.

Но поставщики, которые делают это незаметно (без добавления суффикса к строке собственной версии), рискуют вызвать ложные срабатывания сканеров уязвимостей (и ввести пользователей в заблуждение). Поэтому, чтобы сделать это прозрачным и проверяемым, некоторые поставщики добавляют свои собственные строки к основной версии пакета. И Debian (OpenSSL), и FreeBSD (в OpenSSH, через VersionAddendum sshd_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

С такими вещами в игре вам будет лучше, если вы не доверяйте номеру версии.

К сожалению, я не уверен в этом является кроссплатформенный способ сделать это. Как я обсуждаю в блоге, версия OpenSSL, отображаемая в Ubuntu 12.04, ОСТАЕТСЯ 1.0.1 после обновления до фиксированной версии.

ТОЛЬКО для 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 показывает дату постройки 7 апреля 2014 г. или позже.

Спасибо @danny за дополнительную информацию.

Попробуйте следующее. Он извлечет все строки из крипто библиотека, с которой связан ssh. Он производит более одной строки вывода, но при необходимости может быть преобразован в 1 строку.

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

например на Gentoo до появления

[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

Ой, все еще нет г.

Любой из этих скриптов тестирует все службы или тестирует только HTTPS? Насколько мне известно, PostgreSQL уязвима, но это только слухи, пока не появится атака в дикой природе.

Eсть метасплоит скрипт доступен для использования.

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

Вы можете ввести это (проверено с GnuWin32 Двоичная версия OpenSSL 1.0.1.6 от 14 января 2014 г.), или просто используйте скрипт в комментарии под этим. Так точнее и проще!

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

Источник:

Также есть эти инструменты:

Для Ubuntu вы можете использовать:

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)" если не.

Это зависит не от номера версии, а от перечисления расширения сервера, которое вызывает проблему, поэтому оно должно быть невосприимчивым к махинациям с версией библиотеки.

Машина, на которой вы работаете openssl s_client на должен использовать OpenSSL 1.0.1 или новее, чтобы это работало.