iteX

Несколько дней назад на Full Disclosure опубликовали скрипт для доса Apache всех версий. Он малость не работоспособен, но исправить и направить его в работу дело 5 секунд.

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

Скрипт посылает запрос с определенным полем range (Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300),  апач в ответ на него собирает  из пересекающихся кусочков файла ответ,  постепенно засирая память и процессор. Если включен gzip,  то все многократно усиливается.  Вообщем в несколько запросов можно завалить крупный сервер. Что уже с успехом и делают, сайт нокии и прочие проекты на апаче это уже на себе почуствовали.

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

Как проверить на уязвимость: На сервере должен быть курл. Находим какой нить статический файл, например robots.txt и делаем следующий запрос:
curl -I -H "Range: bytes=0-1,0-2" -s vashsait.com/robots.txt | grep Partial
Если контент выдает Апач с 206 заголовком, то скорей всего сайт подвержен уязвимости.

Как защититься, есть три решения. Все, кроме ограничения длины запроса  и SetEnvIf приводят к тому, что с сайта нельзя будет докачивать статичные файлы после обрыва связи,  клиентам придется закачивать их вновь :

1. Если фронтендом nginx, и она не отдает сам статику, то запрещаем проксировать заголовок Range директивой proxy_set_header Range ""; и proxy_set_header Request-Range ""; в конфиге nginx.
2. В .htaccess прописываем
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
3. В конфигах апача есть несколько решений
   1. Если установлен mod_headers то прописываем директиву
      RequestHeader unset Range
RequestHeader unset Request-Range
      Мод можно включить командой a2enmod headers
   2. Установить лимит на размер заголовков, это может убить другие заголовки, скажем длинные куки, устанавливаем директиву с нужным размером ограничения
      LimitRequestFieldSize 200
   3. Для второй версии апача, для удаления поля, если в нем больше 5 диапазонов, прописываем директиву
      SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
RequestHeader unset Request-Range
CustomLog logs/range-CVE-2011-3192.log common env=bad-range

Вот так, защитились и ждем патчей апача и удачи.

Incoming search terms:

• requestheader unset request-range

Случайно заметил, что на сайте вордпресса идут пермаментные глюки с получением доступа к iMoney. При запросе скажем http://wordpress.org/extend/plugins/imoney/stats/ идет редирект на страницы поиска плагинов. Пробовал удалять файлы из svn, добавлял новые, вообещм шаманил, но не помогло. Если заходишь под своим акком, то страницу видно, но плагин не скачивается, отдает 404, http://downloads.wordpress.org/plugin/imoney.zip .  Возможно связано со ихнеми недавнеми взломами. Но другие мои плагины показываются нормально, да и пароли я свои после взломов менял. Вообщем хз, что делать, может плагин удалить и заново сасубмитить. Или если ктонить с подобным встречался, подскаите алгоритм. В саппорт чтоли им написать))

Временно относительно новые версии можно скахать здесь http://itex.name/wp-content/uploads/itexname/imoney.zip

Incoming search terms:

• imoney

Иногда слежу за такого рода тенденциями со взломами блогов.

Интересуют всякие эпидемии типа екибастоса или например вот, которые использовали  permalink bug до вордпресс 2.8.4.

Сейчас распространяется, чтото новое. Инфы очень мало. Те кто его исследовал называют его “Exploit minisuhosin“. Название идет от того, что файл притворяется секьюрити патчем suhosin. Уязвимость связана скорей всего с тем, что OsCommerce требует register_globals=on в связке в вордпрессом. Вордпресс 3.0.5 тоже были взломаны. Америкосы пишут, что используется только линукс из-за /tmp, но встречал шеллы и на винде. Видимо пробная часть атаки была гдето в декабре 2010, а сейчас распространяется основная волна с конца января 2011. Хотя возможно и то, что только сейчас стали  обнаруживать. Также по следам первых авторутеров идут какието исламские хакеры, дефейсят и пишут, чтото про Аллаха.

Сам вектор атаки  и уязвимые скрипты не ясны. Можно судить лишь по симптомам.

1. Создается файл с именем /tmp/25454b22bf39c75795851f39d5e347c4, возможно есть другие имена, но не встречал
2. В .htaccess прописывается AddType application/x-httpd-php .php .phtml .php3 .php4 .php5 .htm .html
   php_value auto_prepend_file /tmp/25454b22bf39c75795851f39d5e347c4
   Тем самым запуская все запросы к скриптам через злонамеренный файл.
   В гугле сейчас 36к страниц с ошибками, связанными с этим файлом.
3. Сам файл, маскируясь под suhosin, проверяет ип посетителя, и если  ипа нету в блеклисте ставит куки и выдает злонамереннй джаваскрипт. Сайт в джаваскрипте у мя уже не резолвится, в кеше гугла похож на связку сплоитов.
4. Встречал установленные шеллы (с99 и 3gayskeeters), но возможно это от других товарищей.

Для лечения и противодействия возможны следующие действия.

1. Удалить из .htaccess строки, созданные злоумышленником
2. Сделать бекап
3. После этого обновить версии вордпресса и плагинов
4. Сменить пароли
5. Поставить права только для чтения на .htaccess
6. Если не используете пермалинки от .htaccess вообще можно избавиться
7. Проверить файл /tmp/25454b22bf39c75795851f39d5e347c4, возможно создать пустой, с правами только для чтения, чтоб при взломе дальше этого не ушло.
8. Если есть доступ, поставить бит запрета исполнения файлов на /tmp

Если ребята русские, то наверно надо посоветовать им сделать проверку на то, создан ли их файл. То больно много блогов ща просто с ошибкой валятся, когда тот файл удаляют.Не продумано, хотя наверно атака уже окупилась.

Ну вообщем вроде все, новое чтонить узнаю, может распишу.

Incoming search terms:

• взломали oscommerce

Речь идет о почте гугла gmail.com. За сегодня появилась просто уйма случаев рассылки спама через взломанные аккаунты пользователей. Спамят через прокси на домены вида *.co.cc с редиректом на фарма партнерку. Так как пользователи использовали сложные пароли и сидели как и на виндах, так и на линуксе, в разных браузерах, то дело наверно в самом гугле. Из возможных дырок можно выделить включенные pop и imap и апи гугла, которые возможно имеют уязвимость. Второе мне кажется более вероятным, тк 15 числа изменили апи для айфона. Возможно это както использовали хакеры, тк спам рассылается через мобильный интерфейс.

Для проверки, взломали gmail аккаунт ли у вас, надо зайти в историю активности (Last account activity) и посмотреть есть ли там вход мобильного устройства с чужим ипом. Я также на всякий случай отключил POP и IMAP в своем акке, тк ими не пользуюсь. Абузы на домены co.cc можно слать черезе эту страницу.

Для общего развития можно почитать комментарии на хабре взломанных пользователей.

Incoming search terms:

• гугл взломали