Решил поковыряться в сетевой структуре сервиса M.E.Doc, через который был заряжен вирус #Petya, поразивший значительную часть компаний в Украине.
Для начала посмотрел какие IP-адреса стоят за сервисом обновлений upd.me-doc.com.ua. Оказалось что такую большой банк инсталлированных приложений обслуживает только один хост:
$dig -t any upd.me-doc.com.ua
; <<>> DiG 9.8.2rc1-RedHat-9.8.2–0.62.rc1.el6_9.2 <<>> -t any upd.me-doc.com.ua
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39676
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10
;; QUESTION SECTION:
;upd.me-doc.com.ua. IN ANY
;; ANSWER SECTION:
upd.me-doc.com.ua. 59 IN A 92.60.184.55
;; AUTHORITY SECTION:
com.ua. 66991 IN NS ho1.ns.com.ua.
com.ua. 66991 IN NS nix.ns.ua.
com.ua. 66991 IN NS ba1.ns.ua.
com.ua. 66991 IN NS k.ns.com.ua.
com.ua. 66991 IN NS sns-pb.isc.org.
Ой, что это? Для обновления сотен тысяч копий инсталляций Медка используется всего один хост — 92.60.184.55. Я конечно понимаю, что за одним хостом может стоять целый парк серверов. Но есть еще один важный момент — TTL записи равен всего 60 секунд ( на скрине видно 59 сек, потому что 1 сек заняло получение ответа от dns-сервера). Такой маленький TTL будет провоцировать огромное количество запросов на dns-сервера, потому что он практически не кэшируется — срок жизни в памяти кэширующего dns-сервера будет составлять всего 30 сек.
В мире Интернета не принято критически важные сервисы вешать на один хост. Например, для обслуживания dns-записей должно быть не менее 2х хостов, и желательно физическое расстояние между ними — не менее 200 км.
Вітекающий обощенный вопрос: зачем такому критичному сервису использовать такие очень критичные для стабильности показатели — всего 1 хост и с таким коротким временем достоверности 30 сек (половина от TTL 60 сек)?
Ответ пока в голове только один — что бы в случай чего быстро закрыть хост и отказать в обслуживании, попросту — быстро смыться и унести ноги.
Ок, идем дальше, а на чьей площадке располагается этот хост для обновления такого критичного приложения, как M.E.Doc:
whois 92.60.184.55
[Querying whois.arin.net]
[Redirected to whois.ripe.net]
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the “-B” flag.
% Information related to ‘92.60.184.0–92.60.184.255’
% Abuse contact for ‘92.60.184.0–92.60.184.255’ is ‘abuse@wnet.ua’
inetnum: 92.60.184.0–92.60.184.255
netname: Wnet-Kiev-COLO
descr: Kiev colocation
country: UA
admin-c: WNET2-RIPE
tech-c: WNET2-RIPE
status: ASSIGNED PA
mnt-by: WNET-MNT
created: 2011–01–04T13:40:08Z
last-modified: 2011–01–04T13:40:08Z
source: RIPE
role: W NET NOC
address: Wnet LLC
address: Bohdana Khmelnitskoho 50-b
address: Kyiv, 01030
address: Ukraine
phone: +380 44 5900800
fax-no: +380 44 2892817
abuse-mailbox: abuse@wnet.ua
remarks: troubles: http://support.wnet.ua
remarks: troubles: noc@wnet.ua
Ба, знакомые все лица — это же WNet, которого недавно трусило СБУ ))) Именно тот WNet, которого поймали на левых интернет-канал в Крым. Ну конечно мы верим что это чисто коммерческий контракт был и ФСБ абсолютно никакого отношения к этому интернет-каналу отношения не имел, а WNet никакого сотрудничества с ФСБ РФ не вел ))).
Ау, WNet — неужели мы давали повод считать себя идиотами?
Интелект-Сервис «крест на пузе» клянется, что никаких апдейтов с вирусами он не выкладывал. Окей, я лично — верю. Потому что им и не надо было выкладывать. За них это сделали админы дата-центра WNet.
Они просто в нужный момент перекинули трафик с одного хоста на другой, подставной. Всего на 2–3 часа. А потом вернули маршруты в изначальное состояние. Могли даже перебрасывать не весь трафик, а только тот, который касался выгрузки файлов с завирусяченным апдейтом. Тогда даже статистика запросов к серверу upd.me-doc.com.ua ничего не выдаст.
Итого: идеальное кибер-преступление.
Никаких следов, никаких взломов, никаких логов, предьявлять — нечего.
Идеально, но кроме одной мелочи. Если сопоставить лог обновления медка с зараженного, но восстановленного компьютера, с логами на серверах обновления медка, то легко будет выявить разницу — на бухгалтерском компьютере будут записи о скачке апдейта с вирусом, а на серверах медка таких обращений не будет. А это будет однозначным подтверждением того, что WNet «вмочил свои рога» в эту атаку по полной.
Напомню, что во второй половине марта Украина уже пережила одну атаку вируса XData. И тогда словацкая компания ESet обвинила в распространении этого вируса M.E.Doc через свои апдейты. Подробнее читайте здесь: https://ain.ua/2017/05/24/vse-pro-xdata-poka
Скорее всего то была пробная попытка использовать их сервис обновлений для распространения вируса. После этого они просто решили «поднакопить силы», что бы ударить массово, в строго определенное время.
Источник: medium.com
