web-dev-qa-db-ja.com

Xenial：更新中の奇妙なコードとリポジトリ

やあ！

まず、問題のtl; drの説明：

CanonicalのIP 91.189.88.162（security.ubuntu.comが解決する6つのIPの1つ）がHTTP 302リダイレクトを「 http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.comにリダイレクトしています」/ubuntu/dists/xenial-security/InRelease "。 そのIPは公式のUbuntuミラーに属しておらず、URIには何らかの種類の識別子が含まれています（トラッキングコードである可能性があり、すべてのリクエストを変更します）。調査の結果、これはソフトウェア/ OS関連の問題ではないという結論に至りました（Telefonicaのモデムに接続されたLive USBスティックから起動した別のラップトップから簡単に再現可能です。

Canonicalのリポジトリはどんな状況でもそのように振る舞うことになっていますか？このメッセージの最後に添付されているPcapサンプル。 「apt-get update」に似た手動のHTTP要求：

george@workstation-04:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff

GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re

長い包括的なバージョン（徹底的な分析、上記の情報に基づいて何が問題なのかを理解した場合の不要な読み取り）については、次のとおりです。

昨日のVMの1つでの定期的なチェック中に、奇妙なことが私の注意を引きました。

root@workstation-03:/# apt-get update ; apt-get upgrade -y
Hit:1 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]                                                         
Get:3 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]                                                                 
Get:5 http://br.archive.ubuntu.com/ubuntu xenial-updates/main AMD64 Packages [668 kB]                                                                          
Ign:6 http://winswitch.org xenial InRelease                                                            
Get:7 http://br.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages [630 kB]
Hit:8 http://winswitch.org xenial Release                                                           
Get:10 http://br.archive.ubuntu.com/ubuntu xenial-updates/main AMD64 DEP-11 Metadata [307 kB]
Get:11 http://br.archive.ubuntu.com/ubuntu xenial-updates/main DEP-11 64x64 Icons [227 kB]
Get:4 http://179.184.158.91:80/pdata/03ee5d7e461a5049/security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]**
Get:12 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe AMD64 Packages [555 kB]            
Get:13 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe i386 Packages [527 kB]   
Get:14 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe AMD64 DEP-11 Metadata [185 kB]          
Get:16 http://br.archive.ubuntu.com/ubuntu xenial-updates/universe DEP-11 64x64 Icons [263 kB]                       
Get:17 http://br.archive.ubuntu.com/ubuntu xenial-updates/multiverse AMD64 DEP-11 Metadata [5.888 B]                                             
Get:18 http://br.archive.ubuntu.com/ubuntu xenial-backports/main AMD64 DEP-11 Metadata [3.324 B]                                                  
Get:19 http://br.archive.ubuntu.com/ubuntu xenial-backports/universe AMD64 DEP-11 Metadata [4.588 B]                                            
Get:15 http://179.184.158.91:80/pdata/03ee827eaa21046b/security.ubuntu.com/ubuntu xenial-security/main AMD64 DEP-11 Metadata [60,3 kB]          
Get:20 http://179.184.158.91:80/pdata/03ee977e21229dae/security.ubuntu.com/ubuntu xenial-security/main DEP-11 64x64 Icons [57,6 kB]
Get:21 http://179.184.158.91:80/pdata/03eeaa7e9723e1be/security.ubuntu.com/ubuntu xenial-security/universe AMD64 DEP-11 Metadata [51,4 kB]
Get:22 http://179.184.158.91:80/pdata/03eef57e5c24a1d6/security.ubuntu.com/ubuntu xenial-security/universe DEP-11 64x64 Icons [85,1 kB]**
Fetched 3.937 kB in 3s (1.115 kB/s)    
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
...

「179.184.158.91」の由来はわかりません。このVM（winswitch）には非公式リポジトリが1つしかインストールされていませんが、xenial-securityがこのIPアドレスを呼んでいます。さらに、「03ee827eaa21046b」のような一意の識別子を保持しているようです。

追加情報：

cat /etc/apt/sources.list

deb http://br.archive.ubuntu.com/ubuntu/ xenial main restricted
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial main restricted

deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates main restricted
deb http://br.archive.ubuntu.com/ubuntu/ xenial universe
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial universe
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates universe

deb http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial multiverse
deb http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-updates multiverse

deb http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse
 deb-src http://br.archive.ubuntu.com/ubuntu/ xenial-backports main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu xenial-security main restricted
 deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
deb http://security.ubuntu.com/ubuntu xenial-security universe
 deb-src http://security.ubuntu.com/ubuntu xenial-security universe
deb http://security.ubuntu.com/ubuntu xenial-security multiverse
 deb-src http://security.ubuntu.com/ubuntu xenial-security multiverse

cat /etc/apt/sources.list.d/*

root@workstation-03:~# cat /etc/apt/sources.list.d/*
deb http://winswitch.org/ xenial main

インストールされたリポジトリはいずれもそのIPに解決しません。

george@workstation-03:~$ Dig A security.ubuntu.com +short
91.189.91.23
91.189.88.149
91.189.91.26
91.189.88.152
91.189.88.162
91.189.88.161

george@workstation-03:~$ Dig A winswitch.org +short
78.129.163.65

逆IPルックアップツールも、そのIPに解決するFQDNアドレスを見つけることができません。

そのIPはISP（Telefonica）によって発表されていますが、今まで聞いたことのない小さなプロバイダーによって使用されているようです。

george@workstation-03:~$ whois 179.184.158.91 | grep owner:
owner:       TELEFÔNICA BRASIL S.A

george@workstation-03:~$ Host 179.184.158.91
91.158.184.179.in-addr.arpa domain name pointer imaxima.static.gvt.net.br.

すぐにその動作を再現しようとしましたが、apt-getの更新中にそのIPは表示されなくなりました。

このVM（システム全体またはアプリケーション固有）には、いかなる種類のプロキシもありません。このVMは、OPNSenseファイアウォールを介してインターネットに接続し、送信フィルタリングは設定されていません。疑わしいアドレスに気づくとすぐにapt-getによって送受信されるHTTPヘッダーを確認するためにトラフィックをtcpdumpしようとしましたが、その動作を再現できなくなったため、何も思いつきませんでした。しかし幸運なことに、昨夜再びapt-getアップデートを実行しましたが、今回は奇妙なIPが再び現れましたが、今回は1行だけでした。

その瞬間、Wiresharkを起動し、キャプチャ全体を実行しました。判明したように、これはDNS関連の異常ではなく（ここで設定したすべてのリゾルバーを照会することでこれを確認しましたが、「179.184.158.89」を返すものはありません）、6つのIPのうち少なくとも1つ.ubuntu.comは、（91.189.88.162）がHTTP 302を介してその不明なURIを返していることを解決します。以下にテストしたリストを示します。

security.ubuntu.com.    383     IN      A       91.189.88.149
security.ubuntu.com.    383     IN      A       91.189.88.162    X
security.ubuntu.com.    383     IN      A       91.189.88.152
security.ubuntu.com.    383     IN      A       91.189.91.26     
security.ubuntu.com.    383     IN      A       91.189.91.23
security.ubuntu.com.    383     IN      A       91.189.88.161

手動で動作を一貫して再現できるようになりました。念のために、User-Agentを「Debian APT-HTTP/1.3（1.2.24）」に設定して、中間に位置する仮想ハニーポットから注意をそらします。

george@workstation-04:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

302 Found
Cache-Control: no-cache
Connection: close
Location: http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
Content-Length: 0
Content-Type: text/html
Client-Date: Sat, 25 Nov 2017 20:44:04 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1
X-Content-Type-Options: nosniff

GET http://179.184.158.89:80/pdata/05f4cdcfbada50fc/security.ubuntu.com/ubuntu/dists/xenial-security/InRelease
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1144, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sat, 25 Nov 2017 20:13:04 GMT
Accept-Ranges: bytes
ETag: "18ef2-55ed440fdb600"
Server: nginx
Content-Length: 102130
Expires: Sat, 25 Nov 2017 21:05:00 GMT
Last-Modified: Sat, 25 Nov 2017 20:10:00 GMT
Client-Date: Sat, 25 Nov 2017 20:44:05 GMT
Client-Peer: 179.184.158.89:80
Client-Response-Num: 1
X-OC-Service-Type: re

残りの5つのIPはすべてHTTP 200を返します。これは、私が知る限り、すべてのIPに期待される動作です。例えば：

george@core-workstation:~$ GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.161/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=1271, s-maxage=3300, proxy-revalidate
Connection: close
Date: Sun, 26 Nov 2017 23:34:48 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eeac2604300"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Sun, 26 Nov 2017 23:56:00 GMT
Last-Modified: Sun, 26 Nov 2017 23:01:00 GMT
Client-Date: Sun, 26 Nov 2017 23:33:34 GMT
Client-Peer: 91.189.88.161:80
Client-Response-Num: 1

ご覧のとおり、CanonicalのIP 91.189.88.162自体が、その疑わしいIPへのHTTP 302リダイレクトを返しています。この異常は、私のVMのどれからでも再現可能であり、Telefonicaのモデムに直接差し込んで置いた古いラップトップ上のライブOSからでさえも再現可能であるため、これはファイアウォールとも関係がないという結論に達しました。 Telefonicaのギアはリビングルームにありますが、ネットワークの安全な境界の外側にあるため、監査などは行われません。どちらにしても、カスタムの静的ルートが設定されていない、汚れの少ないDSL-2730E ADSL2 +ルーターであるため、私はそれが犯人だとは思いません。私は、物事が変化するかどうかを確認するために、これらの日のうちの1つをブリッジしてみます。

奇妙なことに、302応答には、他のすべての要求とは異なり、Webサーバーの署名が含まれていないため、その間の何かがその特定のIPおよびポートへのパケットをインターセプトしている可能性があります。カナダの私が所有するサーバーから取った例は、「サーバー」ヘッダーを明確に示しています。

root@server-1:~# GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
GET http://91.189.88.162/ubuntu/dists/xenial-security/InRelease
Host: security.ubuntu.com
User-Agent: Debian APT-HTTP/1.3 (1.2.24)

200 OK
Cache-Control: max-age=0, s-maxage=3300, proxy-revalidate
Connection: close
Date: Mon, 27 Nov 2017 05:48:29 GMT
Accept-Ranges: bytes
ETag: "18ef2-55eef9eebc700"
Server: Apache/2.4.18 (Ubuntu)
Content-Length: 102130
Expires: Mon, 27 Nov 2017 05:48:29 GMT
Last-Modified: Mon, 27 Nov 2017 04:49:00 GMT
Client-Date: Mon, 27 Nov 2017 05:48:29 GMT
Client-Peer: 91.189.88.162:80
Client-Response-Num: 1

ただし、物事を短くするために、91.189.88.162の背後にあるそのサーバーをフィンガープリントしようとしても、トラフィックが改ざんされていることを証明できませんでした。 TCPtracerouteとmtrは両方とも予想されるルートを示し、HTTPレイテンシは91.189.88.161（ロンドンにある6つのうちの1つ）と比較して5％のマージン内です。 Nmapプロービングは、Canonicalのサーバーに到達していることも示唆しています（これは非常に慎重に作成されたMITM攻撃である場合を除き、そうではないようです）。また、BGPハイジャックの証拠は見られず、ルートは問題ありません。

show route protocol bgp 91.189.88.162 | no-more 

inet.0: 688953 destinations, 2269968 routes (688942 active, 0 holddown, 4860 hidden)
+ = Active Route, - = Last Active, * = Both

91.189.88.0/24     *[BGP/170] 2w0d 17:19:51, MED 0, localpref 85, from 94.142.108.190
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0
                    [BGP/170] 2w0d 17:20:31, MED 0, localpref 85, from 94.142.108.210
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0
                    [BGP/170] 5d 02:34:24, MED 0, localpref 85, from 94.142.108.193
                      AS path: 3356 41231 I, validation-state: unverified
                      to 5.53.3.85 via ae11.0
                      to 5.53.3.79 via ae17.0
                    > to 5.53.3.223 via et-9/3/0.0

ポート80に対するTcptraceroute：

george@workstation-04:/$ tcptraceroute -w1 91.189.88.162 80
Selected device enp0s3, address 10.4.4.119, port 47917 for outgoing packets
Tracing the path to 91.189.88.162 on TCP port 80 (http), 30 Hops max
 1  10.4.4.200  0.295 ms  0.220 ms  0.306 ms
 2  192.168.25.1  1.938 ms  2.106 ms  1.883 ms
 3  gvt-b-sr01.cta.gvt.net.br (179.184.120.13)  20.106 ms  22.429 ms  19.890 ms
 4  201.22.69.21.dynamic.adsl.gvt.net.br (201.22.69.21)  20.087 ms  20.514 ms  20.716 ms
 5  201.22.64.99.dynamic.dialup.gvt.net.br (201.22.64.99)  27.391 ms  28.520 ms  28.410 ms
 6  213.140.39.82  27.475 ms  28.178 ms  27.646 ms
 7  5.53.3.143  143.486 ms  142.026 ms  142.533 ms
 8  * * *
 9  ae-126-3512.Edge5.london1.Level3.net (4.69.166.45)  271.503 ms  268.769 ms  268.715 ms
10  SOURCE-MANA.Edge5.London1.Level3.net (212.187.138.82)  291.886 ms  271.616 ms  273.050 ms
11  yukinko.canonical.com (91.189.88.162) [open]  281.588 ms  273.400 ms  273.496 ms

私はこの問題を掘り始めていましたが、私の近所で電力が切れました（それ自体は非常にまれです。ゴー・マーフィー！）。 3時間後に復旧したら、すべてのVMを起動しましたが、正常に起動できなかったVMを除きます。どっちだ？そうです

ちなみに、それはたまたま私が家に持っている唯一のUbuntu 16.04 VMです。私のどのVMでもこのタイプの障害は前例のないものであり、偶然の1つです。私はすぐにそのディスクのスナップショットを取り、安全のために、後で詳細なフォレンジック分析のために上記のVMを廃止しました。どうやら何かがX11-Serverを破壊しました。これは2017-11-07に最後に更新されました。後で調べますが、このリダイレクトだけでこれがどのように発生するかはわかりません。

電源が回復すると、その問題に直面しなくなりました。つまり、6つのIPへのすべてのリクエストはHTTP 200を返すはずです。そのため、本日より早く、新しい動的IPを取得するためにPPPoE認証を再起動するようにモデムに強制し続け、その6つのIPを再度チェックして、その動作が戻るかどうかを確認しました。 11後で再接続、ビンゴ！ 91.189.88.162はそれらのHTTP 302を投げ始めました。再接続のたびに使用していたIPのリストを示します（Canonicalのフロントエンドに、何らかの理由でソースIPに基づいて意図的に動作を操作するACLがある場合）。最初と最後を除いて、security.ubuntu.comで問題は発生していません。

191.250.187.149 (The one I was using when I started this topic)
177.132.10.0
187.112.57.37
186.212.197.62
177.132.109.6
187.112.135.18
201.86.5.226
201.86.5.226
201.86.5.226
189.115.80.207
177.133.196.249
177.16.143.235
177.204.139.117
179.182.184.0/24 (The IP I'm using now belongs to this subnet)

ブラジルの別のISPと世界中のいくつかのサーバーからCanonicalの6つのIPを照会し、矛盾を排除するために宛先IPごとに常に5つのクエリを実行しました。それらのどれもそのHTTP 302を返しませんでした。一度もありません。ただし、ホーム接続では、91.189.88.162に対するすべての試行は、数秒間隔を空けない限りHTTP 302になります。その場合、「キャッシュ-コントロール：no-cache」は302応答で設定されます。変だよね？

その動作を再現しようとする人を招待します。その302リダイレクトに遭遇した場合はお知らせください。

GET -USed -H "Host: security.ubuntu.com" -H "User-Agent: Debian APT-HTTP/1.3 (1.2.24)" http://91.189.88.162/ubuntu/dists/xenial-security/InRelease

私の場合、この宛先IP（179.184.158.89）はUbuntuのミラーリストのどの会社にも属していません。InReleaseファイルを提供する必要がある理由がわかりません。 。このアドレスは、ここから400km以上離れた別の州の小さなISPに割り当てられます。

要するに、これが統計を収集するように意図的に設定されている場合（これはあまり意味がありません）、これはかなり不規則であり、6つのIPのうち1つだけで機能するため、非常に不十分に実装されていると言っても安全ですローカルDNSクライアントがそれらを処理する方法を管理できないため、ランダムまたはラウンドロビンが選択され、6 Aレコードはすべて同じTTLを共有します）。これには、推測の余地がたくさんあります。

誰かがそれを見たい場合に備えて、apt-get更新中に撮影されたpcapファイルを以下に示します。簡単にするために、HTTPリクエスト以外は除外しましたが、デバッグに必要な場合はすべてアップロードできます。対象のパケットは、＃6、＃7、および＃9です。

https://mega.nz/#!NORi2ALA!njJRKZ4i26GHXaET_ZA6Z4ymWYKhccTGNiEBCcGtwbA

SHA256：40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe

私は何かを見逃しているはずです... PS：これはセキュリティインシデントというよりもプライバシーの問題だと思いますが、どちらにしてもこの動作は文書化されていません（Googleはそれに似たものを見つけられません）ので、人々に確認することにしました念のために。

どんな助けも大歓迎です！ここまで頑張ってくれてありがとう！ :)

16.04updatesxubuntusecurityrepository
3
Mr.Ash

X-OC-Service-Typeは、応答がOpen Cacheノードから来たことを示します。

ISPは、Qwiltなどの企業が提供するOpen Cacheサーバーを、ネットワーク上の透過的なキャッシュプロキシとして使用します。要求はルーティングノードによってインターセプトされ、キャッシュノードにリダイレクトされました。キャッシュノードにはキャッシュされたオブジェクトがありませんでした（ 're' = relay for miss; 'lo' = local for hit）ので、理論的には、オブジェクトを取得するためにリクエストした元のHost + pathに行きました。

実際には悪意のある傍受のようなものだった可能性がありますが、私の推測では、ISPのプロキシだけでした。

2
Taylor