С 1995 г. в продуктах Oracle было найдено 3896 уязвимостей, и их количество продолжает расти. Исследовательский центр Digital Security занимается поиском уязвимостей в продуктах компании Oracle уже почти 10 лет, найдя за это время массу всевозможных уязвимостей во всей линейке их продуктов, включая разнообразные опаснейшие архитектурные баги. Некоторые из них исправлялись вендором около 3 лет после нашего уведомления (!). Поэтому с Ораклом мы знакомы не понаслышке.
Скандал, который разразился вчера в мире немедленно после публикации и последующего удаления – по словам вице-президента и главного архитектора Oracle Эдварда Скривена (Edward Screven), запись «не отражала истинных взглядов компании на взаимоотношения с пользователями», – этой записи в блоге CSO компании Oracle Мэри Энн Дэвидсон (Mary Ann Davidson), на самом деле достаточно поучителен. В нем прекрасно проявилась вся боль вендоров, все их реальное отношение к безопасности продуктов.
Наилучшей иллюстрацией здесь мог бы быть фильм с Мэлом Гибсоном «Чего хотят женщины?» Исследователи безопасности и заказчики – внимательно прочтите, что же на самом деле думает об исследованиях главный безопасник Oracle и как на самом деле она относится к безопасности своих продуктов. При этом следует понимать, что она говорит то, что другие вендоры просто не решаются сказать. Они благодарят исследователей за найденные уязвимости, мило улыбаются заказчикам, а внутри себя тихо ненавидят и тех и других. «Не трогайте наши продукты!», «Согласно лицензии, вы не имеете право на реверс-инжиниринг!» – это дословно ее высказывания. «Отстаньте уже от нас со своей безопасностью, мы сами разберемся», – вот что на самом деле думают вендоры. И как они сами «разбираются», по три года закрывая опаснейшие архитектурные уязвимости (в частности, с аутентификацией на клиенте!), мы отлично знаем. Что интересно, особенно этим славится именно компания Oracle. И теперь неудивительно почему – при таком-то отношении ее главного безопасника. Однако все-таки дело не в Oracle – и это самое важное. Их CSO просто выразила мнение всех вендоров, сказала то, что не принято говорить открыто. Это наглядная демонстрация реального отношения всех вендоров к безопасности. Кто бы и что из них не говорил, – думают они именно это.
И это страшно.
Поражает и то, что CSO Oracle не знает, что большинство уязвимостей находятся вовсе не реверсингом. Oracle может смело менять слоган со старого – «Несокрушимый» – на современный: «Неприкасаемый».
Перевод заметки Мэри Энн Дэвидсон «Нет, вообще-то нельзя»
В последнее время я много пишу. Кое-что – совместно с сестрой, детективные истории под псевдонимом Мэдди Дэвидсон. Мы сейчас работаем над рассказами и генерируем много новых интересных идей насчет управления людьми (в буквальном смысле, хотя иногда, когда кто-то пытается въехать моей машине в зад, я задумываюсь об их прикладном применении).
Писать детективы гораздо веселее, чем мое второе занятие. Я наблюдаю ощутимый прирост количества пользователей, реверсящих наш код в попытках найти в нем уязвимости. <глубоко вздыхает> Из-за этого мне приходится писать множество сообщений, которые начинаются с «Привет, как дела, рада слышать», а вот заканчиваются так: «Пожалуйста, не нарушайте лицензионное соглашение и прекратите уже обратную разработку нашего кода».
Я могу понять, что в мире, где безымянные злоумышленники, возможно, работающие на враждебное государство, почти каждый день кого-нибудь взламывают и уводят кавырнадцать хреналионов данных, хочется приложить максимум усилий к защите своих систем. В то же время, казалось бы, перед этим дополнительным рывком стоит определить наиболее критичные системы, зашифровать конфиденциальные данные, установить все необходимые патчи, использовать поддерживаемую версию продукта, применить инструменты защиты конфигураций – короче, обеспечить безопасность на гигиеническом уровне, – а потом уже искать в продукте уязвимости нулевого дня. Собственно говоря, многие утечки данных можно было бы предотвратить этими вот унылыми мерами, вместо того чтобы с придыханием вещать о большой и страшной APT-атаке, которая на вас якобы нацелена. Собственная у вас IT-инфраструктура или облачная, общепринятые рекомендации по ее защите есть, и им стоит следовать.
Пусть вы хотите разумной уверенности в том, что поставщик подходит к разработке с разумной осторожностью (а обеспечение надежности далеко не ограничивается запуском сканера), – вы как пользователь можете сделать многое. Например, прикиньте, взять и поговорить с поставщиком о его программе надежности, попросить у него сертификаты на продукты, отмеченные знаком “Good Housekeeping”, в смысле «Хороший код»: сертификат Common Criteria, FIPS-140 и т. д. Большинство разработчиков – по крайней мере, большинство крупных вендоров, которых я знаю, – уже обзавелись весьма сильными программами надежности (а знаю я это потому, что мы сравниваем друг с другом свои записи на конференциях). Это все замечательно, это нормальная проверка добросовестности поставщика, которая рядом не стоит с идеей: «а пойду-ка я сделаю за разработчика его работу и сам(а) поищу в его исходном коде проблемы», несмотря на то что:
- Пользователь не сможет найти в коде проверку, предотвращающую атаку, о которой вопит его сканер (а вопль его, скорее всего, ложноположительный);
- Пользователь не сможет написать патч для уязвимости – только поставщик;
- Пользователь почти наверняка нарушает лицензионное соглашение, запуская инструмент статического анализа (который работает с исходным кодом).
Сразу скажу, что, по-моему, иногда пользователь, реверсящий продукт, сам об этом не знает, потому что всю работу делает консультант: запускает инструмент обратной разработки кода, получает здоровенную распечатку результатов, огорошивает ею клиента, а тот отправляет данные нам. Отмечу, что мы не принимаем просто отчеты о сканировании за «доказательство, что где-то там что-то есть», в том числе потому, что как в статическом, так и в динамическом анализе отчет о сканировании не доказывает существования реальной уязвимости. Часто такой отчет – просто кучка дымящегося… FUD (именно к этой мысли я подвожу читателя: FUD, «страх, неуверенность и сомнение»). Поэтому мы и требуем от пользователей заводить запрос в техподдержку по поводу каждой предполагаемой проблемы (а не просто присылать нам отчет) и предоставлять PoC, подтверждающий возможность атаки (некоторые инструменты умеют их генерировать).
Если в ходе анализа мы определяем, что такие результаты сканирования могли получиться только благодаря реверсингу (как минимум в одном случае в отчете было прямо указано: «статический анализ Oracle XXXXXX», очень удобно), мы отправляем одно письмо согрешившему клиенту, а другое – консультанту, согрешившему от лица клиента, где напоминаем им, что условия лицензионного соглашения с Oracle запрещают обратную разработку, поэтому ПРЕКРАТИТЕ УЖЕ, ПОЖАЛУЙСТА (на канцелярите, конечно; лицензионное соглашение Oracle содержит такой пункт: «Пользователь не имеет права производить обратную разработку, дизассемблировать, декомпилировать и иными способами пытаться получить исходный код Программ…», который мы и цитируем в послании пользователю). Да, и еще мы требуем от пользователей и консультантов уничтожить результаты обратной разработки и предоставить подтверждение.
Почему я об этом заговорила? В первую очередь потому, что, когда я вижу всплеск какой-то активности, я стремлюсь ее опередить. Я не хочу больше пререкаться с людьми: «Вы нарушили лицензионное соглашение», – «Нет, не нарушали», – «Нарушали», – «Нет». Я лучше потрачу свое время и время своей команды, помогая разработчикам улучшить наш код, чем споря с людьми о содержании лицензионного соглашения.
Повторюсь: все это меня не устраивает не только по юридическим причинам. Скорее я хочу сказать: «Мне не нужно, чтобы вы анализировали наш код, потому что мы делаем это сами, это наша работа, мы умеем ее выполнять, мы можем – в отличие от посторонних исследователей или инструментов – провести настоящий анализ и обнаружить, что именно происходит, к тому же у большинства этих инструментов едва ли не 100 % результатов ложноположительные, поэтому, пожалуйста, не тратьте время на поиск зеленых человечков в нашем коде». Я не отказываюсь от своих обязанностей перед пользователями, а просто пытаюсь избежать мучительной и раздражающей взаимной траты времени.
ссылка на оригинал статьи http://habrahabr.ru/post/264581/
Добавить комментарий