Взломать всё. Как сильные мира сего используют уязвимости систем в своих интересах

Если вы не создаете «красную команду», то, чтобы найти уязвимости в своих системах, вам придется полагаться на своих же врагов. Но если уязвимости находит кто-то другой, как вы можете быть уверены, что они будут устранены, а не использованы? В компьютерном мире основным средством противодействия использованию хакерами плодов своих усилий является признание компьютерного взлома преступлением. Если вы хакер и обнаружили новую уязвимость, то можете использовать ее с риском получить тюремный срок. Но вы также можете продать информацию на черном либо на сером рынке.

Противодействующим стимулом являются поощряющие программы, известные как bug bounties, когда компании-разработчики программного обеспечения выплачивают вознаграждение людям, обнаружившим уязвимости в их продуктах. Идея заключается в том, чтобы заинтересовать исследователей сообщать о своих находках в компанию. Bug bounties неплохо справляются со своей задачей, хотя зачастую хакеры могут заработать куда больше, толкая информацию об уязвимостях преступникам или производителям кибероружия.

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

13

Устранение потенциальных хаков на этапе проектирования систем

Автозапуск – функция, впервые появившаяся в Windows 95. До этого момента вы покупали программное обеспечение на компакт-диске, а затем вручную запускали сценарий установки на своем компьютере. С автозапуском вы могли просто вставить диск в дисковод, и система автоматически находила и запускала сценарий установки. Это значительно упрощало установку программного обеспечения для среднего, технически неграмотного пользователя.

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

Обратите внимание, что в данном случае уязвимость не является следствием ошибки. Это была попытка найти баланс между безопасностью и удобством использования. Найденный компромисс, возможно, и выглядел разумным в 1995 г., чего нельзя было сказать о нем десятилетие спустя. Cообщения о системных ошибках, вызванных автозапуском, стали множиться как грибы после дождя, и в 2011 г. Microsoft наконец-то перепроектировала систему для Windows Vista, отключив функцию автозапуска для флешек, сетевых дисков и прочих носителей, оставив ее только для таких вымирающих мастодонтов, как DVD-диски.

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

Вместо того чтобы находить уязвимости в системе до того, как она будет взломана, мы можем попытаться создать систему с меньшим количеством уязвимостей, то есть сделать так, чтобы они не существовали изначально

. В сфере информационной безопасности это называется проектированием безопасных систем.

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