|
15 июн Опасные пробелы Марта Янус 14 июн Фишеры выбирают LAMP-хостинг Татьяна Никитина 09 сен Web-дефейсеры занялись финансовым мошенничеством Дмитрий Бестужев 20 дек Приложения на PHP стали основной проблемой для специалистов по безопасности Игорь Громов Станьте автором Стать автором нашего блога можно, достигнув рейтинга «+100». На ваш рейтинг влияет оценка ваших комментариев другими посетителями сайта. |
Несколько дней назад я написала в блоге о предназначенном для платформы osCommerce PHP/JavaScript-зловреде, в котором для обфускации вредоносного кода применен новый интересный прием. Так получилось, что чуть позже я наткнулась на еще более «продвинутый» образец PHP-инфектора, также в связи с уязвимым решением для электронной коммерции.
Мой коллега из польского офиса нашей компании попросил меня помочь с обнаружением вредоносного ПО, от которого пострадал интернет-магазин его друга. HTML-страница магазина при открытии ее в браузере содержала ссылку на скрипт jquery.js в генерируемом случайным образом домене третьего уровня в бесплатном домене cx.cc. При этом в исходных файлах на сервере этой ссылки и в помине нет. Поставить диагноз оказалось несложно: данный фрагмент кода добавляется динамически каким-то зараженным PHP-скриптом.
Мы просмотрели все PHP-файлы на сервере и были удивлены: на первый взгляд, ничего подозрительного в них не было. Однако, памятуя о зловреде div_colors, я принялась изучать код строку за строкой. В конце концов мое внимание привлекла небольшая функция в начале одного из основных PHP-файлов.
Также в аналитике
В блоге
В предупреждениях
Согласно результатам опроса, проведенного Антифишинговой рабочей группой (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 Кб] ― лишь предварительные результаты. Полный анализ собранного материала и соответствующие рекомендации будут опубликованы позднее.
Ссылки по теме
Также в аналитике
В блоге
В предупреждениях
Киберпреступники в Бразилии, да и во всей Латинской Америке, практически всегда используют приемы социального инжиниринга для запуска атак. Время от времени они рассылают фальшивые сообщения от банков или популярных интернет-сервисов. База электронных адресов потенциальных жертв составляется на основе адресов, украденных с зараженных компьютеров, и частично — на основе адресов, хранящихся в базах e-mail-клиентов.
После компиляции электронных адресов мошенники используют различные внешние инструменты, например PHP-интерфейс взломанных веб-серверов.
В процессе своего ежедневного анализа я обнаружил интересный интерфейс для массовой рассылки. Код указывает на то, что он был создан в Бразилии:

Также в аналитике
В блоге
В предупреждениях
На веб-приложения, написанные на языке 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).
Ссылки по теме
Также в аналитике
В блоге