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。
今後の課題
- 他の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脆弱性
クライアントから情報が漏れるので、かなり危険なんじゃないかと思うけど、あまり注意喚起もされていないようなので知らない人もいるのでは?と思って、その検証と、対策などをまとめてみた。
該当する端末やアプリを使っている人はぜひ参考にして自衛してほしい。
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攻撃ができるか、以下の環境で検証してみた。
- 端末A:Android 4.1.1(リバースHeartbleed影響有り/HTC J butterfly)
- 端末B:Android 4.0.3(影響無し/HTC EVO 3D)
- サーバ:攻撃用サーバ。OSはKali linux、サーバスクリプトはpacemaker.pyを使用。
Heartbleed Detectorで端末のHeartbleed状況を確認する。
左:端末A:Android 4.1.1(HTC J butterfly。リバースHeartbleed影響有り)
右:端末B:Android 4.0.3(HTC EVO 3D。影響無し)
手順と結果
1. 攻撃用サーバの準備
攻撃用サーバからスクリプトを実行する。
サーバのURLは、例えばhttps://192.168.1.1:4433/のようになる。
2. 端末Aで攻撃用サーバにアクセス
端末AのAndroid標準ブラウザから攻撃用サーバにアクセスする。
サーバのコンソール上では以下のように端末のメモリ内の情報が表示された。(バイナリ部分はマスク)
取得したメモリ内容によっては、暗号化鍵や個人の情報が漏洩するおそれがある。
今回は、過去アクセスしたURL、サイトへのログインID、Googleアカウントなどが取得できた。
例:過去アクセスしたURL
また、OSが影響受けても、アプリが影響を受けない場合*2、(そのアプリの通信からは)メモリ内容は漏洩しない。
例:Android 4.1.1(影響有り)でGoogle chrome(影響無し)を使ってアクセスした場合
3. 端末Bで攻撃用サーバにアクセス
端末Bで同様にアクセスする。脆弱性がないので漏洩しない。
以上の結果から、脆弱な端末のユーザを、攻撃用サーバのURLにアクセスさせることができれば、端末のメモリ内容を盗み取ることができると考えられる。
対策
まずは影響を受けるかチェックする。
Androidの場合はHeartbleed DetectorやBluebox Heartbleed Scannerで、OSとアプリをチェックする。
不運にも該当するAndroid端末を使っている人は、以下のどちらかを検討する。
アップデートが提供されていないとか、機種変更がすぐにできない場合は、いったん以下の自衛策を取りつつ、どこかのタイミングで機種を変える。
- 不審なサイト(アングラ色の強いサイトなど)には行かない。
- ブラウザには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/
(追記)
国内のスマホは6機種該当するようですな。お使いの方はぜひアップデートを。
<OpenSSL欠陥>国内のスマホ6機種 OSに問題 (毎日新聞) - Yahoo!ニュース
EVO 3D(ISW12HT)でBluetoothキーボードを試した
先日、Android用にBluetoothキーボードを買った。
用途は、外で打ち合わせ時にメモしたいときに使う予定。*1
買う前に動作情報を調べたが、僕が買ったキーボードについてはあまり情報がなかったので検証結果をまとめておく。
これから買う方の参考になればありがたい。
確認環境
- HTC EVO 3D(ISW12HT)
- Android 2.3.4
- Bluetooth 3.0
- Microsoft Bluetooth Mobile Keyboard 5000 L4L-00001*2
- iWnn IME 2.1.4, Google日本語入力Beta 1.5.1089.3
対象機器を配置したときの様子。
検証内容
検証結果
そもそも使えるのか?
問題なく使用できた。
キーボードの電源を入れて、EVO 3DのBluetoothを有効にして機器検索、表示されたパスコードをキーボードから入力で使用可能になった。
キーボード配列(英字配列、日本語配列)がどう認識されるか?
キーボードは英字配列になった。
(記号は印字通りに出ない。「@」=「Shift+2」など)
ローマ字入力は問題なく使えるか?&縦置き、横置きともに問題なく使えるか?
ローマ字入力と縦置き・横置きの結果は以下のとおり。
入力方法\画面の向き | 縦置き | 横置き |
---|---|---|
iWnn IME | ○ | ○ |
Google日本語入力Beta | × | ○ |
横置きだと問題ない。Google日本語入力Betaで縦置きは実用に耐えない。
キーボードの文字のところを順に入力(12345〜〜、qwerty〜〜)していくとこうなった。法則がよくわからん。かな入力の印字とも異なる。
あかさたなはまやらわー=
むりすめ「れゆてへみ
きもしせちつにぬねう’¥
ろるけ」くふひ。.ん
Simeji、ATOKは使っていないので未検証。
その他、気づいた点(入力時の注意事項など)はあるか?
気づいた点をつらつらと。
- iWnn IMEでは、日本語入力切り替えはShift+Space。
- Google日本語入力では、画面上で日本語入力切り替え操作が必要。ただ日本語入力時でもShiftを押しながらアルファベット入力が可能。
- 記号は日本語入力時だと全角になる。
- CapsLockは利かない模様。
- F3でTELの画面、F4で画面が消える(電源ボタンと同じ)、Homeキーでホーム画面、Endキーで画面が消える
あとはキーボードの感想でも。
キーボードは薄型ながら打ちやすかった。さすがハードウェアに定評のあるMicrosoft。
あとサイズ的にピッタリのケースがないが、ダイソーのA4ワイドソフトケースが横幅ぴったり(縦は余る)なのでこれに入れている。
ELECOMやBUFFALOからもBluetoothキーボードが出ており、店頭でいろいろ試し打ちしたが、Microsoftのが断然打ちやすく感じた。サイズの大きさが気にならなければ、こちらがおすすめ。