Heartbleedチェッカの改善（不正アクセスしないような改造）
•Download as PPTX, PDF•
4 likes•1,532 views
All of Heart Bleed Checker were bleed data of using memory by Open SSL Libary in a apache process. This bleed is accessed unauthorized way, and violated 'Unauthorized access law'. This presentation think these BAD scripts, and 'Heart Bleed check site', and attempts more better method.
Recommended
More Related Content
Similar to Heartbleedチェッカの改善（不正アクセスしないような改造）
Similar to Heartbleedチェッカの改善（不正アクセスしないような改造） (7)
Heartbleedチェッカの改善（不正アクセスしないような改造）
- 2. 2014年4月OpenSSLにメモリリークの脆弱性が発見されまし た(CVE-2014-0160) •SSL通信で使用するメモリの断片が認証なしにリーク •過去２年間の間、“穴”が開いたまま •認証情報の断片、証明書のプライベートキーの断片が漏洩した恐れ •PoC(Proof of Concept)コードで誰もがメモリ断片が取得可能、ログが記録 されない・・・ 欧米で大問題になりました ※日本のIE騒ぎの比ではないくらい・・・
- 3. 慌ててPoCコードベースのチェッカがたくさんでてきました •PoCコード≒Exploitコード（攻撃コード）をベースにしているので、実際に「出 血」するかを確認 •「出血」させるメモリ情報は、本来サーバの管理者権限で認証しなければ、アク セスできないはずの情報です。 HeartBleed チェッカ server httpd SSL local malloc memory ･ID,passwords ・Private証明書 Admin Authentication 本来のアクセス 経路 サーバーの正規のアクセス権限が なければ不正アクセスで す ※不正アクセス禁止法違反（日本） ※米国、英国、豪でも断りなくサーバの セキュリティチェックするのは犯罪です 。
- 4. Heartbleedのチェックツール(5月前半時点） ※OpenSSLの脆弱性（CVE-2014-0160）関連の情報をまとめてみた (http://d.hatena.ne.jp/Kango/20140410/1397139257 )より引用 ≒ほとんどが攻撃コード！
- 5. 実際の以前のパケットコード– 古いssltest.pyの場合 # Classic bounadry check violation. hb = struct.pack(“>BHHBH”, # Format(1,2,2,1,2) bytes = TOTAL 9 bytes 24, # TLS package kind - 24 == Heartbeat 770, # TLS Version (1.1) (0x0301) 3, # Length 1, # Heartbeat type (0x01 == Request, 0x02 == Response) 65535 # Payload length, control how much memory we can snarf on the server side. (exploit here) ) HeartBeat パケットの定義
- 7. Heartbleedのチェックサイト ※OpenSSLの脆弱性（CVE-2014-0160）関連の情報をまとめてみた (http://d.hatena.ne.jp/Kango/20140410/1397139257 )より引用 •どういうチェック方法を行っているか表記がない。 →ほとんど「出血」させている。 •どういう利用者が利用して良いのかの表記が ない。 →サイトオーナーかオーナーから許可を取った人以外 が利用すると不正アクセス •運営者の氏素性がちょっとわからないサイトも ある。 •チェックした結果の情報をどういう風に利用す るかについて記載がないところもある。 →サイトに一定時間表示されるサイトもある
- 9. 一般人に積極的にこのツールや同様のことをするチェックサイトを 使ってサーバのチェックを推奨する記事もでてきました。 記者の目：一般ユーザのための HeartBleed処方箋(ITPro) (http://itpro.nikkeibp.co.jp/ article/Watcher/20140425/ 553263/?ST=security&P=3)
- 10. 他のチェック方法はなかったの？-パッチのコードを覗いてみよう！ unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ + /* Read type and payload length first */ + if (1 + 2 + 16 > s->s3->rrec.length) + return 0; /* silently discard */ + hbtype = *p++; + n2s(p, payload); + if (1 + 2 + payload + 16 > s->s3->rrec.length) + return 0; /* silently discard per RFC 6520 sec. 4 */ Content Type Length Padding Bytes Real Packet Size Check の肝 PoCコードを見て「 あれっ？」って思っ て追加 → RFCが定義する最 低必要なパケットサ イズある？ payload 余計な(?) Check
- 11. つまり・・・ •「Checkの肝」の部分と「余計な(?)Check」の部分はセッ トでパッチされている •「Checkの肝」ではなくて、「余計な(?)Check」の部分に ひっかかるパケットで挙動を判断すればいいのでは？ じゃあ、直してみよう！
- 12. 古いssltest.pyの修正その１ # Classic bounadry check violation. hb = struct.pack(“>BHHBH”, # Format(1,2,2,1,2) bytes = TOTAL 9 bytes 24, # TLS package kind - 24 == Heartbeat 770, # TLS Version (1.1) (0x0301) 3, # Length 1, # Heartbeat type (0x01 == Request, 0x02 == Response) 0 # ( <- 65535 ) Payload length, control how much memory we can snarf on the server side. (exploit here)
- 13. ssltest.pyの修正その2 def hit_hb(s): while True: typ, ver, pay = recvmsg(s) if typ is None: print 'No heartbeat response received, server likely not vulnerable' return False if typ == 24: print 'Received heartbeat response:' - print 'WARNING: server returned more data than it should - server is vulnerable!' + print ' ... WARNING: Server processed malformed heartbeat, server is vulnerable!' return True if typ == 21: print 'Received alert:' - hexdump(pay) - print 'Server returned error, likely not vulnerable' + print ' ... Server is NOT vulnerable!' return False
- 14. でも、＠JｓPenguinさんのコード ssltest.pyは劇的な進化を遂げてい た 暗号化通信の外のHeaｒｔBeetパケットから Encrypted HeartBeatパケットへ変更 「出血させる」パケットから、「出血させない」パ ケットへ(方針はRFCの形式を満たさないパケットの 処理をチェックする方法へ） TLS1.0だけチェックしていたのをSSL3.0/ TLS1.0/1.1/1.2がチェックできるように変更 HTTPのみでなく、SMTPS/SFTP/IPOPS /IMAPSも チェックできるように変更
- 15. 進化コードを眺めてみま しょう！
- 17. 「出血」させているスクリプト/サ イトに関する問題提起 一般ユーザがWebサーバの「出血」状態をスクリプ トでチェックすると「不正アクセス禁止法違反」 か？ 一般ユーザがWebサーバの「出血」状態をチェック サイトでチェックすると「不正アクセス禁止法違 反」か？ ２．が違反だとして、一般ユーザは正犯か？サイト 設置者の立場は？（共同正犯？幇助犯？） チェックサイトがデファクトとして許される場合、 SQLインジェクションやパスワードリストをチェッ クするサイトを立ち上げて、これでWebサーバの脆 弱性をチェックするのは合法？