Volfgang
-
Публикации
73 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем Volfgang
-
-
В админке DLE ремонт базы данных делали? Попробуйте, у меня такое было - после ремонта все ок стало.
-
Хорошо бы, если бы разработчики серьезно обратили внимание на это и как можно быстрее нашли проблему.
Со стороны DLE проблем нет. Почему? Объяснять долго и нужно обладать хорошими знаниями в области PHP. Ни в регистрации, ни в загрузке файлов, DLE не содержит уязвимостей и не содержит проблем.
У нас есть как минимум 3 человека с созданным юзером и следующим за ним взломом, у юзера одинаковое имя и почта.Вряд ли тут дело в PHPmyADMIN или другом ПО.
Т.к. вы не написали какой сайт у вас в взломали, я посмотрел на сайте за какими сайтами у вас лицензии числятся и отправил вам персональным сообщением адреса по которому у стоит уязвимое ПО в открытом виде и без каких либо патчей безопасности. Я незнаю но видимо вы думаете что никто кроме вас не знает структуру панели управления ISP, которая стоит у вас на сайтах? По непонятным причинам вы даже не соизволили предпринять меры которые уже неоднократно были написаны в этой теме. И таких не три человека, таких сотни и уже на протяжении года, и все одно и тоже.
Хорошо, пусть в DLE нет проблем, я спорить не буду, я далеко не так опытен как Вы. Просто смущает тот факт, что взломщик регистрируется перед взломом, следовательно ему нужен юзер на DLE, а это наводит на мысли. Однако, я могу ошибаться, как я уже сказал, я не опытен, поэтому и написал сюда.
В приват получил сообщение, сегодня все исправлю, в любом случае это нужно исправить. Спасибо.
-
у меня также юзер есть wnet с мылом superwnet@ya.ru
Если учесть что юзер wnet с мылом superwnet@ya.ru создавался на взломанных сайтах, можно предположить, что заливка шела все таки связана с регистрацией и наличием юзера в движке бд dle. Если бы уязвимость не была связана с dle, а, например была в серверном по, то и юзера не надо было бы создавать. Так как юзер создан, логично предположить что есть дыра в самом движке.
Полностью с Вами согласен. Хорошо бы, если бы разработчики серьезно обратили внимание на это и как можно быстрее нашли проблему. У нас есть как минимум 3 человека с созданным юзером и следующим за ним взломом, у юзера одинаковое имя и почта. Есть вырезка из логов, где видно, что юзер регнулся и через 28 минут уже сидел через шелл. Вряд ли тут дело в PHPmyADMIN или другом ПО. Да и взломов на форумах других движков нет, если бы дырка была в ПО - пострадали бы админы сайтов на WP или Joomla, но на их форумах ничего нет, я сегодня опять проверял, а на DLE проблема обсуждается активно на многих форумах. Пора искать дырку....
-
1
-
-
celsoft,
о, спасибо!
Отпишитесь потом, что Вам саппорт посоветует. Закидывать одинаковыми обращениями пока не хочется, может есть что-то общее у нас, где-то прав многовато или вроде того
А вообще, бекдоры конечно опасны, но я больше думаю о том, как туда изначально проник шелл, если проник раз, проникнет и два, даже если бекдор удалить, Сначала то бекдора небыло, его туда как-то засунули и точно не через FTP, значит есть обход... -
у меня также юзер есть wnet с мылом superwnet@ya.ru
22 числа регистрация.
Загрузка файлов для зарегистрированных пользлвателей было включена, теперь отключил все, что касается добавления новостей...
У меня тоже такой юзер есть. Регистрация за пол часа до взлома. Заливка разрешена только картинок. Видать знает как обойти.
-
Внесу свои 5 копеек в тему.
В логах было обнаружено следующее:
95.79.105.23 - - [23/Dec/2012:23:03:10 +0100] "GET /index.php?do=register HTTP/1.0" 200 6703
95.79.105.23 - - [23/Dec/2012:23:03:18 +0100] "POST /index.php?do=register HTTP/1.0" 200 6768
95.79.105.23 - - [23/Dec/2012:23:03:18 +0100] "GET /engine/modules/antibot.php HTTP/1.0" 200 3167
95.79.105.23 - - [23/Dec/2012:23:03:25 +0100] "POST /engine/ajax/registration.php HTTP/1.0" 200 179
95.79.105.23 - - [23/Dec/2012:23:03:39 +0100] "POST /index.php?do=register HTTP/1.0" 200 6153
95.79.105.23 - - [23/Dec/2012:23:03:41 +0100] "POST /index.php?do=register HTTP/1.0" 200 5452
95.79.105.23 - - [23/Dec/2012:23:31:28 +0100] "GET /engine/cache/system/minify.php HTTP/1.0" 200 13158
95.79.105.23 - - [23/Dec/2012:23:31:29 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 64708
95.79.105.23 - - [23/Dec/2012:23:31:30 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 21154
95.79.105.23 - - [23/Dec/2012:23:31:31 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 19170
95.79.105.23 - - [23/Dec/2012:23:31:32 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 34334
95.79.105.23 - - [23/Dec/2012:23:31:40 +0100] "GET /engine/cache/system/minify.php HTTP/1.0" 200 13158
95.79.105.23 - - [23/Dec/2012:23:31:43 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 34334
95.79.105.23 - - [23/Dec/2012:23:32:02 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 17540
95.79.105.23 - - [23/Dec/2012:23:32:04 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 20572
95.79.105.23 - - [23/Dec/2012:23:32:06 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 14269
95.79.105.23 - - [23/Dec/2012:23:32:08 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 34334
95.79.105.23 - - [23/Dec/2012:23:33:19 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 13158
95.79.105.23 - - [23/Dec/2012:23:33:22 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 21154
95.79.105.23 - - [23/Dec/2012:23:33:24 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 14261
95.79.105.23 - - [23/Dec/2012:23:33:26 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 14810
95.79.105.23 - - [23/Dec/2012:23:33:27 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 14945
95.79.105.23 - - [23/Dec/2012:23:33:39 +0100] "POST /engine/cache/system/minify.php HTTP/1.0" 200 15466
На следующий день, данная информация из логов пропала.
По данному ip на всех сайтах был зарегистрирован пользователь под ником wnet с имейлом super.wnet@ya.ru
Поиск измененных файлов по дате не дал результатов, тк у шелла стояла дата 2011 года.
Шелл заливался повторно, после запрета регистрации на сайте, взломов обнаружено не было.
Название шелла WSO 2.5. Этот же шелл, был найден еще на нескольких серверах знакомых, с сайтами на дле.
В файл dbconfig.php был добавлен код, который загружал пользователям сайта вирусы.
Надеюсь данная информация окажется полезной.
Как-то такая очередность действий смахивает на дырку в DLE при регистрации
Я конечно не спец, но чисто логически.-
1
-
-
Вопрос тем, у кого обнаружен шел. У вас случайные пользователи могут загружать файлы на сервер?
Только картинки.
http://www.pr-cy.ru/qa/question/12315
пошла прямо волна взломов DLE. Хотя и не глобальная как я понимаю. Возможно сему виной сторонние модули или определенные настройки DLE или php.
Сторонниe модули вряд ли. У меня нету таковых по сути, лишь пара легких хаков, которые добавляют вывод пару простеньких функций, элементарный функционал и слишком спецефический, вряд ли у кого-то есть еще. Скорее всего дырка или у хостеров, например в PHPmyADMIN, как нам указывает уважаемый Celsoft, а может действительно есть в DLE дырка, так как взлом происходит именно на DLE движке, пытался поискать подобные взломы на сайтах с другими движками, у них тихо на форумах. Если проблема в DLE, я думаю патч скоро появится. Хуже, если проблема где-то в ПО сервера, и не факт, что уже есть патч закрывающий это.
-
А вот в сети нашел еще информацию, что dumper уязвимый.
Ссылки:
https://sypex.net/fo....php?f=3&t=1100
http://drupalhosting...BC-%D0%BF%D0%BE
У меня как раз стоял такой скрипт на сайте. Про phpMyAdmin спасибо, обновлюсь.
Про дампер интересно, у меня стоит sypex как раз. Почитал темы, в нем дырок полно, удалю, сдается мне оттуда ноги вырости могли. Господа, у кого еще Sypex стоит из взломанных?
Единственное что заметил, это что в config.php добавили какой то адрес партнерки
Сейчас глянул в свой конфиг файл, там была строчка вписана, которая должна быть автоматически качать обновление браузера если ты заходишь из Android-устройство, короче фейковый блокер/вирус или шпион для Андроид. Я с планшета по своему сайт прыгал последние 2 дня, ничего не качалось, возможно не все успел взломщик доделать, так как я в течение часа после пропажи файлов все исправил, а вот на одно сайте конкурентском такую фигню видел, захожу а там качается что-то, а на сайт не пускает.
-
Админпанель-Настройки системы-Раздел с почтой-Там ввести желаемый заголовок. Появилось в DLE 9.7.
-
так загляни "ручками" в файлы и посмотри что там, если ничего постороннего, то ок)
а лучше вообще не заморачиваться поисками того что изменили,
проще удалить и перезаписать чистыми файлами.
Разобрался. Пока все чисто. Скачал полный бэкап сайта на комп, антивирус не нашел вредоносных кодов. Буду следить, что дальше будет.
-
в фтп логах у меня пусто с июля, ибо фтп не пользуюсь. только sftp
а sftp опять таки только с моего ипа работает
Я фтп не пользовался с 19 ноября, когда заплатку ставил, НО в логах тоже только я. Значит залили как-то через движок, у меня заливка на сайт только картинок разрешена...
Посмотрел в папке /engine/classes/js/, половина файлов с 19 ноября, а файлов 5 обновлены 2го декабря в 0.00 ровно и файлы размером больше, чем в дистрибутиве DLE, я так понимаю эти файлы записывают в себя что-то со временем? Вряд ли злоумышленник мог изменить сразу 5 файлов в 0.00 2го декабря
Антивирус на компе не видит в них подозрительного кода. -
Как смотрел активность человека через Shell? Отслеживал его действия...
я имел в виду пхпшелл, он в логах апача был
через системный шелл зайти можно только с моего айпи, если конечно нет никакой проблемы с этой настройкой в цпанели)))
На самом деле сейчас очень волнует вопрос, как вообще этот PHP файл попал туда
Ведь залить его по сути можно или по ФТП или через дырку в движке, на компе чистота, а захожу я только с него, значит где-то есть лазеечка...-
2
-
-
Как смотрел активность человека через Shell? Отслеживал его действия...
-
они могли в легкую переписать файл антивируса, чтобы он не проверял ничего))
залей оригинальные файлы движка
и потом проверь еще раз,
у меня аналогичная ситуация
сижу разбираюсь
Да не похоже, Антивирус видит левые файлы, у меня там лежат пару модулей простеньких и пару файлов от старой версии движка, которые уже не используется, он их выводит как подозрительные, но я то знаю что там в них, а новый был только 1, который удалил. Файлы антивируса сейчас глянул, никто не редактировал их. Думаю PHP файл закинули из вне каким-то хитрым способом, без участия FTP, но пока не могу понять как....
-
Volfgang,
чувак, это не троян, а шелл
проверь /engine/class/xfields.class.php
есть такой файл?
что дле антивирус говорит? проверь все новые файлы
Captain,
гзипсжатие не создает пхп файлов
это замаскированный шелл
Я об этом и писал, просто наверное выразился не тем языком. Сам вирус определяется как BackDoor.php.PhpShell, а наличие трояна я предполагаю на компе своем, который позволил бы Shell залить, но компьютер чист.
Сканирую сайт после удаления этого файла, пока антивирус ничего странного не видит, htaccess на месте. /engine/classes/xfields.class.php такого файла нет.
-
Файлы minify_***.php в кеше создаёт включённая настройка Gzip сжатия в ДЛЕ.
Как-то я не замечал, хотя сжатие включено, но в любом случае в этом файле, который единственный лежал у меня находился троян и пропали htaccess файлы, не просто так это все
-
А какая версия движка?
Последняя с патчем на защиту от 19 ноября.
-
Сегодня как обычно админил свои сайты утром, все было в порядке. В 16 часов зашел в админку одного из проектов и обнаружил, что файлы .htaccess в engine/cache и engine/cache/system отсутствуют, благо админка сообщила об этом. Сразу просканировал сайт встроенным в DLE антивирусом и обнаружил в папке engine/cache/system файл
Как видно файл добавили в 15.11, в 16 я удачно его стер, возможно он не успел сделать ничего плохого. Решил закинуть файл на компьютер, проверить его код, но антивирус сразу завопил бешено, стер его тутже, нашел там BackDoor очень опасный. Собственно я проверил свой компьютер установленным KIS с последними обновлениями, лицензия, следом проверил утилитами других антивирусных систем, например Dr. Web Cure it! и прочими, никаких троянов или вирусов способных что-то закинуть FTP не нашел, да и сайты я не посещаю почти никакие, только популярные вроде ЛостФильм, на которых вирусов не бывает, защита постоянно включена всевозможная. В логах доступа по FTP я не увидел лишних коннектов, да и на соседних сайтах лежащих на этом FTP ничего не случилось, скорее всего атаковали именно этот сайт, а значит дырка или в правах доступа на папки engine/cache и engine/cache/system, но они как положено по инструкции имеют доступ 777 или есть дырка в движке, возможно. Конечно, я не исключаю косяк со стороны хостера, но пока постепенно ищу проблемные места. Хотелось бы получить комментарий от Celsoft или другого специалиста по защите, куда мне смотреть в плане защиты? Что могло дать возможность злоумышленникам удалить htaccess файлы и положить php файл с вирусом в папку engine/cache/system?
-
У вас memcahed сервер отклоняет все соединения. Смотрите настройки /etc/sysconfig/memcached с какими параметрами запущен демон memcache
конфиг должен быть примерно таким:
PORT="11211" USER="memcached" MAXCONN="1024" CACHESIZE="64" OPTIONS="-l 127.0.0.1"
смотрите настройки брандмауера, может быть порт у вас закрыт для всех.
Мой конфиг полностью соответствует Вашему.
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1"
Фаерволл стоит iptables, пока пытаюсь в нем разобраться )
-
php -i | grep memcache
/etc/php.d/memcache.ini,
/etc/php.d/memcached.ini,
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Moscow' for 'MSD/4.0/DST' instead in Unknown on line 0
memcache
memcache support => enabled
memcache.allow_failover => 1 => 1
memcache.chunk_size => 32768 => 32768
memcache.compress_threshold => 20000 => 20000
memcache.default_port => 11211 => 11211
memcache.hash_function => crc32 => crc32
memcache.hash_strategy => consistent => consistent
memcache.lock_timeout => 15 => 15
memcache.max_failover_attempts => 20 => 20
memcache.protocol => ascii => ascii
memcache.redundancy => 1 => 1
memcache.session_redundancy => 2 => 2
memcached
memcached support => enabled
libmemcached version => 0.31
Registered save handlers => files user memcache memcached
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Moscow' for 'MSD/4.0/DST' instead in Unknown on line 0
Похоже работает.
У вас просто, похоже, запрещено подключение на локальный адрес 127.0.0.1.
Как это проверить еще или может попробовать как-то отключить этот запрет? Если конечно у меня есть доступ к этому с моего VPS.
-
Зашел под рутом. Попытался зайти:
telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Попробовал еще так:
memcached-tool 127.0.0.1:11211 stats
Couldn't connect to 127.0.0.1:11211
Проверил запущен ли он сейчас, вот что вышло:
ps -eaf | grep memcached
root 9976 9263 0 14:15 pts/0 00:00:00 grep memcached
Я с memcache раньше не работал, поэтому не очень понимаю, но явно понятно, что не получается подключиться даже по телнету, а почему....
Хотя вчера проверял что memcache запущен, правда забыл какой командой...
Также создайте простой тестовый PHP скрипт на вашем сервери проверьте его выполнение, что он вам скажет.
Could not connect...по всей видимости ower_xz отписавшийся ниже прав...
-
PHP -m результат:
[php Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
ionCube Loader
json
libxml
mbstring
mcrypt
memcache
memcached
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
readline
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
sqlite3
standard
tokenizer
wddx
XCache
xml
xmlreader
xmlwriter
xsl
Zend Guard Loader
zip
zlib
[Zend Modules]
XCache
Zend Guard Loader
the ionCube PHP Loader
-
Вам нужно к хостеру обращаться. Возможно подключение не к 127.0.0.1:11211, а к другому адресу, может некорректно установлен сам Memcache.
Хостер утверждает, что установлено всё полноценно и подключаться надо именно к этому адресу.
Volfgang,
Возможно вы для PHP не подключили расширение memcache http://www.php.net/m...k.memcache.php. Помимо сервера memcache, для PHP нужно устанавливать специальное расширение для PHP, уточняйте у вашего хостинг провайдера что все два компонента установлены на вашем сервере.
Проверил, в PHP подключены memcache.so и memcached.so.
Смутило следующее. Проверил memcache на возможность принимать соединение следующей командой:
netstat -an | grep LISTEN
В итоге с портом 11211 есть только такие параметры, насколько я понимаю должно быть 127.0.0.1:11211, а вместо этого 0.0.0.0:11211, ниже скопировал строчки:
tcp 0 0 0.0.0.0:11211 0.0.0.0:* LIST EN
tcp 0 0 :::11211 :::* LIST EN
Напишу хостеру, но если кто разбирается в этом, буду рад помощи, возможно стоит что-то еще поменять в настройках, чего я не знаю, а хостер не хочет делать )
UPDATE! Хостер поправил настройки memcache, теперь tcp 127.0.0.1:11211 0.0.0.0:* LIST EN однако не работает memcache, уже не знаю куда глядеть
везде порядок получается. -
Добрый вечер, господа.
Сегодня решил на одном своем проекте попробовать Memcache в действии, узнал настройки у хостера, все можно сказать стандартно: Адрес:порт - 127.0.0.1:11211, естественно memcache установлен на сервере.
Выставил настройки, включил Кеширование через Mamcache и вот что вижу:
Внимание:
Вы включили в настройках сервера кеширование Memcache, при этом по указанным в настройках скрипта параметрам, скрипту не удалось подключиться к Memcache. Проверьте работоспособность сервера Memcache, а также правильность настроек подключения к нему в настройках скрипта. В противном случае включите файловое кеширование в настройках скрипта.
В общем, DLE не коннектится видимо к нему. Какие могут быть проблемы с этой функцией? Куда первым делом смотреть, чтобы заработало?
Кто голосовал и какую оценку поставил?
в DataLife Engine (Общие вопросы)
Опубликовано:
Господа, вопрос следующий:
На сайте в каждой новости голосуют пользователи, ставят свои звездочки, но у некоторых авторов появились недоброжелатели и ставят им единички во все посты, человек делает публикацию, у него за пол часа пара оценок или больше в 1 звезду. Кто-то сидит постоянно и ждет. Голосовать могут только зарегистрированные пользователи. Можно как-то посмотреть, кто ставит эти оценки?