Читать онлайн «Защита от хакеров корпоративных сетей». Страница 186

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

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

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

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

Публикация кода, использующего уязвимость

Предположим, вы обнаружили уязвимость. Нужно ли обнародовать вместе с описанием проблемы код, использующий уязвимость? На этот сложный вопрос вам придется отвечать самостоятельно.

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

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

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

С подобным вопросом сталкиваются и многие производители программ для обнаружения уязвимости (security scanners). Они хотят продавать продукт, позволяющий пользователям тестировать систему на наличие уязвимостей, не давая им при этом в руки легкого в применении инструмента взлома. Впрочем, эти производители могут позволить себе роскошь создавать очень «шумные» сканеры, работу которых обнаружит любой, наблюдающий за сетью. В другом положении находятся те, кто публикует сообщение об обнаруженной уязвимости, обычно содержащее исходный код, поскольку опытный хакер может просто убрать из него любой «шум».

Проблемы

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

Реакция производителя

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

Некоторые производители могут обвинить вас в нарушении лицензии на ограниченное использование, запрещающей восстановление исходного кода их программ или служб. Другие могут заявить, что вы разгласили коммерческую тайну. Достаточно осторожным нужно быть с технологиями, охраняющимися авторским правом, которые в США особо защищены от восстановления исходного кода законом Digital Millennium Copyright Act (DMCA) (его текст находится по адресу www.loc.gov/copyright/legislation/hr2281.pdf), а также международными договорами. Закон DMCA запрещает публикацию сообщений о проблемах безопасности, потому что это предполагает восстановление исходного кода определенного уровня, нарушение авторских прав и (или) обход шифрования.

Например, фирма Motion Picture Association of America (MPAA) подала в суд на ряд пользователей, исследовавших алгоритмы шифрования универсальных цифровых дисков (Digital Versatile Disk, DVD) и обнаруживших, что они очень слабы и ненадежны. Истца не смутило даже то обстоятельство, что ответчиками были иностранные граждане, на которых не распространяются американские законы.