Программа заняла первое место в конкурсе Cyber Grand Challenge от DARPA, посвящённом автоматизации этичного взлома
В 2011 года, когда инвестор Марк Андриссен сказал, что «программы поедают мир», эта идея была свежей. Сейчас очевидно, что ПО проникает во все аспекты наших жизней. От сложных электронных устройств типа медицинского оборудования и робомобилей до простейших, вроде лампочек, подсоединённых к интернету и термометров – нас окружает ПО.
А это значит, что мы уязвимы для атак на это ПО, как никогда раньше.
Каждый год к существующим программам добавляется по 111 млрд строк кода, и каждая из них служит новой потенциальной целью. Стив Морган, основатель и главный редактор исследовательской фирмы Cybersecurity Ventures предсказывает, что взломы систем, совершённые посредством неизвестных ранее уязвимостей – то, что индустрия называет «уязвимостью нулевого дня» – к 2021 году будут происходить в США ежедневно, хотя в 2015 году они происходили еженедельно.
С целью решения этой проблемы я с моими коллегами из Университета Карнеги-Меллона потратили почти 10 лет на создание технологии, способной автоматически сделать ПО безопасной. Затем в 2012 году мы основали компанию ForAllSecure, чтобы представить наш продукт миру. Нам нужно было только доказать, что мы можем делать то, что заявляем, и мы сделали это в виде участия в соревновании.
Великолепная семёрка: соревнующиеся компьютеры светятся перед аудиторией финала соревнований Cyber Grand Challenge, проходившего в Лас-Вегасе в 2016-м.
Перенесёмся в 2016 год: наша группа скопилась в туалете отеля в Лас-Вегасе, и грызёт ногти, находясь в уверенности, что проиграла соревнование, к которому готовилась несколько тысяч часов. Это был конкурс DARPA Cyber Grand Challenge (CGC), одно из множества событий (как, например, конкурс для робомобилей, прошедший в начале 2000-х), организованных Управлением перспективных исследовательских проектов Министерства обороны США для стимулирования технологических прорывов в целях обеспечения национальной безопасности. CGC появилась благодаря тому, что DARPA признало, что для США однажды может настать такой день, когда у них не хватит людей или инструментов для отражения кибератак.
На поле битвы за кибербезопасность встречаются технически подкованные хакеры, а среди лучших из них находятся те, кто способен творчески использовать слабые места в ПО для проникновения через защиту организации. Преступников, делающих это в личных целях, называют блэк-хет хакерами, и часто они создают инструменты, при помощи которых скрипт-кидди, люди, пользующиеся готовыми программами, могут устраивать хаос, как, к примеру, произошло в 2016 году, когда ботнеты интернета вещей запустили массивную атаку по всему интернету, получая доступ к камерам наблюдения в домах у обычных людей. И наоборот, этичные, или уайт-хет хакеры, используют свои навыки для препятствования таким атакам. Но этичных хакеров не хватит для защиты всего ПО, количество которого в коммерческом мире быстро увеличивается, не говоря уже об общей инфраструктуре и военных платформах, жизненно важных для национальной и глобальной безопасности.
В 2014 году DARPA объявила конкурс Cyber Grand Challenge – двухлетний проект с целью проверки возможности разработки ИИ-систем, которые смогут находить, проверять и патчить слабые места ПО. В 2015 году сотня команд вошла в фазу предварительной квалификации. В 2016 году семь из них дошли до финала, где им нужно было представить систему, умеющую рассуждать – такую, которая не только заметит проблему, но и сделает предположение о её происхождении. Чемпион получает $2 млн, а второе и третье места — $1 млн и $750 000.
После того, как DARPA выпустило эти подробности, мы с коллегами тут же поняли, что это будет отличная возможность продемонстрировать, что разработанная нами система автоматической кибербезопасности – не простая теоретическая игрушка. Когда мы рассказывали о ForAllSecure, то всегда сталкивались со скептическим отношением к практичности нашего решения. Мы решили, что нам надо выиграть конкурс, учитывая, что мы работали над ним целое десятилетие.
Наше исследование в университете началось с простого предположения: людям нужен способ проверки покупаемого ими софта, чтобы гарантировать его безопасность. Программисты, конечно, приложат все усилия для устранения проблем с безопасностью, но их основные задачи более просты: им надо выпустить продукт вовремя и гарантировать, чтобы он делал то, что должен. Проблема в том, что хакеры найдут способы заставить ПО делать то, что оно не должно.
Сегодня передовые методы из области безопасности ПО подразумевают использование специальных инструментов для обзора исходного кода и отметки потенциальных слабых мест. Этот процесс выдаёт множество ложно-позитивных результатов – отмечает места, на самом деле слабыми не являющиеся – поэтому человек должен пройти их все и проверить каждое из них. Чтобы улучшить скорость обнаружения ошибок некоторые компании полагаются на этичных хакеров, которые проводят единовременный анализ или участвуют в программах поиска багов за вознаграждение, и платят им за количество и серьёзность обнаруженных багов. Но лишь самые успешные компании могут позволить себе проверку программ наивысшего качества. И проблема только усложняется, когда в итоговый продукт включаются различные компоненты с открытым кодом и другая работа третьих лиц.
Мы представили на конкурсе систему Mayhem, которая автоматизирует работу этичных хакеров. Она не только указывала на возможные слабые места, она эксплуатировала эти уязвимости, доказывая их слабость. Это также было ключевым моментом на CGC – демонстрация доказательства уязвимости и создание работающего эксплоита были одними из способов получения победных очков. И поскольку Mayhem была машиной, которую можно масштабировать, такой анализ может проходить с недоступными человеку скоростями.
Mayhem, как и шесть её соперников, требовала водяного охлаждения. Но статистика по потреблению и температуре показали, что Mayhem работала активнее остальных.
К созданию Mayhem мы подошли, имея готовую систему анализа ПО, разработанную нами в университете, и основанную на формальном анализе текста программы. Этот метод можно сравнить с математической формулой, описывающей каждый путь, по которому может пойти программа, то есть, выдающей постоянно разветвляющееся аналитическое дерево. Такое дерево может быстро стать слишком большим для работы с ним, но мы придумали хитрые способы устранения некоторых путей, сводящие всё дерево к нескольким ветвям. После этого мы уже можем изучать остающиеся ветви более подробно.
Символическое выполнение создаёт уравнение, обозначающее всю логику программы – к примеру, x + 5 = 7 – а затем решает это уравнение. Сравните эту стратегию с другим методом анализа ПО, фаззингом, когда вы пытаетесь скармливать программе случайные значения в попытках уронить её, после чего уже можно определять уязвимости, приведшие к останову и то, как их можно было бы использовать при намеренной атаке. Фаззинг вводит случайные данные до тех пор, пока они не делают значение уравнения истинным, определяя, что x = 2.
У обоих подходов есть свои сильные стороны, но много лет у фаззинга было преимущество лёгкости реализации и скорости обработки входных данных. Символьное исполнение таило в себе огромный и неосвоенный потенциал для любого, кому удалось бы его укротить. В системе Mayhem, которую мы начали создавать в 2010-м, мы смогли достичь этого, скомбинировав оба подхода.
Фаззинг – это попытки с огромной скоростью высказывать информированные предположения о том, какие именно входные данные могут заставить программу вести себя как-то по-новому, а потом отслеживать, какие именно данные действительно приводят к такому результату. Символическое выполнение – это попытки попросить математика формально вывести, какие именно входные данные могут помочь создать эксплоит. Мы обнаружили, что некоторые ошибки лучше находить через быстро высказываемые догадки, а другие – при помощи математического подхода. Поэтому мы решили использовать оба метода параллельно. Символическое выполнение углубляется в последовательное изучение одной части программы, и выдаёт входные данные, которые запускают эту часть кода. Затем система передаёт эти данные программе для фаззинга, которая начинает очень быстро молотить по этому участку кода, вытряхивая из него уязвимость.
Ещё одна способность Mayhem – работа напрямую с двоичным кодом, в отличие от людей, изучающих текстовые файлы, то есть, исходный код. Это значит, что система может анализировать программу без помощи разрабатывавшего её человека, и это очень важно в случае программ, в которые включены написанные сторонними разработчиками компоненты, исходного кода которых уже не найти. Но делать суждения по поводу двоичного кода сложно, поскольку в нём, в отличие от исходного, нет ни функций, ни логических переменных, ни абстракций данных. У двоичного кода есть только один участок памяти и битовые вектора фиксированной длины – эффективная структура хранения данных. Чтобы работать с таким кодом, надо быть машиной, и для создания машины, способной работать с такими ограничениями, инженерам действительно пришлось много поработать.
После определения уязвимости, Mayhem генерирует работающий эксплоит – такой код, которым мог бы воспользоваться блэк-хет хакер для взлома. Цель – продемонстрировать, что эксплоит можно использовать для получения привилегированного доступа к операционной системе. В результате Mayhem определяет уязвимости с абсолютной уверенностью, а не просто отмечает возможные проблемы, как это делает большинство инструментов для анализа кода.
В 2014 году мы испытывали Mayhem на всех программах, входящих в дистрибутив Debian, популярной версии Linux, которую во всём мире используют для рабочих компьютеров и серверов. Mayhem нашла почти 14 000 уникальных уязвимостей, а потом сузила этот список до 250 новых, заслуживавших наивысшего приоритета. Всё испытание заняло неделю, поскольку мы масштабировали Mayhem на много серверов в облаке Amazon, и практически не требовало вмешательства человека. Мы отправили наиболее важные находки на рассмотрение в сообщество Debian. Одной из причин нашего решения превратить исследовательский проект в коммерческую компанию было наше желание сотрудничать на таких масштабах с разработчиками, анализируя тысячи программ в поисках огромного числа уязвимостей.
Команда проекта Mayhem: инженеры из ForAllSecure позируют на фоне своего детища на церемонии закрытия. Автор статьи, Дэвид Брамли, в первом ряду, третий слева.
3 июня 2015 года более сотни участников было допущено в квалификационный тур, и им было выдано 131 уникальное задание, в каждом из которых были известные уязвимости. Семь команд, набравших наибольшее количество очков (выдаваемых за нахождение уязвимостей и патчи к ним) попали на финал Cyber Grand Challenge. ForAllSecure более чем в два раза превысила достижение участника, занявшего второе место по очкам. И этот краткий миг радости быстро уступил место осознанию того, что реальное давление начинается только сейчас!
Задача по созданию полностью автономной системы кибернетического принятия решений на базе технологии Mayhem оказалась сложнейшим предприятием. В частности нам удалось сделать это благодаря тому, что DARPA выделила семи финалистам достаточно финансов для того, чтобы поддержать целый год разработки. Среди основных компонентов технологии – набор инструментов, переводящих исполняемые программы в относительно лёгкий для понимания и анализа язык, а также активные инструменты для поиска и эксплуатации уязвимостей, защитные инструменты для автоматического создания патчей к дефектному двоичному коду, и программа для эффективной координации работы.
В подготовке к финалу мы столкнулись с двумя серьёзными трудностями. Во-первых, хотя мы были довольны тем, как Mayhem справляется с поиском уязвимостей, нам казалось, что патчи будут недостаточно эффективными. В соревновании, как и в реальности, нет смысла добавлять патч, который будет пожирать больше процессорного времени, чем стоит решение этой проблемы. Поэтому мы очень долго работали над системой добавления автоматических патчей, увеличивающих потребление не более, чем на 5%.
Во-вторых, нам нужна была выигрышная стратегия. Допустим, мы нашли уязвимость и сделали для неё патч. Возможно, не стоит сразу же накатывать его, если он замедлит работу программы слишком сильно. Иногда стоит подождать и применять патч только в самом крайнем случае. Мы разработали экспертную систему, принимающую решение о том, в какой момент нужно патчить программу.
Когда наша команда вошла в танцзал Лас-Вегаса, где 5 августа 2016 года проходил финал, мы увидели семь огромных стоек с мигающими огоньками, расположенными на огромной сцене, под которой был резервуар с 180 тоннами воды, охлаждавшей компьютеры участников. Участникам необходимо было подготовить машины накануне вечером перед началом состязания, а потом DARPA отбирала всякий доступ к ним. Машины были отрезаны от интернета и вообще от внешнего мира. Мы могли лишь следить за тем, как трудится Mayhem, наблюдать за энергопотреблением и температурой системы, статистика по которым выводилась рядом с каждой стойкой. Mayhem постоянно работал активнее соперников – и мы надеялись, что это был хороший признак.
В течение почти 100 раундов соревнующиеся системы получали новые программы, и должны были проанализировать код на наличие уязвимостей и выдать необходимые патчи для защиты всего за несколько минут. Очки в каждом раунде давались за способность машины найти и доказать наличие уязвимости, а также за эффективность патчей.
Победа с большим отрывом: Mayhem сумела создать большой отрыв, после чего упала после 40-го раунда. Но про этот отрыв команде не было ничего известно до самого конца соревнования.
Чтобы сделать представление более интересным, организаторы решили сообщить итоговые очки только в самом конце конкурса. Это означало, что в процессе мы не знали, побеждаем ли мы или проигрываем, мы лишь видели, как Mayhem отправляет сообщения о найденных уязвимостях. Однако, спустя несколько часов после начала соревнования, после 40-го раунда, нам стало ясно, что Mayhem перестал отправлять сообщения. Программа упала.
Внутри у нас всё сжалось, ведь нам казалось, что наш худший кошмар превращается в реальность. Мы попросили организаторов возможности перезагрузить программу, но они не разрешили нам сделать это. И поскольку была пройдена всего лишь половина соревнования, мы начали готовиться к позорному поражению.
Организаторы начали комментировать ситуацию по окончанию соревнований, и красивые визуализации демонстрировали нам, как машины каждой команды находили и исправляли проблемы с безопасностью в программах за секунды, по сравнению с теми месяцами или годами, которые потратили бы на это живые люди. В зале присутствовало более 5000 человек, и приглашённые комментаторы – астрофизик и известнейшие хакеры – подогрели их интерес. Мы подготовились к тому, что они объявят о нашем поражении и подтвердят его информацией на экране.
Однако наблюдая за очками, прибавлявшимися после каждого раунда, мы вдруг поняли, что первоначальный отрыв Mayhem оказался достаточным, чтобы сохранить за собой первое место, хотя он и закончил работать после 40-го раунда. После объявления результатов последнего раунда у нас будто гора с плеч свалилась. Мы победили.
Майк Уолкер, директор программы DARPA, сказал, что данная демонстрация автономной киберзащиты была «только началом революции» в мире безопасности ПО. Он сравнил результаты с первыми полётами братьев Райт, не улетевшими далеко, но указавшими путь трансконтинентальным перелётам.
Пока что ForAllSecure продаёт первые версии своего нового сервиса ранним клиентам, включая правительство США и компании, работающие в сферах высоких технологий и аэрокосмических областях. На данном этапе сервис в основном определяет наличие проблем, которые затем исправляют эксперты-люди. Ещё довольно долго системы, подобные Mayhem, будут совместно работать с людьми, экспертами по безопасности, делая мир ПО безопаснее. Но мы считаем, что в отдалённом будущем машинный интеллект сможет справиться с этой задачей самостоятельно.
Комментарии (8)
stanislavkulikov
01.03.2019 14:41Объясните мне пожалуйста, как автоматически можно создать патч, если проблема чисто логическая, например, будет скрываться в сложной логике авторизации? Т.е. я встречал проблемы, когда люди не могли придумать как исправить дыру в безопасности и всё не сломать. Как это исправить в автоматическом режиме я просто не представляю.
PerlPower
01.03.2019 18:20Вот кстати да. Допустим можно сделать так чтобы в каких-то случаях от автопатча программа безопасно падала, без непредсказуемых действий. Но чтобы при это сохранялась изначальная логика хотя бы на не-граничных входных данных? Одно дело если индекс массива криво прописан в алгоритме, и совсем другое если этот индекс приходит извне.
И 250 критических уязвимостей на всю кодовую базу дебиана — это ооочень мало. Настолько же мало как и какой-либок конкретики в статье.
Zwerg
03.03.2019 01:38Это все работает на уровне построения дерева ветвлений бинарного кода. Грубо говоря происходит анализ байт-кода, если при определенных условиях создается возможность переполнения буфера, нужно предотвратить возникновение этих условий. Патчится там все на лету опять же на уровне бинарных кодов. Я в 2015 на дефконе это дело слушал — очень было интересно.
qw1
03.03.2019 17:05Патчится каким образом? При обращении к buffer[i] при i >= N программа падает или заменяет это обращение на buffer[0]? Если падает, то чем это лучше, чем сразу писать на управляемом языке?
Zwerg
03.03.2019 20:59Вы знаете как сейчас фаззинг работает?
Скармливаем кучу барахла в переменную, смотрим что упадет и при каких условиях.
Там подход противоположен, они грубо говоря запускают программу в ГДБ, и везде где данные получаются от юзера/стороннего процесса пытаются проанализировать заданы ли граничные условия для параметра. Если не заданы, пытаются эксплуатировать. ТАм инструмент может использоваться как для подготовки эксплойтов на лету, так и для патчинга на лету. Патчится это очевидно в памяти, а не на диске. Что конкретно в этой реализации сделали для предотвращения BoF я очевидно не знаю. Там конкурсантов 6 или 7 было последний раз когда я проверял. У всех свои подходы и свой проприетарный алгоритм.qw1
03.03.2019 23:07Вы знаете как сейчас фаззинг работает?
Он даёт материал для размышлений исследователю. А тут как алгоритм автоматически реагирует, вообще непонятно. Вот и вы не знаете.
vesper-bot
Мда, запилить такой софт и не запилить к нему watchdog — красавцы. А что победили — красавцы вдвойне.