На ряде web-серверов обнаружен (https://threatpost.com/en_us/blogs/new-linux-rootkit-emerges...) новый руткит, используемый для скрытной подстановки вредоносных вставок в отдаваемый сервером HTTP-контент. Руткит поражает 64-разрядные Linux-серверы, работающие под управлением Debian Squeezy с ядром 2.6.32-5-amd64. После активации в ядро системы загружается специальный модуль, скрывающий следы присутствия руткита и осуществляющий подстановку в генерируемый локальным web-сервером HTTP-трафик iframe-блоков с кодом для эксплуатации уязвимостей в клиентских браузерах и установленных в них плагинах.
В отличие от обычно применяемой техники внедрения вредоносного кода в хранимые на сервере html-страницы, руткит позволяет оставить файлы в неизменном виде, осуществляя подстановку на стадии отдачи контента http-сервером. Так как компоненты руткита маскируются и скрытваются от средств мониторинга, на первый взгляд вредоносная активность отсутствует. Наиболее важным выводом является то, что выявленный руткит является принципиально новой разработкой, не основанной ни на одном из ранее доступных руткитов или инструментов для их создания. При этом реализация и качество исполнение руткита свидетельствует о том, что он создавался не для проведения целевых атак, а для как начальная попытка создания ещё одного средства для распространения вредоносного ПО.
Первая информация о новом рутките была опубликована (http://seclists.org/fulldisclosure/2012/Nov/94) несколько дней назад в списке рассылки Full Disclosure. Администратор одной из поражённых систем привёл первичный разбор странной активности на своём сервере, из-за которой во вне данные уходили с подстановкой вредоносного iframe, но локально следов подстановки вредоносного кода не наблюдалось, в том числе используемый для отдачи контента nginx при проверке через strace отдавал в сетевой сокет корректные данные. В дальнейшем один из исследователей безопасности, получивший доступ к поражённой системе, проанализирован руткит и опубликовал (http://blog.crowdstrike.com/2012/11/http-iframe-injecting-li...) подробный отчёт о методах его работы.
После загрузки руткита он осуществляет перехват управления некоторых функций ядра Linux, скрывая необходимые для работы руткита файлы на диске. Перехват управления производится путем перезаписи нескольких байт непосредственно в начале кода перехватываемой функций (добавляется команда jmp rel32 и копируется рассчитанное в стеке смещение). Запуск руткита производится через загрузку модуля ядра Linux, команда для загрузки которого добавляется в конец файла /etc/rc.local. Но так как в Debian файл /etc/rc.local завершается командой exit 0, команда загрузки модуля размещается после вызова exit, т.е. после перезагрузки руткит не активируется.
Подстановка вредоносного кода в трафик осуществляется (https://www.securelist.com/en/blog/208193935/New_64_bit_Linu...) путем перехвата функции tcp_sendmsg, используемой для построения исходящих TCP-пакетов. Обработчик руткита анализирует передаваемый контент и добавляет после строки с тегом body блок iframe. Для управления руткитом предусмотрен специальный интерфейс, получающий команды от удалённого управляющего сервера. В частности, после обращение руткита к управляющему серверу, тот возвращает блок данных, который следует внедрить в трафик, а также параметры подстановки. Напрмер, поддерживается установка правил для какого именно хоста осуществить подстановку, определяется тип внедрения (JavaScript/iframe).URL: https://threatpost.com/en_us/blogs/new-linux-rootkit-emerges...
Новость: http://www.opennet.me/opennews/art.shtml?num=35392
Опять руткит, который сначала ещё поставить нужно.
> SqueezyХм...
>> Squeezy
> Хм...У RHEL _фрагментация_ [версий/таргетов] сильно выше. %))) Киддизы одобряе стабильность Debian-а.
> После активации в ядро системы загружается специальный модульСМС надо отправлять?
>> После активации в ядро системы загружается специальный модуль
> СМС надо отправлять?Он сам отправит, если оставишь телефон подключенным к компу :)
Я невнимательно читал, или в статье нет подробностей «заражения»?
> и осуществляющий подстановку в генерируемый локальным web-сервером HTTP-трафик iframe-блоков с кодом для эксплуатации уязвимостей в клиентских браузерах и установленных в них плагинах.Кстати, в наше-то время кто-то ещё без NoScript в Сеть ходит? Мдааа...
>а для как начальная попытка создания ещё одного средства для распространения вредоносного ПО.Поправьте, пожалуйста.
Было бы интересно узнать, подвержены ли более новые ядра и что можно сделать для противодействия?
Подвержены чему? Руткит это не вирус, он сам не распространяется, его устанавливают на уже взломанную систему.
да а остальные трояны и вирусы распространяются по протоколу TCP\IP сами ))))
> да а остальные трояны и вирусы распространяются по протоколу TCP\IP сами ))))Червяки например - самораспостраняются. На то и червяки.
>> да а остальные трояны и вирусы распространяются по протоколу TCP\IP сами ))))
> Червяки например - само распространяются. На то и червяки.прочитайте пост с чего началась эта нить:
> руткит это не вирус, он сам не распространяется, его устанавливают на уже взломанную систему.
подчеркиваю: > его устанавливают на уже взломанную систему.
то есть если кто то ставит линукс и там сработал руткит через некоторое время, за незакрытой или неизвестной разрабам дистрибутива уязвимости, то админ установил уже взломанную систему как сервер ?
руткит может сам не размножатся, но ведь админу пришли жалобы от клиентов сервера, тут уже зависит от того, кто писал и для чего и что было дальше в том рутките, но как всегда луноходы все будут отрицать, на хакере даже пишут что ничего нету, новость обман, а Омские линуксоиды одобряют ?
>> Червяки например - само распространяются. На то и червяки.
> прочитайте пост с чего началась эта нить:Я ответил на конкретный тезис. А что там было 100500 сообщений назад - не мои проблемы.
> подчеркиваю: > его устанавливают на уже взломанную систему.
Спасибо, Капитан. Вот только врядли живой установщик был таким дeбилом что наэхал сам в файл строку которая ничего не делает. Потому и вспомнили про червяков.
> установил уже взломанную систему как сервер ?
Хороший в этом году урожай травы походу.
> но как всегда лyноходы все будут отрицать, на хакере даже пишут что ничего нету, новость
> обман, а Омские линуксоиды одобряют ?Это уже становится интереснее. В деле уже появились лyноходы и омские линуксоиды. С нетерпением ждем новых действующих персонажей :). Ах да, судя по упоротости и странным претензиям, res2500 наверное BSDшник. Это же элементарно, Ватсон! :)
травой не увлекаюсь, зашел новость почитаь и упал от смеха с написанных слов> его устанавливают на уже взломанную систему.
)))))))))))))
> Ах да, судя по упоротости и странным претензиям, res2500 наверное BSDшник.
и не только, использую что мне нравитс, еше в 2009 году, на одном из сайтов ру нета был участником холивара, где писали что под линукс вирусов и вредоносов нету и это супер защищенная система ))))
Руткитов и червей полно, а вирусов нет.
Проблема в том, что если Вы скомпилируете бинарник на своей машине и пришлете мне, я его не смогу запустить. А вирусы размножаются путем заражения файлов, что при бинарной несовместимости и существующем либхелле крайне затруднительно. Если думаете иначе, то пишите и вперед за премией Майкрософта. 10000уе на дороге не валяются.Все кричат, что на линуксе полно вирусов, только премию так никто и не забрал.
Но вот появление таких вещей как системд и обсуждение единого формата распространения по - первый шаг к созданию бинарной совместимости. А там и до обычных вирусов рукой подать.
> Руткитов и червей полно, а вирусов нет.Есть: http://ru.wikipedia.org/wiki/Вредоносные_программы_для_Unix-подобных_систем
> Проблема в том, что если Вы скомпилируете бинарник на своей машине и
> пришлете мне, я его не смогу запустить. А вирусы размножаются путемБинарник может быть слинкован статически или не иметь нетривиальных зависимостей.
> заражения файлов, что при бинарной несовместимости и существующем либхелле крайне затруднительно.
Нет ничего затруднительного в том, чтобы вписать себя в ELF-файл - точно так же вирусы пишут себя в PE-файлы, несмотря на их разнообразие.
> Если думаете иначе, то пишите и вперед за премией Майкрософта. 10000уе
> на дороге не валяются.http://linux.slashdot.org/story/01/10/13/1346243/10000-prize... - вы об этом? Там говорится о заражении правильно сконфигурированной машины с линуксом - то есть, системы, на которую в том числе установлены все актуальные обновления безопасности. Раз так, для заражения нужно сперва найти 0day уязвимости в установленном ПО и написать для них reliable эксплойты. При этом за одну только уявзимость с эксплойтом для браузера можно выручить в сумме 20000 плюс макбук, почитайте здесь:
http://en.wikipedia.org/wiki/Pwn2Own#Outcome_3> Все кричат, что на линуксе полно вирусов, только премию так никто и
> не забрал.Возможно, потому что стоимость работ по факту существенно выше 10000 фунтов.
> Но вот появление таких вещей как системд и обсуждение единого формата распространения
> по - первый шаг к созданию бинарной совместимости. А там и
> до обычных вирусов рукой подать.Вирусам не нужна бинарная совместимость на уровне зависимостей, скриптов запуска служб и т.п.
> Есть: http://ru.wikipedia.org/wiki/Вредоносные_программы_для_Unix-подобных_системДа все там есть. Только найти крайне сложно.
> Нет ничего затруднительного в том, чтобы вписать себя в ELF-файл - точно
> так же вирусы пишут себя в PE-файлы, несмотря на их разнообразие.В принципе да, однако проблема в том что линуксоиды чаще всего апдейтят весь софт и либы системным апдейтером + качают оный только из доверяемых репов. А чтобы слитый файл запустился - его надо пометить исполняемым. Что делает нечаянный запуск или запуск дебилом за монитором менее вероятным сценарием. По поводу чего механизмов для самоходного распостранения как-то сильно меньше получается. Ну то-есть оно в принципе возможно но на практике - весьма редко и юзаются в основном методы "на дурака" - тыринг ключей или попытки подобрать слабые пароли.
>> Все кричат, что на линуксе полно вирусов, только премию так никто и не забрал.
> Возможно, потому что стоимость работ по факту существенно выше 10000 фунтов.Ну так это выступает изрядной планкой против атакующих. Это хорошо.
> Вирусам не нужна бинарная совместимость на уровне зависимостей, скриптов запуска служб и т.п.
Все так. Просто для них нет какой-то особо благодатной почвы которая бы позволила им стать простыми и массовыми.
> Да все там есть. Только найти крайне сложно.На сложность написания вирусов это не влияет.
> В принципе да, однако проблема в том что линуксоиды чаще всего апдейтят
> весь софт и либы системным апдейтером + качают оный только из
> доверяемых репов. А чтобы слитый файл запустился - его надо пометить
> исполняемым. Что делает нечаянный запуск или запуск дебилом за монитором менее
> вероятным сценарием. По поводу чего механизмов для самоходного распостранения
> как-то сильно меньше получается.Для вируса, который распространяется через 0day-уязвимости, это не проблема. Поверхность атаки довольно широка: браузер и плагины к нему, почтовый клиент, офисный пакет, IM-клиенты, библиотеки для работы с файлами изображений и т.д.. Эксплуатация уязвимостей в этих компонентах даже под виндой - гораздо более частое и массовое явление, чем ручной запуск троянцев, даже несмотря на объёмы вареза и кряков/кейгенов, потребляемого массами.
Проблема (для вирусописателей) с репами кроется в другом: регулярные и довольно оперативные обновления софта, включая весь вышеперечисленный. Под виндой со сравнимой оперативностью обновляются разве что базы антивирусов. ;) На этом вся существенная "более безопасность" линукса по сравнению с виндой заканчивается: если написание свежего вируса или эксплойта для получения какой-нибудь премии ещё может иметь смысл, то рассчитывать на массовые заражения, используя один и тот же вектор - бесполезно. Большинство уязвимых пользователей с высокой вероятностью получат обновления уязвимого ПО до столкновения с вирусом. Именно это, если отбросить скромный процент присутствия линукса на десктопах, делает вирусописание под линукс невыгодным, а вовсе не преувеличенная неоднородность среды распространения.
>> Возможно, потому что стоимость работ по факту существенно выше 10000 фунтов.
> Ну так это выступает изрядной планкой против атакующих. Это хорошо.Вы путаете сложность и стоимость. В данном случае атакующих просто прельщает бОльшая прибыльность других направлений, особенно, учитывая объёмы наработок по ним.
>> Вирусам не нужна бинарная совместимость на уровне зависимостей, скриптов запуска служб и т.п.
> Все так. Просто для них нет какой-то особо благодатной почвы которая бы
> позволила им стать простыми и массовыми.Вот именно, что нет почвы для массового распространения. Со сложностью написания и внедрения 0day-вирусов проблем нет: она низкая.
> травой не увлекаюсь, зашел новость почитаь и упал от смеха с написанных словСудя по вашим постингам - у меня большие сомнения насчет вашей честности в этом вопросе.
>> его устанавливают на уже взломанную систему.
> )))))))))))))Это вы теперь сами над собой смеетесь?
> под линукс вирусов и вредоносов нету и это супер защищенная система ))))
Супер, не супер, но в целом - достаточно неудобная для вредоносных сущностей система. А со всякими виртуалками, контейнерами, security подсистемами и прочая - оно может быть весьма невкусной для хакеров штукой. Просто техника в руках дикаря - груда металлолома.
> Подвержены чему? Руткит это не вирус, он сам не распространяется, его устанавливают
> на уже взломанную систему.Вопрос в том, кто взламывает и устанавливает. Похоже на червие.
Для противодействия достаточно монтировать на серверах /etc и /lib в read-only.
> Для противодействия достаточно монтировать на серверах /etc и /lib в read-only.И после этого, никогда не обновляться.
>И после этого, никогда не обновляться.Наркоман? man 8 mount на предмет remount'а.
> Наркоман? man 8 mount на предмет remount'а.То есть даже без аппаратной защиты от записи? LOL.
Что мешает сделать remount самому руткиту, если он уже работает на уровне ядра (т.е. с максимальными полномочиями)?
> ядра (т.е. с максимальными полномочиями)?Геморность реализации парирования всех заскоков админов :). Ушибленных админов много а автор руткита - один. Он задолбается AI разгребающий все подляны всех админов выписывать. Поэтому чем нестандартнее настройки - тем вероятнее что автоматизированная хренота словит былинный отказ и отползет сломав зубы.
А кто вам сказал что автор руткита один?
> Геморность реализации парирования всех заскоков админов :).админы, у вас Чуство Собвственной Важности похоже что запредельно...
..вы хоть представляете себе какое огромное количество гемороя пришлось УЖЕ решить разработчиком этого руткита, для того чтобы руткит просто начал работать? решить ещё и чуть-чуть гемороя с тем чтобы просмотреть /etc/fstab и на основании него сделать remount -- это практически нет-ничего.
> ..вы хоть представляете себе какое огромное количество гемороя пришлось УЖЕ решитьДа никакого там особого геморроя. Гражданин исследующий этот экспонат пришел к выводу что это довольно хилая поделка, автор которой очень средне знает линуксный кернель и потому сработал довольно топорно. А былинный отказ с эханием после exit 0 :) явно подтверждает лишний раз что это создано явно не супер-про высшей квалификации.
> разработчиком этого руткита, для того чтобы руткит просто начал работать?
Судя по всему - автору просто пришла в бошку свежая идея и он ее влобешник реализовал. Оно даже работает. Не, идея с патчингом TCP/IP чтобы прямо там вклиниваться - свежо и нахально, не отнять. Но кроме этого - ничего такого особенного. Все руткиты ведут себя похоже в плане маскировки.
> решить ещё и чуть-чуть гемороя с тем чтобы просмотреть /etc/fstab и на основании
> него сделать remount -- это практически нет-ничего.Проблемки только вот в чем:
1) Вариантов монтирования разделов - туева хуча. Писать полновесный парсер который осознает как и где монтируется желаемый путь и его правильный и однозначный ремоунт - не сильно тривиально.
2) Это утяжелит троян и потенциально повысит его паливность.
3) Это лишь один из over 9000 фокусов которые может отколоть админ. Вероятность что админ отколет именно этот фокус а не 9000 иных - очень небольшая.
4) А что если админ оказался чуть более козел и допустим squashfs юзанул? Если уж ему хотелось глухое readonly - это можно. А теперь попробуйте заремаунтить... :)
> 4) А что если админ оказался чуть более козел и допустим squashfs
> юзанул? Если уж ему хотелось глухое readonly - это можно. А
> теперь попробуйте заремаунтить... :)ладно.. тогда предлагаю другой алгоритм (если вы так сопративляетесь!) -- если оказывается что файловая система readonly , то просто затираем /dev/md* /dev/sd* (и другие блочные устройства) из /dev/urandom ...
...в отместку!
так-то! :-) ..а теперь надеюсь что вы проклянёте-всё-на-свете что сделали read-only для защиты от автоматических вторжений. :-D :-D
# P.S.: и кстате да, именно автоматических! потомучто при вторжении вручную -- можно вручную (глазами, мозгом) отпарсить /etc/fstab. тоесть предполагается что вторгатель человек получил уже хоть какой-то доступ к системе, прежде чем внедрять rootkit . может украл SSH-ключ, может через PHP-инъекцию.
> ...в отместку!И немедленно палим свою активность и обращаем внимание на проблемы. А зачем? Руткит пихается с ровно обратной целью.
> защиты от автоматических вторжений. :-D :-D
Я просто перераскатаю все из бэкапов и учиню лютейший аудит на предмет того "а как это вообще стало возможно". Не говоря уж о том что аверы специально начнут расставлять специально ослабленные приманки с такой конфигурацией. Разве плохо если автоматизированные дебилы будут сами себя сдавать как стеклотару? Аверы потом снапшот откатят и им похрен, а вот ценный экспонат поймать - можно :). А вот если некто бодался с написанием такого кастомного модуля, быстро спалиться - явно не в его интересах.
> # P.S.: и кстате да, именно автоматических! потомучто при вторжении вручную --
> можно вручную (глазами, мозгом) отпарсить /etc/fstab.Ну вот в этом и есть отличие между человеком и роботом. На данный момент роботы не могут проявить полную автономность и принимать произвольные по сложности решения самостоятельно. В день когда AI это наконец смогут, у нас будут намного более важные проблемы чем какие-то вшивые вирусы.
> тоесть предполагается что вторгатель человек получил уже хоть какой-то доступ
> к системе, прежде чем внедрять rootkit . может украл SSH-ключ, может через PHP-инъекцию.В данном случае вторгатель явно не был человеком, иначе бы он не зафэйлил с exit 0 :)
> Проблемки только вот в чем:
> 1) Вариантов монтирования разделов - туева хуча. Писать полновесный парсер который осознает
> как и где монтируется желаемый путь и его правильный и однозначный
> ремоунт - не сильно тривиально.Посмотреть в /proc/mounts (или список разделов внутри ядра) и перемонтировать для записи раздел, путь до точки монтирования которого является наиболее длинной частью пути до интересного файла - это разве нетривиально?
> 2) Это утяжелит троян и потенциально повысит его паливность.
Не утяжелит и не повысит.
> 3) Это лишь один из over 9000 фокусов которые может отколоть админ.
> Вероятность что админ отколет именно этот фокус а не 9000 иных
> - очень небольшая.На практике никто никаких фокусов не откалывает. Особенно таких, которые могут стать нетривиальной помехой для взломщика, но не для системных задач (обновление ПО на read-only разделе - пример такой задачи).
> 4) А что если админ оказался чуть более козел и допустим squashfs
> юзанул? Если уж ему хотелось глухое readonly - это можно. А
> теперь попробуйте заремаунтить... :)Админ может оказаться ещё более хитрым перцем и выдернуть из розетки кабель питания сервера. Много лично вы настроили или хотя бы видели Debian-серверов с / на read-only разделе? Риторический вопрос.
> до интересного файла - это разве нетривиально?Да, ибо вариантов как и что может быть смонтировано - туева хуча. А если какой-то админ начнет ивзращаться - туева хуча в квадрате. Полный парсер который ничего не сломает даже в краевых ситуациях не совсем тривиален, а если что-то отвалится, админ тут же попрется смотреть - WTF. Что явно не в интересах руткитчиков.
>> 2) Это утяжелит троян и потенциально повысит его паливность.
> Не утяжелит и не повысит.Всех вариантов что, откуда и как может быть замонтировано - довольно много. И все-равно на кравевых случаях проблемы будут.
> На практике никто никаких фокусов не откалывает.
Ну если рассчитывать на сферического админа в вакууме - да. Поэтому и упомянутый фокус никто не учитывает. Так что тем админам кто не хочет автоматизированные заразы - логично менять конфигурацию системы с дефолтов. Желательно наименее предсказуемым образом. И мониторить все это.
> Особенно таких, которые могут стать нетривиальной помехой для взломщика, но не
> для системных задач (обновление ПО на read-only разделе - пример такой задачи).Обновление системы может делаться под чутким присмотром админа, опять же. Ну и вообще, лучший метод от козлов - неожиданность, как-то так: http://dihalt.ru/gazenvagen.html
>> теперь попробуйте заремаунтить... :)
> Админ может оказаться ещё более хитрым перцем и выдернуть из розетки кабель
> питания сервера. Много лично вы настроили или хотя бы видели Debian-серверов
> с / на read-only разделе? Риторический вопрос.Именно дебиан на ридонли - ну да, редкая штука. А сам я больше предпочитаю виртуалки и контейнеры. Что тоже неплохо :)
>> до интересного файла - это разве нетривиально?
> Да, ибо вариантов как и что может быть смонтировано - туева хуча.Определить точку монтирования раздела, на котором лежит нужный файл, очень просто. Перемонтировать с remount,rw - ещё проще. Нет тут никакой "туевой хучи" факторов. Нет. Точка. Попытайтесь уже сами представить алгоритм определения раздела и перемонтирования и попробуйте найти место, о котором можно сказать: вот здесь высока вероятность таких-то проблем. Нет там таких мест. А ваша уверенность в обратном только ставит ситуацию с головы на ноги и показывает, насколько легковерны админы, и чего на самом деле стоят их "извращения".
> А если какой-то админ начнет ивзращаться - туева хуча в квадрате.
> Полный парсер который ничего не сломает даже в краевых ситуациях не
> совсем тривиален, а если что-то отвалится, админ тут же попрется смотреть
> - WTF. Что явно не в интересах руткитчиков.Не нужен там никакой "парсер". Что он там должен парсить? Список разделов и точек монтирования? Пути до файлов?
> Всех вариантов что, откуда и как может быть замонтировано - довольно много.
> И все-равно на кравевых случаях проблемы будут.Вариантов очень много, но сложности в деплое руткита они не прибавляют. Перемонтировать раздел - это так же просто и очевидно, как снять атрибут immutable с конечного файла. И не многим проще, чем отключить LSM и любые MAC-системы на их базе, располагая подходящей уязвимостью в ядре.
Кроме того, руткит вполне может плакаться родителю о любых провалах. Хотите поставить на то, что папе лень будет зайти на сервер, убрать препятствия, задеплоить руткит и включить обход этих препятствий в следующей версии?
>> На практике никто никаких фокусов не откалывает.
> Ну если рассчитывать на сферического админа в вакууме - да. Поэтому иДаже хитрые и несферические больше треплются, чем реально что-то делают. Потому что как истинные неуловимые джо привыкли мыслить на лучших случаях - надеяться на авось, иными словами. Тогда как общепринятые практики с сфере ИБ совершенно другие, и никакой тайны не составляют - было бы желание прочитать и понять.
> упомянутый фокус никто не учитывает. Так что тем админам кто не
Откуда вы знаете, учитывает или нет? Я видел rescue-скрипты от хостеров, которые учитывают подобные проблемы, а вы рассуждаете в глобальных категориях: "никто"... Авось никто, ага.
> хочет автоматизированные заразы - логично менять конфигурацию системы с дефолтов.
> Желательно наименее предсказуемым образом. И мониторить все это.Менять надо целенаправленно и с пониманием того, зачем именно производится каждое изменение. А не просто в надежде на "авось как-то помешает".
> Обновление системы может делаться под чутким присмотром админа, опять же. Ну и
> вообще, лучший метод от козлов - неожиданность, как-то так: http://dihalt.ru/gazenvagen.htmlА вы сами пробовали обновить ПО на корневом squashfs-разделе без перезагрузки системы? Этот метод создаёт гораздо больше проблем, чем решает.
> Именно дебиан на ридонли - ну да, редкая штука. А сам я
А знаете, почему? Система становится практически неюзабельной. А реальных результатов, помимо поводов для надежды на авось, это не даёт. Пока система работает - работает и руткит, даже если он неперсистентный, а после перезагрузки системы у взломщика есть хороший шанс проникнуть на неё повторно, до следующего перезапуска. Многие даже отдают предпочтение неперсистентным руткитам - чтобы не палить инструментарий в случае ухода машины на аудит.
> больше предпочитаю виртуалки и контейнеры. Что тоже неплохо :)
Без рассмотрения конкретной ситуации не ясно, плохо это или нет. Виртуалки и контейнеры широко известны в узких кругах как хороший способ положить все яйца в одну корзину.
>[оверквотинг удален]
>> Особенно таких, которые могут стать нетривиальной помехой для взломщика, но не
>> для системных задач (обновление ПО на read-only разделе - пример такой задачи).
> Обновление системы может делаться под чутким присмотром админа, опять же. Ну и
> вообще, лучший метод от козлов - неожиданность, как-то так: http://dihalt.ru/gazenvagen.html
>>> теперь попробуйте заремаунтить... :)
>> Админ может оказаться ещё более хитрым перцем и выдернуть из розетки кабель
>> питания сервера. Много лично вы настроили или хотя бы видели Debian-серверов
>> с / на read-only разделе? Риторический вопрос.
> Именно дебиан на ридонли - ну да, редкая штука. А сам я
> больше предпочитаю виртуалки и контейнеры. Что тоже неплохо :)Не позорь имя онанима, теж сказали в ядре все пути есть что куда примонтированно, не нужен парсер, Прикрати слушать только себя, в этом мире куча людей "over 9000" умнее и осведщомленние чем мы с тобой вместе, хорош флудить, как не понятно такие как ты убиваю желание почтить что-то дельное. peace
АГА! Вот так вот и будет изобретён ИИАА (искусственный интелект анти-админа) а там и до простого ИИ недалеко и здравствуй сингулярность
У меня даже на роутере ядро собранное без возможности загружать модули. Кто ставит серверы с модулями?
RHEL/CentOS/Ubuntu Server.
:-D этопять!
> RHEL/CentOS/Ubuntu Server.Пффф, даже в этих дистрибутивах можно пересобрать ядро.
>можно пересобрать ядро.Тогда ты неправильно задал первый вопрос."Кто-то ещё здесь _так пересобирает ядро?"И тему надо было сменить на "Перепись"
Разве на роутере есть смысл собирать ядро как-то по другому?
> Разве на роутере есть смысл собирать ядро как-то по другому?Безмодульная сборка - дешевый выпендреж, не более. Ни на скорость, ни на потребление ресурсов это не влияет.
>> Разве на роутере есть смысл собирать ядро как-то по другому?
> Безмодульная сборка - дешевый выпендреж, не более. Ни на скорость, ни на
> потребление ресурсов это не влияет.Да и /dev/kmem не отменяет, если уж начинать.
Помнится, когда-то иные любители на роутерах патчили обработчик помирания pid 1 и делали kernel-only router, на котором юзерспейс отрабатывает, конфигурирует ядро и самоуничтожается в памяти.
> Помнится, когда-то иные любители на роутерах патчили обработчик помирания pid 1 и
> делали kernel-only router, на котором юзерспейс отрабатывает, конфигурирует ядро и самоуничтожается
> в памяти.На самом деле, красивая идея, только рулить этим во время работы немножко неудобно.
> делали kernel-only router, на котором юзерспейс отрабатывает, конфигурирует ядро и самоуничтожается
> в памяти.Можно пойти чуть дальше и законфигурить все через ядро :)
> Безмодульная сборка - дешевый выпендреж, не более. Ни на скорость, ни на
> потребление ресурсов это не влияет.Мы говорим о безопасности. Руткит грузится как модуль, а в безмодульной сборке никуда он не загрузится. /dev/kmem естесвенно отключен.
Для решения этой задачи можно не выпендриваться с пересборкой http://www.opennet.me/tips/2554_linux_kernel_module_limit_ca...
Ну вот, пришел поручик Ржевский и все опошлил :). Теперь школьники научившиеся щелкать галочки в менюконфиге не смогут понтоваться скиллом. Ай-яй-яй :)
Какая интересная зверушка, работает хирО, это вам не винлоки. Конечно, самый интересный вопрос - распространение этой заразы. Слишком уж просто списать все на неграмотные действия админа.
> Какая интересная зверушка, работает хирО, это вам не винлоки.Под DOS были и более хитрые штуки :)
руткит сам себя никак не распространяет.советую почитать http://ru.wikipedia.org/wiki/Руткит
> руткит сам себя никак не распространяет.Но кто-то же должен его распространять. И это больше похоже не на ручную работу, а на червячка, использующего незакрытую дыру в дебиане.
Как раз это похоже на ручную работу.
Ручная работа, поражающая только конкретный софт, с ручным неправильным добавлением строчки в rc.local?Примерно такая же "ручная", как виндовые ботнеты из сотен тысяч компов, ага.
> Ручная работа, поражающая только конкретный софт, с ручным неправильным добавлением строчки
> в rc.local?
> Примерно такая же "ручная", как виндовые ботнеты из сотен тысяч компов, ага.Думается что вместе с руткитом идет нагрузка в виде червяка. Иначе смысла просто нет.
Дык это же rootkit, а где sploit что его в систему внедрить?
> Дык это же rootkit, а где sploit что его в систему внедрить?Начни с http://www.debian.org/security/2012/ и продолжай движение в сторону горизонта.
DSA это хорошо, а готового sploit'а-то у меня нету :-(
>а готового sploit'а-то у меня нету :-(Большая Земля сказала, не быть тебе киддизом.
+++Преподаватель лопух. Ло-пух! Но аппаратура при ём. Повторяю, пр йём.
> +++Преподаватель лопух. Ло-пух! Но аппаратура при ём. Повторяю, пр йём.Ч-т, "профессор" же:(
> при Нём?...
> Начни с http://www.debian.org/security/2012/ и продолжай движение в сторону горизонта.А кто сказал, что там оно есть? Дебиан - не RHEL, к безопасности досаточно пофигистичен.
> А кто сказал, что там оно есть?А кто сказал, что нет? До кучи - вот еще http://security-tracker.debian.org/tracker/
> Дебиан - не RHEL, к безопасности досаточно пофигистичен.
К счастью, в Debian прежде всего: пофигистичны к голословному "авторитетному" мнению разных анонимов...
> А кто сказал, что нет?Факт наличия инфицированных серваков. Если бы апдейты вышли своевременно - их бы не было.
> К счастью, в Debian прежде всего: пофигистичны к голословному "авторитетному" мнению разных анонимов...
Да, только тупые анонимы могут голословно утверждать, что нужно заботиться о безопасности.
Но настоящим разработчикам Debian пофиг на такие заявления - как не заботились, так и не будут.
>> А кто сказал, что нет?
> Факт наличия инфицированных серваков. Если бы апдейты вышли своевременно - их бы не было.Ну простите, что пока Debian не умеет заменять локального администратора. Мы в процессе ;)
Так что необходимость устанавливать обновления безопасности и тем более ошибок конфигурации ПО у конкретного администратора - никто не отменял. Чем, прежде всего, и объясняется ваш "факт".
>> К счастью, в Debian прежде всего: пофигистичны к голословному "авторитетному" мнению разных анонимов...
> Да, только тупые анонимы могут голословно утверждать, что нужно заботиться о безопасности."Тупые анонимы" (ваши слова) - утверждали, не утруждая себя доказательствами, нечто совсем иное. Напомнить?
> Так что необходимость устанавливать обновления безопасности и тем более ошибок конфигурации ПО у конкретного администратора - никто не отменял. Чем, прежде всего, и объясняется ваш "факт".Прежде всего, он объясняется тем, что обновления безопасности надо _выпускать_.
> "Тупые анонимы" (ваши слова) - утверждали, не утруждая себя доказательствами, нечто совсем иное. Напомнить?
Это вы про свой пост?
>> Так что необходимость устанавливать обновления безопасности и тем более ошибок конфигурации ПО у конкретного администратора - никто не отменял. Чем, прежде всего, и объясняется ваш "факт".
> Прежде всего, он объясняется тем, что обновления безопасности надо _выпускать_.Обновления выпускаются, http://security.debian.org/. Ваш КО.
>> "Тупые анонимы" (ваши слова) - утверждали, не утруждая себя доказательствами, нечто совсем иное. Напомнить?
> Это вы про свой пост?Про ваш. Как будете постить - обратите внимание на подпись вашего поста: "отправлено Аноним".
> Обновления выпускаютсяНо не все и с большим опозданием. Возьмем, например, ядро http://security-tracker.debian.org/tracker/source-package/li...
> Про ваш. Как будете постить - обратите внимание на подпись вашего поста: "отправлено Аноним".
В подписи вашего поста тоже паспортных данных нет :)
>> Обновления выпускаются
> Но не все и с большим опозданием. Возьмем, например, ядро http://security-tracker.debian.org/tracker/source-package/li...Слыхал звон? А теперь тыкаем (случайная выборка):
CVE-2012-3511 - статус NEW в RHEL
CVE-2011-4621 - аналогично
CVE-2012-4565 - NEW>> Про ваш. Как будете постить - обратите внимание на подпись вашего поста: "отправлено Аноним".
> В подписи вашего поста тоже паспортных данных нет :)Его хоть идентифицировать можно другим участникам. А вашу муть - даже не факт, что писал один человек...
> как не заботились, так и не будут.как это «не заботились»?! вон, даже openssl патчили, чтобы секурность повысить!
>> Начни с http://www.debian.org/security/2012/ и продолжай движение в сторону горизонта.
> А кто сказал, что там оно есть?Кто "оно"-то?? Ядро?
Новость сказала мне - "под управлением Debian Squeezy с ядром 2.6.32-5-amd64".> Дебиан - не RHEL, к
Новость не читай, сразу пиши.
А для убунты чтото подобное есть?
> А для убунты чтото подобное есть?В $поисковик ubuntu security совсем не вбивается? ubuntu.com/usn
Прикольный зверёк. Проверили все /etc/rc.local нормальные.
Думаю, что после выкладки на секлисте, руткит уже пропатчился на предмет выдачи правильного /etc/rc.local, ну и корректного запуска после перезагрузки.
Нужно с заведомо исправной системы загрузить сервер, что ли...
А, там уже "правильный" rc.local отдается
http://4.bp.blogspot.com/-c6xVri0YRjo/UKaA7qP4O4I/AAAAAAAAAD...Осталось пофиксить оплошность с загрузкой модуля при старте системы.
Вы все ешё хостите сервисы на голом железе? Тогда мы идем к вам!
PS: Вроде как сто лет в обед тем же контейнерам ан нет - находятся умельцы..
> Вы все ешё хостите сервисы на голом железе? Тогда мы идем к
> вам!
> PS: Вроде как сто лет в обед тем же контейнерам ан нет
> - находятся умельцы..Те же контейнеры вроде как работают с тем же ядром.
> Те же контейнеры вроде как работают с тем же ядром.Вот только они не позволяют грузить модули ядра изнутри контейнера, в котором оказывается атакующий после пробоя сервиса. Как следствие, по своей сути древние как кал мамонта руткиты уровня модулей ядра нервно курят в сторонке.
Уверен, что нет 0-day сплойтов, позволяющих загрузку модулей изнутри контейнера?
> Уверен, что нет 0-day сплойтов, позволяющих загрузку модулей изнутри контейнера?Нарисовать указанный сплойт и его целевую нагрузку (перехватчик) тем более долгоиграющий куда сложнее, чем то, что описано в новости.
> в случае OpenVZ контейнеров - достаточно выставить capability bit - который не доступен простым смертным. после этого загрузка модулей из контейнера будет такой же как из hw node.Отлично! Мы практически взломали Интернет. Дело за малым - как мы будем управлять capabilities контейнера находясь внутри контейнера? Было бы интересно услышать какие-то конкретные рекомендации и пути развития ситуации. Предположим, что рут в контейнере у нас уже есть.
>> в случае OpenVZ контейнеров - достаточно выставить capability bit - который не доступен простым смертным. после этого загрузка модулей из контейнера будет такой же как из hw node.
> Отлично! Мы практически взломали Интернет. Дело за малым - как мы будем
> управлять capabilities контейнера находясь внутри контейнера? Было бы интересно услышать
> какие-то конкретные рекомендации и пути развития ситуации. Предположим, что рут в
> контейнере у нас уже есть.Пойти к админу и попросить рута на хосте, очевидно же.
>> в случае OpenVZ контейнеров - достаточно выставить capability bit
> как мы будем управлять capabilities контейнера находясь внутри контейнера?Дело даже не в том -- пусть сначала продемонстрирует хоть в каком виде загрузку модулей ядра _изнутри_ контейнера openvz. Предположим, что рут есть и в VE, и на HN. Ядро поставки ovz.
Товарищ видимо имел ввиду sys_module container capability bit:Parallels Virtuozzo Containers 4.7 for Linux User's Guide
* Configuring Capabilities
** Available Capabilities for Containers
*** Linux-Specific Capabilities
....
sys_module - Insert and remove kernel modules. Be very careful with setting
this capability on for a Container; if a user has the permission of
inserting kernel modules, this user has essentially full control over
the Node.Лично я его не пробовал, но судя по описанию выставление этого бита на контейнере должно позволять прострелить себе не только ногу но и голову. Дойдут руки - попробую. Вопрос лишь в том, что управление capabilities доступно с хоста но никак не изнутри контейнера.
> capabilities доступно с хоста но никак не изнутри контейнера.Да, и по дефолту в всех хостеров в здравом уме и всех остальных - никто не дает контейнерам модули грузить. Иначе первый же пупкин порутает нахрен весь хост.
> а что в ядре уже совсем нету багов?В ядре бывают баги. Но они бывают и много где еще. Хотя тру параноик может распилить железку на KVM виртуалки, оную на LXC/OVZ контейнеры, а в них еще чрут сделать. Во хакерье будет радо :)
> тру параноик может
> KVM виртуалки, оную на LXC/OVZ контейнеры, а в них еще чрут сделать, а его прикрыть SELinux-ом. Рукописным!
>. Во хакерье будет радо :)
> PS. я помню стопку эксплойтов которые работали на OpenVZ ядреНе, возможно конечно все, но чтобы конкретно взятый руткит прошибал вообще все и в любой позе - автор упухнет его такой выписывать. И если автор поделия не в курсах что эхать что-то после exit 0 неэффктивно - как вы думаете, какая вероятность того что он рассмотрел существование этой самой опенвзы вообще?
А так - для более параноидальных применений есть KVM тот же например. Изолирует лучше, но просадка по скорости больше. В общем, опять tradeoff. Особые параноики юзают Xen, но и в нем находят невкусные баги, если что. Тем не менее, прилично поднять планку для атакующего - вполне можно.
> Товарищ видимо имел ввиду sys_module container capability bit:Товарищ, видимо, безнадёжен. Продемонстрируем это на практике при помощи ALT Linux Sisyphus (x86_64), mkimage-profiles-0.9.0-alt1 и ядра 2.6.32-ovz-el-alt79:
n02:~/mkimage/mkimage-profiles> cat conf.d/ve.mk
# http://www.opennet.me/openforum/vsluhforumID3/87401.html#81
ve/test: ve/generic
@$(call add,BASE_PACKAGES,kernel-image-ovz-el kmod)
n02:~/mkimage/mkimage-profiles> make ve/test.tar.gz
** ARCH: x86_64
23:07:51 cleaning up
23:07:51 initializing BUILDDIR: build/
23:07:52 preparing distro config
23:07:52 starting image build (coffee time)
23:08:41 done (0:49)
** image: ~/out/test-20121121-x86_64.tar.gz [76M]
root@n02 ~ # mv ~mike/out/test-20121121-x86_64.tar.gz \
/var/lib/vz/template/cache/altlinux-sisyphus-test-x86_64.tar.gz
root@n02 ~ # vzctl create 101 --ostemplate altlinux-sisyphus-test-x86_64
Creating container private area (altlinux-sisyphus-test-x86_64)
203MiB 0:00:00 [ 550MiB/s] [================================>] 100%
Performing postcreate actions
CT configuration saved to /etc/vz/conf/101.conf
Container private area was created
root@n02 ~ # vzctl set 101 --capability sys_module:on --capability ve_admin:on --save
CT configuration saved to /etc/vz/conf/101.conf
root@n02 ~ # vzctl start 101
Starting container ...
Container is mounted
Setting CPU units: 1000
Container start in progress...
root@n02 ~ # lsmod | grep dummy
root@n02 ~ # vzctl exec 101 modprobe dummy
ERROR: could not insert 'dummy': Operation not permitted
root@n02 ~ # lsmod | grep dummy
root@n02 ~ # _> Вопрос лишь в том, что управление capabilities доступно с хоста
> но никак не изнутри контейнера.Товарищ ещё и не в курсе частоты появления дырок класса local kernel, пригодных для того, что он попытался языком наляпать. Последняя из тех, что беспокоили, была несколько лет тому в коркомёте (который в альте и так давно отключен по умолчанию по схожим соображениям).
> Последняя из тех, что беспокоили, была несколько лет тому в коркомёте (который в
> альте и так давно отключен по умолчанию по схожим соображениям).Всем и каждому известно, что в линуксе нет уязвимостей. "Security bugs are just bugs." Разве только редкие DoS-уязвимости случаются - но ведь они совершенно точно, достоверно не более, чем DoS-уязвимости.
> "Security bugs are just bugs."Пардон, Берштейн тоже так считает :). Хоть и по иному поводу.
> совершенно точно, достоверно не более, чем DoS-уязвимости.
Троллинг нормальный, засчитан :)
Ставьте OpenBSD и спите спокойно.
Почему?
> Почему?Потому что Неуловимый Джо.
Любая экзотическая ось хороша тем, что под ней работает слишком мало хостов, чтобы тру-хакеры начали с ней заморачиваться.
А что, linux уже mainstream?
> А что, linux уже mainstream?На серверах - да.
> А что, linux уже mainstream?Есть корпорации, которые заинтересованы в том, чтоб оси на базе ядра Linux™ стали мейнстримом, т.к. они бабло на этом рубят. А то что оно всё дярывое как решето, это им даже на руку, лишний повод поднять цену на саппорт.
У вас в голове каша. Как связаны дырявость и цена на саппорт? Дырявость - лишь повод к оттоку клиентов на конкурирующие продукты.
> оно всё дярывое как рeшето,Хотите я вас расстрою? С точки зрения простейшей логики несложно понять что чем больше код тем больше в нем багов. С другой стороны, чем меньше код, тем меньше полезного для пользователя он умеет. Отсюда вытекает несколько простых вещей.
1) Любая достаточно сложная система содержит баги. В том числе затрагивающие безопасность.
2) Система которая заведомо без багов примитивна и ценности для пользователя не представляет.
> 1) Любая достаточно сложная система содержит баги. В том числе затрагивающие безопасность.Вот только количество этих багов и последствия их эксплуатации могут серьёзно варьироваться в зависимости от приоритетов и квалификации разработчиков.
> А что, linux уже mainstream?Давно.
> А что, linux уже mainstream?С разморозкой вас. Хорошо видать криокамера морозила. Да, в 2012 году - он уже вполне себе майнстрим, особенно на серверах.
>> Почему?
> Потому что Неуловимый Джо.
> Любая экзотическая ось хороша тем, что под ней работает слишком мало хостов,
> чтобы тру-хакеры начали с ней заморачиваться.Так почему openbsd, а не haiku, QNX, etc?
> Так почему openbsd, а не haiku, QNX, etc?Лучше Minix. Не знаю правда, умеет ли он TCP/IP, но как минимум модули грузить он точно не умеет. Он даже просто шаред либы то не могет пока. Во хакер обломается! :)
> Любая экзотическая ось хороша тем, что под ней работает слишком мало хостов,
> чтобы тру-хакеры начали с ней заморачиваться.А потом спрашивают, зачем пилить своё, когда есть дебиан...
> А потом спрашивают, зачем пилить своё, когда есть дебиан...Фрагментация дистрибутивов линукса создает проблемы авторам любого софта: и малвари, и добропорядочного прикладного софта. А потом спрашивают, почему автокада, крайзиса и фотошопа под линукс нет...
> почему автокада, крайзиса и фотошопа под линукс нет...Это были примеры малвари? А то адоба вон рассылает уже спам с угрозами, например :)
лучше уж сразу полуось (ecomstation) :)
> лучше уж сразу полуось (ecomstation) :)DOS тогда уж сразу. Если среди хакеров не попадется некрофила, вы в безопасности.
> Почему?там по дефолту в работающей системе нельзя засунуть посторонний код в ядро
> там по дефолту в работающей системе нельзя засунуть посторонний код в ядроНа самом деле, можно.
> там по дефолту в работающей системе нельзя засунуть посторонний код в ядроА в лине мало того что сто лет есть опция запрета вгрузки модулей, для тех кто маньяк, так еще и с ядра 3.7 можно засунуть в ядро ключ и вклчить опцию форсированной проверки подпией - тогда ядро будет грузить только то что подписано правильным привкеем парным к этому ключу. Хоть это и делалось для секурбута, но кроме всего прочего это при желании можно поюзать и просто в пику хакерам.
> - тогда ядро будет грузить только то что подписано правильным привкеем
> парным к этому ключу. Хоть это и делалось для секурбута, но
> кроме всего прочего это при желании можно поюзать и просто в
> пику хакерам.В пику хакерам это поюзать не удастся, потому что инфраструктура модулей в ядре есть, а все запреты на её использование можно отключить посредством эксплуатации уязвимостей в ядре, которая в mainline-ядре почти ничем не затруднена.
> ядре есть, а все запреты на её использование можно отключить посредством
> эксплуатации уязвимостей в ядре, которая в mainline-ядре почти ничем не затруднена.Если ты проэксплуатировал уязвимость в ядре и можешь переколбашивать режим ядра как угодно, накукуй тебе тогда какие-то модули вообще? Из эстетических соображений чтоли? :)
Вон там рядом есть пример как заставить ядро вгрузить предсказуемый хлам в ядерную область памяти. В этом случае - через jit. Но есть и over 9000 иных способов.
> Если ты проэксплуатировал уязвимость в ядре и можешь переколбашивать режим ядра как
> угодно, накукуй тебе тогда какие-то модули вообще? Из эстетических соображений чтоли?
> :)Для упрощения разработки и деплоя руткита.
> Ставьте OpenBSD и спите спокойно.Угу. В мавзолее. Все-равно она железа с гулькин нос не поддерживает.
> Угу. В мавзолее. Все-равно она железа с гулькин нос не поддерживает.Это миф. Было даже время, когда OpenBSD поддерживала наибольшее количество WiFi-чипов среди всех свободных ОС - причём, в открытых драйверах, не проприетарных.
> Это миф. Было даже время, когда OpenBSD поддерживала наибольшее количество
> WiFi-чипов среди всех свободных ОС - причём, в открытых драйверах, не проприетарных.Это время было. Но давно прошло. В пингвине нынче разработка беспроводных сетей - явно активнее. И usb 3.0 пингвин вообще самым первым из осей поддержал, и прочая.
А еще мы умеем отцеплять девайс от физического хоста и отавать его гуесту. С IOMMU это даже прокатывает. Так что виртуальные машины могут почти все что и реальные, обеспечивая более хорошую изоляцию. А в опенке так можно?
> Те же контейнеры вроде как работают с тем же ядром.Вот только модули из контейнеров в то ядро не грузятся.
> Вот только модули из контейнеров в то ядро не грузятся.Да, обламается, проверено :). А в ядре 3.7 нынче стало можно еще и зафорсить цифровые подписи модулей ядра до кучи к тому же. Федористы это конечно по поводу секурбута пилили, но можно же вражескую технологию и на благо пустить. Если уж пушка есть - нехай палит по неприятелю!
> Те же контейнеры вроде как работают с тем же ядром.Только через них не получается модули ядра грузить. Мелочи какие :)
Ничего страшного. Просто человеческий фактор.
Классный курсовик.Наконец-то показали что не перевелись ещё "ядрёные" программеры в инетах.
А то что ашипка вылезла - так это к релизу подправят.
Я так думаю, что это в ожидании геймеров разработка.
> Наконец-то показали что не перевелись ещё "ядрёные" программеры в инетах.Предположительно российских. Досадно то, что какой-никакой талант идёт на вредное.
>> Наконец-то показали что не перевелись ещё "ядрёные" программеры в инетах.
> Предположительно российских. Досадно то, что какой-никакой талант идёт на вредное.Не ругайте кузнеца, чей топор Раскольников на старушке опробовал ;)
Видел этот (ну или похожий по действию) руткит в продаже около года назад.
Автор действительно русскоязычный, и просил за него совершенно неадекватные деньги - $11к. Но видно спустя год всё-таки нашел покупателя, или же поставил нормальный ценник.
Вот насчёт поддерживаемых ядер не помню конкретно, но точно было не одно. Хотя год прошел, кто знает, что сделал автор со своей разработкой.
Ещё по-моему он предоставлял какое-то громадное 200-метровое видео с описанием своего продукта, но мне было впадлу скачивать :)А насчёт твоего утверждения - в русскоговорящих странах не так уж много возможностей реализоваться (и зарабатывать на жизнь) специалисту по компьютерной безопасности. А коммерсанты с "тёмной стороны силы" всегда ценили по достоинству и платили хорошие деньги толковым людям. Так что имеем то, что имеем - у всех самых злых руткитов и банковских троянов ноги растут из стран бывшего СССР.
Судя по тому, что эта игрушка делает - эти "неадекватные деньги" отобьются ифреймом за сутки-другие, если я правильно помню цены на сии "услуги". Достаточно одного хостера найти...
Где можно скачать и как устанавливать?
Что характерно, автор, судя по содержимому модуля - наш соотечественник.
> Что характерно, автор, судя по содержимому модуля - наш соотечественник.Касперский
> КасперскийМожет все-таки Касперски?
PS: Мягко говоря сложно представить себе Каспера, занимающегося подобной херней.
>> Касперский
> Может все-таки Касперски?
> PS: Мягко говоря сложно представить себе Каспера, занимающегося подобной херней.+1
>> Касперский
> Может все-таки Касперски?
> PS: Мягко говоря сложно представить себе Каспера, занимающегося подобной херней.Этот бобик дезертировал в пиндосию, пущай там и сдохнет.
А у Касперского и Ко, уже во всю идёт разбор полётов на ассмеблере.
http://www.securelist.com/en/blog/208193935/New_64_bit_Linux...Kaspersky Lab already detects this rootkit as: Rootkit.Linux.Snakso.a.
Ключевое слово ALREADY :)
> Kaspersky Lab already detects this rootkit as: Rootkit.Linux.Snakso.a. Ключевое слово ALREADY :)Так и не понял всей важности этого ALREADY и почему это столь ключевое слово в заметке на секлисте. Обычная раздача сэмпла всем заинтересованным парти для анализа с последующей публикацией и своей долей PRа.
С технической точки зрения описываемому в новости руткиту сто лет в обед. Подобные зверьки могли быть интересны да и были в реальном ходу лет 5-8 назад. В том же phrack-е описание схожих или куда более интересных технологий датируется 10ти летней давностью. Сегодня совершенно не интересны в силу массового перехода сервисов на рельсы виртуализации и как следствие отчечения оконечных систем от прямого доступа в ядро. Если же кто-то хостится на железе или разрешает, скажем, загрузку модулей из контейнеров - ну он Сам Себе Злобный Буратино.
Лекарство одно - не оставляйте сервак с дефолтными настройками.# chattr +i /etc/rc.local
Пущай трахаеццо, главное самим не забыть :)
он не сделает chattr -i по религиозным соображением?
Обычно это делают роботы, которым естественно нужно это заложить в алгоритм.
> Обычно это делают роботы, которым естественно нужно это заложить в алгоритм.Ну так боты нам багрепорты на мыло шлют.
Мы ценим пользователей наших продуктов и оперативно обновляем ошибки в коде.
Шанс этого раз в 100 ниже при автоматическом взломе, т е такую фигню юзают менее 1% админов. А если еще и монтировать с ro, то шанс еще возводим в квадрат.
У самого просто ведро из бекпортов. Должно быть чуть более безопасно. Дебиан - известное реше то. Обновления приходят чуть ли не пару раз в год, хотя дыры латаются ежедневно.
Лучше сделай rc.local директорией. Во руткит лулзов словит когда файл как бы есть, но ни разу не пишется, хоть там что. Ибо что есть "запись" в директорию? Олдскульно-классический метод создания лулзов всевозможному софту :)
каталог autorun.inf
Вирусы в панике и часть антивирусов тоже :)
Директория autorun.inf на флеше в корне
> Директория autorun.inf на флеше в корнеНу да, знатное западло самоходным экспонатам :)
>> Директория autorun.inf на флеше в корне
> Ну да, знатное западло самоходным экспонатам :)ничего подобного! последние flash-вирусы (которые были на заре заката WinXP) -- при заражении переименовывали autorun.inf в случайное имя!
...но это делали они не для того чтобы избавиться от директории, а для того чтобы убить другой флэш-вирус. а получилось как раз то что надо! :-)
> заражении переименовывали autorun.inf в случайное имя!Ну поставить ему readonly-hidden-system. Интересно, бывает ли зараза которая допирает и это разминировать?
> Лекарство одно - не оставляйте сервак с дефолтными настройками.
> # chattr +i /etc/rc.local
> Пущай трахаеццо, главное самим не забыть :)отлично! задавайте! следующая версия руткита будет использовать crontab@reboot , а на ваш файл /etc/rc.local будет просто плевать (слешиком гемороя много парсить его (rc.local) всевозможный синтаксис) :)
> завершается вызовом exit 0, команда загрузки модуля размещается после вызова
> exit, т.е. после перезагрузки руткит не активируется.FAIL :)
тем не менее фигня такая есть и кавота заразила )
с этого момента можно считать, что как и венда, линух не обижен "вирусами"и кстате кроме /etc/rc.local никаких признаков отлова не описано
> кавота
> линух
> "вирусами"А вас походу неграмотость заразила :P.
> и кстате кроме /etc/rc.local никаких признаков отлова не описаноа какже -- открыть http://localhost ?
Весь трёп не читал, но стоит отметить факт работы web-сервера с UID 0 и GID 0.
ТОВАРИЩИ,ГОСПОДА,ДАМЫ,ЛЮДИ, СЕРВЕР НЕ ДОЛЖЕН УСПЕШНО ЗАПУСТИТЬ INSMOD.
> Весь трёп не читал, но стоит отметить факт работы web-сервера с UID
> 0 и GID 0.
> ТОВАРИЩИ,ГОСПОДА,ДАМЫ,ЛЮДИ, СЕРВЕР НЕ ДОЛЖЕН УСПЕШНО ЗАПУСТИТЬ INSMOD.Савсем глупый, да? Нигда там не написано про полномочия сервера. А insmod запускается sysvinitом, который естественно от рута.
Пионеры заново открывают для себя stealth технологии начала 90-х годов... Не вижу даже повода для новости. Ну сплайсингом перехват сделали, молодцы, похвально. Ну вставляют в traffic flow свое что-то, так це не отнюдь не ново, для TSR вирусов в свое время это было штатным механизмом внедрения, если приравнять хэндл файла к хэндлу сокета разницы принципиальной вообще никакой. Сигнатуру выловил, нужный код в нужное место вставил.Мода какая-то странная взялась, драйвер грузить. Буткит видать ниасилили или формат elf файлов. Хотя в свете наличия сорцов ядра и заточености под конкретное ядро и конкретную сборку буткит - как 2 пальца.
Двоечники. Хоть бы историю вопроса учили. 20 лет ничего нового.
Всё по кругу идёт... Вот интересно, как с этим бороться (распознавать хотя бы) на живой системе. Сервер не писишка - не отправишь с вребут с ровного места. Действительно только виртуалки, получается. А если живешь на VDS что делать?
> на VDS что делать?Надеяться что хостер не полный дебил :). Хотя в ответственных случаях лучше быть сам себе хостером. Ну там например арендовать дедик и распилить самолично хотя-бы. Так ты по крайней мере будешь в случае чего шпынять сам себя. Целесообразность зависит от соотношения твоей квалификации с хостерскими админами.
> вставляют в traffic flow свое что-то, так це не отнюдь не ново, для TSR вирусов в свое
> время это было штатным механизмом внедрения,Справедливости ради, я не видел вирусов вклинивающихся в TCP/IP стек и дописывающих вредительство именно догрузкой пакетов к легитимным страницам :)
Почему-то такие вещи как резалка баннеров на прозрачном прокси и наличие ip_conntrack_ftp на рутере никого не удивляют (хотя первый из траффик флу вычеррыживает контент а второй траффик флу модифицирует).А вставка данных в траффик флу - уже ппц достижение =)
> А вставка данных в траффик флу - уже ппц достижение =)Ну не ппц достижение, но достаточно оригинально.
> Based on the Tools, Techniques, and Procedures employed and some background information we cannot publicly disclose, a Russia-based attacker is likely.Мдя... Интересно, какие такие Tools, Techniques, and Procedures выдали что он русский..? :)
> Интересно, какие такие Tools, Techniques, and Procedures выдали что он русский..?1. Наши комменты не пишут.
2. Функции, переменные и константы вида: void set_jopa(int s, char *d), pox(), nax(), my_huina(), get_pizdec()
int aa =1234, char *mysss = "ОПА",.... ну и классика - int my_buff[] :)
За каждым таким вредоносом, особенно с такими далеко идущими целями, как в этом случае, виднеются уши Microsoft. А за Microsoft-ом торчат уши спецслужб, которые до скрежета в зубах думают только об одном: тотальном контроле за пользователями, но для этого нужно чтоб на веб-серверах "трудились" оси с закрытым исходным кодом (например, microsoft), чтоб даже админы не знали ответа на вопрос "а чем же на самом деле занимается операционная система и её веб-сервер?". Но свободное программное обеспечение - это главное препятствие к этому аду. Вот бесы и нанимают умных, но продажных спецов, которые придумывают спецсредства для компрометации свободного программного обеспечения. Не дай Бог покачнётся доверие к СПО, - и "1984" Джорджа Оруэла нам покажется раем.
да ты поехавший
Следующее поколение ядра Linux будет с изоляцией модулей?
А какая тогда ось считается безопасной для web серверов, на текущее время ????
IIS
> IISОсобенно безопасно смотрелся недавний эксплойт гулявший в диком виде и прошибающий до кернелмода через закрытые (!!!) udp-порты. Настолько масштабного абзаца в *никсообразных за последние годы просто не припоминается совсем.
>> IIS
> Особенно безопасно смотрелся недавний эксплойт гулявший в диком виде и прошибающий до
> кернелмода через закрытые (!!!) udp-порты. Настолько масштабного абзаца в *никсообразных
> за последние годы просто не припоминается совсем.SCTP hack protocol ?
> А какая тогда ось считается безопасной для web серверов, на текущее
> время ????Та, вместе с которой наняли администратора. Как и было всегда.
> Та, вместе с которой наняли администратора.Администраторы разные бывают. Вон тут у нас несколько экспонатов по форуму ходит, которые сискол от компилера не отличат. Как вы думаете, насколько секурна система с таким админом?
>> Та, вместе с которой наняли администратора.
> Администраторы разные бывают.Здравствуй, Кэптен! Каким еще откровением ты жаждешь поделиться?