LINUX.ORG.RU
ФорумTalks

[вирусы] [Linux] [вещества] вариант реализации

 , ,


0

2

Вот моя идея заражения типичного GNU/Linux вирусом:

1) пользователь качает гадость, запускает ее от простого пользователя

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

3) гадость создает alias su=~/.virus/su_wrapper (ну и аналогичные для sudo и прочей гадости, дающей права рута).

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

Если был вызов

su -c "mycmd"
То враппер должен вызвать
/bin/su -c "/home/user/.virus/virus && mycmd"
Таким образом, даже не выбивая из юзверя пароль, вирус получит рут-доступ. А с рут-доступом можно делать что угодно.

Почему это еще никто не реализовал?

PS. Если кому интересно, могу привести код joiner-а (клеилки бинарников) и, собственно, su_wrapper-а.

Deleted

Насчет первого пункта. Проще реализовать через pre-install script deb-пакета, он запускается с правами рута при установке пакета.

firestarter ★★★☆
()
Ответ на: комментарий от geekless

K.O.: гадость будет склеена joiner-ом с не-гадостью :) многие (по крайней мере знакомые) пользователи линукса тоже качают всякую фигню с левых источников.

Deleted
()
Ответ на: комментарий от dikiy

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

arknir
()
Ответ на: комментарий от geekless

> после того, как он уже сольёт из твоего хомяка всю интересную для злоумышленника информацию

Надо быть просто феерическим дятлом, чтобы важную информацию хранить в $HOME

fang
()
Ответ на: комментарий от Deleted

Скрипты обычно. Их весьма просто проверить, достаточно уметь читать.

arknir
()
Ответ на: комментарий от fang

А где ты хранишь куки, пароли и историю посещений для твоего браузера? :)
Или результаты научной деятельности, которую хочет украсть твой коллега из лаборатрии напротив.

arknir
()
Ответ на: комментарий от arknir

> А где ты хранишь куки, пароли и историю посещений для твоего браузера? :)

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


В /media/c/Document\ and\ Settings/admin/Мои\ документы же наверняка.

geekless ★★
()
Ответ на: комментарий от x3al

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

Ага, и можно еще одну штуку сделать - враппер для ssh, который бы подсовывал комманды для скачки и запуска вируса. То есть, вы коннектитесь к своему VPS по ssh, и ваш VPS заражается вирусом тоже.

Deleted
()
Ответ на: комментарий от fang

>> после того, как он уже сольёт из твоего хомяка всю интересную для злоумышленника информацию

Надо быть просто феерическим дятлом, чтобы важную информацию хранить в $HOME

А где ее хранить, умник? Или для тебя важная информация ограничивается номером твоей кредитки и паролем к почте?

dikiy ★★☆☆☆
()
Ответ на: комментарий от Andru

Можно и за пределы: ВНЕЗАПНО Linux тоже поддерживает автораны с флешки, а хомячки любят их запускать, даже не зная, что они делают.

Ну и упомянутый немного ранее метод с ssh. А еще можно поизвращаться с заражением Samba-шар, тыриньем FTP-паролей и т.д. и т.п.

Deleted
()
Ответ на: комментарий от Deleted

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

Да вот как раз я скорее снесу все остальное, чем хомяк. Долго ли чтоли пакеты/систему переставить? У меня хомяк с 2002 года неприкосновенен )

dikiy ★★☆☆☆
()
Ответ на: комментарий от geekless

Метод с ssh я уже привел. Можно искать незапароленные Samba шары, подменить curl и wget для тырения паролей ftp и еще много чего сделать.

Deleted
()
Ответ на: комментарий от arknir

> А где ты хранишь куки, пароли и историю посещений для твоего браузера? :)

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

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


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

fang
()
Ответ на: комментарий от dikiy

О да, понимаю. У меня вчера после небольшого перекраивания диска в начале хомяка вылез кусок суперблока старой ext4. Пришлось всё утро hexeditor'ом искать какой же там теперь офсет, чтобы смонтировать :(

arknir
()
Ответ на: комментарий от geekless

С первыми 2 пунктами согласен. 3-ий немного не понял. Хотя все равно среднему гику обычно ничего не грозит.

Deleted
()
Ответ на: комментарий от dikiy

> А где ее хранить, умник?

Проблемы с хранением СВОИХ данных решай сам, ок?

fang
()
Ответ на: комментарий от xscrew

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

Deleted
()
Ответ на: комментарий от arknir

> Так и я хомяк отдельно монтирую

А вот $HOME как раз на рутовом у меня. И там один хлам, которого ни капли не жалко.

fang
()
Ответ на: комментарий от geekless

И багов в ПО тоже не существует. И сервера в интернете никто не ломает. Да вообще, интернет — это фантастика.

Что за детский сад?

Баги - немного другое.

А при правильной параноидальной защите или адекватном пользователе моя идея обламывается.

Deleted
()
Ответ на: комментарий от firestarter

>Насколько я знаю, в рра можно загрузить только исходники. Они собираются там.
Можно собрать пакет и из бинарников же.

x3al ★★★★★
()
Ответ на: комментарий от arknir

какая-то выгода все же есть. когда линукс станет распространенным, если станет, то у тебя уже будут готовые решения.

derlafff ★★★★★
()
Ответ на: комментарий от adepto

Во-первых, M$ выпускает достаточно security-релейтед апдейтов. В «конструктивно безопасном» линуксе их, впрочем, тоже немало.
Во-вторых, для нормального кейлоггера в венде нужны права рута (обычный кейлоггер не работает в той же сессии в софте, запущенном от другого пользователя). А в иксах любой процесс может слушать весь ввод. Включая ввод пароля для sudo/рута и весь ввод в окнах рутовых приложений. И это принципиальная фича «конструктивно безопасных» иксов (которым в ближайшее время альтернативы не намечается).

x3al ★★★★★
()
Ответ на: комментарий от derlafff

derlafff

И почему не поправил когда правил?

Я думаю, что они думают, что мы и правда думаем (ц)

Не поправил специально, чтобы было удобнее засылать вирус. Очевидно же.

vurdalak ★★★★★
()
Ответ на: комментарий от x3al

> Во-первых, M$ выпускает достаточно security-релейтед апдейтов.

security апдейты никак не закроют принципиальные дыры архитектуры.

А в иксах любой процесс может слушать весь ввод. Включая ввод пароля для sudo/рута и весь ввод в окнах рутовых приложений. И это принципиальная фича «конструктивно безопасных» иксов (которым в ближайшее время альтернативы не намечается).

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

geekless ★★
()
Ответ на: комментарий от geekless

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

дыры в винде

[Citation needed]

x3al ★★★★★
()
Ответ на: комментарий от derlafff

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

x3al ★★★★★
()
Ответ на: комментарий от x3al

> И убедить авторов _всех_ иксоприложений его заюзать.

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

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

geekless ★★
()
Ответ на: комментарий от geekless

>право слушать события на определённых окнах
Есть ещё такая вещь как опрос состояния клавиатуры. Окна при этом не нужны.

x3al ★★★★★
()
Ответ на: комментарий от x3al

зато это делает вендовые компьютеры в целом более уязвимыми.

derlafff ★★★★★
()
Ответ на: комментарий от x3al

> http://insecure.org/sploits/xsecurekeyboard_fequent_query.html

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

Что нужно предусмотреть, так это возможность передачи токена для приложений, которым граббинг _действительно_ нужен вне зависимости от активного окна — оконного менеджера, менеджера хоткеев и других приложений, которым пользователь 100% доверяет. Мне кажется, при правильно проектировании системы прав доступа и механизма для работы с ней, это вполне возможно.

geekless ★★
()

облом.

вирус - это то, что распространяется (размножается, копируется) само, без участия пользователя.

n_play
()
Ответ на: комментарий от geekless

>Достаточно не возвращать актуальное состояние клавиатуры по вызову XQueryKeymap, если данный клиент не имеет токена для окна, которое имеет фокус ввода.
Интересно, что это сломает.

менеджера хоткеев

Хочу такое приложение. Естественно, я не про xbindkeys.

x3al ★★★★★
()

>2) гадость пытается заразить найденные бинарники в хомяке пользователя

И много у тебя бинарников в хомяке?

luke ★★★★★
()
Ответ на: комментарий от luke

У меня - ни одного. Смотреть следующие пункты - для них наличие бинарников в хомяке не принципиально.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.