ᕕ( ᐛ )ᕗ こんにちわ、しいたけです。
webのhttps化が推進される昨今ですね?
https通信は経路上での通信内容が盗聴・改竄されるのを防ぐことができますが、開発用途でhttps通信の内容を確認したい場合が稀にあります。
そのような場合は mitmproxyなどを導入すればよいのですが、せっかくなので実際にこのようなProxyをGoで実装してみて、 中間者攻撃(Man-in-The-Middle Attack)がどのような手法でhttps通信を盗聴・改竄するのか確かめてみました。
実際に書いたProxyのコードはこちらです
yuroyoro/mitm_proxy_sample
https proxy と HTTP CONNECT tunneling
まず、通常のhttps Proxyの動作を確認してみましょう。
httpsでは、ProxyはクライアントからのCONNECTメソッドを受信すると、クライアントに代わって対象ホストとのTCPコネクションを確立し、以降はクライアントと対象ホストのTCP通信を転送します。クライアント-ホスト間のTLS接続のhandshakeもproxyを経由して行わます。
この方式により、Proxyを経由しつつクライアント-ホスト間でTLSセッションが確立され、Proxyを経由しつつも経路上では暗号化された通信が可能となります。
図にするとこんな感じです
![f:id:yuroyoro:20180216193239p:plain f:id:yuroyoro:20180216193239p:plain]()
実装
では具体的な実装を見てましょう。
まずはおなじみ ServeHTTP
です。クライアントから CONNECT
メソッドが送信されたら、通信を転送する relayHTTPSRequest
を呼び出します
https://github.com/yuroyoro/mitm_proxy_sample/blob/master/main.go#L34
func (proxy *MiTMProxy) ServeHTTP(w http.ResponseWriter, r *http.Request) {
if r.Method == http.MethodConnect {
if proxy.mitm {
proxy.mitmRequest(w, r)
} else {
proxy.relayHTTPSRequest(w, r)
}
return
}
proxy.transportHTTPRequest(w, r)
}
実際に通信を転送しているコードは以下のとおりです。処理の流れはコメントを読んでもらえばわかると思いますが、やっていることは単純です。
CONNECT
メソッドで指定されたホストにTCP接続を張って、クライアントからの通信をそのまま流し込むだけです
https://github.com/yuroyoro/mitm_proxy_sample/blob/master/https.go#L12
func (proxy *MiTMProxy) relayHTTPSRequest(w http.ResponseWriter, r *http.Request) {
proxy.info("relayHTTPSRequest : %s %s", r.Method, r.URL.String())
dest, err := net.Dial("tcp", r.Host)
if err != nil {
http.Error(w, err.Error(), http.StatusServiceUnavailable)
return
}
conn := hijackConnect(w)
conn.Write([]byte("HTTP/1.0 200 OK\r\n\r\n"))
proxy.info("relayHTTPSRequest : start relaying tcp packets %s %s", r.Method, r.URL.String())
go transfer(dest, conn)
go transfer(conn, dest)
}
func transfer(dest io.WriteCloser, source io.ReadCloser) {
defer dest.Close()
defer source.Close()
io.Copy(dest, source)
}
Goには http.Hijackerという便利なインターフェースがあり、 http.ResponseWriter
から生のクライアントとのTCP接続を取り出すことができます。
これを利用して、TCP通信の転送を行っています
func hijackConnect(w http.ResponseWriter) net.Conn {
hj, ok := w.(http.Hijacker)
if !ok {
panic("httpserver does not support hijacking")
}
conn, _, err := hj.Hijack()
if err != nil {
panic("Cannot hijack connection " + err.Error())
}
return conn
}
実際はtimeoutなどを考慮した実装をすべきなのですが、これだけでも動きます。
Man in The Middel Proxyの仕組み
では、本題の中間者攻撃を行うProxyについてです。
通常のhttps proxyでは、クライアントからの CONNECT
メソッドを契機に、対象HostとのTCP通信を中継していました。
Proxyを流れる通信内容はTLSによって暗号化されており、内容を盗聴・改竄することはできません。
しかし、対象Hostとクライアント間のTLS handshakeもProxyを経由するので、この段階でクライアントからのTLS handshakeを、対象ホストになりすましてProxyが行うとどうなるでしょうか?
つまり、Proxyは対象ホストのサーバー証明書をその場で生成して署名し、クライアントに提示します。
もちろん、Proxyが署名したサーバー証明書は信頼できないCAのものとしてブラウザには警告が出ますが、そのままユーザーが続行することでTLS handshakeが成功します。
クライアントは確立したTLS接続を対象ホストとのものだと思いこんで、Proxyがクライアントに送り込んだニセのサーバー証明書の公開鍵で通信を暗号化するので、Proxyはその内容を復号することができます。
あとは、復号したリクエストをそのまま対象のホストに転送すれば、httpsにも関わらずProxyは通信内容を把握しつつ、対象ホストとの通信を取り持つことができてしまいます。
これで中間者攻撃が成立しますʕ ゚皿゚ ʔ 。
図にすると以下の流れとなります
![f:id:yuroyoro:20180216193258p:plain f:id:yuroyoro:20180216193258p:plain]()
通常、このような攻撃はブラウザが警告を出すために成立しません。
まず、ユーザーが明示的にブラウザにProxyを指定する必要がありますし(port forwardを利用した透過Proxyはその限りではない)、Proxyが署名に使用するルート証明書(または中間証明書)がTrust Chainにないからです。
逆に言えば、信頼できないルート証明書をシステムにインストールしてしまうと、このような攻撃が成立する余地が生まれてしまいます。
実際に、一部のセキュリティアプライアンスやアンチウィルスソフトウェアは、このような手法でhttps通信の内容をチェックしています。
Avastを入れた状態でブラウザで証明書チェーンを確認すると、 「Avast trusted CA」という謎の認証局が出現するのはこのためです( ;゚皿゚)ノシΣ フィンギィィーーッ!!!
以前、LenovoのPCにプリインストールされたアドウェア「Superfish」がルート証明書をシステムにインストールした上に、全PCで共通のCA秘密鍵を使っていたことで大問題になりましたね。
Dellでも似たようなことがあったみたいです( ꒪⌓꒪)
LenovoのPC全機種にプレロードされているアドウェアが実は恐ろしいマルウェアだった! | TechCrunch JapanDellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ
実装
それでは具体的な実装の解説を行います。処理の流れは以下のとおりです。
- CONNECTメソッドのリクエストから、http.Hijackerを使って生のTCPコネクションを取り出す
- クライアントには200 okを返す
- 接続先ホストの証明書を、予め用意してあるroot証明書でサインして生成する
- 生成した証明書でクライアントとtls接続を確立する (root証明書が登録されていないとブラウザで警告が出る)
- goroutine起こして、クライアントとのtls接続からhttp requestを読み込む
- 受けたhttp requestをそのまま接続先hostに送信する
- 接続先hostからのhttp responseを、クライアントtls接続に書き込む
- EOFが来るまで 5-7繰り返し
https://github.com/yuroyoro/mitm_proxy_sample/blob/master/https.go#L57
func (proxy *MiTMProxy) mitmRequest(w http.ResponseWriter, r *http.Request) {
conn := hijackConnect(w)
conn.Write([]byte("HTTP/1.0 200 OK\r\n\r\n"))
go proxy.transportHTTPSRequest(w, r, conn)
}
func (proxy *MiTMProxy) transportHTTPSRequest(w http.ResponseWriter, r *http.Request, conn net.Conn) {
proxy.info("transportHTTPSRequest : %s %s", r.Method, r.URL.String())
host := r.Host
tlsConfig, err := proxy.generateTLSConfig(host)
if err != nil {
if _, err := conn.Write([]byte("HTTP/1.0 500 Internal Server Error\r\n\r\n")); err != nil {
proxy.error("Failed to write response : %v", err)
}
conn.Close()
}
tlsConn := tls.Server(conn, tlsConfig)
if err := tlsConn.Handshake(); err != nil {
proxy.error("Cannot handshake client %v %v", r.Host, err)
return
}
defer tlsConn.Close()
proxy.info("transportHTTPSRequest : established tls connection")
tlsIn := bufio.NewReader(tlsConn)
for !isEOF(tlsIn) {
req, err := http.ReadRequest(tlsIn) if err != nil {
if err == io.EOF {
proxy.error("EOF detected when read request from client: %v %v", r.Host, err)
} else {
proxy.error("Cannot read request from client: %v %v", r.Host, err)
}
return
}
proxy.info("transportHTTPSRequest : read request : %s %s", req.Method, req.URL.String())
req.URL.Scheme = "https"
req.URL.Host = r.Host
req.RequestURI = req.URL.String()
req.RemoteAddr = r.RemoteAddr
dumpRequest(req)
removeProxyHeaders(req)
resp, err := proxy.transport.RoundTrip(req)
if err != nil {
proxy.error("error read response %v %v", r.URL.Host, err.Error())
if resp == nil {
http.Error(w, err.Error(), 500)
return
}
}
proxy.info("transportHTTPSRequest : transport request: %s", resp.Status)
dumpResponse(resp)
resp.Write(tlsConn)
}
proxy.info("transportHTTPSRequest : finished ")
}
ポイントは、 リクエストを受けるとニセのサーバー証明書をその場で生成して、その証明書と http.Hijacker
で取り出したクライントのTCPで tls.Server
を用いてTLS接続をなりすますことです(生成した証明書はキャッシュします)。
証明書の生成は長くなるのでここには載せませんが、 こちらを見てもらえばと思います。
クライントとのTLS接続を乗っ取れば、あとはその接続上でHttpリクエストを読み込み、対象ホストに転送すればOKです。Goでは、 http.RoundTripper
を利用すれば http.Request
をそのまま転送できるので便利です。その際に、リクエスト・レスポンスの内容をdumpしています。
悪意があれば、この段階で改竄も可能でしょう。
まとめ
以上が、Man-in-The-Middle Attackを行う簡単なProxyの実装です。この攻撃が成功する条件としては、
- 経路上にこのようなProxyが存在する (https通信がport forwardされている場合もある)
- Proxyが署名に使うルート証明書がTrust Chainに存在する
の2点です。特に2点目はTLSの根幹をなす部分で、それゆえにルート証明書の管理は厳格に行う必要があり、GoogleはSymantecの証明書を無効にし、LenoveやDellは責められるべきなのです。Avastもちょっとどうかと思います。
実際に手を動かして実装してみると、Proxyの実装で注意スべき点や、TLSと認証局の仕組みとか色々と学びがあり、よかったとおもいました( ꒪⌓꒪)