Xenial: странный код и репо во время обновления

Hy!

Во-первых, объяснение проблемы:

IP-адрес Canonical 91.189.88.162 (один из шести IP-адресов security.ubuntu.com разрешает) возвращает HTTP 302 перенаправление на « http://179.184.158.89:80/pdata/05f7e7f89ba2302b/security.ubuntu.com/ubuntu/dists / xenial-security / InRelease ". Этот IP-адрес не принадлежит официальному зеркалу Ubuntu, а URI содержит какой-то идентификатор (это может быть код отслеживания, он изменяет каждый запрос). Исследование привело к выводу, что это не проблема, связанная с программным обеспечением / ОС (легко воспроизводимая с другого ноутбука, загружаемая с USB-накопителя Live, подключенного к модему Telefonica, и не может быть воспроизведена нигде еще).

Предполагается, что хранилища Canonical должны так себя вести в любых обстоятельствах? Пример Pcap, прикрепленный в конце этого сообщения. Ручной HTTP-запрос, имитирующий «apt-get update»:

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 

Теперь для долгой, исчерпывающей версии (тщательный анализ, ненужное чтение, если вы выяснили, что не так, основываясь на информации выше):

Во время обычной проверки на одном из моих ВМ вчера, что-то странное привлекло мое внимание:

 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», на этой виртуальной машине (только Winswitch) установлено только одно неофициальное репо, но 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 не могут найти любой адрес FQDN, разрешающий этот IP-адрес.

Этот IP объявлен моим провайдером (Telefonica), но, похоже, он используется небольшим провайдером, о котором я до сих пор не слышал:

 george@workstation-03:~$ whois 179.184.158.91 | grep owner: owner: TELEFÔNICA BRASIL SA george@workstation-03:~$ host 179.184.158.91 91.158.184.179.in-addr.arpa domain name pointer imaxima.static.gvt.net.br. 

Я попытался воспроизвести это поведение сразу после, но этот IP-адрес больше не появлялся во время обновления apt-get.

В этой виртуальной машине (как для всей системы, так и для приложения) нет никакого прокси-сервера. Эта виртуальная машина подключается к Интернету через брандмауэр OPNSense, настройка исходящей фильтрации не настраивается. Я попытался tcpdump трафик, чтобы проверить HTTP-заголовки, отправленные и полученные apt-get, как только я заметил подозрительный адрес, но поскольку я больше не мог воспроизвести это поведение, с ним ничего не получилось. К счастью, однако, вчера вечером я снова запустил обновление apt-get, и этот странный IP появился снова, хотя на этот раз только на одной линии.

В этот момент я выстрелил в Wireshark и прошел весь захват. Как оказалось, это не аномалия, связанная с DNS (я ранее подтвердил это, запросив каждый резольвер, который я установил здесь, ни один из них не вернул это «179.184.158.89»), по крайней мере, один из шести IP-адресов, .ubuntu.com разрешает (91.189.88.162) возвращает этот неизвестный URI через HTTP 302. Вот список, который я тестировал:

 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)», чтобы отвлечь любое внимание от гипотетического honeypot, который мог бы сидеть где-то посередине, на всякий случай:

 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 

Все эти пять оставшихся IP-адресов возвращают HTTP 200, что является ожидаемым поведением для всех из них, насколько я знаю. Например:

 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 возвращает HTTP 302 перенаправление на этот подозрительный IP-адрес. Поскольку эта аномалия воспроизводится с любой из моих виртуальных машин и даже с живой ОС на старом ноутбуке, который я прокладывал, подключив прямо к модему Telefonica, я пришел к выводу, что это также не связано с моим брандмауэром. Несмотря на то, что аппарат Telefonica находится в моей гостиной, он находится за пределами защищенного периметра моей сети, поэтому он не проверяется или что-то еще. В любом случае, я не считаю, что это преступник, поскольку это грязный дешевый DSL-2730E ADSL2 + Router без настраиваемых статических маршрутов. На днях я попытаюсь разогнать его, чтобы посмотреть, не изменится ли ситуация.

Как ни странно, этот ответ 302 не несет подпись веб-сервера в отличие от всех других запросов к нему, что заставило меня поверить, что что-то промежуточное может перехватывать пакеты для этого конкретного 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-латентность находится в пределах 5% по сравнению с 91.189.88.161 (что является одним из шести, а также находится в Лондоне). Исследование 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 

Tcptraceroute против порта 80:

 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 

В то время как я начинал копаться в этом вопросе, сила вышла в моем районе (что крайне редко само по себе. Go Murphy!). Как только он вернулся через 3 часа, я загрузил все свои виртуальные машины, за исключением тех, которые не были загружены должным образом. Угадайте, какой? Это верно.

Кстати, это единственная Ubuntu 16.04 VM у меня дома. Этот тип сбоев беспрецедентен для любой из моих виртуальных машин, что делает его одним из совпадений. Я немедленно приступил к снимку своего диска и выведенному из эксплуатации указанной виртуальной машины для углубленного судебно-медицинского анализа позже, чтобы быть в безопасности. По-видимому, что-то сломало X11-Server, который был последний раз обновлен до 2017-11-07. Я расскажу об этом позже, но я не вижу, как это приведет к тому, что это произойдет.

Следует отметить, что после того, как власть вернулась, я больше не сталкивался с этой проблемой, то есть каждый запрос к шести IP-адресам возвращал бы HTTP 200, как и следовало бы. Поэтому ранее сегодня я продолжал заставлять модем перезапускать аутентификацию PPPoE, чтобы получить новый динамический IP-адрес, а затем снова проверил бы эти 6 IP-адресов, чтобы узнать, вернется ли это поведение. 11 снова соединяется, бинго! 91.189.88.162 начал бросать мне те HTTP 302. Вот список IP-адресов, которые я использовал после каждого повторного подключения (в случае наличия ACL в интерфейсе Canonical, который по какой-либо причине целенаправленно манипулирует поведением, основанным на исходном IP-адресе). Все, кроме самого первого и последнего, не возникало проблем с 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) 

Я запросил шесть IP-адресов Canonical у другого провайдера в Бразилии, а также на нескольких серверах по всему миру, всегда выполняя 5 запросов для IP-адреса назначения, чтобы исключить несоответствия. Никто из них не возвращал HTTP 302. Никогда. Даже не один раз. Однако в моей домашней связи каждая попытка против 91.189.88.162 дает HTTP 302, если я не буду пытаться отделить несколько секунд, и в этом случае он вернет HTTP 200, как если бы я обходил какой-то кеш, несмотря на то, что «Cache- Контроль: 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. Этот адрес выделяется маленькому интернет-провайдеру в другом состоянии на расстоянии 400 км + отсюда.

Итог: если это намеренно настроено для сбора статистики (что даже не имеет особого смысла), можно с уверенностью сказать, что это было крайне плохо реализовано, поскольку оно довольно неустойчиво и работает только для одного из 6 IP-адресов (что будут выбраны случайным образом или циклически, поскольку они не могут управлять тем, как будет обрабатываться локальный DNS-клиент, и все записи из 6 A имеют один и тот же TTL). Это оставляет много места для спекуляций.

В случае, если кто-то захочет это увидеть, вот он pcap-файл, сделанный во время обновления apt-get. Я просто отфильтровал все, кроме HTTP-запросов, для простоты, но я буду рад загрузить все это, если необходимо для отладки. Интересные пакеты – №6, №7 и №9:

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

SHA256: 40fc995e505ee2dcaf9aa3e23961a757f628224e3fca83d0deed6374ba9a3fbe

Я должен что-то упустить … PS: Я предполагаю, что это скорее проблема конфиденциальности, чем инцидент с безопасностью, так как это поведение недокументировано (Google не найдет ничего похожего на него), поэтому я решил проверить с вами людей просто чтобы быть в безопасности.

Любая помощь высоко ценится! Благодарим за то, что вы так далеко! 🙂