Множество наскоро разкрити уязвимости в OWASP ModSecurity биха могли да позволят на атакуващи да заобиколят защитите на защитните стени за уеб приложения (WAF), чрез експлоатиране на разлики в парсването, деформирани входни данни, грешки при трансформации и ограничения на ресурсите.

Недостатъците засягат функции, които обикновено се използват за инспекция на HTTP заявки и отговори, което поражда притеснения за организациите, разчитащи на ModSecurity правила за откриване на зловреден код.

Един от най-сериозните проблеми, проследяван като GHSA-5pww-8rfg-9crf, включва параметъра filename* от RFC 2231 при качване на файлове чрез multipart HTTP.

ModSecurity прилага строги правила за валидация на имената на файлове, но бекенд приложенията, съвместими с RFC и написани на Go, Python, Node.js или Java, могат да интерпретират кодираните стойности на filename* по различен начин. Атакуващ би могъл да създаде заявка за качване на файл, която бекендът приема, докато избягва правилата за проверка на името на файла в ModSecurity.

Това разминаване може да създаде опасна празнина между защитната стена и защитено приложение. Правилата за сигурност могат да блокират съмнителни разширения, низове за обхождане на директории (path traversal) или злонамерени имена на файлове в стандартните полета.

Междувременно бекендът обработва кодираната според RFC 2231 стойност. Проблемът е оценен със висока степен на опасност (High), тъй като може да позволи качването на злонамерен файл или да заобиколи контролите за сигурност, проектирани около валидацията на имена на файлове при multipart качвания.

Уязвимости в ModSecurity

Друга уязвимост със средна степен на опасност (Moderate), GHSA-4j47-8qcr-jf59, засяга трансформацията t:base64DecodeExt. Когато трансформацията срещне деформирана Base64 група за запълване (padding group), тя мълчаливо отхвърля целия декодиран резултат.

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

Атакуващите често кодират съдържание за SQL инжекции, cross-site scripting (XSS), инжектиране на команди или уеб шелове (web shell), за да избягват филтрирането, базирано на сигнатури.

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

Трети недостатък, GHSA-qrch-pjfr-9g47, засяга трансформацията removeComments. Функцията е предназначена да премахва коментари от входните данни, преди да бъдат проверени спрямо правилата за сигурност.

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

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

Допълнителните бюлетини за сигурност включват заобикаляне на инспекцията на тялото на HTTP отговора с висока степен на опасност, недостатък при дерефериране на указател в процесора на тялото на XML заявки, слабости при парсването на multipart form-data и проблем, при който грешките от ограничението на съвпадения при PCRE2 @rxGlobal се третират като липса на съвпадение.

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

Администраторите трябва да прегледат съответните бележки към новата версия на ModSecurity и бюлетините за сигурност, да инсталират корекции за сигурност веднага щом са налични и да тестват правилата си срещу кодиран, деформиран, multipart съдържащ зловреден код или такъв, скрит с коментари. Организациите трябва също така да използват многослойна защита, вместо да разчитат единствено на WAF сигнатури за сигурността на приложенията си.