Архив недели @sergeybelove
Понедельник
Юхуу! Всем привет! Эта неделя будет неделью безопасности :) С вами на связи - @sergeybelove. Я наметил очень много тем, держитесь! (:
Я 2 года занимался безопасностью в американском стартапе (реклама для мобильных устройств) и 3 года работаю в @DSecRU / @erpscan.
В основном занимаюсь атакой, а не защитой. Писал на хабр (habrahabr.ru/users/belove/) и в @XakepRU. Выступаю на конференциях, в РФ и зарубежом
CodeFest (3 раза :3), РИТ++, CEE-SECR, FrontendConf, OWASP (RU & PL), Hack In Paris, ZeroNights и другие. Также одно время багхантил/баунтил
Находил уязвимости в VK, Telegram, Yandex, Google, CloudFlare, Badoo, Digital Ocean и у др. В общем, давайте к делу - конец прошлого года
Я как раз интересовался безопасностью фронта, около JS технологиями и платформами. Поэтому есть что сказать на эту тему.
Твит для ретвита: habrahabr.ru/company/dsec/b… -
статья про (Не)безопасный frontend. Здесь отразил большинство проблем безопасности фронта.
Конечно, основная проблема безопасности frontend - нарушение SOP. Но и с SOP не все так просто, он не всегда зависит от [scheme][host][port]
На эту тему был воркшоп на ZN 2013 - 2013.zeronights.org/includes/docs/… от @kkotowicz (сейчас в Google). Просто полистайте слайды, они самодостаточны.
@jsunderhood @sergeybelove привет. Помню вас по лекции по security в JetBrains, было интересно
Привет, спасибо! Да, было приятно получить отзывы ) dsec.ru/news/press/the… twitter.com/huston007/stat…
Вкратце: в java applets хост не имеет значения (если ip1 = ip2), IE - порт не учитывается, cookies - могут ставить с поддомена на основной
Вот с куками как раз много подстав. Так, например, на гитхабе были cookie бомбы от @homakov (ставим большую куку, получаем client side DoS)
Или @i_bo0om использовал этот трюк на последнем PHDays bo0om.ru/telegram-love-… для эксплуатации уязвимости в веб-версии телеграмма
Я к чему - нельзя доверять поддомены кому попало. Иногда cookie injection довольно просто находится, когда он нужен, например для XSS.
Соответственно относимся к cookies недоверительно (при обращении из js) и санитайзим значения, если подставляем их в DOM.
Кстати, про термины! Санитайзим - обезопасиваем (энкод в html сущности), эскейпим - ставим \ перед нужными символами (кавычки как пример)
Фильтруем - значит не пропускаем (вообще) или вырезаем какую-то часть входящих данных. Поэтому при работе с юзер контентом мы санитайзим
(речь про XSS). Что пользователь ввел - то и должно получить на экране, но в "безопасном" виде, после санитайзинга. Ничего не режем.
В случае, если юзеру нужно дать HTML и тут же его подставить в DOM - используем github.com/cure53/DOMPuri… от @cure53berlin. Там все в доках.
Тут подсказывают, что с терминологией в ИБ - беда. Санитайзинг/эскейпинг/фильтрация, XSS - уязвимость/атака, и мн. др. Пропустим это)
Вообще, все, что привносит новый веб - и усложняет атаки (например, как CSP), но и расширяет attack surface, такие вещи как postMessage
Но остаются и "смешные" проблемы, например как с window.opener. Который работает по сей день(и даже в ФБ, хоть их shim и срежет при жалобах)
Демка на facebook - facebook.com/sergeybelove/p… (открывать в браузере, кликнуть, выполнит JS во вкладке с FB, origin изолирован)
@jsunderhood как изменился подход к поиску уязвимостей за последние скажем лет 5? Что-то произошло революционное или подходы все те же?
Cтало больше фреимворков, меньше типичных багов (в лоб). Выгоднее (по импакту) искать логические/бизнес баги. twitter.com/xufocoder/stat…
Демка на facebook - facebook.com/sergeybelove/p… (открывать в браузере, кликнуть, выполнит JS во вкладке с FB, origin изолирован)
Ну так, кто-нибудь тестировал? twitter.com/jsunderhood/st… :) Вообще - всегда задавайте вопросы, если возникают по ходу.
@jsunderhood ещё не залатали
Они и не будут латать, мол shim если надо - вступится facebook.com/notes/facebook… twitter.com/safinalexey/st…
Что-то ответов не так много. Как оно вообще?) Ни комментов, ни результатов клика по ссылке, только один дм) Стоит:
🤔
41.5% Больше разъяснять🤔
41.5% Закидывать больше хадкора🤔
16.9% Продолжать в том же духеВторник
Вы сами в курсе, к чему эта картинка тут :(
Но вернемся к нашей теме. Или это хорошее трололо, или так и есть - ровно поровну народ хочет и простых вещей и хардкора. Начнем со сложного
Задача: найти значение, которое при клике на "Render" приведет к DOM XSS (например, выполнится alert). URL таска - sergeybelove.ru/exploits/dom_x…
Решение точно есть для браузера Сhrome (чекнул на версии 51). Там только нативный JS. Ведь это аккаунт разработчиков фронтенда!
Вы можете найти вектора в интернетах. Но более интересно понимание решения (оно и простое, и сложное). Твитьте скрины с вектором и алертом
Эту задачу оставлю до утра (пишите хотя бы, если пробовали решать), а завтра на повестке - "JS, вышедший далеко за рамки фронтенда".
@jsunderhood я даже не понял, что нужно сделать:) можно как то поконкретнее описать?)
Есть textarea, там можно ввести html, он отрендерится (<img src=...>). Нужно таким образом исполнить на js alert(1) twitter.com/aleshaoleg/sta…
Т.е. по факту - обойти санитайзер, у которого есть белый список (в котором нет <script> или onerror/onload событий, для onerror=alert(1) )
Задача: найти значение, которое при клике на "Render" приведет к DOM XSS (например, выполнится alert). URL таска - sergeybelove.ru/exploits/dom_x…
И снова привет! Сегодня много работы, поэтому я напоминаю, что есть таск для решения и 1-ый хинт: name="body" twitter.com/jsunderhood/st…
@jsunderhood есть только один способ исполнить js здесь - это записать его в атрибут src. Но и тот не работает, потому что https
Все же решение не инжект в src, а связано с разбором DOM. Публично этот баг упоминался нечасто, но есть презентации twitter.com/boriscoder/sta…
Видно, что первый таск идет сложно. Пока мы не перешли к новой теме - закидываю таск попроще - sergeybelove.ru/exploits/task2 (задача - найти XSS)
Я не писал код для второго таска (и не добавлял сам уязвимостей). Я просто загуглил - codemag.com/article/1301091, взял весь код и развернул.
К слову, сколько уязвимостей допущено копипастом по первым ссылкам из гугла (stackoverflow - тоже идёт в счет). И это еще не server side.
Уверен, с этим таском у вас должно все получится. Ваш ответ - ссылка в reply, перейдя по которой у меня выскочит alert(1) на моем домене :)
(где-то глубоко в душе я уверен, что фронтендерам интересна безопасность их же технологий). Так что точно попробуйте решить второй таск!
К слову - именно такая навигация (как в таске №2) использовалась в Drupal долгое время (в админке). И точно также была уязвима к DOM XSS
XSS - это когда мы можем внедрить произвольный JS. Как пример - внедрить надо alert(1)
А что-нибудь типа микросервисов во фронтэнд не завезли ещё? Хочу сервис из набора SPA. Есть уже решения, Best practices? /cc @jsunderhood
Ретвичу, чтобы дела шли в гору) это не по безопасности, так что ответ за фолловерами twitter.com/webholt/status…
Мегахинт: да, первый таск решается через clobbering. Часть залатали, но в паблике есть обходы twitter.com/panyakor/statu…
Если вы нашли ТУ самую статью, откуда код для таска, то да, оттуда работать не должно )
Поздравляю @eShreder, @PanyaKor и @naxel_ с решением второго таска! И как факт - вы нашли уязвимость в коде, который в топе выдача гугла )
И @an4ger с решением первого! Атака называется DOM clobbering. Пэйлоад можно было найти здесь - github.com/Microsoft/JSan…
Вкратце - атака на разбор DOM, реализуется за счет использования зарезервированных имен. thespanner.co.uk/2013/05/16/dom… owasp.org/images/a/ae/Ad…
И конечно же slideshare.net/x00mario/in-th… от @0x6D6172696F. Атака мала известна, включая специалистов по web sec. Но 42% просили что-то сложное!
И конечно же slideshare.net/x00mario/in-th… от @0x6D6172696F. Атака мала известна, включая специалистов по web sec. Но 42% просили что-то сложное!
Правда что-то со SlideShare, но точно можно выкачать PDF'ку twitter.com/jsunderhood/st…
Среда
Не теряйте, я точно расскажу о всем, о чем еще запланировал :) А пока новый челлендж, добейтесь alert(1) везде! escape.alf.nu
Четверг
Наконец-то могу вернуться к твиттеру (надолго), давайте продолжим тему безопасности. Ранее мы познакомились с уязвимостями фронтенда (хабр)
Что SOP - штука гибкая, код из гайдов - м.б. с уязвимостями и есть разные, интересные сложки атаки на разбор DOM.
Многие попробовали себя в качестве пентестеров (поискать DOM XSS) и у некоторых это вышло, отрадно! Едем к следующей теме.
JS - язык настоящего и будущего и я действительно так считаю. Фронт, бэк, SmartTV, машины (multimedia), десктопные скрипты (win/linux)
расширения для браузеров и мн. другое, все на JS. Из этого я также занимался безопасностью расширений и виджетов и приложений для SmartTV
И эта наша следующая тема. По факту мы имеем тот же JS только с расширенным API (доступ к железку, датчикам, файловой системе и т.п.)
Естественно можно выстрелить себе в ногу при разработке и допустить уязвимость. Только тут импакт уже в разы больше -
мы уже за стандартной песочницей браузера. Начнем с расширений, дело было давно (в 2013) и было интересно. Чтобы не скучали, закину видос :)
Я пользовался расширением Any.DO и при поиске уязвимостей в gmail внезапно нашел в нём xD Demo - youtube.com/watch?v=5Nr-ta…
По факту мы имеем обычную DOM XSS, но в контексте расширения, которое может слать XHR запросы на любые домены(спрашиваются при установке, *)
Но здесь просто full SOP bypass (см. видео). А может быть и выполнение команд ОС (у юзера), статья - blog.kotowicz.net/2012/09/owning…
Поэтому, если вы разрабатываете расширения, смотрите в сторону тех же багов фронта / запрашивайте корректные права и будьте параноиком
SmartTV. С этой темой я выступал на последнем ZeroNights и баги описал в статье - habrahabr.ru/company/dsec/b…
Тут важно понимать, SmartTV - они очень разные и на разных ОС (от кастомных сборок до Tizen и тупо - просто Android'а).
В случае со SmartTV от Samsung - у них своя ОС на базе linux (2008-2014) и Tizen (тоже linux) для новых моделей. Приложения пишутся на JS.
По факту - это SPA + доп API. И в случае приложений для 2008-2014 у вас НЕТ ВОЗМОЖНОСТИ БЕЗОПАСНО хранить данные (OAuth токены, например)
Любое приложение при помощи XHR + схемы file:/// может стащить файл другого приложения, где лежат "секретные" данные. А сколько людей ставят
себе виджеты от "Васяна", в которых вполне может быть подобный бэкдор. Tizen так в руки и не попал, но мне говорили, что фиксили это
Но идем дальше. Я пошел искать настоящие уязвимости. В реальности угрозу несут только DOM XSS (нашел - получил доступ к файловой системе)
И инфолики. Например, в официальном приложении для FB от Samsung я нашел захардкоженные учетки для тестов :) работающие
@jsunderhood разве куки не отдельно от виджетов лежат?
отдельно, но можно прочитать, как и файлы из песочницы (описывал в статье на хабре). Все чекал на реальном TV. twitter.com/somerandstring…
Идем дальше. АВ-ТО-МО-БИЛЬ! И до сюда добрался JS, как пример спека - w3.org/2012/11/web-an…
В рамках данной твиттер-сессии мы не будем вплотную рассматривать этот вопрос, но вкратце: есть API до всяких мультимедиа штук
Но ограничения, как обычно, вводит сам производитель. Мы будем пристально следить за этой темой :)
Очень многое зависит от того, в какую песочницу поместит JS производитель. Неудачная реализация со SmartTV 2008-2014 яркий тому пример.
Но это не освобождает разработчиков от ответственности за код :) Так что будьте в тренде, думайте о безопасности.
Едем дальше, я бы хотел написать про пентесты (анализ защищенности). Формально, бывают разных типов: [white|gray|black]box
Зависит от того, что заказчик предоставляет - всё (исходники и т.п.), дает часть (учетки, что-то еще) и тупо ничего. Например, только url
Отдельно выделим анализ кода (как работу). Ведь исходники могут просто помогать при пентесте, а можно детально анализировать только их.
В последнее время есть тенденция на whitebox и анализ кода. Понимание, что лучше найти дыры до инцидентов - это круто.
А вообще - должна быть дружба между security & developers. Если вы, как разработчики сами имеете сомнения в каком-то функционале - обратите
на него внимание пентестером. Можно что-то говорить спортивность, но пентест на заказ - это ограниченное время и невозможно посмотреть всё.
За определенное время специалистами с таким-то опытом найдутся такие-то уязвимости. Поэтому нет ничего страшного что-нибудь подсказать.
@jsunderhood какие статические анализаторы для js используете?
DOMinator - dominator.mindedsecurity.com + разные плагины для Burp + просто регулярки code.google.com/archive/p/domx… twitter.com/artemborzilov/…
Ладно, будут про пентесты вопросы - пишите :) Возможно, это не так интересно. Поэтому перейдем к вопросу про ... багбаунти! Это так модно :)
(и я догнал тему 4го дня из своего плана). Про это все 1000 раз слышали, когда можно получить деньги за найденные уязвимости.
В реальности, это могут быть easy money (запустил сканер уязвимостей, нашел, оформил тикет, гребешь бабло).
Но чаще всего такое подчищено. В РФ довольно много программ, включая Яндекс, Mail.ru, VK, Badoo и Qiwi.
Среднюю сумму, которую можно получить (за "типичные" баги) - от 5 до 25 тысяч рублей. Критичные - от 30 до ~150
Часть программ управляются тупо через почту, но большая вынесена на площадки - hackerone.com / bugcrowd.com
Там смотрим у кого открыта бб программа, репортим через них же тикет, в случае аппрува - получаем деньги на PayPal. Расценки указны.
Обычно out of scope - флаги для Cookies, security headers (HSTS/XFO/etc), self-xss и подобные штуки. Но если найдете импакт - то платят.
Так, что-то я уже тут много написал, сделаю перерыв :) почитайте ленту, будут вопросы - пишите, поотвечаю и пойдем дальше.
Понедельник
Ping! Совсем сложно оказалось на неделе со временем, но за ночь дострочу мысли, идеи, советы и мнения.
Одна из тем, которую хотел затронуть - последние громкие взломы больших компаний. haveibeenpwned.com/PwnedWebsites
И, даавйте исключим из списка "дампы" mail.ru / yandex / etc, они пришли одной волной и были в результате фишинга / слива ботнета, факт
А вот у некоторых действильно слили базу :) И мое мнение, что просто есть проблема в подходе: выстраивать защиту - значить защищаться.
Но защищаться, когда мб тебя и не пытались действительно атаковать - значит сливать деньги в трубу. Да, можно купить крутые железки
Но что толку от них без правильной настройки? А чтобы правильно настроить - надо их проатаковать. Давайте на примерах. Вот корп. фаирволлы
Например, интернета в компании быть не должно ("секретка"). Но всегда не закрывают путь - DNS. DNS резолвится, значит есть прямой путь
Перекидывать данные наружу, да что там - прокидывать шеллы (при социалке удобно). Например, можно через wiki.skullsecurity.org/Dnscat
А внутри сети? С ARP спуфингом научились бороться. Но проводить mitm можно по-разному, и github.com/SpiderLabs/Res… очень помогает в этом
(помните, все тулзы привожу только, конечно же, для ознакомления и в учебных целях)
@jsunderhood не волнуйся, тебя все равно практически никто не понимает
Для того и пишу, чтобы кому ничего непонятно - заинтересовались (полезно), а кто понимает - мб узнали нового :) twitter.com/Chudesnov/stat…
Снаружи, обычно, тоже находится путь. Кстати, чтобы чекать банальные штуки я как-то запилил сканер - sergeybelove.ru/one-button-sca… (в одну кнопку)
Тупо вбивайте урл и он делает разные проверки. Обязательно расширю ему базу. Как-то этот сканер нашел реальные баги на wikipedia/yahoo :)
Будут еще утечки, будут сливать базы и не станет "тише", имхо. Чтобы снизить риски - никогда не надо строить защиту без нападения (на себя)
В качестве примера такого тру подхода, в котором я принимал участие - это компания Qiwi. Статья от @isox_xx - journal.ib-bank.ru/post/413
Тру - я конечно же имел ввиду строить защиту, "нападать" на нее, строить дальше, снова "нападать". Сложно придумать лучше.
Кстати, в целом тусовка ИБ (практиков) не очень большая. Это две больших конфы - @phdays и @ZeroNights и небольшие комюнити по городам.
DCG группы (найди в своем городе - defcon.org/html/defcon-gr…), OWASP встречи (Москва), митапы в mail.ru (Москва)
Так же есть CTF тусовки, там тоже обычно встречаются и делают доклады по безопасности. Сейчас это есть почти во всех городах (онсайд).
Поэтому, если надумаете изучать сферу - всегда велком, очень много возможностей, встреч, статей, материалов с конференций и т.п.
А это любому разработчику нужно сделать - хотя бы разобрать базовые/уязвимости атаки. Например, хотя бы, с XSS (если мы говорим про фронт)
Будет хорошо, если будете вникать глубже - например JSONP leaks / CORS / и т.п., что я приводил в статье на Хабре.
Вообще, это большая проблема, что когда собеседуют разработчиков НЕ ЗАДАЮТ вопросов по безопасности. Никаких.
Старший разработчик / тимлид точно может сам понять все базовые атаки. Спрашивайте при приеме на работу / понимаете уровень
@jsunderhood а что еще нужно посмотреть, по фронту?
А я скидывал статью в начале - habrahabr.ru/company/dsec/b…. Более актуального материала пока не находил. twitter.com/aleshaoleg/sta…
Знаете уровень - будете ставить задачи с этим учетом. Если плохо понимает человек CORS/JSONP/Referer - значит стоит быть аккуратным :)
@jsunderhood помню, в универе написал программу, которая вообще не ломалась никакими данными. У меня не приняли, типа нафиг сложно так писал
Буду банальным, но по универу делать выводы и выбирать подход в тру разработке не надо :) А так да, бывает проблема. twitter.com/PMarinchenko/s…
Вообще, обычно тут проблемы другие. Если делать безопасно - то это дороже / больше сроки / неудобно юзерам. Поэтому должен быть баланс.
Картинка к теме. Минимальные затраты уже сразу дают резкий рост. С верхним пределом сложно, панацеи нет.
Из чеклиста, что еще оставалось: JS в Security. Например, в reverse engineering - habrahabr.ru/company/dsec/b… (от @evdokimovds )
А также подходит для малвари (скорее в целом - скриптовые языки). Тот же powershell - куча возможностей и не палится антивирусами.
Кстати, все хотел закинуть статью, как через JSONP
serviceWorkers получить постоянную XSS :)
c0nradsc0rner.wordpress.com/2016/06/17/xss…
Подводя итоги хочу сказать, что если вы пропустили мимо тему безопасности, она все равно вас настигнет. Как тот экзамен, который надо сдать.
Поэтому не откладывайте её каждый раз подальше, например как ту кучу непрочитанных закладок в браузере, которые у каждого есть.
Все твиты/ссылки за неделю можно будет найти здесь - jsunderhood.ru/sergeybelove/. Возникнут вопросы - всегда пишите на почту или в твиттер.
Я рад, что была такая необычная возможность поделиться чем-то полезным с сообществом разработчиков. Будьте в безопасности и пока!
