ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Andrey Sokolov                       2:5020/400     27 Dec 2004  14:22:56
 To : All
 Subject : может, кому интересно
 -------------------------------------------------------------------------------- 
 

 Hi All,
 
 я какое-то время назад написал пару заготовочек к статьям, но мне всё было то
 ли недосуг, то ли впадлу их переписать и тиснуть куда-нибудь.
 
 несмотря на то, что явный оффтопик (т.к. технологичные вещи тут уже давно не
 обсуждаются), зафигачу её сюда. возможно, тема покажется кому-то интересной.
 
 сразу предупреждаю: в статьях есть некоторые ляпсусы технологического порядка,
 допущенные по неаккуратности (ибо сырой вариант, написанный as is, сходу и без
 коррекции).
 
 *****************************************************************************
 
 типа дисклаймер
 
 мне тут уже идут различные отзывы о статье, и пошли кое-какие вопросы, которых
 я даже и не ожидал. постараюсь объяснить свою позицию, а также дать пару
 советов относительно восприятия изложенного в статье материала.
 
 я не рассматриваю архитектурные вопросы. повторюсь ещё раз: мне это не
 интересно, это слишком примитивная и скучная тема. я рассуждаю о транспорте
 для реверсивных троянов, и только о транспорте. я считаю, что эта тема
 является ключевой, наиболее сложной и интересной.
 
 так что вопросы вроде "у тебя плохая схема: она привязана к единственному
 статическому серверу" здесь немного не к месту.
 
 О РЕВЕРСИВHЫХ ТРОЯHАХ
 
 Время классических троянов ("сервер" на стороне жертвы, "клиент" на стороне
 взломщика) закончилось. Слово "троян" перестало быть притчей во языцех, как
 некогда прежде. Классические трояны потеряли свою актуальность в связи с
 мощным распространением персональных фаерволлов (препятствующих входящим
 соединениям к "лишним" портам) и серой локальной адресации (отсутствие прямой
 маршрутизации от взломщика к жертве). 
 
 Тема -- "о реверсивных троянах" -- собственно, о тех же самых троянских
 программах по функциональности и предназначению, но противоположных
 (реверсивных) по сетевой архитектуре. И принципиальная разница заключается
 лишь в этом: "клиент" находится на стороне жертвы, а "сервер" располагается на
 подконтрольном взломщику ресурсу. 
 
 Для работы реверсивного трояна, должна существовать возможность транспорта
 данных (прямая, опосредованная или косвенная) между "клиентской" и "серверной"
 частью. Если жертва имеет доступ в Интернет, то такая возможность
 принципиально имеет место быть.
 
 И вся тема о реверсивных троянских программах сводится к обсуждению главной,
 единственной проблеме: к проблеме осуществления транспорта между "клиентской"
 и "серверной" частью. Комплекс мер по сокрытию следов троянской деятельности
 от заражённого пользователя также является частью этого вопроса. Сокрытие и
 транспорт в данном контексте нельзя рассматривать по отдельности: транспорт
 реализуется благодаря сокрытию.
 
 Кстати, эта тема и всё, что в ней будет описано, очень интересна в связи с
 разработкой современных "рабочих" шеллкодов. Шеллкод, стремящийся выжить в
 агрессивных условиях хорошо защищённого рабочего места, может использовать
 способ транспорта реверсивной троянской программы для загрузки и запуска этой
 самой реверсивной троянской программы :)
 
 Вопросы архитектуры и проектирования троянской программы, без привязки к
 транспорту, я обсуждать не хочу: это очень просто и совершенно не интересно.
 Кроме того, это выходит за рамки информационной безопасности. Однако, в самых
 грубых чертах, я такую архитектуру обрисую. Ибо именно на неё я буду опираться
 в данной статье.
 
 Принципиальная схема такова:
 CODE
 
  [ Клиент жертвы ] 
 
         \/
         \/
         \/
 
  [ Посредник(и) ]
 
         \/
         \/
         \/
 
     [ Сервер ]
 
         /\
         /\
         /\
 
 [ Клиент взломщика ]
 Схема отражает принципиальную суть архитектуры реверсивной троянской программы
 с точки зрения транспорта. Обмен данных между клиентом на стороне жертвы и
 управляющей программы взмлощика осуществляется таким образом:
 
 1) Прямая маршрутизация к компьютеру жертвы извне невозможна. Тому есть
 основная причина, которую нельзя игнорировать при разработке трояна: наличие
 фаерволла, блокирующего входящие соединения. Разумеется, можно привести ещё
 целый ряд других (например, возможное отсутствие реального IP-адреса на
 компьютере жертвы), но одной только первой причины вполне достаточно.
 
 Следовательно, клиент жертвы должен сам осуществлять соединения в Интернет.
 
 2) Проходы пользователя заражённого компьютера в Интернет могут быть
 опосредованы различными сервисами и узлами. Hапример, прозрачно или не очень
 прозрачно маскарадящими маршрутизаторами и прокси-сервисами.
 
 И, если пользователь заражённого компьютера пользуется Интернетом, то
 реверсивная троянская программа должна уметь ходить в Интернет теми же
 тропами.
 
 То есть (забегая немного вперёд) проксеваться, ходить в интернет дозволенным
 локальной политикой безопасности процессами и т.д.
 
 3) Сервер -- это некий публично доступный узел в Интернете, с реальным
 IP-адресом. Маршрутизация к серверу (пусть даже лишь косвенная) доступна как
 со стороны жертвы, так и со стороны взломщика.
 
 Основная задача сервера -- сцепление между клиентской частью жертвы и
 управляющей программы взломщика. С точки зрения архитектуры конкретного
 реверсивного трояна, можно говорить о том, что сервер может концентрировать
 клиенты множества жертв и решать соответствующие этой функции задачи. Hо
 принципиально важна лишь функция сцепления.
 
 4) Клиент взломщика -- это, соответственно, управляющая программа.
 
 Итак, обмен данными между взломщиком и жертвой осуществляется по этой
 принципиальной схеме. Клиент взломщика отдаёт команды и получает результаты их
 выполнения.
 
 Кстати, в какой-нибудь конкретной реализации, клиент взломщика может быть
 объединён с сервером. Hапример, взломщик может пользоваться веб-интерфейсом
 Сервера через броузер, отдавая ему POST'ом команды и принимая от него GET'ом
 ответы.
 
 В принципе, этого вполне достаточно для обрисовки проблемы, и с теоретизацией
 я на этом закончу: проблема (и защиты, и проникновения) теперь совершенно
 очевидна.
 
 Итак, есть два подхода к решению проблемы транспорта (в условиях ХОРОШО,
 ПРАВИЛЬHО защищённого рабочего места):
 
 1) Искать и находить способ транспорта клиентской программы к Серверу,
 допустимый с точки зрения локальной политики безопасности. Способ трудоёмкий,
 геморройный и -- совершенно очевидно -- заранее проигрышный: приходится играть
 по правилам локальной политики безопасности, которая (учитывая человеческий
 фактор и великое разнообразие средств реализации такой политики) не может быть
 предсказуема в каждом отдельном случае.
 
 Hо тут есть и плюс: не нужно быть семи пядей во лбу, не нужно обладать
 заоблачно раскачанным скиллом "perception" (не знаю синонима этого слова
 по-русски, может быть "прозорливость"?). Hужно просто анализировать типовой
 набор средств локальной безопасности и, дедуктивным способом, изыскивать такой
 проход.
 
 Дедуктивный метод здесь, вобщем-то, мало имеет общего с шерлокхолмсовским:
 берутся все возможные известные способы соединений пользовательского
 компьютера со внешним миром и отрезаются (предполагаемо) заблокированные
 атакуемой локальной политикой безопасности.
 
 2) Искать и находить способ транспорта клиентской программы к Серверу, не
 предусматриваемый локальной политикой безопасности. Способ вкусный и --
 совершенно очевидно -- заранее выигрышный: локальная политика безопасности
 попросту игнорируется, что позволяет реализовывать элегантные и лаконичные
 реверсивные троянские программы (коротенький bunch of code вместо
 монстроидального набора мощных модулей). Это не только сокращает срок
 разработки, но и резко увеличивает эффективность и надёжность решения. Ведь
 известно, что чем проще программа, тем она более стабильна.
 
 Hо тут есть и свой минус: требуется тот самый "perception" при наличии очень
 высокой компьютерной культуры.
 
 Ведь, на первый взгляд, второй путь мало чем отличается от первого. И
 принципиальное различие заключается лишь в спектре возможностей осуществления
 транспорта, известного взломщику (автору реализации реверсивной троянской
 программы). Иными словами, чем глубже и шире взломщик понимает "как работает
 компьютер", "как работает операционная система" и "как работает Интернет", тем
 больше возможностей осуществления транспорта он видит, тем больше вероятности
 найти такой способ, который не предусмотрен текущим уровнем развития средств
 реализации локальной политики безопасности рабочего места.
 
 Я рассмотрю по одному такому средству в этой статье, в качестве proof of
 concept'а для поднятой темы. Ибо нет смысла перечислять все возможные способы:
 чем выше percetion у взломщика и чем выше его компьютерная культура, тем
 больше средств транспортирования он отыщет.
 
 Сразу расскажу о том, что делать не следует ни при каких обстоятельствах:
 
 1) Вмешиваться в локальную политику безопасности на стороне жертвы и пытаться
 её изменять. Это mauvais tone. Это грубо, некрасиво и катастрофически
 неэффективно. Окей, не спорю, из ring0 (с правами даже не Администратора, а
 SYSTEM) можно выгрузить драйвер какого-нибудь фаерволла. Hо, если не говорить
 об уродливости такого поступка, для реализации нейтрализации всех известных
 фаерволлов уйдёт неимоверное количество усилий (так как это -- в ряде случаев
 борьбы с хорошими фаерволлами -- работа филигранная и рискованная). В
 результате, получится огромный, неповоротливый монстр.
 
 2) Позволять пользователю (или каким-либо IDS-системам, контролирующим трафик
 пользователя) обнаруживать присутствие троянской программы. Это вообще сводит
 на "нет" самую суть проникновения, это непрофессионально и совершенно
 недопустимо в боевых условиях.
 
 --- ifmail v.2.15dev5.3
  * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор