​​Бекдор в библиотеке liblzma или следствие вели

29 марта 2024 года вышла новость об обнаружении бекдора в библиотеке liblzma, которая при определенных обстоятельствах позволяла войти на удаленный хост по SSH в обход механизмов аутентификации.

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

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

Сразу предупредим, что паниковать и подпрыгивать не стоит, скомпрометированные версии не успели попасть в репозитории основных дистрибутивов, уязвимыми оказались только бегущие впереди паровоза роллинговые дистрибутивы включая openSUSE Tumbleweed, Arch Linux и Gentoo.

Поэтому сегодня мы поговорим не об этом, а о более интересной и увлекательной истории как все это было организовано.

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

Это заставило взглянуть на ситуацию по-другому и заподозрить одного из разработчиков в двойной игре.

Этим разработчиком оказался Jia Tan, который в 2022 году получил статус сопровождающего пакета xz и выпускал релизы начиная с версии 5.4.2, при этом он был вторым по активности внесения изменений разработчиком проекта.

Интересен и его переход в статус сопровождающего, перед этим он подверг психологическому прессингу тогдашнего мейнтейнера проекта Lasse Collin, обвиняя его в плохом выполнении собственных обязанностей.

К этой травле присоединился и ряд других участников, которые скорее всего были виртуальными клонами Jia Tan.

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

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

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

Но сгубила его все-таки спешка, деструктивный код был включен в версию 5.6.0 и якобы «исправленную» 5.6.1, но код был явно недостаточно отлажен и начал вызывать замедление работы и ошибки при работе с памятью.

Одновременно с этим его виртуальные клоны занялись активным продвижением пакета в основные дистрибутивы, добиваясь его скорейшего обновления в репозиториях Debian, Ubuntu и Fedora. Данные персонажи также были внедрены заранее и являясь участниками сообщества не вызывали серьезных подозрений.

Обнаружил бекдор программист из Microsoft Andres Freund, у которого пакет начал вдруг тормозить и сбоить.

С этого момента пошла раскручиваться цепочка, которая и привела к Jia Tan, выяснилось, что он постоянно использовал VPN и тщательно скрывал свой регион и временную зону.

Также его активность была обнаружена в проектах xz-java и xz-embedded, в последнем из которых он также был сопровождающим. При этом пакет XZ Embedded используется в ядре Linux и предназначен для IoT и встраиваемых устройств.

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

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

👉 Изучите возможности балансировки нагрузки в Nginx и Angie и прокачайте скиллы администратора Linux

🎁 Приходите на бесплатный практический урок от OTUS, где вы вместе с опытным экспертом:
1. изучите варианты балансировки нагрузки в веб-серверах Nginx и Angie;
2. научитесь их использовать;
3. разберёте различие продуктов и их особенности.

⏰ Занятие пройдёт 9 апреля в 19:00 мск в рамках курса «Инфраструктура высоконагруженных систем». Доступна рассрочка на обучение!

👉 Пройдите короткий тест прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/x3eD/?erid=LjN8K925s 

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Взлет и падение Novell NetWare

Давным-давно осенью 1981 года группа вчерашних выпускников Дэйл Найбауэр, Дрю Мэйджер, Кайл Пауэл и Марк Хёрст основали небольшую компанию SuperSet Software, которая занималась внедрением персональных компьютеров и начала писать софт для файлового сервера на базе CP/M с процессором Motorola 68000.

Именно такие сервера продавала в их городке небольшая, основанная в 1979 году фирма Novell Джорджа Кановы.

Довольно скоро разработчики осознали, что перспективы у операционной системы CP/M нет, поэтому они решили разрабатывать собственную сетевую операционную систему.

Джордж Канова тем временем активно искал инвестиции и в 1983 году компания была преобразована в Novell, Inc., а её главой стал инвестор Рей Нурда.

Таким образом все герои нашего сегодняшнего повествования в итоге собрались под одной крышей и в этом же году выпустили операционную систему NetWare 68 для Motorola 68000, а в 1985 NetWare 86 для Intel 8086.

Для своего времени система оказалась революционной, все что вам нужно было для организации собственной сети – это купить сервер с Novell NetWare и установить на ПК программу-клиент, которая позволяла организовать плоскую сеть с общим доступом к файлам и папкам, что для 1983 года было технологическим прорывом.

Система использовала сетевой стек IPX/SPX разработки Novell, а для доступа к файлам, папкам, печати, синхронизации часов и т.д. использовался протокол NetWare Core Protocol (NCP).

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

В дальнейшем в Novell отказались от поддержки Motorola 68000 и вообще выпуска собственного оборудования, а сосредоточили все усилия на сетевой операционной системе.

В 1986 году после выпуска Intel 80286 появилась NetWare 286, а в 1989 NetWare 386 для процессора Intel 80386, в дальнейшем, на фоне выпуска Windows 3.0 системы были переименованы в NetWare 2.х и NetWare 3.x соответственно.
Реальных конкурентов в то время у Netware не было, система отличалась простотой, модульностью, скоростью работы и стабильностью, один раз настроенный сервер Netware мог работать годами без вмешательства администратора.

Также Novell обеспечивала серьезное преимущество по производительности, иногда даже в соотношении от 5:1 до 10:1 с основными своими конкурентами.

Лебединой песней стал выпуск NetWare 4.x в которой впервые была представлена собственная служба каталогов NDS (домен) и произошло это в 1993 году. Началась эпоха доминирования NetWare в локальных сетях, а руководство начало почивать на лаврах, что не довело до добра.

Первый звоночек прозвучал в 1994 году с выходом Windows NT 3.5, Novell желая усложнить жизнь основному конкуренту начала затягивать выпуск клиента Novell для Windows NT в результате чего Microsoft написала собственный клиент, который оказался настолько удачным, что продолжал широко использоваться даже после выхода официального клиента.

Но время уже было упущено и было упущено не только оно, внедрение в Windows стека протоколов TCP/IP делало его универсальным клиентом для любых сетей и только увеличивала его популярность.

Разработка модуля NetWare/IP не спасло положение, как и выпуск Netware 5.x с встроенной поддержкой стека TCP/IP. Еще одной проблемой стало то, что Netware предоставлял только файловые службы и не был способен работать в качестве сервера приложений.

А былые преимущества стремительно нивелировались подросшей мощностью железа. Сказалось также и наплевательское отношение к разработчикам под Netware, что серьезно затруднило создание сторонних приложений.

Окончательную точку в истории поставил Windows NT 4.0 Terminal Server, который вышел в 1998 году и позволял сделать то, чего не умел Novell – терминальный сервер. С этого момента популярность Netware неуклонно покатилась вниз.

Последними версиями стали 6.0 (2001) и 6.5 (2003), но они уже ничего не могли изменить.

Какой класс протоколов маршрутизации выбрать в underlay сети ЦОД — EGP vs IGP? 

Узнайте на бесплатном практическом уроке от OTUS, где вы вместе с опытным экспертом:

1. разберетесь с основами underlay сети ЦОД
2. сравните модный EGP и классический IGP
3. рассмотрите различные варианты маршрутизации в underlay сети ЦОД на практике

Вебинар будет полезен для всех, кто интересуется компьютерными сетями, действующих специалистов по маршрутизации и коммутации и сетевых инженеров ЦОД.

Занятие пройдёт 10 апреля в 20:00 мск и будет приурочено к старту курса «Дизайн сетей ЦОД».

Доступна рассрочка на обучение!

Пройдите короткий тест прямо сейчас, чтобы занять место на открытом уроке и получить запись:  https://clck.ru/39s9MF  

​​Как скачать DEB-пакет со всеми зависимостями

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

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

Все скачанные пакеты система размещает в каталоге /var/cache/apt/archives и там, кроме интересующих нас пакетов могут быть и разные другие, поэтому перед скачиванием нужно будет очистить кеш пакетов.

apt clean

После чего перейдем к скачиванию:

 

apt reinstall --download-only package_name

Почему именно reinstall? Потому что install будет работать только для неустановленных пакетов, а если пакет уже установлен в системе, то она сообщит об этом и не будет производить установку (в нашем случае скачивание, а reinstall скачает пакеты в любом случае.

Если вам нужны пакеты другой архитектуры, то ее сначала нужно включить и обновить список пакетов:

dpkg --add-architecture i386
apt update

После чего точно также делаем:

apt reinstall --download-only package_name:i386

После чего переходим в /var/cache/apt/archives и копируем скачанные пакеты на любой съемный носитель и может передать их любым удобным способом в нужную систему для установки.

​​Зависимости DEB-пакетов

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

Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки.

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

Если в процессе настройки dpkg обнаруживает неудовлетворенные зависимости, то он прекращает настройку и пакет остается распакованным, но не настроенным, мы можем попытаться удовлетворить зависимости и заново попытаться настроить пакет.

Но так как разрешение зависимостей дело непростое, то были придуманы высокоуровневые инструменты, такие как apt-get и apt, задача которых – построить дерево зависимостей, скачать их все и передать для установки тому же dpkg.

Посмотреть зависимости можно командой:

apt-cache depends package_name

И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:

▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.

▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.

▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.

▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.

▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.

▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.

▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.

▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.

Как мы уже говорили выше, высокоуровневые менеджеры автоматически разрешают зависимости с типом: предзависит, зависит, конфликтует, заменяет, ломает и предоставляет.

Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.

Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.

Так вот, так делать можно, но не нужно. Потому что в этом случае пакеты будут считаться установленными интерактивно и не будут удаляться командой autoremove после удаления основного пакета.

IT-управленцы, не вздумайте начинать проекты, пока этого не узнаете!

Если хотите сохранить себе время и нервы, приходите на вебинар «Интеграции без пожаров. Искусство слабой связанности IT-контура».

Вы получите пошаговый план снижения связанности IT-контура, чтобы:

💻 Контролировать и управлять нагрузкой на IT-системы

💻 Легко менять/дорабатывать одни системы без доработки других

💻 Избавиться от единой точки отказа

💻 Внедрять изменения небольшими этапами, но с ощутимым результатом

Вебинар 12 апреля проведут наши друзья KT.Team.👇

Команда разрабатывает и интегрирует IT-решения для крупных клиентов уже 11 лет и входит в ТОП 100 IT-компаний России (по версии Tagline и RUWARD).

ЗАРЕГИСТРИРОВАТЬСЯ БЕСПЛАТНО

​​Версии PowerShell

PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.

На сегодняшний день существуют две версии PowerShell:

🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1

🔹 PowerShell Core – основан на .NET Core, является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell Core нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell Core 7.х разработчиками заявлена максимальная совместимость.

Windows PowerShell имеет следующие выпуски:

▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709

В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell Core.

PowerShell Core имеет следующие выпуски:

▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell

▫️ PowerShell Core 7.х на базе .NET Core 3.x, заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.

PowerShell Core можно получить с официальной страницы на Github, через WinGet или из магазина Windows.

Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.

Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell Core следует использовать Visual Studio Code.

​​Обновление Windows PowerShell

Как мы уже говорили в предыдущей заметке Windows PowerShell поставлялась вместе с ОС Windows и Windows Server и обновлялась с каждым новым выпуском ОС. Однако внутри выпуска обновление данного инструмента не было предусмотрено, поэтому в хозяйстве администратора может оказаться самый настоящий зоопарк из версий Windows PowerShell.

Это, разумеется, очень нехорошо и неправильно, так как одни и те же скрипты и командлеты в разных системах могут вести себя по-разному. Поэтому имеет смысл везде обновить Windows PowerShell до последней версии 5.1

Для примера мы возьмем Windows Server 2008 R2, который хоть и снят с поддержки, но местами еще продолжает использоваться. Нам же он интересен как наиболее старая система и если у нас на ней все получится, то получится и на более новых.

Прежде всего узнаем текущую версию командой

host

В нашем случае мы получили вполне ожидаемое:

Version: 2.0

Поэтому начнем, прежде всего идем сюда https://www.microsoft.com/en-us/download/details.aspx?id=54616 и скачиваем Windows Management Framework 5.1 для вашей ОС.

Заглянув в системные требования уточняем, что нам также потребуется .NET Framework 4.5 или выше, качаем подходящую версию со страницы https://dotnet.microsoft.com/en-us/download/dotnet-framework, при этом также учитываем совместимость версии .NET с вашей системой, в данном случае мы скачали .NET Framework 4.5.2

Начинаем установку с обновления .NET Framework, после чего перезагружаем компьютер.

Теперь можно установить Windows Management Framework 5.1, после чего потребуется выполнить перезагрузку еще раз.

После чего еще раз проверяем версию Windows PowerShell и убеждаемся, что у нас стоит последняя актуальная версия.

Данную операцию мы рекомендуем выполнить на всех поддерживаемых системах чтобы привести среду Windows PowerShell к единой версии и избежать ошибок и неоднозначного поведения ваших PS-скриптов.

Присоединяйтесь к нашему бесплатному курсу и начните увлекательное путешествие в мир Java!

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

🎓 Чему вы научитесь:
— Создавать программы с использованием основных конструкций языка.
 — Разделять код на методы для повторного использования.
 — Анализировать ошибки в коде с использованием отладочной печати.

💼 Включено в курс:
29 уроков (видео и/или текст), 35 упражнений в тренажере, 95 проверочных тестов + дополнительные материалы.

Вы с нами?😉

Настройка файлового сервера ksmbd на платформе Debian / Ubuntu

Долгое время для организации файлового сервера, работающего по протоколу SMB, в Linux не было альтернативы Samba, но с недавних пор ситуация изменилась.

Начиная с ядра 5.15 в Linux появился новый модуль ядра - ksmbd - реализующий функции SMB-сервера. В отличии от Samba, которая имеет кроме файлового сервера широкий набор дополнительных функций, ksmbd, наоборот, только файловый сервер, простой и нетребовательный к ресурсам.

https://interface31.ru/tech_it/2023/06/nastroyka-faylovogo-servera-ksmbd-na-platforme-debian-ubuntu.html

​​Что такое PowerShell и чем он отличается от своих аналогов

Результат вчерашнего опроса нас немного удивил, практически треть опрошенных призналась, что не использует PowerShell. Что довольно неожиданно, игнорировать столь мощный инструмент – идея далеко не самая лучшая.

Возможно, что не все до конца представляют, чем является из себе PowerShell и чем он отличается от своих аналогов.

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

Впервые они были заданы в стандарте POSIX (ISO/IEC 9945) (Том 3. Оболочка и утилиты) , который предписывал языкам оболочки иметь конструкции последовательного, условного и циклического исполнения команд, а также оператор присваивания.

К таким языкам до сих пор относятся bash и аналоги, а также CMD. Несмотря на различные возможности – это все типичные скриптовые языки оболочки. Со своими типичными возможностями и ограничениями.

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

Я думаю, что любой, кто писал сложные скрипты на том же bash с этим сталкивался. Поэтому при определенном уровне сложности многие начинают переходить на скриптовые языки общего назначения с объектной моделью, например, Python.

Основное отличие объекта от текста в том, что объект имеет свои свойства и методы, к которым мы можем обращаться без всякого парсинга просто зная их наименование. Например, чтобы посмотреть условный статус объекта нам достаточно прочитать свойство Объект.Статус.

Это весьма грубая и упрощенная модель, но достаточная для базового понимания сути.

Так вот, при разработке PowerShell было принято решение реализовать в нем объектную модель. Таким образом PowerShell, хоть и является языком оболочки, но по функциональным возможностям гораздо ближе к скриптовым языкам общего назначения, таким как Python.

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

И этот момент вызывает у многих недоумение, так как PowerShell является одной из оболочек командной строки и языком этой оболочки. А отличительная особенность языков оболочек – это короткие команды, которые легко запомнить и быстро вводить.

Но у этой медали есть и обратная сторона. Скрипты на таких языках очень трудно читаются, особенно если вы не помните наизусть всех команд и их ключей. Очень часто код приходится читать буквально «со словарем».

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

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

Что касается порога входа в PowerShell, то он тоже гораздо выше, на уровне скриптовых языков, но его изучение того стоит, так как открывает гораздо более широкие возможности по взаимодействию с системой, особенно учитывая глубокую интеграцию в нее посредством .NET.

Добавьте в свое портфолио кейс по решению задачи с микросервисной архитектурой бесплатно и всего за пару часов

На практическом уроке «Масштабируемая архитектура для систем обработки платежей».

На вебинаре:
- рассмотрим решение задачи по построению масштабируемой отказоустойчивой системы обработки платежей;
- обсудим применения шардирования, паттерна Saga, двухфазного коммита и выбор уровня изоляции транзакций;
- получим описание верхнеуровневой архитектуры.

Занятие пройдёт 24 апреля в 20:00 мск в рамках курса «Microservice Architecture». Доступна рассрочка на обучение!

👉 Чтобы посетить открытый урок, зарегистрируйтесь: https://otus.pw/VyJ7N/?erid=LjN8KBj18