Вредоносное по для линукс

Опасные вирусы для Linux

С давних времен между пользователями ходят споры есть ли вирусы для Linux и если есть, то стоит ли использовать антивирусы на своем компьютере. Операционная система Linux спроектирована таким образом, чтобы быть максимально безопасной и защищенной от вирусов.

Она действительно намного безопаснее Windows и менее подвержена атакам вирусов и вирусам. Но разработчики — тоже люди и иногда они ошибаются. Из-за недосмотра или еще по каким-либо причинам в системе появляются уязвимости, которые могут быть использованы вирусами. В наши дни Linux стремительно набирает популярность. Если на персональных компьютерах она используется не так часто, то на серверах Linux занимает лидирующие позиции, а теперь еще и на различных IoT устройствах, которых становится все больше.

Хакерам становится все выгоднее делать вирусы для Linux. Ими сложнее заразиться чем в Windows, и в большинстве случаев они используют уже устраненные в новых версиях linux и всем известные уязвимости для проникновения в систему, а также недочеты в настройке.

Так что если ваша система правильно настроена и вовремя обновляется, то вам нечего бояться. Но многие IoT устройства, роутеры или серверы долго не обновляются, и именно они становятся жертвами таких вирусов. В нашей сегодняшней статье мы рассмотрим самые опасные вирусы для Linux, которые появились за последние несколько лет.

1. Linux.Encoder

Linux.Encoder известный, как первый шифровальщик для операционных систем на базе ядра Linux. Распространение вируса началось 5 ноября 2015 года. Используя различные уязвимости в системе вирус шифровальщик linux проникал на сервер и зашифровывал все доступные для записи файлы с помощью симметричного шифрования AES и RSA.

Открытый ключ, которым было выполнено шифрование доступен всем, а вот за закрытый, нужный для расшифровки, злоумышленники требовали деньги в валюте bitcoin. Основным путем для проникновения в систему для этого вируса была уязвимость в популярной CMS для создания онлайн магазинов — Magento. Естественно, уязвимость была давно закрыта, но не все небольшие ресурсы установили обновление, за что и поплатились.

Было обнаружено несколько версий вируса Linux.Encoder.0, Linux.Encoder.1 , Linux.Encoder.2. Но для всех из них со временем были найдены способы расшифровки файлов.

2. Linux.Mirai

Первая версия Linux.Mirai была обнаружена в мае 2016. У него совсем другая специфика работы. Вирус не причиняет вреда владельцу устройства и пытается остаться незамеченным. Он нацелен больше на IoT устройства, под управлением Linux, которые подключены к сети интернет и использует их для осуществления DDoS атак. Пользователь, скорее всего, ничего не заметит кроме существенного снижения пропускной способности сети.

Попадает вирус на машину путем совсем простым. Он ищет устройства на которых работает служба telnet с доступом без пароля или паролем по умолчанию. Linux.Mirai находится на устройстве до перезагрузки. Но если логин и пароль telnet не были изменены, то устройство будет инфицировано снова.

Этот вирус еще известен под именами Bashlite, GayFgt, LizKebab, Torlus, Bash0day и Bashdoor. Именно с помощью ботнена, организованного этим вирусом были осуществлены несколько нашумевших DDoS атак этой осенью. Как бы то ни было, но успех Mirai вдохновил хакеров разрабатывать другие linux вирусы, для организации DDoS атак.

3. Linux.NyaDrop

Это еще один троян, который инфицирует IoT устройства под управлением Linux точно так же, как это делает Mirari. Он не просто ищет устройства без пароля, но и пытается перебрать самые часто используемые пароли для telnet, чтобы попасть на устройство.

Работает вирус немного другим образом, после проникновения на устройство, он загружает исполняемые файлы бэкдора, который позволяет получить удаленный доступ к устройству. Пока что инициируются только роутеры на архитектуре MIPS, но в будущем вирус может расширить круг своих жертв. Хакеры смогут использовать зараженные устройства не только для DDoS атак, но и, например, в качестве прокси.

4. Linux.BackDoor.Gates

Этот троян для Linux был обнаружен еще в мае 2014. Он атакует устройства, под управлением 32 битной версии операционной системы Linux. Вирус состоит из двух частей, бэкдора, который позволяет злоумышленникам выполнять на вашем компьютере необходимые ему команды, а также DDoS бота. Основное предназначение, как и у двух предыдущих — проведение DDoS атак.

В процессе работы вирус передает злоумышленникам много данных о вашей системе, среди них: количество ядер, скорость CPU, использование CPU, MAC адрес, информация о сетевых интерфейсах, объем памяти, объем передаваемых и получаемых данных.

5. Linux.Lady

Еще один троян для операционных систем семейства Linux обнаруженный в октябре 2016. Он написан на новом языке, разработанном в корпорации Google. Он заражает серверы через неправильно настроенную программу Redis. Троян способен сам распространяться от машины к машине и постоянно исследует сеть на наличие уязвимых компьютеров.

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

6. Linux.DnsAmp

Этот троян для Linux был обнаружен еще в 2014 году, он может заражать как 32, так и 64 битные системы Linux. После заражения вирус прописывает себя в автозагрузку через /etc/rc.local и начинает ожидать команд от сервера. Основная цель вируса — участие в DDoS атаках.

Попадая на вашу машину, как и другие linux вирусы, он отправляет на свои сервера информацию о ней, например, объем памяти и количество swap пространства, а также другие характеристики.

7. Linux.Hanthie

Троян для Linux, обнаруженный еще в 2013 году, сам распространяться не умеет, но может попасть на компьютер путем социальной инженерии. После запуска прописывается в автозагрузку и пытается подключить свою библиотеку ко всем процессам.

Вирус подключается ко всем браузерам и следит за трафиком HTTP и HTTPS перехватывая и отправляя злоумышленникам данные форм, которые заполняет пользователь. Также он предоставляет злоумышленникам доступ к вашей системе и имеет средства защиты от антивирусов и обнаружение запуска в виртуальных окружениях.

8. Linux.Myk

Еще один троян для операционных систем Linux, созданный китайскими программистами. Как и Mirori, этот вирус предназначен для организации DDoS атак, но также может предоставить злоумышленнику доступ к вашему компьютеру. Характерная особенность этого вируса в том, что он способен отключать брандмауэр. Инфицирование осуществляется с помощью социальной инженерии. Впервые вирус был обнаружен весной 2015.

9. Linux.Rex

В 2016 году появилось несколько вирусов для Linux, написанных на новом языке от Google — Go. Вирус инфицирует сервера, под управлением различных систем управления контентом, используя обнаруженные в них уязвимости. Он может рассылать электронные письма и самостоятельно искать уязвимые сервера. Чаще всего вирус заражает серверы с Durpal, WordPress, Magento, JetSpeed, в которых не исправлены уязвимости. В WordPress вирус пытается использовать уязвимые плагины WooCommerce, Robo Gallery, Rev Slider, WP-squirrel, Site Import, Brandfolder, Issuu Panel и Gwolle Guestbook. Для сайтов Magento используются уязвимости CVE-2015-1397, CVE-2015-1398 и CVE-2015-1399.

Он используется злоумышленниками для организации DDoS атак, способен собирать доступную информацию о сервере, в том числе логины и пароли пользователей. Также вирус рассылает email сообщения с угрозой DDoS атаки и требует выкуп.

10. Linux.Sshcrack

Эта вредоносная программа пытается заразить как можно большее количество устройств путем перебора паролей ssh. Когда программа получает доступ к новому компьютеру, она запускает на нем 200 потоков, выбирает случайный адрес и пытается перебрать ssh пароль для него. Перебор осуществляется по словарю, в котором есть более 10000 значений.

11. Linux.Rekoobe

Этот простой вирус для Linux был обнаружен в ноябре 2015. Он способен выполняться на машинах с архитектурой x86 и x64, хотя изначально был разработан только для SPARC. Вирус распространяется путем социальной инженерии, и может даль злоумышленнику доступ к вашему компьютеру, а также способен загружать на ваш компьютер различные файлы и передавать команды интерпретатору команд linux.

12. Linux.Ellipsis

Этот вирус создает на инфицированном сервере или компьютере с операционной системой Linux прокси-сервер, с помощью которого злоумышленник может делать нужные ему действия в сети и оставаться незамеченным. Вирус распространяется путем перебора логина и пароля к службе удаленного доступа — ssh.

В процессе работы вирус отключает iptables и мешающие ему программы, ведение логов. А также передает контроль над вашим компьютером злоумышленникам.

13. Linux.Ekoms

Этот вирус под Linux передает злоумышленникам снимки вашего экрана каждые 30 секунд. Также может загружать на сервер содержимое папки /tmp. Кроме снимков экрана, вирус может записывать звук. Заражение машины, как и во многих других способах выполняется путем социальной инженерии.

Выводы

Как видите, вирусы и операционные системы linux, вещи все же совместимые. За последнее время их появилось очень достаточно много. Другое дело, что они ориентированны, либо на уязвимые и не обновляемые системы, IoT устройства, или социальную инженерию. Это не повод ставить антивирус, но это не значит что нужно терять бдительность и расслабляться. Не забывайте обновлять свою систему вовремя, особенно если у вас есть сервер. А как вы относитесь к вирусам в Linux? Напишите в комментариях!

Источник

Вредоносное ПО для GNU/Linux и борьба с ним

Проблемы

ПО для GNU/Linux, как и ПО для любой другой ОС, содержит уязвимости и с этим ничего не поделаешь. Не так давно мне попадалась новость про найденную уязвимость в каком-то плеере или библиотеки с кодеками (точно не помню, не суть важно). Уязвимость позволяла выполнить произвольный код при обработке специально сформированного файла. Да что далеко ходить, можно для примера взять хоть Flash, не важно.

Допустим у нас есть жутко уязвимый плеер, при открытии специального файла в нем выполняется произвольный код. Что такой код сможет сделать? Если нет каких либо уязвимостей в ядре (или в других важных компонентах) позволяющих повысить права, то напакостить он сможет только в пределах домашней директории. Но ведь именно в домашней директории и есть самое ценное (да, про бекапы я помню). Т.е. возможно испортить/удалить файлы пользователя, сделать из компьютера пользователя бравого бойца какого нибудь ботнета, слить ценную информацию (пароли, документы, т.д.). Испортить остальную систему, навредить другим пользователям, сделать серьезный LinLock (который будет не просто удалить) уже не получится.

Сможет ли код остаться в системе? Пусть /home смонтирован с опцией noexec, но у злоумышленника остается возможность использовать скрипты. Вредоносному коду ничто не помешает создать файл

/.config/long/path/hard/to/find/zlovred.py и дописать в .profile его автозапуск. А еще можно прописать зловреда в

/.config/autostart, а может и еще куда, я думаю что места найти можно.

Т.е. нагадить один раз в домашней директории можно, прописаться в автозапуск и гадить часто тоже можно, например на флешки. Кстати о флешках. Допустим уязвимость не в плеере, а в библиотеке, которая кроме всего прочего используется каким нибудь thumbnailer’ом для создания превьешек видеофайлов. Пользователь вставляет флешку, открывает ее nautilus’ом, nautilus запускает вспомогательный процесс для создания превью… Все, зловред в системе, т.е. и кликать никуда не надо, вставил флешку — получил вирус.
Если я что то упустил или не учел, то прошу прокомментировать. Если вышеописанное не получится, то что помешает испортить пользователю счастливую жизнь через уязвимость во Flash при заходе на вражеский сайт?

Да, Linux не так распространен, существует зоопарк дистрибутивов и вирусописателю придется учитывать кучу нюансов, но если захотеть, то ведь можно. Сейчас Linux не очень популярен, что будет когда наступит ОН популярность возрастет? владельцы ботнетов откажутся от увеличения их численности из-за того что для Linux создать зловреда несколько сложнее? Мне так не кажется.

Что делать?

Антивирусы для Linux? No way!

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

Что нужно (можно) плееру? Ему нужно только читать файлы, писать в

/.config/player, открывать URL, если он это умеет. Все остальное не нужно, точнее низяаааа (голосом Полунина). Flash’у и того меньше, только сеть и какой нибудь

/.config/adobe/flash (или где оно там?). Возможно требуется еще несколько директорий, например для временных файлов, но все это четко ограничивается.

Так что же делать? Средства принудительного контроля доступа уже есть — SELinux и AppArmor. Только как мне кажется, их не мешало бы доработать. Например AppArmor (С SELinux знаком поверхностно… Может там уже все хорошо?), там для каждого приложения, которому надо урезать права, надо написать специальный конфиг и положить в /etc/apparmor.d/. Как мне кажется, такой подход не достаточно гибкий (Насколько я знаю, в SELinux тоже не гибкий). Не хватает возможности создания таких профилей «на лету», без прав суперпользователя. А именно:

1. Интерфейс создания профиля безопасности приложения из самого приложения
2. Интерфейс для запуска приложения с указанным профилем
3. Возможность назначить приложению привилегии для редактирования профилей других приложения «на лету», т.е. изменения уже примененных профилей
4. Шаблоны профилей, изменения в формате исполняемых файлов, возможно изменение пакетов

Например, запускается тот самый дырявый плеер. Первым делом процесс плеера через специальное API применяет для себя ограничивающий профиль. Т.е. разработчик плеера явно должен добавить в него соответствующий код со списком требуемых приложению прав. Что-то типа «можно читать все файлы, можно писать в свой конфиг, все остальное нельзя». Т.е. данный метод для сознательных разработчиков, которые знают что их приложение может содержать баги и хотят ограничить систему от действий своей программы. Или соответствующий код может быть добавлен в рамках какого либо дистрибутива. Да, надо будет править код, но правок будет не много. Таким образом права можно будет урезать, но не повысить (как и есть в AppArmor), кроме того данный механизм должен позволять только однократное применение профиля, т.е. если приложение будет взломано, то уже ничего изменить будет нельзя. Такой профиль безопасности можно будет применять сразу после запуска, или не сразу, например, до применения приложение может прочитать/записать какие-то фалы, которые в дальнейшей работе уже не потребуются.
Когда применять профиль решает разработчик.

Не ко всем приложениям таким образом можно применить профиль, например, с приложениями с закрытым кодом будет проблема. Кроме того, может возникнуть ситуация, когда в зависимости от контекста запуска нужно применять различные профили. Именно для этого и требуется механизм номер два. С помощью него приложение может запустить другое приложение с указанием профиля. На мой взгляд, самый подходящий пример это браузер и плагины. Flash, java-аплеты, Silverlight и другие плагины при запуске получают профили безопасности, ограничивающие их права. Пусть Flash будет трижды дырявым, пусть в нем будет ActionScript API для доступа к файловой системе, сделать он ничего не сможет.

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

/Downloads, но это будет безопасностью в ущерб удобству. Какому нибудь редактору в принципе нужна возможность прочитать и записать любой файл. В этом случае нам поможет пункт номер три. Диалоги открытия и сохранения файлов нужно вынести в отдельные процессы, а в, например, /etc/apparmor/trusted_programs прописать что /usr/bin/gtk-open-dialog и /usr/bin/gtk-save-dialog могут изменять «на лету» профили других, уже запущенных приложений (к примеру через /proc/[pid]/aa_profile). Естественно, можно редактировать профили приложений только того же пользователя, от которого запущены и сами специальные программы (диалоги открытия и сохранения).
Запускается браузер, к нему применяется профиль, ограничивающий все и вся. Когда браузеру надо будет сохранить скачиваемый файл, то он запустит gtk-save-dialog (естественно, для kde нужна будет своя штуковина). Пользователь явно выберет имя файла для сохранения. Gtk-save-dialog внесет соответствующее исключение в профиль процесс браузера и вернет браузеру имя файла. Таким образом приложение сможет читать и писать только те файлы, которые явно разрешил пользователь. Приложению можно будет запретить читать и сами директории, чтобы не было возможности получить список файлов (хотя, получение списка файлов достаточно безопасно, я думаю). Так же можно поступить и с офисными программами (да и многими другими). Пусть в текстовом процессоре разрешены все макросы и прочие небезопасные вещи, испортить что либо будет невозможно, разве что сами офисные документы, и то только те, которые уже открыты в данный момент. Для пользователя все останется как и было, те же программы, те же диалоги, ничего нового, никаких неудобств. Для программиста тоже можно обойтись без изменений, все тот же вызов функции показа диалогового окна. Надо будет только подправить библиотеки виджетов (Gtk,Qt. )

Остался четвертый пункт. Зачем он нужен? Нужен он для безопасного запуска приложений из непроверенных источников. Вот когда наступит ОН GNU/Linux станет более популярным и под него будет множество приложений, вот тогда и понадобится четвертый пункт. Как правило, в GNU/Linux приложения из проверенных источников — репозиториев, но бывают ситуации, когда надо поставить приложение из непроверенного источника. Четвертый пункт заключается в следующем: система содержит шаблоны профилей безопасности, они стандартны; исполняемый файл содержит название/id профиля. При запуске приложению применяется профиль, если приложение не содержит id/название профиля или ему требуются потенциально опасные права, то пользователю выводится предупреждение. Таким образом пользователь сможет скачивать и запускать большое количество приложений из непроверенных источников, конечно, системные приложения сюда не относятся, т.к. им понадобится множество потенциально опасных привилегий. Всякую мелочь, типа игр, небольших утилит, скринсейверов и т.п. можно будет спокойно запускать, при этом, если приложение не требует каких-то особых прав, то пользователя можно вообще не уведомлять («Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»), а сразу запускать. Почему шаблоны и названия/id профилей, а не просто профили безопасности непосредственно в исполняемых файлах? Потому что, тогда будет нужен парсер, который будет проверять профиль и выдавать заключение о его безопасности, а это время при запуске, кроме того исключается атака на ядро через профиль безопасности из непроверенного источника (мало ли чего там понаписали… и у ядра будет DoS). Все это, насколько я могу судить, напоминает работу с приложениями для мобильных устройств.

Зачем я это написал?

Просто изложил свои мысли и мне интересно обсудить тему безопасности в GNU/Linux, что я и предлагаю сделать в комментариях. Конечно я не описал ничего принципиально нового, но некоторые идеи описанные здесь мне нигде не встречались (например, вынесение диалогов открытия и сохранения в другие процессы), может быть это действительно будет полезной идеей. Почему я не бросился писать патчи для ядра, а написал топик на хабре? К сожалению мои знания C, а уж тем более ядра, оставляют желать лучшего. Кроме того, есть мысль обсудить изложенные идеи, и возможно, написать об этом на Ubuntu Brainstorm (Я туда писал пару строчек на эту тему, но они остались почти без внимания, может быть потому, что у меня английский так себе, а может быть это никому не надо. Найду ссылку — добавлю сюда) или подобный ресурс.

P.S. Не уверен, что я выбрал подходящий блог для написания данного топика. Если ему не место здесь, то перенесу.

[update 1]
Небольшое дополнение 1:
То что я тут описываю — дополнения к существующему AppArmor. API для создания профиля из самого приложения не замена профилям AppArmor, которые сейчас существуют в текстовых файлах, а дополнение.
Мне кажется что может быть полезно в некоторых случаях:
— Одно приложение смоет работать с разными профилями в зависимости от использования, т.е. по разному урезать права самому себе.
— Урезать права можно будет не сразу после запуска, а несколько позже.
Например отработал полностью проверенный и вылизанный участок кода, которому нужны большие права, дальше права приложению не нужны и они урезаются.
Т.е. это дополнение которое добавляет гибкость, а не замена.

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

Небольшое дополнение 3:
Как и в случае классического AppArmor эта система прав будет менее приоритетна чем классическая система прав. Т.е. если самому пользователю что-то нельзя, то и всем приложениям это нельзя вне зависимости от их профилей.

[update 2]
Оказывается в Mac OS X разрабатывается нечто подобное.
techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology
developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html
Спасибо int80h’у за ссылки.
Кстати, там есть возможность ограничивать права из самого приложения через специальный API, как описано у меня и о чем в комментариях пишут «нафиг не надо».

Интересно, а для Windows уже есть что-то подобное?

Источник