Собственно перед взламыванием сайта зачастую собирают информацию о платформе и её версии.
Если это джумла — добавляем к имени домена /language/en-GB/en-GB.xml и вуаля!
P.S.
Запись для себя, чтоб не забыть 🙂
рубрики: Joomla, security | Комментарии (0)
Собственно, может кому интересно будет — небольшой пример из текущего (буду краток).
Гемор: джумла, за безопасностью которой особо никто не следит, потому что джумла!
По знакомству данный гемор лежит на моём серваке, где у меня ночью отрабатывает самописный скриптик по отлову изменений в скриптах, и информирует меня в случае оных.
Вот и проинформировал меня вчера о появлении нового скрипта » /images/stat.php < 92427 "
Излюбленное место хранения бэкдоров и наиболее популярное для бэкдора название 🙂
Смотрим файло глазами:
видим обфусицированный код (если есть желание посмотреть исходный код — пробуем) исходник бэкдора
запускаем — форма пост запроса (вероятно пароль к бэкдору)
Зараза 100% — убиваем её!
Осталось одно НО! — если зараза проникла единожды, проникнет и вторично!
Первое, что делаем — меняем все пароли доступа (т.к. скорее всего они уже у хакера в базе).
Второе, нужно анализировать логи веб-сервера и искать непосредственно дыру: как именно был внедрён бэкдор?
Дату создания и модификацию файла бэкдора подменили (бывает и не меняют — искать в логах гораздо проще).
Далее недолгий анализ, насторожил меня GET запросами вида
"/?option=com_contenthistory&view=history&list[ordering]=&item_id=&type_id=&list[select]=polygon%28%28/*!00000select*/*/*!00000from*/%28/*!00000select*/*/*!00000from*/%28/*!00000select*/concat_ws%280x7e3a,%28/*!00000select*/concat_ws%280x7e3a,0x534b4f54494e4b494e,username,password,0x505343%29/*!00000from*/fot6h_users%20where%20id%20=%20710%29%29as%20mk%29%60%60%29%60%60%29%29"
С какого это перепугу, в запросе иньекции SQL кода ?! явно используя дыру хотят чего то из базы поиметь — админские пароли, куки и т.д. и т.п.
Далее гуглим про дыры в «com_contenthistory» и сразу всё становится на свои места 🙂
Искать заплатки по данной дыре — дело хозяина джумлы, я же на скорую руку просто затыкаю любые запросы с вхождением com_contenthistory в параметры через .htaccess
RewriteCond %{QUERY_STRING} com_contenthistory
RewriteRule .* - [F]
рубрики: Joomla, security | Комментарии (1)
Статья настолько мне понравилась, что с указанием источника сделал полный репост!
Знания необходимы для возможности определить «заразу» визуально для дальнейшего его уничтожения.
Далее от автора:
Цель данной статьи — познакомить веб-мастеров с различными подходами, которыми пользуются хакеры, чтобы затруднить обнаружение и анализ исходного кода бэкдора или хакерского шелла.
В процессе лечения сайтов мы обнаруживаем множество разновидностей хакерских шеллов и бэкдоров. Скрипты отличаются функционалом и способом обфускации исходного кода, но у всех есть общая черта — это неявное объявление переменных и функций, а также косвенный вызов функций.
Данный подход с одной стороны значительно усложняет анализ исходного кода, а с другой — позволяет хранить код в текстовых данных. Например, часть вредоносного кода может загружаться со стороннего сайта, из базы данных и мета-данных jpeg/png/gif или передаваться в запросе к скрипту. Кроме того, часть кода, представленная в виде обычной текстовой строки, может быть очень надежно зашифрована.
Эти же приемы используются веб-разработчиками и в мирных целях в скриптах проверки лицензионных ключей и регистрации веб-приложений, чтобы затруднить взлом программных продуктов.
Несмотря на все многообразие вредоносного кода, существует не так много вариантов объявления и косвенного вызова функций.
Ниже представлены примеры различных техник скрытого вызова кода. Для простоты и наглядности пусть «вредоносный код» представлен обычной функцией
echo «Test»
которая выводит слово «Test» на странице. Естественно, имена переменных и функций, а также исполняемый код не хранятся в открытом виде и в большинстве случаев обфусцированы.
Вариант 1: косвенный вызов функции
<?php
$a = "var_dump";
$b = "Test";
$a($b);
?>
Вариант 2: выполнение кода через eval
<?php
eval('$a = "Test"; echo $a;');
?>
Вариант 3: выполнение кода через assert
<?php
assert('print("Test")');
?>
Вариант 4: выполнение кода через array_map
<?php
function evil($a) {
echo $a;
}
array_map('evil', array("Test"));
?>
Вариант 5: выполнение кода через preg_replace(‘/.*/e’)
<?php
preg_replace('/.*/e', 'print("Test")', '');
?>
Вариант 6: выполнение кода через preg_replace_callback
<?php
$a = function () { echo "Test"; };
preg_replace_callback('/.*/', $a, '');
?>
Вариант 7: выполнение кода через usort, uasort, uksort
<?php
$a = function ($x, $y) { echo "Test"; };
$b = array(1 => '1', 2 => '2');
usort( $b, $a);
?>
Вариант 8: скрытое объявление функций и передача параметров через extract
<?php
extract($_REQUEST);
$a($b);
?>
При запуске http://site.ru/script.php?a=system&b=ls выполнит системную функцию system(«ls»)
Вариант 9: через регистрацию функции завершения (можно сделать exit() или die() для немедленного выполнения)
<?php
register_shutdown_function(create_function('', "echo 'Test';"));
?>
Такой же подход можно использовать со всеми вызовами, принимающими в качестве аргумента callable функцию: call_user_func_array(), call_user_func(), forward_static_call_array, forward_static_call(), register_tick_function(). Хотя в реальных шеллах и бэкдорах вызовы через данные функции мы не встречали, обычно используются варианты с 1 по 8.
В реальных бэкдорах перечисленные варианты используют в комплексе, причем сами объявления переменных и функций часто выносят за пределы скрипта (например, загружают из базы данных, с удаленного сервера или из мета-данных изображений).
Кстати, бОльшая часть данных вызовов успешно детектируется сканером вредоносного кода AI-BOLIT. Это отличает его от обычных сканеров, выполняющих поиск вредоносного кода по хэшу.
рубрики: security, Полезности | Комментарии (0)