1. Debian OpenSSLvulnerability ARAKI Yasuhiro

2. Summary 21 May 2008 2

4. Why caused? Codes for generating random seed (md_rand.c) in OpenSSL was commented out by DD at May.2 2006. Because purify complains these line. As results, random numbers are generated from PID (≦ 65,535)! http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c

5. Action! Update OpenSSL (Debian-based system). Find weak keys Debian OpenSSL Weak Key Detector (dowkd) http://security.debian.org/project/extra/dowkd/dowkd.pl.gz Stop to use and remove weak keys. Make new keys (and re-certificate) 日本ベリサイン、Linux OSの脆弱性による影響を受けたお客様に、電子証明書を再発行

6. OpenSSH OpenSSH is serious! $ ssh-vulnkey -a COMPROMISED: 2048 46:73:25:26:26:96:0e:e0:c9:20:15:2f:b5:ef:e1:bc ishida@mnsdebian COMPROMISED: 2048 68:f5:6c:e0:f3:e8:73:39:1f:b7:fd:09:e9:64:dd:27 ishida@mnsdebian COMPROMISED: 1024 db:bf:40:1a:71:e7:89:d6:a3:f8:b9:72:a9:6c:74:d2 svn@mnsdebian COMPROMISED: 2048 f9:cf:61:ad:21:4c:bd:c2:9a:4a:da:cf:53:bc:a4:07 /user/morito/.ssh/id_rsa.pub COMPROMISED: 1024 52:b0:1d:3a:84:9c:1d:d3:ea:fc:f9:3a:ff:d3:3a:5d jun@jubuntu COMPROMISED: 1024 d6:fa:67:0f:df:d Principal of user self-responsibility NO CA. NO Key revoke system. Weak key infected through ssh user key If vulnerable keys are listed in the ~.ssh/authorized_keys in ANY SSHD RUNNING SERVERS, these servers are possibly takeover.

7. Reference http://metasploit.com/users/hdm/tools/debian-openssl/ http://www.debian.or.jp/blog/openssl_problem_qanda.html http://www.debian.org/security/2008/dsa-1576.en.html If you use Debian System : Please security update. If your server is used by Debian user, it might be threaten by OpenSSH user keys. Please check with http://security.debian.org/project/extra/dowkd/dowkd.pl.gz 21 May 2008 7

8. Questions? 8

9. Thank you!

10. Backup for SSH dummies

11. 11 サーバ公開鍵について ホスト認証（利用者から見たサーバの認証）の注意点 サーバ公開鍵（サーバのホスト公開鍵）は，ＳＳＨサーバが最初に１回だけ生成する．（ユーザは生成しない．） サーバ公開鍵の送付時にMan-in-the-middle攻撃が可能！ 最初に送付されるサーバ公開鍵は，ユーザの目で確認して，yes/noを選ばなければならない． 確認方法…fingerprintの照合 自己責任で「yes」を選ぶこともある サーバ公開鍵を，何らかのメディアで転送してもよい． サーバ公開鍵は ~/.ssh/known_hostsに保存される． それ以降の同じサーバとの接続では，自動的に確認される． サーバが鍵を作り直したら，クライアント側は古い公開鍵情報を削除しなければならない．

12. 12 ユーザ認証の方法 ユーザ認証（サーバから見た利用者の認証）の注意点 パスワード認証 ログインごとにパスワードを入力 従来のリモートログイン（telnet, ftpなど）を安全に行える 字数が少なく安全性にやや不安 公開鍵認証 ログインごとに，ログイン用パスワードとは異なるパスフレーズ（passphrase）を入力 エージェント（ssh-agentコマンド）の利用により，パスフレーズ入力の省力化が可能 あらかじめローカルホストで鍵ペアを生成し， ~/.ssh/authorized_keysに公開鍵を登録しておく． どの認証方法を許可するかは，/etc/sshd/sshd_configに記載する（編集にはroot権限が必要）．