Разработчики исправили серьезную уязвимость в OpenSSH

Олег Иванов 14 Ноября 2017 - 12:20

...

Разработчики исправили серьезную уязвимость в OpenSSH

Уязвимость OpenSSH была обнаружена экспертом Михал Залевски (Michal Zalewski) в файле-исходнике sftp-server.c, она затрагивает версии OpenSSH с 5.5 по 7.6.

Как можно видеть в коде, приведенном ниже, если SFTP-сервер стартует с параметром –R, он будет включать переменную «readonly». Это означает, что клиентам не разрешено записывать операции.

int
sftp_server_main(int argc, char **argv, struct passwd *user_pw)
{
   ...
    while (!skipargs && (ch = getopt(argc, argv,
        "d:f:l:P:p:Q:u:cehR")) != -1) {
        switch (ch) {
    ...
        case 'R':
            readonly = 1;
            break;
    ...
}

Открытие файла для SFTP-сервера выполняется с помощью вспомогательной функции process_open(), которая открывает доступные только для чтения файлы:

static void
process_open(u_int32_t id)
{
    ...
    if (readonly &&
        ((flags & O_ACCMODE) == O_WRONLY ||
        (flags & O_ACCMODE) == O_RDWR) != 0)) {
        verbose("Refusing open request in read-only mode");
        status = SSH2_FX_PERMISSION_DENIED;
    } else {
        fd = open(name, flags, mode);
    ...
}

Здесь можно увидеть, что если «readonly» активирован, будет осуществляться проверка наличия «WRITE ONLY» или «READ/WRITE». Если это условие удовлетворено, будет выведена ошибка открытия файла в режиме read-only.

В противном случае файл будет открыт с использованием системного вызова open(). Залевски использовал эти параметры для создания произвольных read-only-файлов на SFTP-сервере. Чтобы исправить эту брешь, только для чтения. Чтобы исправить это, разработчики.

Код патча можно увидеть ниже:

if (readonly &&
-       ((flags & O_ACCMODE) == O_WRONLY ||
-       (flags & O_ACCMODE) == O_RDWR)) {
+       ((flags & O_ACCMODE) != O_RDONLY ||
+       (flags & (O_CREAT|O_TRUNC)) != 0)) {
        verbose("Refusing open request in read-only mode");

Следующая главная новость »

Identity Security 2026: как защитить доступ до компрометации?
Регистрируйтесь на эфир!

Екатерина Быстрова 13 Марта 2026 - 19:44

Трояны Домашние пользователи Персональный VPN Microsoft

Поддельные VPN в поисковой выдаче крадут учётные данные

Microsoft раскрыла детали новой кампании по краже учётных данных, в которой злоумышленники распространяют поддельные VPN-клиенты через SEO: продвигают вредоносные сайты в поисковой выдаче под видом легитимных страниц загрузки. Эту активность Microsoft отслеживает под кодовым именем Storm-2561.

Схема довольно неприятная и при этом очень житейская. Пользователь ищет в поисковике корпоративный VPN-клиент, видит сверху вроде бы знакомый результат, переходит на сайт-двойник и скачивает ZIP-архив с «установщиком».

На деле внутри оказывается троянизированный MSI-файл, который маскируется под легитимный VPN-клиент и во время установки подгружает вредоносные DLL-библиотеки.

Microsoft отдельно отмечает, что в этой кампании использовались домены вроде vpn-fortinet[.]com и ivanti-vpn[.]org, а вредоносные архивы размещались в GitHub-репозиториях, которые позже были удалены.

Дальше всё строится на доверии пользователя к знакомому интерфейсу. Фальшивый клиент показывает очень правдоподобное окно входа, похожее на настоящее приложение Pulse Secure, просит ввести логин и пароль, а затем отправляет эти данные на сервер злоумышленников. После этого жертве показывают сообщение об ошибке и предлагают скачать уже «настоящий» VPN-клиент. В некоторых случаях пользователя даже перенаправляют на легитимный сайт, так что заражение можно и не заметить.

Для кражи данных используется вариант инфостилера Hyrax. Он вытаскивает не только введённые учётные данные, но и сохранённую VPN-конфигурацию, включая сведения из файла connectionstore.dat. Закрепление в системе обеспечивается через ключ реестра RunOnce, чтобы вредоносный компонент запускался и после перезагрузки устройства.

По данным Microsoft, Storm-2561 активна как минимум с мая 2025 года и уже известна использованием SEO poisoning и подделкой популярных программных брендов. Компания также сообщила, что вредоносные компоненты были подписаны действительным цифровым сертификатом на имя Taiyuan Lihua Near Information Technology Co., Ltd., но этот сертификат уже отозван.

Identity Security 2026: как защитить доступ до компрометации?
Регистрируйтесь на эфир!