Безпека не починається з розкриття CVE

Дозвольте мені розповісти вам історію Існує впорядкована, майже академічна версія того, як має працювати безпека програмного забезпечення. Вона з'являється в конференціях, документах про відповідність та в веселих діаграмах, побачених на маркетингових слайдах. Дослідник знаходить помилку, тихо (і професійно) повідомляє про неї вгору, вгору виправляє її, призначається CVE, утримувачі внизу витягують виправлення, сканери повідомляють, захисники виправляють, і світ залишається в основному в порядку. Якби це дійсно було, як працювали речі, я б не писав про виправлення, які існують тільки в подальшому потоці, тихі патчі або проблеми безпеки, які існують в одному місці і зникають в іншому. І кожен має знати. турбує Що ви дізнаєтеся в цій статті Інверсія часової лінії безпеки: як розкриття CVE не є справжнім початком часової лінії безпеки. Результати безпеки: Чому рішення про регулярне обслуговування, а не швидкість реакції або інструменти, визначають результати безпеки. Помилкові показники: чому оцінки CVE, сканери та терміни дотримання не є ефективними системами раннього попередження. Викривлення вразливості: як вбудовані, сформовані та кінцеві компоненти приховують видимість уразливостей та відповідальності. Необхідні зміни: Управління та зміни життєвого циклу необхідні для того, щоб уникнути структурного запізнення до «тихих» вразливостей. У лютому 2025 року Apache Tomcat випустив набір Вони прибули без термінів, без коментарів і без такого типу шуму, який може супроводжувати значні інциденти безпеки. Рутина Для більшості команд не було безпосередньої причини розглядати ці випуски по-різному від інших оновлень технічного обслуговування. Ніщо не здавалося порушеним. Ніщо не здавалося порушеним. Не було ідентифікатора вразливості, на який можна було реагувати. Через кілька тижнів ті самі випуски стали центром надзвичайної ситуації з безпекою. Коли CVE-2025-24813 був оприлюднений у березні, уразливий шлях коду вже був виявлений, виправлений і відправлений через підтримувані філії Tomcat. Виправлення існувало до того, як проблема мала назву. Для всіх інших це стало неприємним сюрпризом: оцінка CVSS в 9,8 - це відмінний спосіб почати свій день. Почуйтеся вільними, щоб переглянути деталі CVE тут Ми розглянемо зміст пізніше, оскільки те, що записується і хто записує його, є частиною цієї історії.Горі технічні подробиці CVE в основному не мають значення.Важливою особливістю є те, що цей CVE не відбувається в Мода – вона повинна бути дозволена. https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Дефолт https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Ця послідовність подій допоможе нам зрозуміти, як CVE можуть розвиватися і як це може вплинути на споживачів. Інверсія часової лінії безпеки Цю інверсію легко пропустити, якщо подивитися тільки на дати розкриття. Терміни безпеки зазвичай розповідаються так, ніби вони починаються, коли CVE публікується. Коли ракета на пусковій платформі починає рахувати вниз, ми бачимо, що двигуни запускаються, перш ніж ракета покидає землю. Це такий зразок, який ми бачимо з CVEs. У цьому випадку команда безпеки Tomcat слідувала шаблону, який є цілком нормальним для довготривалої відкрито-джерелової інфраструктури. Прибув приватний звіт. Проблема була досліджена. Виправка була розроблена і відправлена. Тихо, і все до того, як «ракета» залишила платформу. Намір був не секретність, а стримування: мета полягає в тому, щоб зменшити вікно, під час якого захисники не мають життєздатної відповіді. Навички vs. Hype Цей підхід добре працює для організацій, які розглядають точкові випуски як щось, що слід застосувати. І рутинно Ці команди оновилися, не знаючи чому, і до того моменту, коли уразливість була публічно обговорена, вони вже були захищені. Для організацій, які покладаються на розкриття як виклик для дій, березень відчував себе нульовим днем.Вразливість з'явилася повністю сформована, повна результатів серйозності, претензій на експлуатацію і т. д. Ззовні здалося, що всі стикалися з одним і тим же ризиком одночасно. Дві команди могли керувати однаковими версіями Tomcat в січні і в кінцевому підсумку опинилися в дуже різних позиціях до середини березня.Одна була ізольована, інша викрита. Це було Звичка Помилкове припущення про гучні попередження Існує наполеглива припущення в багатьох інженерних організаціях, що серйозні проблеми безпеки будуть оголошувати себе достатньо гучно, щоб вимагати уваги. Ця припущення стає все більш ненадійною. У цьому випадку, найважливіший показник був невіддільним від рутинного обслуговування. Вхід changelog. Версійний удар. Випуск, який не відчував термінів, тому що нічого ще не говорив нікому, що це повинно бути. Як тільки CVE був опублікований, звичайний розповідь взяв на себе. вразливість отримала ім'я, оцінку і цільову аудиторію. Обговорення щодо серйозності, експлуатованості та конфігурації почалося відразу. Пріоритети змін перед історіями Це спокуса розглядати ті випуски лютого як щасливий час. Вони не були. Вони були просто результатом процесу, який пріоритетує виправлення коду над керуванням сприйняттям. Вони структуровані так, щоб відповідати на історії, а не на зміни, на заяви, а не на дифференціації. Невідомо До того часу, коли ширша екосистема почала обговорювати наслідки CVE-2025-24813, технічний результат вже був встановлений. Як це CVE (і, щоб бути чесним, переважна більшість всіх CVE) розгорнулася по всьому світу було зіткненням інтерпретацій, оцінок і зобов'язань Саме в цьому випадку дослідження стає цікавим і робить такий великий зразок. Ось головний термін Важливі елементи обертаються навколо інформації про CVE та CPE NVD. . https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Я повинен підкреслити, що це не має на увазі, щоб припустити, що щось несприятливе сталося. Я повинен підкреслити, що це не має на увазі, щоб припустити, що щось несприятливе сталося. 13 січня 2025 р. Уразливість повідомляється приватно Команда безпеки Apache Tomcat отримує приватний звіт про уразливість, що включає часткові запити HTTP PUT та сервет файлу за замовчуванням. 24 січня 2025 року: Fix Committed. Комітет записані, і, як зазвичай і очікується, немає ніяких ознак того, що він виправляє недолік безпеки. пов'язаний запит на витяг має назву "Підвищення життєвого циклу тимчасових файлів, використовуваних частковим PUT" https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c https://github.com/apache/tomcat/commit/0a668e0c27f2b7ca0cc7c6eea32253b9b5ecb29c 10 лютого 2025 року: Fix випущено тихо. Apache тихо випускає Tomcat 9.0.99, 10.1.35 і 11.0.3 з включеним виправленням. Це за місяць до публічного розголошення. 10 березня 2025: CVE-2025-24813 Публічно розкрито Зазначимо, що у зв'язку з тим, що виявлені ускладнення можуть бути пов'язані з інфекційними захворюваннями, слід звернути увагу на те, що в результаті виявлення ускладнень, виявлені ускладнення можуть бути пов'язані з інфекційними захворюваннями. ( ) цитати https://nvd.nist.gov/vuln/detail/CVE-2025-24813 https://nvd.nist.gov/vuln/detail/CVE-2025-24813 Ця проблема стосується Apache Tomcat: від 11.0.0-M1 до 11.0.2, від 10.1.0-M1 до 10.1.34, від 9.0.0.M1 до 9.0.98 13-14 березня 2025: початок експлуатації PoC та активних атак Упродовж 30 годин після розкриття, проб-оф-концепції експлуатації публічно випущені. Масове сканування і експлуатації спроби починаються негайно. Метод атаки: завантажити JSP webshell через частковий PUT, триггер через виготовлений JSESSIONID запит. Sources: Sonatype Blog | CyRisk Analysis 17 березня 2025: до запису NVD CVE додається POC-експлойт https://github.com/absholi7ly/POC-CVE-2025-24813/blob/main/README.md 18 березня 2025: перша інформація про CPE додається до CVE Про CPE Це магічна інформація, яка робить CVE в основному машиночитаним. Вона дозволяє автоматизованим споживачам CVE «знати», які версії продукту є вразливими. https://nvd.nist.gov/products/cpe https://nvd.nist.gov/products/cpe На цьому етапі CPE просто відповідає декларації оригінального діапазону версій, яку ви бачили раніше. 19-26 березня 2025: Опубліковано аналіз постачальників безпеки Rapid7, Akamai, Wiz, і Sonatype публікують детальні аналізи. Rapid7 зазначає, що "не потрібно панікувати", тому що широко поширена експлуатація не була підтверджена і деякі з заявлених передумов Apache були переоцінені. Sources: Rapid7 Blog | Akamai Blog | Wiz Analysis 1 квітня 2025 :CISA додає в каталог KEV CVE записує, що CISA додає CVE-2025-24813 до свого каталогу відомих експлуатованих уразливостей, посилаючись на докази активної експлуатації. Федеральним агентствам США було надано термін 22 квітня 2025 року для виправлення. Amazon AWS також випускає ALAS-2025-2812 в той же день. Sources: Keysight Analysis | Amazon Linux Advisories На початку квітня 2025 року: випущені патчі для постачальників підприємств Red Hat, Amazon, SUSE, Atlassian та інші корпоративні постачальники випускають патчі. Більшість підкреслюють, що за замовчуванням конфігурації не є вразливими, оскільки за замовчуванням сервлет є тільки для читання. Sources: Red Hat CVE | Amazon CVE 3 липня 2025 року: підрозділ 42 повідомив про 125 000+ спроб нападу Підрозділ 42 Пало-Альто повідомляє про 125,856 спроби експлуатації, заблокованих тільки в березні 2025 року. Більшість трафіку експлуатації здається "опортуністичним" з використанням публічних PoC з боку акторів з низькою витонченістю. Source: Unit 42 Report Чи ми готові? Ну, для деяких користувачів Tomcat, тих на версіях 9, 10 або 11, все в порядку.У них є виправлення, і поки вони оновлюються, то вони безпечні. 7 серпня 2025 - CVE оновлено "Старіші версії EOL також можуть бути уражені". Через деякі лобіювання під керівництвом HeroDevs, команда Apache додала попередження. Це важливо. Це дуже рідко трапляється, але були інженери в суміші в Apache і в інших місцях, які вважали, що попередження потрібно. CPE був оновлений, але він не отримав ніякої інформації про версії EOL, оскільки не було нічого конкретного, щоб включити. 8 серпня 2025 - CVE Оновлено з додатковою інформацією про версії EOL CVE тепер стверджує: "Наступні версії були EOL на момент створення CVE, але є Відомо, що впливають: 8.5.0 до 8.5.100.” Тепер CVE офіційно застосовується до іншої версії потоку Tomcat. На жаль, CPE не був оновлений. Сьогодні Навіть сьогодні цей CVE не був оновлений, щоб включити інформацію про CPE, яка може допомогти сканеру виявити проблему у версії 8.5. Частина цього може бути пов'язана з характером CVE. Оскільки вразливість можлива тільки при зміні умовної конфігурації. Змінюється Читання = Правда Читати далі про: Фальшиво Це означає, в теорії, експлуатованість залежить від того, що користувач Tomcat може зробити цю зміну. Якщо Tomcat вбудований таким чином, що запобігає зміні цієї конфігурації, то продукт «вбудування» може по праву стверджувати, що вони не є вразливими. Є також багато форків і комерційних варіантів Apache Tomcat. Наприклад, це компонент Spring Boot, і Broadcom Tanzu також вбудовує його. Скільки жирних банок є там, де інформація про компоненти була втрачена, або проект POM був оновлений з моменту доставки? Як поширюється повідомлення Часто гірка правда полягає в тому, що звітування CVE і отримання належної обізнаності правильним людям не вдається. Насправді, чим популярнішим є компонент для вишивки або вбудовування, тим важче може бути досягти тих, хто повинен знати про це.Часто, в спеку моменту, нижчі продавці досягають початкового звіту CVE, але не повертаються для оновлень. ТАНЦУ правильно стверджує, що CVE застосовується до Tanzu і призначає йому свій власний ідентифікатор, TNZ-2025-014. Вони попереджають своїх користувачів про те, що CVE застосовується до версій 9,10 і 11, але потім, як завжди, він стає незручним. "Я не знаю, чи має Tanzu версії з Tomcat 8 або раніше - я припускаю, що вони це роблять. Враховуючи їхню консультацію датується 2025-03-25, задовго до того, як CVE мав додаткову інформацію про версію EOL додано, можна співчувати цій помилці, навіть якщо це може бути великим впливом на старі продукти Tanzu. Сторінка підтримки Are-you-exposed або не Спільний сценарій До моменту, коли CVE-2025-24813 набув назву, оцінку та медіа-цикл, результат вже розходився. Виправлення існувало до CVE. Деякі системи були захищені, перш ніж хтось знав, чому. Ця розбіжність не виникла через обізнаність, інструменти або будь-яку інформацію про загрози. Вона виникла через час, точніше, з припущення, що безпека починається, коли вразливість оголошується, а не коли код тихо змінюється. Те, що наслідувало, було не однією подією, а тривалою каскадою. Текст CVE розвивався. Дані CPE прибули пізно і неповністю. Поради постачальників переглянули сферу застосування. Терміни дотримання затвердили часткову правду в політиці. Оновлення щодо впливу EOL з'явилися місяцями пізніше, після того, як вже було прийнято багато подальших рішень. Ніщо з цього не було шкідливим. Ніщо з цього не було незвичайним. Сучасна екосистема вразливості поводиться, коли вона розглядає розкриття як момент, а не процес. Як Це сталося в січні, лютому, березні, серпні і далі. Залежно від того, де ви сидите і на які сигнали ви покладаєтеся.Некомфортна реальність полягає в тому, що до того часу, коли ширша екосистема закінчила обговорювати серйозність і експлуатованість, технічний результат вже був фіксований. CVE-2025-24813 Як ви повинні реагувати? Що це означає для вас і що робити далі Настільки, наскільки мені не подобається термін «некомфортна правда», це той, який найчастіше використовується в цих обставинах. Таким чином, «неприємний висновок» цього дослідження не полягає в тому, що Це було надзвичайно небезпечно. це те, що нічого про те, як це було повідомлено і управляється було Приймати CVE-2025-24813 Незвичайні взагалі Вразливість не прийшла з будь-яким фанфером. Вона не оголосила себе терміновою. Вона була вирішена, перш ніж вона була названа. Системи, які вижили, зробили це не тому, що вони реагували швидше, а тому, що вони вже вирішили, задовго до того, як вони будуть ставитися до змін. Якщо ваша позиція безпеки залежить від Чому оновлення має значення, перш ніж застосувати його, тоді ви вже працюєте занадто пізно. Знаючи У сучасних екосистемах пояснення слідує за діями, а не навпаки. Що це означає на практиці , розкриття більше не є початком таймеру безпеки. До моменту, коли CVE набуває ім'я, оцінку і, нарешті, термін відповідності, вирішальна технічна робота часто вже відбулася в іншому місці. First Сканери не дають вам передбачення; вони просто говорять вам, що ви запізнилися. Second Бази даних CVE, CPE і каталоги KEV є інструментами координації. Вони допомагають великим екосистемам рухатися разом, коли розповідь стабілізується. Вони не потрапили в вашу кодову базу, ані тоді, коли вони тихо пішли. фактично , «За замовчуванням безпечний» не є стратегією. Third Багато команд заспокоїлися у думці, що ця вразливість вимагає нестандартної конфігурації.Це розрізнення впало в момент, коли вбудовані розподіли, форки та розгортання JAR ввійшли в картину. Якщо ви не можете довести, як компонент конфігурується у виробництві, ви не можете покладатися на попередні припущення безпеки. Звичка перемагає героїв. Різниця між захищеними і викритими системами в цій історії полягала не в інструментах, розвідці загроз або швидкості реакції. Finally Що ви повинні зробити далі Не чекайте, поки наступний CVE перевірить ці припущення. Визначивши джерела ваших рішень щодо оновлення. Start Якщо оновлення надають пріоритет тільки після того, як вразливість названа, оцінена або призначена, це проблема управління та контролю, а не технічна проблема. Рішення приймаються, а не які інструменти консультуються. Коли Як ви ставитеся до «тихого» звільнення Examine Запитайте, які пункти випуску у вашому середовищі будуть застосовані автоматично, і які будуть відкладені до виправданого. Відповідальність за кінцеві компоненти експлицитно. Map Якщо залежність більше не підтримується потоком, ризик більше не є абстрактним або датованим у майбутньому. Відповідальність за безпеку вже змінилася. Тепер вона сидить або з вами, з продавцем внизу потоку, або з ніким взагалі. Я повинен бути чітким щодо моєї власної позиції тут. Це один із способів, іноді дуже практичний, щоб відновити контроль, коли вразливості з'являються в старішому програмному забезпеченні. (Відгуки про героїв) Але це не єдиний варіант, ані замінник для розуміння того, як ви прийшли сюди. Розширена підтримка є мережею безпеки, а не стратегією. Так відбуваються прискорені оновлення, компенсаційні контролю, ізоляція або архітектурні зміни. Всі вони є дійсними відповідями в різних контекстах. Реальний режим невдачі не є вибором будь-якої відповіді. Дрейф до стану, де ніхто явно не відповідає, і жодна відповідь насправді не належить, є неправильним вибором. Кінець життя не означає «небезпечний за замовчуванням». Це означає, що тягар доказування перемістився. Хтось тепер повинен активно нести відповідальність за безпеку. Якщо ви не можете вказати, хто це або пояснити, як ця відповідальність виконується, то ризик вже присутній, незалежно від того, чи має CVE вашу увагу чи ні. Розглядайте безпеку як життєвий цикл, а не подію. Так роблять більшість реальних вразливостей.Якщо ваші процеси залучаються тільки в момент розкриття, ви оптимізуєте для розповідей, для історій, а не для результатів. Finally CVE-2025-24813 Безпека не починається з підйому До моменту, коли відрахування досягає нуля, двигуни вже горять протягом тривалого часу.Єдине питання - чи помітили ви це і чи побудували ви свої системи, щоб рухатися, перш ніж хтось сказав вам, чому.