Содержание статьи
Друзья, вот уже много лет наш журнал пишет о том, как сломать то или это с одной стороны или как правильно защитить и что делать, чтобы это не сломали. Многие в ИБ-тусовке называют такую концепцию «взлом/защита» гонкой и противостоянием, что, в принципе, логично и понятно, но если смотреть с другой точки зрения, то вся эта борьба — единственный путь к недосягаемому совершенству, стабильному и надежному ПО. Давай же попробуем оглянуться на то, что было сделано за последние несколько лет в мире безопасности для решения этой проблемы.
Что есть безопасность
Так как тема широкая и довольно многогранная, мы не сможем обойти стороной повествование в стиле «люди и события», но все же будем смотреть на этот вопрос более акцентированно — атака/нападение, допустим на примере переполнения буфера. Резюмируя: давай посмотрим, как живут уязвимости в ПО (на примере переполняшки), как разработчики ПО «отвечали» этой проблеме, ну и как финал этой ретроспективы — попробуем проанализировать ближайшее будущее и развитие ПО в целом.
Начало
Принято считать, что изначально о безопасной разработке ПО никто в мире не думал, аж до червя Морриса, и лишь потом появились CERT и началась движуха с безопасной разработкой и так называемыми менеджерами. Например, насколько мне известно, именно червь Морриса содержал первый «документированный» эксплойт переполнения буфера. Да, как мы знаем, одна из самых популярных и известных уязвимостей — переполнение буфера, и впервые мир пострадал от нее в ноябре 1988 года, однако до сих пор мы сталкиваемся с этой уязвимостью в современных программных продуктах.
Было бы, кстати, неправильно не отметить, что в 1988 году Моррис показал эксплойт миру, но по факту об этой проблеме было известно аж с 1972 года! Именно тогда Джеймс Андерсон и группа других специалистов (работающих на правительство, а конкретно на ВВС США) выпустили работу Computer Security Technology Planning Study. В этой работе присутствует анализ угроз и атак для компьютерных технологий, актуальных тогда для ВВС США . Именно тогда было сформулировано множество интересных тем, от троянского коня до недоверия к обрабатываемым пользовательским данным. В контексте последнего и были выявлены угрозы работы с указателями (типа HeartBleed), и переполнений буфера. То есть уже в 1972 году отдельные организации были озадачены проблемами безопасности ПО, однако и в 2014-м мы имеем все те же самые проблемы. Конечно, стоит принимать во внимание сложность и масштаб. Все-таки в первую очередь ПО — это эффективный инструмент для ведения бизнеса и прочих дел, в 80-х компьютер уже не был редкостью в работе западных компаний, а в 90-х вопросы ИБ стали более актуальными.
Надо сказать, что с 1961-го по 1988-й безопасность программного обеспечения была вопросом логики и архитектуры, и, несмотря на то что единицы (будь то инженеры при правительстве США или единичные хакеры) находили и эксплуатировали уязвимости ПО, системного и массового развития эта тема не получала. К тому же большинство атак в 80-е также были «системными» и использовали не уязвимости в ПО, а скорее человеческий фактор, типа пароли по умолчанию и документированные особенности системы нестандартным образом. То есть не было большой угрозы, и существованию ПО (как продукта) угрозы не было, поэтому действия разработчиков была реактивными, а не проактивными: есть проблема — устраним. Такой подход был вполне рабочим до тех пор, пока количество проблем и атак не начало расти так, что переходило в реальную угрозу. Угрозу не конкретному клиенту с продуктом, а угрозу существованию всего продукта, идеи или технологии, глобальной безопасности. Подумай сам: если бы уязвимости в ПО не фиксились и любой человек мог получить полный доступ к твоему ПК, ты бы просто перестал пользоваться ПК или искал бы контрмеры. Вот разработчики и стали действовать проактивно где-то в 1990-х, а кто-то и в начале 2000-х.
Вернемся к нашей проблеме, с которой мы начали: переполнение буфера. Итак, о проблеме было известно с 1972 года, однако первая атака с использованием этой уязвимости датирована 1988 годом. Кажется, что 26 лет — это много, но стоит помнить, что распространение ПО и компьютеров не было массовым, да и возможности проводить такие атаки были очень ограниченными (интернета не было, сервисов, доступных по сетям, — тоже не особо). Теория стала практикой, когда появились векторы атаки, а до того это было неактуально.
Эволюция
Итак, с 1972-го по 1988-й атака у нас была теоретическая, но известная. В следующий период сети и технологии, интернет и BBS развивались в странах, которые были далеки от всего этого. Разработчики продолжали писать софт, возможно подозревая о каких-то мифических атаках, но разницы в мотивации и конкретных действий по сравнению с тем, что было до 1988 года, не наблюдалось. Все осталось как было. Почти. На самом деле концепция фаззинга, для тестирования ПО в том числе и с целью поиска ошибок ввода и переполнения буфера, появилась почти сразу после червя Морриса, в 1990 году . Однако зачем это нужно разработчикам, для которых такое явление скорее научный проект, чем выгодный бизнес, пока неясно. Но с другой стороны баррикад все менялось — хакеров становилось все больше и больше, информация распространялась (Фидо, интернет), как и легенды.
Так, следующий известный мне публичный эксплойт на переполняшку появился в 1995 году . Немец просто поставил NCSA HTTPD и, так как он читал про червя Морриса, по аналогии нашел такую же проблему и в этом HTTP-сервисе, о чем и отписал в созданный в 1993 году лист рассылки bugtraq. Классика в чистом виде. Позже появлялись единичные сплоиты, так, за 1995 год их было опубликовано аж целых два. Короче было это дело тех, кто самостоятельно может проанализировать аналоги, понять, как работает, и применить эти знания на новом объекте. При этом техника и идея не сильно меняется. Разумеется, было и множество приватных эксплойтов, которые не попадали в багтрек, но все равно масштабы были не такие, как, допустим, в наше время.
Однако в 1996 году выходит популярная работа, которая подробно разжевывает шаги по эксплуатации этой уязвимости, фактически учебник для новичков — . И надо сказать, что это дало ход делу. Эксплойтов стало появляться все больше и больше, учитывая, что интернет уже был довольно распространенным и ПК и сервисов было уже очень много, да и само ПО становилось сложнее и избыточнее в коде. Короче, целей для атак стало много, а главное — вектор атаки стал простым и реальным, а знания доступными. К слову сказать, основная цель атак — сетевые и локальные сервисы. Очевидно, что имеется некая глобальная проблема в безопасности, которая основана на фундаментальных принципах функционирования компьютера (фоннеймановская архитектура), а поскольку ПО стало важной частью бизнеса и жизни многих людей, необходимо предпринимать какие-то действия. Уже в 1998 году (за год до) на конференции USENIX Security Symposium году был представлен StackGuard — технология защиты адреса возврата с помощью stack canaries. И тут уже действительно начинает работать принцип гонки: «вот вам защита» с одной стороны и «а я тогда обойду ее так» — с другой. Очевидно, что это лучший способ эволюции для ПО, и разработчики приняли вызов: cтало нерентабельным для бизнеса делать ущербное ПО, а постоянно латать дыры еще и дороже, чем пытаться изначально их не допускать. Индустрия ИБ начинает расти где-то в это время, но мы не будем рассматривать всю картину, так как ограничиваемся только переполнением буфера.
В 2001 году Билл Гейтс сказал, что так дальше жить нельзя, и вложил в безопасность своей, безумно популярной ОС огромные деньги. Разумеется, это не работает сразу, и первые плоды появились лишь в середине 2000-х: и защита адреса возврата, и SEH-обработка, и поддержка бита NX — все это результат той борьбы. Разумеется, хакеры также не сидели на месте, и было опубликовано множество эксплойтов и работ на тему обхода этих защитных механизмов, про что мы не раз писали (так как в это время и наш журнал стал вносить лепту в эту борьбу, распространяя информацию). В Open Source мире, так же как и в MS, очень охотно принимали поддержку всего, что помогало защититься от этой напасти, — DEP, PIE, FORTIFY. Тем не менее проблемы обратной совместимости, необходимость в поддержке этих вещей сторонними разработчиками (а тут у нас человеческий фактор) — все это делает наш мир пока еще несовершенным. Кроме того, разработчики стали использовать различные парадигмы безопасной разработки — во всех софтверных компаниях, для которых безопасность продукта — важный показатель качества и ответственности, имеются процедуры фаззинга, анализа кода на уязвимости, обучение программистов навыкам безопасного кодинга и так далее.
Уже в конце 2000-х практически перестали появляться боевые эксплойты с переполнением буфера под сетевые сервисы (Windows/*nix — не важно). Вообще говоря, уже в середине 2000-х акцент эксплойтов на переполняшку сместился на клиентское популярное ПО. Например, когда в начале 2000-х разработчики «серверных» компонентов подошли более конкретно к валидации пользовательских данных и смогли снизить количество уязвимостей к концу 2000-х, разработчики клиентских программ не видели проблем и спохватились лишь тогда, когда хакеры перешли на них (а до этого было нерентабельно, не было потребности).
Сейчас
В данный момент защита от BoF — это дело разработчика (не допустить ошибки, поддержать технологии защиты), ОС (предоставить методы страховки от эксплуатации), пользователя (озадачиться риском для себя и, например, поставить EMET) и даже железа (ага, например, в 2005 году не все процессоры поддерживали NX-бит). Есть тут место и хакерам — они постоянно заинтересованы во взломе всего этого стека защиты, и если они это смогли сделать, то значит, с той стороны сделали не все, чтобы защитится. Эта борьба продолжится до тех пор, пока хакеры не перейдут на что-то более перспективное и легкое (в любом смысле — продукт, тип уязвимости или пользователя). В целом вся эта экосистема делает эволюционное развитие всей системы — уже сейчас эксплойты на переполнение появляются в основном для мелких или экзотических продуктов, «война» еще не закончена, но путь с 1972-го до 2014-го очень значительный и показательный — с ростом значимости сетей и компьютеров растет и значимость безопасности. Основной этап борьбы все же прошел с 1996 до 2012 года (мои внутренние ощущения), для того, чтобы осознать, как побеждать проблему и что это возможно (с некоторой очень высокой вероятностью). Всего этого бы не было без всех участников событий — без хакеров, без инженеров и даже, как ни странно, без менеджеров и бизнесменов, просто каждый выполняет свою роль.
Будущее
Человеческий фактор пока что главная проблема несовершенства — даже имея все технологии и методы защиты от такой проблемы, как BoF, мы все еще их встречаем. Как сказано выше — сейчас это не Google и Microsoft, а более мелкие вендоры, которые не столкнулись с значимостью безопасности своих продуктов, что логично. Но другая реальность видится мне более значимой проблемой для нас. Повторяется история 80–90-х — было много важного и уязвимого ПО, но оно было изолировано от хакеров, поэтому разработчики, даже зная, что у них есть уязвимости (хотя бы в теории), игнорировали эту проблему по причине нерентабельности и значимости — нет угрозы. Пример АСУ ТП — софт там такой же, как и везде, а вот решений проблем безопасной разработки в контексте современных угроз мало. Сообщество разработчиков АСУ ТП было не готово встретить тот факт, что кто-то сможет и будет атаковать их продукты. Учитывая, что доступность АСУ ТП сетей через интернет пока не очень обширна, мы не имеем проблем с реальными атаками в массе. Пока это единичные случаи, которые основаны на куче условий, вроде заразить флешку или подрубиться к токовой линии, — векторы реальны, но не многочисленны, а инцидентов мало. Поэтому поезд едет медленно.
C другой стороны, я вижу автопроизводителей, которые выводят автомобили в сети, в том силе и в интернет и в радиоканалы, — со слабо подготовленным для современных угроз ПО. И я смело вангую, что следующие десять лет пройдут не под лозунгом безопасности АСУ ТП, а под лозунгом безопасности автомобилей и появятся первые эксплойты, в том числе и RCE под реальные машины. Производители авто прекрасно знают, что эра их взломов идет, но стали думать они об этом немного поздно: к сожалению, обновление прошивок для компонентов автомобиля и ОС — процесс не совсем отлаженный и простой. Поэтому я верю, что BoF возродится, просто в другой среде. Тем не менее дорожка по защите протоптана — ОС QNX и ARM-чипы (которые используются в тачках) поддерживают и NX, и ASLR. Ребята, мы делаем будущее, и неважно, с какой стороны. Хакер ли ты и публикуешь ресерч, как ломать, или ты менеджер, внедряющий SDLC, — все мы часть большой экосистемы, и результат наших трудов один — более совершенные технологии, ПО и мир!
