Текст книги "Как противостоять хакерским атакам. Уроки экспертов по информационной безопасности"

Информация о Кевине Митнике

Более подробно познакомиться с историей Кевина Митника можно по ссылкам:

• официальный сайт Кевина Митника: https://www.mitnicksecurity.com/;

• «Призрак в Сети. Мемуары величайшего хакера»: https://book24.ru/product/prizrak-v-seti-memuary-velichayshego-khakera-180793/;

• «Искусство быть невидимым»: https://book24.ru/product/iskusstvo-byt-nevidimym-kak-sokhranit-privatnost-v-epokhu-big-data-5255267/;

• The Art of Deception: https://www.amazon.com/Art-Deception-Controlling-Element-Security/dp/076454280X/;

• «Искусство вторжения»: https://www.amazon.com/Art-Intrusion-Exploits-Intruders-Deceivers/dp/0471782661/;

• тренинг Кевина Митника, посвященный вопросам ИБ: https://www.knowbe4.com/products/kevin-mitnick-security-awareness-training/;

• интервью с Кевином Митником: https://news.slashdot.org/story/11/09/12/1234252/Kevin-Mitnick-Answers.

6. Уязвимости программного обеспечения

Уязвимости программного обеспечения – слабые места (т. е. ошибки), которые появляются из-за недостатков, внесенных разработчиком или присущих языку программирования. Не каждый баг – это уязвимость. Ошибка должна быть доступна злоумышленнику, чтобы стать угрозой или риском. Большинство программных ошибок вызывают проблемы в работе (которые могут и не проявляться непосредственно у пользователя) или даже приводят к фатальному прерыванию работы, но не могут быть использованы злоумышленником для получения несанкционированного доступа к системе.

Уязвимые места в ПО ответственны за большой (если не подавляющий) процент взломов в настоящее время, несмотря на то что другие методы взлома (такие как троянские программы и социальная инженерия) зачастую весьма конкурентоспособны. Некоторые эксперты по ИБ считают, что большинство проблем исчезнут, если все программы будут написаны без ошибок. Тем не менее, даже если это не панацея, более надежный код с меньшим количеством уязвимостей сведет на нет значительную часть хакерских проблем и сделает компьютерную среду существенно безопаснее.

Количество уязвимостей программного обеспечения

Существует множество источников для отслеживания уязвимостей общедоступного ПО, хотя список ошибок для каждого из них может существенно отличаться. В среднем каждый год крупные разработчики программного обеспечения и баг-файндеры объявляют о 5–6 тысячах новых уязвимостей ПО, то есть около 15 находках ежедневно. Организация Common Vulnerabilities and Exposures (https://cve.mitre.org/) и публикуемая ею база данных общеизвестных уязвимостей информационной безопасности (https://cve.mitre.org/data/downloads/index.html) считаются инклюзивными, надежными и независимыми источниками и хорошо подходят для отчетности и отслеживания общедоступных уязвимостей. Многие другие разработчики отслеживают либо собственные уязвимости, либо все известные. Прочитайте отчет Microsoft Security Intelligence (https://www.microsoft.com/ru-ru/security/business/security-intelligence-report), чтобы узнать последние цифры и результаты анализа.

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

Примечание. Количество уязвимостей ПО – это только один из аспектов, а не полная картина безопасности программы или системы в целом. Единственное, что действительно имеет значение, – какой урон был нанесен уязвимостями программного обеспечения. Количество таких уязвимостей, вероятно, войдет в историю как объем ущерба, хотя в целом использовать более безопасные программы будет лучше для всех.

Почему уязвимости ПО – по-прежнему большая проблема?

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

Общее количество эксплойтов довольно велико и постоянно. Значительная часть ресурсов компьютерного администрирования тратится на исправление ошибок. Это невероятная трата времени, денег и других ресурсов, которые лучше пустить на более продуктивные вещи. Даже когда пользователи и администраторы исправляют ошибки, со временем, когда разработчик допускает новую, хакер может ею воспользоваться до того, как пользователь закроет ее патчем. Если я терпеливый и настойчивый хакер, преследующий определенные цели, то могу просто подождать, пока разработчик не оповестит о новой ошибке, и использовать ее для достижения своей цели.

Когда разработчики выпускают патчи, «белые шляпы» и «черные шляпы» немедленно анализируют их, чтобы найти целевую уязвимость. Затем они создают эксплойты, которые могут ее эксплуатировать. Существуют десятки коммерческих компаний, несколько бесплатных сервисов и неизвестное количество хакеров, которые делают это каждый день. Вы можете приобрести и/или загрузить сканеры уязвимостей, которые будут сканировать устройства и сообщать о незакрытых уязвимостях. Эти сканеры часто содержат тысячи и тысячи эксплойтов. Есть много хакерских веб-сайтов по всему миру с тысячами отдельных эксплойтов, которые вы можете скачать, чтобы эксплуатировать определенную уязвимость. Один из самых популярных бесплатных инструментов – это Metasploit (https://www.metasploit.com/).

Защита от уязвимостей программного обеспечения

Защита от уязвимостей ПО номер один – это квалифицированные разработчики и более безопасные языки программирования.

Процесс, преследующий цель уменьшить число уязвимостей программного обеспечения, теперь широко известен как жизненный цикл безопасной разработки. Он сосредоточивается на каждом компоненте в жизненном цикле программы ПО, от ее начального создания к исправлению недавно найденных уязвимостей, чтобы реализовать более безопасное программное обеспечение. Компания Microsoft Corporation, вероятно, лучше всего потрудилась в этой области и опубликовала больше свободно доступной информации и инструментов (https://www.microsoft.com/en-us/securityengineering/sdl/), чем любой другой источник. Человеческий фактор гарантирует, что программный код всегда будет иметь эксплуатируемые ошибки, но, следуя жизненному циклу безопасной разработки, мы можем допускать меньше ошибок на то же количество строк кода.

Примечание. Доктор Даниэль Бернштейн (https://en.wikipedia.org/wiki/Daniel_J._Bernstein) – профессор в колледже, который пишет и продвигает невероятно безопасный код. Он создал несколько бесплатных и широко используемых программ, таких как dbjdns и qmail, в которых крайне мало ошибок. Он даже платит за найденные баги из собственного кармана. Даниэль верит, что разработчикам становится стыдно, когда он публично объявляет об ошибках, прежде чем предоставить разработчикам возможность анализировать и исправлять свои продукты.

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

После разработки версии программы ее всегда следует анализировать на отсутствие известных и распознаваемых ошибок. Это можно сделать вручную или с помощью программных средств. Анализ вручную, как правило, наименее эффективен, так как обнаруживает наименьшее количество ошибок в час, но он чаще находит эксплуатируемые ошибки, которые нельзя отыскать с помощью программы. Программные средства поиска ошибок часто называют «статическими анализаторами» или инструментами «фаззинг-тестирования». Они проверяют исходный код (или программы) на наличие известных программных ошибок в самом коде. Фаззинг-анализаторы вводят случайные (или неправильные, неожиданные) данные и ищут уязвимости в программе во время выполнения. Многие печально известные специалисты, ищущие уязвимости ПО, включая Чарли Миллера, о котором мы поговорим в главе 36, полагались на фаззинг-тестирование во многих своих открытиях.

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

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

Идеальное программное обеспечение не решит все проблемы

Никакая защита не сравнится с ПО, которое изначально разрабатывается с учетом средств защиты и исключением ошибок. Тем не менее идеальное, безошибочное программное обеспечение не решит все проблемы. К сожалению, его уязвимости не единственная наша проблема. Троянские программы срабатывают только потому, что их запускает сам пользователь. Многие хакеры и вредоносные программы используют типичные, часто легитимные возможности данных, языков программирования и других компонентов, чтобы совершать злодеяния. А социальная инженерия может сделать то, на что не способно программное обеспечение. Тем не менее никто не спорит, что более безопасные программы не могут быть панацеей.

В следующих главах мы поговорим о двух экспертах, посвятивших свою жизнь совершенствованию ПО. Глава 7 посвящена Майклу Ховарду, который популяризировал более безопасные методы разработки, а глава 8 фокусируется на Гари Макгроу, одном из лучших специалистов по поиску уязвимостей в истории.

7. Профиль: Майкл Ховард

Майкл Ховард – отличный педагог и энергичный оратор, который за 20 лет работы в сфере ИБ не утратил ни грамма энтузиазма, которым заражает всех, кто с ним сталкивается. Обычно пары минут общения с Майклом достаточно, чтобы собеседник загорелся желанием сделать мир более безопасным с помощью нескольких строк кода. Он получил всемирное признание, написав книгу Writing Secure Code (https://www.amazon.com/Writing-Secure-Code-Michael-Howard/dp/0735615888) вместе с Дэвидом Лебланом. Кроме того, он сделал очень много для того, чтобы компания Microsoft стала приверженцем идеи безопасного программирования. Ховард родом из Новой Зеландии, но сейчас живет в Остине, штат Техас. Он стал соавтором нескольких книг по безопасному программированию и ведет собственный блог.

Примечание. Дэвид Леблан, в соавторстве с которым Ховард написал книгу Writing Secure Code, – еще один прогрессивный специалист по ИБ. Он значительно обезопасил пакет Microsoft Office и создал более безопасную модель браузера, которая в настоящее время используется компаниями Google, Adobe и Microsoft.

Я спросил Ховарда, как он пришел в сферу ИБ. Вот что он ответил: «Я работал над ранними версиями Windows NT в компании Microsoft. Отвечал за такие низкоуровневые аспекты, как контроль доступа, криптография и графические интерфейсы GINA (которые раньше использовались для авторизации в операционной системе Microsoft Windows и других сервисах аутентификации). Это заставило меня задуматься о безопасности как о функции. Примерно в 2000 году стало ясно, что встроенные в продукт защитные функции не делают его по-настоящему безопасным, поэтому мы должны сосредоточиться на разработке безопасных функций, а это совершенно другая дисциплина».

На мой вопрос об истории возникновения концепции SDL в компании Microsoft он сказал: «Со временем различные практики обеспечения безопасности, изученные командами разработчиков. NET Framework, Windows, Office и SQL Server, а также других продуктов, превратились в концепцию SDL (Security Development Lifecycle, жизненный цикл безопасной разработки). Эта концепция помогла популяризировать идею безопасного программирования, и во многом именно благодаря ей компании стали гораздо лучше защищать свое ПО».

Я спросил Ховарда, стала ли концепция SDL результатом совершенствования уже существовавшего подхода или чем-то абсолютно новым, на что он ответил: «Мы все опираемся на работу других людей, однако бо́льшая часть концепции SDL – это результат экспериментов. То, что работает, остается, а то, что не работает или оказывается нецелесообразным, отбрасывается. Иногда я задаюсь вопросом о том, были ли те или иные академические модели опробованы в производственной среде со всеми ее дедлайнами, требованиями к производительности, сроками вывода продукта на рынок, экономическими соображениями, обеспечением обратной совместимости и т. д.

В то время было принято считать, что улучшение качества кода автоматически делает его более безопасным. Но я не видел никаких эмпирических доказательств этой идеи. Вы можете создать функциональный SQL-код, который проходит все функциональные тесты, но он может оказаться уязвим к SQL-инъекциям. Если вы никогда не сталкивались с ними, вы увидите перед собой лишь идеальный код, который делает то, что от него требуется. Безопасная система делает только то, что должна, и не более того, – небезопасной ее делает “дополнительная функциональность”, связанная с уязвимостью к SQL-инъекциям».

Когда я спросил о его роли во внедрении компанией Microsoft концепции SDL, Ховард сказал: «Этому способствовало сочетание различных вещей, над которыми помимо меня работало множество людей. Все началось в конце 2001 года, когда команда разработчиков. NET провела мероприятие, где обсуждались текущие проблемы безопасности и потенциальные риски. Благодаря ему мы многому научились и добавили множество новых средств защиты. Я помню, что для этого мероприятия было заказано несколько футболок с нанесенной на них датой конференции, правда, из-за начавшейся снежной бури ее пришлось отложить… Так что по иронии судьбы на мероприятии, посвященном повышению безопасности кода, мы все ходили в футболках с неправильной датой. Однако уроки, полученные в ходе этой конференции, в итоге были положены в основу концепции SDL. Публикация нашей с Дэвидом книги заставила многих людей задуматься о безопасности кода. В 2001 году система компании Microsoft подверглась множеству атак со стороны хакеров и вредоносных программ. Особенно серьезный ущерб нанесли черви Code Red и Nimda. Билл Гейтс спросил нас о природе уязвимостей в ПО и о том, почему мы до сих пор их не устранили. Будучи частью команды, с которой он встретился, я вручил ему раннюю копию книги Writing Secure Code, и после встречи он написал свою знаменитую заметку «Надежные вычисления» (https://www.wired.com/2002/01/bill-gates-trustworthy-computing/), в которой упомянул нашу книгу, благодаря чему ее продажи выросли в разы! В итоге я перешел на работу во вновь созданное подразделение надежных вычислений Microsoft. После этого был проведен ряд аналогичных мероприятий, посвященных проблемам безопасности ОС Windows, SQL Server и многих других продуктов Microsoft. Все это способствовало проработке концепции SDL, которая обновляется практически ежегодно».

Я спросил, действительно ли он и компания Microsoft предоставили больше информации и инструментов, связанных с безопасным программированием, чем любая другая организация. Он сказал: «Однозначно да! Но что еще более важно, все эти инструменты и методы мы используем в своей производственной среде, ежедневно применяя их к миллионам строк кода. Это не отвлеченная теория. Это то, чем занимается одна из крупнейших компаний в мире. И она охотно делится своим наработками».

Я спросил, почему количество публично анонсируемых уязвимостей не сокращается, несмотря на то, что программисты все больше узнают о проблемах информационной безопасности. Вот что сказал Ховард: «Отчасти это связано с появлением все большего количества программ, содержащих множество строк кода. Однако главная проблема заключается в том, что программистов все еще не обучают методам безопасного программирования, и они плохо осознают основные угрозы. Большинство образовательных программ не отвечают современным потребностям. На днях, просматривая учебную программу по информационной безопасности одного университета, я обратил внимание на то, что почти половина занятий посвящена низкоуровневым сетевым угрозам. Я не обнаружил лекций по обеспечению безопасности облака или безопасному программированию. Наши колледжи все еще выпускают программистов, которые мало что знают об информационной безопасности и разработке безопасного ПО, что довольно странно, учитывая то, что этим выпускникам предстоит создавать критически важные системы, подключенные к Интернету. Я до сих пор нахожу примитивные ошибки в коде других людей. Когда я демонстрирую им весьма распространенную проблему, связанную с повреждением памяти, или уязвимость к SQL-инъекции, на меня смотрят так, будто я совершил нечто невероятное. Программисты, знакомые с основами информационной безопасности, встречаются так редко, что я радуюсь, если кандидат хотя бы проявляет интерес к этой теме. Если программист внимательно слушает, когда я говорю о проблемах ИБ, это делает меня счастливым. Если человек заинтересован, мы можем научить его всему остальному. Но вы даже не представляете, скольким людям нет до этого никакого дела, и одна из главных причин в том, что их этому до сих пор не учат. Или учат, но не тем вещам, делая акцент на сетевой безопасности или каких-нибудь мелочах. Студентам подробно описывают принцип работы алгоритма RSA, но не объясняют, почему он должен использоваться, какие проблемы он решает и для каких целей подходит лучше всего. Умение правильно использовать инструмент для решения реальных проблем безопасности гораздо важнее понимания принципа его работы. Любой человек может разобраться в работе протокола, однако нам нужны люди, осознающие риски и думающие о решениях. Правда, существуют некоторые преподаватели и колледжи, которые придерживаются правильного подхода, например Мэтт Бишоп из Калифорнийского университета в Дэвисе. Он и другие неравнодушные преподаватели – настоящие герои».

Я спросил, что может сделать сам программист, учитывая то, что большинство колледжей недостаточно хорошо готовят студентов в этом отношении. Он посоветовал: «Постоянно учитесь. Я ежедневно выделяю час на учебу. Я читаю, пишу код и экспериментирую с чем-то новым. И занимаюсь этим на протяжении всей своей карьеры. Кроме того, если в вашем учебном заведении нет формального курса по информационной безопасности, разработайте собственную обучающую программу. Перейдите на сайт https://cve.mitre.org/cve/ и внимательно прочитайте о недавно обнаруженных уязвимостях. Затем напишите код, содержащий одну из них, и подумайте, что нужно было сделать для предотвращения ее появления как на техническом уровне, так и на уровне процессов. Выясните, откуда взялась эта уязвимость и как именно попала в код. А затем используйте извлеченные уроки, чтобы предотвратить появление подобных ошибок в вашем собственном коде».

На вопрос о том, что могут сделать компании для создания более безопасного кода, помимо следования текущим принципам SDL и использования доступных инструментов, он ответил: «Сделайте так, чтобы программисты не только понимали теоретические основы, но и осознавали реальные угрозы. Кроме того, вам следует встроить процесс обеспечения безопасности в сам конвейер разработки ПО, чтобы плохой и небезопасный код не мог в него попасть. В Microsoft мы используем так называемые ворота качества. Хороший (не связанный с безопасностью) пример – это написание кода, который предполагает, что все IP-адреса состоят из четырех октетов. Это означает, что такой код никогда не будет работать в чистой среде IPv6. Этот код даже не сможет пройти проверку, поскольку специальный инструмент, работающий в автоматическом режиме, выявит проблему и предотвратит его сохранение в системе. Вот что мы подразумеваем под термином “ворота качества”. В целях обеспечения безопасности этот же подход можно применить для выявления уязвимостей к SQL-инъекциям, угроз, связанных с безопасностью памяти, и всего того, что вы не хотите видеть в своем коде.

Если бы меня попросили назвать несколько основных практик, связанных с обеспечением безопасности, то я выбрал бы следующие:

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

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

• наконец, тестировщики должны доказать неправоту разработчиков, создавая или приобретая инструменты, которые генерируют вредоносные и/или недействительные данные. Цель в том, чтобы выявить недочеты, допущенные разработчиками, если они есть.

Разумеется, это далеко не все, что требуется для обеспечения безопасности ПО, но, на мой взгляд, это те фундаментальные навыки, которыми должны обладать все инженеры-программисты».