Технологический Болт Генона
8.26K subscribers
3.05K photos
371 videos
214 files
3.91K links
До Декарта никогда не существовало рационализма.

Музыкальный Болт Генона: @mus_b0lt_Genona
Мемный Болт Генона: @mem_b0lt_Genona
Кадровый Болт Генона @kadr_b0lt_Genona

Обратная связь: @rusdacent
Download Telegram
Технологический Болт Генона
Acra — database security suite for sensitive and personal data protection. Acra provides field level encryption (client-side or proxy-side), multi-layered access control, database leakage prevention, and intrusion detection capabilities in a convenient, developer…
Ребята из Cossack Labs выкатили большой релиз Arca в котором заопенсорсили то, что раньше было только в платной версии, например, маскировка и токенизация данных, логи-метрики-ивенты, криптографические подписанные аудит логи, обнаружение вторжений на poison records и т.д.

Полный список отличий между CE и EE версиями тут
https://github.com/cossacklabs/acra#major-security-features

Вообще, Acra это набор сервисов, которые позволяют зашифровать данные в БД и при этом не усложнять работу на стороне приложений. Acra можно поставить перед SQL базой данных, настроить какие поля шифровать, настроить приложение читать данные через неё и приложение будет прозрачно шифровать/расшифровывать данные.

Ссылка на запись в блоге
https://www.cossacklabs.com/blog/acra-0-90-0/
Большой и подробный пост о том как разломали GoCD

Agent 008: Chaining Vulnerabilities to Compromise GoCD
https://blog.sonarsource.com/gocd-vulnerability-chain

Предыдущий пост
Agent 007: Pre-Auth Takeover of Build Pipelines in GoCD
https://blog.sonarsource.com/gocd-pre-auth-pipeline-takeover
Умелец подключил к своему ПК б/у клавиатуру с трекболом от системы управления пуском ядерных ракет
https://habr.com/ru/news/t/593383/
Forwarded from k8s (in)security (D1g1)
9 декабря 10:00 MSK (Online) состоится VK Kubernetes Conference!

И там мне посчастливилось в очень крутой компании выступить с докладом "Kubernetes Resource Model (KRM): Everything-as-Code". Буду про YAML рассказывать и то как на него Dev, Ops и Sec командам нужно правильно смотреть в Kubernetes =)

Регистрация открыта ;)
Flipper ищет техписа https://xn--r1a.website/zhovner_hub/1507

От себя добавлю, потому что кто-то знает, а кто-то нет.

Я успел поработать с ребятами около года и это абсолютно классная, технически сильная, увлечённая проектом и результатом команда. Если вы подходите под описание вакансии и хотите попробовать свои силы, то всячески рекомендую.

Вот это абсолютная правда =)
> Дружный коллектив и дух стартапа (в хорошем смысле!)
У GitLab'а в GitLab есть замечательная репа в которой собираются CVE связанные с ним

https://gitlab.com/gitlab-org/cves

Там удобно можно следить чего новенького появляется и изменяется
Вот, например, обновление описания для CVE-2021-39923
https://gitlab.com/gitlab-org/cves/-/commit/cd66080376206983db21d30b545670290119daed

Или добавление информации о CVE-2021-39890
https://gitlab.com/gitlab-org/cves/-/commit/81afc741b4b2db7379b6dd0bd1ab0e88c57f95fb

Последняя, кстати, является критичной и затрагивает последние версии GitLab
It was possible to bypass 2FA for LDAP users and access some specific pages with Basic Authentication in GitLab 14.1.1 and above.

https://www.cve.org/CVERecord?id=CVE-2021-39890
https://vulmon.com/vulnerabilitydetails?qid=CVE-2021-39890
В связи с участившимися случаями захвата репозиториев крупных проектов и продвижения вредоносного кода через компрометацию учётных записей разработчиков, компания GitHub вводит повсеместную расширенную верификацию учётных записей. Отдельно для сопровождающих и администраторов 500 самых популярных NPM-пакетов в начале следующего года будет внедрена обязательная двухфакторная аутентификация.

С 7 декабря 2021 года по 4 января 2022 года будет произведён перевод всех мэйнтейнеров, имеющих право публикации NPM-пакетов, но не использующих двухфакторную аутентификацию, на использование расширенной верификации учётных записей. Расширенная верификация подразумевает необходимость ввода одноразового кода, отправляемого на email при попытке входа на сайт npmjs.com или выполнения аутентифицируемой операции в утилите npm.

GitHub внедряет в NPM обязательную расширенную верификацию учётных записей
https://www.opennet.ru/opennews/art.shtml?num=56304
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
Про безопасность разработки в большой организации

Не так давно ребята из Мимокрокодил позвали меня записать подкаст про современный DevSecOps в крупных организациях. Помимо главной темы, мы подняли концепцию AppSec/DevSecOps-платформ, путь моего развития в индустрии, влияние медийности на карьеру, а также подноготную ведения телеграм-каналов. Получилось весьма интересно:)

Предлагаю послушать:
https://podcast.ru/1505781025

#talks
В Apache Log4j 2, популярном фреймворке для организации ведения логов в Java-приложениях, выявлена критическая уязвимость, позволяющая выполнить произвольный код при записи в лог специально оформленного значения в формате "{jndi:URL}". Атака может быть проведена на Java-приложения, записывающие в лог значения, полученные из внешних источников, например, при выводе проблемных значений в сообщениях об ошибках.

Отмечается, что проблеме подвержены почти все проекты, использующие такие фреймворки, как Apache Struts, Apache Solr, Apache Druid или Apache Flink, включая Steam, Apple iCloud, клиенты и серверы игры Minecraft. Ожидается, что уязвимость может привести к волне массовых атак на корпоративные приложения, повторив историю критических уязвимостей во фреймворке Apache Struts, который по приблизительной оценке применяется в web-приложениях 65% компаний из списка Fortune 100. В том числе уже зафиксированы попытки сканирования сети на предмет уязвимых систем.

Проблема усугубляется тем, что уже опубликован рабочий эксплоит, но исправления для стабильных веток на данный момент не сформированы. СVE-идентификатор пока не присвоен. Исправление включено только в тестовую ветку log4j-2.15.0-rc1. В качестве обходного пути блокирования уязвимости рекомендуется выставить параметр Log4j2.formatMsgNoLookups в значение true.

Критическая уязвимость в Apache Log4j 2, затрагивающая многие Java-проекты
https://www.opennet.ru/opennews/art.shtml?num=56319
+
https://github.com/tangxiaofeng7/apache-log4j-poc
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)»

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast
Forwarded from AWS Notes
Подробный постмортем падения AWS на несколько часов 7 декабря 2021:

https://aws.amazon.com/message/12721/

Кому нужна выжимка:

• Проблема была во внутренней сети AWS, где крутятся мониторинг и control plain некоторых сервисов. Поэтому сами сервисы не падали, но невозможно было внести изменения, что для некоторых сервисов, например, API Gateway оказалось равным проблемам его работоспособности (делается фикс такого поведения).

• Задержка с отображением проблем на странице статуса в том числе связана с недоступностью мониторинга в результате падения внутренней сети. Так как инженеры AWS долгое время не могли узнать (без мониторинга), что на самом деле происходит.

• Интересно отметить, что причиной послужил код, который уже несколько лет успешно крутится в проде, просто его поведение, когда он масштабируется, не было оттестировано (теперь протестировали – нет, не работает). Автоскелинг выключили, мощности хватает, как дотестируют, включат автоскелинг обратно (может быть).

Дополнительно отмечу для себя интересный факт, что S3 и DynamoDB ресурсы, которые, как и другие, не страдали во время инцидента, однако вот те, что подключены через VPC Endpoint – были недоступны. Причём, как понимаю (чего нет в постмортеме) – речь именно о (бесплатных) Gateway VPC Endpoints, в то время как (платные) Interface endpoints – не пострадали.

Итого: приятно читать столь детальный отчёт, проливающий свет на внутреннюю кухню AWS.

We want to apologize for the impact this event caused for our customers. While we are proud of our track record of availability, we know how critical our services are to our customers, their applications and end users, and their businesses. We know this event impacted many customers in significant ways. We will do everything we can to learn from this event and use it to improve our availability even further.

#postmortem
Тут пришли подтверждения, так сказать, что VMware реально под ударом из-за бага с Log4j
https://twitter.com/tnpitsecurity/status/1469429810216771589

Вот страница от самой VMware, где можно отслеживать статус по продуктам, а так же узнать о workaround'е (не для всего есть)
https://www.vmware.com/security/advisories/VMSA-2021-0028.html

В общем, если у вас Варя наружу торчит, то пора меры принимать, потому что 10/10 критичность.
Forwarded from Блог*
#prog #java #kotlin #scala

Well-Typed Programs Can Go Wrong: A Study of Typing-Related Bugs in JVM Compilers

В этой статье авторы отмечают, что усилия в тестировании компиляторов в основном направлены на отлов некорректных оптимизаций, при этом мало кто целенаправленно занимается отловом багов в фронтендах. Авторы выбрали 320 багов, связанных с типами, среди багов компиляторов Java, Scala, Kotlin и Groovy, и разобрались с тем, как они себя проявляют, какие фичи языка используют и как они фиксятся. Вооружившись этим знанием, они написали генератор тестовых программ, который смог найти 28 багов, из них 12 были новыми (то есть для них исправлений не было).

А ещё авторы отличились тем, что нормально выложили материалы по исследованию.
Мы думали, что всё, но это не всё. Теперь с log4j ещё долго время не слезут. Пока "все" баги там не найдут.

Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
+
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability. Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

https://nvd.nist.gov/vuln/detail/CVE-2021-45046