Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Но в реальном мире противник, оборудовавший себе плацдарм в локальной сети по любую сторону от маршрутизатора, занимает прекрасную позицию для организации атаки на сеть в силу отсутствия защитных мер в инфраструктуре сети–жертвы. Если противник находится в том же сегменте сети, что и одна из оконечных точек (например, подключен к концентратору), то он может просматривать весь трафик в этом сегменте и обычно способен перехватить его. Но даже если противник подключен к коммутатору (концентратор, в котором отдельные порты не «видят» трафика на других портах), то и тогда техника подлога по протоколу ARP (Address Resolution Protocol – протокол разрешения адресов) позволяет ему притвориться шлюзом и перенаправить на себя весь трафик. Обработав трафик, противник может отправить его первоначальному адресату. Есть и другие методы. Например, некоторые коммутаторы можно затопить потоком ARP–запросов, в результате чего они переходят в пропускающий (promiscuous) режим и начинают работать как обычный концентратор.
Как все это реализуется? ARP – это протокол, отображающий адреса уровня 2 (Ethernet MAC) на адреса уровня 3 (IP). Противник может объявить, что его собственный МАС–адрес соответствует IP–адресу шлюза. Когда остальные машины видят такое объявление, они начинают маршрутизировать весь трафик через компьютер противника. У этой проблемы нет практичного и универсального решения, которое можно было бы реализовать быстро, поскольку речь идет о базовых службах на уровне Ethernet, которые только–только начинают обсуждать в органах стандартизации. Кстати, в беспроводных сетях эта проблема стоит еще более остро.
Даже на уровне маршрутизатора не всегда можно предполагать отсутствие вектора атаки. Популярные маршрутизаторы работают под управлением больших и сложных программ на языке С, которые могут быть подвержены ошибкам переполнения буфера и иным, что позволит противнику исполнить произвольный код. Пока производители маршрутизаторов не перейдут на технологии, которые сведут к минимуму или вообще исключат риск такой катастрофы, опасность будет существовать. И ведь находили же в прошлом ошибки переполнения буфера в маршрутизаторах. См., например, бюллетени CVE–2002–0813, CVE–2003–0100 и CAN–2003–0647 в базе данных CVE (http://cve.mitre.org).
Сетевые атаки весьма разнообразны.
□ Подслушивание. Противник прослушивает сеанс связи и извлекает всю ценную информацию, например имена и пароли пользователей. Даже если пароль передается не в читаемом виде (а часто так и есть), почти всегда возможно путем перебора по словарю раскрыть его. А иногда и это не нужно, поскольку пароль не шифруется, а лишь маскируется.
□ Воспроизведение. Противник извлекает уже имеющиеся в потоке данные и воспроизводит их. Это может быть весь поток или какая–то его часть. Например, можно воспроизвести данные аутентификации, чтобы зарегистрироваться под чужим именем, а затем начать сеанс от чужого имени.
□ Подлог (spoofing) . Противник представляет данные, как бы пришедшие от другого участника сеанса связи, хотя на самом деле данные подложные. Обычно для этого требуется открыть новое соединение, возможно, воспроизведя данные, посланные во время предыдущей аутентификации. В некоторых случаях такую атаку можно провести против уже существующего соединения, особенно когда виртуальное соединение устанавливается поверх транспортного протокола, не поддерживающего соединений (обычно UDP). Очень трудно (хотя и возможно) проделать такое с протоколами, требующими установления соединения, если операционная система должным образом рандомизирует порядковые номера, применяемые в протоколе TCP.
□ Вмешательство. Противник модифицирует передаваемые данные, возможно, вполне невинно, например заменяя единичный бит нулевым. В протоколах на базе TCP это довольно сложно из–за кодов циклической избыточности (CRC), но поскольку CRC–код не является криптографически безопасным, то такую защиту легко обойти, когда есть возможность поменять несколько битов, не оказывающих существенного влияния на обработку данных.
□ Перехват. Противник ждет момента установления соединения, а затем отрезает одного из участников, подменяя все исходящие от него данные своими. В наши дни внедрить новый трафик в середину сеанса или подделать существующий довольно трудно (по крайней мере, в случае использования протокола TCP и современных операционных систем на обоих концах), но все–таки возможно.
Если вас беспокоит безопасность сетевых соединений, то вы должны знать, какие услуги могут предоставлять приложения. Мы сначала поговорим о базовых службах, а потом – в разделе «Искупление греха» – о способе достижения цели. Как бы то ни было, для защиты от такого рода атак необходимо обеспечить три основных сервиса безопасности.
□ Начальная аутентификация. Необходимо гарантировать, что каждая сторона знает, с кем общается. Есть много способов добиться этого, но самыми распространенными являются пароли в силу своего удобства. Говоря о данном грехе, мы не будем затрагивать вопросы аутентификации, но еще вернемся к ним в грехах 10, 11 и 17.
□ Аутентификация во время сеанса. Даже если вы уверены в том, с кем начали общаться, хотелось бы удостовериться, что вы продолжаете обмен данными с тем же лицом. Это более строгий вариант обеспечения целостности сообщений. Легко убедиться в том, что пришло именно то сообщение, которое было отправлено, но неплохо бы знать еще, что его отправил законный пользователь, а не противник. Например, протокол TCP обеспечивает слабую проверку целостности сообщения, но никакой аутентификации.
□ Конфиденциальность. Это, наверное, наименее важный из сервисов безопасности. Есть немало ситуаций, когда нужно лишь гарантировать аутентичность данных, а шифровать их необязательно. Обычно не имеет смысла обеспечивать конфиденциальность без начальной и последующей аутентификации. Например, если противник пользуется потоковым шифром, например RC4 (у него есть также режимы работы, обеспечивающие блочное шифрование), то он может переставить случайные биты в шифртексте, и без надлежащей аутентификации сообщения об этом никто не узнает. Если противнику известен формат данных, то он сможет добиться и более разрушительного эффекта, поменяв конкретные биты.
Родственные грехи
Совсем несложно полностью игнорировать вопросы безопасности в сети. Но не менее просто воспользоваться сервисами безопасности неправильно, особенно это относится к протоколам Secure Sockets Layer и Transport Layer Security (SSL / TLS) (Грех 10). Аутентификация тоже является важной частью инфраструктуры сетевой безопасности и также нередко становится точкой отказа (см., например, грехи 11, 15 и 17). Для обеспечения конфиденциальности нужен криптографически сильный алгоритм генерирования случайных чисел (грех 18).
Где искать ошибку
Этот грех обычно проявляется, когда:
□ приложение пользуется сетью;
□ проектировщик не обращает внимания на риски, связанные с работой в сети, или недооценивает их.
Например, типичный аргумент звучит так: «мы ожидаем, что этот порт будет доступен только из части сети за межсетевым экраном». На практике в большинстве случаев нарушения безопасности так или иначе участвуют люди, причастные к работе компании, – недовольные, подкупленные или желающие оказать дружескую услугу сотрудники, уборщики, клиенты, поставщики, приехавшие осмотреть место развертывания своего продукта, и т. д. К тому же не так уж редко настройки межсетевого экрана не совпадают с ожидаемыми. А как вы думаете, сколько людей из–за неполадок с сетью временно отключают экран, а после устранения проблемы забывают его включить? В большой сети со многими точками входа представление о защищенной внутренней сети уже можно считать устаревшим. Такую сеть следует рассматривать как полуоткрытую, враждебную среду.
Выявление ошибки на этапе анализа кода
Если вы не задумывались о «площади атакуемой поверхности» приложения (в это понятие входят все точки входа в него), то следует заняться этим незамедлительно. В модели угроз, если таковая составлена, уже должны быть отражены точки входа. Как правило, сетевой трафик просто шифруется по протоколам SSL/TLS. Если это так, то в грехе 10 вы найдете рекомендации по устранению слабых мест.
В противном случае для каждой точки, которая может иметь выход в сеть, определите, какой механизм применяется для обеспечения конфиденциальности основного потока данных, начальной и последующей аутентификации. Иногда риск считается допустимым, хотя не предусматривается никакой защиты, особенно если частью системы является электронная почта.
Если какие–то сетевые соединения защищены, проверьте, работает ли защита, как задумано. Это может оказаться довольно сложно, поскольку требует глубоких знаний в области криптографии. Вот некоторые базовые рекомендации:
