生存報告

主に情報セキュリティ関連のエントリをたまに書いて、存命であることを報告するページ。

IPv6に対する検証コマンドのメモ

IPv6のサーバに対して検証をする機会があって、コマンドとかIPv4とは勝手が違う部分があって苦労している。

 

あまりまとまっているページが見当たらなかったので、調べた内容を把握する範囲でメモしておこう。

基本的には、クライアントはLinux環境を想定している。

 

コマンドなど

 

ping

ping6コマンドを使う。

 ping6 -c 3 2001::abcd

リンクローカルアドレスはインタフェース番号を末尾に付ける。

ping6 -c 3 fe80::abcd%eth0

 

WindowsではpingコマンドでOK。

 

telnet

-6オプションを付ける。

 telnet -6 2001::abcd 80

 

Windowsではオプション不要。

 

ssh

-6オプションを付ける。

ssh -6 2001::abcd

 

ftp

-6オプションを付ける。

ftp -6 2001::abcd

 

ssl

接続にはncatを使う。

調べた限りOpenSSLではv6に接続できなかった。

ncat -6 --ssl -v 2001::abcd 443

 

OpenSSLが使えなかったので、Cipher Suiteの確認はsslscanかnmapを使う。

sslscanの場合：

sslscan --ipv6 [2001::abcd]:443

nmapの場合： 

nmap -6 --script ssl-enum-ciphers -p 443 2001::abcd

 

nmap

-6オプションを付ける。

nmap -6 2001::abcd

 

Nessus

Linux環境からスキャンする。

Windowsだとスキャンできない。（5.2のhelpには「IPv6 is now supported on most Windows installations」とあるが、期待した結果が得られなかった）

 

OpenVAS

Linux環境からスキャンする。

 

 

ひとまず以上。

追加があれば追記する。

 

Burp suiteのリクエスト/レスポンス文字化け対策(試作)

Burp suiteのリクエスト/レスポンスからコピペするとマルチバイト文字が文字化けしてしまう問題について、Burp Extenderで試作してみた。

 

ニッチなところに需要があるかもしれないので、まずは、ひっそりと置いておきます。

なお、お約束として、動作を保証するものではありません。

 

 

概要

  • Burp Extenderで実現(コピーのためのコンテキストメニューを追加)
  • Burp proxyで現在表示しているリクエスト/レスポンスを、クリップボードにコピー
  • 現時点では、リクエスト/レスポンス全体コピーと、ヘッダのみコピーの機能を搭載

 

要件

  • burp suite 1.5.01以上(新しいBurp Extenderが必要)
  • JRE 1.7以上

あとは特にないと思います。

動作確認は、Windows 8.1、JDK 1.8.0_05、Burp suite 1.6(Free版)でやっています。

 

使い方

Burp proxyのコンテキストメニューにメニューが追加されているので、それを選べばOK。

 

f:id:tosebro:20140703060000p:plain

 

今後の課題

  • 他のBurpツールからのコピー(現在Burp proxy以外の動作は未定義)
  • 「選択範囲のみコピー」で、マルチバイト文字の途中まで選択状態でコピーすると化ける（これは仕方ないかも）
  • その他

 

ダウンロード

https://github.com/tosebro/CopyForEvidence

 

（2014/07/02 更新）

・UTF-8以外で化けるのを修正

 

（2014/07/03 更新 ver.alpha 25）

・Proxyのhistoryからのコピーに対応。

・選択範囲のコピーに対応。ようやく実用的になってきた。

 

（2015/03/29 更新）

・GitHubに公開しました。

 

まとめ

Burp suiteの文字化け対策を試作してみた。

新しいBurp Extenderはかなり強力になっているようなので、他にもいろいろ拡張できそう。折を見て更新していきたい。

 

そもそもの話

文字化けの原因が分からず。swingからクリップボードへの文字列コピーが怪しいと思ってるが、、、

Burp suite文字化けの原因とか有効な対策があったら教えて下さいm(_ _)m

 

 

 

リバースHeartbleed(Reverse Heartbleed)を検証してみた。

セキュリティ

セキュリティ界隈でOpenSSLのHeartbleed(CVE-2014-0160)が話題になっている。

サーバからの情報漏洩がクローズアップされており、対策が進んでいるようだけど、一方でクライアントを攻撃できる「リバースHeartbleed」脆弱性がある。

 

Android 4.1.1のリバースHeartbleed脆弱性

Google Online Security Blog: Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)

 

クライアントから情報が漏れるので、かなり危険なんじゃないかと思うけど、あまり注意喚起もされていないようなので知らない人もいるのでは？と思って、その検証と、対策などをまとめてみた。

該当する端末やアプリを使っている人はぜひ参考にして自衛してほしい。

 

Heartbleedとは

改めて説明するまでもないと思うけど、OpenSSLの脆弱性である。

OpenSSLはHeartbeat機能に実装不備があり、これを悪用することで最大64KBのメモリ上のデータを不正に取得できる。(しかも何回でも取得できる)

秘密鍵や、ユーザの入力したIDやパスワードなどの漏洩のおそれがある。

 

リバースHeartbleed(Reverse Heartbleed)とは

通常は、クラッカー(クライアント側)が世の中のサーバを標的として攻撃するが、リバースHeartbleedでは「リバース」の名の通り、サーバがクライアントを攻撃するHeartbleedである。*1

 

影響を受けるクライアント 

冒頭の記事によるとAndroid 4.1.1と一部の4.2.2が影響を受けるとのこと。(厳密にはAndroidに組み込まれたOpenSSLが影響を受ける。4.2.2は詳細不明)

 

Androidのシェア的には4.1.xは最も多い35.3%みたい(4.1.1は不明)。ただWikipediaによると、日本ではAndroid 4.1.1の製品の種類は少ない。日本では一部の人が使っているだけなので話題になっていないのかな？

 

他に影響を受けるソフトウェアについてはセキュインコさんのまとめが詳しい。

 

検証

実際にリバースHeartbleed攻撃ができるか、以下の環境で検証してみた。

 

Heartbleed Detectorで端末のHeartbleed状況を確認する。

f:id:tosebro:20140427010150p:plain

左：端末A：Android 4.1.1(HTC J butterfly。リバースHeartbleed影響有り)

右：端末B：Android 4.0.3(HTC EVO 3D。影響無し)

 

手順と結果

1. 攻撃用サーバの準備

攻撃用サーバからスクリプトを実行する。

f:id:tosebro:20140427005353p:plain

サーバのURLは、例えばhttps://192.168.1.1:4433/のようになる。

 

2. 端末Aで攻撃用サーバにアクセス

端末AのAndroid標準ブラウザから攻撃用サーバにアクセスする。

サーバのコンソール上では以下のように端末のメモリ内の情報が表示された。（バイナリ部分はマスク）

 f:id:tosebro:20140427005519p:plain

 

取得したメモリ内容によっては、暗号化鍵や個人の情報が漏洩するおそれがある。

今回は、過去アクセスしたURL、サイトへのログインID、Googleアカウントなどが取得できた。

例：過去アクセスしたURL

f:id:tosebro:20140427010952p:plain

 

また、OSが影響受けても、アプリが影響を受けない場合*2、（そのアプリの通信からは）メモリ内容は漏洩しない。

例：Android 4.1.1(影響有り)でGoogle chrome(影響無し)を使ってアクセスした場合

f:id:tosebro:20140427010149p:plain

 
3. 端末Bで攻撃用サーバにアクセス

端末Bで同様にアクセスする。脆弱性がないので漏洩しない。

f:id:tosebro:20140427010148p:plain

 

以上の結果から、脆弱な端末のユーザを、攻撃用サーバのURLにアクセスさせることができれば、端末のメモリ内容を盗み取ることができると考えられる。

 

対策

まずは影響を受けるかチェックする。

Androidの場合はHeartbleed DetectorやBluebox Heartbleed Scannerで、OSとアプリをチェックする。

 

不運にも該当するAndroid端末を使っている人は、以下のどちらかを検討する。

  • OSのアップデートがあれば適用する。
  • 機種変更する。(影響を受けないAndroidか、iPhoneに乗り換える)

 

アップデートが提供されていないとか、機種変更がすぐにできない場合は、いったん以下の自衛策を取りつつ、どこかのタイミングで機種を変える。

  • 不審なサイト(アングラ色の強いサイトなど)には行かない。
  • ブラウザにはGoogle chromeを使う。標準ブラウザを使わない。
  • オンラインバンキングなどにはログインしない。

 

あと、オススメできない方法だけど、思いついたのを一応載せておく。

  • rootを取ってカスタムROMでアップデートする→root化に伴うリスクがある
  • 以前使っていた携帯に戻す→(通常は)OSが古くなってしまうので別のリスクがあるかも。キャリアを変えていたり3GからLTEに機種変更していると戻せない。

 

まとめ的な

というわけでAndroid端末を例にリバースHeartbleedの検証結果と対策のまとめでした。

悪い人のサイトにユーザを誘導できれば、情報が抜き取れるというお話です。

ツッコミや考慮漏れなどがあったら教えていただけるとありがたいです。

 

情報源

URLを載せておきます。(本文と重複あり)

http://googleonlinesecurity.blogspot.jp/2014/04/google-services-updated-to-address.html

http://www.infoq.com/jp/news/2014/04/android_heartbleed

http://d.hatena.ne.jp/Kango/20140414/1397498442

http://blog.meldium.com/home/2014/4/10/testing-for-reverse-heartbleed

https://reverseheartbleed.com/

https://forums.hak5.org/index.php?/topic/32368-exclusive-how-to-exploit-reverse-heartbleed-on-real-websites/

 

（追記）

国内のスマホは6機種該当するようですな。お使いの方はぜひアップデートを。

＜ＯｐｅｎＳＳＬ欠陥＞国内のスマホ６機種 ＯＳに問題 （毎日新聞） - Yahoo!ニュース

 

*1:Heartbeat機能には対称性がある。つまり、サーバからクライアントにHeartbeatを送信することができる

*2:自前で、脆弱性のないSSLのライブラリをもっているとか