История начинается ….   неожиданно …

Все было как обычно — заходим на сайт — ищем нужный журнал. Ссылка ведет на весьма известный файлообменник fileshare.in.ua.

Качаем.

И.

Сюрприз :)

Рамка всем известного вируса вымогателя

Отставляем панику.
Мышка кроме рамки недоступна, но клавиатура работает.
Пуск - выполнить - cmd
Дальше команда списка процессов :
tasklist
или поэкранно :
tasklist | more
Видим нечто необычное :
0.3534388206875574.exe
Дальше команда снятия процесса :
taskkill /F /IM 0.3534388206875574.exe
Рамка пропала.
Но курсор все так же в области рамки.
Дальше я снял еще пару процессов, в том числе и :
taskkill /F /IM java.exe
Закрыл консоль (cmd).
Все встало на свои места.
Дальше стандартно. Сканер + антивирус.
Как ни странно антивирус (Microsoft Security Essentials) увидел эту «заразу» :

Но вот в чем вопрос : Почему он не пресек это на этапе загрузки ?
Дальше сканер :

Все. Очищаем остатки — перезагружаемся.
А все могло быть намного хуже. Например, если сразу перезагрузить компьютер — то вместо рабочего стола только рамка. Тогда только LiveCD и поиск тела и остатков вируса.
Мораль : не паникуйте раньше времени — иногда вирус можно убрать даже без помощи антивируса.

Итак новый «веселый» вирус был найден мной на этих выходных.

Вирус прячется в файле :

\windows\system32\sfcfiles.dll - Trojan.Win32.Patched.fr ( BitDefender: Trojan.Generic.2929983, AVAST4: Win32:Patched-KP [Trj]

И находится почти всеми антивирусами. Да вот только удалить его они не могут.

Файл системный.

Лечение очень простое :

• 1. Отключить систему восстановления.
• 2. Загрузиться в Safe mode , а намного лучше в любой лайв-дистрибутив. Заменить поврежденный файл на оригинальный (можно скачать в конце этой заметки).
• 3. Удалить все папки System Volume Information на всех дисках (это папки с точками восстановления)
• 4. Загрузиться в обычном режиме. Включить восстановление. Сделать контрольную точку.
• 5. Работать дальше.

Это все. Прилагаю оригинальный sfcfiles.dll.

Недавно наткнулся на статью про найденную уязвимость в веб-сервере apache.

Пять дней назад в листе рассылки Full Disclosure появился скрипт, по заявлению автора, убивающий Apache начиная от самых старых версий до самых новых.

Работает скрипт очень просто : запускает простой запрос в несколько десятков потоков.

HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close

В ответ на такой запрос Apache для подсчета Content-Length собирает в памяти длинный ответ из перекрывающихся кусков запрошенного файла, который может занять и занимает значительный объём памяти. При этом потребление памяти Apache начинает резко расти, как на том графике в начале, что при должном, совсем небольшом, количестве запросов приводит к DoS даже на приличных серверах.

Проверить, уязвим ли ваш сервер к этой атаке легко:

curl -I -H "Range: bytes=0-1,0-2" -s www.example.com/robots.txt | grep Partial

Если Вы увидели ответ :

206 Partial Content

То Ваш сервер 100% уязвим для такой атаки.

Что же делать и как поставить защиту ?

Самым простым способомбудет прописать для nginx запрет для проксирования пустых запросов :

proxy_set_header Range "";
proxy_set_header Request-Range "";

А вот если nginx у Вас нет, то рекомендую его установить. Или по сообщениям сайта  cybersecurity.ru :

Разработчики web-сервера Apache сообщают об исправлении опасной уязвимости CVE-2011-3192 , которая использовалась злоумышленниками для проведения атак на отказ в обслуживании web-серверов. Стоит отметить, что web-сервер Apache обеспечивает работу двух третей всех сайтов в мире.

Напомним, что опасная уязвимость была обнаружена независимыми специалистами в области информационной безопасности 20 августа. В тот же день в сети Интернет появился эксплоит, который позволял вывести из строя любой сайт, который использует Apache HTTP Server.

Уязвимость в Apache HTTP Server позволяла злоумышленникам аварийно завершать работу web-серверов, используя простую вредоносную программу. Ошибка заключалась в способе обработки большого количества Range запросов в HTTPD, что приводило к исчерпанию ресурсов удаленной системы. Ошибка была исправлена в новой версии Apache HTTP Server 2.2.20. Однако для того, чтобы предотвратить атаку, все администраторы сайтов, которые используют Apache HTTP Server, должны самостоятельно установить обновление.