Скенирање рањивости и сигуран развој. Део 1

Као део својих професионалних активности, програмери, пентестери и стручњаци за безбедност морају да се баве процесима као што су управљање рањивостима (ВМ), (безбедни) СДЛЦ.
Испод ових фраза налазе се различити скупови пракси и алата који се користе који се преплићу, иако се њихови корисници разликују.

Технолошки напредак још није достигао тачку да један алат може да замени човека за анализу безбедности инфраструктуре и софтвера.
Занимљиво је разумети зашто је то тако и са каквим проблемима се човек мора суочити.

Процеси

Процес управљања рањивостима је дизајниран да континуирано надгледа безбедност инфраструктуре и управљање закрпама.
Сецуре СДЛЦ процес („безбедни развојни циклус“) је дизајниран да одржи безбедност апликације током развоја и рада.

Сличан део ових процеса је и процес процене рањивости – процена рањивости, скенирање рањивости.
Главна разлика између скенирања унутар ВМ-а и СДЛЦ-а је у томе што је у првом случају циљ проналажење познатих рањивости у софтверу треће стране или у конфигурацији. На пример, застарела верзија Виндовс-а или подразумевани стринг заједнице за СНМП.
У другом случају, циљ је откривање рањивости не само у компонентама треће стране (зависности), већ првенствено у коду новог производа.

Ово доводи до разлика у алатима и приступима. По мом мишљењу, задатак проналажења нових рањивости у апликацији је много интересантнији, јер се не своди на узимање отисака прстију верзије, прикупљање банера, бруте форце лозинке итд.
Висококвалитетно аутоматизовано скенирање рањивости апликација захтева алгоритме који узимају у обзир семантику апликације, њену намену и специфичне претње.

Инфраструктурни скенер се често може заменити тајмером, као авлеонов. Поента је да чисто статистички, своју инфраструктуру можете сматрати рањивом ако је нисте ажурирали, рецимо, месец дана.

Алат

Скенирање, као и безбедносна анализа, могу се извршити као црна или бела кутија.

Црна кутија

Са скенирањем црне кутије, алатка мора бити у могућности да ради са услугом преко истих интерфејса преко којих корисници раде са њим.

Инфраструктурни скенери (Тенабле Нессус, Куалис, МакПатрол, Рапид7 Некпосе, итд.) траже отворене мрежне портове, прикупљају „банере“, идентификују инсталиране верзије софтвера и претражују своју базу знања за информације о рањивостима у овим верзијама. Такође покушавају да открију грешке у конфигурацији као што су подразумеване лозинке или јавни приступ подацима, слабе ССЛ шифре итд.

Скенери веб апликација (Ацунетик ВВС, Нетспаркер, Бурп Суите, ОВАСП ЗАП, итд.) такође могу открити познате компоненте и њихове верзије (нпр. ЦМС, оквири, ЈС библиотеке). Главни кораци пузања су пузање и фуззинг.
Током пописивања, пописивач прикупља информације о постојећим интерфејсима апликације и ХТТП параметрима. Током фузинга, сви детектовани параметри се замењују мутираним или генерисаним подацима како би се изазвала грешка и открила рањивост.

Такви скенери апликација припадају класама ДАСТ и ИАСТ – динамичко и интерактивно тестирање безбедности апликација.

Вхите бок

Код скенирања беле кутије постоји више разлика.
Као део ВМ процеса, скенерима (Вулнерс, Инсецурити Цоуцх, Вулс, Тенабле Нессус, итд.) се често даје приступ системима тако што се изврши проверено скенирање. Дакле, скенер може преузети инсталиране верзије пакета и конфигурационе параметре директно са система, а да их не погађа са банера мрежних услуга.
Скенирање је прецизније и потпуније.

Ако говоримо о скенирању белог кутија (ЦхецкМарк, ХП Фортифи, Цоверити, РИПС, ФиндСецБугс, итд.) апликација, онда обично говоримо о статичкој анализи кода и коришћењу одговарајућих алата САСТ класе – Статиц Апплицатион Сецурити Тестинг.

Проблеми

Много је проблема са скенирањем! Са већином њих морам да се бавим лично у оквиру пружања услуге за изградњу процеса скенирања и безбедног развоја, као и приликом обављања послова безбедносне анализе.

Издвојићу 3 главне групе проблема, што потврђују и разговори са инжењерима и руководиоцима служби за безбедност информација у различитим компанијама.

Проблеми са скенирањем веб апликација

1. Тешкоћа имплементације. Скенери треба да буду распоређени, конфигурисани, прилагођени за сваку апликацију, додељено тестно окружење за скенирање и имплементирани у ЦИ/ЦД процес да би били ефикасни. У супротном, то ће бити бескорисна формална процедура, издавање само лажних позитивних резултата
2. Трајање скенирања. Скенери, чак и 2019. године, лоше раде на уклањању дупликата интерфејса и могу данима да скенирају хиљаду страница са по 10 параметара, сматрајући их различитим, иако је за њих одговоран исти код. Истовремено, одлука о пуштању у производњу у оквиру развојног циклуса мора бити донета брзо.
3. Лоше препоруке. Скенери дају прилично опште препоруке и није увек могуће да програмер брзо схвати од њих како да смањи ниво ризика, и што је најважније, да ли то треба да се уради одмах или још увек није страшно
4. Деструктивни утицај на апликацију. Скенери могу лако да изврше ДоС напад на апликацију, а могу и да креирају велики број ентитета или да промене постојеће (на пример, да креирају десетине хиљада коментара на блогу), тако да не би требало непромишљено да покрећете скенирање у производу.
5. Лош квалитет откривања рањивости. Скенери обично користе фиксни низ корисних оптерећења и лако могу промашити рањивост која се не уклапа у њихово познато понашање апликације.
6. Скенер не разуме функције апликације. Сами скенери не знају шта је „Интернет банка“, „плаћање“, „коментар“. За њих постоје само везе и параметри, тако да је огроман слој могућих пропуста пословне логике остао потпуно неоткривен, неће се досјетити да изврше дупли отпис, завирују у туђе податке по ИД-у или намотају стање кроз заокруживање
7. Неразумевање семантике странице од стране скенера. Скенери не могу да читају често постављана питања, не могу да препознају цаптцхас, неће сами да погоде како да се региструју и поново се пријаве, да не можете да кликнете на „одјава“ и како да потпишете захтеве приликом промене вредности параметара. Као резултат тога, већина апликација може уопште остати нескенирана.

Проблеми скенирања изворног кода

1. Лажно позитиван. Статичка анализа је сложен задатак који укључује много компромиса. Често морате жртвовати тачност, па чак и скупи скенери предузећа дају огроман број лажних позитивних резултата.
2. Тешкоћа имплементације. Да би се повећала тачност и потпуност статичке анализе, неопходно је прецизирати правила скенирања, а писање ових правила може бити превише дуготрајно. Понекад је лакше пронаћи сва места у коду са неком врстом грешке и поправити их него написати правило за откривање таквих случајева.
3. Недостатак подршке зависности. Велики пројекти зависе од великог броја библиотека и оквира који проширују могућности програмског језика. Ако у бази знања скенера нема информација о опасним местима („сливовима“) у овим оквирима, ово ће постати слепа тачка, а скенер једноставно неће ни разумети код.
4. Трајање скенирања. Проналажење рањивости у коду је тежак задатак и у погледу алгоритама. Стога, процес може бити одложен и захтева значајне рачунарске ресурсе.
5. Ниска покривеност. Упркос потрошњи ресурса и трајању скенирања, програмери САСТ алата и даље морају да прибегавају компромисима и анализирају не сва стања у којима програм може бити.
6. Проналажење репродуктивности. Указивање на одређену линију и стек позива који води до рањивости је сјајно, али у ствари, скенер често не пружа довољно информација за проверу спољне рањивости. На крају крајева, мана може бити и у мртвом коду, који је недостижан за нападача.

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

1. Недовољан инвентар. У великим инфраструктурама, посебно географски одвојеним, често је најтеже схватити које хостове скенирати. Другим речима, задатак скенирања је уско повезан са задатком управљања имовином
2. Лоше одређивање приоритета. Мрежни скенери често дају многе резултате са недостацима који се у пракси не могу искористити, али је формално њихов ниво ризика висок. Потрошач добија извештај који је тешко протумачити и није јасно шта прво треба исправити
3. Лоше препоруке. База знања скенера често садржи само веома опште информације о рањивости и како је поправити, тако да ће администратори морати да се наоружају Гоогле-ом. Ситуација је нешто боља са скенерима беле кутије, који могу да издају одређену команду за поправку
4. Ручна израда. Инфраструктуре могу имати много чворова, што значи да постоји потенцијално много недостатака, извештаји о којима се морају рашчланити и анализирати ручно на свакој итерацији
5. Лоша покривеност. Квалитет скенирања инфраструктуре директно зависи од величине базе знања о рањивостима и верзијама софтвера. У чему, испада да, чак ни лидери на тржишту немају свеобухватну базу знања, а у базама бесплатних решења постоји много информација које лидери немају
6. Проблеми са крпљењем. Најчешће, закрпање рањивости инфраструктуре је ажурирање пакета или промена конфигурационе датотеке. Велики проблем овде је што се систем, посебно застарели, може понашати непредвидиво као резултат ажурирања. У ствари, мораћете да спроведете интеграцијске тестове на живој инфраструктури у производњи.

Прилази

Како то може да буде?
У следећим деловима ћу детаљније говорити о примерима и начину решавања многих од ових проблема, али за сада ћу навести главне области у којима можете да радите:

1. Агрегација различитих алата за скенирање. Правилном употребом вишеструких скенера може се постићи значајно повећање базе знања и квалитета детекције. Можете пронаћи још више рањивости него што је збир свих скенера покренутих појединачно, док можете прецизније проценити ниво ризика и дати више препорука
2. САСТ и ДАСТ интеграција. Могуће је повећати покривеност ДАСТ-ом и тачност САСТ-а дељењем информација између њих. Из извора можете добити информације о постојећим рутама, а уз помоћ ДАСТ-а можете проверити да ли је рањивост видљива споља
3. Мацхине Леарнинг™. 2015. године И рекао (И више) о коришћењу статистике да би скенери добили хакерску интуицију и убрзали их. Ово је свакако храна за развој аутоматизоване безбедносне анализе у будућности.
4. ИАСТ интеграција са аутотестовима и ОпенАПИ. Унутар ЦИ/ЦД-цевовода, могуће је креирати процес скенирања заснован на алатима који раде као ХТТП проксији и функционалним тестовима који раде преко ХТТП-а. ОпенАПИ/Сваггер тестови и уговори ће дати скенеру информације које недостају о токовима података, што ће омогућити скенирање апликације у различитим стањима
5. Исправна конфигурација. За сваку апликацију и инфраструктуру, потребно је да направите одговарајући профил скенирања, узимајући у обзир број и природу интерфејса, технологије које се користе
6. Прилагођавање скенера. Често се апликација не може скенирати без модификације скенера. Пример је гејтвеј за плаћање где сваки захтев мора бити потписан. Без писања конектора у протокол мрежног пролаза, скенери ће безумно кљуцати захтеве са нетачним потписом. Такође је потребно писати специјализоване скенере за одређену врсту мана, као нпр Небезбедна директна референца објекта
7. Управљање ризиком. Коришћење различитих скенера и интеграција са екстерним системима као што су Ассет Манагемент и Тхреат Манагемент омогућиће коришћење више параметара за процену нивоа ризика, тако да менаџмент може да добије адекватну слику о тренутном безбедносном стању развоја или инфраструктуре.

Останите са нама и хајде да пореметимо скенирање рањивости!

Извор: ввв.хабр.цом