powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / Критическая уязвимость log4j
23 сообщений из 48, страница 2 из 2
Критическая уязвимость log4j
    #40121861
Вот чтоб такого не происходило и нужны security эксперты. Они могут быть встроены в процесс разработки - это им позволит объяснять как делать можно, как нельзя, ну и самое главное - почему. Так же они могут инструменты для анализа кода в процесс разработки.

Я ж не против безопасности в целом. Но
а) security команда не должна быть паникерами
б) они должны работать во благо компании
в) они должны понимать как severity проблемы, так и приоритет по ее фиксу
г) им нужно предлагать хорошие, эффективные решения, а не просто чуть что - перекрывать всем воздух. Самый безопасный способ работы - это полностью парализовать всю компанию и ничего не делать. Часто кажется что security команды стремятся именно к этому идеалу.

Не каждый vulnerability заслуживает большого внимания, и не каждая должна быть "пофикшена".
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121867
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Да ну, эт чепуха какая-то. Если кто-то может залезть на сервер и менять там файлы как хочет, так он и само приложение может подменить на другое :)


кто может в поставке подменить файл и приложение будет делать чтото чего не планировалось. Уже даже в css встроили хэши для защиты от подмены доблестными провайдерами.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121880
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Не каждый vulnerability заслуживает большого внимания, и не каждая должна быть "пофикшена".
Вот это вот всё не имеет смысла без модели угроз и уровня нарушителя.
Банальное сотрясание воздуха.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121881
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Они могут быть встроены в процесс разработки
-1
Это мечты.
За уровень секретности всегда отвечает исполнитель.
Вплоть до уголовной.
Есть в приказе не использовать не сертифицированное ПО? Вот и не тащи либы с гитхаба.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121891
Basil A. Sidorov
Stanislav Bashkyrtsev
Не каждый vulnerability заслуживает большого внимания, и не каждая должна быть "пофикшена".
Вот это вот всё не имеет смысла без модели угроз и уровня нарушителя.
Банальное сотрясание воздуха.
Не понял к чему этот комментарий..
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121913
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
Не понял к чему этот комментарий..
модель угроз - это когда вместо очевидного разделения на плохишей и кибальчишей, внезапно возникает цветовая дифференциация штанов: сидят такие сотрудники ИБ и выдумывают креатив в духе "нам нужна роль настройщика logback приложения X", там появляются штатные единицы, у руководителей растет ЧСВ и пр. - ну вот в этом месте внезапно случается, что администратор логов может себе позволить нечто большее, а на вполне резонный вопрос: ну а что с того, можно же было аппендер с правильным кодом вставить или лог куда нужно направить (тут в первом приближении уже DoS)? тебе отвечают: в документации же не написано что при обращении по JNDI оно код выполнять может.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121941
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В большой корпорации мы не можем спорить с ОИБ.
Ведь аргументы безопасников напоминают аргументы пожарного инспектора по поводу отсутствия огнетушителя на стене.

Инспектор просто приведет пример того что где-то погибли люди вследствие пожара.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121944
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Инспектор просто приведет пример того что где-то погибли люди вследствие пожара.


интересно было бы выслушать мнение почему у https://nvd.nist.gov/vuln/detail/CVE-2021-27568 скор 9.1, а у https://nvd.nist.gov/vuln/detail/CVE-2015-6420, которая в свое время вообще все подряд пробивала, всего лишь 7.5 (причем последнюю довольно криво анонсировали из-за чего много кто пострадал). Вопрос не в том что спорить/не спорить, обновляться/не обновляться, а в том, чтобы наводимый шухер был адекватен угрозе, в противном случае условно завтра все побегут обновлять томкаты, потому что там же тоже можно локатор JNDI прописать.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121977
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
модель угроз - это когда вместо очевидного разделения на плохишей и кибальчишей, внезапно возникает цветовая дифференциация штанов: сидят такие сотрудники ИБ и выдумывают креатив в духе "нам нужна роль настройщика logback приложения X"
Ещё хуже, когда пофигукто,напримерайтишники, начинают домысливать в меру собственной неосведомлённости.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40121979
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
mayton
Инспектор просто приведет пример того что где-то погибли люди вследствие пожара.


интересно было бы выслушать мнение почему у https://nvd.nist.gov/vuln/detail/CVE-2021-27568 скор 9.1, а у https://nvd.nist.gov/vuln/detail/CVE-2015-6420, которая в свое время вообще все подряд пробивала, всего лишь 7.5 (причем последнюю довольно криво анонсировали из-за чего много кто пострадал). Вопрос не в том что спорить/не спорить, обновляться/не обновляться, а в том, чтобы наводимый шухер был адекватен угрозе, в противном случае условно завтра все побегут обновлять томкаты, потому что там же тоже можно локатор JNDI прописать.

А каким образом они считают рейтинг уязвимости? Откуда взялось число 9.1 ?
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122025
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122051
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
Ещё хуже, когда пофигукто,напримерайтишники, начинают домысливать в меру собственной неосведомлённости.


Обычно спесь с экспертов ИБ довольно быстро спадает после вопроса к количестве уязвимостей, ими опубликованных...
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122052
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
А каким образом они считают рейтинг уязвимости? Откуда взялось число 9.1 ?


по калькулятору считают: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator, но нужно понимать, что корректность вектора, указанного в CVE, скорее исключение, чем правило, например для smart-json правильный вектор это AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N , т.е. выбивает 0, а нарисовали 9.1. Подобные несостыковки вызваны тем, что объективным анализом уязвимостей фактически никто не занимается (кроме злодеев, которые хотят нас взломать), поскольку процесс выглядит примерно так как описано ниже (дальше нужно учитывать, что про то как работают различные bug bounty программы я не в курсе, ибо не участвовал, поэтому в случае bug bounty что-то может идти иначе)

если нам повезло и мы нашли уязвимость, то есть три варианта (помимо того, чтобы просто опубликовать в твитере и наблюдать что будет):
- просто перетереть с вендором, и здесь все может закончиться или успешно или не успешно в самом широком понимании этого слова, ну например если выяснится, что наши исследования основываются на декомпилировании бинарников, то вместо удлинения ЧСВ можно на самом деле озалупиться: у вендора может быть какой-нить EULA явно запрещающий подобные действия
- продать кому-то: с одной стороны не факт что купят (здесь самыми ликвидными считаются уязвимости в браузерах, а повышение привилегий с оператора до dba в каком-нить оракле никому не интересно), с другой стороны как-то не особо красиво это (но это уже каждый сам для себя решает)
- идти по пути coordinated vulnerability disclosure (далее CVD)

В случае CVD первым делом нужно выбрать CNA и здесь уже нас ждет сюрприз: все крупные вендоры являются CNA, существует вариант выбрать какой-нить CERT, но они первым делом порекомендуют обратиться к соответствующему CNA, а выступать в качестве координатора будут только в крайнем случае (вендор не является CNA, либо нужно как-то обосновать почему мы не хотим общаться с вендором, например вендор не идет на контакт, мы не хотим светиться перед вендором), но здесь нужно понимать что у CERT нет функций оценки уязвимостей - они только координируют процесс, а оценивать будет или вендор (в случае если он выпускает бюллетень) или заявитель (если бюллетень выпускает CERT или заявитель), и в этом месте как раз возникают несостыковки связанные с правильной оценкой:
- заявителю условно выгодно чтобы скор был повыше - ЧСВ никто еще не отменил, в итоге получаем high вместо положенных medium или low
- в большинстве случаев вендор стремится занизить скор потому что критические уязвимости портят карму, а занизить его довольно просто: переключение Attack Complexity с Low на High сразу снимает единицу (причем наличие эксплоита само по себе подразумевает Low, но о наличии можно и умолчать и не разглашать информацию о том, где именно нашлась уязвимость), игра с Impact Metrics тоже позволяет еще пару очков скинуть - и вот получаем medium вместо high

Итог всего этого безобразия такой, что непонятно что делать на самом деле:
- далеко не факт, что в случае high нужно бросаться и срочно все обновлять
- с другой стороны medium вполне себе может быть на самом деле high - либо вендор сознательно скор занизил, либо наша среда выполнения, настройки или процессы довольно специфичные
- практически никто не публикует бюллетени, если информация об уязвимостях была получена не в результате CVD или где-то еще не всплыла, по крайней мере фразу в духе "This vulnerability was discovered by Cisco during internal testing" я видел только в бюллетенях от циски, да и то довольно редко

В целом же ситуация с ИБ довольно плачевная:
- по истине крутые чуваки в ОИБ не работают, а те которые работают в ОИБ предпочитают перебздеть чем недобздеть - я встречался с типами, которые в свое время постоянно обновляли серверную жаву после того как оракл публиковал бюллетени об очередном пробитии песочницы в апплетах
- различные сертификации/аттестации ПО работают тоже так себе, вот лично сталкивался со следующими случаями:
-- в ПО, уже сертифицированном по Common Criteria, выявлялась эскалация привилегий исключительно за счет вдумчивого чтения документации - как раз сценарий про цветовую дифференциацию штанов: пользователь, наделенный привилегиями чуть выше обычного, имел возможность повысить привилегии до суперпользователя
-- приглашенные пентестеры тупо не находили уязвимости, которые были уже опубликованы - толи сканер обновления не скачал, толи подписку не продлили
- иногда бизнес продавливает кривые решения, иногда подрядчик скрывает проблемы, однако чаще всего ИБ откровенно вставляет палки в колеса
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122054
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
Обычно спесь ...
... никак не связана с разницей между "модель угроз" и "система прав".

P.S.
Прежде чем определять победителя в споре - согласуйте терминологию и тезисы.

P.P.S.
Лично я никак не собираюсь оценивать значения критичности той или иной угрозы.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122424
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
Андрей Панфилов
Обычно спесь ...
... никак не связана с разницей между "модель угроз" и "система прав".
Вам не мешало бы методичку перечитать...

РСБ.7Доступ к записям аудита и функциям управления механизмами регистрации (аудита) должен предоставляться только уполномоченным должностным лицам.

Basil A. Sidorov
согласуйте терминологию и тезисы.


Какой в этом смысл? Создание очередного птичьего языка преследует только единственную цель - выкачивание денег из заказчика, здесь примерно как с юристами: что бы не произошло - юристы всегда в выигрыше (в случае ИБд - безопасники всегда не при делах). Ваша "модель угроз" - это даже не документ, а некое обоснование того, почему были выбраны те или иные меры защиты, причем это обоснование строится на совершенно неправильных концепциях, ну вот пример: ИБ определяет меры защиты для конкретной системы исходя из данных, которые в ней хранятся - это в корне неверно, поскольку:
- принципиально невозможно определить/спрогнозировать насколько важные данные могут оказаться в той или иной системе: условно есть какое-то текстовое поле в форме или возможность прикрепить файл - пользователи системы могут положить туда что угодно, тот же российский ФСТЭК пытается выкрутиться из этой ситуации за счет того, что указывает ограничения на объемы хранимой информации, т.е. предполагает что существуют специализированные системы, а на остальные плевать; в случае же, к примеру, PCI DSS если у аудиторов возникает подозрение что в системе потенциально могут храниться PAN - то иди и выполняй все требования
- пользователям свойственно везде устанавливать одни и те же пароли, поэтому защищать в инфраструктуре только какую-то конкретную систему не имеет никакого смысла
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122448
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
Ваша "модель угроз" - это даже не документ, а некое обоснование того, почему были выбраны те или иные меры защиты
Я правильно понимаю ваш посыл как "меры защиты невозможно обосновать"? Почему? "Потому что!".
Так?это обоснование строится на совершенно неправильных концепциях, ну вот пример: ИБ определяет меры защиты для конкретной системы исходя из данных, которые в ней хранятсяВас укусил 152-ФЗ или его западный аналог?пользователям свойственно везде устанавливать одни и те же пароли, поэтому защищать в инфраструктуре только какую-то конкретную систему не имеет никакого смыслаЯ правильно понимаю, что если проигнорировать в модели угроз конкретный вектор атаки, то плохой должна стать система, а не конкретные исполнители?
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122489
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
mayton
А каким образом они считают рейтинг уязвимости? Откуда взялось число 9.1 ?


по калькулятору считают: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator, но нужно понимать, что корректность вектора, указанного в CVE, скорее исключение, чем правило, например для smart-json правильный вектор это AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N , т.е. выбивает 0, а нарисовали 9.1. Подобные несостыковки вызваны тем, что объективным анализом уязвимостей фактически никто не занимается (кроме злодеев, которые хотят нас взломать), поскольку процесс выглядит примерно так как описано ниже (дальше нужно учитывать, что про то как работают различные bug bounty программы я не в курсе, ибо не участвовал, поэтому в случае bug bounty что-то может идти иначе)

Понятно. Насчет скоринговых калькуляторов я ничего не имею против. Это уже математика. Но до математики
там нужна экспертная оценка например признаков. Вот взять Availability Impact (A). Он может быть None, LOW, HIGH.
Кто та персона которая решает что этот импакт попадает в сегмент LOW или HIGH? Здесь - бесконечное пространство
для манипуляций. Может булевый признак был-бы предпочтительнее. Всяко проще решать между ДА или НЕТ чем
между тремя нечеткими философскими категориями.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122493
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Вот взять Availability Impact (A). Он может быть None, LOW, HIGH.
Кто та персона которая решает что этот импакт попадает в сегмент LOW или HIGH?
Если в вашей модели угроз нет уязвимых LDAP-серверов, которые и должны "предоставить" вредоносный код, то вам полностью NONE на уязвимость log4j2.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122579
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
нужна экспертная оценка например признаков. Вот взять Availability Impact (A). Он может быть None, LOW, HIGH.
Кто та персона которая решает что этот импакт попадает в сегмент LOW или HIGH? Здесь - бесконечное пространство
для манипуляций. Может булевый признак был-бы предпочтительнее. Всяко проще решать между ДА или НЕТ чем
между тремя нечеткими философскими категориями.

кто бюллетень публикует тот и является экспертом - такой вот процесс. Вообще гайды с примерами опубликованы - оттуда можно кое-какие знанияидеи почерпнуть, однако ясности оно особо не вносит: скор рисуют основываясь на известных прецедентах, например:
- для RCE C/I/A сейчас почти всегда ставят H/H/H
- для жавы даже потенциальные RCE через десериализацию засчитываются как 9.8 - выглядит это несколько притянутым за уши поскольку за последнее время вроде как весь опенсорс от приколов с RCE почистили и как найти уязвимое приложение - загадка, остался в основном DoS , но вот практика такова, что рисуют 9.8 поскольку никто толком не знает что там у приложения в classpath лежит


Basil A. Sidorov
Если в вашей модели угроз нет уязвимых LDAP-серверов, которые и должны "предоставить" вредоносный код, то вам полностью NONE на уязвимость log4j2.

Вот нужно было с этого и начинать, а то модели угроз, ФЗ и прочие филькины грамоты
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40122661
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
Вот нужно было с этого и начинать, а то модели угроз, ФЗ и прочие филькины грамоты
Если начинать с модели угроз, то "вот это вот всё" становится очевидным без "погружения" в "критичности" и прочие скоринги.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40123333
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
Если начинать с модели угроз, то "вот это вот всё" становится очевидным без "погружения" в "критичности" и прочие скоринги.


Можете дальше не отвечать, я и так знаю что там будет очередная пурга написана, то что ниже - это не для вас, а для тех, кто способен когда нужно включать мозги...

1. Так называемая "модель угроз" ни в коем случае "самостоятельным" документом не является, здесь правильно говорить, что это не документ, поскольку, согласно российским реалиям, он написан птичьим языком, а его целевая аудитория - это либо регулятор, либо аудитор (читать: ИБ пишут что-то сами для себя, чтобы избежать ответственности), и единственная цель этого "документа" - обосновать перед регулятором или аудитором минимальный набор реализованных мер исходя и данных, хранящихся в конкретной ИС и гипотетической "модели злоумышленника". Если бы эта реальная "цель" указывалась бы во введении, то вопросов бы к этому "документу" не было - все бы понимали, что это просто некая формальность необходимая для прохождения аудита, но при этом никакого отношения к информационной безопасности не имеющая, однако, ИБ действует иначе: раз бизнес "документ" подписал, то в случае чего с нас взятки гладки.
2. "нет уязвимых LDAP-серверов, которые и должны "предоставить" вредоносный код, то вам полностью NONE на уязвимость log4j2" - такое в "модель угроз" никак поместить нельзя - "документ" совсем не про это, где такое утверждение и имеет право быть, так это в "политике информационной безопасности" с формулировкой вида: "обращение из жавы к LDAP-серверам может таить скрытую угрозу, поэтому на соответствующие участки кода следует обращать особое внимание" (здесь сразу возникает очевидный вопрос: а какого хрена жава пытается до сих пытается использовать проприетарную схему в LDAP? Ну и ответ на него тоже очевидный: какие-то долбоклюи из оракла пытаются блюсти обратную совместимость, которая в данном случае никому не упала, но при этом вызывает массу проблем)
3. обычно упоротые поклонники бумажек, в т.ч. "политики информационной безопасности" на самом деле ничерта не умеют, однако, искренне полагают, что в случае использования какого-то стороннего ПО всенепременно наступит счастие - существует аж целая секта свидетелей статического анализитора, ну вот код, представленный ниже, в том же сонаркубе выглядит зеленым, хотя согласно MITRE в нем аж 2 уязвимости, одна из них - RCE:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
@WebServlet
public class Test extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        evilMethod(req);
    }

    private void evilMethod(HttpServletRequest req) {
        try {
            String url = req.getParameter("url");
            ClassLoader classLoader = new URLClassLoader(new URL[]{new URL(url)});
            Class<?> clazz = Class.forName("com.hackers.YouAreP0wned", true, classLoader);
            clazz.getConstructor().newInstance();
        } catch (Exception ex) {
            throw new IllegalArgumentException(ex);
        }
    }

}


4. здесь прав Stanislav Bashkyrtsev с утверждением "встроены в процесс разработки" - все остальное полная херня, не имеющая к ИБ никакого отношения
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40123640
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ох тыж японский гордовой. Хадуп-коммон пострадал. Да еще и фикса нету.
Текущая версия по состоянию на Dec-28, 2011 это 3.3.1.
...
Рейтинг: 0 / 0
Критическая уязвимость log4j
    #40124572
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
теперь всем срочно обновлять LogBack - там тоже "RCE": https://jira.qos.ch/browse/LOGBACK-1591


ну вот собственно как и было обещано:

CVE-2021-44832 :
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Судя по всему отсюда идет: https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/

Забавно что никто настоящий эксплоит не показывает, а просто пишут "вот смотрите, тут десериализация - это зашквар", однако оно уже два года как известно что в коте самый настоящий бэкдор живет: https://www.veracode.com/blog/research/exploiting-jndi-injections-java а те только недавно репу чесать начали: https://bz.apache.org/bugzilla/show_bug.cgi?id=65736
...
Рейтинг: 0 / 0
23 сообщений из 48, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Критическая уязвимость log4j
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]