Heartbleed: cara memeriksa versi OpenSSL dengan andal dan mudah dibawa?


88

Saya mencari cara yang andal dan portabel untuk memeriksa versi OpenSSL di GNU / Linux dan sistem lainnya, sehingga pengguna dapat dengan mudah menemukan apakah mereka harus memutakhirkan SSL mereka karena bug Heartbleed.

Saya pikir itu akan mudah, tetapi saya dengan cepat menemukan masalah di Ubuntu 12.04 LTS dengan OpenSSL 1.0.1g terbaru:

openssl versi -a

Saya mengharapkan untuk melihat versi lengkap, tetapi saya malah mendapatkan ini:

OpenSSL 1.0.1 14 Mar 2012
dibangun di atas: Sel 4 Jun 07:26:06 UTC 2013
peron: [...]

Yang mengejutkan saya tidak menyenangkan, surat versi tidak muncul. Tidak f, tidak ada g di sana, hanya "1.0.1" dan hanya itu. Tanggal yang tercantum tidak membantu dalam menemukan versi (non-) yang rentan.

Perbedaan antara 1.0.1 (af) dan 1.0.1g sangat penting.

Pertanyaan:

  • Apa cara yang dapat diandalkan untuk memeriksa versi, lebih disukai lintas distro?
  • Mengapa huruf versi tidak muncul di tempat pertama? Saya tidak dapat menguji ini pada hal lain selain Ubuntu 12,04 LTS.

Yang lain melaporkan perilaku ini juga. Beberapa contoh:

Beberapa saran (khusus distro) bergulir di:

  • Ubuntu dan Debian: apt-cache policy openssldan apt-cache policy libssl1.0.0. Bandingkan nomor versi dengan paket di sini: http://www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl(terima kasih @znmeb di twitter) danyum info openssl-libs

Memeriksa apakah versi OpenSSL yang lebih lama masih ada:

Ternyata memperbarui paket OpenSSL di Ubuntu dan Debian tidak selalu cukup. Anda juga harus memperbarui paket libssl1.0.0, dan -kemudian memeriksa apakah openssl version -amenunjukkan built on: Mon Apr 7 20:33:29 UTC 2014.


2
setidaknya pastikan bahwa versi OpenSSL yang Anda miliki bukan g karena tanggal yang ditampilkan
Pato Sáinz

3
Ini bekerja pada CentOS[root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013
Jacob

1
@ PatoSáinz Saya telah memeriksa apt-cache policy openssldan merespons dengan: Installed: 1.0.1-4ubuntu5.12yang merupakan 1.0.1g baru saja dirilis oleh Ubuntu untuk 12,04 LTS. Saya login dan kembali. Apakah ada hal lain yang bisa saya lakukan untuk memverifikasi?
Martijn

1
Saya akan tunjukkan, untuk itu yang tidak tahu, kalau-kalau itu membantu ... Ubuntu 12.04 LTS dikirimkan dengan OpenSSL 1.0.1 (vanilla).
HopelessN00b

1
Jika tanggal pembuatan itu akurat, Anda tidak dapat memiliki kode "rilis versi" lebih baru dari 1.0.1e, karena 1.0.1f keluar pada 2014 per catatan rilis OpenSSL 1.0.1 . Masing-masing baris atau bagian mungkin telah di-backport ke versi Ubuntu Anda sebelum rilis resmi OpenSSL 1.0.1f, tentu saja. Dan tanggal pembuatan mungkin kurang begitu membantu sepenuhnya.
Kata sandi anti-lemah

Jawaban:


66

Berdasarkan tanggal yang ditampilkan oleh versi OpenSSL, tampaknya Anda sedang melihat versi lengkap ditampilkan di sana.

Open SSL 1.0.1 dirilis pada 14 Maret 2012 . 1.0.1a dirilis pada 19 April 2012.

Jadi, saya akan melanjutkan dan menegaskan itu openssl version -aadalah cara yang tepat, lintas-distro untuk menampilkan versi lengkap OpenSSL yang diinstal pada sistem. Tampaknya berfungsi untuk semua distro Linux yang saya miliki aksesnya, dan merupakan metode yang disarankan dalam dokumentasi OpenSSL help.ubuntu.com . Ubuntu LTS 12.04 dikirimkan dengan vanilla OpenSSL v1.0.1, yang merupakan versi yang terlihat seperti versi singkat, karena tidak memiliki surat yang mengikutinya.

Karena itu, tampaknya ada bug besar di Ubuntu (atau bagaimana mereka mengemas OpenSSL), yang openssl version -aterus mengembalikan versi 1.0.1 asli dari 14 Maret 2012, terlepas dari apakah OpenSSL telah ditingkatkan atau tidak ke suatu dari versi yang lebih baru. Dan, seperti kebanyakan hal saat hujan, hujan deras.

Ubuntu bukan satu-satunya distro besar dalam kebiasaan backporting pembaruan ke OpenSSL (atau paket lain), lebih baik daripada mengandalkan pembaruan hulu dan penomoran versi yang diakui semua orang. Dalam kasus OpenSSL, di mana nomor versi huruf hanya mewakili perbaikan bug dan pembaruan keamanan, ini tampaknya hampir tidak bisa dipahami, tetapi saya telah diberitahu bahwa ini mungkin karena plugin yang divalidasi FIPS yang disahkan oleh kapal-kapal besar distro Linux yang dikemas dengan OpenSSL. Karena persyaratan sekitar validasi ulang yang memicu karena perubahan apa pun, bahkan perubahan yang membuat lubang keamanan, itu terkunci versi.

Misalnya, pada Debian, versi tetap menampilkan nomor versi 1.0.1e-2+deb7u5alih-alih versi hulu 1.0.1g.

Akibatnya, saat ini, tidak ada cara yang andal dan portabel untuk memeriksa versi SSL di seluruh distribusi Linux , karena mereka semua menggunakan tambalan dan pembaruan yang di-backport sendiri dengan skema penomoran versi yang berbeda. Anda harus mencari nomor versi tetap untuk setiap distribusi Linux yang berbeda yang Anda jalankan, dan memeriksa versi OpenSSL yang terinstal terhadap penomoran versi khusus distribusi itu untuk menentukan apakah server Anda menjalankan versi yang rentan atau tidak.


3
Instalasi saya adalah Ubuntu 12,04 LTS sederhana tanpa apa pun yang saya kompilasi sendiri atau diunduh dari sumber lain selain dari repositori Ubuntu. Jika Ubuntu mendistribusikan OpenSSL dengan nomor versi singkat, maka openssl version -aitu bukan metode portabel (setidaknya tidak portabel untuk Ubuntu). Saya telah memeriksa apt-cache policy openssldan merespons dengan: Installed: 1.0.1-4ubuntu5.12yang merupakan 1.0.1g baru saja dirilis oleh Ubuntu untuk 12,04 LTS. Saya logout dan kembali sebelum memeriksa.
Martijn

19
HopelessN00b, tidak ada yang meragukan tentang kebijakan perbaikan backporting bukan versi bumping; ini adalah cara yang sangat baik untuk memastikan stabilitas platform, yang sangat diinginkan di lingkungan server. Seperti halnya keputusan apa pun, itu memiliki konsekuensi, yang perlu diketahui pengguna; tetapi hanya karena itu melanggar " Saya menjalankan foo xyz karena itu saya / saya tidak rentan terhadap eksploitasi terbaru " alasan, itu tidak membuatnya menjadi hal yang buruk.
MadHatter

10
Nomor versi @towo ada karena suatu alasan. Jika kita hanya akan membuang nomor versi hulu keluar jendela karena "enterprisey," atau apa pun, mengapa repot-repot dengan nomor versi sama sekali? Semoga juga mulai memberi nama semua barang kami dengan aliterasi. Kita bisa menyebut versi OpenSSL yang rentan Holy Heartbleed dan yang diperbaiki Cunning Coagulant .
HopelessN00b

7
@ HopelessN00b Saya pikir Anda terjebak pada perangkap "ini diperbaiki di versi XYZ", mereka tidak mengikuti nomor versi karena semua yang diimpor ke versi terbaru adalah perbaikan bug dan keamanan. Jika mereka menabrak nomor versi, Anda juga akan mengharapkan fungsionalitas tambahan .. "Saya punya OpenSSL v XYZ, mengapa saya tidak memiliki ECDHA ???? ..etc". Masuk akal ketika Anda mengerti bahwa itu hanya perbaikan bug.
NickW

13
@NickW @Jubal @MadHatter masalahnya dengan OpenSSL, adalah: After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features.Jadi, tidak ada yang diperoleh dengan meninggalkan skema versi upstream; backporting pembaruan pada dasarnya sama dengan menggunakan versi yang diperbarui, karena pembaruan hanya mencakup perbaikan keamanan dan bug. Apa yang dilakukannya adalah membingungkan hal-hal dan membuat kami tidak dapat memeriksa versi OpenSSL di seluruh distro Linux.
HopelessN00b

18

Jika Anda menginginkan sesuatu yang benar-benar lintas platform, periksa kerentanannya sendiri daripada mengandalkan nomor versi.

Anda mungkin memiliki kode yang melaporkan nomor versi yang dikenal rentan, tetapi kode sebenarnya tidak rentan . Dan sebaliknya - kode yang secara diam-diam rentan - bisa jadi lebih buruk!

Banyak vendor yang menggabungkan produk-produk sumber terbuka seperti OpenSSL dan OpenSSH secara selektif akan memperbaiki perbaikan yang mendesak ke versi kode yang lebih lama, untuk menjaga stabilitas dan prediktabilitas API. Ini terutama berlaku untuk "rilis jangka panjang" dan platform alat.

Tetapi vendor yang melakukan ini secara diam-diam (tanpa menambahkan sufiks string versi mereka sendiri) berisiko memicu positif palsu dalam pemindai kerentanan (dan membingungkan pengguna). Jadi untuk membuat ini transparan dan dapat diverifikasi, beberapa vendor menambahkan string mereka sendiri ke versi paket utama. Baik Debian (OpenSSL) dan FreeBSD (dalam OpenSSH, melalui VersionAddendumarahan sshd_config) terkadang melakukan ini.

Vendor yang tidak melakukan ini mungkin melakukannya untuk meminimalkan kemungkinan kerusakan karena banyak cara langsung dan tidak langsung bahwa program lain memeriksa nomor versi.

Jadi bisa terlihat seperti ini:

$ 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

... meskipun sudah ditambal :

$ 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

Dengan hal-hal seperti ini dalam permainan, Anda lebih baik jika Anda tidak mempercayai nomor versi.


Jelas bahwa memeriksa versi tidak semudah dan transparan seperti yang saya harapkan. Memeriksa kerentanan adalah lintas-platform, tetapi juga lebih sulit untuk dilakukan: Anda harus memiliki PoC yang andal atau uji praktis untuk layanan perangkat lunak rentan tertentu yang Anda jalankan. Dalam hal ini semuanya dimulai dengan PoC untuk Apache dan nginx. Bagaimana jika saya hanya menggunakan SMTP dengan SSL pada saat itu, dan saya ingin memeriksa apakah saya rentan? Akhirnya kami akan melakukan tes untuk sebagian besar layanan, tetapi mungkin perlu waktu.
Martijn

Martijn, itu poin yang adil. Ketika tes tidak tersedia, metode sekunder (seperti melacak checksum untuk binari yang terkena dampak pada sistem target Anda) kurang optimal, tetapi mungkin cukup baik untuk menyelesaikan pekerjaan ... dan kemudian beralih ke api berikutnya. :-)
Royce Williams

14

Sayangnya, saya tidak yakin ada adalah cara cross-platform untuk melakukan hal ini. Seperti yang saya bahas dalam posting blog , versi OpenSSL ditampilkan di Ubuntu 12.04 REMAINS 1.0.1 setelah memutakhirkan ke versi yang tetap.

Untuk Ubuntu 12.04 HANYA, Anda dapat mengetahui apakah Anda telah diperbarui jika semua hal di bawah ini benar:

  1. dpkg -s openssl | grep Version menunjukkan versi 1.0.1-4ubuntu5.12 atau yang lebih baru.
  2. dpkg -s libssl1.0.0 | grep Version menunjukkan versi 1.0.1-4ubuntu5.12 atau yang lebih baru.
  3. openssl version -a menunjukkan tanggal "dibangun pada" 7 April 2014 atau lebih baru.

Terima kasih kepada @danny untuk info tambahannya.


2
Ok, dalam hal ini saya harus menambahkan bahwa versi paket 1.0.1-4ubuntu5.12HANYA untuk Ubuntu 12,04 LTS. Jika Anda menggunakan Ubuntu 12.10, Anda harus melihat setidaknya versi 1.0.1c-3ubuntu2.7dan jika Anda menggunakan 13.10 maka itu harus setidaknya versi 1.0.1e-3ubuntu1.2, menurut sumber: ubuntu.com/usn/usn-2165-1
Martijn

1
Sayangnya ini tidak cukup. Anda juga harus memutakhirkan libssl1.0.0secara eksplisit di ubuntu. Jika Anda melihat tanggal dibangun sebelum 7 April 2014 meskipun versi openssl terlihat benar ( 1.0.1-4ubuntu5.12untuk Ubuntu 12.04) Anda mungkin masih rentan.
danny

@danny Anda baru saja menyelamatkan saya, jadi banyak pekerjaan. Saya mencoba mencari tahu mengapa tanggal pembuatan benar pada beberapa sistem 12,04 dan salah pada yang lain. Anda seorang penyelamat!
Schof

openssl version -amungkin tidak memerlukan tanggal pembuatan 7 April, karena perbaikan sedang di-backport ke rilis yang lebih lama.
Patrick James McDougle

4

Cobalah yang berikut ini. Ini akan mengekstrak semua string dari pustaka crypto yang ssh ditautkan. Ini menghasilkan lebih dari satu baris output, tetapi jika perlu dapat dikonversi menjadi 1 baris.

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

menghasilkan

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

mis. di Gentoo sebelum emerge

[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

perintah di atas menghasilkan

...
OpenSSL 1.0.1c 10 May 2012

setelah

...
OpenSSL 1.0.1f 6 Jan 2014

Aduh, masih belum g.


3
Saya pikir Anda sangat dekat untuk memberikan solusi yang baik, tetapi sayangnya ini tidak berfungsi untuk pustaka crypto di Ubuntu 12,04 LTS. Ini menampilkan semua string dengan versi [...] part of OpenSSL 1.0.1 14 Mar 2012, dengan cara yang sama seperti openssl version -ahalnya. Ini adalah trik yang mungkin berhasil dalam kasus lain!
Martijn

@ Martijn Yah itu disayangkan, tetapi tidak berfungsi di ubuntu 12.10. Aneh bahwa itu akan salah mengidentifikasi dirinya pada 12,04. Apakah ada banyak lib? Apakah mungkin ssh tidak menggunakan yang terbaru?
waTeim

Saya tidak dapat menemukan binari openssl atau pustaka crypto lainnya. Disarankan oleh orang lain bahwa perbedaannya adalah, pada 12,04 LTS, Ubuntu mendukung perubahan ke 1.0.1 tanpa meningkatkan versi. Sedangkan 12.10 bukan LTS dan karenanya Ubuntu menggunakan versi terbaru di sana alih-alih sebagai backport.
Martijn

2

Apakah ada di antara skrip ini yang menguji semua layanan, atau hanya menguji HTTPS ? AFAIK , PostgreSQL rentan, tapi itu hanya desas-desus sampai permukaan serangan liar muncul.

Ada skrip metasploit yang tersedia untuk digunakan.

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

Anda dapat mengetik ini (diuji dengan GnuWin32 OpenSSL biner versi 1.0.1.6, tanggal 2014-01-14), atau cukup gunakan skrip dalam komentar di bawah ini. Ini lebih akurat dan sederhana!

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

Setelah terhubung, tipe B dan Anda akan melihat host yang rentan dan Anda tidak akan terputus:

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

Anda akan mendapatkan respons detak jantung yang mirip dengan yang ini.

Pada host yang ditambal, Anda akan melihat respons yang mirip dengan di bawah ini dan Anda akan terputus:

Masukkan 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

Sumber:

Ada juga alat-alat ini:




0

Saya menemukan skrip ini di devcentral :

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

Ganti example.comdengan nama atau alamat IP dari server yang ingin Anda periksa.

Akan kembali "safe"jika server Anda baik-baik saja atau "server extension "heartbeat" (id=15)"jika tidak.

Ini tidak bergantung pada nomor versi, tetapi pada daftar ekstensi server yang menyebabkan masalah, sehingga harus kebal terhadap shenanigans versi perpustakaan.

Mesin Anda menjalankan openssl s_clientpada harus menjadi menggunakan OpenSSL 1.0.1 atau lambat agar ini bekerja.


4
Berguna, tetapi tidak memberi tahu Anda jika Anda memiliki versi dengan ekstensi dan perbaikannya .
mattdm

1
Ini memang cara yang baik untuk memeriksa kerentanan dan apa yang dilakukan beberapa skrip. Sebenarnya tidak memerlukan akses SSH.
Stefan Lasiewski

8
PERINGATAN PENTING SCARY BESAR - Mesin yang Anda jalankanopenssl s_clientHARUS menggunakan OpenSSL 1.0.1 atau yang lebih baru agar ini berfungsi. Jika Anda menjalankan perintah ini pada mesin dengan 0.9.8 atau 1.0.0 ITU AKAN SELALU LAPORAN "Aman", bahkan untuk server yang rentan .
voretaq7

Aneh. Saya menjalankan versi OpenSSL yang diduga dipengaruhi oleh bug ini, namun string itu tidak muncul di output ...
Michael

@StefanLasiewski Saya memperbarui jawaban saya dan menghapus bagian "perlu ssh"
egarcia
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.