Неприкасаемый Oracle
С 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% результатов ложноположительные, поэтому, пожалуйста, не тратьте время на поиск зеленых человечков в нашем коде». Я не отказываюсь от своих обязанностей перед пользователями, а просто пытаюсь избежать мучительной и раздражающей взаимной траты времени.
