Comments 19
UFO just landed and posted this here
Да уж… как страшно жить на белом свете)) Лишний раз убеждаюсь, что не зря свою домашнюю машинку и ноут (оба под XP) закрыл шлюзом на FreeBSD. Разумная осторожность при серфинге в Сети, антивири и пр. это конечно хорошо и спасает от многих неприятностей, но береженого, как говорится, бог лучше бережет))
А вообще, было бы интересно узнать, если такого вот «зверька» злыдни подсадят на шлюз, то получается, что никак его уже не отловить будет? (если конечно для фряшки тоже аналогичную поделку сумеют сделать) Единственное, что приходит в голову — это ловить по косвенным признакам — странным правилам в ipfw, утечке трафика и т.п. Но это тоже далеко не панацея…
А вообще, было бы интересно узнать, если такого вот «зверька» злыдни подсадят на шлюз, то получается, что никак его уже не отловить будет? (если конечно для фряшки тоже аналогичную поделку сумеют сделать) Единственное, что приходит в голову — это ловить по косвенным признакам — странным правилам в ipfw, утечке трафика и т.п. Но это тоже далеко не панацея…
ну на то он и руткит чтобы все прятать — ни странных правил и траффик будет в пределах нормы. Вот стоит у вас на машинке и ноуте антивирь по дефолту и вроде как обновляется от заразы часто и закрыто все по дефолту да ходите вы через фрю в инет и никто вас не тронет. А вот Фря ваша наружу смотрит и ежели что не успели обновить или закрыли не так — поимеют и не узнаете никогда. Потому что проверок то никаких кроме как «глазками в конфигах» нет. А это в первую очередь поправят.
То обстоятельство, что для на писания руткита под linux понадобились усилия «компании, занимающейся исследованиями в области компьютерной безопасности», а не отдельно взятого кулхацкера 14-и лет от роду не может не радовать.
Интересно, а макюзеры догадываются, что у них установлено? ;-)
Кстати, и вправду интересно, используются ли такие техники в Вин руткитах.
Новость как-то очень слабо переведена. Цитата оригинала:
«DR places a hardware breakpoint on the syscall handler, and the
resulting trap places a memory watch on the syscall_table entry for the
__NR_syscall of the intercepted syscall. It does this for both INT 0x80
and sysenter based system calls.
When the memory watch for the syscall_table entry kicks in, the trap
handler then redirects execution for that syscall to a syscall hook.
»
Т.е. штука в том, что все вызовы кернел мод кода из юзер мод кода осуществляется через так называемое шлюзование, как в Linux, так и в Windows. Оно осуществляется посредством вызова инструкции syscall или sysenter, в зависимости от того, процессор какой фирмы у вас установлен. Также существует специальная таблица для того, чтобы проводить это шлюзование, эта таблица описывает соответствие аргумента, который был записан в регистр процессора, и функции ядра, которая должна быть вызвана. Ребята научились подменять эту таблицу таким образом, чтобы не модифицировать ее вообще. Т.е. система делает syscall, вместо оригинального обработчика срабатывает их обработчик, далее они чего-то делают и передают управление системе.
В общем говоря, они с помощью дебаг регистров процессора, устанавливают точку останова в момент вызова syscall_handler, функции, которая обслуживает syscall, и подменяют ее указатель в регистре eip на свой собственный syscall_handler. Далее они возобновляют выполнение. Их собственный syscall_handler уже производит все необходимые действия. Он содержит свою syscall таблицу. Таким образом они получают полный контроль над шлюзованием и таблицей шлюзования. Ничего нового, раньше можно было просто перезаписывать определенные области памяти, модифицируя syscall таблицу, в их же случае нету модификации памяти, просто подмена указателя syscall_handler. В этом и вся принципиальная новизна, подобные же техники перехвата существовали давно.
Да, такое возможно и в BSD. Думаю, что и в Windows тоже, но из-за закрытости этой ОС прийдется много реверс инжинирить. Да и вообще, подобный метод перехвата Native API функций описал еще для Windows 2000 Свен Шрайбер, и с тех пор большенство существующих файерволлов и руткитов этот метод эксплуатируют (они патчят таблицу шлюзования). Однако в 64 разрядных версиях, Microsoft применяет специальный patch guard, который призван не допустить пропатчивание ядра, но вроде бы он успешно обходиться :)
Если кому интересно, может напишу статью на эту тему с более понятными пояснениями, а не такими абстрактными.
«DR places a hardware breakpoint on the syscall handler, and the
resulting trap places a memory watch on the syscall_table entry for the
__NR_syscall of the intercepted syscall. It does this for both INT 0x80
and sysenter based system calls.
When the memory watch for the syscall_table entry kicks in, the trap
handler then redirects execution for that syscall to a syscall hook.
»
Т.е. штука в том, что все вызовы кернел мод кода из юзер мод кода осуществляется через так называемое шлюзование, как в Linux, так и в Windows. Оно осуществляется посредством вызова инструкции syscall или sysenter, в зависимости от того, процессор какой фирмы у вас установлен. Также существует специальная таблица для того, чтобы проводить это шлюзование, эта таблица описывает соответствие аргумента, который был записан в регистр процессора, и функции ядра, которая должна быть вызвана. Ребята научились подменять эту таблицу таким образом, чтобы не модифицировать ее вообще. Т.е. система делает syscall, вместо оригинального обработчика срабатывает их обработчик, далее они чего-то делают и передают управление системе.
В общем говоря, они с помощью дебаг регистров процессора, устанавливают точку останова в момент вызова syscall_handler, функции, которая обслуживает syscall, и подменяют ее указатель в регистре eip на свой собственный syscall_handler. Далее они возобновляют выполнение. Их собственный syscall_handler уже производит все необходимые действия. Он содержит свою syscall таблицу. Таким образом они получают полный контроль над шлюзованием и таблицей шлюзования. Ничего нового, раньше можно было просто перезаписывать определенные области памяти, модифицируя syscall таблицу, в их же случае нету модификации памяти, просто подмена указателя syscall_handler. В этом и вся принципиальная новизна, подобные же техники перехвата существовали давно.
Да, такое возможно и в BSD. Думаю, что и в Windows тоже, но из-за закрытости этой ОС прийдется много реверс инжинирить. Да и вообще, подобный метод перехвата Native API функций описал еще для Windows 2000 Свен Шрайбер, и с тех пор большенство существующих файерволлов и руткитов этот метод эксплуатируют (они патчят таблицу шлюзования). Однако в 64 разрядных версиях, Microsoft применяет специальный patch guard, который призван не допустить пропатчивание ядра, но вроде бы он успешно обходиться :)
Если кому интересно, может напишу статью на эту тему с более понятными пояснениями, а не такими абстрактными.
Как я понимаю, главная проблема вирусостроения под линух, это, скорее, средства доставки, нежели сам вирус, в этом отношении ничего нового, вроде бы, нет. А, вообще, руткиты под вторым ГПЛ это круто! Вот RMS порадуется.
А что с доставкой? Вон ftp.gnu.org был же поломан в течение полугода. Мало ли что оттуда накачали :)
Так что в ответ на «у меня нет троянов — я на линуксе» можно ответить «может быть у вас хороший руткит и про трояны вы и не узнаете» :)
Вообще интересно, что серьезно тема руткитов под Win появилась относительно недавно (конец 2005 — начало 2006). И публикации, и инструменты — как отдельные, так и интегрированные в антивирусы.
Это хохма есть такая — что есть gcc, который при сборке внедряет заразу. А поскольку сам gcc собирается предыдущими версиями то это так и ползет с незапамятных времен.
Так что в ответ на «у меня нет троянов — я на линуксе» можно ответить «может быть у вас хороший руткит и про трояны вы и не узнаете» :)
Вообще интересно, что серьезно тема руткитов под Win появилась относительно недавно (конец 2005 — начало 2006). И публикации, и инструменты — как отдельные, так и интегрированные в антивирусы.
Это хохма есть такая — что есть gcc, который при сборке внедряет заразу. А поскольку сам gcc собирается предыдущими версиями то это так и ползет с незапамятных времен.
Sign up to leave a comment.
DR Linux 2.6 — руткит принципиально нового типа