Russian
Интернет находится в нормальном состоянии, крупных эпидемий и других серьезных инцидентов службой мониторинга «Лаборатории Касперского» не зафиксировано. Уровень опасности: 1
Все угрозы
выбрать автора
2013 Янв Фев Мар Апр Май Июн Июл Авг Сен Окт Ноя Дек
Новые
постинги
Топ по
рейтингу
Топ по посещаемости

Станьте автором

Стать автором нашего блога можно, достигнув рейтинга «+100». На ваш рейтинг влияет оценка ваших комментариев другими посетителями сайта.

Инциденты|Опасные пробелы

Марта Янус
Эксперт «Лаборатории Касперского»
опубликовано 15 июн 2011, 17:06  MSK
Сюжеты: Взломы веб-сайтов, PHP
0.9
 

Несколько дней назад я написала в блоге о предназначенном для платформы osCommerce PHP/JavaScript-зловреде, в котором для обфускации вредоносного кода применен новый интересный прием. Так получилось, что чуть позже я наткнулась на еще более «продвинутый» образец PHP-инфектора, также в связи с уязвимым решением для электронной коммерции.

Мой коллега из польского офиса нашей компании попросил меня помочь с обнаружением вредоносного ПО, от которого пострадал интернет-магазин его друга. HTML-страница магазина при открытии ее в браузере содержала ссылку на скрипт jquery.js в генерируемом случайным образом домене третьего уровня в бесплатном домене cx.cc. При этом в исходных файлах на сервере этой ссылки и в помине нет. Поставить диагноз оказалось несложно: данный фрагмент кода добавляется динамически каким-то зараженным PHP-скриптом.

Мы просмотрели все PHP-файлы на сервере и были удивлены: на первый взгляд, ничего подозрительного в них не было. Однако, памятуя о зловреде div_colors, я принялась изучать код строку за строкой. В конце концов мое внимание привлекла небольшая функция в начале одного из основных PHP-файлов.

0.1
 

Согласно результатам опроса, проведенного Антифишинговой рабочей группой (Anti-Phishing Working Group, APWG), подавляющее большинство легальных сайтов, задействованных в фишинговых атаках, в качестве операционной среды используют open-source платформу LAMP (Linux, Apache, MySQL, PHP).

APWG приступила к анкетированию в конце 2009 года; к апрелю 2011-го активисты опросили 270 веб-мастеров, пострадавших от взлома. Как оказалось, составными компонентами архитектуры сетевых ресурсов, оккупированных фишерами, являются, как правило, ОС Linux (76% респондентов), сервер Apache (81%), СУБД-приложение MySQL (87%) и система разработки PHP/Java (82%).

В 84% случаев злоумышленники использовали взломанный ресурс для создания фишингового сайта или размещения поддельных страниц, 24% вторжений имели целью размещение вредоносного ПО. При этом четверть участников опроса не смогли точно сказать, когда и как непрошеные гости проникли на их территорию. 52% пострадавших обнаружили взлом, получив уведомление от антифишинговой организации, 18% были предупреждены хостинг-провайдером, 19% ― жертвой фишинга. Лишь 6% опрошенных зафиксировали инцидент, изучая логи веб-сервера, 16% отследили измененные файлы, а 4% получили сигнал от IDS, антивируса или иной защитной системы.

APWG отмечает, что представленная статистика [PDF 548 Кб] ― лишь предварительные результаты. Полный анализ собранного материала и соответствующие рекомендации будут опубликованы позднее.

0
 

Киберпреступники в Бразилии, да и во всей Латинской Америке, практически всегда используют приемы социального инжиниринга для запуска атак. Время от времени они рассылают фальшивые сообщения от банков или популярных интернет-сервисов. База электронных адресов потенциальных жертв составляется на основе адресов, украденных с зараженных компьютеров, и частично — на основе адресов, хранящихся в базах e-mail-клиентов.

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

В процессе своего ежедневного анализа я обнаружил интересный интерфейс для массовой рассылки. Код указывает на то, что он был создан в Бразилии:

0
 

На веб-приложения, написанные на языке PHP, приходится 43 процента всех проблем, связанных с безопасностью информационных сетей. Таковы результаты исследования, проведенного в текущем году американским Национальным институтом стандартов и технологии (NIST), сообщает сайт Securityfocus.com. В 2005 году на долю приложений на платформе PHP приходилось всего 29 процентов уязвимостей. С учетом того, что число брешей в самом языке минимально, цифры NIST показывают, что проблема кроется в разработчиках, многие из которых не являются профессионалами в области информационных технологий.

Проблемы с PHP приобретают особую остроту в тот момент, когда исследователи сферы информационной безопасности стали обращать особое внимание на бреши в веб-приложениях. В начале этого года один из экспертов обратил внимание на тенденцию роста брешей в веб-приложениях в целом и приложениях, реализованных на PHP в частности. По данным, собранным в течение первых 9 месяцев текущего года, веб-приложения заняли три верхних позиции в списке самых распространенных уязвимостей. Например, в сентябре 45 процентов инцидентов в области информационной безопасности были связаны со случаями кросс-сайт скриптинга, внедрением багов в базы данных или уязвимостей, связанных с изменением PHP файлов. В настоящее время PHP используется приблизительно в 20 миллионах доменов и 1,3 миллиона IP-адресов.

Популярный язык программирования стал объектом особого внимания на прошлой неделе, после того, как группу разработчиков языка покинул Стефан Эссер (Stefan Esser), занимавшийся обеспечением безопасности PHP. В качестве причины своего ухода Эссер назвал нерасторопность других разработчиков в плане ликвидации угроз безопасности. В свою очередь, члены PHP Group заявили, что Эссер покинул их из-за того, что потерял интерес к разработке в составе их команды.

Согласно данным NIST, по состоянию на 15 декабря из 6198 уязвимостей, зафиксированных в 2006 году, 2690 (или 43 процента) содержали в описании слово «PHP». «Я думаю, обычным людям тяжело создавать безопасные динамические веб-приложения. Языки для создания сайтов должны быть адаптированы под "чайников" максимально возможно. Во многих случаях я, будучи профессионалом в области безопасности, ломал голову над тем, как укрепить безопасность кода. Я хотел укрепить ее, но для меня не было очевидным, как это сделать», — заявил представитель NIST Питер Мелл (Peter Mell).