Suicide
29.03.2021, 20:51
В NPM-пакете node-netmask (https://www.npmjs.com/package/netmask), насчитывающем около 3 млн загрузок в неделю и используемом в качестве зависимости у более 270 тысяч проектов (https://github.com/rs/node-netmask/network/dependents?package_id=UGFja2FnZS00OTM0NjU5NDU) на GitHub, выявлена (https://sick.codes/universal-netmask-npm-package-used-by-270000-projects-vulnerable-to-octal-input-data-server-side-request-forgery-remote-file-inclusion-local-file-inclusion-and-more-cve-2021-28918/) уязвимость (https://github.com/sickcodes/security/blob/master/advisories/SICK-2021-011.md) (CVE-2021-28918), позволяющая обойти проверки, в которых сетевая маска используется для определения вхождения в диапазоны адресов или для фильтрации. Проблема устранена в выпуске node-netmask 2.0.0 (https://github.com/rs/node-netmask/releases/tag/2.0.0).
Уязвимость позволяет добиться обработки внешнего IP-адреса как адреса из внутренней сети и наоборот, а при определённой логике использования модуля node-netmask в приложении совершить атаки SSRF (https://en.wikipedia.org/wiki/Server-side_request_forgery) (Server-side request forgery),RFI (https://en.wikipedia.org/wiki/File_inclusion_vulnerability#Remote_file_inclusion ) (Remote File Inclusion) и LFI (https://en.wikipedia.org/wiki/File_inclusion_vulnerability#Local_file_inclusion) (Local File Inclusion) для обращения к ресурсам во внутренней сети и включения в цепочку выполнения внешних или локальных файлов. Проблема заключается в том, что в соответствии со спецификацией (https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02) строковые значения адресов, начинающиеся с нуля, должны интерпретироваться как восьмеричные числа, но модуль "node-netmask" не учитывает данную особенность и обрабатывает их как десятичные числа.
Например, атакующий может запросить ресурс, указав значение "0177.0.0.1", которое в десятичном представлении соответствует "127.0.0.1" (число 0177 в восьмеричной системе равно 127 в десятичной), но модуль "node-netmask" отбросит ноль, и обработает 0177.0.0.1" как "177.0.0.1". В приложении при оценке правил доступа не будет определена тождественность с "127.0.0.1" и ресурс будет загружен с "0177.0.0.1" (фактически с 127.0.0.1), несмотря на запрет обращения к адресам loopback-интерфейса.
Аналогично при обращении к приложению атакующий может указать адрес "0127.0.0.1", который тождественен "87.0.0.1", но в модуле "node-netmask" будет обработан как "127.0.0.1" (т.е. приложение разрешит доступ к операциям с 127.0.0.1, несмотря на то, что фактически указан внешний адрес). Подобным образом можно обмануть и проверку обращения к интранет адресам, указав значения подобные "012.0.0.1" (эквивалент "10.0.0.1", но при проверке в node-netmask будет обработан как 12.0.0.1).
Выявившие проблему исследователи называют проблему катастрофичной и приводят несколько сценариев атак, но большинство из них выглядят умозрительными. Например, говорится о возможности атаковать приложение на базе Node.js, устанавливающее внешние соединения для запроса ресурса на основе параметров или данных входного запроса, но конкретно приложение не называется и не детализируется. Даже если найти приложения, выполняющие загрузку ресурсов на основе введённых IP-адресов, не совсем ясно, как можно применить сценарий с отдачей фиктивного ресурса без подсоединения к локальной сети или без получения контроля за "зеркальными" IP-адресами.
Исследователи предполагают, что владельцы адресов в подсетях 87.0.0.1/8 и 177.0.0.0/8 имеют возможность обойти ограничение доступа к 127.0.0.1. Более реалистичным сценарием является использование уязвимости для обхода различных списков блокировки, реализованных на стороне приложения. Проблема также может применяться для обмена определения интранет-диапазонов в NPM-модуле "private-ip".
https://d.radikal.ru/d36/2103/f9/fafbf9471328.png (https://radikal.ru)
29.03.2020
https://www.opennet.ru/opennews/art.shtml?num=54857
Уязвимость позволяет добиться обработки внешнего IP-адреса как адреса из внутренней сети и наоборот, а при определённой логике использования модуля node-netmask в приложении совершить атаки SSRF (https://en.wikipedia.org/wiki/Server-side_request_forgery) (Server-side request forgery),RFI (https://en.wikipedia.org/wiki/File_inclusion_vulnerability#Remote_file_inclusion ) (Remote File Inclusion) и LFI (https://en.wikipedia.org/wiki/File_inclusion_vulnerability#Local_file_inclusion) (Local File Inclusion) для обращения к ресурсам во внутренней сети и включения в цепочку выполнения внешних или локальных файлов. Проблема заключается в том, что в соответствии со спецификацией (https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02) строковые значения адресов, начинающиеся с нуля, должны интерпретироваться как восьмеричные числа, но модуль "node-netmask" не учитывает данную особенность и обрабатывает их как десятичные числа.
Например, атакующий может запросить ресурс, указав значение "0177.0.0.1", которое в десятичном представлении соответствует "127.0.0.1" (число 0177 в восьмеричной системе равно 127 в десятичной), но модуль "node-netmask" отбросит ноль, и обработает 0177.0.0.1" как "177.0.0.1". В приложении при оценке правил доступа не будет определена тождественность с "127.0.0.1" и ресурс будет загружен с "0177.0.0.1" (фактически с 127.0.0.1), несмотря на запрет обращения к адресам loopback-интерфейса.
Аналогично при обращении к приложению атакующий может указать адрес "0127.0.0.1", который тождественен "87.0.0.1", но в модуле "node-netmask" будет обработан как "127.0.0.1" (т.е. приложение разрешит доступ к операциям с 127.0.0.1, несмотря на то, что фактически указан внешний адрес). Подобным образом можно обмануть и проверку обращения к интранет адресам, указав значения подобные "012.0.0.1" (эквивалент "10.0.0.1", но при проверке в node-netmask будет обработан как 12.0.0.1).
Выявившие проблему исследователи называют проблему катастрофичной и приводят несколько сценариев атак, но большинство из них выглядят умозрительными. Например, говорится о возможности атаковать приложение на базе Node.js, устанавливающее внешние соединения для запроса ресурса на основе параметров или данных входного запроса, но конкретно приложение не называется и не детализируется. Даже если найти приложения, выполняющие загрузку ресурсов на основе введённых IP-адресов, не совсем ясно, как можно применить сценарий с отдачей фиктивного ресурса без подсоединения к локальной сети или без получения контроля за "зеркальными" IP-адресами.
Исследователи предполагают, что владельцы адресов в подсетях 87.0.0.1/8 и 177.0.0.0/8 имеют возможность обойти ограничение доступа к 127.0.0.1. Более реалистичным сценарием является использование уязвимости для обхода различных списков блокировки, реализованных на стороне приложения. Проблема также может применяться для обмена определения интранет-диапазонов в NPM-модуле "private-ip".
https://d.radikal.ru/d36/2103/f9/fafbf9471328.png (https://radikal.ru)
29.03.2020
https://www.opennet.ru/opennews/art.shtml?num=54857