Комментарии 74
Это актуальная проблема, и по идее владельцы этих сервисов должны с ней бороться
А владельцы файловых сервисов не могут просто хранить файлы? Обязательно нужно с чем-то бороться, будь то порно, вирусы или ветряные мельницы?
Имхо спасение утопающих - дело рук самих утопающих. И защищать нужно сами устройства. Потому как иначе идельной защитой от вирусов будет отключение от любых сетей
Жопы они свои спасают, а не утопающих. Когда у тебя компания на сотню миллиардов $, и общение с регуляторами, спецслужбами, представителями власти, - это не разовая неприятность, а ежедневная рутина, то важно показывать, что "мы мониторим", "мы боремся", "социальная ответственность для нас не пук"
А владельцы файловых сервисов не могут просто хранить файлы?
А им это не нужно: их бизнес хранить файлы для "обычных" пользователей, а не файлы с вирусами неизвестно для кого. Первое — массовый потребитель с минимумом рисков, второе — нишевый с кучей потенциальных проблем для хостера.
Если вы квартиру сдаёте, вам будет интересно сдавать её мутным личностям, которые занимаются в ней изготовлением каких-то химических веществ? Или предпочтёте сдавать обычному, понятному человеку без домашних животных?
Вопрос предложенной цены
Ставить домашних животных в один ряд с "изготовлением химических веществ" - это сильно.
А им это не нужно: их бизнес хранить файлы для "обычных" пользователей
В недавней истории с фоткой ребёнка для врача тоже видимо было очень много проблем для хостера.
Просто надо признать, что все файлопомойки слишком много на себя берут. Как скоро они начнут заменять файлы на похожие просто потому что "Ваш файл был слишком большой, но мы нашли почти такой же, но поменьше - разницу вы не заметите"
Хотя погодите, кажется одна очень известная компания на этом обделалась ещё года два назад
Просто надо признать, что все файлопомойки слишком много на себя берут
Ну, допустим, признаете, дальше-то что? :) Пока они зарабатывают деньги, у них всё хорошо. Сомневаюсь, что действительно массовому пользователю нужны файлы с вирусами или точные копии файлов. А немассовый пользователь уже не нужен файлопомойкам.
А какая компания 2 года назад обделалась? Очень интересно, расскажите
Apple, с заменой музыки, которую загружали пользователи. Когда кто-то поныл, что ему на основании тегов заменили его live записи на студийные - пошли на попятную. С тех пор я об этом ничего не слышал
Там вроде еще было про удаление музыки с устройств, если она «спираченная». Хотя тоже давно не слышал об этом.
Хотя мб в удалении было про Майкрософт и Windows, я не уверен.
iTunes испокон веков предлагает хранить у себя в медиатеке всю музыку. Спираченная она или нет. Ну и соответсвенно синхронизировать с iPod и iOS устройствами. И никто ничего не удалял. На счёт iTunes Match - то же самое. Apple думала сэкономить место и сделать "хорошо" пользователям (ну мы же берём трек плохого качества (live) и меняем его на трек хорошего качества (студийный), что не так-то?!). В итоге вышло не очень. С пиратством они таким способом не боролись.
Как скоро они начнут заменять файлы на похожие просто потому что "Ваш
файл был слишком большой, но мы нашли почти такой же, но поменьше -
разницу вы не заметите"
Google это и так уже делает примерно с такой же формулировкой ;)
Раньше с Pixel-ов можно было грузить фотки в Google Photo/Drive без лимита и без ограничений по качеству. А сейчас предлагают безлимит, но с пережатием ("но разницы вы не заметите!").
Ага, конечно. Особенно по видео хорошо заметно..
Сдадите мне квартиру? я там кошек разводить буду. И варщики наркоты вам покажутся сказкой
У вас очень странное мышление.
Во-первых, владельцы сервисов хранения работают не из космоса, а почти во всех странах есть какой-никакой контроль за тем, что крутится в интернете.
Во-вторых, как пользователь облачного хранилища, мне было бы приятно узнать, что есть подстраховка со стороны хранилища тоже. То есть я сам "бдю", но где-то могу и "недобдеть".
В-третьих, лишней защиты в интернете не бывает.
А не добавляет ли это ненадежности? Вот загрузил ты в облако какие-то данные, облако решило, что там вирус, и выпилило половину (хорошо еще, если предупредило). А это был не вирус, а очень важные данные, бэкапа которых у тебя по какой-то причине не было.
Как можно доверять хранение чего бы то ни было кому-то, кто полезет копаться в том, что ты у него хранишь?
Тьфу, противно аж видеть такую точку зрения.
Про "чётких пацанов" вы сами придумали - сами оскорбились. Я лишь за то, чтобы каждый занимался своим делом. Файлопомойки - хранили файлы, антивирусы - ловили вирусы, отладчики отлаживали программы.
А то вдруг дебаггер добавит себе антивирусные базы и решит, что больше его нельзя использовать для отладки "неправильных" программ. Ведь иначе получается, что компиляторы и дебаггеры помогают вымогать "деньги с лохов".
А то вдруг дебаггер добавит себе антивирусные базы и решит, что больше его нельзя использовать для отладки «неправильных» программ. Ведь иначе получается, что компиляторы и дебаггеры помогают вымогать «деньги с лохов».
Это slippery slope fallacy (Заблуждение о скользкой дорожке, гуглится). Опять же, исключительно вопрос КПД и количества ложно-положительных срабатываний.
Но это заблуждение работает и в другую сторону. Например, если каждый должен заниматься своим делом и ничем иным, а дело антивируса — блокировать malware, то мы можем придти к выводу-заблуждению, что он не должен блокировать руткиты или любой вирус, у которого есть хоть какой-то шанс не сработать или не навредить. Потому что malware это по определению вредоносные программы, а если факт вреда не доказан или не гарантирован, то это уже и не его дело что-то там блокировать. Мало ли, может это программист написал сюрприз-поздравление своей девушке, а антивирус, такой-сякой, испортил весь праздник.
Ну вообще я регулярно встречаю файлы, которые половина антивирусов считает вредоносными на основании своих эвристик уровня "файл запакован и подписан не Microsoft, а значит это Suspicious.cqweja.Malware". Что бы ни проверял - на virus total найдется какое-нибудь поделие, котрое посчитает что конкретно этот jpeg несёт угрозу моему компьютеру и человечеству в целом.
Но я понял ваш аргумент - может в этом и есть смысл, вот только без процедуры аппеляции это всё очень мутно
Если Proton файлы, как и почту, шифрует еще до передачи на стороне клиента - то проверить и не должно быть возможности. Вот если-бы он предупредил до загрузки - было-бы интересно:)
Кстати, и Mega вроде заявляет о таком-же - шифрование до отправки.
Зачем выгружали зашифрованные запароленные архивы?
В защиту iCloud предположу, что он проверяет только вирусы для своих ос, то есть iOS, macOS, watchOS, tvOS и тд. А судя по статье вы загружали вирусы для винды(?). Собственно основные пользователи данного сервиса яблоководы.
Стоит опробовать данное облако с яблочными вирусами.
Ну не знаю, не могу назвать это прям оправданием, с учетом того, что с iCloud можно скачивать и на винду через браузер. Так что притянуто за уши)
Наоборот хорошо, опять глючная винда завирусилась, а макось работает как часы, перейду на неё навсегда. Ещё длиннее уши, но кто знает, может по этому и не парятся.
Вы удивитесь - есть официальный клиент для винды https://support.apple.com/ru-ru/HT204283
Mega и Proton не знают о том, что Вы загружаете в их облако. По определению, как хранилища с оконечным шифрованием. Файлы зашифровываются на стороне клиента приложением или скриптами браузера.
А как же потом можно скачать по публичной ссылке оттуда?
Ключ в ссылке. Или можно его другим каналом передать, по выбору, тогда придётся вводить при скачивании.
Ну тогда этот ключ знает и сервис, потому что там есть "сделать ссылку"
Ключ на сервере лежит зашифрованый, он расшифровывается на клиенте с помощью пароля пользователя, который он вводит при логине. Ну или с помощью другого ключа, который лежит в local storage или еще где-то.
Судя по хелпу меги, там есть
1) folder links, то есть мы публикуем ссылку на папку - и все желающие могут скачать файлы из папки.
Если на стороне меги не хранятся нешифрованые файлы - это получается что у всех файлов в папке один ключ шифрования.
2) shared folders (между пользователями меги) - что будет с ключами на файлы у таких папок? Общий на всех пользователей, втч на тех, кого пригласили позднее?
Что-то тут не бьется совсем.
Не знаю как именно работает мега, но такое тоже можно реализовать без необходимости хранения ключей в открытом виде на серверах меги. Например можно иметь ключ на папку, с помощью которого можно расшифровать ключи для отдельных файлов. Этот же ключ передавать в ссылке для доступа к папке и/или во время расшаривания папки с другими пользователями.
А вы сами это проверяли или просто верите их маркетологам?
Откройте консоль браузера, когда загружаете файл. Ким Дотком весьма гордился в своё время реализацией AES в js. Ну и уж кого-кого, а этого криптоповстанца при его истории борьбы с ФБР и феерическим побегом из США в выдаче данных сложно упрекнуть.
https://mega.nz/SecurityWhitepaper.pdf
В Proton специально не проверял, диском их не пользовался. Если есть желание, то вот
Но там 142 репозитория, чёрт голову сломит.
То есть второй вариант. Вопросов больше не имею. Почитайте на досуге:
https://habr.com/ru/post/168025/
http://master-gadgets.ru/portal-mega-udaljaet-zakonnye-polzovatelskie-fajly
продолжайте верить.
Могли конечно решить сверкой хэшей, но если хэши видят, то и о файлах знают достаточно.
Для распаковки архивов нужны огромные ресурсы.
То-то у нас сжатие по умолчанию в любом HTTPS соединении.
я про перебор, даже по словарю, ВСЕХ архивов ВСЕХ пользователей, которые что-либо аплоадят. Вдобавок deflate это очень простой и быстрый алгоритм в отличие от того, что используется в 7zip и winrar по умолчанию
Тут не только сжатие, но и расшифровка. Она конечно тоже довольно легкая — при условии, что вы знаете ключ, а не делаете сотни тысяч попыток его подобрать :р
Можно сказать, что наиболее точным оказался антивирусный сканер, встроенный в Google Drive
Может потому, что Гугл купил VirusTotal много лет назад?
Автор провел большой объем изрядно пустой работы:
архивирование вирей. В давние времена была интересная игрушка: берется файлик, копируется в несколько десятков экземпляров и сжимается архиватором, после чего с получившимся архивом повторяется операция... и так несколько циклов. т.к. разнообразие данных не велико сжимаетс очень эффективно. И скидывается жертве по почте. Жертва его скачивает, антивирус начинает лезть в архивы, распаковывая все это, кушает много памяти и ... комп встает. У многих антивирусов тогда появился порог вложенности архивов, если не ошибаюсь у каспера он по умолчанию был 3. Это можно было бы проверить, на какую вложенность он реагирует. Опять же вопрос, какой архиватор используется, тот же tar в виндовой среде не очень понимается...
архивирование с паролем. Тут все совсем жутко.. Антивирусное ПО работает по сигнатурам, и любого рода шифрование не позволяет применить данный подход... иными словами, сработка это случайность. Есть еще механизм "песочницы", но для него так же нужно предварительно расшифровать файл, а только потом запустить и наблюдать. Вы полагаете, что владелец облака будет расходовать ресурсы на пробручивание пароля архива чтобы слазить в него антивирусом? если на той стороне пароли брутят, то скорее всего они решают задачи не хранения информации, а несколько иные.
Данные в ЦОД периодической проверке не подлежат, да и на домашних ПК это постепенно отмирает. Проверка в большинстве случаев происходит на момент "касания" данных, т.е. в момент чтения или записи. Причины описывать смысла нет, оно на поверхности. Но смысла выжидать неделями побьются ли данные точно не было.
Раз уж речь зашла про вложенные архивы, можно ещё проверить сервисы на устойчивость к zip-бомбам: нерекурсивным (когда небольшой файл распаковывается в 4.5 петабайт мусора) и рекурсивным (размер не ограничен)...
Как указано в статье, в заголовках запароленного архива содержатся CRC файлов, по которым можно опознать вирус, не расшифровывая его.
Что такое CRC? Это не более чем контрольная сумма для проверки целостности. Множество различных файлов могут иметь абсолютно одинаковые контрольные суммы. Ко всему прочему сигнатура в большинстве случаев имеет описание не всего вредоносного кода, а типичного участка, соответственно один и тот же вирус, скомпилированный разными версиями компилятора может иметь разные CRC.
Подобного рода аналитика возможна, но она однозначно малоэффективна и может указать лишь на вероятность наличия вредоноса, ни о каком принятии решения на основе этих данных речи быть не может.
При всем при этом, проблемные файлы в Dropbox никак не помечаются, так что я не смог подсчитать, сколько семплов распознала встроенная защита.
О, это как раз было причиной почему мы в компании отказались от Dropbox несколько лет назад. В какой-то момент тоже вылезло такое предупреждение, полагаю был какой-то false-positive, потому что экзешников или архивов с экзешниками в общей шаре никогда не было. Зато был доступ к техподдержке, правда за 2 недели они так и не смогли мне назвать проблемный файл, были лишь стандартные отписки вида "наша система обнаружила у вас проблемные файлы, просканируйте ваш каталог Dropbox антивирусом". Так что техподдержка бы вам не помогла, просто этот "сервис" надо обходить стороной.
А на моем личном аккаунте публичные ссылки перестали работать из-за превышения лимита по трафику, но узнать какой же файл сгенерировал этот трафик тоже было невозможно :)
Внимание! За распространение вредоносного ПО грозит уголовная ответственность. Описанные ниже действия не имели целью распространение вредоносного ПО и нанесение вреда кому-либо
Для уголовной ответственности совершенно не важно, какой у вас была цель - если бы закон в РФ применялся не избирательно, то тут написано достаточно для возбуждения дела в отношении ваших сотрудников.
Ну а если бы законодатель в Думе таки думал (головой, а не игрой doom), то соответствующая норма закона была бы сформулирована адекватно, а не как квинтэссенция страхов человека, опасающегося любого устройства сложнее утюга.
Интересная информация, интересно что с обычными кодами будет (хотя оно синхронизируется у меня и вроде все норм).
Непонятно - зачем надо было загружать запароленные архивы? Разумеется, ни один сервис, не зная пароля, их не откроет (не будет же он перебирать пароль, который может быть каким угодно).
Имя файла ничего не значит, его можно переименовать. Размер файла - можно удлинить до любого. Контрольная сумма - это просто математическая сумма всех слов, а в EXE полно неиспользуемых полей, так что контрольную сумму файла можно сделать какой угодно.
Считай что облачное хранилище не знает ничего о содержимом запароленного архива, все что оно может сделать - запретить вообще загружать или скачивать такие архивы, но никак не проверить на вирусы.
"Mega, Amazon Drive, iCloud, Proton Drive, Box". Теперь понятно где лучше хранить файлы. В частности Google Drive мне пару раз не давал скачать файл потому что там якобы был вирус. Это был бэкап сделанный программой в зашиврованном виде. Отчего стало понятно что GDrive для бэкапа не годен. В другом случае также он мне не дал скачать из своего же хранилища (как и в первом случае) бэкап APK файлов с телефона. Так что нет, это их борьба с вирусами наоборот мешает. И эти оьлака себя характезирует в данном случае положительно как раз.
Как Gdrive залез в зашифрованный архив и нашёл там вирус?
даа.. я что-то не совсем то написал. виноват. нет, пароля на нëм не было. это был бэкап TitaniumBackup вообщем. т.е. он делал бэкап и потом всë это синхрил в облако. и вот этот сделанный им бэкап я однажды когда мне понадобилось, я не смог польностью скачать, некоторые файлы GDrive не отдавал говоря мол там вирус.
Было бы корректно указать, что компания Бастион (автор поста) и Лаборатория Касперского (которую истпользуют Mail.ру/VK) - официальные партнёры.
В то же время эта статья написана до того, как мы запартнерились с Лабораторией Касперского, и это далеко не единственный вендор, с которым мы сотрудничаем.
Никакой ангажированности. Если кому то в ближайшее время придет в голову повторить описанное самостоятельно, (лично я не рекомендую этого делать), он придет к схожим выводам.
Я загрузил 4000 вирусов в разные облачные хранилища, и вот что из этого вышло