Електронната търговия пред нов риск – атаки без автентикация

Новоразкрита уязвимост, наречена PolyShell, засяга всички стабилни версии 2 на Magento Open Source и Adobe Commerce, като позволява изпълнение на код от разстояние (RCE) и компрометиране на потребителски акаунти без необходимост от автентикация.

Въпреки че към момента няма потвърдени активни атаки, експертите предупреждават, че експлойт методът вече циркулира, което означава, че масови автоматизирани атаки са въпрос на време.

Как работи PolyShell: злоупотреба с REST API и качване на файлове

Уязвимостта произтича от начина, по който Magento обработва заявки към своя REST API при добавяне на продукти в количката.

Конкретният проблем:

• Поддържат се custom опции от тип „file“

• Системата приема base64 кодирани файлове чрез file_info обект

• Качените файлове се записват в директория:
  pub/media/custom_options/quote/

Тази функционалност позволява качване на зловредни файлове, които при определени условия могат да бъдат изпълнени.

Polyglot файлове: невидимата заплаха

Името PolyShell идва от използването на polyglot файлове – файлове, които могат да функционират едновременно като:

• Валидно изображение

• Изпълним скрипт

Това позволява заобикаляне на стандартни защитни механизми, които проверяват само типа на файла.

В зависимост от конфигурацията на сървъра:

• Може да се постигне пълно RCE

• Или stored XSS, водещ до превземане на акаунти

Реалният риск: масово изложени среди

Анализът показва, че:

• Много Magento инсталации позволяват достъп до upload директорията

• Често липсват ефективни ограничения на ниво уеб сървър

• Хостинг конфигурациите варират и не винаги следват добри практики

Това прави уязвимостта широко експлоатируема в реални условия.

Проблемът с пачовете: защита само в alpha версия

Компанията Adobe вече е разработила корекция, но тя е налична само в:

• alpha версия 2.4.9 (втора alpha компилация)

Това означава, че:

• Продукционните среди остават уязвими

• Организациите трябва да разчитат на временни мерки

Препоръки: как да се намали рискът преди официален пач

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

• Ограничаване на достъпа до pub/media/custom_options/

• Проверка на конфигурациите на nginx/Apache

• Забрана за изпълнение на скриптове в upload директории

• Сканиране за:

  • Web shell файлове

  • Backdoor-и

  • Подозрителни качени файлове

Supply chain и конфигурациите като слабост

PolyShell подчертава един системен проблем:

Сигурността на платформата често зависи не само от кода, а от конфигурацията на средата.

В случая:

• Уязвимостта е в приложението

• Но експлоатацията зависи от сървърната конфигурация

• А тя често се управлява от трети страни (хостинг доставчици)

Уязвимост с потенциал за масови атаки

PolyShell има всички характеристики на високорискова уязвимост с потенциал за масова експлоатация:

• Без нужда от автентикация

• Лесна автоматизация

• Широко разпространени засегнати системи

Липсата на официален production пач допълнително увеличава риска, превръщайки следващите седмици в критичен период за електронната търговия.