OWASP Sofia May 2025 Meetup @ Progress

3:20↗Yeah. Така невероятно. А, ще говорим за DNET. Аз съм Иван. А, така. Колко от вас някога са писали на DNET или продължават да пишат? О, да, да. Ще има, ще има за какво да си говорим. Значи, ами да, ще се учим да си първаляме днеска, защото това е много полезно. Много неща се учат, докато човек си преваля. А кой съм аз? Аз съм девелопър в Progress Softare в Занимавам се с DNET. В момента съм в Reporting Docs and Tools звеното, но понеже съм от доста години в прогрес, съм бил в най-различни екипи, свързани с портфолиото на Телевик и в момента съчетаваме и втора роля и съм secкюрити champion на няколко от продуктите. Та слагам си едната шапка, пиша код, после си го хаквам и така по цял ден. А и да, ето сега въпросът. Ама как да фейлнем с DNET reflection? Ами много е лесно да фейлнеш с DNET reflection. Пишеш си една къстъм севилизация и си готов общо взето. И сега защо D е в

4:44↗скопки? Защото сериолизацията на никой нищо лошо не е направила. Обаче като почнем да десериализираме, както знаете, ей там става голямата красота. Та да, а както има много проблеми в програмирането, когато ако сам решиш да си направиш някакво твое решение, обикновено грешиш, нали, ако вземем примерно да си напишем наша хш функция. А къстъмс реализацията не е чак в такъв скоуп, но се доближава, да кажем, така че трябва много да внимаваме. Та да, най-лесният начин е да си напишеш лоша къстъм сриализация. И това беше презентацията. Благодаря ви. Да лови. Продължаваме. А има някои митове, свързани със сериализацията, с рефлекшън, как как различните видове сериализация и десериализация могат да бъдат атакувани и ще се опитаме да ги развенчаем. Сега, първо reflectionшъ. Какво е reflectionш? Ако отворите някой учебник за DNET, има много голям шанс там да пише не

5:52↗ползвайте рефлекшън, защото е бавен, което едно време беше много вярно, ама хората от Microsoft го правят все по-малко вярно това и го доближават до Direct invлка по Performance. Да, все още може да кажем, че е бавен. Какво друго е рефлекшъ? Ами то е такъв слопи. Що е слопие? Еми, чупиш тамкапсулации, имаш някакви рестрикшъни за access, ти ги чупиш тях. А има много забавни такива цели системи, дето всеки вика коцфлекш в тях. Страхотна красота е. Maintainability-то е на ниво, нали. И това са най-лошите примери. Обаче има едно нещо, дето го пропускате, че понякога reflectionш всъщност е и remote cд execution, което нали вече почва да звучи доста зле. И сега тука J девелопърите ще кажат ха-хахаet е много зле, нали? Но всъщност цялата концепция за рефлекшъна, тя се среща в много различни платформи и каквото си говорим днес, може да не е директно transferable навсякъде, но специално за

7:08↗Java е доста и вярвам, че това е валидно, нали, и за много други такива технологии. И защо е толкова защо е толкова вярно цялото това нещо? Ами рефлекшъна е много труден да го опазиш. Аnet с годините той стана така от раннияфреймърк, където всяко нещо беше направено да е удобно до новите версии на DNET, където всичко е направено да е сигурно по дефолт. Имаше постоянно инкриментални подобрения, но рефлекшън продължава да е също толкова опасен, както тогава. Сега има уговорката, нали, че може да си направите а специален app домейн смишъни, които забраняват да викатешъ, ама истината е, че повечето апликейшъни се рънват full, нали, каквото стане. И там е в ръцете на девелопърите целия тоя контрол. Та да, използвайте доnet. Развенчахме първия мит. Втория мит. Абе не може да е толкова зле. Абе да. Сега това сигурно ви е до болка познато. CVSS калкулатор, който

8:23↗показва някаква си там атака, дето е свързана с remote cod execution специално заради фелнала десериализация. И сега тука кое е толкова интересно? Интересното първо е, че ей такива големи числа не искате да пише никъде около вашия сайт, нали? Това е ужасно голямо число и влизате във всички новини, когато имате толкова. Но защо се случва това? Еми, за заради заградените ректангли те така много помагат това число да стане толкова високо. И атак комплексито обикновено на девилиization атаките е много ниско, понеже като измислиш един payload, даже може да не си го измислил ти. Даже може твоето приятелче хакер да ти го е дал и ти минаваш и хакваш всичко наред с него. Та абсолютно е repйable са. Обикновено има нали както всяко нещо изключения. И другото е импакт метриките обикновено са на макс. Ако успееш да вържеш такъв добър гаджетйн, който не просто там да

9:32↗крашне нещо на сървъра, ами директно да екзекютне код, еми ти може да направиш всичко, което позволяват мишъните на апликейшъна, който ръндва. Като ако не дай си боже ей тоя последния, най-горния слайд за спа отиде на change scope, тогава нали отиваме много близо до perfectтен. Та много трябва да внимаваме с reflection, защото като чуете reflection си мислете за remote cod execution и добре, хубаво, лошо е, ама пък ние сме сейф, нали, няма, няма страшно, няма как да ни се случи и как може да се предпазим и в същото време все едно не сме се предпазили. Можем да прочетем първата статия в MSDN, която излезе за рискове, свързани с десериализация. И тя е много полезна тая статия, защото ни казваей тука има едни два много опасни селайзъра, ако ги използвате имате проблем. И така хората се басват, че ако не ги използват, нали, нямат проблеми, всичко е топ. казват си аз имам страхотна къстъм

10:42↗имплементация, имам статичен secюрити анализ на кода ми, той е зелен и освен това там ни казаха, че имало някакъв проблем и ние си направихме един лист и тоя проблем го го финтираме и няма просто какво да се случи. Ние сме сейф. Еми да. Сега почваме тука. А ще има лайв излагация с лай кодинг сесия и почваме с нещо много много ниска топка, нали? Буквално най-тъпия пример, който можах да се сетя с с десевирализация и с защита от нея, нали. Това е такъв абсурден пример. Идват някакви данни отвън, ние ги десериализираме и после кастваме да видим дали типът е тоя, който ни харесва, нали? А парти, това е много лоша идея, понеже голямата беля става още на първия ред и всичко друго е полезно, само ако ви плащат на ред код, който сте написали. И така, та сега ще показваме калкулатори. Защото както знаете калкулаторът е най-лошото нещо, което може да се случи на един no

12:00↗secure envirймент. Някой да покаже калкулатор там. И ако не сте виждали такъв гаден код писан в обедната почивка, ей тука има малко и такива. А да, това е между другото AI е реванмпа на тая презентация, защото се чудих трябва да има нещо свързано с AI. Тоя е гигахай и се опитах да измисля някакви примери с AI, които да релейтват добре за зафлекшън. Ама накрая се оказахме с тоя калкулатор. Беше анимиран, но Microsoft не поддържат HTML анимации в PowerPoint за жалост. И добре, почват демата. Така. Сега, а мисля да първо да ви разкажа какви ще са демата и после да направя демата едно по едно, защото иначе трябва да суичвам между презентацията постоянно и така да загубим фокуса. Първото ми демо ще е свързано с така наречените type конвертери. Type конвертери а са едно нещо в dnet, което ти казва, че е прекрасно, че някакви типове могат да се трансформират в други типове и за

13:17↗жалост типовете, инпут типовете обикновено са стринг, аputт типовете могат да бъдат всичко и понякога това всичко е нещо много лошо. Та това ще е първото ни демо и сега като се замисля, ще се опитам да го направя в момента.

13:37↗Така. П. Не,

13:46↗така. Така. Ето го демото за теб конвертер. Виж, което се надяваме да работи. Сега, а тук нивото е твърде близко до това, което видяхме в оня аа в оня екзампъл с картинката с кода. Та казваме си да, то това няма как да се случи, но всъщност ако поразгледате някакви по-стари код бейсове, доста често става. И тук примерът а е с някакъв хипотетичен компонент, който някой е решил, че може да се екстендва. А понеже в DNET и особено в DNET framework е една такава странна концепция, а има едно нещо наречено гак. Оттам се завеждат асмблита, има един алгоритъм с проби пад. Те се завеждат, ако ги няма в грави места. И за да ги тривиализираме толкова много от тея примери, общо взето всичко е или в един проект, или в някакъв проект, който го реферира. Та тук това, което имаме, е някакъв контрол. Това е, да кажем, WPF. И тук някой е казал: "Ха, аз ще си направя една тема. Тая тема ще има type

15:02↗конвертер и в зависимост от какво аа си напише човекът там в замъз му сложа някаква много красива тема и всичко ще е много красиво. И ето пак една абсурдна защита. Проверяваме дали типът, който сме resolвнали е имплементирам, което нали е елементарно да го byпаснеш, правиш малишаe, който имплементира тим. И това е а методът в dnet, в който аа след като си е резовнал някакъв тип, с него крийтваш инстанция или с дефолтния конструктор, или с някакъв конструктор, който който си си харесал. И сега как потенциално може да стане тая атака? А, изтегляш се някакви много яки теми от интернет и там има evл Team или B team и ти казваш о сигурно тая Evil Team е някаква много красива. Сигурно ще ми направя аплиш на Evil, но всъщност в конструктора на тая тема просто няма да познаете какво става. Сега стартирам и става първият калкулатор. Та да, очакваме на пет калкулатора да видим. Той е първия.

16:17↗Какъв е тука трики моментът, нали, че някой си казваз тука ще си направя да си зареждам моите теми по някакъв много лесен начин. Тук хората си пишат името на темата и тя се зарежда, но нали това може да бъде много лесно експлоитнато. Та това е почти толкова ниска топка като първия пример, но е някакъв кейс, който абе може и да го видим някъде. Не е не е напълно изключено. Тада, къде ми отиде кликалката? Ето я. И да, хубаво. Сега показахме как някой ни е пребутал гадни теми. В тях е имало малише скот. Ама какво ще направим, ако всъщност ние си използваме само DNET, някакъв vanill application? Никой не може да зарежда никакви external dependance има супер стриктно полиси, никакви чужди пакети, само DNET. Няма как в доnetта да има нещо лошо, нали? Ами всъщност се оказва, че голяма част от аnet апликейшъните директно още на старите се зареждат такива асемблита, в

17:25↗които има супер известни гаджет чейнове, нали? Гаджет чейновете са поредици от код ивокейшъне, дето накрая се случва нещо лошо на на последната стъпка. И кои са такива апликейшъни? Всички WPF апликейшъни буквално. И сега ще покажем един пример. За жалост обаче, а това, че ваши апликейшън не е WPF, не означава, че сте предпазени, защото аа също тея тея апита много лесно могат да бъдат заведени в аа вашия апликейшъ, защото особено ако сте DNETФWorkк, тея assembмлите стоят в гак. Просто някой трябва да ги извика. Та това е Данотория Замъл Парсави. А замъл, който е имал така щастието да работи, е тоя майкъп език, който ти позволява да пишеш тея прекрасни UI с него, но той е а страда от някаква такава а идентити криза и понякога не само представя UI, понякога представя документи, а пък понякога представя конфигурации и много често хората го ползват не за UI, а за някакви други

18:48↗неща. примерно описание на някакъв документ и за да разбереш какво има в документа, ти тоя зал го пасваш или специално тоя тест прави нещо друго, а позволява хората да си зареждат някакви замъл стрингове и да да получават нещо и да се ъпдейтват лайв дома. И сега тука заредих ей тоя застрин и си добавих тоя прекрасен бутон, нали? И сега другият бутон изкарва калкулатор. И сега защо изкарва калкулатор? Ако се вгледаме ей тука малко в тоя замъл, той е много интересен. инстанцира един тип object data provider, който е най-якият гаджетн, който може да а намерите, защото буквално на него можеш да му подадеш тип, от който да да инстанцира типа и да му викне метод с определени параметри. Изключителна красота. И а ако по някакъв шанс има presentation framewor assemblyто да се зареди във вашия домейн и да ви се налага там да викате за PS, винаги трябва да мислите за тоя Object Data provider и и

20:07↗изключително брутално изпълнение е той. И сега как може да се защитите? За жалост мисля, че в Microsoft са се усетили чак няколко след години, след като са го написали това нещо за за това, че трябва да се защитават и техният така наречен замъл не поддържа някакъв разумен начин да се филтрират тия типове. И тук съм направил един secure zam reader, който а може да чеква ръчно името на на нода, на който си в момента. Както си представяте как работят XML рийдърите, нали? Четеш си елемент по елемент по елемент по елемент, в някакъв момент стигаш до някакъв елемент, който не ти харесва, хвърляш кърпата и казваш: "Не, не, не, това не ми харесва." Та ще го опитна тоя моя емпъл да използва secure readра, за да видим една възможна защита от това нещо.

21:15↗И да, сега отиваме, зареждаме си бутона и той е също толкова красив, колкото беше и преди. И сега ще се опитаме с object data провайдера. Dangerous type detected. А тук съм използвал един прекрасен антипатърн да се опитвам да се пазя с един лист. Ще си говорим малко повече за това. Направих го просто защото е лесно. Не бъдете като мен.

21:45↗Така. Та да, вашият доме а домейн не е вашият л. Много внимавайте за всеки един тип, който някъде инстанцирате. Затова се пазете. И един много лош начин да се пазиш е да се опитваш като мачваш някакви стрингове да познаеш ей сега какво ще се случи като се зареждам assembм. Та да, това е нашият приятел Бенда, който вярва, че ще направи най-якия assembly verрифиicationшъ, който сега ще погледнем.

22:22↗Така, това е един изключително защитен конзолен апликейшън, който чете типове от конзолата и ги стартира, обаче той е много защитен и като получи някакъв тип, а то го очаква да е с лифй name типа, но след това а се опитва да се гарантира, че от така нареченото safe assembly ли като му апендва а името на асемлито и казвада тук задължително ей сега тоя тип ще го заредя от това safe assembly и го стартираме и сега ще видим какво ще се случи казваме искам да заведим save assembly save class. Представете си, че това е някакъв аа инпут, който идва от какви ли не юзъри някъде в интернет и тоя код се изпълнява, нали, на вашия уеб сървър. И да, сега изписахме, че ей сега ще видим safe assembly, safe типа от safe assembly. Всичко изглежда страхотно. Казва, че сейф конструкторът се е извикал. Добре, сега ще опитаме с един не чак толкова save string. И сега кое е забавното тук? Вторият стринг е анат

23:48↗mal, който накрая съдържа просто една кавичка, която ще счупи сега цялото нещо.

24:00↗Извинявайте. Добре. Ето го калкулатора. Ама защо го получихме? Нали имаме уж някаква защита, че сме казали, че много е важно да е от нашето асмбли. И какво направихме? Получихме един стринг, който съдържа името на опасния тип, опасното ассембли, от което да бъде зареден, някаква глупост, която алгоритъма на Microsoft за мачване на асемлито не сработва и след това фу всичко се дизарегайдва. фейлвани нашата така наречена валидация и calculator appears.

24:43↗Така и отиваме нататъка. Сега това бяха някакви по-типични сценарии, дето да кажем, че можем да се защитим от тях изцяло с коън сенс,

25:00↗обаче има доста по-завъртени случаи. А понякога това да провериш кода, който екзекютваш ей сега, ами не е достатъчно, понеже нещото се случва някъде другаде, а не където ти си мислиш. И един много интересен такъв фичр на DNET са така наречените моди инилайзъри. Това са такива класове, които екзекютват код, когато просто асмлито се зареди. И имаме такъв пример, където

25:41↗някой ще зарежда тук някакъв си тип. Той е така нареченият save клас и е възможно най-сй класа, който можех да измисля. Move along. Nothing to see here. Но тоя save cl има другарче, което е не толкова save и има module иalizer, който ще ни извади калкулатор. Ама ние трябва да сме сей, нали? Зареждаме сей класа. Еми не точно.

26:26↗Добре, още един калкулатор. Сега как можехме да се предпазим от това? Тук слава богу от Microsoft са се усетили и са добавили няколко доста добри начина как да спрем тояр и едното е така наречения мета контекст. Ми сега ще го пробваме. Това е такъв, да кажем, safe reflection. отидохме и каза, "А, ама ти тоя тип не може да го инстанцираш." И сега хвърли епшън, защото ни позволява да вземем типа, позволява ни да го разгледаме, позволява ни да решим дали това е типът, който искаме да заредим, но не ни позволява да го заредим, освен ако не го а заредим по каналния ред. Така че ей това е един такъв много хубав начин, ако работите с някакви потенциално малиша с типове, да си ги заредите, да си ги разгледате и да си живеете спокойно. Друг такъв малко по-рискован ароч е да си направите ваш assembly load контекст, който е някаква кутийка, в която си зареждате типовете и асемблитата и след

27:41↗това може да изхвърлите кутийката, но трябва да внимавате да не вземете да извикате аа инстанциране в тая кутийка. И сега тука тоя пример е правим го тоя контекст, зареждаме асмблито, имаме да речем, някаква валидация, решаваме а не не това асем не ми харесва изобщо и сега ще го диспозналоваме контекста, колектваме memoryто и чакаме за finлайри, ако а защото може да има някакъв тип от това асмли, което да го държи да се а дисползне. Тук още един аа garbage collect колеect няма да е излишен, ако имаме наистина такъв finalizйer, да сме сигурни, че обектът е заминал, въпреки че това няма да ни блокира да се ънлоудне контекстъ. И тук какво би се случило?

28:34↗Ами нищо не се случи, защото ълоднахме контекста преди да се опитаме да заредим типа. Така че ей тая проверка фейлна. И пак сме on the safe side. Та да, това са доста полезни тулове, когато искате да зареждате някакви асмблита и да бъдете sa. И любимият ми пример за всички така фенове на технологията Winforms, която още световната икономика някъде се крепи на нея, един пример с акризай тайма. И имаме някакъв аликейшъ. Казваме не го знаем какъв е тоя апликейшън. Няма да го стартираме. Няма просто само ще видим дизайна му. И тука имаме една форма и ще кажем дай да видим дизайнеъра. Оп, калкулатор, нали? Нещо не натиснах. Look, мама no hands. Ами има клас, който се занимава с дизайн тайма на тоя аа компонент и нищо не пречи някой да инжектне. Има лиш скод в дизайнера? Та да, както виждате, понякога ами някои неща е трудно да се сетиш. Та продължаваме нататък. Сега видяхме

29:59↗много е страшно. За някои неща може да се сетим, за други не. Как да се защитим?

30:08↗Вечната дилейма, нали? Allулист също deny list. Всеки, който е чувал нещо там за security principles веднага ще каже: "Ами да, нали, ама добре да си преговорим защо." Ами secure by default principle. А знаем, че позволяваме само нещата, които ние сме казали да окей са и е много лесен зайте. Ако нещо ти потрябва още си го добавяш, знаеш какъв е атак сърфиса и като цяло спиш спокойно. А за жалост не винаги е опция, но винаги, когато можем да имаме избор, трябва да изберем листа. Много хубаво. Обаче как гифосваме тия неща? И представяме си една организация. Тя е нали много конъс за своите secюрити процеси, написала едни дебели книги там, каквото може се ефорсва, нали? Нетърк правила много лесно. Имаш файлове, имаш еcus, имаш правила, ама application security-то някъде там някой пише код. Дали ще спазва дебелата книга със secюрити полито, може само да се

31:23↗надявате. Има securюity cд revюwта. Еми някой може да преспи нещо. И как се пазиш тоя кейс, че първият девелопър, дето наемеше ей така луте, няма да каже:"Абе, аз знам как се прави това, няма да няма да гледам тука." Ами ние поне го правим с код аналайзъри и можеш да си напишеш твой или може да използваш някой готов и преди да си кажеш: "Абе къде ще си пиша мой, нали? Сега ще ви покажа колко всъщност е лесно. И това е реално следващото ми демо.

32:03↗Така.

32:08↗Сега да кажем, че това е девелопът, който е дошъл миналата седмица е почнал да пише код и тоя девелопър казва:"А аз ще викам тука activator create instance и ще си инстанцирам някакви обекти, нали? Това е ми приме, в който инстанцираме type of object, нали? Но той ко когато се опита да си билдне проекта, то ще му каже:"Ха, не може, не може да викаш activator create instance и той ще си прочете там, ще се притесни, ще отиде да пита някого и как го постигаме цялото това нещо. А, казва му, извикай сейф активатора. И сейфтиваторът е също такъв активатор, обаче да кажем, че е вързан с някаква централизирана валидационна логика, която са го писали там най-умните виcurюти експерти и знаете, че тука bypass няма. И с тоя аналайзър сте сигурни, че дето сте си потърдили да го помислите, всеки един девелопър еми това ще ползва, няма как, иначе няма да му мине билда. И самият

33:10↗аналайзър, той е обикновен диагностик аналайзър розлински и на в момента, в който трябва да се случи да се а резовне някакъв syntaxe, той може да провери абе тоя syntaxe дали не е тука от едни методи, дето ние не искаме да се ползват. А, activator create. Ами добре, това какво ще направи? Ще генерира директно грешка в билда. И това според мен е изключително удобен начин дафорсваш всякакви неща, включително ако искаш и стайлинг, а не само аа директно прохибиitionшъ на някакъв на апита. Също друг подход към темата би бил да имате тестове с подходящи малиша сйлоди. И ако се търсите изнета, за Java има супер много, за DNET има Y serial и няколко други, където всякакви гаджет атаки ги има развити до ниво. Аз мога да вземало и да си го интегрирам в continuous integraation, което е прекрасно и винаги може да си on the top of the game с най с най-новите файдинги.

34:29↗Друго полезно нещо е да използвате de compiler toлове, ако искате да видите какво ще стане сега, ако заредя това assemли. Може да вземете кода, да го пуснете през вашите чекове, които имате и чак тогава да го тръснете. Та като цяло това беше от мене. Готов съм за някои въпроси, ако има.

35:03↗>> Първо благодаря за за презентацията, за лекцията. Някои от нещата демота трябва да ги изгледам после малко по-бавничко, да се поузирам, за да видя, понеже бяха доста интересни. >> Кодъ ще е там може да го гледате. Да, >> да. А, супер. А въпросът ми е за къстъм аналайзъра. Това нещо не е one time sh, нали така? А, в смисъл това е живо нещо, което някой трябва да го поддържа. >> Да. >> В смисъл имате човек, който се грижи за това да го поддържа up to datйт. >> Ами е играчка, не е за друго. Изисква някакви локални ресурси, докато ако си наемеш външен, нали, инструмент, той би могъл да ти върши статичния код анализ. Да, това е така, но а когато е в твоите ръце, нали, може да си добавиш каквото искаш, флексибилити. И мисля, че изборът е Ние Ние така си го направихме, защото ни беше интересно общо взето, но аа няма причина да не избереш нещо готово. Може ли да кажеш, че по-скоро образовате

36:03↗така вашите програмисти да ползват конкретен начин, който смятате за правилен написане на код? >> Да, >> може би и този аналайзър може да го вкара в някаква да политика на или начин на писане на код на компанията, ако привнат по някакъв начин. >> Да, да. Това в момента при нас има неща, които са задължително не, особено в такива а секюрити сенсирии, където не можем да поемем никакви рискове и това ни позволява да сме супер дистриктивни с тоя аналайзъри. >> Супер, благодаря ти. Други въпроси?

36:49↗И благодаря ти много, Иван. >> И аз много благодаря.

36:56↗>> Вече знаем, че ако калкулаторът сам се отвори, нещо хич не е наред. >> Да. Ако стартирате софтуер и излезе калкулатор.

37:07↗>> Добре, нека приветстваме следващия лектор Дани, който ще ни разкаже за треadт моделинг.

37:23↗S

39:32↗А, извинявам се, ама който на живото предаване

40:44↗Ме ли се? Да.

40:50↗Добре. Здравейте на всички. Темата, която ще ви представя е effective tradлиing. Първо да ви се представя. Аз съм Дани, application инженер, тоест работата ми е основно да правя secure quote revwю-та, като цяло ревюта на различни архитектури, треad моделинг и а пенетрейшън тестове. Преди това съм бил около 4тири-пет години backend инженер, като в момента интересите ми са основно около web и mobile security research, penнеetation testing и bug bounty hunting. Така, каква е аджендата за днес? Първо малко теория. Какво е трет моделинг? Защо ни интересува, как и къде най-вече трябва да го правим и след това три практически тип типс от мен, като накрая ще се опитам да сумаризирам всичко, което сме говорили и евентуално да остане време за Q&A сесия. Така. Трет моделинг. Ами, честно казано, според мен моделинга е доста естествен процес за нас като хора и реално всеки човек постоянно

42:15↗прави под някаква формат моделинг. Примерно аз всеки път, когато излеза с колата да карам, си пускам йс, за да следя за потенциални проблеми. Също нали на всеки му се е случвало да отиде в непознат град или някой съмнителен квартал. Проверяваш откъде как трябва да минеш, за да няма проблеми, нали? Примери от реалния живот всекидневието доста, но формално казано трет моделинга това е проактивен процес за а идентифициране на потенциалнирабилитита в продукта, който разработвате. Неформално казано, събирате си целия екип, отваряте архитектурната диаграма и почвате да разсъждавате къде какво може да се обърка и как бихте го предотвратили. Основната идея е, че нали трябва да се поставите в обувките на един външен атакър и да се опитате да мислите като него. Тоест как бихте счупили самото приложение. Друго ключово заред моделинга, може би едно от най-важните неща е, че а

43:31↗колаборативно упражнения, тоест най-ефикасните трет моделинг сесии, като цяло трет модели се правят, когато целият екип, независимо дали са техchnical или nonнтеchical хора.

43:47↗Така, сега идва въпроса защо ни интересува като цяло това нещо. Ами, както казах преди малко, това е проактивен процес. Тоест каква би била алтернативата? Ами алтернативата е реактивно. Тоест правят ви пентест, идват 20 плюс проблема, които трябва да оправяте, нали. Съответно това ще отнеме доста ресурси. От ресурси имам предвид а време и пари също така. А другият вариант е без pнтеest report директно някой ви хаква, нали тогава искате, не искате. трябва да почнете да мислите по тая насока. А друга причина е, че съм забелязал, че колкото повече такъв тип треad моделинг сесии се правят в един екип, толкова повече се вдига secюрити a и те прехвърлят този тип мислене в различни области от техния живот, не само професионални. Аа нали предполагам, че тия аргументи няма да са много силни за някаква част от вас. Затова следващият аргумент ами Cyber Resilience Act. Това е

44:58↗директива на Европейския съюз. В сила е от миналата година, но ще започне да се енфорсва а 2027 година. Като една от точките в Cyers Cyber Resilance Act е, че трябва да се правят моделинг сесии. не е желателно, а е абсолютно задължително да се правят. И рисковете, ако не сте compliant с това, са глоби до 15 милионаро, нали, брутални суми. Така че следващите години ще виждате все повече хора да говорят за това, да правят такъв тип амсии, както и ще се появят най-вероятно и много различни тулове, които да помагат за това. А, на последно място, за мен най-важната причина, честно казано, е яко. Поне мен ме кефи. Следващият въпрос е кога трябва да правим моделин. Предполагам това ви е на повечето познато. Softare development life cycle. Грубо казано има шест фази. Planning, requirements design implementation testing and integration и maintenance. Като няма да влизам в детайли във всяко

46:25↗едно, но нали план това е, когато първоначалната идея за това, което искате да правите е създадена, какви функционалности искате да има. В requirements вече формално се дефинират всички functional и nonfunctional requirement. В дизайн фазата се създава самата архитектура, както и deep dive на всеки един от компонентите в тази архитектура. Implementation реално, където се пише кода и се създава самата инфраструктура. Testing and integration. Това е моментът, в който приложението е качено на някаква среда. Дали е деф тест, няма значение и са извършени тестове върху него. И накрая maintenance фазата. Тука може да кажем, че приложението вече е живо и работи на productionшъ среда. Сега аз имам един въпрос към вас. Според вас коя е най-добрата фаза от тези шест, която да се прави аред моделинг? Като само да уточня, ще има награда за отговора, който най-много ми хареса.

47:33↗Планирането. Добре. планирането. А как би направил тре модул, като нямаш подробна информация за самата архитектура текстака дизайн. Добре. Други отговори?

47:55↗Ами, честно казано, аз нали като се чудих кой отговор е най-правилен за мене, си казах, че бих приел три отговора. Първият е зависи. Естествено, да. Не всеки спазва този аoftare development life cycle. Всяка една от фазите може да изглежда по различен начин при различните екипи, така че нали относително е. Вторият отговор, който щях да приема, е дизайн фазата наистина, защото в нея вече имаме по-подробна архитектурна диаграма на компонента, който правим и а нали на базата на нея може да направим горе-долу окейт модул, но мм според мен най-правилно е всички. И какво имам предвид с това? Между другото, кой каза дизайн първо? Добре, ще се разберем после.

48:58↗А, та да, във всяка една от фазите според мен под някаква форма трябва да участват моделинга. Тоест още на ниво планинг спрямо това какво искаме да направим, примерно сайт с еди каккви си функционалности, може да направим така наречения high level thread modelлиing. Тоест, без да имаме аа детайлите за техническата имплементация, все пак може да направим някакъв вид модеъл, като резултатът от него а евентуално могат да бъдат securюity requirementм, които да бъдат да бъдат добавени към останалите functional и nonfunctional requirement в следващата фаза. А, както казах, в дизайн фазата реално формално се правят архитектурните диаграми, data flow диаграмите и към тях се добавят аред моделинга. Implementation фазата тук а по-скоро идеята е да refйнем самия модел. А защо? Ами защото в процеса на девелопмънт могат да излязат неща, които не са предвидени в дизайн

50:12↗фазата. Тоест, нали, най-простият пример е някой девелопър е решил да си вкара доста съмнителна библиотека в кода, която нали носи рискове дали ще са анерабилитита, дали пък няма да е нещо сine chain атака. След това в testing in integraation фазата по-скоро трет моделин играе спомагателна роля. Тоест това между другото е фазата, в която е хубаво да се извършват пентестовете и а м нали използвайки модула и описаните от него а компенсиращи контроли чрез пентеста може да валидираме дали те наистина работят или пък нещо сме пропуснали. Съответно, ако сме пропуснали, връщаме се и ъпдейтваме самия трет модел. Накрая в maintenнаance фазата супер важно е отново причината за това е, че всеки ден излизат новинерабилитита и е хубаво, ако някой от компонентите, които ползвате, а което е засегнато дадено vulnerрабилити, нали, това да го вкарате и в самия трет модел. Също така след

51:34↗инциденти задължително ъпдейтвайте ред модела. Още малко теория. А ще говоря за Strike Striite е много готин фреймърк, създаден от Microsoft. Той ни позволява да категоризираме различните vulnerрабилитита в шест категории. спуфинг, тоест да се представяш на нещо или на някой, който не си, с цел да достъпиш или да направиш нещо. А там това е м по някакъв начин да модифицирашта или код, а information disclosure ясно, под някаква форма е изтекла чувствителна информация за internal инфраструктурата. А repudiation е малко по-странно. То е грубо казано дали имате а Audit tril, тоест примерно ако имате администраторски акаунт в платформата и този админски акаунт е изтрил друг потребител, дали може да докажете, че наистина това го е направил даден админ или не се е случило нещо друго? А service отново ясно make system available и privilege escalation или elevation of privilege да добиете

52:57↗права, които са по повече от това, което в момента имате. Аа така. Друго нещо, за което искам да говоря, това е dreadт. Значи страйт ни позволява да категоризираме vulnerabilлитата в някои от различните категории, а ни позволява да им дадем скор, тоест дали са high, low или medium, нали? Повечето от вас знаят, че а рискът това е грубо казано функция с два параметъра impact и проability, като ни позволява да разбием тия два параметъра на още погранулярни, тоест

53:43↗damage reproducibility exploitability affected users и discoverability. Тоест за всички потенциални проблеми, които сме идентифицирали, можем да им дадем точка за всяко една от тия категории, като точкуването е от нула до 10 обикновено, нали? Демидж, какви щети биха нанесли, ако някой ни експлойтне дадения проблем. Колко лесно е да се репродудюсне, колко лесно е да се експлоитне, а потенциално колко потребителя биха били засегнати от товабилити и накрая а колко лесно е да се намери. Като идеята е, че за всяко едно давате оценка, сумирате ги и на базата на сумата може да определите рейтинга на третовете. Пак да повторя, strike категоризираме vulnerability. Даваме им скоринг. И сега към практическите съвети. Преди да спомня какъв е първият тип, искам да ви разкажа за три продукта, които а последните месеци станаха доста известни и доста нашумели. Първият е Cyber

54:58↗Security AI или CAI. Това е open source продукт, който е така да кажем fully autonomous agent, който може да намира и експлойтва различни vulnerability. Ако се загледате в Milstones, за седем дни е успял да стигне ранк топ 30 в Hack the Box, нали? Повечето от вас сигурно сте играли Hack the Box, знаете, че това не е нещо тривиално. А друго нещо интересно е, че наскоро Hack the Box организираха CTF за Human Versus AI, като в този CTF този tool е достигнал първо място от всички а AI ботове. А ако отворите GitHub repто, може да прочетете we predict that by 2028 AI powered security testing tools will outn human pen testers. Сега това колко е вярно? А, спорно, но е факт, че виждам все повече и повече хора, които са offensive security ориентирани да използват под някаква форма AI. Следващият, този може би сте го виждали, се казва Xball. Интересното за Xball е,

56:21↗че за последния ктър е ранк номер едно в Hacker One за а Америка. Между другото, той работи от три месеца, така че ще видим как ще се представя занапред. Отново ли autonomous, нали? Като казвам autonomous не е баш така, защото винаги има human in the loop. Тоест то успява да намери дадено vulnerability, потенциално да го експлойтне, но след това в повечето случаи задължително трябва да бъде а проверено от човека. Последният такъв л е а Hacktron AI. Отново Fly Autonomous Offensive Security малко по-различен от предходните, защото се фокусира върху по-скоро правене на код ревюта и в последствие експлойтване на разнирабилитита. А интересното е, че един от създателите Siri се казва, а той е security инженер в Cure 53. Може би сте чували за Cure 53. Това е нали спорно е, но за мен е една от най-добрите компании в Европа, свързана със secюрити. Те са а разработили до

57:36↗Peurify. Това е буквално най-добрата библиотека за санитизация. Та той и още няколко човека са го създали този тул и отново доста обещаващи резултати. Даже днеска ми излезе туит, че са намерили а някакъв доста девастайтинг zero day. Та както се сеща, тип номер едно е използвайте AI. По принцип не съм фен на хайп технологиите, но определено от това, което виждам последните месеч години, а това е доста мощен инструмент и ако не го използвате, по-скоро ще изостанете. реално не виждам какво губите от това да не го използвате, като за целта правя едно кратко демо. Аа така.

58:38↗Това е едно приложение, което съм разработил. А за момента ро за момента това, което може да прави е тези highлет модели, които ви говорих по-рано за тях. Тоест необходимото да бъде създаден такъв high level трет модел са следните неща. Първо application name, да кажем library уебсайт. А

59:18↗съм

59:24↗хм

59:32↗така. А та както казвах този л може да прави high level. Не знам що се случва тая микрофония. Съжалявам.

59:45↗Така. Application name а library application версия да кажем 00 100 алфа. Като цяло апликеation версията не е особено важна. Основната роля е за по-скоро tracking purposes. След това description. Аз съм си подготвил единпtion. Само секунда.

1:00:16↗Надявам се да се виждал. The college library website is the first implementation of a website to provide librarians and library patrons with online services. Има три user student, staff, librarians. А като staff и students могат да се логват, да търсят книги и така нататък, нали. Няма да влизам в детайли. А следващият въпрос е дали ебing. Да, facing. Какъв му е типът? Възможностите са web, API, mobile, desktop, IoT, cloud или нещо друго, да кажем web. Data sensitivity-то, тоест с какъв тип информация,

1:01:06↗какъв тип информация борави, а да кажем privна от гледна точка на бизнеса. А вариантите са доста, но да кажем operational не е особено важно. И последният въпрос. Какъв auentication метод ще използваме като възможности са password base, passwordless, MFA, Federated, Biometric и Ten based, да кажем Password Base. Готово, попълнихме въпросника. Сега приложението е създадено и ни пита дали искаме да ни създаде трет модел. Цъкаме yes и докато чакаме, ще ви покажа system промта, който използвам.

1:01:59↗Както виждате, доста голям е. Има доста детайли вътре. А основните неща са първо RS and expertise, тоест в каква роля искате LM-ъ да влезе. Тук съм описал, че е application security engнеer с 20 години опит, не знам си какво. Правил е много моделинг сесии и така нататък. А задачата му е да анализира описанието, което преди малко въведох и на базата на него да а генерира поне четири на брой vulnerabilityта във всяка една от strйт категориите. След това му описвам responsс формата какво искам да включва. А какъв би бил applicationшъ котекст? Тоест тук за type изброявам така нататък. Много важно, когато пишете такъв тип промтове, задължително а поставяйте какъв точно искате да е репонс формата, за да може стриктно да го спазва. Тук съм му описал един Jйсън, който искам да ми връща. И накрая завършвам с един дисклеймър за ALM-а, че трябва по възможност да не халюцинира много и а

1:03:18↗нещата, които ми връща да са релевантни за м applications, които съм му дал. Това е промта. През това време ни се генерира а трет модела. Сега мога да го отворя. Тука, ако искам, мога да си го филтрирам по strйт категория или по северити. Така, няма да минавам през всичките, защото нямаме много време, но това, което искам да обърнете внимание е по-скоро на им improvв а са suggжеestте. Те биха били едни идеални аurity nonfunctional requireмти, които дадете на хората, на архитектите или на синиър инженерите, нали, който прави самата архитектура, да ги вземе в предвид, примерно stronger password policies, потенциално MFA, а да имаме добърback, а всички страници да използват HTPS, естествено акрип transit audit на c imp validation нали голяма част от тия неща са сравнително казанок но те са една много добра отправна точка за това да разсъждавате впоследствие в детайли за

1:04:51↗аа потенциални проблеми

1:05:00↗така да се вър върна на презентацията

1:05:09↗и сега голяма част от вас ще кажат нали много хубаво, много е яко, обаче откъм privacy гледна точка или от пък регулаторна гледна точка няма как да ползваме AI. А между другото аз имам познати, които на работа им е абсолютно забранено да ползват AI поради една или друга причина, но пък имам и познати, където абсолютно за всичко ползват AI. Буквално а голяма част от камитите са писани от курсор. Даже част от меседжите са буквално промота, който е използван, за да си напише този код, нали? Зависи. Все пак а ако някой има privacy concerns, има два варианта как може да се справите. Първият е да използвате а локален модел, а препоръчвам QN плюс някакъв вид рак. А, няма да влизам в детайли какво е рак, но грубо казано му вкарвате един голям списък от документи, които са релевантни за темата към нали, от която се интересувате в случая моделин, тоест му вкарвате strike

1:06:27↗документацията, вкарвате му различни готови трет модели, различен бройрабилитита и а когато генерира локалния моделпонс, информацията от рак има по-висок приоритет. Тоест доста по-ефикасно работи. А ако това не ви устройва, има друг вариант. Отново се ползва локален модел, само че този път ролята му е изцяло да маскира чувствителната информация. Тоест, преди промата да го изпратите към Open AI или Antropic или whatever, първо го прекарвате през локалния модел. Той го, така да кажем, санитизира, премахва всичката чувствителна информация или нещо, което не е окей а Open AI да го знаят и чак тогава го а изпращате към LM-а, който искате да ползвате. И двата варианта са окей, а особено първия. Аз доста съм си играл с това и резултатите са сравнително добри. А така. Втори тип gamifying. А трелин. Това, което виждате отдясно е една игра. Казва се Elevation of Privilge.

1:07:51↗Идеята е, че има а тесте с карти в комбинация с някаква архитектурна диаграма. Може да е ваш. Има и готови. Няма значение. Играе се на рундове. Всеки човек тегли. А карти шест на брой и във всеки рунд се избира една категория, примерно да кажем тампъринг и всеки играе най-силната си карта. Като какво значи да играеш най-силната си карта? Ами трябва да убедиш всички останали играчи, че потенциалноторабилити, което смяташ спрямо архитектурата, върху която работите, е валидно. Тоест всички се съгласяват, че това е потенциален проблем. А има още неща към правилата, но основното е това. Между другото играта е open source, безплатна, всеки може да си я принтира и подаръкът, който бях подготвил е точно тази игра. А якото е, че а го прави inclusive, тоест независимо от това дали а екипът от хора, с който работите, така да кажем, навътре в секюрити, той може да участва. Защо? Ами защото всяка

1:09:05↗една от картите това са, нали, то не се чете много, но по принцип това са реалнирабилитита, които биха били а възможни. Тоест с един такъв тип игра може а много лесно да вкараме а различни хора да разсъждават върху архитектурата. Между другото сега се сетих че доста интереснити покрай Business Logic Falls откриват най-лесно от продукт хората. Те най-добре познават домейна, който разработват и веднага могат да кажат кога нещо не е окей. Тоест, както казах по-рано, за да имате един хубав трет модел, е хубаво да включите всички. Друго нещо, че такъв тип competтив thinking в повечето случаи случаи води до а доста креативни идеи и аа нали съревнуванието честно казано е полезно, защото в крайна сметка трет моделът, който се създава по този начин е доста обхватен. Всеки иска да спечели евентуално. Съответно всеки разсъждава върху най-импаctт vulnerabilityта, които

1:10:27↗може да има спрямо архитектурата, върху която работите. Аа тип номер три, start simple. А, no fancy tools required. Да, мисля, че това е доста ясно. Като цяло за да правите моделинг, не ви е необходимо абсолютно нищо. Нали може да започнете с една дъска или на лист хартия. А, даже между другото преди две-три години, ако се сещате, Twitch ги бяха хакнали и им бяха лийкнали доста отлвете и едно от нещата, което беше лийкнато, а беше точно техният модел. Сега колко е бил добър, друг въпрос, ама а интересното е, че беше точно на лист хартия тоест и и това е добър апроуч. А все пак, ако работите в екип, който има хора от целия свят, нали, физически да се съберете, няма как да стане. А тук вариант е да се използват различни такъв тип алове, като например Draw IO или Excali Draw. Предполагам, че всеки от вас в екипа си имат имате някаква някакъв такъв инструмент, който използвате за чертаене

1:11:58↗на диаграми. Еми тоя инструмент може да го превърнете в инструмент за трет моделинг. А така. Сам съм.

1:12:15↗Това е draw io. А тук съм подготвил една data flow диаграма. Реално то еquнс диаграма в случая на доста познат за повечето хора. Authorization и authentication flow. А актьорите, така да кажем, в случая са frontend client, API gateway, Keylock, което ползваме за authorization server, различен n на брой microservices и потенциално administration service. След като имате такъв тип dataта flow диаграма, ами просто какво правите? Почвате през всяка една от тези точки, сядате и разсъждавате тук какво може да се счупи. Ако а може да се счупи, как може да го оправим и така нататък, нали? Примерно на мен това, което в момента ми прави впечатление, че тук имаме single point failure, тоест а първо токън се валидира от API gatewayя, за да знае накъде да ротира след това рекуеста към кой microserвиice след това самият microsвиice отново валидира токъна, като вали валидацията се случва

1:13:39↗през а intrроppection quy-то на keyкlock, което не е не е особено добра практика, нали? По-добре е да се ползва JW key, където а самия API Gateway и самия Microsice, използвайки публичния ключ на Keyклок, могат да валидират токъните. Но да кажем, а това ако не е feasible, вариантът е да си подсигурим примерно keclock да работи в high availableity cluster. Това е доста лесно да се направи. Буквално една кратка конфигурация. Аа също така на API gateway-я може да почнете да разсъждавате. Сега тук трябва ли ни а rate limiting? Тази login страница, която Keylock връща, пуснат ли е brot force protection от Keylock? Нужно ли е да имаме MFA и така нататък, нали? Минавате всяка една от точките, гледате може ли да се счупи, ако го предотвратим? Горе-долу това е най-лесният и интуитивен процес за правене наред молин.

1:14:58↗А ако все пак искате да стенси, може да използвате специализирани инструменти за това. А Microsoft имат, но и а O AllP имат, а именно Allp Thread Dragon. М доста е удобен, доста е готин. Плюсовете са, че има предефиниран списък от потенциални vulnerabilтиes, както и използвайт методологията, за която говорих по-рано. Нали проблемът с dragon е, че както всеки един инструмент си има аниve, тоест нали не може да седнете и директно да почнете да правите трет модели и трябва да го разцъкате и да видите как работи. Затова най-добре ползвайте инструмента, който така или иначе вече използвате. А така. Сега да обобщим. Ключовите моменти, в които трябва да се прави модел са по време на requirements и design фазите, когато има нов maрчъ или сериозна архитектурна промяна преди лиз и абсолютно задължително след инцидента, като може да използвате този, така да кажем, decision flow chart.

1:16:27↗Като почвате от най-отгоре, първо започваме, както казахме, с high level thread model. Създавате го или ползвате AI да го направи за вас. Резултата от този а level model са security requirementм, които се а вкарват в самата архитектура. Целият този процес, тоест първите две стъпки могат да се повтарят а доста пъти. Идеята е да итерираме, докато аа не оеднеквим а самата архитектура с трет модела. След това аа стандартно, като имате такъв тип архитектура, се прави така нареченият deep diйв на всеки един от компонентите. И в този deep dive за всеки компонент, за всяка негова основна функционалност какво правите? Първо генерирате dataф диаграма. Може да използвате sequнънс диаграма, както това, което ви показах. Може и нещо друго. Основното е да се вижда как информацията преминава между компонентите. След това за всеки а син илис на информация, тоест всяко място, където

1:17:42↗идва или излиза някаква информация, мислим за потенциални проблеми. Като ползвамейт, а ако не можем да се сетим за никакви проблеми, тогава отваряме картиation of privilege и си избираме някоя и гледаме дали е applicable. А след това за всяко такова и тука съм пропуснал да добавя, но е хубаво да му дадете и dread score, тоест high low или medium и на базата на тези две неща да прецените какво ще правите с този проблем. Вариантите са четири. Първият вариант е да го приемете. Казвате окей, нали това е потенциален проблем, няма какво да направим. Вкарвате го вристри-то и си седи така. Вторият вариант най-добре е да го митирате. Тоест или решавате някаква форма проблема, или слагате компенсиращи контроли, примерно лав или нещо подобно. А третият вариант също много добър. Аз много го харесвам и това е eliminate, тоест функционалността, която е породила проблема, директно я премахвате

1:18:52↗и аа трансфер. Трансфер е много удобно. Буквално казвате някой друг да го мисли. Мен не ме интересува. Така. След това аа идва стъпката validate controls. Тук има два механизма за това. Единият е Secure C review, другия са penнеetation тестовете. Между другото, като казвам penнеetation тестове, в повечето случаи имам предвид white boxetation тестове. Смятам, че те са а най-ефикасни и имат най-голям импакт. В крайна сметка идеята на пеншъ теста е да се покрият възможно най-много неща, но все пак ако налиal фирма или еnalл човек ви правийшън теста, нали, предполагам няма да е много а окей да му предоставите цялата информация, а source код, документация и така нататък. поне а това, което можете, тоест какви функционалности има, какви user роли има, тоест нещо тип greaybox penнеetation test. А след това, ако сте видяли, че сте пропуснали даден проблем или пък

1:20:07↗компенсиращият контрол, който сте измислили, явно не е особено ефикасен, се връщате на стъпка две. review and improve architecture. Цялото нещо, нали, то този фолу е итеративен и трябва да се случва доста регулярно, нали. Моят съвет е чисто практически правите го по време на дизайн фазата. След това на всеки relлиase maр имам предвид ли, който не е backward compatible и а задължително след инцидента.

1:20:50↗И това е. Благодаря ви.

1:20:58↗въпроси.

1:21:04↗>> Два въпроса от мен. Единият е защо препоръча Allp Rad Modeling Dragon >> Dragon пред Microsoft Rad Modeling tool, честно казано, защото съм го ползвал. Другия не съм го ползвал особено много и затова, но както казах, тула няма особено голямо значение, нали, всеки един би било подходящ. >> Добре, благодаря. Другият въпрос е каза, че е хубаво да участват хора от екипа, които не са технически ориентирани. Да. Добре де, ама същевременно тоя curve, за който спомена, нали, с туловете и с целия тоя модел, изобщо какво какво изобщо означава страйт, как да им обясниш на на тия хора, докато им обясниш какво е страйт, е свикнат да мислят в тия термини, нали, колко време трябва да мине. >> Да. Еми това е, нали, затова съвет номер две ми беше да се използваation of privilegge, защото в крайна сметка повечето хора са играли бордови игри. Това е точно такъв тип борд гейм. Тоест

1:22:06↗правилата са сравнително лесни, а постоянно всеки има правилата пред себе си, може да проверява коя примерно страйт категория какво значи и по тоя начин реално се и научават. В последствия няма да са им нужни.

1:22:26↗>> Да.

1:22:32↗Ами да, нали много зависи вече от конкретния екип.

1:22:55↗>> Да, това също е добър ароч.

1:23:05↗Един въпрос, ако може така от опита ти да отговориш. А направили сме перфектния ред модел на дизайна имплементацията и след това я заради някой бъгфикс, я заради някоя нова функционалност сме променили какво сме имплементирали. >> Връщате се. Как да се сетим сега с това да се върнем, да го направим и как да го поддържаме? >> Аа има различни варианти. Първият е да си имате ясно дефиниран процес. Тоест знае се, че когато има мейджър промяна, вследствие на нов фичъ или архитектурна промяна, задължително сядате и променяте трет модула. Другия има, аз това не говорих за това, но има един tool, казва се Agile, който позволява а той е буквално един AM в repository, в който всеки девелопър е длъжен при нов pull request да го ъпдейтва и по този начин, нали, всички да се уведомяват, че има някакви промени, ако трябва да се ъпдейтне и самият модул.

1:24:08↗>> Едно въпросче от мен. А твоя опит какъв тип проблеми най-често си виждал да се откриват, да си избереш един >> основно Добре, ще кажа два. А първият е Business Logic Fallse. Това е много трудно да се намери с автоматизирани тулове. Тоест, ако имаш SAS Software Composition anal, whatever, няма да мога да го намеря. А другия са broken access control проблемите. Те са неслучайно ос топ едно. >> Аа благодаря. Бих искал да попитам какви са предимствата на това да се въвтехнически хора в цялата дискусия. Каква стойност добавяте? >> Ами доста често нетехническите лица имат така да кажем out of the box thinking и могат да се сетят за проблеми, които техническите въобще дори няма да им дойде на ум. И това са проблеми, които са свързани точно с бизнес логиката на приложението. Тоест имате функционалности, които нали на пръв поглед изглеждат окей, работят, но

1:25:14↗реално помежду си те са несъвместими и водят до някакъв проблем.

1:25:24↗Някой друг?

1:25:31↗>> А, първо благодаря за презентацията, беше прекрасна. А два въпроса и двата провокативни. А как се справяш с Natural Resistance на програмисти и бизнес да предприема да приемат секюрити мерките дори и в трет модела, защото някой път при трет модел, особено при планинга може да се наложи да се промени бизнес логика. В смисъл изобщо не са мислили за 2FA и не са го бюджетирали, че пък не са и чували някой път дори. >> Ами >> примета >> номерът е да обработваш хората, така да ти кажа. Нали, месеци наред трябва да им обясняваш, че това е важно, трябва да се прави и да им доказваш защо е важно. Но по-лесният вариант, ако работиш в проект, който е силно регулиран, просто им казваш искате, не искате, трябва да е така, нали? Дали им харесва, >> трябва да имаш си левъл подкрепа. >> Да. И вторият прогативен въпрос, този тул, който ни показах, а склонна ли си да го отвориш за Educational Purpes

1:26:27↗примерно, >> защото изглежда наистина много интересен и би могъл да помогне в университет или в училище. >> Мислил съм си го, но искам да го развия още малко. А следващият фичър, който пише е да прави по-детайлен тред моделинг на конкретни фичъри. Тоест в момента, в който се отвори Pull request, а тула да анализира кода, да преценя какво прави и на базата на това да генерира вече детайлен трет модел, който да включва конкретната имплементация, нали, depендънситета, които са ползвани, абсолютно всичко. >> Ако ти се четат лекции в университета, обади ми се също. Ще те поканим с удоволствие в няколко. Благодаря ти. Само последно нещо да кажа. Нали презентацията беше фокусирана върху defensive tha model моделиing, но съществува и така нареченото а offensive trading. Доста от high performing bug bounty hunter го използват това. А малко по-различна е концепцията. Сам не се

1:27:30↗ползвайт, а се ползват така наречените attack 3. Тоест, а задавате си цел, примерно акаунт takeover и създавате всички възможни пътища до тази цел, като това после се ползва като чеклист от самия теester или buутинър, за да провери дали може да достигне тая цел. Та ако имате интерес, мога следващите лекции да направя за offensive modelling. Мерси. Благодаря ти много, Дани.

1:28:10↗>> Чудно ми е дали самите уей приемат полицаите като тредове. Аз не говори за полицаите. Говори. >> А, да, да, да, да. Така е. А, добре. Благодаря отново. Нека приветстваме и последния ни лектор за вечерта, който е Мартин. Той ще ни разкаже малко за CVSS.

1:30:23↗Здравейте, добър вечер от мен. А аз съм Мартин. Ще ви разкажа за CVS, а как да оценяваме уязвимости Common Vability System. А преди това съвсем накратко няколко въвеждащи думи. А тук имаме поне три категории, може би четири хора, които пишат софтуер, хора, които защитават софтуер, хора, които чупят софтуер и евентуално хора, които пишат софтуер, който чупи друг софтуер. В крайна сметка стигаме до ситуацията с уяазимостите. Затова правим треadт моделинг, затова гледаме нещата по-рано, да нямамости, но алазимости винаги има. дали защото допускаме грешки като разработчици, дали защото технологиите имат своите а ограничения и трябва да имаме начин, по който да оценяваме уязвимостите коя е по-сериозна, коя е по-малко сериозна, какви аспекти имат тези уязвимости. Всъщност аз съм Security инженер, Prodюри в момента бил съм и Offensive Securриity. Бил съм от двете страни на

1:31:36↗това да гледам уязвимости, да намирам и да и да докладват на нас за наши продукти лъзимости. Много често стават аа едни разсточителни обсъждания, ама тая лазимост толкова ли е сериозна, такава ли е оценката? Аа съответно има една естествена м едно естествено противоборство между тези, които докладват и тези, които четат докладите. А защото тези, които докладват, искат да имат много голяма стойност тяхната улазимост, която са намерили тея, които пък четат докладите, евентуално искат да да намалят оценката. Аз лично винаги и от двете страни съм се старал да ги оценявам, както смятам, че технически а е правилно. А ще се опитаме да направим една по-интерактивна сесия към втората част. Първо ще разкажа малко за CVSS, после ще се опитаме заедно да оценим няколко уязвимости, така че после ще има един QR код и ще направим а една оценка на живо. Така че, ако имате желание да участвате, напълно

1:32:43↗анонимно ще ще разгледаме няколко уезимости. CVSS това всъщност е а методология, по която може да оценяваме а уязвимости. Произвежда оценка от нула до 10. Нула е всъщност това не е точно уязвимост. Това може би е хардънинг съвет за за това как да направим нещо по-добре, но няма узимост и оттам нататъка от low, medium, high до critical, а организацията, която е отговорна за CVSS като стандарт е first. Ам всичко, което видите тук като спецификация го има на на този сайт. Може да влезете в повече подробности. Аз лично ползвам техния калкулатор зазимости. Има, разбира се, много различни UI за това. Какво ни дава CVSS? Дава ни нещо като историята на Озимост, не толкова история, колкото какво представлява тя. А тук е един произвон пример, но това, което веднага можем да разберем от примера, бидейки опитни с CVSS, е как се атакува таяст, тоест как като подход, не като

1:34:01↗специфична а специфична атака и какви са последствията от тази уязвимост. Нещо, което е много важно, CVSS не е оценка за риск. CVSS е техническа характеристика на назимостта. даване някакво число, но това не е риск. Защо не е риск? Защото една узимост в система, която е отговорна за живота и здравето на хората, не е също като узимост, която е отговорна за приложението, чрез което слушате музика. Аа както и съответно от гледна точка на бизнеса, едни данни са по-чувствителни от други данни. Едни системи по по-важни от други системи. Това е риск. CVSS техническата характеристика като а разбира се има някакви механизми в CVSS, по които можем малко да аа да боравим с тези неща. Аз ще говоря за CVSS 3.1. Има всъщност най-новата версия на CVSS е CVSS 4, но CVSS4 не е напълно а възприета от една страна. От друга страна от CVSS3 до CVSS4 стъпките са малко. А аз ще ще покажа какви са какви

1:35:16↗са разликите, без да влизам съвсем в подробности, но ще ще покрием и и разликата. А също така защо си говорим за CVSS3? Това е пример за уяазимост, която е всъщност от преди може би две седмици. А CV еди си кой номер. Ако ако отворим тая това CV, тази лазимост, ще видим, че има CVSS3 оценка, но няма CVSS 4 оценка. Така че не не всяко нещо, на което попаднем, ще има аа ще има CVSS4 също така. А всъщност да да навлезем първо в CVSS3. Има три групи метрики. Основната base, а temporal и environmental. Base matric това е характеристиката на улазимостта, такава каквато е самата природа на тази уяазимост. А тя сама по себе си не се изменя, въпреки че нали с времето може примерно да има публичен експлойд или а може да има информация за това как може да проверим променим конфигурацията на нашата система дори без да сме почнали така че да нали намалим последствията

1:36:32↗тая уяазимост в основната оценка в беe score гледаме самата а уязимост и тук се предполага най-лошия а най-лошия сценарии. Temporal score включва неща от рода на има ли а има ли е exploй кой код, който да е пуснат, а доколко сме всъщност уверени, че такаваст наистина съществува? Без кора вече ги ги предполагат тия неща, че че имат гледаме лазимостта, все едно има публичен експлоит код за нея. От тази гледна точка temper score може само да намали серизността назимостта, като предполага, че няма exploit cд или този доклад не е съвсем а точен. Environmental а групата може да ни покаже как малко по-конкретно тази лъзимост се съотнася към дадена организация или дадена среда. Аа примерно ако имат, ако имат някакъв, това може да помогне. А както пък да е една организация confidentiшиity иct може да е по-чувствителна, отколкото за друга организация. Това донякъде ни позволява

1:37:47↗да направим нещо като риск, но пак това не е не е бизнес риск в смисъл на риск мениджмънт. Това е техническата характеристика и съответно environmental score може да е повече или по-малко от а от B score. Метриките а са осем на брой да ги пробря. А осем на брой, но най-общо са разделени в две групи. Exployitability. Колко е лесно или колко е трудно да атакуваме тази уязимост и импакт. колко малко или колко голямо а големи са последствията от атакуването на тази лъзимост. Разликата от CVSS3 до CVSS4 attack complexity се разделя на две категории. Attack complexity attack requirements. А user interaction от required по всички тези разбира се ще минем. Това са само на високо ниво какви какви точно са разликите и scope, ако има scope change ще разделяме системите. В CVSS 3 имаме за confidentiшиity integrity availability а едни метрики в CVSS4 може да ги разделим на на две части. Основните

1:39:09↗метрики а атак вектор откъде може да бъде изпълнена атаката. Тук имаме четири възможни стойности по мрежата. Това са уеб атаките. Със сигурност влизат а в тази категория. Adjacent локална мрежа физически или логически. Физическите примери са върху протокол, който протоколите и Bluetooth, и Wi-Fi, тъй като са въз основа на радиовълни, имат някаква физическа ограниченост, докато логическите аналогическите протоколи като ARP, като DHCP, а те може да нямат физически а физическо измерение, да имат логическо от гледна точка на на самата мрежа.

1:39:56↗local а attack vector local това са улаязимости, които не са свързани с а с мрежата. Примери за такива уязвимости са, ако имаме уязвимост в заключения екран, тоест ако имаме една машина, която е със заключен екран, обаче ако въведем примерно 1000 знака и натиснем enter и то ни пусне да да влезем вътре, тогава вече а е пример заvector local. привлеч също влиза в атак Vctor Local и разбира се има и чисто а чисто физически а векторна атака, ако сме ако сме близо до хардуера. А пример, който ми дойде на ум за такъв видка, представете си на на метрото машинките, където трябва да сканираме. Ако примерно беше случая, което не знам дали е така и предполагам, че не е, не не съветваме да пробвате, но представете си, че минете с един голям магнит през тая машинка и тя ви пусне. Ей, това е пример закрфиical.

1:41:04↗Следващата метрика attack complexity. Дали има допълнителни изисквания, които биха могли да са извън контрола на атакуващия? Това не е колко сложен експлойта. Това не е дали на 10 човека в едно мазе им е трябвало три месеца да измислят как да направят експлойта. Това е по-скоро дали ако напише, нали тия 10 човека три месеца са работили и са написали един експлойт, дали ако го дадат на един петокласник, той ще може да счупи нещо с него. В общи линии е това дали има допълнителни а условия, които трябва да бъдат изпълнени. Две възможни стойности имаме тук. Low и high. Low нямаме допълнителни условия. Повечето уеб атаки влизат в тази а в тази категория. High има такива допълнителни условия. Не може да бъде просто направена атаката по по всяко време, по което искаме. А може да да има нужда да знаем някаква много специална информация. Тази информация, информация, която не

1:42:08↗може да бъде получена от просто познаване на системата по-добре. Може да е някакъв ключ, някаква тайна, а може и да е сценарий от рода на in the middle или някакъв вид кодиш, който трябва да бъде спечелен. Тогава бихме имали атакти high. А, както казахме по-рано, в CVSS4 тази категория се разцепва на две. Attack complexity и attack requirements. Attack complexity са специфични механизми, които чиято цел е изрично да да са secкюрити механизми, докато attack requirements е нещо, което няма само по себе си не предполага, че трябва да е securриity aspect и то е main the middle условия за изпълняване на възлността. Следваща метрика privileges required. Откъде трябва да почне атакуващия? Какви права са му необходими? Три възможни стойности. N всеки може да го изпълни без да е потребител в системата. Пример затова искам инжекция на логин страницата. Low атакуващият трябва да е потребител в

1:43:21↗системата, но може да е обикновен потребител. Няма нужда да е някакъв специализиран потребител. А пример за това са само да хна мишката.

1:43:35↗Пример за това, ако един потребител може по някакъв начин да получи достъп до adminн панела, local privileg escalation, а или един потребител да променя данни на друг потребител. И сценария, който е най-специфичен може би тук, хай. Ако за да постигнем атаката, трябва вече да имаме някакви по-сериозни а привилегии. Като нещо, което е много важно за CVSS е, че CVSS мери само нещата, които постигаме допълнително чрез уязимостта. Няма смисъл да оценяваме изречение от рода на администраторски потребител може да прави администраторски неща. Тоя ясно, това е ролята. Или пък ако успеем да откраднем сесията на администратора, ще бъдем администратори. Това също е Това са също е ясно. Въпросът е как открадваме сесията.

1:44:31↗А на пръв поглед това действително е малко по-рядък случай, който се случва с узимусите, но има има такива сценарии. User interaction. Необходимо ли е потребител на системата или наша жертва да направи нещо изрично, за да за да може да постигнем атаката? А две възможни стойности поне в CVSS3. Първият сценарий не е необходимо примера SQ инжекцията на логин страницата. просто си влиза. А или required това са случаите, когато а най-често случаите, когато имаме някаква някаква жертва, пращаме а по имейл или по някакъв друг начин или зловреден линк или злоувреден файл, потребителят трябва да го отвори, да го изпълни и чак тогава атаката се случва.

1:45:26↗Разгледахме exploitability, колко лесно или колко трудно се случва атаката. Сега да погледнем какви са последствията от от атаката. Първата метрика е скоп дали системата, която атакуваме е същата система като тази, върху която ще бъдат последствията. Две възможни стойности. Ако нямаме scope change, тоест ако оставаме в същата система, а примерно да видим какви са потребителите на на система, ако това не се е предполагало да е възможно или пък да можем да изпълним някакви действия в системата без да сме без да сме се логнали, а пък се е предполагало, че трябва да бъдем логнати. Scope change. Най най-лесните за разбиране примери са контейнер или VMS. Тръгваме от виртуална машина поради уязимост в хипервайзора излизаме на хоста. А, но дори и cross с scриptтинг, ситуация, в която уязвимостта се намира в уеб приложението, което атакуваме, но в крайна сметка крайната жертва е

1:46:38↗клиентският браузър, върху който се изпълнява кода. Това също е пример за scope change ca confidentiшиity integrity availability по едно изречение съвсем набързо за тея трите свойства confidentiшити означава е свойството което ни дава възможност ни гарантира това че атакуващ не може да прочете данните интегрити че не може да промени данните алабилитиity е свойство че атакуващ не може да повлияе на услугата не може да спре услугата да бъде да бъде доставена на потребителите. Отново мерим само това, което се постига благодарение назимостта и това, което така в разумен мащаб се очаква. Тоест, а ако ние сме от гледна точка на penнеation тест или бъг баoundти и видим, че някъде ползват а несигурен несигурни крипитографски алгоритми,

1:47:50↗ако нали си направим анализа и установим, че че това действително е проблем, не е необходимо да направим proof of concept, ако вече знаем със сигурност, че има определени атаки срещу тия аа срещу тия протоколи. Примерно, ако знаем, че изчислителната цена за това да направим криптографската атака струва, да речем, $10 000, не е нужно да я правим, но целенасочен атакуващ с възможности естествено би го направил. Така че това е сценарият, в който е reasonably expected, а въпреки че може да не го покаже и това си е легитимно. Разбира се, клиентът би искал да получи of concept, би искал да виде демонстрация на това. Ако е готов да ги плати тия пари, няма проблем. Ще приготвим и демонстрация. Аа трите възможни стойности за за CIA импакт, разбира се, появата възможност. Няма няма никакъв импакт за която и да е от тия стойности. Това е очевидно. някакъв частичен а частичен

1:48:57↗импакт върху конфидентиity може атакуващ може да прочете някакви данни обаче или няма контрол върху това какви са данните или това е някакво много ограничено а количество или тип данни същото е за интегрити за valability а възможностите са или системата да стане малко по-бавна performance impact или частичен А частични последствия, обаче атакуващият не може напълно да спре системата или не може да спре важни части от системата. High за confidentity или integrity или всички данни или много чувствителни данни. Примерно ако вземем а интегрити уязимост, която може да промени профилната снимка на друг потребител. Ние сме атакуваш, може да променим профилната снимка на някакъв потребител. Странно е, не е не е чудесно, ама integrity а integrity low, негрити high. Обаче ако може да потребим, а ако може да променим паролата на тоя потребител, изведнъж това вече почва да има много

1:50:06↗повече значение. Тогава би било вля влязло като integrity high за avilability. А пак разглеждаме два подце сценария. При първия има пълен а пълно въздействие върху наличността на тая система, тоест тя е напълно неналична. Или докато правим атаката, тоест докато примерно изпращаме някакви заявки или пращаме една заявка, някаква логика се чупи, системата умира и дотам. А искам да отбележа всъщност, че за този сценарий асing the attack, това е нещо, което на мен честно казано ми се е струвало много интересно като а пентеester. А това е нещо, което техническите хора и бизнес хората го гледат от две коренно различни гледни точки. А който тук е бил пентестър, може би се се е срещал с това. Техническите хора винаги ще кажат е да ти винаги може да направиш дина сървис, ако пратиш 10терабита мрежова атака. Много ясно, че нали ще счупиш, тоест няма да да го има

1:51:18↗сървис. Еми да, естествено. Обаче ако мога да да направя динав сървис с 1 мегабит секунда от Rasberry от мобилен интернет атака и вашата услуга я няма, значи може би има някакъв проблем. А това обаче бизнес бизнес хората го гледат точно обратно. бизнес хората са о някой някой ще спре бизнеса, не може да обслужваме клиенти. Това е голям проблем. Та та винаги е винаги е много интересно това. Аа освен това обаче availability Impact High може да имаме, ако счупим определена част функционалност на системата, която е важна. Примерно, ако в системата вече не могат да се логват потребители, те са регистрирани, имат си нали стандартно достъп, обаче в момента не могат да се логоват. Това също е а high impact наability и в крайна сметка получаваме сглобявайки всичките метрики получаваме а някаква оценка в този пример са най-лесно за експлоатиране с най-големи а последствия и това е CVSS 10 което е

1:52:22↗critical

1:52:26↗пак разликате от три до четири атак комплексите се разделя на две категории А между другото взема се при тях се взема по няма значение дали и двете са high. Ако едното е high се смята за за high в тези две категории. User interaction required възможност да се разделя на две подчасти passive и active. И при scope changed, ако имаме, ако сме почнали от една система, а в крайна сметка последствията са върху друга система, може отделно да оценяваме последствията в двете системи, което го прави малко по-лесно за а за боравяне. Иначе официалната спецификация в три казва, че гледаме по-лошо от двете върху а уязвимата и последващата система. Няколко примерчета може да разгледаме. Сега първият пример. А всъщност това беше примерът, който в началото видяхме, че няма CVSS оценка от преди две седмици някъде. Autentenication bypass в Иванти. Напълно произволно съм го избрал. Не е нищо

1:53:39↗спрямо никого. А и да видим какво позволява на атакуващи да достъпи protected resources без да сме се удостоверили. Така, да видим кое коя част от описанието казва всъщност каква е CVSS оценката. Значи Autentication bypass в API. Тук има едно допускане, че е API without proper credential. Значи vector е network без да сме логнати. Значи privileges required nam. За другите две отляво по подразбиране, ако нищо конкретно не пише, решаваме, че са найа лесния вариант. И какво получаваме? Access to protected resources, значи confidentiденity. Не, такова е описанието. Тук всъщност може би е добър момент да отбележим, че за да оценим адекватно една лъзимост, трябва да имаме достатъчно информация за тая лъзимост. А това са някакви публични описания на публични. Бихме могли да ги а да ги преценим донякъде, но дали имаме целия контекст, малко е сложно. Сега тия

1:54:49↗protected resources confidentлите дали е low или дали е high няма как да знаем съвсем. Ама не само, че няма как да знаем. Ами и в официалната в официалната страничка в MVD за таямост също донякъде и те няма как да знаят що. Защото ни стvди казва това е confidentity high. Обаче производителят казвами това е кофиншилиity low. Сега кой е крив, кой е прав? Както казахме, едните имат а стимул да кажат, че е по-зле, другите имат стимул да кажат, че е по-малко зле. Това е една от може би не толкова недостатъците на CV на CVSS като такъв, което което просто отразява различните интереси на различните страни. Добре, още още един пример също не е обвързан целенасочено срещу някого, просто е много добър примерът. Виртуализационен софтуер има use after free в USB контролер злонамерен атакуващ с локални административни права може да експлоатира виртуалната машина да излезе

1:56:08↗от нея и да я спълнява като нейния процес добре да го разбием това малко на части какво имаме като начало local administrative privileges което веднага ни казва vector local prives required high. Защо? Защото трябва да сме администратори. За другите две стойности отляво предполагаме аа възможностите отляво, тоест няма допълнителни изисквания. Къде почваме? Почваме във виртуалната машина. Къде завършваме? Завършваме на хост, където се изпълнява тая виртуална машина. Тоест, имаме scope changed и какво още изпълняваме като VMX процеса, който е привилегирован процес на host. Така че имаме пълен контрол върху системата. Не просто може да четем и да пишем, може просто да цялостно да да я унищожим тая система. Затова и а последствията са highха highха high за кофинтиity, integrity и availability.

1:57:16↗Добре. И сега стигаме до малко по-интерактивната част. Пригответе се с телефоните.

1:57:28↗Пускам това QR-че. Ползваме аа тъй като ползваме безплатната версия на Engrock, ще ви попита дали наистина искате да дойдете тук. Ако смятате, че се доверявате на това нещо, може да натиснете visit.

1:57:47↗>> Затова, затова казвам, ако смятате, че се доверявате. Аа всъщност би трябвало да виждаме три Да. CVSS 1, 2 и 3. Три примерче. Ще разгледаме първото примерче. SAS услуга неудостоверен атакуващ може да види потребителите.

1:58:43↗Ще изчакаме, разбира се, няколко минутки да имаме възможност да оценим.

1:59:50↗Ако си готов да отговориш следващия пример Нари

1:59:57↗няма лошо.

2:00:03↗>> Добре, повечето от половината хора изглежда са успели да дадат своето мнение. Все пак >> не от тези, които са се доверили на QR кода, повечето вече са отговорили на всички въпроси. Ако изведнъж стана тука 5-6 000 потребители, ще почна да се съмнявам.

2:00:27↗Няма проблем.

2:00:33↗Добре. А за да имаме възможност да разгледаме другите примерчета, мисля да продължаваме, освен ако някой много настоява да си помисли още малко.

2:00:46↗Оценката, която аз предлагам за за тази уяазилност, която е напълно измислена, но също така много често се случва, е 5,3 medium, защото какво имаме? Инкеer, тоест най-лесното като предпоставки за атакуване и виждаме списък от потребители. В общия случай това е confidentiшиity low. Пак казвам, има сценарии, има бизнеси, за които това може да не е confidentiшиity low, може да е high, но това е бизнес аспект. Самата самата уязимост е а така доста простичка. Втори сценарий. Пак разглеждаме някакъв SAS, някакво уеб приложение.

2:01:32↗злонамерен потребител, ако знае някакво потребителско ID, което е 80 бита уникално ID, може да им промени паролата на тия потребители, на този потребител.

2:03:23↗Добре, да видим какво предлагам аз като оценка. Аз предлагам 6,8 med. Сега да разгънем малко какво става тука. Имаме SAS, значи говорим си за TAG Vector Network. Знаем, че е потребител системата. Значи privileges required low. Не сме казали, че трябва да е специален потребител. Просто казваме, че трябва да е потребител. Какво също ни трябва? Трябва ни някакво специално познание. Трябва ни някак си да знаем user ID-то. Обаче това user ID е уникално. Тоест то не е примерно потребител 137, че да може да го извъртим. Ами това е някакво някакво 80 битово ID. А така че имаме та complexity high. Ако някак си го я знаем тая информация, примерно от някакъв доклад може да да има другите потребители, които са пипали тоя документ са еди си кой, еди си кой. Та ако някак си я знаем тая информация, можем да им променим паролата. Значи веднага интегритий, обаче това е парола.

2:04:37↗Има има. Щом променяме паролата, правим допускането, че тука няма втори фактор или пък, че може да променим и втория фактор, то буквално означава, че може да превземем тоя потребител. Затова има confidentiшити high. Услугата сама по себе си, нали, не е налична наистина за тоя потребител, но самата услуга като такава е налична. Тя не е не е атакувана. А затова предлагам тази оценка 6,8 medium. И сега в интерес на истината CVSS въпреки че не е а пригоден изрично за това, все пак тоест не му е целта това, все пак позволява да оценяваме аа вериги от уязимости. В тази която гледахме тук, а ще се върна назад. Какво ни трябваше? Трябваше ни User ID и да сме потребители. А в предния сценарий какво имахме? Някой може да показва потребителите. Ако предположим сега, че някой може да показва, нали, освен да вижда самите потребители, вижда и техните ID-та. Ами то тогава може да

2:05:42↗навържем тия двете неща и да получим оценка на цялостната атака. Това е важно. Това е важно, когато а искаме да покажем ние като атакуващи да покажем, че всъщност правим нещо, което е много по-сериозно от просто механичния сбор на двете уязвимости. Съответно пък нали системата, последствията върху системата са също много по-сериозни и в крайна сметка комбинираната а оценка на тая верига от уязимости от medium, от два медиума става хай. Може е сценария от няколко low плюс med да стане high или critical също, но тука какво става? Последствията ги запазваме, защото те идват оттука, нали, тежките последствия. Това, за което ни помага първата уязимост е да свалим атаксиity от high на low, защото всеки вече може да видите user ID-та.

2:06:40↗И сега още едно последно примерче.

2:08:43↗Добре. Да видим какви са оценките. Това всъщност е истинска узимост от 23 година. Има се CV-то, ако нещо имате коментари към оценката, към нист. Ам какво имаме тук? Linux. Добре. Ам unprivilaged local user. Това е първото нещо, което имаме за това как може да атакуваместта. Attack vector local. То си го пише local user unpriviled. Значи privileges required low. Нещо друго по-специално като изискване няма. Score unchanged. А, тоест какво постигаме? Постигаме аа can obtain root privileges. Root privileges веднага означава тука сме high. Scope е unchange, защото оставаме нямаме друга система. Оставаме си там. Local privilage escalation. от обикновен потребител станаме администратор. И всъщност това беше последното примерче, което да комплекси защо >> комплекси защо е lлоow? Има ли нещо, което тук даправи >> да предполага, че е complexity high?

2:10:04↗>> Да, да. Но също така тук няма нищо, което да предполага, че че атаката е сложна. Ако ако атаката беше нещо от рода на

2:10:22↗някакви определени адреси в паметта, са се озовали на в конкретения регион, което примерно е, да кажем вероятност едно на 100, като бутнем системата да са точно в това място и само нали тогава може да се случи атаката, тогава веднага щяхме да сложим атам high. Но тук няма никакви допълнителни изисквания. Предполага се, че а примерно тия бачст, ако атакуващият може да си ги пусне да си да си ги направи сам, няма а attack complexity high. Аack complexity е само за неща, които са отвъд това, което се предполага, че има атакуващия като възможности. А нали въпреки че in the midle в някакъв смисъл нали то си е атама дали във всеки един момент ще може да направиш the midle атака е отвъд специфичността на саматазимост. Окей. Извинявай. Окей. Сега имаме, ако нямаме информация за тоя в момента, освен че той е Linux, а защо нямаме change call, ако си казваме, че е reasonable сценария, защото reas в

2:11:39↗сценария на че аз ако стана ще намеря кренъли за някаква за някакви други ресурси, които са отвъд тоя девай заради превилически. Добре. А защото правиш допълнителни предположения за контекста, в който се намира тая система, а не за самата система. >> Аз тук мога малко да се екстенд на въпроса. Мислех да ти го задавам извън. >> Да, да, разбира се. А как някакви типс дали може да ни дадеш? Примерно ние сме венъри на софтуер. Не, а голяма част от софтуера ни го ползват директно както е потребителите. Те го интегрират в техните системи. Сега ние като спорваме, а обикновено се опитваме да измислим някаква хипотеза, най-лошата хипотеза възможна, която може да постигнем с нашия софтуер. То ние трябва да си мислим за някакви хипотетични апликейшъни, нали, защото ако имаш един уеб компонент, ти не знаеш как правиш. Обаче, ако някой може да направи XS през твоя компонент и то най-лошият сценарий,

2:13:01↗нали, има някакъв магически апкейшън там някъде, някой кликджак да мине през твоя компонент, вземе му сесията, отива да те видя дали измине и всичко кайно. Да, ей тая работа, когато нямаш допълнителна информация, как решаваш къде са границите на най-лошото? >> Да, значи доста е адекватен въпросът и честно казано дори и в дори и в CVSS спецификациите, даже днеска ги гледах, има примери аа, които са разгънати и ако отворим CVSS3, примерите има буквално два примера, свързани с Chrome. Аа единият е атакуваме браузъра през уеб страница и всъщност в крайна сметка излизаме от браузъра и може да изпълняваме код на машината и там го дават като scope change. Другият пример. Атакуваме компонент в браузъра, който е PDF, свързан с PDF. А туку имаме компонент в браузъра, обаче не излизаме, нали, пак изпълняваме неща като б като браузъра, обаче тогава не му дават спчейнта, нали.

2:14:18↗Това е в официалната спецификация. И сега отговорът е малко е сложно. Аз затова в моя затова в моя в моя отбор сме имали часове общо, в които обсъждаме сега това тука как ще го оценяваме. Да, затова, защото понякога като почнем да оценяваме има една така страшна осцилация, нали, в възможно някакъв много такъв ник спорт някакъв брутално голям, който изглежда просто супер нари или >> значи това, което това, което бих казал е гледайте как е предвидено да се ползва а тоя продукт, щото да кажем, Ако а имате а някаква система, която се връзва с някакъвти провайр, там примерно Microsoft, Google, каквото и да е. И ако в тая система решите, че за secкюрити цели ще ползвате някакво поле на потребителя, дали той има достъп до него или не, май така, защото е така сте решили да го имплементирате и после се оказва, че той е потребител, той може сам да си го сменя това поле и да от достъп до

2:15:37↗аа source контрола да има достъп дойрол системите, само защото в потребителя му някъде, където има домашния му адрес, телефона на му има и достъп за какво ще се ползва. Сега в тоя сценарий не може да обвините доставчика, нали, че че позволява това. Дори дори да предположим, че доставчикът би трябвало само администраторите да имат достъп до това поле, неговата улазимостче е а интегрити някакъв low impact, защото някой може да го променя, а пък не се е предполагал, че трябва да може. Ама това, че вие сте го ползвали за секюрити критични а цели, това нещо вече е малко ваш проблем. В смисъл, а на тоя, който ги решава тия неща, но все пак а уязиемостта на самия доставчик в тоя сценарий, обикновеният потребител да не да трябва да не може да го сменя, пък да е успял да го смени, си е само integrity low. Тоест нали трябва да се гледа и какво се предполага, че че че трябва да прави тая

2:16:36↗система. А това, че това е brc abstraction в крайна сметка какво правят потребителите с нашата библиотека.

2:16:49↗Достига >> да reasonable е малко по-осто като поне.

2:16:59↗Добре, това беше последното примерче. Ако има някакви въпросчета други, ще се радвам също да отговоря.

2:17:13↗въпроси, >> ако можеш. Благодаря много първо за много изчерпателната аа презентация, ако може да се върнеш на слайда с аа чейна от двете уязвимости. Аа в скора на chйна защо атак complexity >> защо паднал ли? Да сме помнили уяазимостите. Тази уезмост тук, тя беше вторият пример е, ако някак си знаем user ID на някого, може да му сменим паролата. Първата уязвимост беше, че може да видим какви потребители има в системата и ги разгънахме малко, освен самите потребителски имена и техните ID-та. Тоест вече изискването за ID-тата от това тука трябва ни ID-та. стига до това най-вляво та complexity low, защото всеки може да ги види тия ID-та. Така че предпоставката да намерим ID вече идва почти на готово, защото има друга уязмостя, която не ги дава тия ID-Да. >> А тоест, тоест ти приемаш, че при експлоатирането на първата ти виждаш така >> тези. Точно така. Да, това е нали така

2:18:41↗навързваме двете уязвимости заедно. От първата си взимаме адитата и с вторатамост а атакуваме тези потребители. >> Добре.

2:18:54↗>> Моля. >> Точно така. Без без никакви допълнителни изисквания. Затова и на тоест ние без привилегия ги взимаме, но после за да изпълним атаката със смяната на паролата, все пак трябва да сме ни трябват тия привилегии за >> Да. Зарайдитата няма нужда от никакви привилегии. >> Добре. А ето тука още едно въпросче.

2:19:23↗Каква ти е чисто субективната оценка за числовото изражение на скора? Добре ли е, че има числово изражение или по-скоро смяташ, че някой път пречи? >> Това, което пречи е, когато аа това ще се опитам да не ги обиждам, обаче има хора, които казват не, не, не може да има едикви уязвимости с еди какво, повече или по-малко. А, което разбира се има смисъл в крайна сметка, ако а ако гледаме две уязвимости, едно, ако гледаме 200 уязвимости, трябва да почнем отнякъде. И а там действително се случва това, че а в нашия софтуер ползваме библиотека, която има улазимост, която е примерно high и съответно там compliance и всички а други хора казват нали това е голям проблем и то наистина може да е проблем, обаче може да е случаят такъв, че а ние да не използваме уязвимата част от тая библиотека, което вече нали за нас може да е fse positтив. Сега имаме тая библиотека, имаме уязвимата версия на тая

2:20:34↗библиотека, ама ние не ползваме уязвимата функционалност, така че за нас е нали environmental score в нашия контекст е нула. А или обратното, тоест не обратното, друг друг друг тип нещо. да използваме уязвимия компонент, обаче примерно аа имаме някакъв рейлимит нашата система, така че тя не може да бъде експлоатирана тая или поне става много много малка вероятността. В крайна сметка, нали, към въпроса числовото изражение. Ами има смисъл часовото изражение. Аа според мен е добре. Истината е, че нали от lлоow до lлоу ей това е 5 и3, другото е 6 и8. По принцип на хората им е се тая. Въпросът е каква е каква е категорията, дали е low, medium и high. Ам, между 5 и3 и 6 и 8 не вярвам някой да да има значение. Нито тия, дето ходят за бъгбаутита, нито тея, дето плащат бъгбаунтитата, нитос хората правят разлика в рамките на категорията. Но според мене има има полза от

2:21:46↗числовото има полза от чисовото изражение, защото може да боравиш по някакъв начин с тия неща. Дали има смисъл как боравиш с тях е малко контекстно зависимо, но да мисля, че има смисъл.

2:22:03↗Супер беше презентацията. И аз имам един въпрос пак върху чейна. Хм. Ако трябваше да го опишеш в репорт, как точно щеше да го направиш? Тоест самият chенй щеше ли да е като допълнително vulnerability или по-скоро а това vulnerability с high complexityто да го репортнеш като l като реферираш предишното vulnerability.

2:22:31↗Значи тук може би зависи какъв ти е контекстът, дали си бъгбаути или пентест. Що? Защото в пентест намериш ли намериш, на те вече се плаща да хо да си а заслужиш това, за което са ти платили, но нямаш пряк пряк финансов стимул за това нещо, докато в Buny има. А и в Bug Boути а също зависи дали минаваш през платформа или директно го докладваш на някого. Аз съм чел доклади, в които атакуваш казва, нали там баутир казва аз намерих medium и отсреща са нали компанията, за която не се сещам конкретен пример, но но съм чел такива доклади компанията явно нали са така доста добро намерени и съвестни, абе като цяло готини хора и казватми ти си намерил medium, обаче нали ние установихме, че може да се навържат други неща и да стане хай, затова ще платим хай, нали това е добронамерено. ност от тяхна страна. Ам,

2:23:40↗най-вероятно не е било, но в крайна сметка, ако съм ако съм в контекста на бъг баoти и по някакъв начин все пак съм ограничен и от а и от контекста, в който начина, по който ги пращам нещата, Мм може и да пусна веригата с разбивка надолу. Първо всички програми, които съм виждал, които са нали сериозни програми дават нали нескалира линейно. Две medium са по-малко от едно хай, нали? Тоест едно хай е повече от две medium и едно критикъл е повече от две хай. А обикновено така че искаш да си гарантираш, че че ще ти платят за хая, защото си го намерил. Освен това има и и някакъв друг проблем е, че едно от тия двете може някой друг да го е докладвал, а цялата верга може никой да не е докладвал, но там вече е нали така стратегия как точно да подходиш като като баутихънтър. Мерси. Добре, още въпроси.

2:25:04↗Дали има причина да разглеждаме само бе score?

2:25:11↗Не трябва да разглеждаме само base score.

2:25:18↗Не. В интерес на истината temporal score има много смисъл. А и примерът, в който има много смисъл, всъщност е ясно видим и тук. Аз лично как бих подходил към узима, която има а privileges required low, обаче това е система, която е отворена за всеки. Примерно всеки може да се регистрира в XYZ, а Google, Microsoft, там и да е компания, всеки може да си направи потребител и тогава environmental score. Технически трябва да си потребител, ама environmental score на тая лазимост ще е privileges required n, защото всеки може да да почне, но ако системата е затворена, ако е не знам нашия fiw или нещо такова, там не се предполага, че всеки е потребител. Там prived low си е истинско условие, което не е не е много важно. А, така че в такъв случай определено бих ползвал environmental скоро.

2:26:27↗Добре, още въпроси сега или никога? Добре, благодаря ти много. >> Добре.

2:26:40↗>> Та това беше последната сесия за тази вечер. Супер много се радвам, че дойдохте. Благодаря ви, че дойдохте. Кажете на вашите приятели да дойдат следващия път. Елате и вие. И сега може да си ходите, освен ако не харесвате пица и да си говорите с готини хора на седмия етаж. Моля ви се, елате, защото после трябва да нося тая пица вкъщи. Децата ще ядат една седмица пица. Много са щастливи, ама жена ми ще ме убие. Чао.