раздел обмен ссылками. уязвимость?

[vmkvadim]

в разделе обмен ссылками появилась куча ссылок на левые сайты.
учитывая, что разместиться там они могли только ройдя модерацию ручную, то возникает вопрос - модерацию они не проходили, откуда могли взяться?
это уязвимость shop script? или у кого-то появился пароль от админки (это вряд ли)

 

[MastZzz]

Поищи шел. Выглядеть будет в корне примерно temp.php, pr.php и т.д. Может стоять в папках еще. Оттуда и пароли. Запусти его, сразу увидишь откуда растут ноги. С соседних сайтов лезут, тогда предензии к хостеру или все таки через твои скрипты. Боюсь утверждать однозначно, пока, но походу ноги растут отсюда. Ссылочки ведут, по крайней мере у меня, на украинсские сайты (делаем сайты (киев), и пару магазинов, которая эта контора сделала ....). Данные магазины на этом форуме светились, что дает повод утверждать о росте ног.

Также просмотри шаблон особенно файлы прайс, дополнительные страницы, детальная страница и т.д. на предмет вставки ссылок на вышеупомянутые сайты через <div>. Еще посмотри, не стоит ли скрипт показывающий пользователей онлайн. Он вскрывается на ура.

 

[shkiper]

тоже было такое дело, но за всё время ссылок 3-4.
еслиб шел, то наверное поболее расплодилось.

 

[MastZzz]

у меня стоял именно шел и те же, 3-4 ссылки. Как вариант - убрать шел, в папки вкинуть пустой файл index и посмотреть наличие htaccess. Что туда писать, где-то было. Ну и поработать с шаблоном. Поискать файлы слива. Ну а самый грамотный способ, обратится к специально обученным людям. Вроде такие здесь обитают.

Обратился в службу безопасности хостера. Тож подтвердили сей факт, дали советы и .... самое главное бумагу за печатью. Об этом малек ниже.

Если честно, то меня больше волнует другой аспект. Жадность и глупость, граничащая на уровне дибилизма. В моем случае шел вел в конкретное место, туда же вели и ссылки. Это каким же жадным и тупым надо быть, чтоб не понимать, в наше время, что это как паспорт у взломанной квартиры оставить. А к примеру в Беларуси, откуда я сам, за такие вот делишки - сажают в путь. Вот для этого, в случае чего, бумага и нужна. Тож самое и на Украине (откуда растут ноги). Специально задался целью узнать практику примения статьи. Оказалась применяется и не просто применяется, а ух как. Только единственное что могут не посадить, а вот нервы вытрепят. Компы на экспертизу утянут на пару месяцев, опросы, допросы и т.д. Неужели нельзя более честным способом продвигать свои творения ? Ну эт так, лирика. Но к этому придем скоро.

 

[sergio433]

Аналогичная ситуация на 3 сайтах в разделе обмен ссылками появляются ссылки и уже про модерированые. Как правило дата модераци у всех ссылок 10.10.2010 в 0-00 часов. Хотя ссылки появляются и позже. Шеллов точно нету, слил весь движок и пере сканировал антивиром (нод32 например все шелы видит). Пароли менял и на админку. Все равно появляются. Скорей всего есть какой то способ сразу в базу зайти. сейчас сменил пароли на mysql... посмотрим что будет .
По логам сервера в админку никто не входил кроме со моего айпи по журналу авторизации тоже.
Если у кого есть догадки пишите

 

[vmkvadim]

у меня кстати тоже 10.10.2010 в 0-00
однозначно не через админку, иначе дата была бы не та
и что интересно в базу можно подключиться у меня только с определенных ip, фаерволом закрыто. значит уязвимость какого-то php-файлы

 

[sergio433]

у меня кстати тоже 10.10.2010 в 0-00
однозначно не через админку, иначе дата была бы не та
и что интересно в базу можно подключиться у меня только с определенных ip, фаерволом закрыто. значит уязвимость какого-то php-файлы

После смены паролей на админку ФТП и базу сегодня ссылки опять появились. Пол логам заходили

89.251.104.186 - - [17/Jan/2011:08:51:43 +0200] "GET /index.php?links_exchange=yes&page=2 HTTP/1.0" 200 24653 "-" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"
89.251.104.186 - - [17/Jan/2011:08:52:02 +0200] "POST /index.php?links_exchange=yes&page=2 HTTP/1.0" 302 3 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"
89.251.104.186 - - [17/Jan/2011:08:52:06 +0200] "GET /index.php?links_exchange=yes&page=2&added=ok HTTP/1.0" 200 24767 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"

Только эти три запроса было то есть уязвимость точно не в базе и не админке. Он каким то способом методом POST модерирует ссылку. Только не могу пока понять как

Подозреваю что SQL иньекцией как то модерирует

Самый интересный средний запрос с кодом ответа сервера 302
При попытке просто добавить ссылку у меня этот лог отображается с кодом 200 а у него почему то с кодом 302.
Сложилось впечатление что он небольшим php скриптом модерирует ссылку где просто методом POST что то передает базе. проверить логи по MуSQL не могу так как хостинг не предоставляет такие услуги

 

[Zolinger]

Значится так. Вот что у тебя происходит:
Первое.

89.251.104.186 - - [17/Jan/2011:08:51:43 +0200] "GET /index.php?links_exchange=yes&page=2 HTTP/1.0" 200 24653 "-" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"

кулхацкер зашел на страничку добавления ссылок из своих закладок.
Второе.

89.251.104.186 - - [17/Jan/2011:08:52:02 +0200] "POST /index.php?links_exchange=yes&page=2 HTTP/1.0" 302 3 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"

через форму добавления линков, запихнул свои ссылки посредством SQL-иньекции. При этом интересно ,что сервер выдал код 302 - "302 Moved Temporarily". а затем страница благополучно перезагрузилась, на правильную, что отображает третья строчка:

89.251.104.186 - - [17/Jan/2011:08:52:06 +0200] "GET /index.php?links_exchange=yes&page=2&added=ok HTTP/1.0" 200 24767 "http://site.com.ua/index.php?links_exchange=yes&page=2" "Mozilla/4.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20"

Для того, чтобы добавленная ссылка отображалась, в соответствующей таблице БД, поле "le_lVerified" должно содержать дату, а не NULL.
Т.е. SQL-иньекция добавляет ссылки в БД с датой валидации ссылки.
Как бороться.
1. Сложный вариант - найти дыру (уязвимость) в обработчике переменной $_POST, данной формы.
2. Простой, но как средство спрятать дыру, а не удалить:
- изменить имя переменной links_exchange на другую, например exchange77_links88.
- изменения затронут только два файла - links_exchange.php и links_exchange.tpl.html
Простого варианта в принципе должно хватить, т.к. злоумышленник использует скрипт автоматизирующий процесс добавления (это видно по дате валидации линка - она одна и таже) и скорее всего не будет из 200 или 1000 сайтов, на котором "фокус не удался", выяснять причину - почему не удалось! И даже скажу больше. Этот кадр скорее всего не является дыркооткрывателем и мозгом написавшим хак-скрипт. Поэтому простой вариант условно решит проблему.
Заморачиваться на сложный вариант можно только из принципиальных соображений и при наличии бабла на толкового программера, который устранит саму уязвимость кода.

 

[sergio433]

Да вчера разбирался с проблемой . Пока Выяснил что уязвимость в файле \core_functions\linkexchange_functions.php потому что именно там идет запись в базу.
И именно этот файл инклюдиться в index.php
У него скорей всего как ты и говоришь автоматический скрипт который SQL иньекией вставляет дату в колонку le_lVerified . Я вчера даже написал небольшой php скрипт с методом POST который кстати отрабатывает с другого хоста и добавляет автоматом ссылку в базу .... но добиться что бы дата проставлялась пока не удалось. Может у кого то получилось ?
Одним из возможных решений: заменить в базе название колонки le_lVerified и соответственно в файле \core_functions\linkexchange_functions.php тоже.

PS ссылки сегодня опять появились и опять 8 утра )))

 

[vmkvadim]

у меня также с этого (89.251.104.186) ip и сегодня проделали подобную процедуру.
может по ip забанить? кстати скиньте в личку какие сайты у вас добавляли.