🍕 Bitcoin Pizza Day.

• 16 лет назад, 22 мая 2010 года, впервые оплатили товар биткоинами. Именно в этот день в 2010 году программист Ласло Хейниц купил две пиццы за 10 тысяч биткоинов.

• 18 мая 2010 года на форуме BitcoinTalk программист Ласло Хейниц написал, что он готов заплатить 10 000 BTC тому, кто закажет ему 2 пиццы. Ответа на его предложение не последовало, и 21 мая Ласло обновил свой пост. На следующий день к нему в дверь постучался студент Джереми Стардивент, держа в руках две грибные пиццы из Papa John’s. Тогда Джереми даже не подозревал, что получает потенциальные миллиарды долларов. Обе стороны оказались весьма довольны сделкой, которая вошла в историю как первая в мире покупка за биткоины. По курсу на сегодня цена той пиццы составляет около 60 миллиардов рублей...

➡ https://www.blockchain.com/transactions

• А еще, в Джексонвилле, штат Флорида, была установлена памятная доска, увековечивающая память о покупке.

#Разное

• 2000 часов или 83 дня - именно столько продолжается интернет-шатдаун в Иране. В стране нет доступа к глобальному интернету, а за все время шатдауна в стране была создана настоящая трехуровневая система, которая разделяет людей на "уровни" для доступа к сети:

• Первый уровень - "белый интернет" - доступен только чиновникам и некоторым журналистам, которые получили соответствующее разрешение. Интернет на данном уровне работает без ограничений.

• Второй уровень - "Internet pro" - доступ к сети предоставляется только преподавателям, врачам, юристам и определенным организациям. Однако, на данном "уровне", доступ отрыт не более чем к десяти сервисам. Открывается Telegram, а вот ютубчик посмотреть уже не получится. Стоит это около 0,20 евро за 1 гигабайт.

• Третий уровень - все остальные жители Ирана. Они вынуждены покупать коммерческие VPN и платить за 1 гигабайт около 2.5 евро - это очень высокая цена и большинство просто не может себе позволить платить такую сумму за доступ в сеть.

• Если верить экспертам, то экономический ущерб от отключения уже привысил 1 миллиард баксов... Как то так...

➡️ Источник.

#Новости

• Когда написал правил на километр, а systemctl restart firewalld забыл...

• Всем хороших выходных ❤

#Юмор

• Доброе утро...🫠

#Понедельник

• Классика: один из подрядчиков Агентства по кибербезопасности и защите инфраструктуры США (CISA) допустил утечку данных ведомства. Ребята хранили архив с паролями и другими данными CISA в открытом GitHub репозитории...

• Публичный репозиторий под названием Private-CISA содержал 844 МБ данных, включая код инфраструктуры Terraform, журналы сборки CI/CD, документацию по процессам развёртывания инфраструктуры, манифесты Kubernetes, файлы ArgoCD и YAML-файлы, AWS-ключи, логины и пароли к десяткам внутренних систем CISA. Все эти данные давали подробное представление о внутренней инфраструктуре CISA, процессах её разработки и эксплуатации.

• Утечка была найдена исследователями из компании GitGuardian. Сначала они усомнились в подлинности находки. Названия папок и файлов выглядели слишком уж "удачно" - Backup-April-2026, Kubernetes-Important-Yaml-Files, Important-AWS-Tokens, AWS-Workspace-Firefox-Passwords и т.д. Однако анализ содержимого показал, что данные подлинные. 

• Эксперты сообщили о своей находке через портал CERT/CC 14 мая, а также попытались связаться с ответственными за репозиторий лицами напрямую. Только на следующий день, 15 мая, исследователям удалось установить контакт с CISA, и к вечеру репозиторий был отключён.

➡️ Источники [1], [2].

#Новости

• URLScan.io - настоящая "песочница" для безопасного просмотра подозрительных ссылок! Если говорить простыми словами, то тут можно проверить адрес в изолированном Chrome.

• Сервис делает скриншот, записывает исходящие запросы, показывает TLS-сертификаты, заголовки безопасности и технологии. Полезен тем, что можно увидеть, куда "ломится" страница, какие домены резолвит, какие куки ставит и какие скрипты подгружает.

➡️ URLScan.io

#Tools

• Ярослав Лабочевский из GitHub Security обнаружил критическую уязвимость в 7-Zip, которая получила идентификатор CVE-2026-48095 и затрагивает версию 26.00.

• Проблема находится в обработчике NTFS-архивов. Из-за ошибки при расчёте размера буфера 7-Zip может выделить под данные всего 1 байт, а затем попытаться записать туда 256 МБ контролируемых атакующим данных.

• В результате данные выходят за пределы буфера и начинают перезаписывать соседние участки памяти. По данным специалистов, уже после 304 байт может быть повреждён указатель vtable, а дальше появляется возможность выполнить произвольный код.

• Уязвимость была устранена в версии v26.01.

➡️ POC и технические детали.
➡️ Источники [1], [2], [3].

#Новости #CVE #Security

• Очень крутое исследование, в рамках которого вы найдете детальный разбор CVE-2026-3102 в ExifTool - эта уязвимость позволяет атакующим компрометировать системы на базе macOS с помощью специально подготовленного изображения.

• Дело в том, что ExifTool является очень популярным open source решением для чтения, редактирования и записи метаданных в изображениях. Тулза используется фотографами и специалистами фотоархивов, применяется в аналитике, криминалистических экспертизах и журналистских расследованиях.

• Уязвимость CVE-2026-3102 проявляется при обработке вредоносного файла изображения (например, PNG), содержащего в метаданных команды оболочки. При успешной эксплуатации уязвимости злоумышленник может выполнять произвольные shell-команды с привилегиями пользователя, запустившего ExifTool, что потенциально может привести к полной компрометации системы.

• Если говорить простыми словами, то для эксплуатации данной уязвимости атакующий должен подготовить специальный файл (картинку). Сама картинка может быть любой, но в ее метаданные нужно записать дату и время создания изображения DateTimeOriginal в неверном формате. Кроме даты и времени, там должны содержаться вредоносные команды оболочки. Из-за специфики обработки в ExifTool, эти команды сработают при выполнении двух условий:

➡Приложение или библиотека запускаются под macOS;
➡Включен режим -n (он же —printConv), в котором данные машиночитаемого формата выводятся без дополнительной обработки, как есть.

• Сценарий целевой атаки будет выглядеть так: в лабораторию криминалистики, в редакцию СМИ или в крупную организацию, обрабатывающую юридическую или медицинскую документацию, поступает цифровой документ, представляющий для нее интерес. Сенсационное фото, юридическая претензия — приманка зависит от рода деятельности жертвы. Все поступающие в компанию файлы проходят сортировку и каталогизацию с помощью системы управления активами (Digital Asset Management). В крупных компаниях это может быть автоматизировано, частные лица и маленькие фирмы запускают нужный софт вручную. В любом из случаев внутри этого ПО должна использоваться библиотека ExifTool.

• При обработке даты зловредного фото компьютер, где проводится эта обработка, заражается трояном или инфостилером, который в дальнейшем способен похитить все ценные данные, хранящиеся на атакованном устройстве. При этом жертва запросто может ничего не заметить, поскольку атака использует метаданные изображения, а сама картинка может быть безобидной, полностью уместной и полезной.

➡️ Детальный разбор этой уязвимости можно изучить тут: https://securelist.ru/exiftool-compromise-mac/115659/

#Исследование

• Команда MySQL закрыла один из самых известных багов-долгожителей. Тикет для баги завели ещё летом 2005 года, а исправили спустя 20 лет и 9 месяцев, 20 марта 2026 года. На этом фоне пользователи иронично шутили, поздравляя баг каждый год с днём рождения!

• Суть ошибки заключалась в том, что при каскадных изменениях через внешние ключи MySQL обновлял строки в дочерних таблицах, но не запускал для них триггеры. Например, если в родительской таблице удаляли запись, то в дочерней таблице срабатывал ON DELETE SET NULL или ON DELETE CASCADE, и данные в ней действительно менялись. При этом триггер AFTER UPDATE или AFTER DELETE, который разработчик ожидал увидеть при таком изменении, не запускался.

• Разработчики отмечают, что это давнее архитектурное ограничение MySQL. Всё из-за того, что каскадные операции внешних ключей выполняются внутри InnoDB, а триггеры находятся на SQL-уровне. Возможность исправить этот баг появилась только в MySQL 9.6, когда команда перенесла обработку внешних ключей на SQL-уровень.

• Новое поведение по умолчанию выключено, а для активации предусмотрена переменная enable_cascade_triggers. Разработчики просят внедрять опцию внимательно. Если приложение годами нормально работало без запуска триггеров при каскадных изменениях, то активация опции может изменить результаты операций и нарушить логику.

• К слову, на Reddit продолжают обсуждать ошибку и шутить о возрасте бага:

- Какого хрена? Я полагался на этот функционал. Верните все обратно!

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

- Ребята, моя девушка говорит, что выйдет за меня замуж, как только эта ошибка будет решена. У нас есть какие-нибудь новости по этому поводу? P.S: Мы ждем с 2017 года.

- [18 января 2021 0:49] Просто проверял, не пережил ли наш любимый баг пандемию covid-19. Рад видеть, что все хорошо.

- эта ошибка старше меня.

- Я никогда не думал, что доживу до этого дня!

➡️ https://bugs.mysql.com/bug.php?id=11472

#SQL #Разное