Решил поковыряться в сетевой структуре сервиса 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 через свои апдейты.

Скорее всего то была пробная попытка использовать их сервис обновлений для распространения вируса. После этого они просто решили «поднакопить силы», что бы ударить массово, в строго определенное время.

Присоединяйтесь к группе Другой Взгляд на Facebook а также к каналу в Telegram и следите за обновлениям

Sergey Prach