​​Найден способ бесплатно продлить установку патчей для Windows 7

Сообщество специалистов, оказывающих техническую поддержку на форуме My Digital Life, нашло способ обойти установленные Microsoft ограничения на загрузку обновлений безопасности для системы Windows 7. Ранее необходимо было заплатить, чтобы продлить срок выпуска патчей, теперь же любой пользователь устаревшей ОС может воспользоваться пролонгированной поддержкой.

Напомним, что официальная дата окончания срока поддержки Windows 7 — 14 января 2020 года. В этой связи Microsoft предложила модель Windows 7 Extended Security Updates (ESU) — платная услуга, которая может продлить выпуск патчей для этой версии системы до 2023 года. ESU может стоить от $25 до $200 за одну машину (Enterprise или Pro). При этом стоит учитывать, что воспользоваться ESU сможет далеко не каждая компания.

Как же обойти установленные Microsoft ограничения? В прошлом месяце корпорация выпустила апдейт Windows 7 ESU (KB4528069), который должен помочь администраторам понять, подходят ли их системы для программы продлённого выпуска обновлений. При установке KB4528069 пользователь должен предоставить лицензионный ключ ESU, который в дальнейшем будет использоваться для верификации выходящих патчей. И вот тут вклинились специалисты My Digital Life, создавшие специальный инструмент BypassESU, обходящий процесс проверки ключа ESU. Благодаря этому установить тестовый апдейт может любой пользователь.

➡️ https://nsprg.ru/taghd

​​Компания Mozilla представила движок распознавания речи DeepSpeech 0.6

Представлен выпуск развиваемого компанией Mozilla движка распознавания речи DeepSpeech 0.6, который реализует одноимённую архитектуру распознавания речи, предложенную исследователями из компании Baidu. Реализация написана на языке Python с использованием платформы машинного обучения TensorFlow и распространяется под свободной лицензией MPL 2.0. Поддерживается работа в Linux, Android, macOS и Windows. Производительности достаточно для использования движка на платах LePotato, Raspberry Pi 3 и Raspberry Pi 4.

В наборе также предлагаются обученные модели, примеры звуковых файлов и инструментарий для распознавания из командной строки. Для встраивания функции распознавания речи в свои программы предложены готовые к применению модули для Python, NodeJS, C++ и .NET (сторонними разработчиками отдельно подготовлены модули для Rust и Go). Готовая модель поставляется только для английского языка, но для других языков по прилагаемой инструкции можно обучить систему самостоятельно, используя голосовые данные, собранные проектом Common Voice.

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

Обратной стороной подобного подхода является то, что для получения качественного распознавания и обучения нейронной сети движок DeepSpeech требует большого объёма разнородных данных, надиктованных в реальных условиях разными голосами и при наличии естественных шумов. Сбором подобных данных занимается созданный в Mozilla проект Common Voice, предоставляющий проверенный набор данных с 780 часами на английском языке, 325 на немецком, 173 на французском и 27 часами на русском.

Конечной целью проекта Common Voice является накопление 10 тысяч часов c записями различного произношения типовых фраз человеческой речи, что позволит достичь приемлемого уровня ошибок при распознавании. В текущем виде участниками проекта уже надиктовано в сумме 4.3 тысячи часов, из которых 3.5 тысячи прошли проверку. При обучении итоговой модели английского языка для DeepSpeech использовано 3816 часов речи, кроме Common Voice охватывающей данные от проектов LibriSpeech, Fisher и Switchboard, а также включающей около 1700 часов транскрибированных записей радиошоу.

При использовании предлагаемой для загрузки готовой модели английского языка уровень ошибок распознавания в DeepSpeech составляет 7.5% при оценке тестовым набором LibriSpeech. Для сравнения, уровень ошибок при распознавании человеком оценивается в 5.83%.

DeepSpeech состоит из двух подсистем - акустической модели и декодировщика. Акустическая модель использует методы глубинного машинного обучения для вычисления вероятности наличия определённых символов в подаваемом на вход звуке. Декодировщик применяет алгоритм лучевого поиска для преобразования данных о вероятности символов в текстовое представление.

➡️ https://nsprg.ru/3p0xw

​​Началось общее голосование о системах инициализации в Debian

Проект Debian объявил о начале общего голосования (GR, general resolution) разработчиков проекта по вопросу поддержки нескольких систем инициализации, которое определит дальнейшую политику проекта в отношении привязки к systemd, поддержки альтернативных систем инициализации и взаимодействия с производными дистрибутивами, не использующими systemd. Голосование продлится до 27 декабря включительно, итоги будут подведены 28 декабря.

Напомним, что в 2014 году технический комитет утвердил переход дистрибутива по умолчанию на systemd, но не выработал решения по отношению к поддержке нескольких систем инициализации (при голосование победил пункт, указывающий на неготовность комитета вынести решение по данному вопросу). Лидер комитета порекомендовал сопровождающим пакеты сохранить поддержку sysvinit в качестве альтернативной системы инициализации, но указал, что не может навязывать свою точку зрения и в каждом случае решение следует принимать самостоятельно.

После этого некоторыми разработчиками была предпринята попытка проведения общего голосования, но предварительное голосование показало отсутствие необходимости принятия решения по вопросу использования нескольких систем инициализации. Несколько месяцев назад, после проблем с включением пакета elogind (необходим для работы GNOME без systemd) в ветку testing из-за конфликта с libsystemd, вопрос был повторно поднят лидером проекта Debian, так как разработчики не смогли договориться, а их общение переросло в противостояние и зашло в тупик.

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

Предложенные варианты:

1. Основное внимание фокусируется на systemd. Предоставление поддержки альтернативных систем инициализации не является приоритетом, но сопровождающие вправе опционально включать в пакеты init-скрипты для таких систем.
2. Поддержка разнообразных систем инициализации и возможность загрузки Debian с системами инициализации, отличными от systemd. Для запуска сервисов пакеты обязательно должны включать init-скрипты, поставка только unit-файлов systemd без sysv init-скриптов недопустима.
3. Предпочитаемым остаётся systemd, но оставляется возможность сопровождения и альтернативных систем инициализации. Технологии, такие как elogind, позволяющие в альтернативных окружениях запускать приложения, привязанные к systemd, рассматриваются как важные. В пакеты допускается включение init-файлов для альтернативных систем.
4. Поддержка систем, не использующих systemd, но без внесения изменений, мешающих развитию. Разработчики соглашаются поддерживать несколько систем инициализации в обозримом будущем, но также считают необходимым работать над улучшением поддержки systemd. Разработкой и сопровождением специфичных решений следует заниматься заинтересованным в таких решениях сообществам, но другие мэйнтейнеры должны активно помогать и способствовать решению проблем, когда в этом возникает необходимость. В идеале пакеты должны функционировать при использовании любой системы инициализации, для чего можно поставлять традиционные init-скрипты или использовать иные механизмы, позволяющие работать без systemd. Невозможность работы без systemd рассматривается как ошибка, но не как ошибка блокирующая релиз, за исключением случаев, когда имеется готовое решение для работы без systemd, но его отказываются сохранять (например, когда проблема вызвана удалением ранее поставлявшегося init-скрипта).

➡️ https://nsprg.ru/3br4s

​​Уязвимость, позволяющая вклиниваться в TCP-соединения, осуществляемые через VPN-туннелиОпубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели. Проблема затрагивает Linux, FreeBSD, OpenBSD, Android, macOS, iOS и другие Unix-подобные системы. Linux поддерживает механизм rp filter (reverse path filtering) для IPv4, включение которого в режим "Strict" нейтрализует данную проблему.

Метод позволяет осуществить подстановку пакетов на уровне TCP-соединений, проходящих внутри шифрованного туннеля, но не позволяет вклиниваться в соединения, применяющие дополнительные слои шифрования (например, TLS, HTTPS, SSH). Применяемые в VPN алгоритмы шифрования не имеют значения, так как поддельные пакеты поступают из внешнего интерфейса, а обрабатываются ядром как пакеты из VPN-интерфейса. Наиболее вероятной целью атаки является вмешательство в незашифрованные соединения HTTP, но не исключается и использование атаки для манипуляция с ответами DNS.

Успешная подмена пакетов продемонстрирована для туннелей, создаваемых при помощи OpenVPN, WireGuard и IKEv2/IPSec.Tor проблеме не подвержен, так как использует SOCKS для проброса трафика и привязку к loopback-интерфейсу. Для IPv4 атака возможна в случае перевода rpfilter в режим "Loose" (sysctl net.ipv4.conf.all.rp filter = 2). Изначально в большинстве систем применялся режим "Strict", но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на "Loose" и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.

➡️ https://nsprg.ru/msu4n

​​Android может лишиться одного из преимуществ над iOSОдно из преимуществ мобильной ОС Android — возможность беспроблемной установки приложений из любых удобных источников. Но вскоре ситуация может измениться — по данным инсайдеров, в новой версии системы защиты Advanced Protection появится функция ограничения доступа к программам, опубликованным за пределами магазина Google Play.
Google Advanced Protection Program

Упоминание готовящегося нововведения обнаружилось в новой бета-версии программы Advanced Protection Program для Google Play. Опубликованные ими комментарии кода содержат фразы «для дополнительной безопасности Advanced Protection не позволит использование приложений, загруженных вне магазина Google Play» и «приложение заблокировано Advanced Protection». Сейчас сторонние приложения уже проходят проверку системой защиты Google Play Protect, которая предотвращает установку подозрительных программ.

Хотя участие в программе не обязательно для разработчиков, в перспективе они смогут использовать программу безопасности Google в качестве DRM-защиты, публикуя вне Google Play только часть приложений. Учитывая, что речь идёт о бета-версии, до изменения политики магазина приложений может пройти ещё несколько месяцев, либо данная функция вообще не будет реализована. Компания Google утечку официально не прокомментировала.

➡️ https://nsprg.ru/ntlhx

​​Уязвимости в OpenBSD, позволяющие повысить привилегии и обойти аутентификацию в smtpd, ldapd и radiusd

Компания Qualys выявила четыре уязвимости в OpenBSD, одна из которых позволяет удалённо подключиться без аутентификации к некоторым сетевым сервисам, а три остальные повысить свои привилегии в системе. В отчёте Qualys отмечена быстрая реакция разработчиков OpenBSD - все проблемы были устранены в OpenBSD 6.5 и OpenBSD 6.6 в течение 40 часов после приватного уведомления.

Удалённо эксплуатируемая уязвимость вызвана ошибкой при организации вызова обработчика аутентификации в библиотеке libc, которая вызывает программу /usr/libexec/auth/loginstyle с передачей аргументов в командной строке. В том числе при вызове loginstyle при помощи опционального параметра "-s service" допускается передача названия протокола. В случае использования в начале имени пользователя символа "-", данное имя будет обработано как опция при запуске loginstyle. Соответственно, если указать при аутентификации в качестве имени пользователя "-schallenge" или "-schallenge:passwd" то loginstyle воспримет обращение как запрос использования обработчика S/Key.

Проблема в том, что протокол S/Key в loginstyle поддерживается лишь формально, а фактически игнорируется с выводом признака успешной аутентификации. Таким образом, атакующий может, представившись пользователем "-schallenge", обойти аутентификацию и получить доступ без указания пароля или ключей. Потенциально проблеме подвержены все сетевые сервисы, использующие штатные вызовы libc для проведения аутентификации. Например, возможность обращения в обход аутентификации подтверждена в smtpd (AUTH PLAIN), ldapd и radiusd.

В sshd уязвимость не проявляется, так как в нём имеется дополнительная защита с проверкой присутствия пользователя в системе. Тем не менее, sshd можно использовать для проверки подверженности системы уязвимости - при обращении с именем пользователя "-sresponse:passwd" соединение зависает, так как sshd ждёт от loginpasswd возвращения параметров вызова (challenge), а loginpasswd ждет передачи недостающих параметров (имя "-sresponse" воспринимается как опция). Потенциально локальный атакующий может попытаться обойти аутентификацию в утилите su, но передача имени "-sresponse" приводит к краху процесса из-за возвращения нулевого указателя при выполнении функции getpwnamr("-schallenge", ...).

Другие уязвимости:

- CVE-2019-19520 - локальное повышение привилегий через манипуляции с утилитой xlock, поставляемой с флагом sgid, меняющим группу на "auth". В коде xlock переопределение путей к библиотекам запрещается только при смене идентификатора пользователя (suid), что позволяет атакующему изменить переменную окружения "LIBGLDRIVERSPATH" и организовать загрузку своей разделяемой библиотеки, код которой будет выполнен после повышения привилегий до группы "auth".
- CVE-2019-19522 - позволяет локальному пользователю, входящему в группу "auth", запустить код с правами root при включении в системе аутентификации через S/Key или YubiKey (по умолчанию не активны). Вхождение в группу "auth", доступ к которой может быть получен через эксплуатацию вышеотмеченной уязвимости в xlock, позволяет записать файлы в каталоги /etc/skey и /var/db/yubikey. Например, атакующий может добавить новый файл /etc/skey/root для генерации одноразовых ключей для аутентификации под пользователем root через S/Key.

➡️ https://nsprg.ru/vis08

​​В каталоге Python-пакетов PyPI выявлены две вредоносные библиотеки

В каталоге Python-пакетов PyPI (Python Package Index) обнаружены вредоносные пакеты "python3-dateutil" и "jeIlyfish", которые были загружены одним автором olgired2017 и маскировались под популярные пакеты "dateutil" и "jellyfish" (отличается использованием символа "I" (i) вместо "l" (L) в названии). После установки указанных пакетов на сервер злоумышленника отправлялись найденные в системе ключи шифрования и конфиденциальные данные пользователя. В настоящее время проблемные пакеты уже удалены из каталога PyPI.

Непосредственно вредоносный код присутствовал в пакете "jeIlyfish", а пакет "python3-dateutil" использовал его в качестве зависимости. Названия были выбраны из расчёта на невнимательных пользователей, допускающих опечатки при поиске (тайпсквоттинг). Вредоносный пакет "jeIlyfish" был загружен около года назад — 11 декабря 2018 года и оставался незамеченным. Пакет "python3-dateutil" был загружен 29 ноября 2019 года и через несколько дней вызвал подозрение у одного из разработчиков. Информация о числе установок вредоносных пакетов не приводится.

Пакет jellyfish включал в себя код, загружающий список хэшей из внешнего репозитория на базе GitLab. Разбор логики работы с этими хэшами показал, что они содержат скрипт, закодированный при помощи функции base64 и запускаемый после декодировки. Скрипт находил в системе ключи SSH и GPG, а также некоторые типы файлов из домашнего каталога и учётные данные для проектов PyCharm, после чего отправлял их на внешний сервер, запущенный в облачной инфраструктуре DigitalOcean.

➡️ https://nsprg.ru/vci0s

​​15 уязвимостей в USB-драйверах, поставляемых в ядре Linux

Андрей Коновалов из компании Google опубликовал отчёт о выявлении очередных 15 уязвимостей (CVE-2019-19523 - CVE-2019-19537) в USB-драйверах, предлагаемых в ядре Linux. Это третья порция проблем, найденных при проведении fuzzing-тестирования USB-стека в пакете syzkaller - ранее данный исследователь уже сообщал о наличии 29 уязвимостей.

На этот раз в списке включены только уязвимости, вызванные обращением к уже освобождённым областям памяти (use-after-free) или приводящие к утечке данных из памяти ядра. Проблемы, которые могут использоваться для отказа в обслуживании в отчёт не включены. Уязвимости потенциально могут быть эксплуатируемы при подключении к компьютеру специально подготовленных USB-устройств. Исправления для всех упомянутых в отчёте проблем уже включены в состав ядра, но некоторые не вошедшие в отчёт ошибки пока остаются неисправленными.

Также можно отметить выявление четырёх уязвимостей (CVE-2019-14895, CVE-2019-14896, CVE-2019-14897, CVE-2019-14901) в драйвере для беспроводных чипов Marvell, которые могут привести к переполнению буфера. Атака может быть совершена удалённо через отправку определённым образом оформленных кадров при соединении с беспроводной точкой доступа злоумышленника. В качестве наиболее вероятной угрозы отмечается удалённый отказ в обслуживании (крах ядра), но не исключается и возможность выполнения кода в системе.

➡️ https://nsprg.ru/vci0s

​​Microsoft развивает новый язык программирования на основе Rust

Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.

Рассматривается возможность использования развиваемого языка в том числе для переработки низкоуровневых компонентов Windows с целью блокирования потенциальных проблем, всплывающих при применении языков C и C++. Безопасность кода повышается за счёт автоматического управления памятью, которое избавит разработчиков от необходимости манипулирования указателями и защитит от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.

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

➡️ https://nsprg.ru/zg6t3

​​Новая версия Kali Linux умеет маскироваться под Windows 10

Релиз Kali Linux 2019.4 состоялся на прошлой неделе. Новая версия отметилась режимом «Undercover», позволяющим быстро сделать рабочий стол Kali похожим на Windows 10. Как известно, Kali является Linux-дистрибутивом, созданным специально для этичных хакеров и пентестеров. Обычно исследователи задействуют Kali для тестирования систем безопасности организаций.

Есть мнение, что использующий Kali человек может вызвать подозрение в общественных местах. Именно поэтому разработчики реализовали режим «Undercover» в Kali Linux 2019.4.

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

«Скажем, вы работаете в общественном месте, прорабатываете схемы взлома, но при этом не хотите, чтобы кто-то увидел логотип Kali и задался вопросом: чем вы занимаетесь. Именно поэтому мы написали небольшой скрипт, который поменяет вид вашего Kali на схожую с Windows тему», — пишут программисты. «В результате вы сможете работать более незаметно, а когда окажетесь в более уединённой обстановке, запустите скрипт ещё раз — вы вернётесь к стандартному виду Kali».

Чтобы активировать вышеупомянутый скрипт, произведите следующие действия: Откройте терминал. Введите kali-undercover и нажмите «Enter».

➡️ https://nsprg.ru/z1578