Об инфосеке, пентестинге, аудитах и белых шляпах. Интервью с Иваном d0znpp`ом Новиковым, основателем ONsec

Этого человека многие знают как Владимира Воронцова, другие — как d0znpp. И не так уж важно, что на самом деле его зовут Иван Новиков. Главное, что это один из самых идейных whitehat’ов России. Он знает почти все о безопасности веб-приложений и своим примером показывает, что эти знания можно пустить в правильное русло, не только делая мир безопаснее, но и строя на этом успешную технологическую компанию.

Интервью с d0znpp впервые появилось в выпуске «Хакера» в августе 2013 года, но так и не было опубликовано на сайте. Поскольку d0znpp и isox — большие друзья, редакция посчитала публикацию интервью с Кириллом удачным поводом для того, чтобы «вспомнить былое» и сравнить взгляды на профессию от двух крупных white hat`ов. Итак, встречайте: Владимир Воронцов!

Я всегда был идейным white hat

Я никогда не «болтался в воздухе». Так сложилось, что я никогда не был в положении «я студент, и мне нечего делать». После поступления в университет я почти сразу пошел работать, так что времени не оставалось. А тратить свое свободное время на то, чтобы чем-то рискнуть... это бред. Меня такие мысли никогда не посещали.

Black hat’ов видно сразу. У меня есть опыт, я вижу этих людей. Это даже трудно объяснить словами.

У блэков есть интуиция. Обычно все сразу понятно по скиллам. Даешь человеку тестовое задание, наблюдаешь за ним и, как правило, сразу понимаешь, что он делал раньше. Блэки не пытаются найти уязвимость и XSS, они пытаются добиться фактического результата, разными способами. Когда даешь им реальное, живое приложение, сразу видно, что они занимаются нетрадиционным хаком. Видно, что человек знает. Если человек просто начитался чего-то, он начинает планомерно смотреть — авторизация, валидация... Блэки поступают не так.

Вообще, заработать можно на чем угодно. Вопрос лишь в том, чего ты хочешь. Если ты хочешь зарабатывать деньги, ты вряд ли станешь заниматься безопасностью — это, пожалуй, самый трудоемкий и глупый способ для этого :). Да, говорят, что black hat получают больше. Однако нет примеров того, что они откровенно блэчат. Да, существуют черные CEO, которые реально получают много денег. Но как все устроено там внутри, не очень ясно.

Мне смутно кажется, что люди, ломающие что-то руками, все равно нуждаются в каких-то еще скиллах. И я сильно сомневаюсь, что многие black hat хорошо зарабатывают. Большинство из них воспринимают происходящее как игру. Или занимаются откровенным криминалом, как те же кардеры. Если они даже и зарабатывают, то вовсе не потому, что хорошо ломают, а потому, что у них есть некая своя фишка — умение что-то организовать, сделать, закрутить. Это никак не связано с компьютерами.

Просто нужно понять, что тебе нужно от жизни, и заниматься именно этим.

Как я попал в ИБ? Не сразу. Пришел, как и все, из интереса. Первый компьютер, DOS, бейсик, программирование — примерно такая последовательность.

Но сначала я пошел работать не в ИБ, а как все — программистом. Поработал какое-то время, а потом в 2009 году был конкурс по обходу проактивной защиты на Chaos Constructions. На CC я ездил и раньше, все это интересовало меня давно. Но именно в 2009 году был байпасс «Битрикс», я прошел его и понял, что пора менять работу. И отправился устраиваться в Positive Technologies, но меня туда не взяли. Тогда я подумал-подумал и решил, что буду делать аудиты сам, — ну а чего здесь такого? 🙂

Когда я выиграл конкурс, в новостях опубликовали ссылку на ONsec.ru. Там был блог с уязвимостями, которые были найдены по full disclosure, и кнопочка для оформления заявки на заказ. Через CMS все и началось.

Поэтому в конкурсах стараюсь участвовать до сих пор, чтобы показать — мы на волне, живы, развиваемся, не окостенели. И сам конкурсы стараюсь устраивать.

Репутация — очень сложная штука, которую зарабатывать надо годами, а потерять можно за минуту. Зарабатывать репутацию можно по-разному, главное — результат. Тебя должны рекомендовать. Нет для репутации ничего лучше, чем положительный (отличный, восхищенный) отзыв о проведенном аудите на каком-нибудь закрытом ивенте между заказчиками. Громкие достижения тоже важны.

Все включено

Фаундеров исторически трое: Настя, я и Саша. Саша отвечает за сеть, наше облако, всю инфраструктуру администрирования. Я занимаюсь алгоритмами и аудитом. Настя... Настя обеспечивает нам жизнь в «идеальном мире», чтобы мы могли работать, пока она занимается всем остальным — бухгалтерией, кадрами, налогами, заказчиками, договорами и прочим. Она администратор.

Людей в компанию я находил, можно сказать, по крупицам. Некоторые участвовали в наших квестах, некоторые ушли из каких-то конкурирующих организаций. Бывает и так, что человек приезжает в Москву, оканчивает университет, работает здесь год и понимает, что смысла здесь жить просто нет. И едет человек домой, в прекрасный, зеленый Алтайский край. Получает там почти те же деньги, что и в Москве, но чувствует себя человеком, ловит рыбу сетями, ему классно. Так что у нас много удаленщиков — из Якутии, Читы, Украины, Германии и других мест.

Мы ищем людей не по каким-то шаблонам, типа «программист», мы ищем именно людей. Главное, чтобы человек был хороший.

Конечно, смотрим на общение, проводим анализ бэкграунда, но на первом месте стоит интерес самого человека. Если есть желание — все остальное приложится. Только желание должно быть где-то на уровне мании, одержимости, если хочешь. Когда с таким человеком общаешься — не важно, лично, через Skype или даже почту, — сразу чувствуется эта одержимость, и значит, можно работать, значит — сработаемся.

Пентестов мы вообще-то не делаем. Мы проводим аудиты. Пентест — это задачка на пролом системы. Понятно, что он производит вау-эффект. По итогу пентеста ты отвечаешь на вопрос, безопасно ли все организовано. Но пентест никак не помогает организовать эту самую безопасность. Спустя месяц ты можешь заказать еще десяток пентестов, и тебя еще десять раз сломают. Если ты не будешь концептуально предпринимать никаких мер, ничего не изменится.

Пентесты, возможно, имеют какой-то смысл в корпоративных сетях — там есть некие базовые вещи, и понятно, как их настроить. Но в веб-приложениях все зависит от самого кода, там ничего не понятно, нет никаких гайдов.

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

Чтобы все это лучше продавалось, мы, конечно, проводим какие-то «пробивы», вроде пентестов. Берется одна из тысячи найденных уязвимостей, эксплуатируется, и клиенту демонстрируется, как мы с ее помощью получаем полный доступ. Но в масштабах проекта это лишь небольшая работа на вау-эффект, чтобы тебя запомнили.

Основная работа — это монотонное изучение всего-всего. Она очень методичная, во многом неблагодарная, автоматизированная, а иногда и ручная... В общем, очень унылая работа.

Мы проводим и white box, и black box. Без исходных кодов и с ними. Что труднее? Не знаю, не могу разделить.

Бывают очень простые white box, когда приложение написано очень просто. Все потенциальные точки входа сосредоточены в одном месте, которое можно быстро проверить и сказать «все плохо» или «все хорошо». А все остальное — просто обвязочки, расширяющие эти точки входа. Такие приложения бывают.
Но опять же бывают очень сложные black box. Бывает наоборот. Все вариативно.

Сканер в таком деле вообще не поможет. Мы исходим из того, что сначала нужно узнать приложение, понять, что и как оно делает. И только потом начинаем ломать.

Мы вручную изучаем приложение, составляем общую картину того, что в нем есть. Исходя из нее, смотрим, к чему стремимся и где есть потенциальные проблемы. Мы пытаемся их предсказать. Садимся и обсуждаем, как мы проломим это приложение, в каких конкретно местах. Затем занимаемся сбором информации «вокруг периметра», изучаем приложение глубже, составляем всякие деревья вызовов. Потом в ход идут техники фаззинга, еще что-то — различные автоматизированные вещи. Ошибки логики ловим руками.

Для black box мы используем Burp Suite, ничего лучше пока не видели. Для него у нас есть свои плагины и тулзы. Никаких Acunetix не применяем, они бесполезные и бестолковые.

Для white box у нас есть свой сканер, статический и динамический анализатор. Его мы писали сами; собственно говоря, с него-то мы и начинали. Это был первый внутренний продукт — PHP vulnerability tracer. Артур писал его с нами, а потом уже выпустил open source.

Фаззеры пишем «на месте». Ведь каждый фаззер уникален. Когда нужен, тогда и пишем.

Пишем на чем угодно, чаще всего — на Ruby и PHP. Либо можно многое подфаззить к Burp через Intruder. Как правило, вещи вроде переборов мы делаем просто на Intruder. Там же есть и bit flip’ы. А всякие хитрые шутки, с обработкой payload’ов и всякими фильтрами, обычно пишем на Ruby или PHP.

Конечно, бывает, что к нам приходят и за пентестами. Мы можем сделать и это. Но мы пытаемся донести до людей, что сначала им нужен аудит, а уже потом можно провести пентест для проверки.

Как правило, после нашего аудита кому-то еще заказывают пентест, а нам заказывают пентест после чьего-то аудита. Это нормально, я вообще не совсем понимаю компании, которые придерживаются идеологии «это наш клиент, и будем с ним всю жизнь». Подобное невыгодно клиенту, ему выгодно менять команды и получать наиболее объективную оценку уровня.

Цена аудита зависит от многих факторов, но, наверное, в максимуме это порядка нескольких сот тысяч долларов. Это, скажем, аудит большого, многомиллионного ресурса.

По времени аудит занимает от двух-трех недель до четырех месяцев. У нас были проекты и по четыре месяца. Это аудит исходного кода, когда приложение многоплатформенное, много кода на разных языках (C, Java, куски на PHP).

Мы вообще стараемся не брать проекты «внахлест», работаем очень дотошно и поэтому не всегда и не всех можем взять в срок, который нужен заказчику. Делаем мало, но хорошо.

Как сделать хороший WAF

Началось все с того, что мы спокойно делали аудиты. Жили себе и жили. Но каждый раз, когда мы заканчивали аудит, оказывалось, что заказчик хочет, чтобы мы по итогам аудита еще и приняли какие-то меры, что-то изменили в его системе.

Нам предлагали дополнительные деньги за настройку какого-нибудь mod_security. Поначалу мы брались за это, но вскоре поняли, как это сложно. Нужно постоянно поддерживать регулярные выражения, править их, а они очень большие, нужно заниматься настройкой, чтобы не было false’ов, а это тоже очень трудно. Плюс жутко падает производительность, а у заказчиков обычно дела с железом обстоят не очень хорошо. Поэтому мы отошли от такой практики и стали отвечать: «Чуваки, настраивайте сами, это очень сложная работа».

На тот момент с платными продуктами все было очень плохо. Были решения, которые просто не имели дистрибьюторов в России. Сейчас дистрибьюторы появились, но у них очень большие прайсы, что тоже отпугивает простых смертных. К тому же эти решения тоже совершенно неочевидны. Человек, не разбирающийся в безопасности, не сможет их применять.

Любой WAF — это система IDS/IPS. Скажем, ты хочешь заниматься безопасностью, тебе нужно как-то работать с системой, разбирать ее логи, а людей для этого у тебя нет. Это и есть самая большая проблема. Поэтому на самом деле мы не делаем WAF. Мы делаем систему, которая будет лучше WAF.

К примеру, у тебя в наличии регулярные атаки. Они постоянно в логах, потому что есть сканеры, серверные ботнеты, WordPress, которых у тебя никогда не было... Все это отражается в WAF. Он радостно все это отбивает, что-то false’ит, что-то нет. Но понять что и где — очень трудно. Это одна большая каша. И что же делать?

Мы придумали систему, в которой такой каши не будет. Систему, которая будет четко отвечать на перечисленные вопросы и встраиваться в security development lifecycle, который все так любят и хотят внедрять. Плюс все это сделано для простых смертных, а не для «архитектурно зрелых» чуваков. Простая, удобная и понятная система. Которую, к тому же, практически никак нельзя будет обойти, потому что у нее не будет статичного состояния.

Как сделать систему, которую нельзя обойти? Нужно дать ей возможность динамически изменять свое состояние. Когда состояние системы меняется, даже если у тебя на руках имеется какой-то байпасс, ты его подобрал и применяешь, он будет работать лишь какое-то ограниченное время, а после перестанет. Потому что состояние системы меняется (если она правильно функционирует на тот момент). По крайне мере, у тебя нет возможности эту же багу на ошибку регулярки mod_security раскатать по всем уязвимостям. Ведь они все в разном состоянии, вычленить которое почти невозможно.

Что там внутри? Нейронные сети и машинное обучение — только красивые слова. Большинство людей ни разу в жизни нейронную сеть не делали, а если и делали, то не очень представляют, как это связано с какими-то реальными процессами. Поэтому я предпочитаю термины «аномалия», «статистика». Это более понятные и честные определения того, что физически можно сделать в алгоритмах.

Сейчас у нас уже есть совместный релиз с HighLoad. Инсталляция уже работает, и мы ее обкатываем. Но будет еще круче.

И пока с HighLoad все работает, мы делаем инстанцию, но это не прогон трафика. Будут локальные клиенты, которые можно установить и настроить, они будут работать с нашим облаком, но весь трафик перегонять туда не будут.

Это наиболее оптимальный вариант — так у нас не будет всех данных клиентов, мы не будем видеть трафик и «живые данные», не будем их обрабатывать. Мы будем видеть только выборочную выжимку, которую сформирует наша инсталляция у клиента. Какие-то крупные компании, которые банально не смогут сгружать все в наше облако, будут ставить наше облако у себя, stand alone. Это подойдет для поисковых систем и проектов подобного рода.

Зачем вообще нужен продукт из коробки? Мы делали продукт, ориентированный на конкретные требования. Первое и основное требование — производительность. Мы создавали очень производительную систему, непохожую на все, что сейчас существует. Благодаря этому наша система способна обрабатывать много запросов и вносить маленькую latency, даже если стоит посередине.

Второе требование: мы сделали систему, которую можно использовать в Big Data, а там же огромные нагрузки. Когда у тебя огромная инфраструктура, ты даже не можешь переконфигурировать фронтенды. Если чуть изменишь настройки, это отклонение от производительности получится настолько сильным (в масштабах тысяч фронтендов), что тебе придется все вернуть на место. Поэтому мы делали систему, способную внедряться даже в очень нагруженные проекты, не меняя их, не внося погрешностей в их нормальную работу.

Если у тебя большая производительность, твоя задача — обработать все вообще без latency. Твоя идеология — брать и обрабатывать запросы. Если ты будешь делать это в реальном времени, всегда будет latency. Но если делать это не в реальном времени, можно сделать как надо.

Cуть Big Data в том, чтобы обрабатывать запросы не в реальном времени, а ориентируясь на то, чтобы система переваривала ровно столько, сколько она может переварить. Тогда, увеличивая ресурсы нашей системы, мы уменьшаем время реакции на атаку.

Время реакции на атаку важнее, чем блокировка данных. Атака редко происходит в один запрос, никакой гений с одного HTTP-запроса не сломает систему. Сначала он проведет некую подготовительную работу, и уже на этом этапе система его узнает. Узнает не его IP-адрес, а именно профиль человека, который совершает примерно вот такие действия. И этот профиль блокируется. Дальше, если система понимает, что эти действия правда опасны, она выкидывает этого человека и уведомляет, что вот здесь — реальная проблема. Все. Потом ты автоматически решаешь задачу и защищаешь систему.

Это не есть защита от какого-нибудь 0-day, который придумали и пробили десять лет назад (такое практически никогда не встречается). Проблема 0-day вообще не в том, что они существуют, а в том, что под их блокировку невозможно настроить никакие сигнатуры. По понятным причинам — ведь ты его не знаешь, на то он и 0-day. А мы умеем блокировать 0-day не по сигнатурам. Именно поэтому нас очень трудно байпассить, даже практически нереально.

Reward-программы

Как стать хорошим практическим безопасником? Нужно пойти в лес, найти пенек и перевернуться через него три раза. Ну конечно, нужно работать, работать и работать.

Что вообще такое «практический безопасник»? Это человек, который получил возможность что-то поломать и честно выполнил свою работу. Чтобы что-то поломать и не нарушить закон, не нужно делать ничего. Достаточно скачать любое open source приложение, каких миллион, и расфигачить его. Или воспользоваться программой вознаграждений, тогда ты вообще будешь самым настоящим, профессиональным практическим безопасником. Ведь ты будешь делать свою работу и фактически не нарушишь никаких законов.

Любая программа вознаграждений — это неокупающиеся деньги, зато на таком хорошо делать имя. Во всем этом больше PR, нежели чего-то еще, но PR не всегда удается получить. Проблема программ вознаграждений в том, что они нужны, чтобы платить людям «немножечко денег», а не для того, чтобы прославить их.

Когда тебе нужен PR и ты пытаешься договориться с людьми, порой возникает недопонимание. Они говорят: «Да, вы сделали классную штуку, но вы не должны никому о ней рассказывать». Часто бывает, что организаторы программ принципиально против разглашения деталей уязвимости, хотя это не по правилам.

Если организаторы возражают против огласки, они сами же от этого страдают. У них получается security by obscurity. Им кажется, что если они не будут никому говорить о своих глупых багах, то таковых станет меньше. На самом деле не станет. А вот если донести эту информацию до масс, когда все узнают о таких багах, то и люди организатора тоже — о чудо! – будут лучше об этом информированы.

В целом к reward-программам я отношусь положительно. Стараюсь поддерживать людей. По мере возможности стараюсь помогать им, высылать что-то интересное. Сам я участвовал в ряде программ. В Яндекс засабмитил больше двадцати багов. Все они были критические, серверные, там XSS не было. Я находил баги в чтении файлов, отправке запросов, инжекты... Ошибки логики, обход авторизации. Другого, не считая «Островов», я не отправлял.

С «Островами» вышло смешно. Сразу после объявления о них и открытия беты я поломал их через паблик. Минут через пять. Сегалович написал в твиттере, что они выпускают новую систему, кто-то ретвитнул это сообщение, я нажал на ссылочку и поломал ее. Вот так просто.

Еще у меня был reward от Nokia за телефончик. Вознаграждение от Google за Chrome. В Chrome был обход ограничений. А именно — как функционирует same original policy. Это логика. Я ничего не реверсил, ничего не делал, просто нашел ошибку. Через этот баг можно было с HTML-странички тырить локальные файлы на машине пользователя. Причем она работала в те времена, когда в Chrome еще не было своего ридера, через Flash и PDF. Эксплойт там состоял из трех частей.

На самом первом PHD я рассказывал про эту багу, но к тому моменту в Chrome уже появился свой ридер, а бага исполнялась только через продукты Adobe и только в Chrome. То есть тогда она уже не имела особого смысла.

Пара советов и тренды ИБ

Проблема продуктов обычно в том, что их делают программисты. Они и обходятся и работают так, как нужно программистам или чуваку, что писал техническое задание. Практически нет продуктов, которые делают люди, умеющие ломать.

Совет всегда один: если берешься на чем-то писать проект, пиши его и выпускай только тогда, когда уверен, что изучил инструмент, который используешь. Изучил то, на чем пишешь. Чаще всего ошибки основаны именно на том, что люди используют нечто, не понимая, что хотят сделать. Если используешь object relational model, попробуй сначала понять, что это, и только потом писать на нем код. Возможно, сейчас он тебе не подходит. Или наоборот — возможно, он подходит тебе, но ты поленился до конца понять, о чем это.

То же самое в PHP. Там много интересного, опять же много фреймворков. Часто проблему пытаются решить не так, как нужно, и отсюда возникают новые проблемы.

PHP — язык у которого очень низкий порог вхождения. Там почти сразу можно начинать делать что-то работающее, и это очень расслабляет. Совет здесь один: нужно следить хотя бы за input validation. Проверяйте все данные, приходящие от пользователя, от его запроса. Если вы вообще как-то их обрабатываете, то сначала их нужно проверять. Это сразу ощутимо сократит количество ошибок, по сути, останутся только ошибки логики.

К получению сертификатов я лично отношусь плохо. Готов обучаться у профессионалов, но таких совсем немного, к сожалению. Они есть, конечно, но тренинги не ведут.

Если говорить о трендах в сфере ИБ, то XXE уже «отцветает», как мне кажется. Многие эксплуатации уже закончились, и это понятно. Уязвимость заканчивается тогда, когда один человек прочитал весь парсер. Вот нашлись люди, которые дочитали весь XML-парсер, и все.

На самом деле XML-баги еще будут стрелять — XSLT, выполнение кода и прочее. Кстати, очень классные штуки, которые дают выполнение кода через XLT, но их просто редко можно вызвать из userdata.

А тренды... Тренды всегда примерно одинаковы. Это инъекции, как бы их ни называли. Они всегда будут, они самые тупые, простые и жесткие.

Также сейчас публикуется много ошибок авторизации, ошибок логики, в Skype такое находили, где-то еще. Когда что-то меняешь, что-то пишешь туда и сюда... Это чисто логические баги, не классические input validation. Input, который они эксплуатируют, абсолютно валиден по форматам, только с какой-то логикой что-то не так. Очевидные вещи, которые очень сильно зависят от конкретного приложения. Сейчас так сложилось, что их нашли очень много за последнее время.

Как появился d0znpp

Когда не было интернета и был только 486-й, обо всех технологиях я узнавал из «Хакера». Тогда писали очень веселые статьи вроде «истории взломов», мало что было понятно, но было очень интересно и захватывающе. Сейчас я иногда перечитываю их с улыбкой :). Так же я познакомился с UNIX.

Алиас Володя Воронцов появился тоже из журнала «Хакер». Я написал статью и подписал ее Володей Воронцовым. Я не знаю почему. Ника у меня тогда еще не было, вот и придумал такое. Это был 2008 год.

Когда я отправил статью, мне ответили, что еще нужен ник. Так появился и d0znpp.

Самое главное — я никогда не шифровался, все получилось как-то само собой. Я сочинил этого Володю Воронцова... от балды. Просто тогда я работал, а работать и писать статьи в «Хакер»... если на работе не очень хорошо относятся к таким вещам и вдруг прочитают статью, а потом скажут: «Ага!». В общем, я не хотел такого и изобрел псевдоним. Наверное, многие так поступают. Но больше это я по глупости сделал, не подумав. А потом оно примелькалось, ко мне стали относиться как к автору этих статей, и я не мог отвечать по-другому.

Для большинства людей я деанонимизировался сразу. Вопрос принципов общения, каких-то жизненных ситуаций. А вообще, недавно деанонимизировался официально. Надоело немного. Хотя какая разница, вон Крис Касперски живет и не парится. У меня похожая ситуация, и она меня тоже мало волнует. Главное, чтобы каких-то глупых, ненужных ассоциаций не возникало. Если не возникает и люди относятся ко мне хорошо, то мне не принципиально, как меня зовут.

Большинство людей все равно называют какими-то производными от имен и фамилий. Меня вот Вова Воронцов зовут, и что? Не считая того, что это псевдоним, никакой роли это не играет :).