Easy Hack. Хакерские секреты простых вещей

Захватываем контроль над Cisco

В этот чудес­ный снеж­ный день в этом прек­расном раз­деле Easy Hack мы зай­мем­ся девай­сами Cisco и раз­берем все основные век­торы атак на девай­сы Cisco, в осо­бен­ности на мар­шру­тиза­торы под опе­раци­онной сис­темой IOS (как самые рас­простра­нен­ные).

Ко­неч­но, начать сле­дует с того, что­бы опре­делить, а зачем их вооб­ще ломать. Чаще все­го пот­ребность зах­ватывать кон­троль над цис­ками появ­ляет­ся в том слу­чае, ког­да необ­ходимо обой­ти какие‑то огра­ниче­ния на уров­не сети. Нап­ример, если мы пыта­емся прор­вать­ся из интерне­та внутрь кор­поратив­ной сети, то кри­во нас­тро­енная цис­ка поз­волит нам про­валить­ся внутрь. Роуте­ры же внут­ри сети час­то выс­тупа­ют в роли фай­рво­лов и филь­тру­ют тра­фик меж­ду сег­мента­ми, что может нам помешать при ата­ках. К тому же c цисок мы можем про­вора­чивать ата­ки типа man-in-the-middle.

В основном ата­ки на цис­ки далеко не rocket-science и сво­дят­ся чаще все­го к перебо­ру уче­ток. К сожале­нию, уяз­вимос­тей, да еще и с пуб­личны­ми экс­плой­тами для цисок прак­тичес­ки нет. При­чин тому мно­го, хотя для нас это не столь и важ­но.

Но для того, что­бы «пра­виль­но» бру­тить, желатель­но узнать кое‑какие под­робнос­ти о внут­ренних решени­ях в IOS (которые во мно­гом будут ана­логич­ным цис­ко и на дру­гих плат­формах: ASA, PIX, CatOS).

Итак, в IOS есть раз­деление поль­зовате­лей по уров­ню при­виле­гий. Все­го их 16: от 0 до 15, где 15 — мак­сималь­ные при­виле­гии, 1 — уро­вень обыч­ного поль­зовате­ля с очень уре­зан­ными воз­можнос­тями, а осталь­ные в основном не исполь­зуют­ся. По умол­чанию, ког­да юзер логинит­ся в сис­тему, у него уро­вень 1, и если он хочет получить при­виле­гиро­ван­ный дос­туп и воз­можность перекон­фигури­ровать устрой­ство, то дол­жен ввес­ти спе­циаль­ный «enable»-пароль (чаще все­го — cisco). Хотя мож­но нас­тро­ить, что­бы сра­зу был 15, и тог­да вво­дить допол­нитель­ный пароль не нуж­но.

При этом на цис­ке изна­чаль­но есть понятие обще­го юзе­ра, для которо­го мож­но уста­новить пароль. И есть «новая» модель раз­гра­ниче­ния дос­тупа, называ­емая AAA (authentication, authorization, accounting), которая поз­воля­ет иметь мно­жес­тво раз­личных поль­зовате­лей с раз­личны­ми пра­вами в ОС, а так­же под­держи­вает внеш­ние хра­нили­ща, исполь­зуя про­токо­лы RADIUS или TACACS+. AAA на IOS необ­ходимо «вклю­чать», что­бы она зарабо­тала.

Все это важ­но из‑за того, что вли­яет на то, где и как бру­тить учет­ки. Обыч­но дос­тупны Telnet, SSH или веб (по HTTP или HTTPS). При этом SSH работа­ет толь­ко с моделью AAA. А Telnet под­держи­вает и вход под общим юзе­ром, то есть ког­да при аутен­тифика­ции мы дол­жны вво­дить толь­ко пароль. Еще более инте­рес­ным может быть web (basic аутен­тифика­ция), который может быть нас­тро­ен на исполь­зование «enable»-пароля для аутен­тифика­ции. То есть в пос­леднем слу­чае мы можем, исполь­зуя «enable»-пароль, вой­ти в цис­ку, слить кон­фиг и из него получить уже обыч­ные учет­ные записи.

Для кон­фигура­ции через веб исполь­зует­ся URL такого вида: http://cisco_dev/level/15/exec (нап­ример, вывод исполь­зуемо­го кон­фига /level/15/exec/-/show/running-config/CR). Хотя знать его нет необ­ходимос­ти, обыч­но там все понят­но. Зато в 2000 году здесь была при­лич­ная бага, поз­воля­ющая обой­ти аутен­тифика­цию: если ввес­ти любой дру­гой уро­вень боль­ше 15 (но мень­ше 99), то цис­ка пус­кала тебя и пре­дос­тавля­ла при­виле­гиро­ван­ный дос­туп. Цис­ки, конеч­но, юза­ются дол­го, но 15 лет — это уж слиш­ком, так что в реале встре­тить такой баг малове­роят­но.

Те­перь нес­коль­ко фак­тов о прак­тике. Во‑пер­вых, брут SSH не пред­став­ляет собой ничего осо­бого, так что подой­дет любая тул­за. Во‑вто­рых, веб‑мор­ды у цисок могут отли­чать­ся от вер­сии к вер­сии, но дос­туп по ука­зан­ному выше URL’у впол­не уни­вер­сален и порож­дает зап­рос по basic-аутен­тифика­ции, то есть ана­логич­но мож­но исполь­зовать любые тул­зы. С тел­нетом дела обсто­ят нес­коль­ко слож­нее. Клас­сичес­кие тул­зы типы Hydra, Medusa, Ncrack могут откро­вен­но false’ить, к тому же бру­тить толь­ко пароль (для стан­дар­тно­го юзе­ра) уме­ет толь­ко гид­ра. Тут на помощь могут прий­ти тул­зы cisco-torch или cisco-auditing-tool. Они, прав­да, очень олд­скуль­ные, но вхо­дят в Kali.

В слу­чае успе­ха и захода на девайс смот­рим кон­фигура­цию:

Сливаем конфигурацию с Cisco через SNMP

Хо­телось бы отдель­ным пун­ктом выделить ата­ки на цис­ки через SNMP. Хотя на боль­шинс­тве устрой­ств SNMP изна­чаль­но отклю­чен, но он дос­таточ­но час­то вклю­чает­ся для уда­лен­ного монито­рин­га и управле­ния девай­сами (к тому же на некото­рых вклю­чен с обще­извес­тны­ми комь­юни­ти‑стрин­гами).

С точ­ки зре­ния самой ата­ки все впол­не стан­дар­тно: бери любимую тул­зу да бруть, если SNMP-сер­вис дос­тупен. Важ­но здесь дру­гое — что в слу­чае успе­ха и «под­бора» комь­юни­ти с пра­вами на запись мы можем получить пол­ный кон­троль над устрой­ством. Ведь мы можем и ска­чать кон­фигура­цию, и залить новую через SNMP. Вот пос­ледова­тель­ность команд:

Нес­мотря на дли­ну, она впол­не прос­та:

• -c private — комь­юни­ти‑стро­ка на запись;
• -v 2c — вер­сия про­токо­ла SNMP (чаще все­го имен­но эта);
• cisco_ip — IP-адрес цис­ки;
• 1.3.6.1.4.1.9.9.96.1.1.1.1.2.444 — спе­циаль­ный цис­ков­ский OID с 444 — слу­чай­ным чис­лом;
• i — тип уста­нав­лива­емых дан­ных (i — integer, a — IP-адрес, s — стро­ка).

Фак­тичес­ки дан­ная пос­ледова­тель­ность ука­зыва­ет цис­ке, что и куда ско­пиро­вать. Пер­вая коман­да опре­деля­ет про­токол TFTP (1 — TFTP, 2 — FTP, 3 — RCP, 4 — SCP, 5 — SFTP). Вто­рая — что копиру­ем запущен­ную кон­фигура­цию (1 — файл в сети, 2 — файл с фле­ша цис­ки, 3 — startup-кон­фиг, 4 — running-кон­фиг, 5 — тер­минал, 6 — фаб­ричный startup-кон­фиг). Тре­тий — что копиру­ем на уда­лен­ный ресурс, то есть файл в сети. Здесь выбор­ка ана­логич­на пре­дыду­щей коман­де. Далее ука­зыва­ем и IP-адрес нашего хос­та, где открыт TFTP-порт. Пятой коман­дой зада­ем, под каким кон­фигура­ция будет сох­ранена у нас. И пос­ледней мы запус­каем копиро­вание, делая соз­данную пре­дыду­щими коман­дами запись активной (1 — active, 2 — notInService, 3 — notReady, 4 — createAndGo, 5 — createAndWait, 6 — destroy).

Та­ким обра­зом, пред­став­ленная пос­ледова­тель­ность будет ана­логом коман­ды в IOS:

Но это мы получи­ли кон­фигура­цию. Для того что­бы ее залить обратно, тре­бует­ся прак­тичес­ки та же пос­ледова­тель­ность, толь­ко коман­ды 2 и 3 поменя­ются мес­тами. Таким обра­зом, мы можем модифи­циро­вать кон­фигура­цию и «подс­тро­ить» ее под наши нуж­ды.

Од­ну из типовых труд­ностей, воз­ника­ющих на нашем пути, пред­став­ляют access-лис­ты — они могут дос­таточ­но чет­ко огра­ничи­вать перечень хос­тов, с которых раз­решен дос­туп на SNMP-сер­вис цис­ки. Но в этом слу­чае нам могут помочь как минимум два метода. Во‑пер­вых, важ­но пом­нить, что SNMP — это UDP-про­токол, в котором отсутс­тву­ет handshake, то есть мы можем под­менить IP-адрес отпра­вите­ля на раз­решен­ный access-лис­том, таким обра­зом обхо­дя огра­ниче­ние. Вто­рое решение — ата­ковать цис­ку с дру­гой цис­ки. Нап­ример, есть спе­циаль­ный management-сег­мент, недос­тупный обыч­ным юзе­рам, через который дос­тупен SNMP на цис­ках. Тог­да в слу­чае, если мы взло­маем одну цис­ку, мы с нее можем отпра­вить SNMP-коман­ды на дру­гие цис­ки (так как у нее есть дос­туп в management-сег­мент), что­бы те сли­ли нам кон­фиг. Фор­мат команд внут­ри цисок таков:

Я думаю, что сопос­тавить осталь­ные коман­ды ты смо­жешь без тру­да.

Ес­ли же вер­нуть­ся к пер­вой час­ти, то для того, что­бы не копиро­вать «вруч­ную», мож­но вос­поль­зовать­ся тул­зами. Вари­ант пер­вый — cisc0wn, вто­рой — snmpblow (вхо­дит в Kali Linux). Snmpblow уме­ет под­делывать IP-адре­са, зато пер­вая более «авто­мати­чес­кая» и может сра­зу отпарсить кон­фиг на инте­рес­ные шту­ки.

Сливаем исходники с систем контроля версий

Сис­темы кон­тро­ля вер­сий (а‑ля Git или SVN) исполь­зуют­ся сей­час пов­семес­тно в хоть сколь­ко‑то орга­низо­ван­ных про­ектах. Очень час­то с помощью их накаты­вают­ся/обновля­ются и веб‑про­екты. Это, в свою оче­редь, может породить ряд проб­лем, если веб‑сер­вер некор­рек­тно (во мно­гом по умол­чанию) нас­тро­ен.

Вся основная проб­лема появ­ляет­ся тог­да, ког­да спе­циаль­ные пап­ки и фай­лы (.git, .svn, CVS…) ока­зыва­ются в дирек­тори­ях веб‑сер­вера, то есть дос­тупны через веб‑сер­вер. Ситу­ация реаль­но впол­не типовая, а поэто­му экс­плу­ата­ция ее нам инте­рес­на.

Но для начала важ­но пом­нить, что сис­темы кон­тро­ля вер­сий хра­нят в себе очень мно­го дан­ных — прак­тичес­ки все изме­нения, которые были совер­шены. Это дает нам воз­можность (не всег­да, прав­да) получить и исходни­ки сущес­тву­юще­го веб‑при­ложе­ния, и то, что было, ког­да оно толь­ко соз­давалось (а зна­чит, и тес­товые, вре­мен­ные учет­ки, которые ког­да‑то были захар­дко­жены в при­ложе­нии, у нас тоже есть воз­можность получить).

Хо­телось бы отме­тить, что не раз уже «всплы­вали» дис­кло­зы исходни­ков в круп­ных про­ектах. Так что этой типич­ной мис­конфи­гура­цией сто­ит вос­поль­зовать­ся.

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

Пер­вый при­мер — SVN до вер­сии 1.7. В ней дирек­тории .svn находят­ся в каж­дой дирек­тории про­екта. Один из самых инте­рес­ных фай­лов — entries, в котором содер­жатся име­на фай­лов и дирек­торий про­екта. Имея их, мы можем к ним нап­рямую обра­щать­ся. Кро­ме того, копии всех фай­лов хра­нят­ся в /.svn/text-base/. Нап­ример, /.svn/text-base/config.txt.svn-base, то есть мы еще и отсю­да их можем получить. При этом важ­но пом­нить, что в зависи­мос­ти от кон­фигура­ции рас­ширение svn-base может не учи­тывать­ся, что может не дать воз­можность ска­чать исполня­емые фай­лы типа PHP.

И еще раз под­чер­кну, что .svn в каж­дой дирек­тории, а потому и entries, и дан­ные, воз­можно, пот­ребу­ется с каж­дой сли­вать.

Вто­рой вари­ант — SVN начиная с вер­сии 1.7 и выше. Здесь мно­гое изме­нилось: дирек­тория .svn при­сутс­тву­ет толь­ко в кор­не про­екта, а не в каж­дой дирек­тории. Фай­ла entries нет, зато появил­ся wc.db, который пред­став­ляет собой базу дан­ных SQLite 3, в которой и хра­нит­ся основная мета­информа­ция о про­екте. Кро­ме того, теперь фай­лы с исходнич­ками лежат в одной пап­ке /.svn/pristine/. Но, что­бы не было проб­лем с оди­нако­выми име­нами в раз­ных пап­ках (а может, и еще какие при­чины были), пол­ный путь до фай­ла пред­став­ляет собой зна­чение SHA-1 от име­ни фай­ла и дирек­торию с пер­выми дву­мя бук­вами хеша. Нап­ример, /.svn/pristine/bb/bb6499b8e938f92a3695fff1afe57edea4b9efb7.svn-base.

Один из боль­ших плю­сов для нас зак­люча­ется в том, что про­пада­ет рас­ширение из име­ни фай­ла, таким обра­зом, мы обхо­дим проб­лему исполне­ния таких фай­лов, как PHP.

Са­ми хешики и соот­ношения с путями до фай­лов мож­но взять как раз из wc.db сле­дующей коман­дой:

И пос­ледний вари­ант — Git. Вся информа­ция хра­нит­ся толь­ко в кор­не, в дирек­тории /.git/. Но струк­тура хра­нения дан­ных там зна­читель­но более спе­цифич­ная. Во мно­гом потому, что в Git фай­лы, дирек­тории, ком­миты пред­став­ляют собой объ­екты, которые и хра­нят­ся уже в фай­ловой сис­теме в дирек­тории /.git/objects со зна­чени­ями хеша SHA-1 в качес­тве под­дирек­тории и име­ни. Так что я поз­волю себе опус­тить это опи­сание. В ито­ге мы име­ем то, что чис­то вруч­ную рас­парсить — дело зат­рудни­тель­ное, раз­ве что файл /.git/index может дать нам перечень имен фай­лов. С дру­гой сто­роны, есть раз­личные тул­зы, которые нам могут помочь. Нап­ример, dvcs-ripper или модуль в OWASP ZAP.

Са­мое при­ятное, что в резуль­тате мы можем получить у себя пол­ностью рабочий Git-репози­торий и прос­мотреть акту­аль­ные исходни­ки, а так­же «исто­рию» ком­митов, то есть про­изве­ден­ных изме­нений в коде.

Получаем plain-text пароли от девайсов Cisco

Итак, у нас есть кон­фиги от цисок. Что даль­ше? Конеч­но, на дан­ном эта­пе мож­но было бы и закон­чить, если мы взя­ли под кон­троль инте­ресу­ющую нас цис­ку и про­кину­ли дос­туп, куда необ­ходимо. Но если нам не повез­ло и на необ­ходимую цис­ку нет дос­тупа, а есть толь­ко на «левую», то мы можем пос­мотреть кон­фигура­цион­ный файл, вынуть пароли­ки и понаде­ять­ся на то, что адми­ны исполь­зовали одни и те же на мно­гих девай­сах. А потому воз­ника­ет задача разоб­рать­ся с фор­матами паролей в девай­сах Cisco.

Преж­де все­го, понять, какой кон­крет­но тип исполь­зует­ся, мож­но либо по виду, либо по иден­тифика­тору. Нап­ример:

7 перед самим закоди­рова­ным/захеши­рован­ным паролем и явля­ется его типом.

Из­началь­но (для IOS) пароли хра­нят­ся в откры­том виде. Это так называ­емый type 0. Ясное дело, что здесь нет необ­ходимос­ти с ними что‑то делать.

Тип 7 так­же не пред­став­ляет труд­ностей для нас, так как это прос­то набор под­ста­новок. Тулз, которые могут его «обра­тить», очень мно­го. Cain&Abel, нап­ример. Нес­мотря на его «сла­бость», от это­го вида кодиро­вания ник­то не собира­ется отка­зывать­ся. Суть здесь в том, что есть мно­жес­тво видов паролей, которые необ­ходимы цис­ке для работы (то есть нуж­на воз­можность получить пароль в изна­чаль­ном виде). Нап­ример, для аутен­тифика­ции по OSPF или RADIUS’e. Хотя исполь­зование это­го типа для хра­нения паролей юзе­ров или enable-пароля, естес­твен­но, небезо­пас­но.

Даль­ше есть тип 5. Он пред­став­ляет собой клас­сичес­кий UNIX-вари­ант солено­го MD5. Нап­ример:

Здесь нам может помочь толь­ко брут либо ата­ка по сло­вари­ку, oclHashcat в помощь с типом 500.

Сле­дующий тип, 4, появил­ся лишь в отно­ситель­но пос­ледних вер­сиях IOS. Это 15-я вет­ка вер­сий (рань­ше были 11, 12, а 13 и 14 про­пуще­ны). Фак­тичес­ки им хотели заменить 5-ю вер­сию и вмес­то MD5 исполь­зовать PBKDF2 (соленую, мно­гоите­раци­онную SHA-256). Да вот слу­чилась «проб­лема» с импле­мен­таци­ей (которую, надо ска­зать, обна­ружи­ли пар­ни из Hashcat’а в 2013 году), и получил­ся обыч­ный несоле­ный SHA-256. Даже хуже типа 5. В ито­ге цис­ка отка­залась от исполь­зования type 4 и говорит о том, что готовит что‑то новень­кое.

При­мер:

В oclHashcat для бру­та исполь­зует­ся тип 5700.

Те­перь нем­ного про ASA и PIX, то есть про фай­рво­лы. В них исполь­зует­ся по умол­чанию имен­но хеширо­вание (на осно­ве MD5 и без соли). А сло­во encrypted дол­жно под­тол­кнуть тебя в пра­виль­ном выборе типа для oclHashCat — 2400. При­мер:

Кста­ти, еще есть «новый» вид в oclHashCat — 2410, в котором вро­де как исполь­зует­ся часть име­ни поль­зовате­ля как соль при хеширо­вании. Но под­робнос­ти это­го мне неиз­вес­тны.

Получаем информацию о роутере Cisco

В зак­лючение темы нем­ного про еще одну при­ятную фичу Cisco-роуте­ров — про­токол Cisco Discovery Protocol (CDP). Это проп­риетар­ный про­токол цис­ки, исполь­зуемый для обна­руже­ния друг дру­га девай­сами цис­ко. Супер­фун­кци­ональ­нос­ти не несет (хотя это зависит от ситу­ации), в основном мас­су инте­рес­ной информа­ции об отправ­ляющей пакет цис­ке (обыч­но один пакет каж­дые 60 с). Он исполь­зует вто­рой уро­вень OSI. Вклю­чен по умол­чанию на мно­гих роуте­рах и рас­сыла­ется на все интерфей­сы (физичес­кие пор­ты) на multicast-адрес — 01-00-0c-cc-cc-cc. С уче­том того что боль­шинс­тво сви­чей скон­фигуре­ны на пересыл­ку мул­тикаст‑зап­росов на все пор­ты (то есть «прев­раща­ют» их в широко­веща­тель­ные), мы без проб­лем в поль­зователь­ском сег­менте име­ем воз­можность дос­таточ­но точ­но узнать о находя­щих­ся в нашем сег­менте цис­ках.

При этом нам не тре­бует­ся ничего делать — лишь вклю­чить wireshark и подож­дать с минуту. А получен­ная информа­ция может быть очень даже полез­на. Это и вер­сия IOS, IP-адрес на интерфей­сах, номер native VLAN’а.

Ес­ли же есть дос­туп на цис­ку, о сосед­них цисоч­ках нам поможет узнать коман­да show cdp neighbors.

Кро­ме это­го, мы можем пос­пуфить CDP-пакети­ки и получить кое‑какие бонусы, но об этом в сле­дующий раз.

И кста­ти, дан­ный про­токол нын­че плав­но заменя­ется на «общий» IEEE 802.1AB Link Layer Discovery Protocol (LLDP).

Спа­сибо за вни­мание и успешных поз­наний нового!