• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья 0day RCE в админке ботнета от X-Shar и Jeffs. Делаем обряд препарации.

Отслеживать
Пожалуйста, обратите внимание, что пользователь заблокирован
corax сказал(а):
Спрячь админку за групповым роутом.
Код: 
adm := router.Group("b8c05ca8f5b0a9dcce037d6a9a153001413b2d2be8fc52d812816459d01a5d4d06d568db0411f562bc65e2a7bacb36ba4b38e530ebc7825b9f613667cf7e44f2")
Апи для фронта да, можно было бы спрятать, но не гейт. Путь до гейта можно попробовать зашифровать. Например:
domain.com/?*bcrypt path name hash*
На сервере настроить роут:
router.POST("/:pathHash", Handler)
В функции Handler из контекста вытаскивать параметр по ключу pathHash, сравнивать его с путями, которые нам нужны.
 
Сочная статья, даже не в плане того, что автор нашел уязвимости в коде "шаровой" малвари (хотя очевидно, что ребята теоретики, которые малварь на петоне и го хуярят впервые, типа же проще...), а в плане интересной информации о том, как вычисляется вредоносный пажилойсетевой поток.

Вот прям, бл#ть топ-1, а топ-2 пусть уйдет парнише с хипами. Топ 3-5 под вопросом, но думаю отдать ребяткам со статьями, - "Как я научился кодить" и "Парсер курса валют". Топ-100 можно выдать ребяткам с хсс-ботом, как источнику лулзовматериалов под такие статьи (ой, топ-100 нет, пичаль... тогда пусть будет приз зрительских симпатий)

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

з.з.ы: всё выше сказанное, чисто моё имхо, если что - осуждаю, не одобряю и блм... ауе.
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
А я с апокалипсисом согласен. Халявный ботик вышел. Хз, из интересного там разве-что админка, но и то, кривая, судя по данной статье.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
nullptr сказал(а):
А я с апокалипсисом согласен. Халявный ботик вышел. Хз, из интересного там разве-что админка, но и то, кривая, судя по данной статье.
Фикс админки уже залит на гит. Скоро выйдет так же обновление бота
 
Обе статьи крайне интересны! Еще было бы интересно прочесть в принципе про анализ веб приложений (Blackbox/Whitebox). Используемые инструменты в контексте blackbox/whitebox. Подходы. На что обращать внимание. В общем было бы интересно прочесть Ваш "скомпилированный" опыт в данной теме!
 
Мораль басни про трафик между ботом и СС:
лучше юзать не http с зашифрованым пейлоадом как в сабж-боте, а кастомный TCP протокол, причем такой, чтоб абсолютно все байты выглядели рандомно + рандомизация длины и количества пакетов + рандомизация таймингов
 
Bertor сказал(а):
лучше юзать не http с зашифрованым пейлоадом как в сабж-боте, а кастомный TCP протокол
Кастомный tcp протокол тоже не лучшая идея, кастомный легче обнаружить из потока данных, чем обычный.
https + encrypted payload = меньше будешь выделяться
 
Bertor сказал(а):
Мораль басни про трафик между ботом и СС:
лучше юзать не http с зашифрованым пейлоадом как в сабж-боте, а кастомный TCP протокол, причем такой, чтоб абсолютно все байты выглядели рандомно + рандомизация длины и количества пакетов + рандомизация таймингов

Не правильная мораль. Тут HTTP вообще не причём, тут реализация плоха. HTTP как протокол для связи трояна и C&C является самым оптимальным как по мне, за достаточно редкими исключениями. Главное грамотно реализовывать соединение, без лишних сигнатур на подобии присуствия URI в запросе или нестандартных HTTP заголовков в запросах и ответах. Сам ключ POST запроса должен обфусцироваться чтобы к нему нельзя было привязать сигнатуру, или вообще быть рандомным, значение ключа POST запроса должно быть зашифровано всегда разными ключами. Эту мысль просто не разжевать в двух предложениях, я попытаюсь успеть ещё написать развёрнутую статью про C&C, там максимально полностью разверну эти вопросы.
 
g0bl сказал(а):
https + encrypted payload = меньше будешь выделяться

Тоже не верная реализация. Если ты уже юзаешь HTTPS с самоподписанными сертификатами для шифрования трафика между ботом и C&C то шифровать сам пейлоад который и так уже передаётся полностью по шифрованному трафику нету никакого смысла. Но у HTTPS тоже есть свои серьёзные недостатки для такой задачи, потому что аверы детектят HTTPS по сертификатам которые передаются в открытом виде с уникальными полями в момент создания HTTPS соединения.
 
Bertor сказал(а):
кастомный TCP протокол
Bertor сказал(а):
рандомизация длины и количества пакетов
ты бы сначала изучил TCP подробнее

при использовании TCP у кодера нет контроля за длиной сегментов
 
Rubicon сказал(а):
Тоже не верная реализация.
Скорее не "не верная", а не самая лучшая, но я и не говорил, что она самая лучшая, а просто привел пример, что будет лучше, чем юзать свой кастомный tcp.
Rubicon сказал(а):
Но у HTTPS тоже есть свои серьёзные недостатки для такой задачи, потому что аверы детектят HTTPS по сертификатам которые передаются в открытом виде с уникальными полями в момент создания HTTPS соединения.
Ну тут можно предложить генерацию уникального серта на каждый билд, будет уже меньше совпадений. Выдумывать можно много, главное подогнать под обычный трафик по сети.
Rubicon сказал(а):
я попытаюсь успеть ещё написать развёрнутую статью про C&C, там максимально полностью разверну эти вопросы.
Давай, почитаем
 
g0bl сказал(а):
Скорее не "не верная", а не самая лучшая, но я и не говорил, что она самая лучшая, а просто привел пример, что будет лучше, чем юзать свой кастомный tcp.
"Не верная" имея в виду твои слова использовать HTTPS и через него передавать ещё зашифрованный пейлоад. Неверно в том плане, что нету никакого смысла ещё дополнительно шифровать пейлоад если и так используется шифрованный протокол (HTTPS) для передачи данных.

Ну а сам HTTPS использовать для шифрования и передачи данных конечно альтернатива как вариант, но не оптимальнее чем обычный HTTP с своим протоколом шифрования. Как к примеру сделали авторы ботнета, но у них просто реализация не продумана хорошо, за счёт как раз не опытности и не знания что такие системы детекта шифрованного трафика по мета дате существуют.

g0bl сказал(а):
Ну тут можно предложить генерацию уникального серта на каждый билд, будет уже меньше совпадений. Выдумывать можно много, главное подогнать под обычный трафик по сети.
Не оптимальнее чем HTTP именно из-за этого. Потенциально это приличный головняк, когда решить задачу можно просто взять HTTP + своё шифрование буквально 50 строчками кода что на сервере что и на клиенте.
 
ppdonchiq сказал(а):
ты бы сначала изучил TCP подробнее

при использовании TCP у кодера нет контроля за длиной сегментов
Я имел ввиду длину пакетов кастомного протокола, реализованного поверх tcp. Типа Content-Length в http.
Ну и на практике если отключен Nagle-алгоритм и если длина пакетов небольшая и если буфер отправки не заполнен, то число отправленных tcp-пакетов равно числу вызовов функции send()
 
Если ты уже юзаешь HTTPS с самоподписанными сертификатами для шифрования трафика между ботом и C&C то шифровать сам пейлоад который и так уже передаётся полностью по шифрованному трафику нету никакого смысла.
есть решения типа F5 и fireeye, которые разворачивают ссл траф. к слову, самоподписной серт, как и домен с недавней регой (на практике регистрация не позднее 30 либо 60 дней), тоже палево. но если говорить о массовых прогрузах - наверное, можно забить.
 
Последнее редактирование:
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх