Все кто фантазируют на тему https - посмотрите хотя бы прекрасное видео из ТС-поста вконце. Там ясно, что на момент 2017г у cisco уже было готовое решение, работающее на уровне маршрутизаторов, которое детектировало малварный https трафик с вероятностю 99.9% без mitm'а.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Статья 0day RCE в админке ботнета от X-Shar и Jeffs. Делаем обряд препарации.
- Автор темы Rubicon
- Дата начала
- Автор темы
- Добавить закладку
- #42
Это никак не может работать если у нас самоподписанные сертификаты и грамотно реализован TLS (не SSL). Если троян проверяет валидность созданного с С&C HTTPS соединения и не передаёт данные если HTTPS соединение нарушено, то никакое митм решение, будь оно даже корпоративное никак митмить без реверса трояна не сможет. Это будет похоже на то чтобы попробовать смитмить трафик между сайтом и сервером, когда передача идёт по HTTPS с ресурсом который добавлен в HSTS список и при этом у митмящего нету возможности установить свой сертификат в доверенные в само хранилище браузера. Как собственно и делают все эти решения для митма HTTPS трафика, в том числе обычные антивирусы.
Как раз таки для точечных APT атак один сам факт самоподписанного серта - это не будет паливом, потому что там на тачках юзеров стоит просто огромное количество специализированного софта который передаёт инфу используя как раз HTTPS с самоподписанными сертификатами. То есть детектить самоподписанный HTTPS по такому принципу АВ никак не могут, из-за огромного количества ложных срабатываний.
Вообще лучше не использовать HTTPS для передачи данных, он буквально во всём уступает обычному HTTP, просто из-за неоправданной сложности грамотной реализации. Возможно настанет время когда сам факт использования HTTP станет для защитных решений аллертом, но это время ещё не настало и в ближайшем будущем пока не планирует, особенно в корп секторе с огромным количеством легаси софта.
Последнее редактирование:
не смотрел то видео о котором речь, но именно для этого я и написал, что https + encrypted payload. Не панацея разумеется, но сложность в детекте/расшифровке явно прибавит.
- Автор темы
- Добавить закладку
- #44
Я просто пытаюсь донести мысль что шифровать пейлоад два раза нету смысла. Это только прибавит дополнительный код шифрования в троян, а любой дополнительный код в трояне - это увеличение поверхности "атаки" с точки зрения АВ чтобы положить сигнатуру. Отсюда это усложнит поддержку такого софта в том числе и на бекенде. При этом фактически не давая никаких преимуществ.
tls тоже разворачивает. положим, что на уровне бота мы задетектили, что происходит митм. что дальше? если при этом не передавать данные между ботом и сервером, тогда фактически это равносильно отсутствию соединения с сервером.
я не про ав, а в целом про всё то, что можно обозначить как security solutions. в таком случае будет зависеть от конфига, есть ли вайтлисты или какие-то особые правила. допустим, что их нет, тогда оба фактора (самоподписной серт и/или свежий домен) просто попадут в лог с пометкой suspected. если другой (легитимный) софт админ добавил в исключения, чтобы не захламлялся лог подозрительных коннектов, тогда мы будем в этом логе как на ладони. но если честно, я не вижу причины, по которой мы должны упираться в самоподписной серт. иметь полноценный валидный серт и домены с давней регистрацией - не проблема. другое дело, что именно будет видеть железка при анализе расшифрованного трафика.
не могу сказать, что склоняю к дополнительному шифрованию внутри https. считаю более рациональным маскироваться под легитимный траф.
- Автор темы
- Добавить закладку
- #46
В этом то и суть что такие системы не будут активно врезаться в трафик и митмить любое HTTPS соединение, особенно с самоподписанными сертами. Иначе они могут порушить много много эктерпрайз софта.
Не ну тут понятное дело, если предположить что там крутые корп защиты и хорошо настроенные политики по белому и репутационному списку и при этом хорошо работает отдел SOC-а. То обходить всё это уже работа вирмейкера, там уже в бой вступают такие вещи как беспаливные инжекты в доверенные процессы и отправка трафика через них. Это очень обширная и сложная тема.
Все вопросы поднятые тобой - это корпоративная внутрянка, я в этом не являюсь уверенным спецом, у меня лишь базовое понимание того как работает та или иная корп защита, я всё таки пока специализируюсь именно на вебе. Поэтому всё что я скажу далее может быть не верно, но я попробую пояснить то что я имею в виду и ответить на твои вопросы.
Предположим у нас есть условно такая структура корп сети "Клиент на Windows" -> "Firewall" -> "Сервер в интернете". Этот фаервол предположим активно митмит HTTPS, единственное как он это может делать не нарушая целосность HTTPS соединения между клиентом и сервером - это добавить в хранилище браузера и винды свои SSL сертификат в доверенную цепочку корневых сертификатов. После этого он может митмить без нарушения целостности соединения HTTPS любые домены/ip которые подписаны не самоподписанным сертификатом. То есть буквально фаервол будет видеть весь зашифрованный трафик как будто он не шифруется вовсе. Похожую процедуру нужно проходить когда ставишь burp, нужно взять его корневой сертификат и добавить в браузер, только после этого мы можем открыто видеть HTTPS соединения и снифать их.
Отсюда я даже не рассматриваю вариант того чтобы использовать HTTPS соединение с валидным сертификатом. А если софт на винде и удалённый сервер использует самоподписанные сертификаты, то Firewall в сети в такой трафик врезаться и активно его митмить без поломки криптографической целосности которая происходит при различных криптографически проверках в начале соединения не сможет. Из-за этого такое делать Firewall не может в случае с самоподписанными сертами, так как может нарушить целосность HTTPS проверок при установлении соединения и из-за этого нарушить работоспособность кучи софта который просто ставится на винду и работает с сервером используя самоподписанные серты. Всё что может делать Firewall в случае с самоподписными сертами - это анализировать мета дату самого соединение, в данном случае мета информацию сертификатов при криптографическом рукопожатии в момент создания соединения и это буквально всё. Именно по мета дате данных хранящимся в SSL самоподписанных сертификатов которые вирмейкеры не обфусцирует и возможен детект.
Теперь насчёт массовых атак, использовать валидный серт, а не самоподписанный плохая идея тем, что тебе нужно будет покупать кучу доменов и на каждый из них ты можешь взять один сертификат до детекта самого домена или сертификата.
В теории нормально должно это всё выглядить как-то так. Ты берёшь покупаешь сервер с одним или несколькими IP адресами, на этот IP вешаешь самоподписанный сертификат и к этому серверу по определённому IP коннектится по HTTPS соединению сам бот, грамотно проверяя криптографическую целостность соединения и если он видит что идёт митм и криптографическая целостность соединения нарушена - значит идёт какой-то ручной анализ, к примеру реверсер просто нагло начал митмить подставив свой сертификат, троян при этом должен это задетектить и перестать отправлять данные, в таком случае реверсер не сможет снифать трафик никак, ему придётся для этого реверсить сам троян.
Короче, тут столько всяких не нужных сложностей появляется если использовать HTTPS что просто забей. Поэтому HTTPS лучше даже не рассматривать как вариант и делать соединение на обычном HTTP. по сути чтобы тебя не детектили АВ или любые системы всё что тебе нужно в HTTPS протоколе это 3 вещи
1- отправлять любые запросы всегда на корневой URL, то есть на evil.com/ а не на evil.com/example_uri/. В случае с ботнетом из статьи они отправляли разные запросы на разные URI которые являются дополнительной сигнатурой для АВ.
2- клиент не должен от себя добавлять в HTTP какие либо заголовки, тоже самое не должен делать этого и сервер, в случае с ботнетом о котором я написал статью, там всегда в ответе отправлялся CORS заголовок.
3- ключ и значение POST параметра должны быть не предсказуемо разные. Это уже добивается кастомным шифрованием, в ботнете из статьи они шифровали значение ключа Data в котором хранился пейлоад симметричным алгоритмом RC4 и весь value ключа data оборачивали в base64. Но они оставили статичным ключ data, который тоже является сигнатурой. От него нужно либо избавляться, либо так-же шифровать/обфусцировать, а на сервере принимать любой POST запрос который был отправлен по корневому URI, расшифровывать и как-то обрабатывать уже по функционалу.
И теперь если мы сравним сложность грамотной реализации с HTTP + кастомное шифрование и сложность реализации с HTTPS, то очевидно что HTTPS проигрывает во всём, слишком много деталей там нужно учесть, при этом нужно погружаться в криптографию во всю эту целосность с сертификатами, так-же постоянно менять самоподписанные серты на сервере, всё это автоматизировать и т.п. головняк. А если делать это всё ещё на доменах с валидными сертами, то добавляются ещё головняки.
В любом случае весь этот гемморой с сертификатами лучше обойти, это просто даёт дополнительный гемморой, но при этом не предлагает никаких преимуществ перед кастомным шифрованием с обычным HTTP.
А передавать данные просто через TCP стоит только в том случае где это обоснованно функционально, потому что там тоже есть свои сложности.
Надеюсь я донёс мысль и моя клава страдала не зря
Последнее редактирование:
- Автор темы
- Добавить закладку
- #47
Ну а использование доменов не новорегов и с трастом, с этим полностью согласен. Это не так важно в случае с массовыми атаками, но очень важно в случае APT атак.
Решения у него есть.
F5 и FireEye это два разных вендора, так, на минутку.
Через установку своего Root CA, и против этого есть меры защиты в современном HTTPS.
-----
Рубик выше все верно по HTTPS расписал, лайкнуть не могу из-за лимита.
з.ы. а я говорил что вижу боф))
Absolutely my voice for you, Cheers!
- Автор темы
- Добавить закладку
- #51
Перечитав на свежую голову свой текст обнаружил ляп в этом месте. Я имел в виду "всё что тебе нужно в HTTP это 3 вещи". Не HTTPS. Из-за этого сильно меняется смысл моих слов.
Явно крутейшая статья, но, жаль что бага примитивная и такие извращения для реализации, я бы посмотрел на разбор редких багов, не описанных в гугле
Content-legth это длина сообщения HTTP, никакого отношения к длине TCP-сегмента не имеет.
Отслеживать длину сообщения нужно как раз для того, чтобы правильно делить поток байт, отдаваемый сокетом, на сообщения.
ты бы сначала изучил TCP подробнее [x2]
ты бы сначала изучил устройство интернета [x1]
не думай, что пару раз поюзав сокеты, выставив пару флагов, уже познал истину
между твоим ботом и с2 находятся
1) энтерпрайз сеть, если бот аптшка. На пути следования трафика в этой сети встретятся прокси, ферволы, IDS, IPS, другие страшные аббревиатуры. Каждая из этих коробок или виртуальных аплаенсов, чтобы заглянуть внутрь тсп-трафика делает что? Правильно, собирает сегменты в TCP-сессию и дальше работает с потоком байт. Дальше отдает этот же трафик уже по-своему. Контролировать это ты не можешь никак.
2) сеть провайдера, если бот на домашнем ПК или ПК мелкой конторы,
сеть оператора, если бот на смарте.
Здесь аналогично, только главную скрипку играют кеширующие прокси, призванные сохранить трафик (за него оператор платит деньги своему аплинку). Все про сессию и сегменты в силе.
короче, ебаться с размеров тсп-сегментов = тратить время на третьестепенный вектор, в большинстве случаев усилия пойдут насмарку
держи в курсе
Хз к чему вообще твоя капитанская и ЧСВшная простыня. Я писал про необходимость рандомизации длины пакетов (размера запросов\ответов) в кастомном протоколе, реализованном поверх tcp, а не про рандомизацию длины или количества tcp-сегментов. Подобный подход, если не ошибаюсь, был реализован в Zeus Gameover
Мне обидно такое читать, я думал, мы друзья.
А, все, понял.
То есть ты сообщения своего кастомного протокола называешь "пакетами"? Несмотря на то, что они пакуются в байтовый поток TCP и не имеют в общем случае жесткой структуры, как IP-пакеты.
Прости, я просто думал, что говорю с человеком, который хоть немного знаком с инкапсуляцией (4-, 7- уровневые модели, вот это все) и соответствующей терминологией.
Если у тебя кастомный протокол, то решения безопасности ничего о нем не знают. Они видят:
- или поток байт, который отдает сокет (везде где пересобирается сессия), в этом потоке байтов они не могут в общем случае никак отличить одно сообщения от другого, потому что у тебя кастомный протокол. Зачем тогда рандомизировать длину сообщений?
- или IP-пакет с куском TCP-данных, в редких случаях фильтрацци по данным на роутерах без пересборки сессии. Здесь вместо потока байт есть только его фрагмент, та же логика. Если нельзя выделить одно твое сообщение от другого (протокол кастомный и закрытый), то зачем тогда рандомизировать длину сообщений?
Ничего не знать они будут некоторое время. Потом малварь попадёт в лапы ресёрчеру, который её разберет по байтам включая механизм работы кастомного протокола. Далее он сядет и будет думать, какие YARA-правила (надеюсь ты в курсе, что это) написать, чтоб детектить трафик бота. Если все байты в реквестах\респонсах пошифрованы или хотя бы обфусцированны, то написание YARA-rules будет крайне проблемным.
Теперь для чего нужна рандомизация длины запросов\ответов: если ты читал тс-пост, то он там предлагает детектить CC по определённым сигнатурам в http трафике и, в частости, по длине ответа сервера.
При шифрованом кастомном протоколе задетектить по сигнатуре не получится, но всё равно остаётся возможность просканить все ipv4, посылая определенный request-пакет, (который ресёрчер увидел в сниффере допустим) и сохранять те ip, которые вернули response определённой длины. Так вот: при рандомизации длин реквестов\респонсов этот метод не сработает.
Мой фаворит на конкурсе. Надеюсь, автор продолжит радовать нас и в будущем.
Спасибо за статью, для новичка весьма интересно и познавательно, особенно про http запросы, я так предполагаю надо настраивать для C&C типа кастомный пул с заголовками популярных сервисов и при запросе слать рандомный ответ из этого пула, дабы исключить однотипные ответы для детекта трафа. ☺
Отличный материал. Читал и ржал от мысли "если хочешь победить - уничтожь всех конкурентов"
Материал доступный, хорошо разжеван. На счет "налил воды" - не согласен. Если вывалить голые цифры или голый код - это будет не интересно читать. Не нужно превращать статью в техническую документацию. Да, так уходит больше времени. НО, благодаря всему описанию мы видим по какому пути вы шли, как и что находили, на что обращали внимание, как и что пытались делать. В конце-концов, местами, даже ваши эмоции проскальзывают. А это делает материал "живым". Если бы я не стремился оживить свои обзоры - их можно было бы уместить в десяток скриншотов и пару таблиц.
Материал доступный, хорошо разжеван. На счет "налил воды" - не согласен. Если вывалить голые цифры или голый код - это будет не интересно читать. Не нужно превращать статью в техническую документацию. Да, так уходит больше времени. НО, благодаря всему описанию мы видим по какому пути вы шли, как и что находили, на что обращали внимание, как и что пытались делать. В конце-концов, местами, даже ваши эмоции проскальзывают. А это делает материал "живым". Если бы я не стремился оживить свои обзоры - их можно было бы уместить в десяток скриншотов и пару таблиц.