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

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

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

процеси

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

Подобна част от тези процеси е процесът Vulnerability Assessment – ​​оценка на уязвимостта, сканиране на уязвимостта.
Основната разлика между сканирането в рамките на VM и SDLC е, че в първия случай целта е да се намерят известни уязвимости в софтуера на трети страни или в конфигурация. Например остаряла версия на Windows или стандартен низ на общността за SNMP.
Във втория случай целта е да се открият уязвимости не само в компоненти на трети страни (зависимости), но преди всичко в кода на новия продукт.

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

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

Инструменти

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

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.

Бялата кутия

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

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

Проблеми

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

Ще отделя 3 основни групи проблеми, които се потвърждават и от разговори с инженери и ръководители на службите по информационна сигурност в различни компании.

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

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

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

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

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

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

Подходи

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

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

Останете на линия и нека прекъснем сканирането за уязвимости!

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