iteX

Гдето в начале лета wordpress.org взломали и засадили им бекдоры в распространенные плагины.
После того как они обнаружили это, поменяли пароли всем юзерам и поменяли отношение к безопасности.
Только както не по нормальному. Если простым языком, то через жопу. Прикрутили видимо какойто код проверки на безопасность плагинов.
В итоге забанили мой плагин iMoney на репозитарии. Причем сделали это без уведомлений, по тихому. Просто в один день перестали давать скачивать плагин с сайта. Или редиректит на главную или 404.
Я долго считал, что это всеголишь глюки их svn. Мучался с удалением, восстановлением файлов и прочим шаманством.
Потом написал им на форуме поддержки, никто не ответил. Написал на plugins@wordpress.org сообщение такого плана:

I am the author of the plugin iMoney (http://wordpress.org/extend/plugins/imoney).
About a two month ago, when I upgrade versions in SVN, plugin is not updated.
http://wordpress.org/extend/plugins/imoney – redirect on main, http://downloads.wordpress.org/plugin/imoney.zip – 404.
I change passwords, add and removed files.
Plugin removed from plugins repository? Why?
What is the solution?
Thank you anyway.

Через несколько дней они ответили:

Hi,
The plugin was removed for a couple of reasons:
- compressed code. Code should be in the clear and readable.
- you are using $_SERVER many times and this has security implications as well as being inefficient.

If you could redo the code and check it against known exploits we’d be happy to put it back.

Тоесть, им не нравится упакованный код от бирж ссылок и частое использвание директивы $SERVER. Мол это может быть не безопасно и не ээфективно.
Что может быть не эффективного в вызове переменной $SERVER?
Я не спорю, что в коде есть спорные участки. Костыли и подобное. Но каждый такой участок решают какунить конкретную проблему, возникшуюю у человека, клиента плагина.
Это все было изначально со времен написания плагина. Тоесть с 2008 года их все устраивало, а весной 2011 уже нет.
Я считаю, что у них появился какойто статический анализатор, который ругается на определенные конструкции языка. И они не смотря в код, делают на основании отчетов анализатора выводы о коде.

Прошло дофига времени, я наконец решил малость переписать код. Переменную $_SERVER сделайл по ссылке внутренней переменной класса.
Запакованный код со всего плагина свел в одну функцию и специально ее подписал, мол хранилище кода.
Проверил, что все работает и написал им новое письмо. Мол сделал, что они хотели. Мой плагин, чтоб не можифицировать файлы вордпресса или код бирж использует всяческие ухищрения, переопределения $_SERVER и тд.
При инсталяции запакованного кода пользователь сам должен нажать кнопку, чтоб его установить. Причем он сам может его установить вручную без плагина. Написал, что с 2007 не было зарегистрировано случаев взлома через мои плагины. И что я очень помешан на безопасности.

Hi, Sorry for my English. I modified code and check it against known exploits. My plugin easily combines codes from link systems and WordPress. In order to not modify the code link systems, and WordPress, to have to find ingenious solutions in a plugin ($_SERVER replacement and other). I made a few changes to your static analyzer less swearing.
Move data into a separate function. This code from other systems and is installed on the user’s request. Users are always aware of it. If it is stored in other separate files, there is a chance that it can executed. I really care about security. I’ve seen less safe plugins, do not know why it was blocked. The plugin has existed since 2007 and have never been hacked.
Thank you for your patience))

Опять от них пришел отрицательный ответ.

Here’s the bottom line:
- Your code, as it stands, is extremely insecure. Doesn’t matter if you’ve been hacked or not, or whether anybody has discovered the vulnerabilities or not. Insecure is insecure.
- Your use of base64 obfuscated files is unacceptable. We do not allow obfuscated code in the repository. No exceptions.
As the code currently stands, it will not be allowed back in the plugin repository. These issues must be addressed for the plugin to be listed again.

Пишут, что мой код очень дырявый, весьма спорное утверждение, что не имеет значения, взламывали или нет, есть уязвимость или нет. Просто, без отсылок к дырявому коду и прочему. С чего они решили тогда, что он дыряв? Начет упакованного кода, что нельзя использовать никому, без исключений.

В итоге както мя напрягает такое поведение. Их репозитарий весьма удобен тем, что с него автоматом у всех пользователей обновляет на новые версии плагина. Соотвественно забивать на них не надо, несмотря на то, что они забили на всех, кто пользовался моим плагином.
Другие мои плагины с такимиже свойствами ими вообще никак не затронуты. На всякий случай решил новые версии плагинов не выкладывать, то еще и остальные забанят.

Из решений, хм, есть три варианта.

Просто взять новое название плагина и они заапрувят стопудоф. Но возникнет путаница у пользователей.
Второе, это проявить чудеса обсфукации и фиг их статический анализатор чтонить найдет. Опять же возникнут вопросы у вебмастеров, нафиг в плагине такая вирусоподобная защита вставлена.
Ну а третье переписать плагин. Снова. А потом еще раз и опять и опять. Заместо того, что добавлять новые биржи или еще чтонить, придется делать ревизии кода.
Пока все равно склоняюсь к третьему варианту.

Вообщем я считаю, что они все таки мудаки, но если есть возможность, посмотрите код на дыры, я особо опасных мест не вижу.
Три месяца уже все это длиться.
Надо чтото уже решить относительно быстро и эффективно.

Несколько дней назад на 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

Недавно логи смотрел по некоторым блогам на предмет подозрительных действий, из просмотра появилась некоторая закономерность. Вообщем видимо jacksoft написали бота который проходит по блогам из списка, регится там, активируют акканут, а потом по xmlrpc постит посты или чтото подобное, насчет постов я не уверен, тк по умолчанию у меня вновь созданные пользователи не имеют прав на запись. Бот на пхп, в пользу этого говорят заголовки при обращении к rpc “Incutio XML-PRC”, и возможно ошибки при создании адреса, вида “//xmlprc.php” и “/wp-login.p/xmlprc.php”. Кстати довольно интересная идея, может даже спалил чего, тк защиты особой от этого нет, и если по умолчанию народ может постить в блог , то соотвественно бот сделает свое дело. Также допускаю возможность, что бот делает какиенибудь деструктивные действия или ссылки размещает. Как разпознать бота хз, единственное, что он xml-rpc обращается и еслиб не прошелся по нескольким моим блогам, я даже бы и не запалил закономерности. Хотя может у меня опять паранойя, пойду их блог почитаю, вроде интересно с первого взгляда. У когонить были похожие случаи?

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

Интересуют всякие эпидемии типа екибастоса или например вот, которые использовали  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

Есть такая партнерка Teasernet покупки-продажи кликов по тизерам. Принимает, как и продает, только трафик из СНГ. Существует больше года, что радует.
Цена за 1 клик, которую получает партнер, на данный момент по рекламе от 30 до 70 копеек. На деле я думаю, что поменьше на говонтрафе. Минимальная сумма выплат 100 рублей.
Внешний вид тизеров, статистика и запреты показов настраиваются в самой партнерке. На сайте прописывает чисто код и два параметра.
Теперь есть возможность использовать автоматически Тизернет и в вордпрессе.

Read the rest of this entry »

Incoming search terms:

• teasernet wordpress