Сканиране за уязвимости и безопасна разработка. Част 1

В рамките на професионалната дейност разработчиците, пентестерите и специалистите по сигурност се сблъскват с процеси като Управление на уязвимости (VM) и (Сигурна) SDLC.
Под тези фрази се крият различни набори от практики и използвани инструменти, които са взаимосвързани, макар и потребителите им да варират.

Техническият прогрес все още не е достигнал до момента, в който един инструмент може да замени човека за анализа на сигурността на инфраструктурата и софтуера.
Интересно е да разберем защо е така и с какви проблеми се сблъскват.

Процеси

Процесът на Управление на уязвимости е предназначен за непрекъснато наблюдение на сигурността на инфраструктурата и управление на пачовете.
Процесът на Сигурна SDLC е предназначен за поддръжка на сигурността на приложението по време на разработка и експлоатация.

Сходен процес е Оценка на уязвимостите — сканиране за уязвимости.
Основната разлика между сканирането в рамките на VM и SDLC е, че в първия случай целта е да се открият известни уязвимости в трета страна или в конфигурацията. Например, остаряла версия на Windows или стандартен community стринг за SNMP.
Вторият случай цели откриване на уязвимости не само в компоненти на трети страни (зависимости), но и предимно в кода на новия продукт.

Това поражда разлики в инструментите и подходите. Лично смятам, че задачата за откриване на нови уязвимости в приложението е значително по-интересна, тъй като не се свежда до идентификация на версии, събиране на банери, подбиране на пароли и т.н.
За качествено автоматизирано сканиране на уязвимости в приложения са необходими алгоритми, които отчитат семантиката на приложението, неговото предназначение и специфичните заплахи.

Инфраструктурният скенер често може да бъде заменен с таймер, както се изрази avleonov. Същността е, че статистически можете да считате вашата инфраструктура за уязвима, ако не сте я обновявали, да речем, месец.

Инструменти

Сканирането, както и анализът на сигурността, може да се извършват както с черна кутия, така и с бяла кутия.

Black Box

При сканирането с черна кутия инструментът трябва да може да работи със службата чрез същите интерфейси, през които работят потребителите.

Скенерите на инфраструктурата (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose и др.) търсят отворени мрежови портове, събират "банери", определят версиите на инсталирания софтуер и проверяват в своята база данни информация за уязвимости в тези версии. Те също така се опитват да открият конфигурационни грешки, като пароли по подразбиране или открит достъп до данни, слаби SSL шифровки и др.

Скенерите на уеб приложения (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP и др.) също могат да определят известни компоненти и техните версии (например, CMS, фреймворци, JS библиотеки). Основните стъпки на скенера са краулинг и фаззинг.
По време на краулинга, скенерът събира информация за съществуващите интерфейси на приложението, HTTP параметрите. При фаззинга в всички открити параметри се вмъкват мутирали или генерирани данни с цел да се предизвика грешка и да се открие уязвимост.

Тези скенери на приложения принадлежат към класовете DAST и IAST — съответно Dynamic и Interactive Application Security Testing.

White Box

При whitebox сканирането разликите са повече.
В рамките на процеса VM на скенерите (Vulners, Incsecurity Couch, Vuls, Tenable Nessus и др.) често се предоставя достъп до системите, провеждайки аутентифицирано сканиране. По този начин скенерът може да извлече инсталираните версии на пакети и конфигурационни параметри директно от системата, без да ги гадае по банерите на мрежовите услуги.
Скенът става по-точен и по-пълен.

Ако говорим за whitebox сканиране (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs и др.) на приложения, става въпрос обикновено за статичен анализ на кода и използването на съответните инструменти от клас SAST — Static Application Security Testing.

Проблеми

Съществуват много проблеми със сканирането! С повечето от тях ми се налага да се сблъсквам лично в рамките на предоставянето на услуги за изграждане на процеси на сканиране и безопасна разработка, както и при провеждане на анализи на сигурността.

Ще изтъкна 3 основни групи проблеми, които потвърдиха разговорите ми с инженери и ръководители на ИБ служби в най-разнообразни компании.

Проблеми със сканирането на уеб приложения

1. Сложност при внедряването. Сканирането трябва да се настройва, конфигурира и персонализира за всяко приложение, да се отделя тестова среда за сканирания и да се интегрира в процеса на CI/CD, за да бъде ефективно. В противен случай това ще бъде безполезна формална процедура, предоставяща само фалшиви сработвания.
2. Продължителност на сканирането. Сканерите дори през 2019 г. не се справят добре с дедупликацията на интерфейсите и могат да сканират хиляди страници с 10 параметъра на всяка, смятайки ги за различни, макар че отговорен за тях е един и същ код. В същото време решението за разгръщане в производство в рамките на цикъла на разработка трябва да се взема бързо.
3. Оскъдни препоръки. Сканерите дават достатъчно общи препоръки и не винаги разработчикът може бързо да разбере как да намали нивото на риска, а най-важното, дали трябва да го направи в момента, или да изчака.
4. Деструктивно въздействие върху приложението. Сканерите напълно могат да извършат атака DoS на приложението, а също така могат да генерират голямо количество същности или да променят съществуващи (например, да създадат десетки хиляди коментари в блог), така че не е разумно да се стартира сканиране в производство без размисъл.
5. Ниско качество на откритие на уязвимости. Сканерите обикновено използват фиксиран набор от полезни натоварвания («payloads») и лесно могат да пропуснат уязвимост, която не попада в известния им сценарий на поведение на приложението.
6. Неправилно разбиране от сканиратора на функциите на приложението. Сканерите сами по себе си не знаят какво е «интернет-банк», «плащане», «коментар». За тях съществуват само връзки и параметри, така че огромен обем от възможни уязвимости на бизнес логиката остава напълно непокрит, те няма да се сетят да направят двойно начисляване, да надзърнат в чужди данни по ID или да манипулират баланса чрез закръгляне.
7. Неправилно разбиране от сканиратора на семантиката на страниците. Сканерите не умеят да четат FAQ, не разпознават каптчи, сами по себе си не ще се сетят как да се регистрират и че след това трябва да се пренавлят, че не трябва да натискат «logout», и как трябва да подписват заявки при промяна на стойностите на параметрите. В резултат на това голяма част от приложението може да остане изцяло несканирана.

Проблеми при сканирането на изходния код.

1. Фалшиви сработвания. Статичният анализ е сложна задача, при решаването на която често се налага да се правят компромиси. Често се жертва точността, а дори и скъпите enterprise скенери дават огромно количество фалшиви сработвания.
2. Сложност при внедряването. За да се увеличи точността и пълнотата на статичния анализ, е необходимо да се доразвият правилата за сканиране, а написването на тези правила може да се окаже прекалено трудоемко. Понякога е по-лесно просто да се намерят всички места в кода с определен бъг и да се поправят, отколкото да се пише правило за откритие на такива случаи.
3. Липса на поддръжка на зависимостите. Големите проекти зависят от множество библиотеки и фреймворкове, които разширяват възможностите на програмния език. Ако в базата данни на скенера няма информация за опасните места („sinks“) в тези фреймворкове, това ще стане сляпо петно, и скенерът просто няма да разбере кода.
4. Продължителност на сканирането. Търсенето на уязвимости в кода е сложна задача и по отношение на алгоритмите. Следователно, процесът може да отнеме значително време и да изисква съществени изчислителни ресурси.
5. Ниско покритие. Независимо от потреблението на ресурси и продължителността на сканирането, разработчиците на SAST инструменти все пак трябва да правят компромиси и да не анализират всички състояния, в които може да се намира програмата.
6. Възпроизводимост на находките. Указанието за конкретен ред и стека на повиквания, който води до уязвимост, е прекрасно, но всъщност често скенерът не предоставя достатъчно информация, за да се провери наличието на уязвимост извън. Все пак, проблемът може да е и в ненужния код, който е недостижим за атакуващия.

Проблеми със сканирането на инфраструктурата.

1. Недостатъчна инвентаризация. В големите инфраструктури, особено географски разделени, често е най-трудно да се разбере кои хостове трябва да се сканират. С други думи, задачата по сканиране е тясно свързана с управлението на активите.
2. Лоша приоритизация. Мрежовите скенери често дават много резултати с недостатъци, които на практика не могат да се експлоатират, но формално техният рисков ниво е високо. Потребителят получава доклад, който е труден за интерпретиране, и не е ясно какво трябва да се поправи първо.
3. Оскъдни препоръки. В базата на знанията на скенера често има само много обща информация за уязвимостите и начините за тяхното отстраняване, така че администраторите ще трябва да се въоръжат с Google. Ситуацията е малко по-добра с whitebox скенерите, които могат да предоставят конкретна команда за поправка.
4. Ръчна работа. В инфраструктурите може да има много възли, а следователно потенциално и много недостатъци, за които докладите трябва да се анализират и разберат ръчно при всяка итерация.
5. Лошо покритие. Качеството на сканирането на инфраструктурата пряко зависи от обема на базата знания за уязвимости и версии на софтуер. В същото време, се оказват, дори сред лидерите на пазара, базата знания не е всеобхватна, а в базите на безплатни решения има много информация, която липсва на лидерите.
6. Проблеми с патчването. Най-често патчването на уязвимостите в инфраструктурата представлява актуализиране на пакет или промяна на конфигурационен файл. По-голям проблем тук е, че системата, особено старата, може да се държи непредсказуемо след актуализацията. Всъщност ще е необходимо да се проведат интеграционни тестове в активна инфраструктура.

Подходи

Какво да правим?
Повече за примери и за това как да се справим с много от изброените проблеми ще разкажа в следващите части, а сега ще посоча основните направления, по които може да се работи:

1. Агрегиране на различни инструменти за сканиране. При правилна употреба на няколко скенера може да се постигне значително увеличаване на базата знания и качеството на откритията. Може да се намерят дори повече уязвимости, отколкото сумарно всички скенери, стартирани поотделно, като същевременно може да се оценява по-точно нивото на риск и да се дават повече препоръки.
2. Интеграция на SAST и DAST. Може да се увеличи покритието на DAST и точността на SAST чрез обмен на информация между тях. От изходните кодове може да се получи информация за съществуващите маршрути, а чрез DAST може да се провери дали уязвимостта е видима от външната страна.
3. Machine Learning™. През 2015 година аз разказвах (и още) за прилагането на статистиката с цел предоставяне на скенерите интуицията на хакера и ускоряване на процеса. Това определено е храна за развитие на автоматичния анализ на сигурността в бъдеще.
4. Интеграция на IAST с автоматизирани тестове и OpenAPI. В рамките на CI/CD-pipeline е възможно създаването на процес на сканиране, базиран на инструменти, работещи като HTTP-прокси, и функционални тестове, работещи по HTTP. Тестовете и договорите OpenAPI/Swagger ще предоставят на скенера липсващата информация за потоците от данни, което ще позволи да се сканира приложението в различни състояния.
5. Правилна конфигурация. За всяко приложение и инфраструктура е нужно да се създаде съответният профил за сканиране, който да отчита количеството и характера на интерфейсите и използваните технологии.
6. Персонализация на скенерите. Често приложението не може да бъде сканирано без доработка на скенера. Пример — платежен шлюз, при който всяко искане трябва да бъде подписано. Без разработването на конектор за протокола на шлюза, скенерите ще генерират искания с неправилна подписка. Също така е необходимо да се разработват специализирани скенери за конкретни видове недостатъци, като Ненадеждно пряко препратка на обект
7. Управление на риска. Използването на различни скенери и интеграцията с външни системи, като управление на активи и управление на заплахи, ще позволи да се използват множество параметри за оценка на нивото на риска, така че ръководството да може да получи адекватна представа за текущото състояние на сигурността на разработката или инфраструктурата.

Следвайте ни и нека нарушим сканирането на уязвимости!

Източник: habr.com