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

Как провести SDRF, используя PDF

Ата­ка SDRF (Same Domain Request Forgery) не нова и появи­лась уже лет пять назад. Пом­нится, я при­сутс­тво­вал на выс­тупле­нии d0znpp из ONsec’а на Сhaos Constractions 2010 года, тог­да и услы­шал впер­вые сам тер­мин и поз­нал все радос­ти самой ата­ки. Надо ска­зать, что веб‑при­ложе­ний и сай­тов, уяз­вимых к ней, наш­лась мас­са, и они сис­темати­чес­ки до находят­ся сих пор. Нес­мотря на то что сама она ког­да‑то опи­сыва­лась на стра­ницах «Хакера», поз­волю себе пов­торить­ся и добав­лю нем­ного новых под­робнос­тей.

Ес­ли говорить без глу­боких деталей, то SDRF во мно­гом похожа на всем извес­тную ата­ку CSRF (Cross Site Request Forgery). Важ­ней­шее раз­личие здесь в том, что при CSRF мы зас­тавля­ем бра­узер жер­твы отправ­лять зап­росы с пер­вично­го сай­та (на который зашел поль­зователь) на дру­гой (где и нуж­но что‑то выпол­нить с пра­вами юзе­ра). Ты зашел на сайт А, а на нем находит­ся код, который зас­тавит твой бра­узер отпра­вить на сайт Б какой‑то зап­рос. Самый важ­ный ком­понент CSRF — куки при зап­росе на сайт Б будут под­став­лены бра­узе­ром авто­мати­чес­ки, а потому зап­рос будет обра­ботан на сай­те Б.

Так вот, SDRF — это ана­логич­ная ата­ка, но про­водит­ся она толь­ко внут­ри кон­тек­ста одно­го сай­та Б. По сути, мы дол­жны впих­нуть на сайт Б что‑то, что смо­жет отправ­лять зап­росы. Если срав­нить с CSRF, роль сай­та А здесь игра­ет сайт Б, а роль сай­та Б — какой‑то исполня­емый код. Теоре­тичес­ки если мы можем вста­вить свой JavaScript- или HTML-код, то это и будет SDRF (ну и по фак­ту так­же XSS). Но чаще все­го SDRF про­водит­ся за счет исполь­зования сто­рон­них пла­гинов, под­держи­ваемых бра­узе­ром, нап­ример Adobe’овских.

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

Нем­ного об огра­ниче­ниях. Для про­веде­ния ата­ки нам чаще все­го необ­ходима воз­можность заг­ружать PDF’ки, SWF’ки на ата­куемый сайт. При­том важ­но, что­бы они попада­ли на тот же домен, который мы ата­куем: секь­юрная прак­тика говорит нам, что поль­зователь­ский кон­тент надо хра­нить на дру­гом спе­циаль­ном домене (который не содер­жит ни фун­кци­она­ла, ни кри­тич­ных кук). Вто­рое огра­ниче­ние воз­ника­ет, если ата­куемый сайт отда­ет нам наш кон­тент с заголов­ком Content-Disposition: attachment (или некор­рек­тным Content-Type), это ука­зыва­ет бра­узе­ру, что файл надо ска­чать, а не открыть с помощью соот­ветс­тву­юще­го пла­гина.

Нем­ного тех­ничес­ких аспектов. С флеш­ками все ясно и прос­то. Фун­кци­онал для генера­ции зап­росов и чте­ния отве­тов есть в ActionScript и хорошо докумен­тирован. А вот с PDF’ками… В PDF как бы раз­реша­ется встав­лять явас­крипт, но он живет там в жес­ткой песоч­нице, которая сис­темати­чес­ки меня­ется, — сов­сем не гуд. А вот FormCalc — еще один под­держи­ваемый Adobe язык — поз­воля­ет делать необ­ходимое: посылать про­изволь­ные GET-/POST-зап­росы, читать и пар­сить отве­ты. Нас­коль­ко мне извес­тно, эта осо­бен­ность ничуть не поменя­лась с 2010 года. Так что при­мер от d0znpp все еще дол­жен отлично работать.

Те­перь нем­ного новос­тей. В 2010 году SDRF-ата­ке (через PDF) были под­верже­ны все бра­узе­ры, в которых был уста­нов­лен пла­гин от Acrobat Reader, исклю­чени­ем был IE. Фиш­ка с ним была в том, что по умол­чанию он PDF’ку сна­чала ска­чивал, а потом уже откры­вал через пла­гин. То есть откры­валась она в дру­гом сай­те (локаль­но), и тог­да уже вме­шива­лось Same Origin Policy, из‑за которо­го перед отправ­кой зап­роса PDF’ка зап­рашива­ла у поль­зовате­ля раз­решение на него.

Но вот минова­ли годы, поменя­лись бра­узе­ры и соот­ношение их исполь­зования у поль­зовате­лей. Кое‑что поменя­лось и с PDF’ками. В бра­узе­рах FireFox и Chrome теперь по умол­чанию (даже если уста­нов­лен пла­гин Acrobat Reader) для откры­тия PDF’ок исполь­зует­ся спе­циаль­ная JS-либа — PDF.js, то есть сам бра­узер пар­сит и отоб­ража­ет PDF’ки. Понят­ное дело, что FormCalc’ом там и не пах­нет, а JavaScript жес­тко порезан (хотя качес­тво это­го дела тре­бует про­вер­ки). Зато IE испра­вил­ся и теперь име­ет обыч­ное поведе­ние: при откры­тии PDF’ок сра­зу откры­вает пла­гин Acrobat Reader’а. Получа­ется, воз­можность про­вес­ти ата­ку умень­шилась в одном мес­те, но при­бави­лась в дру­гом (осо­бен­но в кор­поратив­ном сек­торе, плот­но сидящем на IE).

Как переслать пакет данных из Wireshark’а

При ана­лизе при­ложе­ний я сис­темати­чес­ки стал­кива­юсь со стран­ными про­токо­лами. С Wireshark’ом мож­но заг­лянуть внутрь их, а инет под­ска­жет общие фак­ты. Но иног­да хочет­ся и потыкать их: перес­лать еще разок, изме­нить что‑нибудь и опять пос­лать, срав­нить отве­ты. При­чем, пос­коль­ку вре­мя огра­ничен­но, хочет­ся все делать опе­ратив­но.

Я думаю, мно­гие из нас при­ходи­ли к мыс­ли, что было бы хорошо, если бы в Wireshark’е был редак­тор пакетов: клик‑клик, поменял и отпра­вил. Но пока это­го не слу­чилось, мы вынуж­дены искать иные пути. Фак­тичес­ки задач­ку при­ходит­ся свес­ти к тому, что мы сни­фаем тра­фик в Wireshark’е, находим необ­ходимые пакеты и сох­раня­ем толь­ко их в pcap-файл. А далее каким‑то «редак­тором» их меня­ем на свой вкус и отправ­ляем в канал. Задач­ка при­водит­ся к выбору это­го редак­тора.

Как ни стран­но, одним из глав­ных решений стал scapy (хотя кто бы сом­невал­ся, но о нем чуть поз­днее). Меня же заин­тересо­вал отно­ситель­но молодой и вро­де бы активный про­ект Ostinato. Это GUI-шный муль­тип­латфор­менный (на Python’е) откры­тый генера­тор пакетов, а заод­но и сни­фер. Мож­но либо взять и соб­рать пакет с нуля, а мож­но импорти­ровать из Wireshark’а (фор­мат pcap, pcap-ng — не понима­ет). Далее через GUI мож­но поменять любой из сло­ев TCP/IP-сте­ка, что‑то убрать, что‑то добавить или изме­нить. Так­же мож­но посылать пос­ледова­тель­нос­ти пакетов. По сути, все базовые пот­ребнос­ти пок­рыва­ются. Тем, кто не близ­ко зна­ком со сте­ком TCP/IP, я бы очень посове­товал с ней поиг­рать­ся. В ней «сло­еность пирога» очень чет­ко прос­матри­вает­ся. В качес­тве малень­кого совета — глянь ми­ни‑видео с сай­та, ведь без него «методом кли­ка» с тул­зой не раз­берешь­ся, нес­мотря на всю ее прос­тоту.

Те­перь о scapy. Это мощ­ней­ший инс­тру­мент для генера­ции/обра­бот­ки сетевых пакетов. Фун­кци­она­ла очень мно­го, из короб­ки под­держи­вает­ся боль­шое раз­нооб­разие про­токо­лов. Мож­но вос­создать прак­тичес­ки все сетевые ата­ки или эму­лиро­вать про­токо­лы. Если не зна­ком с ним, то The very unofficial dummies guide to scapy поможет тебе в пер­вом приб­лижении понять, что там и как.

Ну а теперь о решении. Все, что тре­бует­ся, — это про­делать сле­дующее в scapy:

1. От­крыть pcap-файл и сох­ранить пакеты в мас­сив:

   wspkt=rdpcap("path_to_pcap_file")

2. Мож­но пос­мотреть спи­сок получен­ных пакетов в мас­сиве wspkt:

   wspkt.summary()

3. Пол­ностью пос­мотреть кон­крет­ный пакет:

   wspkt[0].show()

4. Не забыва­ем, что нуж­но что‑то еще и отре­дак­тировать. Мож­но обра­тить­ся к опре­делен­ным полям (из пун­кта выше). Нап­ример, поменя­ем MAC:

   wspkt[0][Ether].dst="67:66:66:66:66:66"

5. От­пра­вить какой‑то пакет (нап­ример, вто­рой) из мас­сива в сеть:

   send(wspkt[1])

Как видишь, все тоже впол­не быс­тро и прос­то. Но вот кста­ти, пос­тавить сам scapy под Win — это тот еще гемор­рой.

Как проснифать трафик под Windows без WinPcap

Wireshark и его ана­логи пре­дос­тавля­ют воз­можность сни­фать тра­фик за счет уста­нов­ки WinPcap. Тот, в свою оче­редь, тре­бует уста­нов­ки драй­вера в ОС. Это мы не всег­да можем себе поз­волить, нап­ример если хотим сде­лать все сов­сем незамет­но, с минималь­ными сле­дами в ОС. И пер­вая радость: начиная с вер­сии Win 7/2008 появи­лась встро­енная воз­можность отсни­фать тра­фик! Но под­ход здесь сов­сем дру­гой — не через драй­веры, а за счет логиро­вания событий. Воз­можнос­ти этой под­систе­мы ОС зна­читель­но рас­ширились по срав­нению с прош­лыми вер­сиями.

Од­но из глав­ных понятий в сис­теме логиро­вания — «про­вай­дер». Имен­но про­вай­деры отве­чают за генера­цию событий, которые воз­ника­ют при опре­делен­ных дей­стви­ях поль­зователь­ско­го или сис­темно­го ПО. То есть захоте­ло при­ложе­ние пос­лать HTTP-зап­рос на google.com — дол­жны «отра­ботать» про­вай­деры, которые отве­чают и за резолв име­ни, и от API, отве­чающе­го за генера­цию зап­роса, и от фай­рво­ла с кон­крет­ными дан­ными пакетов. Получа­ется такая стоп­ка блин­чиков… Приз­наюсь, что от глу­бин этой час­ти вин­ды я очень далек, но, думаю, общее опи­сание впол­не кор­рек­тно.

Но про­вай­деров очень‑очень мно­го, у меня на Win 8 нас­читалось око­ло тысячи. И хотя мож­но логиро­вать дан­ные отов­сюду, но очень быс­тро уто­нешь в потоках ивен­тов. При­чем час­то дан­ных с одно­го про­вай­дера может быть недос­таточ­но. Потому есть такое понятие, как сце­нарии — груп­пы про­вай­деров, объ­еди­нен­ные темати­чес­ки.

Пе­речень всех про­вай­деров мож­но получить коман­дой (под адми­ном в кон­соли)

Пе­речень сетевых сце­нари­ев:

Прав­да, с ними дру­гая беда — без ине­та, чис­то по опи­санию об их содер­жании ничего не пой­мешь. Нап­ример, «Раз­решение проб­лем, свя­зан­ных с сетевым адап­тером». Ну да лад­но… Мож­но поп­робовать пос­мотреть, какие про­вай­деры вхо­дят в тот или иной сце­нарий:

В ине­те для того, что­бы отсни­фать тра­фик, пред­лага­ется такая коман­да:

• netsh trace start — стан­дар­тная пос­ледова­тель­ность для запус­ка логиро­вания сетевых событий;
• scenario=NetConnection — выбира­ем сце­нарий;
• capture=yes — ука­зыва­ем, что дан­ные сетевых пакетов необ­ходимо сох­ранять (мож­но хра­нить толь­ко сами события);
• report=yes — соз­дание ито­гово­го фай­ла отчет;
• persistent=no — логиро­вание будет отклю­чено при перезаг­рузке ком­па;
• maxsize=1024 — мак­сималь­ный раз­мер ито­гово­го фай­ла логов в мегабай­тах;
• correlation=yes — груп­пиров­ка свя­зан­ных событий;
• traceFile=C:\Logs\Trace_name.etl — путь до фай­ла с логом событий.

Для оста­нов­ки логиро­вания нуж­на коман­да:

Фак­тичес­ки эта связ­ка работа­ет. Тра­фик сох­раня­ется. Но сце­нарий NetConnection содер­жит в себе очень мно­го про­вай­деров, а потому получа­ется слиш­ком мно­го событий (в том чис­ле лиш­них), и файл с отче­том рас­тет на гла­зах. Для реаль­ных дей­ствий рекомен­дую порыс­кать и выб­рать лишь необ­ходимые про­вай­деры.

На выходе работы под­систе­мы логиро­вания событий мы получа­ем файл в фор­мате etl. Для каких‑то дел он, может, и подошел бы, но для ана­лиза тра­фика реаль­но очень хотелось бы получить pcap, что­бы потом его запих­нуть нап­рямую в Wireshark. Тут нам иног­да может помочь тул­за от Microsoft — Network Monitor. Она по фун­кци­она­лу во мно­гом сма­хива­ет на Wireshark. Поз­воля­ет и сни­фать, и прос­матри­вать содер­жимое пакетов, но, имхо, зна­читель­но менее удоб­на. Но зато она уме­ет читать etl-фай­лы и сох­ранять потом в pcap (хотя и не всег­да с этим успешно справ­ляет­ся).

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

Как проснифать трафик с loopback под Windows

Мы уже не раз касались этой темы в Easy Hack. Лич­но у меня она сис­темати­чес­ки всплы­вает, а потому поиск иде­аль­ного пути про­дол­жает­ся. Дан­ное решение — часть пре­дыду­щей задачи, но для удобс­тва вынесе­но в отдель­ный пункт.

Ока­зыва­ется, что через под­систе­му логиро­вания событий мы можем сни­фать и тра­фик с loopback. При­чем и исхо­дящие, и вхо­дящие пакеты. Все, что необ­ходимо, — это, как я понял, исполь­зовать про­вай­дер Microsoft-Pef-WFP-MessageProvider.

Ин­форма­ция была получе­на при тес­тирова­нии отно­ситель­но нового сни­фера от Microsoft — Message Analyzer. В нем есть отдель­ный пункт про loopback-интерфейс, который и выбира­ет выше­ука­зан­ный про­вай­дер и поз­воля­ет сох­ранять дан­ные пакетов, переда­ваемые по loopback.

Хо­тя сни­фать мож­но и через коман­ду netsh, но Message Analyzer зна­читель­но удоб­нее. Выг­лядит этот про­дукт очень при­лич­но и содер­жит инте­рес­ный фун­кци­онал. Советую взгля­нуть. Но более важ­ный момент — он поз­воля­ет сох­ранить ито­ги в необ­ходимом нам pcap-фор­мате. При­чем иног­да то, что не выг­ружалось нор­маль­но из Network Monitor, получи­лось экспор­тировать Message Analyzer’ом, хотя со ста­биль­ностью здесь еще есть проб­лемы.

Как подыскать аналог ProcMon под nix

Опять‑таки задач­ка, свя­зан­ная с ана­лизом какого‑либо при­ложе­ния, ког­да нам хочет­ся опе­ратив­но пос­мотреть как работа­ет прог­рамма, какие фай­лы она чита­ет или пор­ты откры­вает. На осно­ве таких дан­ных мы най­дем кри­тич­ные фай­лы, воз­можно какие‑то некор­рек­тные пра­ва в ОС. Т.е. это важ­ное под­спорье для понима­ния, как что‑то работа­ет. И если с Windows все сво­дит­ся к набор­чику Sysinternals Tools c его тул­зами ProcMon, FileMon, RegMon, с которы­ми лег­ко мож­но решить пос­тавлен­ные задачи, то как обсто­ят дела с nix’ами, точ­нее даже с Linux-сис­темами? Как это ни стран­но — впол­не хорошо, и даже луч­ше, чем под вин. Чаще все­го мож­но спра­вить­ся с основны­ми задача­ми даже без сто­рон­него ПО (и как обыч­но для nix’ов — раз­личны­ми путями).

Итак, для начала нам поможет коман­да lsof, которая по умол­чанию отоб­ража­ет все откры­тые фай­лы в ОС и про­цес­сы, которые «сто­ят» за этим. Но так как мы ана­лизи­руем кон­крет­ное ПО, то мы можем огра­ничить вывод толь­ко по нему, а точ­нее по его PID’у:

Тул­зень хороша еще и тем, что показы­вает нам перечень под­гру­жен­ных биб­лиотек, а так­же пор­тов, откры­тых дан­ным про­цес­сом (пом­ним, что в nix-сис­темах каж­дая сущ­ность явля­ется фай­лом, поэто­му мы ее тут тоже видим). Иног­да быва­ет полез­но сна­чала най­ти, а что же за про­цесс сидит на кон­крет­ном пор­ту:

Кро­ме того, мож­но «филь­тро­вать» по име­ни поль­зовате­ля:

Ми­нус для нас в том, что если файл (с кон­фигом, нап­ример) был открыт, а на момент запус­ка lsof уже зак­рыт про­цес­сом, то мы его не уви­дим в спис­ке.

Вос­поль­зуем­ся тог­да дру­гой тул­зой, от которой дан­ные момен­ты не укро­ются, — strace (или одним из ее ана­логов). Она фак­тичес­ки монито­рит сис­темные вызовы для какого‑то при­ложе­ния.

Здесь

• –f ука­зыва­ет, что необ­ходимо трей­сить и child’ы (порож­денные про­цес­сы);
• -e trace=open — что нас инте­ресу­ет толь­ко откры­тие фай­лов;
• -p116 — PID про­цес­са, к которо­му при­атта­чит­ся strace;
• -o ~/log — куда сох­ранять логи (ина­че –— на стан­дар­тный вывод).

Ес­ли хотим оттрей­сить с самого запус­ка, то вмес­то -p коман­ду с аргу­мен­тами ука­зыва­ем в кон­це пос­ле парамет­ров.

О’кей, с этой частью разоб­рались. Если есть про­цесс, то понять, куда и ког­да он пол­зает, мы смо­жем. А как нас­чет дру­гой час­ти задач­ки, ког­да у нас есть некий файл и надо узнать, кто и ког­да им поль­зует­ся? Strace здесь уже не помощ­ник, так как он не может монито­рить сис­темные вызовы от всех про­цес­сов.
Рас­смот­рим пару.

Пер­вый — демон Linux auditd. Похож на strace, так­же поз­воля­ет прос­матри­вать сис­темные вызовы, но на уров­не всей ОС. Прав­да, в работе «потол­ще» и тре­бует уста­нов­ки (хотя sudo apt-get install auditd и 600 Кб мес­та…).

Для работы с auditd нам пот­ребу­ется две коман­ды. Сна­чала уста­нав­лива­ем аудит события, исполь­зуя auditctl:

• -w /etc/passwd — путь до фай­ла, который монито­рим;
• -k passwd_mon — ключ, по которо­му мож­но будет най­ти события, отно­сящи­еся к дан­ному пра­вилу;
• -p rw — кон­тро­лиро­вать дос­туп на чте­ние и запись.

Да­лее мож­но пос­мотреть события с помощью коман­ды ausearch:

• -k passwd_mon — как раз ключ, который мы ука­зали ранее.

Две допол­нитель­ные коман­ды. Уда­ление пра­вила (ана­логич­но соз­данию, толь­ко с заг­лавной W):

Спи­сок пра­вил:

Сис­тема ауди­та событий дос­таточ­но мощ­ная. Логи содер­жат мно­го информа­ции. Так что мож­но читать ману­алы и радовать­ся жиз­ни. С ней глав­ное — не пог­рязнуть в оби­лии получен­ных дан­ных.

Ес­ли же тебе нра­вит­ся боль­ше GUI и минимум изме­нений в ОС, то мож­но взгля­нуть на тул­зу glsof. Она написа­на на Java, сис­темати­чес­ки запус­кает lsof, пар­сит его вывод и оставля­ет толь­ко инте­ресу­ющую нас информа­цию. Кир­пично, но работа­ет. С пер­вой задач­кой так­же спра­вит­ся (счи­тай это GUI для lsof). Минус может быть в том, что если за про­межу­ток меж­ду запус­ками lsof про­цесс успе­ет обра­тить­ся к фай­лу и закон­чить с ним работу, то мы это­го в логе не уви­дим.

Еще момент. Одним из пер­вых решений было исполь­зование под­систе­мы inotify, которая дает воз­можность гиб­ко монито­рить дос­туп к фай­лам и пап­кам на уров­не фай­ловой сис­темы. Для дос­тупа к ней исполь­зовал iWatch. Все зарабо­тало быс­тро и чет­ко, кро­ме одно­го важ­ного момен­та — через inotify нет воз­можнос­ти узнать, какой про­цесс про­изво­дит изме­нения.

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