Многие вещи в мире информационной безопасности делаются не для того чтобы кому-то навредить, а с научной целью. Подобные тексты расширяют кругозор, предлагают алгоритмы поиска уязвимостей, вовлекают людей в Open Source разработку, учат чему-то новому.
Но Судя по плюсам к комментариям я могу судить, что большинство читателей ждут какие-то шаги раз, два, три, как проэксплуатировать конкретную систему, хотя ни название, ни пре-текст материала ничего подобного не обещают.
Надеюсь, что тем 22-м проголосовавшим "вверх" этот материал показался полезным и они нашли в нем что-то новое для себя, а всем кто голосует "вниз" предлагаю внести вклад в хаб по информационной безопасности, чтобы мы все узнали что-то новое.
А то, что в середине war_and_piece.txt будет ассемблерный код Вас не смущает? Думаете, это никто не заметит? Так же ваш War and Piece должен начинаться с ассемблерных инструкций, которые не вызовут ошибку, так что "серединой книги" не обойдется. В примере выше картинка будет выглядеть точно так же, как и обычные "котики", но одновременно будет являться и шелл-кодом.
Схема атаки здесь не описывается. Здесь описывается способ передачи шелл-кода в виде, в котором он с высокой долей вероятности не будет обнаружен средствами защиты ни во время передачи по сети, ни после передачи.
То что запускает жертва в виде PowerShell скрипта не является эксплойтом и не несет в себе вредоносный код. Это скрипт для скачивания картинки из интернета и проведение с ней каких-то манипуляций. Так что в чем проблема передачи такого файла по сети?
Касательно Rarjpeg — здесь иной принцип работы, не имеющий отношения к принципу, по которому работает DKMC.
Смысл в сокрытии. Шелл-код передается на машину жертвы в виде изображения и файл выглядят в точности как нормальное изображение. Нет ничего необычного в передаче изображения по сети и этот факт может привести к тому, что подобный трафик никак не инспектируется средствами защиты и картинка не будет проверяться антивирусным ПО, даже, если хранится на файловой системе. Антивирус не будет пытаться "запустить" картинку в песочнице, а если Вы передадите шелл-код в виде исполняемого файла, то антивирус может выполнить его в песочнице и заблокировать. То, что мы "запускаем" картинку через Powershell — это, считайте, Proof-of-Concept. Факт, есть, факт, что BMP изображение может являться и картинкой, и шелл-кодом одновременно. Смотря как на это смотреть. Надеюсь, я правильно понял Ваш вопрос и ответил на него корректно.
Набор ограничен, верно. Можно выучить все уязвимости в модулях и тогда будет уже не интересно. Если участники так сделали, то можно сделать свои модули. Я надеюсь, что число модулей будет расти и тогда этот вопрос решится сам собой.
Здесь сказано, что параметр устарел. Сейчас в osmocom серьезные перемены происходят. Многие параметры могут не работать. Я говорил, что нужен пустой конфиг, а у Вас там как-то оказался устаревший параметр. Изучите работу в VTY osmobts и настройте минимум необходимых парасетров.
Уберите вообще все из файла. Потом запустите osmo-bts-trx, подключитесь к ней telnet-ом и настройте через CLI все, что нужно. Что нужно — можно посмотреть в моем конфиге и сделать по аналогии.
Для Pass-the-hash такой токен не подойдет. Но можно провести брутфорс хэша и узнать пароль пользователя. А чем вас не устраивает перебор? Современные фермы неплохо справляются с брутфорсом.
В сети есть множество публикаций на тему NTLM-Relay атак, можете изучит их или взглянуть на мой пример "SMB-Relay при просмотре каталога".
Да, это так опасно и, да, протокол все еще жив, ибо, обратную совместимость никто не отменял и нет так-то просто полностью отключить NTLM везде.
Полученной информацией злоумышленник может распоряжаться как ему вздумается и тут все зависит от конкретного случая. В некоторых случаях, это может привести к полной компрометации всей инфраструктуры компании.
Что же касается блокировки NTLM — об этом можно долго говорить, но это не тема моей публикации. Но, как Вы верно заметили, сперва нужно хорошенько подумать, что вы включаете/выключаете, прежде чем переходить к действиям.
Внутри GSM сети Вы используете TCH/H (Half-Rate) и один телефон может быть отдан под канал TCH/H, а TCH/H, в свою очередь, может обслуживать двух абонентов или один звонок между ними. Если вы подключаете Asterisk через osmo-sip-connector, он может некорректно работать с TCH/H, а потребует TCH/F (тут используются "классические" GSM кодеки). Но один TCH/F может обеспечить один телефон, значит, для двух абонентов Вам понадобится 2 телефона с TCH/F и один с BCCH (Beacon channel). Как-то так. К тому же для создания сети на основе 3-х телефонов, вам понадобится использовать две BTS, подключить их к OpenBSC и так далее, так как transceiver приложение не позволяет 3 телефона подключить, а только 2. В общем, есть над чем работать :) Может быть, у Вас заработает и с TCH/H и кодеком AMR Asterisk, попробуйте.
Каналы неправильно настроены или с виртуалкой проблемы или с железом или собрали jolly ветку новым компилятором… вариантов много одним словом. Начните с проверки конфигов.
Спасибо. Пишите еще, пожалуйста.
Спасибо за ссылки по теме! Это правильно.
Многие вещи в мире информационной безопасности делаются не для того чтобы кому-то навредить, а с научной целью. Подобные тексты расширяют кругозор, предлагают алгоритмы поиска уязвимостей, вовлекают людей в Open Source разработку, учат чему-то новому.
Но Судя по плюсам к комментариям я могу судить, что большинство читателей ждут какие-то шаги раз, два, три, как проэксплуатировать конкретную систему, хотя ни название, ни пре-текст материала ничего подобного не обещают.
Надеюсь, что тем 22-м проголосовавшим "вверх" этот материал показался полезным и они нашли в нем что-то новое для себя, а всем кто голосует "вниз" предлагаю внести вклад в хаб по информационной безопасности, чтобы мы все узнали что-то новое.
А то, что в середине war_and_piece.txt будет ассемблерный код Вас не смущает? Думаете, это никто не заметит? Так же ваш War and Piece должен начинаться с ассемблерных инструкций, которые не вызовут ошибку, так что "серединой книги" не обойдется. В примере выше картинка будет выглядеть точно так же, как и обычные "котики", но одновременно будет являться и шелл-кодом.
Схема атаки здесь не описывается. Здесь описывается способ передачи шелл-кода в виде, в котором он с высокой долей вероятности не будет обнаружен средствами защиты ни во время передачи по сети, ни после передачи.
То что запускает жертва в виде PowerShell скрипта не является эксплойтом и не несет в себе вредоносный код. Это скрипт для скачивания картинки из интернета и проведение с ней каких-то манипуляций. Так что в чем проблема передачи такого файла по сети?
Касательно Rarjpeg — здесь иной принцип работы, не имеющий отношения к принципу, по которому работает DKMC.
Смысл в сокрытии. Шелл-код передается на машину жертвы в виде изображения и файл выглядят в точности как нормальное изображение. Нет ничего необычного в передаче изображения по сети и этот факт может привести к тому, что подобный трафик никак не инспектируется средствами защиты и картинка не будет проверяться антивирусным ПО, даже, если хранится на файловой системе. Антивирус не будет пытаться "запустить" картинку в песочнице, а если Вы передадите шелл-код в виде исполняемого файла, то антивирус может выполнить его в песочнице и заблокировать. То, что мы "запускаем" картинку через Powershell — это, считайте, Proof-of-Concept. Факт, есть, факт, что BMP изображение может являться и картинкой, и шелл-кодом одновременно. Смотря как на это смотреть. Надеюсь, я правильно понял Ваш вопрос и ответил на него корректно.
Набор ограничен, верно. Можно выучить все уязвимости в модулях и тогда будет уже не интересно. Если участники так сделали, то можно сделать свои модули. Я надеюсь, что число модулей будет расти и тогда этот вопрос решится сам собой.
Здесь сказано, что параметр устарел. Сейчас в osmocom серьезные перемены происходят. Многие параметры могут не работать. Я говорил, что нужен пустой конфиг, а у Вас там как-то оказался устаревший параметр. Изучите работу в VTY osmobts и настройте минимум необходимых парасетров.
Конечно
Можно
Добрый день,
Примеры работы всех можно найти на официальном сайте по ссылке выше.
Пример по rli:
cat dict1
qwerty123
Qwerty_123
Qwerty123
123
12345
cat dict2
123
1234
./rli.bin dict1 new_dict dict2
Caching dict1…
Cached 5 lines
Sorting...
Checking dict2 against cache
Lines compared 2
Removed 1 lines from cache
Sorting back to original positions...
Finished!
Removed 1 lines from cache
Writing 4 lines to new_dict
cat new_dict
qwerty123
Qwerty_123
Qwerty123
12345
Пароль 123 был удален из результирующего словаря, так как он изначально был в dict1 и присутствовал в dict2.
Уберите вообще все из файла. Потом запустите osmo-bts-trx, подключитесь к ней telnet-ом и настройте через CLI все, что нужно. Что нужно — можно посмотреть в моем конфиге и сделать по аналогии.
Уберите строки из файла конфигурации, на которые ругается osmo-nitb. Все таймеры попробуйте убрать вообще.
Интересный вопрос, спасибо. Если только FAR не пытается (зачем-то) переходить по вышеупомянутым путям. Думаю, что через FAR бояться нечего.
Верно, никак. (На данный момент по крайней мере)
Для Pass-the-hash такой токен не подойдет. Но можно провести брутфорс хэша и узнать пароль пользователя. А чем вас не устраивает перебор? Современные фермы неплохо справляются с брутфорсом.
В сети есть множество публикаций на тему NTLM-Relay атак, можете изучит их или взглянуть на мой пример "SMB-Relay при просмотре каталога".
Да, это так опасно и, да, протокол все еще жив, ибо, обратную совместимость никто не отменял и нет так-то просто полностью отключить NTLM везде.
Полученной информацией злоумышленник может распоряжаться как ему вздумается и тут все зависит от конкретного случая. В некоторых случаях, это может привести к полной компрометации всей инфраструктуры компании.
Что же касается блокировки NTLM — об этом можно долго говорить, но это не тема моей публикации. Но, как Вы верно заметили, сперва нужно хорошенько подумать, что вы включаете/выключаете, прежде чем переходить к действиям.
Установите libosmo-netif из исходников, как раньше
Да, тоже об этом подумал :) Думаю, они не специально.
Внутри GSM сети Вы используете TCH/H (Half-Rate) и один телефон может быть отдан под канал TCH/H, а TCH/H, в свою очередь, может обслуживать двух абонентов или один звонок между ними. Если вы подключаете Asterisk через osmo-sip-connector, он может некорректно работать с TCH/H, а потребует TCH/F (тут используются "классические" GSM кодеки). Но один TCH/F может обеспечить один телефон, значит, для двух абонентов Вам понадобится 2 телефона с TCH/F и один с BCCH (Beacon channel). Как-то так. К тому же для создания сети на основе 3-х телефонов, вам понадобится использовать две BTS, подключить их к OpenBSC и так далее, так как transceiver приложение не позволяет 3 телефона подключить, а только 2. В общем, есть над чем работать :) Может быть, у Вас заработает и с TCH/H и кодеком AMR Asterisk, попробуйте.
Смотрите последнюю статью в цикле, про атаки. Там рассказываю, как можно. Но, возможно вам понадобится использовать TCH/F, т.е. больше чем 2 телефона.
Каналы неправильно настроены или с виртуалкой проблемы или с железом или собрали jolly ветку новым компилятором… вариантов много одним словом. Начните с проверки конфигов.