> We are now seeing a massive contraction of the Infrastructure space. Teams are increasingly looking for simple, less platform specific tooling. In my own personal circles it feels like a real return to basics, as small and medium organizations abandon technology like Kubernetes and adopt much more simple and easy-to-troubleshoot workflows like "a bash script that pulls a new container".

Я лично такого не наблюдаю и, по моим ощущениям, Кубер тянут так или иначе все подряд уже.

A Eulogy for DevOps
https://matduggan.com/a-eulogy-for-devops/

JetBrains запретил срать скачивать свои продукты

https://www.jetbrains.com/idea/download/ при нажатии кнопки Download для версии, например, Ultimate

You may be familiar with Version 1, which is written in Rust. So, why re-write it in Go?

Ultimately, treefmt is spending most of it's time shelling out calls to the underlying formatters. This process is just as fast/performant in Go as it is in Rust.

The remaining tasks are processing some cli args and parsing a config file. Do we really need something as heavy duty as Rust for that?

Despite all this, you can make good, sane arguments for continuing with Version 1 in Rust instead of a re-write. So here's a bad argument.

Brian wanted to improve performance by moving away from a Toml cache file, introduce pipelines for applying multiple formatters against the same file set, and add an extensible approach for how treefmt walks file systems. He knows Go much better than Rust.

zimbatm thought it was a good idea too.

So here we are 🤷.

https://github.com/numtide/treefmt

По наводке из @itpgchannel

Потерпевший — мой брат, узнал о том, что он должен банку ВТБ 1.7 млн за автокредит только вчера. В почтовом ящике обнаружил письмо от банка с требованием начать вносить платежи по договору на автокредит от апреля этого года. Этим банком он года с 2015 не пользовался, в офисы не ходил, по счетам движений не было, да и счет был тоже открыт под теоретическую ипотеку, которая с этим банком так и не состоялась.

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

Дальше идет в салон МТС узнать, что вообще с этим номером, которым уже года с 2019 не пользовался. МТС говорит, с августа 2023 этот номер больше не ваш. А в апреле 2024 его оформили на новое лицо. Никаких выписок по нему не дадим, даже за тот период, когда он был ваш, обращайтесь в головной офис, у нас лапки.
. . .
У ВТБ недавно была очередная утечка персональных данных, ходили даже скрины на пикабушках в начале года, что в тг–каналах продают данные. Пока не видел, что там за данные были, но предположение, по ним можно было сделать выборку о неактивных клиентах и их номеров телефонов.

Затем ищется на сайтах операторов, можно ли купить этот номер.
. . .
А дальше, заполучив нужный номер клиента, который в кабинет ВТБ сто лет даже не заходил, начинается самое охуенное, такого пиздеца похуизма со стороны ИБ я не встречал даже в мелких региональных банках.

Давайте вначале представим, что в таком случае делает, например, Тинькофф или Сбер, сталкивался с заменой симки, поэтому на личном опыте. После замены сим–карты войти в приложение не могу, Сбер заставил зайти в офис по причине противодействия мошенничеству, ок, зашел, паспорт показал, подтвердил, что сим–карту менял — разблокировали. Тинькофф поебал на поддержке, кодовое слово, какие–то еще вопросы — разблокировали.

Теперь случай курильщика ВТБ. Как зайти в онлайн–банк, если для этого нужен логин? Наверное, нужны связи с подкупленным сотрудником банка? Нет. Может быть, эти данные были в той утечке? Нет. Возможно, достаточно знать номер телефона и зайти по нему как логину? Снова нет. 

Звоним на номер 1000 с привязанного к банку номера и говорим роботу одно слово — "Ты пидор!", а нет, это два слова. Тогда "Логин". Вуаля, записывайте, ваш логин — ebat_ty_loh_777, спасибо за ваш звонок. 

Далее все просто, вот логин, забыл пароль, восстановить, введите номер из смс, добро пожаловать в наш банк.

Свежая схема мошенничества ВТБ
https://telegra.ph/Svezhaya-shema-moshennichestva-VTB-06-30

Тред на Банки.ру
https://www.banki.ru/services/responses/bank/response/11514382/

Демонстрация "дыры" в прикреплённом видео.

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

Ну и тут скорей не про ВТБ, а в целом совет: актуализируйте номера на всех ресурсах, которыми пользуетесь.

Выложили доклады с DevConf.CZ 2024

Плейлист
https://www.youtube.com/playlist?list=PLU1vS0speL2aQkUwVfSruQz-K-4tzMIKW

Программа
https://www.devconf.info/cz/schedule/

Андрей Белевцев: Сбер создаёт собственную среду разработки и исполнения Java-приложений SberJDK
http://www.sberbank.ru/ru/sberpress/tekhnologii/article?newsID=64b3d035-f8ba-479a-adfa-c5a16d9ba2b8&blockID=69b149cd-6db4-45aa-ade1-b6920d771b11&regionID=61&lang=ru&type=NEWS

> создаёт

Прям создаёт. Понимаю.

Если подытожить, первое разочарование от Flipper Zero продлилось недолго. Это устройство быстро развивается как платформа, и, пожалуй, сейчас я был бы готов заплатить за него даже больше, чем пару лет назад.

Не скажу, что этот гаджет нужен всем и каждому. Я так и не нашел ему достойного применения в повседневной жизни. Да и специалистам, которые ломают веб, он вряд ли пригодится. Но для физического проникновения на объекты клиентов это инструмент из серии must have. Только не воспринимайте Flipper как панацею: нужно трезво оценивать его возможности и ограничения.

Flipper Zero — мнение пентестера после двух лет «полевой» эксплуатации
https://habr.com/ru/companies/bastion/articles/820279/

ЗЫ

> так как она позволяет запаролить девайс. Это важно с точки зрения безопасности клиентов, пропусками которых я временно пользуюсь

Ну такое. Если твой Flipper уплывёт в чужие руки, то ничто не помешает посмотреть, что там на SD-карточке лежит просто с компьютера или другого устройства.

> but OpenBSD is notably not vulnerable

Слава Патрику Тео

This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function
that is directly called by sshd's SIGALRM handler. In other words:

- OpenSSH < 4.4p1 is vulnerable to this signal handler race condition,
  if not backport-patched against CVE-2006-5051, or not patched against
  CVE-2008-4109, which was an incorrect fix for CVE-2006-5051;

- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable to this signal handler race
  condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added
  to sigdie() by the patch for CVE-2006-5051 transformed this unsafe
  function into a safe _exit(1) call);

- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again to this signal handler
  race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was
  accidentally removed from sigdie()).

This vulnerability is exploitable remotely on glibc-based Linux systems,
where syslog() itself calls async-signal-unsafe functions (for example,
malloc() and free()): an unauthenticated remote code execution as root,
because it affects sshd's privileged code, which is not sandboxed and
runs with full privileges. We have not investigated any other libc or
operating system; but OpenBSD is notably not vulnerable, because its
SIGALRM handler calls syslog_r(), an async-signal-safer version of
syslog() that was invented by OpenBSD in 2001.

regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
(CVE-2024-6387)
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

PoC подъехал для CVE-2024-6387

a signal handler race condition in OpenSSH's server (sshd)
https://github.com/7etsuo/cve-2024-6387-poc

За ссылку спасибо подписчику

UPD: репу удалили, архив в комментах

@disasm_me_ch "рецепт" описал как быстро митигировать, пока фиксы не долетят, на примере Debian-based

apt-get update
apt-get install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wget https://github.com/openssh/openssh-portable/archive/refs/tags/V_9_8_P1.tar.gz
tar -xzf V_9_8_P1.tar.gz
cd openssh-portable-V_9_8_P1
./configure
make
make install
mv /usr/sbin/sshd /usr/sbin/sshd.bak
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
systemctl restart sshd

Выпустил новую версию своей книги "Автомато-программато-компарадио-кружок":
https://github.com/artyom-poptsov/SPARC/releases/tag/v2.1.0

В новой версии:

- Расширен раздел "Платформа Arduino".

- Дополнен раздел про последовательный порт в главе "Белый шум".

- В главе "Язык общения машин" добавлен новый раздел "Последовательный порт". Также доработано введение к главе.

- В главе "Диалоги с компьютером" дополнен раздел про работу с мультиметром, улучшен раздел "Работа с макетной платорй", добавление ссылок на другие связанные разделы.

- В главе "Синтез музыки и технологии" исправлены ошибки в реализации мелодии "Sweet Dreams".

- Добавлена библиография.

- Исправлены выявленные стилистические и орфографические ошибки. Значительная часть ошибок была выявлена Van0Mask, несколько ошибок были выявлены Антоном Шеффером (Agaffer). Множество рекомендаций по изложению материала и исправлений было предложено Петром Третьяковым, большинство из которых были в том или ином виде реализованы.

PDF-версия книги доступна на странице релиза, также скину копию в комментарии к этому посту.

#sparc_book

> Sniffing Bitlocker keys with $10 of equipment

Полное видео с объяснениями
Breaking Bitlocker - Bypassing the Windows Disk Encryption
https://www.youtube.com/watch?v=wTl4vEednkQ
+
Исходный код с KiCad под железку
https://github.com/stacksmashing/pico-tpmsniffer

Хорошие статьи по теме

Sniff, there leaks my BitLocker key
https://labs.withsecure.com/publications/sniff-there-leaks-my-bitlocker-key

TPM sniffing
https://blog.scrt.ch/2021/11/15/tpm-sniffing/

EXTRACTING BITLOCKER KEYS FROM A TPM
https://pulsesecurity.co.nz/articles/TPM-sniffing

Я бы назвал это неким чеклистом

Steve Kaelble. Kubernetes Security For Dummies. 2024.

Забрать можно тут, если не из телеги
https://www.datocms-assets.com/75231/1704995046-kubernetes-security-for-dummies_wiz_final.pdf

Сидел я сегодня такой, развлекался с Nix'ом и внезапно обнаружил, что конструкции вида nix shell nixpkgs#hello -c bash в шебанге и Linux и MacOS отрабатывают совершенно по-разному.

Краткая справка: Шебанг (shebang) - это конструкция вида #!interpreter [args] (#! обязателен), расположенная строго в начале файла, и говорящая операционной системе запустить interpreter [args] [original file] [original args].
Была придумана, чтобы не писать руками python script.py, а сделать ./script.py, условный.

Когда функциональность уровня ядра ведет себя как-то неправильно, первое и логичное решение... пойти копаться в сорцах этого самого ядра.

Спасибо эплу, некоторым лицензиям, и неизвестному самаритянину (насколько я знаю, это неофициальное зеркало) - у нас есть код XNU (ядро MacOS) на гитхабе.

Непродолжительные поиски действительно привели меня к строке, в которой определяется условие конец шебанга, где концом строки считается либо #, либо \n.
Окей, теперь я знаю, что у меня нет шизофрении (на самом деле есть), и это действительно ядро ведет себя так странно.
Встает следующий вопрос: а почему оно так себя ведет?

Если посмотреть на путь к файлу kern_exec.c, можно увидеть, что он начинается с папки bsd.
Так возможно это не у apple что-то с головой, а они просто бэкпортировали какое-то странное изменение из ядра *BSD? (Да, XNU основан во многом на BSD)

Быстро пробежавшись по старым *BSD ядрам (4.3BSD, FreeBSD версий 2-3) я ничего полезного не нашел, там этой особенности не было.

Дальше я решил вернуться обратно к blame'у сорцов XNU. К сожалению, текстов коммитов нет (разве что где-то в недрах Apple), поэтому остается довольствовать описаниями версий, в которых что-то меняли.
Таким образом я узнал, что это добавили в XNU-517.

Быстрый гуглеж по XNU-517 shebang наконец-то привел меня к цели всего поста: шедевральной страничке https://www.in-ulm.de/~mascheck/various/shebang/, содержащей огромный и очень информативный текст (я не шучу, сходите сами почитайте!) про историю шебангов.

Конкретно про обработку второй # - тут.
Как оказалось, я смотрел слишком ранние версии FreeBSD - это действительно внесли именно в ней, в 4.0 ветке, а потом убрали в 6.0.
XNU бэкпортировали это к себе, но так и не убрали, только рефакторя код год за годом (стало кстати объективно лучше, тоже забавное наблюдение).

Итак. Изначальной причиной появления такого способа обработки # в шебангах была...
Рекомендация в документации к perl'у писать шебанг следующим образом:

#!/bin/sh -- # -*- perl -*- -p

чтобы избегать каких-то странных кроссплатформенных проблем (да, утилиту env тогда ещё не придумали).

Зайдите ещё в комменты, там есть парочка мемов, которые не влезли в пост =)