Автоматизирана система, наречена NOVA, прочете изходния код на 3 915 проекта с отворен код за два месеца и откри 14 090 уязвимости, всяка от които потвърдена чрез тръбопровода за валидиране на системата.

Изследователи на уязвимости от Unit 42 на Palo Alto Networks изградиха системата и след това сравниха резултатите ѝ с публичните регистри. Само 85 констатации съвпадат с вече документирани такива, като повечето от тях са публикувани две до осем седмици след като NOVA ги е открила.

Броят не е частта, която трябва да ви тревожи. Машините откриват грешки на едро от 2016 г., когато стартира OSS-Fuzz на Google. До август 2023 г. той помогна за идентифицирането и отстраняването на повечето от 10 000 недостатъка в 1 000 проекта. Това, което се промени, е видът на грешката. Само 8% от констатациите на NOVA попадат в категориите, с които фазърите (fuzzers) се справят от години. Останалите 92% са грешки, които никога не се изявяват със срив на системата.

Фазърите откриват сривове. Това откри нарушени права за достъп.

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

„В таксономията, която използвахме за констатациите ни от водещи модели на изкуствен интелект, най-близката категория – проблемите с паметта и изчисленията – представляваше 557 констатации или само 4,0% от общия брой. Дори ако се добавят проблемите с управлението на ресурсите и отказа на услуга, тези удобни за фазване категории възлизат на 1 121 констатации – все още само 8,0%“, обясни Ксу Зоу, старши вицепрезидент на Cloud Delivered Security Services в Palo Alto Networks.

Всичко останало идва от категории, в които нищо видимо не се чупи. Недостатъци в контрола на достъпа, където софтуерът проверява кой сте, но не и дали имате право да правите това, което сте поискали. Преминаване по пътя (path traversal), инжектиране на код, замърсяване на прототипи (prototype pollution), подправяне на заявки от страна на сървъра (SSRF). Улавянето на тези проблеми изисква логическо осмисляне на това, което кодът е трябвало да направи.

Комбинацията варира в зависимост от езика по начини, които проследяват как е изградена всяка екосистема. Констатациите за C и C++ се групират в безопасността на паметта. Констатациите за JavaScript и TypeScript се групират в инжектиране, замърсяване на прототипи и SSRF. В констатациите за PHP, Java и Python доминира нарушената проверка на достъпа – повтарящата се слабост на приложения, които трябва да проследяват много видове потребители.

Типът уязвимост по езици показва, че всяка екосистема има различен профил на слабостите.

Един дефект в зависимост, четири хиляди излагания на риск

В изследваните екосистеми от пакети, тръбопроводът е произвел 5 421 констатации за веригата за доставки. От тях 1 280 са дефекти в самите пакети със зависимости. Останалите 4 141 са последващи излагания на риск (downstream exposures) – случаи, в които кодът на дадено приложение достига до уязвима зависимост.

Това съотношение е числото, на което трябва да се обърне внимание: приблизително 1 300 дефекта в пакети са генерирали повече от 4 000 последващи излагания на риск. Като 2 776 от тях са валидирани с работещо доказателство за концепцията (PoC), стартирано от крайното приложение, а не просто изведени от графика на зависимостите. Инструментите за анализ на състава на софтуера (SCA) сигнализират за наличието на уязвима версия. Това изследване установи, че уязвимостта може да бъде задействана от мястото, където действително се намира приложението.

Разликата във времето между корекцията на сигурността и експлойта е целият проблем

„Нашият опит с NOVA подчертава ясна структурна промяна: прозорецът за инсталиране на корекции за сигурност се срина“, пише Зоу. Средното време в индустрията за внедряване на традиционна корекция по преценка на неговия екип е 55 дни.

Атакуващият не се нуждае от най-новия и модерен AI модел, за да се възползва от всичко това. След като корекцията бъде доставена, разликата (diff) между старата и новата версия стеснява търсенето до шепа редове, а работата в обратна посока от корекцията за сигурност до експлойта е много по-евтин проблем от намирането на уязвимостта от нулата. По-бързото откриване означава повече корекции за сигурност, а повечето корекции означават повече стартови точки за киберпрестъпниците.

Unit 42 казва, че работи с разработчици на софтуер с отворен код и с центрове за обмен на информация за уязвимости, назовавайки Lightwell и Akrites, за да коригира уязвимостите при първоизточника. Това, което не е направила, е да назове нито един засегнат проект, да публикува CVE идентификатор или да каже кога някоя от 14 090-те уязвимости е била докладвана на хората, които поддържат кода.

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

Сериозността зависи от това коя скала използвате. Според CVSS 3.1 малко над една четвърт от констатациите са оценени като високи или критични. Според CVSS 4.0 – малко под две пети. Едни и същи грешки, различна аритметика.