Комментарии 57
Любопытно. Для каких-то локальных сетей удобнее разослать пачку ICMP без установки полноценного TCP-коннекта. Но выглядит жутко опасно, если такое вдруг начнет торчать в интернет.
Из структуры с IP-хедером можно взять source, но чтобы он не был захардкожен надо дополнительно заморочиться, потребуется больше времени и разработки. Это пара строк дополнительного кода, но решение не идеальное. Хочу найти какие-нибудь примитивы, которые позволят обеспечить симметричное шифрование вместо авторизации по источнику и префикса с паролем, надеюсь, кто-нибудь подскажет.
Из структуры с IP-хедером можно взять source
Но ведь такой пакет легко подделать
1. Что будет, если злоумышленник подслушает зашифрованный пакет и через некоторое время пошлёт его повторно? Не выполнится ли команда повторно?
2. Предположим, злоумышленник поменял порядок прохождения пакетов. К чему это приведёт?
3. Предположим, злоумышленник перехватил все пакеты и не пустил ни один из них к серверу. А потом через несколько дней сам начал отправлять перехваченные пакеты на сервер. Что будет?
4. Предположим, злоумышленник подслушал два зашифрованных пакета и произвёл над ними, например, операцию XOR. Не получит ли он в результате XOR от посланных на сервер команд?
5. Предположим, злоумышенник некоторое время слушал трафик, а потом устроил маски-шоу и получил доступ к серверу и хранящемуся на нём паролю. Не сможет ли он после этого расшифровать отправленные на сервер команды?
6. Предположим, злоумышленник знает, какую команду Вы хотите отправить. Он перехватил пакет. Не получится ли у него изменить несколько байтов в зашифрованном пакете и заставить сервер выполнить _другую_ команду?
7. Не получится ли у злоумышленника подобрать пакет, который пройдёт проверку, измеряя время от получения ICMP-пакета до отправки ответа на него? Если пакет, не прошедший проверку, отвергается, то следует рассмотреть случай, когда злоумышленник отправляет _два_ пакета, первый из которых содержит payload, требующий проверки, а второй является обычным ping'ом.
Спасибо, полезно. Я успел обеспокоиться только о получении ключа на основании предсказуемого содержимого пейлода. К мусору надо ещё время добавить и проверять, чтобы исключить реплей-атаку.
От чего это зависит?
Было бы интересно увидеть реализацию отправки «ответа» в icmp reply.
Реализовать полноценное шифрование в данной схеме — задача куда более сложная. Но почему бы и нет?
И, самое главное, в боевых условиях проверяли? Будет ли оно работать когда уже свалился shh? Подозреваю, что вызов /bin/sh не пройдет.
каков максимальный размер ICMP payload?
Сам ICMP-пакет по размерам не ограничен, но есть ограничения на IP-пакет, 65535 байт. Из этого вычитаем 20 байт на заголовок IP-пакета и 8 байт на заголовок ICMP-пакета, получается намного больше, чем моё ограничение.
Было бы интересно увидеть реализацию отправки «ответа» в icmp reply.
Думаю, что это технически невозможно. Как раз потому что ядро крашится, если ждать даже начала выполнения команды.
Будет ли оно работать когда уже свалился shh?
Конкретно это не проверял, /bin/sh никак не зависит от SSH-сервера. Кроме того, SSH работает по TCP, а в моём модуле TCP никак не затрагивается.
Сам ICMP-пакет по размерам не ограничен, но есть ограничения на IP-пакет, 65535 байт.
Насколько я понимаю, это не совсем так. Есть ограничение на ethernet пакет, там что-то порядка 1500 байт. IP поверх него умеет фрагметировать/собирать пакеты большего размера, но врят ли это коснется вашего icmp кетчера.
Думаю, что это технически невозможно. Как раз потому что ядро крашится, если ждать даже начала выполнения команды.
Сохраните вывод команды в некий буфер и при следующем icmp echo отправьте его назад.
Конкретно это не проверял, /bin/sh никак не зависит от SSH-сервера.
Когда у меня на виртуалке заканчивается оперативная память вместе с буфером подкачки, то /bin/sh уже не открывается. Подозреваю, что где то тут же сдохнет и ssh. Ваша идея призвана бороться с подобными случаями. Она с ними справляется? Просто подключая вызов внешней утилиты вы убиваете саму идею обработки команды в ядре. Имеет ли это хоть какой нибудь смысл? С тем же успехом можно было написать свой простейший
Есть ограничение на ethernet пакет
Да, MTU, про него не думал. Если IP-пакет собирается ядром прежде чем попадёт в нетфильтр, то всё будет хорошо. Возможно, зависит от приоритета, надо проверять.
при следующем icmp echo отправьте его назад
Думаю, можно дропнуть этот пакет и потом скрафтить следующий, с соответствующими заголовками, чтобы клиент принял его за родной. Это усложнит сам модуль и потребует непредсказуемого с моим уровнем знаний времени на разработку. Идея всё же хорошая, спасибо.
Когда у меня на виртуалке заканчивается оперативная память вместе с буфером подкачки, то /bin/sh уже не открывается.
Подозреваю, что в этом случае и сама команда рискует не выполниться. Команда ведь всё же не в ядре выполняется, ядро запускает процесс в юзерспейсе. Пока я имел в виду только высокий LA, на случай нехватки памяти, проще будет добавить ключ sysrq:, который будет в обход юзерспейса триггерить нужный обработчик. Там есть и вызов OOM и убийство всех процессов кроме инита.
Телнету надо максимальный приоритет выставить найсом и ионайсом, тогда будет работать.
Все модули должны лежать в /lib/modules, не такой уж незаметный бэкдор.
Постойте, а разве более-менее сетевая flow-based железка по дороге не заменит содержимое нагрузки на random?
У меня до виртуалки ничего не подменялось. Есть сведения о железках, которые точно так делают?
ping ngs.ru -s 1000
Посмотрел wireshark'ом что уходит и что приходит. Полное совпадение.
Большинство мэ анализирует содержимое нагрузки в том числе и icmp. Так что есть вероятность, что в корпоративной сети не взлетит.
Так же всякие системы DDos очень нервно могут реагировать на содержимое ICMP и начать дропать трафик. Понятно, что все зависит от настроек…
Боюсь, что и провайдеры со своими DPI и прочими погремушками могут манипулировать icmp-ями в полный рост.
И вообще, тестирование сетевых штук на виртуалке, установленной на локалхосте, не покажет все богатство красок. Тот же STP на порте, например.
Никакие файрволлы не должны манипулировать содержимым пакетов, разве что только если нужен NAT — но и то с ограниченным числом протоколов.
Суть ICMP echo как раз в том что отправитель получит ровно то что отправил, иначе это сломает много тулзов. Не пустить пакет — другое дело, но менять содержимое — никак.
А вообще идея не нова — уже был модуль ping-sysrq, да и похожие типа icmp shell.
Не специалист в ядерной разработке, но не будет ли тут гонки при работе с cmd_string? Чтение и запись туда ведь никак не синхронизируется, на первый взгляд.
Не понимаю проблему, я даже в C не специалист. cmd_string может перезаписываться разными ICMP-пакетами?
Да, речь в том числе и про это.
Может произойти следующая ситуация:
Пришел 1й icmp-пакет, в cmd_string записалось, скажем, echo hello world и в планировщик поставилась задача.
В момент обработки 2го пакета в cmd_string начало записываться, например killall ssh и "в это же время" планировщик начал выполнять задачу на запуск команды, где из cmd_string началось считывание. И считаться может, к примеру echoall ssh (т.е. совсем не то, что ожидалось изначально).
Похоже на то, что тут нужна некая очередь команд, взятие и добавление элемента в которую будет происходить атомарно.
Интересно, спасибо. Подумаю над этим, когда чуть лучше изучу язык.
Тут не столько язык, сколько проблема конкурентного доступа к памяти. И всплывает она во многих языках.
The code made me cry.
справедливо заподозрив скам
Что это?
Не помешает изучить зачем нужны и как работают skb_header_pointer(), skb_copy_bits() и skb_may_pull().
Déjà Vu: lwn.net/Articles/225946
Обязательно, спасибо! Про фрагментированные echo-пакеты я даже не знал.
«Любой фрагментированный ICMP echo, и получаем kernel panic или перезапись памяти ядра.»
?
Кажется, что синхронная будет проще. Если есть примитивы для асинхронной, то можно и так. Мне кажется, есть возможность для атаки, команды отправляемые на сервер в критичной ситуации однообразны, мало энтропии в полезных данных, поэтому в идеале надо ещё и мусорную нагрузку добавлять.
Вероятно, вы все таки имели ввиду асимметричное шифрование, а не асинхронное?
Ядерный шелл поверх ICMP