Пятница, 21.07.2017, 19:40
# FreeBSD ГлавнаяРегистрацияВход
Приветствую Вас Гость | RSS
Меню сайта
Категории раздела
Мои статьи [167]
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0
Форма входа
 Каталог статей 
Главная » Статьи » Мои статьи

Атака на Cisco IOS
Атака на Cisco IOS

Дыра, обнаруженная в маршрутизаторах Cisco и обнародованная на хакерской конференции Black Hat 2005 USA, наделала столько шуму, что попала на страницы некомпьютерных газет. О ней много пишут, но все как-то в общих словах - никакой конкретики. Говорят о скором конце интернета, пугают захватом управления магистральных каналов связи, но исходных кодов эксплойта не показывают…

"Я считаю, что должен сделать то, что необходимо, - для страны в целом и национальной инфраструктуры в частности. У меня есть информация, что подрывные элементы уже активно занимаются диверсионной деятельностью против IOS. Я считаю необходимым рассказать всем, что да, IOS уязвима"
Майкл Линн
Немного предыстории

Все началось с того, что 26 января 2005 года телекоммуникационный гигант Cisco Systems обнародовал сообщение о дыре в своей новой операционной системе Cisco IOS, установленной на миллионах маршрутизаторов ("Cisco Security Advisory: Multiple Crafted IPv6 Packets Cause Reload" www.cisco.com/warp/public/707/cisco-sa-20050126-ipv6.pdf). Однако информация была неполной. Технические детали отсутствовали, и добыть их легальным путем не удавалось. Cisco явно что-то скрывала, прячась за туманными фразами, которые можно было трактовать и так, и эдак. Компания ISS (Internet Security Systems), специализирующаяся на информационной безопасности, решилась на собственное расследование. Провести его поручили молодому (всего 24 года), но довольно продвинутому хакеру Майклу Линну (Michael Lynn). Шеф вызвал его к себе на ковер и спросил: "Можешь ли ты дизассемблировать ISO и разобраться с этой уязвимостью?" Ну, какой хакер ответил бы "нет"?

Всю ночь Майкл пил кофе и пытал Cisco, но все-таки нашел… совсем другую дыру, намного более коварную и могучую. К в общем-то безобидной перезагрузке (reload) добавился захват управления, а это уже серьезно. Представитель ISS немедленно позвонил в Cisco и сказал: "Хорошо, мы на 100% не уверены, что нашли тот же самый баг, о котором вы говорили, но наш баг гораздо более серьезен. Вы говорили, что возможен только отказ в обслуживании, но баг, найденный нами, допускает захват управления". Но там не поверили: "Ваш парень лжет. Невозможно выполнить shell-код на Cisco IOS". Майкла снова вызвали на ковер, приказав написать экплойт: "Майкл, твой новый исследовательский проект есть Cisco IOS. Вынь да положь рабочий эксплойт для Cisco IOS, чтобы мы могли доказать, что те редиски неправы".

Весь следующий месяц Майкл провел в ожесточенных исследованиях. Но даже имея работоспособный эксплойт на руках, ISS так и не смогла убедить телекоммуникационного гиганта, что его маршрутизаторы дырявы, как старый галош. Только 14 июня (то есть спустя три месяца!) они выслали инженера, который охарактеризовал себя как "архитектора IOS", чтобы закрыть этот вопрос раз и навсегда. Майкл в присутствии адвоката продемонстрировал работу эксплойта, натянув маршрутизатор по самые помидоры. Это повергло инженера в глубокий шок, но вместе с тем и развеселило: "Вау! Это круто!" Инженер ознакомился с черновой версией презентации, которую Майкл планировал продемонстрировать на конференции Black Hat, и укатил назад в свою компанию…

Майкл Линн – известный хакер, специализирующийся на встраиваемых (embedded) системах, хачиньи ядра, обработке сигналов, криптографии, голосовой телефонии, дизассемблировании и сетевых протоколах. В последнее время сосредоточился на безопасности инфраструктуры критических каналов маршрутизации (securing critical routing infrastructures).

Руководство ISS отнеслось к презентации с большим одобрением: "Эй, ты хочешь выступить на Black Hat'е? Это нам нравится!" И порекомендовало распространить эксплойт среди всех тестеров компании: "Раздай его всем инженерам по продажам и всем бумажным тестерам". Но Майкл опасался за последствия: "Неужели вы не понимаете, что если вы сделаете это, то произойдет утечка?" Руководство, недоуменно пожав плечами, возразило: "Это проблема Cisco". Короче, все шло своим чередом. Презентация готовилась, а конференция приближалась. Неожиданно Майкла вызвали на ковер и под угрозой увольнения запретили упоминать факт дизассемблирования IOS. Затем его пригласил на пиво большой босс из Cisco и предложил отложить презентацию… на год - до тех пор, пока не будет выпущена новая версия операционной системы. Телекоммуникационный гигант осознавал угрозу, но отчаянно не хотел, чтобы ее осознали другие. Сошлись на том, что вместе с Майклом на сцену поднимается парень из Cisco, который скажет "пару слов", очевидно, обозвав докладчика лжецом, но Майкла это не беспокоило. Чтобы развязать себе руки, он уволился из ISS, решив прочитать доклад во чтобы то ни стало. Кто-то же должен предупредить народ об опасности!

И доклад "The Holy Grail: Cisco IOS Shellcode and Remote Execution" был действительно прочитан! Эффект разодрал аудиторию взрывом атомной бомбы. Майклом заинтересовались Военно-воздушные силы, Агентство национальной безопасности и, конечно же, небезызвестный CERT. Они предложили ему подключиться к проекту по разработке антихакерской стратегии выхода из ситуации, но это уже совсем другая история. Вернемся к Cisco, чья реакция оказалась весьма неоднозначной. Во-первых, при содействии организаторов Black Hat она изъяла текст презентации из материалов конференции и конфисковала сопроводительные компакт-диски, заменив их точно такими же, но без доклада. Во-вторых, она обвинила Майкла во всех смертных грехах, в том числе в краже интеллектуальной собственности.

Сейчас Майкла ожидает куча судебных исков и разбирательств, а Cisco ведет охоту на всех тех, кто осмелился выложить копию доклада в интернет. К счастью, всемирная сеть живет по своим законам и любые попытки взять ее под контроль имеют обратный результат. Копии плодятся как кролики. Оригинальную презентацию можно скачать, например, здесь: www.security.nnov.ru/files/lynn-cisco.pdf. А здесь лежит видеоролик, запечатлевший конфискацию дисков в самой "демократической" стране мира: downloads.oreilly.com/make/cisco.mov.
Дыра дыре рознь

Ошибочно считать, что до презентации оборудование Cisco считалось неуязвимым. Так думать мог либо некомпетентный специалист, либо маркетолог. Это не первая и не последняя уязвимость в IOS. Дыры в маршрутизаторах обнаруживались и раньше. За последние пять лет их накопилось около двухсот (!), в чем легко убедиться, посетив сайт CISO: www.cisco.com/en/US/products/products_security_advisories_listing.html. А это только официально подтвержденные уязвимости! Неподтвержденных, естественно, больше.

Существует множество эксплойтов, в том числе и с переполнением буфера, через которые засылается shell-код, берущий маршрутизатор под свой контроль. Их можно найти практически на любом хакерском сайте. Например: www.securiteam.com/exploits/5OP0L1FCAE.html, www.antiserver.it/Cisco-Exploit и т.д. В частности, еще три года назад в Cisco IOS обнаружилось переполнение буфера, приводящее к захвату управления, и был написан демонстрационный эксплойт, выставленный на конференции Black Hat 2002 Asia ("Attacking Networked Embedded Systems" - www.blackhat.com/presentations/bh-asia-02/bh-asia-02-fx.pdf), детально описанный в 60-м номере журнала Phrack ("Burning the bridge: Cisco IOS exploits"). Так что заслуги Майкла и масштабы угрозы сильно преувеличены. Линн не был первопроходцем. Обнаруженная им уязвимость применима только к IPv6 (он же "интернет 2") и только к IP-пакетам, пришедшим с локального интерфейса. То есть хакнуть свой собственный маршрутизатор можно, а чей-то чужой, взятый наугад, уже нет. Вот тебе и власть над магистральными каналами, вот тебе и интернет, поставленный на колени.

Вопреки распространенному мнению, рабочий код эксплойта ни на конференции, ни в сопроводительных материалах так и не был продемонстрирован. Майкл не оставил никаких намеков, в каком направлении рыть, но это не помешало остальным хакерам повторить его подвиг, и дыра была переоткрыта, однако слишком рано говорить о каком бы то ни было практическом использовании. IPv6 войдет в нашу жизнь не через год и не через два, а к тому времени IOS будет повсеместно или практически повсеместно обновлена. Впрочем, кое-где IPv6 все-таки используется (особенно у аплинков), так что всегда можно найти подходящую "дичь".
Свет и тьма в конце тоннеля

Дыры в маршрутизаторах - вполне закономерное явление, которого следовало ожидать. Еще ни одному разработчику не удалось реализовать TCP/IP без ошибок. Обнаруженные уязвимости - симптом тяжелой болезни. До сих пор маршрутизаторы работали лишь потому, что выпадали из поля зрения хакеров, которым намного более выгодно ковырять Windows/LINUX/BSD, а не возиться с Cisco. Оно и понятно. Традиционные операционные системы у каждого стоят на столе, а до маршрутизатора еще дотянуться нужно! Завладеть такой штукой может далеко не каждый, к тому же дизассемблирование IOS требует высокой квалификации и специальной подготовки. Нет никакой готовой информации, и каждый шаг требует кучи исследований. Вместо наезженной дороги перед нами расстилается сумеречная тьма непроходимой местности, усеянной множеством ловушек. Впрочем, не все так сложно. Как говорится, что сделано одним человеком, может быть понято другим. Главное - даже не знания. Главное - это желание и настойчивость.

Cisco наступила на грабли. И скоро получит в лоб. Она выиграла тактическое сражение, но проиграла стратегическую войну. Попытка удержать информацию под спудом породила скандал, а скандал породил интерес. Хакеры всколыхнулись и бросились штурмовать ISO. "Причина, по которой мы это делаем, заключается в том, что кто-то сказал: «Вы не сделаете этого»", - сказал один из них. "Линн не ограничился только идеями, хотя и не сообщил всех деталей. Но он сказал достаточно, чтобы люди могли понять, как им действовать, и они сделали это", - добавил другой.

Всплеск интереса к IOS обещает принести множество новых дыр, так что следующий год должен быть весьма "урожайным". Но как подступиться к маршрутизатору? Монитора нет, клавиатуры нет… Какие инструменты нам понадобятся? Какие машинные языки следует изучить? Короче, для начала исследований нам нужен хороший стартовый толчок.
Внутри маршрутизатора

Архитектурно Cisco состоит из материнской платы, процессора, памяти, шины и интерфейса ввода/вывода. Процессоры довольно разнообразны. В зависимости от модели маршрутизатора, в них может быть установлен и традиционный Intel, и Мотороллер, и MIPS. В частности, на дизассемблерных фрагментах, приведенных в презентации Майкла, легко узнаются PowerPC, так что поклонники x86 отдыхают или в срочном порядке изучают ассемблеры для остальных платформ. Перечень используемых процессоров приведен в таблице 1.

Полностью укомплектованный Cisco несет на своем борту четыре вида памяти:
Энергонезависимую перезаписываемую FLASH, содержащую сжатый образ операционной системы (для сжатия используется библиотека zlib);
Энергонезависимую перезаписываемую NVRAM со стартовой конфигурацией (startup-config);
Энергозависимую перезаписываемую DRAM/SRAM (обычная оперативная память);
Энергонезависимую неперезаписываемую постоянную память типа BootROM, содержащую ROMMON-код, включающий себя процедуру начального тестирования POST, первичный загрузчик IOS - короче говоря, ПЗУ в его обычном понимании.

В усеченных конфигурациях NVRAM может отсутствовать. Подробности можно найти в материале "Cisco Router Forensics" (http://cansecwest.com/core03/CSWcore03-RouterForensics-DDoS-v101.ppt).

Если процессор - сердце маршрутизатора, то операционная система - его душа. В оборудовании Cisco главным образом используются две операционных системы: CatOS и IOS (Internet Operation System), причем последняя намного более популярна, это операционная система реального времени, скомпилированная gcc и подозрительно похожая на BSD. Она основана на монолитной архитектуре ядра, то есть загружаемых модулей нет, во всяком случае, пока. По соображениям быстродействия в ранних версиях оси все процессы работали с одним и тем же образом (image) и разделяли единое адресное пространство (share memory space). Никакой защиты от воздействий со стороны одного процесса на код/данные, обрабатываемые другим процессом, не предусматривалось, что существенно облегчало написание shell-кода. Также имелся псевдомногозадачный планировщик невытесняющего типа "run to completion" (выполнение до завершения). Другими словам, если в NT операционная система сама переключает потоки без участия со стороны программиста, то в IOS поток должен явно вызвать системную функцию для передачи управления. А это значит, что shell-код может легко захватить власть над системой и не давать удалять себя, впрочем, радоваться по этому поводу слишком рано. Начиная с IOS-XR поддерживается и защита памяти между процессами, и вытесняющая многозадачность. (Подробности о структуре IOS можно почерпнуть из книжки "Inside Cisco IOS software architecture" издательства Cisco Press, которую легко найти в любом парнокопытном.)

Поверх ядра накидано множество программного обеспечения, занимающегося самыми разнообразными задачами, - от маршрутизации до "чистки" конюшен, причем в различных "железках" это программное обеспечение сильно неодинаково. И приложения, и ядро работают с одинаковым уровнем привилегий и имеют доступ ко всем системным ресурсам. Программные файлы представляют собой обыкновенные 32-битные статически слинкованные ELF'ы с покоцанной отладочной информацией (ELF 32-bit MSB executable, statically linked, stripped).

Управление маршрутизатором осуществляется через любой внешний порт - от COM-шнурка до telnet-терминала, работающего на TCP/IP. Интерфейс - командная строка. Среди команд есть как документированные, так и недокументированные (подробнее о недокументированных командах можно узнать у старика Гугла: запрос "undocumented IOS command" выдает тысячи ссылок, среди которых встречается немало полезных, в том числе www.xfocus.net/tools/200307/DOTU.pdf).

Вот, например, результат команды "show proc":

Просмотр списка процессов с помощью команды show proc

scep#show proc

CPU utilization for five seconds: 10%/4%; one minute: 14%; five minutes: 14%

PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process

1 M* 0 1248 107 11663 2204/4000 1 Virtual Exec

2 Lst 802DF16 34668 313 110760 1760/2000 0 Check heaps

3 Cwe 801D5DE 0 1 0 1736/2000 0 Pool Manager

4 Mst 8058B20 0 2 0 1708/2000 0 Timers

5 Lwe 80BFD4A 24 46 521 1448/2000 0 ARP Input

6 Mwe 81F78F0 4 1 4000 1744/2000 0 SERIAL A'detect

7 Lwe 80D935A 4 1 4000 1656/2000 0 Probe Input

8 Mwe 80D8CD6 0 1 0 1744/2000 0 RARP Input

9 Hwe 80CA966 80 89 898 3116/4000 0 IP Input

10 Mwe 80F41BA 16 322 49 1348/2000 0 TCP Timer

11 Lwe 80F5EB8 8 3 2666 3244/4000 0 TCP Protocols

12 Mwe 813785E 80 177 451 1588/2000 0 CDP Protocol

13 Mwe 80D5770 0 1 0 1620/2000 0 BOOTP Server

14 Mwe 81112C0 1356 1522 890 1592/2000 0 IP Background

15 Lsi 8121298 0 25 0 1792/2000 0 IP Cache Ager

16 Cwe 80237BE 0 1 0 1748/2000 0 Critical Bkgnd

17 Mwe 802365A 12 5 2400 1476/2000 0 Net Background

18 Lwe 804E82E 16 4 4000 1192/2000 0 Logger

19 Msp 80456DE 80 1493 53 1728/2000 0 TTY Background

20 Msp 802345C 20 1494 13 1800/2000 0 Per-Second Jobs

21 Msp 80233F2 68 1494 45 1488/2000 0 Net Periodic

22 Hwe 80234DC 4 1 4000 1724/2000 0 Net Input

23 Msp 8023482 772 25 30880 1800/2000 0 Per-minute Jobs

24 Lwe 8109834 4 2 2000 3620/4000 0 IP SNMP

25 Mwe 815CE08 0 1 0 1712/2000 0 SNMP Traps

26 ME 811805A 0 26 0 1892/2000 0 IP-RT Background

27 ME 803B0F8 32 11 2909 2760/4000 2 Virtual Exec

Настоящим подарком для хакеров стала команда "gdb", вызывающая встроенный отладчик и поддерживающая следующие подкоманды:

gdb

debug PID /* не реализовано */

examine PID /* отладка процесса с указанным PID */

kernel /* отладка ядра, работает только с консоли */

Однако, прежде чем использовать отладчик, его необходимо скомпилировать. Идем на www.gnu.org/software/gdb/download, берем копию посвежее или, наоборот, постарее (предпочтительно использовать gdb-4.18, как наиболее протестированную) и говорим:

mkdir m68k-cisco

../configure --target m68k-cisco

make

В результате мы получим двоичный файл для платформы m68k. Для остальных платформ компиляция осуществляется аналогичным образом. Теперь можно начинать отладку! Консоль в это время будет нефункциональна, а весь обмен с отладчиком пойдет через его собственный отладочный протокол, описанный в исходном файле remote.c. На маршрутизаторе устанавливается серверная часть отладчика, а на терминале - клиентская. Причем отладка ядра (подкоманда kernel) возможна только с консоли.

Дадим команду "gdb examine 18", где "18" – идентификатор отлаживаемого процесса (в данном случае "logger"). Подробнее обо всем этом можно прочитать на сайте команды XFocus: www.xfocus.net/articles/200307/583.html). Основные отладочные команды перечислены в таблице 2.

Для отладки желательно иметь символьную информацию, однако IOS - это закрытая система с закрытыми спецификациями (ну, не такими уж и закрытыми, если учесть, что это порт BSD, унаследовавший родимые пятна багов в zlib, ssh и SNMP), и символьной информации не достать (во всяком случае, через легальные каналы), тем не менее, корпеть над дизассемблированием дампа не придется.

В мае 2004 года корпоративная сеть Cisco Systems была взломана и исходные тексты системы IOS 12.3, 12.3t попали в руки хакера по кличке franz, который распространил через IRC небольшую часть сорцов (~2,5 Мб) в качестве доказательства. Самое интересное, что Майкл обнаружил бага именно в этом месте. Подозрение усиливается тем фактом, что дизассемблировать IOS за ночь современно невозможно, а именно столько потребовалось franz'у для анализа.

К настоящему времени исходные тексты просочились в Сеть, и теперь их можно найти в любом парнокопытном. Полный объем архива составляет 800 Мб, и его перекачка на Dial-Up'е может занять несколько месяцев, однако она стоит того! Впрочем, отсутствие исходных текстов - это еще не преграда. IDA Pro в руки – и поехали.
Где и как искать дыры

Приемы поиска переполняющихся буферов в Cisco IOS мало чем отличаются от приемов для других осей, но в ней есть и свои особенности. Стек используется крайне редко, в основном она налегает на кучу. По сообщениям Cisco, разрушение кучи - наиболее распространенный баг ее маршрутизаторов. Но вот о том, что причиной разрушения являются переполнения динамических буферов, она предпочла умолчать. Так что дыры есть! Методика переполнения кучи подробно описана в моей книге "Hacker shellcoding uncovered" и в статье "Once upon a free()" из 57-го номера Phrack'а. В IOS все блоки памяти объединены в двунаправленный список следующего типа:

foo->prev->next = foo->next;

foo->next->prev = foo->prev;

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

*prev=*next;

*(next+20) = *prev;

Результатом этой операции становится запись в ячейки *prev и *(next+20) значений *next и *prev. Если в результате переполнения нам удастся подменить поля prev и next, мы сорвем банк, получив возможность писать произвольные данные/код в любое выбранное место. Эта техника (кстати, она разработана хакерами FX и KIMO) получила название "Uncontrolled pointer exchange", но, прежде чем воспользоваться ей, необходимо познакомится со структурой кучи. Она довольно проста:

Вначале идет так называемый магический номер (MAGIC), равный AB1234BCh, а в самом конце - Красная Зона (REDZONE), равная FD1001DFh. Обе выполняют охранную функцию, и нельзя затирать их. Значение указателя prev проверяется перед освобождением, и потому должно быть валидно. В упрощенном виде проверка выглядит так:

if (next_block->prev!=this_block+20) abort();

Еще проверяется значение поля Size + Usage, старший бит которого определяет занятость блока (0 - свободен, 1 - занят), что создает проблемы при строковом переполнении, поскольку мы не можем располагать здесь нули, а минимальное значение, которое мы можем получить, получается слишком большим (7F010101h). Однако тут есть обходной путь. Поскольку переполнение разрядной сетки никем не контролируется, использование значений типа 7FFFFFFFh даст ожидаемый результат.

Остальные поля никак не контролируются и могут содержать любые значения. Короче говоря, написание shell-кода вполне возможно. Операционная система IOS использует статические адреса (а это хорошо!), но они меняются от одного билда к другому – вот это плохо. Поэтому, прежде чем атаковать жертву, необходимо тем или иным способом определить версию IOS (иначе червь сдохнет еще в зародыше), что можно сделать через CDP или SNMP.

Еще хуже, что IOS контролирует целостность кучи и автоматически перезагружает маршрутизатор, если цепочка ссылок (chunk linkage) оказывается разрушенной. За это отвечает специальный фоновой процесс, в зависимости от загрузки маршрутизатора пробуждающийся каждые 30 или 60 секунд. Именно он проверяет магический номер и красную зону. Так что shell-коду отпущено совсем немного времени. Конечно, 30 секунд – это целая вечность для процессора, за это время можно не только внедриться в целевое железо, но и заразить множество соседних маршрутизаторов. FX с KIMO предложили несколько решений этой проблемы, но все они оказались нежизнеспособными. Майкл был первым, кому удалось нащупать правильный путь, простой, как и все гениальное.

Оказалось, что процедура abort(), выполняющая перезагрузку, использует специальный флаг-семафор, предотвращающий повторное вхождение (по такому же принципу устроена защита от многократного нажатия <Alt>-<Ctrl>-<Del> в NT). Если мы установим его в единицу, функция abort() тут же выполнит return без всякий перезагрузки. Ниже приведен ее ключевой фрагмент. (Впрочем, маршрутизатор все равно будет перезагружен через некоторое время, так как куча разрушена, так что shell-коду надо спешить.)

stwu sp, var_18(sp)

mflr r0

stmw r29, 0x18+var_C(sp)

stw r0, 0x18+arg_4(sp)

lis r9, (crashing_already_ >> 16)

lwz r0, (crashing_already_ & 0xFFFF)(r9)

cmpwi r0, 0

bne loc_80493D18 # return
Программа для расчета контрольных сумм

Ни одна из версий IOS, работающих на платформе M68K, не использует аппаратные механизмы контроля памяти, предоставляемые MMU (Memory Management Unit – блок управления памятью), поэтому запись в кодовый сегмент проходит вполне беспрепятственно. Для защиты от непреднамеренного разрушения используются контрольные суммы. Каждые 30 или 60 секунд специальный процесс сканирует кодовый сегмент на предмет проверки его валидности и перезагружает маршрутизатор, если контрольные суммы не совпадают с расчетными. Однако против преднамеренной модификации эта "защита" уже не срабатывает, поскольку контрольные суммы легко пересчитать и подправить. Это можно сделать, например, так:

// (c) freedemon

#include <stdio.h>

unsigned char const hexchars[] = "0123456789abcdef";

char tohexchar (unsigned char c)

{

c &= 0x0f; return(hexchars[c]);

}

int main(int argc, char **argv)

{

unsigned char checksum; int count; char *command; char ch;

if (argc <= 1) exit(1); printf("gdb protocol command: ");

command = argv[1]; putchar ('$'); checksum = count = 0;

while ((ch = command[count]))

{

putchar(ch); checksum += ch; count++;

}

putchar('#'); putchar(tohexchar(checksum >> 4));

putchar(tohexchar(checksum)); putchar('\n');

}

На платформе MIPS операционная система IOS ведет себя иначе. На стадии инициализации она перепрограммирует MMU, запрещая модификацию кодового сегмента. Любая попытка записи в эту область вызывает крах системы и последующую перезагрузку маршрутизатора. Против непреднамеренной модификации этот механизм действует очень хорошо, но здравомыслящий хакер после пятого пива сможет легко обойти его. Идея заключается в отображении одной из физических кодовых страниц на область данных в записываемый регион. Аналогичный трюк, кстати говоря, используется и для модификации ядра NT. В частности, он применяется во многих брандмауэрах и утилитах Марка Руссиновича.
Источники

Вот три основных источника данных для поиска переполняющихся буферов: исходные тексты, обновления firmware и дамп памяти. Исходные тексты хороши тем, что их легко читать, но они не дают никакой информации о реализации системы на конкретном маршрутизаторе, к тому же их добыча, вообще говоря, не совсем законна. Firmware, как правило, упакован, и перед дизассемблированием необходимо распаковать его, причем сделать это не так-то просто, потому как Cisco слегка покалечила заголовок. Майкл использовал WinRAR, другие хакеры используют zlib и пишут свой распаковщик самостоятельно. Дамп памяти, создаваемый либо по команде, либо в результате краха системы, часто бывает сильно поврежден, и дизассемблировать его непросто. С другой стороны, он содержит реальный образ рабочей системы, поэтому наиболее точно отображает текущее положение дел.
Надолго и всерьез

Операционная система IOS распространена чрезвычайно широко: она встречается и в коммутаторах, и в маршрутизаторах, и в точках доступа, однако не стоит думать, что, обнаружив новую дыру, мы сможем взять все эти устройства под свой контроль: в них используются различные процессоры и различные версии IOS, так что с каждой железкой приходится воевать индивидуально. А вот хорошая новость. В отличие от серверов и персональных компьютеров, далеко не весь парк IOS-оборудования позволяет обновлять прошивку, а даже если и позволяет, далеко не каждый администратор об этом задумывается всерьез. И самое главное. Ты спросишь: "Взлом Cisco – это хорошо, но причем тут «мобильный взлом»?" Все очень просто: Cisco IOS можно взломать и с ноутбука :-).
Категория: Мои статьи | Добавил: Admin (07.10.2011)
Просмотров: 1055 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск
Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Copyright MyCorp © 2017Сделать бесплатный сайт с uCoz