gteissier/cve-2016-6271CVE-2016-6271の概念実証エクスプロイト。libbzrtpのハッシュコミットメントバイパスによるZRTP中間者攻撃を示し、DockerベースのシミュレーションとSASブルートフォーサーを備えています。
CVE-2016-6271は、Belledonne Communicationsが開発したZRTPライブラリであるlibbzrtpに影響を及ぼします。
このライブラリはエンドユーザーアプリケーション、例えばlinphoneに組み込まれており、linphoneはPlayストアのAndroidアプリとして利用可能です。現在のバージョン3.2.7は、CVE-2016-6271に対して脆弱でないバージョンのlibbzrtpを組み込んでいます。
cd vulnerable-bzrtp && docker build -t vulnerable-bzrtp .
cd mitm-bzrtp && docker build -t mitm-bzrtp .
docker-compose -f cve-2016-6271.yaml upZRTPはVoIP通話をセキュリティ保護するソリューションです。
以下はIETF rfc6189からの抜粋です：
ZRTP is a key agreement protocol that performs a Diffie-Hellman key
exchange during call setup in the media path and is transported over
the same port as the Real-time Transport Protocol (RTP) [RFC3550]
media stream which has been established using a signaling protocol
such as Session Initiation Protocol (SIP) [RFC3261]. This generates
a shared secret, which is then used to generate keys and salt for a
Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from
[PGPfone]. A reference implementation of ZRTP is available in
[Zfone].
要約すると：
脆弱なZRTPエージェントは単一のCファイルからコンパイルされます：
ctx = bzrtp_createBzrtpContext(self_ssrc);
assert(ctx != NULL);
ret = bzrtp_setCallbacks(ctx, &bzrtp_callbacks);
assert(ret == 0);
bzrtp_initBzrtpContext(ctx);
bzrtp_setClientData(ctx, self_ssrc, ctx);
ret = bzrtp_startChannelEngine(ctx, self_ssrc);
assert(ret == 0);
for (now = 0; now += 50;) {
usleep(500000);
ret = recv(sd, buffer, sizeof(buffer), MSG_DONTWAIT);
if (ret > 0) {
received = ret;
bzrtp_processMessage(ctx, self_ssrc, buffer, received);
}
bzrtp_iterate(ctx, self_ssrc, now);
}
使用するには、cd vulnerable-bzrtp && docker build -t vulnerable-bzrtp . でDockerイメージをビルドしてください。Dockerfileはエントリポイントとしてstart.shを定義しており、これによりmalloryを経由したルーティングが設定されることに注意してください。詳細は後述します。
2016年3月30日にBelledonne Communicationsに開示され、この脆弱性はこのコミットですぐに修正されました。
ZRTPはDHPart1とDHPart2と呼ばれる2つのメッセージでDiffie-Hellmanを実行します。BobはAliceのDHPart1を受信した後に送信するDHPart2メッセージを_コミット_します。
| Commit (Bob's ZID, options, hash value) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
bzrtpで発見された脆弱性は、ハッシュコミットメント検証の欠如であり、攻撃者が興味深い特性を持つpviを偽造できる余地を残しています。
この概念実証は、rfc6189に記述された脆弱性を実装しています：
The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct Short Authentication String (SAS) (Section 7) in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. Without this hash commitment feature, a MiTM attacker would acquire both the pvi and pvr public values from the two parties before having to choose his own two DH public values for his MiTM attack. He could then use that information to quickly perform a bunch of trial DH calculations for both sides until he finds two with a matching SAS. To raise the cost of this birthday attack, the SAS would have to be much longer. The Short Authentication String would have to become a Long Authentication String, which would be unacceptable to the user. A hash commitment precludes this attack by forcing the MiTM to choose his own two DH public values before learning the public values of either of the two parties.
Malloryをアクティブな攻撃者として、上記のDH交換は次のようになります：
Bob Mallory Alice
| | Commit (Alice's ZID...) |
| |<------------------------|
| Commit (Alice's ZID...) | |
|<------------------------| |
| | |
| DHPart1 (pvr...) | |
|------------------------>| |
| | DHPart1 (pvr'...) |
| |------------------------>|
| | DHPart2 (pvi...) |
| |<------------------------|
| * SAS(Mallory, Alice) is known at this time * |
| * now find a pvi' such as SAS(Bob, Mallory) * |
| * equals SAS(Mallory, Alice) * |
| DHPart2(pvi'...) | |
|<------------------------| |
| * SAS(Mallory, Bob) = SAS(Alice, Mallory) * |
| * Both parties will confirm they share the same * |
| * SAS value * |
| * Note that SRTP material (Alice, Mallory) will * |
| * not match SRTP material (Mallory, Bob) * |
| * However, Mallory will be able to handle SRTP * |
| * flows from both Bob and Alice, giving * |
| * interception and tampering capabilities. * |
これはPython3とasyncioで構築されています。Raw IPパケットはPF_PACKETソケットを使用してキャプチャされ、IPv4フレームのみをリッスンします。ScapyがRawフレームの解析を支援します。ZRTPパケットを分析して書き換え、特にHMAC認証タグを再計算します。
SASブルートフォーサーはCベースで、以下の入力を受け取ります：
Hello of responder || Commit || DHPart1DHPart1で送信する公開値Dockerイメージをビルドするには、cd mitm-bzrtp && docker build -t mitm-bzrtp . && cd .. を実行してください。
中間者攻撃は以下のものを使用してセットアップされます：
AliceとBobはMalloryを介して通信し、Malloryは日和見的に中間者攻撃を実行します。
これは、さまざまなsviをテストし、導出されたSASが既に取得されたSASと一致するかどうかを検証することに帰着します。詳細な内容はブルートフォースソースにあります。
ZRTPメッセージは、反復ハッシュの逆連鎖を鍵として使用して認証されます。DHPart2がMalloryによって途中で変更された場合、AliceはMalloryの改ざんされたDHPart2を非認証として検出します。これは、計算されたHMACが受信したHMACと一致しないためです。このチェックを通過するために、Malloryは反復ハッシュの全チェーンを使用しなければならず、このチェーンを使用して送信するすべてのメッセージに署名する必要があります。