Охота на ведьм в исходных кодах: НДВ, закладки и черная магия

Краткое содержание

Много букв и пару картинок про "закладки", "НДВ", бэкдор, анализ исходных кодов и APT, хотя он здесь оказался не при чем (внимание! в тексте много скобок и немного теории заговора).


Присказка

Интерес к анализу качества программного обеспечения с точки зрения безопасности продолжает расти у всех участников рынка. Крупные компании вовсю используют привычные и относительно новые методы анализа защищенности, включая распространённый во всем мире вариант crowd-sourcing – Bug Bounty program. К активно спонсирующему российских вайтхэт Yandex недавно присоединился QIWI с достаточно приятными расценками, достигающими 150 000 рублей за уязвимость.
Традиционный драйвер ИБ в виде регуляторов тоже не обходит эту область стороной. Кроме привычных требований раздела 6 PCI DSS и стандарта PA DSS существует 7.3.5 СТО БР ИББС 1.0, косвенно затрагивающего безопасность приложений АБС.
В недавно утвержденном приказом ФСТЭК России №17 документе «Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» содержится тезис о необходимости проводить «анализ уязвимостей информационной системы», что может трактоваться достаточно широко, включая поиск уязвимостей реализации в программном обеспечении разработанном специально для ГАС. А уж если вспомнить о приказе N21, где явно обозначена "...проверка системного и (или) прикладного программного обеспечения, включая программный код, на отсутствие недекларированных возможностей"...

Естественно рынок не мог не отреагировать на этот интерес. Сразу на двух крупных отраслевых мероприятиях, конференции Рускрипто и форуме Positive Hack Days прошли секции и мастер-классы по теме анализа кода, SDLC, Application Security (для практиков особенно рекомендую hands-on lab Владимира Кочеткова, и его интервью).
Кроме привычных уже услуг по анализу защищенности и инструментов для тестирования приложений в режиме «черного ящика» (или Dynamic Application Security Testing) таких как MaxPatrol, Acunetix, HP WebInspect на рынке начали появляться средства анализа исходного кода, такие как Appercut Custom Code Scanner, Positive Technologies Application Inspector, IBM AppScan, HP Fortify. Понятно, что продукты HP и IBM существуют не один год, но в России они активно не продвигались .

Завязка

Среди функций этих инструментов, кроме ожидаемого поиска уязвимостей по классификациям OWASP/WASC/CWE, многие из разработчиков обозначают «поиск закладок» или «обнаружение недекларированных возможностей». Давайте попробуем разобраться с этим немного подробнее.

Сказка

Прежде всего давайте определимся, что такое НДВ. Согласно букве закона (см. Руководящий документ. Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей. Утверждено решением председателя Государственной технической комиссии при Президенте Российской Федерации от 4 июня 1999 г. № 114), цитирую:

2.1. Недекларированные возможности - функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.

Т.е. определение достаточно широко и вполне может включать стандартные, но нигде не зафиксированные пароли, ошибки, приводящие к обходу аутентификации и авторизации, любые уязвимости типа Remote Code Execution и SQL Injection. Все эти ошибки попадают под определение, поскольку они не описаны в документации (за редким исключением a-la Intel Errata Sheets) и их использование вполне может привести к нарушению одного из аспектов CIA.
Т.е. фактически обнаружение в приложении уязвимости с CVSS > 6.6 не только требует действий по мнению «продвинутых» стандартов, таких как PCI DSS, но и вызывает вопросы с точки зрения РД ФАПСИ/ФСТЭК 1999 года выпуска.

Однако, на понятийном уровне,  больше интересуют не «простые ошибки» разработчиков, а «закладки», т.е. «ошибки» преднамеренные. 

Вот так выглядит "НДВ" с точки зрения PT Application Inspector 

"Обычная уязвимость" - чтение произвольных файлов, но с дополнительным условием

 А вот так становится понятно, что это - самая настоящая "закладка"

Здесь тоже все не очень просто. Ведь если потенциальный злоумышленник рассматривает возможность анализа его кода на предмет «закладок» (что весьма вероятно в случае инцидента) логично не только максимально запутать код  (чтобы усложнить анализ) но и создать себе алиби. Простейший вариант алиби – маскировка «закладки» под «просто ошибку». Ведь если, например в SCADA-системе работающей в критичной АСУ ТП обнаружится «зашитый» пароль, то это сразу вызовет массу идей и подозрений. С другой стороны, SQL Injection в той же системе будет рассматриваться как «просто ошибка», и форсирует скорее установку обновлений, чем какие-либо теории заговора.

CVE-2013-3957 vs CVE-2013-3958 – что из них «закладка»? А что НДВ?

Хотя и то, и другое может быть ошибкой разработчика (или проектировщика ПО, как в приведенном примере с Siemens SIMATIC WinCC). Или не ошибкой. Пойди разберись… С точки зрения практического использования SQL Injection приводящая к обходу авторизации и выполнению произвольного кода на сервере SCADA может быть гораздо полезней для потенциального злоумышленника, чем инженерная учетная запись на Web-сервере. 

Не все так просто...

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

APT или не APT?

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

Здесь налицо «НДВ» (вряд ли в документации присутствовала информация о том, что частная информация абонентов будет сохранена где-то за Великим Китайским Фаерволом) и «закладка» (программист намеренно внес адреса серверов в код).  Но, обнаружить ее автоматическими средствами, что статическими, что динамическими достаточно проблематично. Если, конечно, не сконфигурировать средство анализа таким образом, чтобы оно выявляло все активности по передаче информации вовне и фильтровало их по белому (ну или черному, не суть) списку. Однако, такая проверка должна исходить из функций приложения, которые понятны человеку (после прочтения документации, например, если она есть), но достаточно трудно формализуемы для автоматизированного поиска. 

Резюме

Таким образом, цитируя отличный доклад Андрея Петухова: «Все плохо!».

В сухом остатке:

1. Вероятность найти «закладку» или "НДВ" класса if Now == 0day Steal(Money); гораздо ниже, чем аналогичную по возможностям, но замаскированную под «ошибку разработчика» или «просто уязвимость». 
2. Автоматизация поиска «application specific flaws», т.е. «настоящих закладок» с учетом «специфики архитектуры приложения и бизнес-процессов» без серьезного участия экспертов по специфике данного конкретного приложения – деньги на ветер. Т.е. техническая составляющая самого метода анализа тривиальна (grep или более продвинутые техники pattern matching), но база знаний сигнатур разрабатывается для данного конкретного приложения и очень плохо переносится на другие.  Т.е. для системы, которая эксплуатируется многие годы и прошла не одну итерацию анализа защищенности более-менее полную базу сигнатур создать можно, но для соседнего приложения, даже использующего ту же ERP, все это может оказаться бесполезно. 

Или, если переформулировать в виде требований с системе автоматизированного поиска уязвимостей:

1. Система анализа на НДВ должна иметь функции поиска «традиционных» уязвимостей, относящихся к фильтрации ввода/вывода, реализации функций безопасности и т.д. и т.п.
2. Для выявления application specific flaws или «логических закладок» в системе необходим механизм добавления собственных сигнатур, относящихся к конкретному приложению.
3. Для реализации 2 необходимы эксперты, понимающие логику приложения и умеющие объяснить ее системе анализа на НДВ в привычных для нее терминах. «Из коробки» не взлетит.