пятница, июня 20, 2008

IT-Безопасность: KIS 2009 протестирован лабораторией AV-Comparatives


«Лаборатория Касперского» сообщает о первом тестировании новейшего решения для защиты домашних пользователей от всех видов информационных угроз, Kaspersky Internet Security (KIS) 2009, проведенном авторитетной австрийской тестовой лабораторией AV-Comparatives. По эффективности новый защитный комплекс на 47% превзошел показатели предыдущей версии продукта, а также со значительным отрывом опередил большинство конкурентов.

В результате проведенного тестирования Kaspersky Internet Security 2009 автоматически заблокировал (или рекомендовал пользователю заблокировать) около 68% неизвестных вредоносных программ. Данный показатель входит в тройку лучших результатов, продемонстрированных различными антивирусными решениями в ходе ретроспективного теста проактивной защиты, проведенного AV-Comparatives одновременно с тестированием KIS 2009.

Так как в новейшем решении «Лаборатории Касперского» для проактивного обнаружения вредоносных программ используются технологии, не имеющие аналогов у представленных в тесте конкурентов, авторы исследования сочли необходимым оценивать Kaspersky Internet Security 2009 за рамками общего теста. При этом уровень проактивного обнаружения вредоносных программ, продемонстрированный продуктом, значительно превзошел показатели, показанные в ретроспективном тесте продуктами таких компаний, как Symantec, McAfee и Microsoft, а также продуктами целого ряда менее крупных производителей, включая компании AVG, Norman, Eset и BitDefender.

В Kaspersky Internet Security 2009 помимо сигнатурного детектирования вредоносных программ, эвристического анализатора и поведенческого блокиратора реализован уникальный модуль фильтрации активности приложений, использующий технологию HIPS (Host-based Intrusion Prevention System). Он обеспечивает защиту системы от любых угроз – как уже существующих, так и еще неизвестных. Все неизвестные приложения подвергаются многофакторному анализу, на основе которого им присваивается определенный рейтинг опасности.

Решение Kaspersky Internet Security 2009 будет представлено на российском рынке в конце августа 2008 г. Пользователи предыдущей версии, Kaspersky Internet Security 7.0, смогут обновить ее бесплатно.

cnews.ru

вторник, июня 17, 2008

IT-Безопасность: Сезонное обострение хактивности

Из журнала "Компьютерра"
Сезонное обострение хактивности

Автор: Киви Берд
Опубликовано 17 июня 2008 года


Исторически сложилось так, что в майские дни - накануне летних сессий и отпусков - во всем мире проходит множество научных конференций, в том числе и по компьютерной безопасности. На сей раз май выдался необычно плодотворным на доклады по "хакерской" тематике. По-настоящему интересных, можно даже сказать, этапных работ опубликовано не меньше полудюжины. Мы расскажем лишь о трех из них: две были представлены на конференции IEEE по проблемам безопасности и приватности (IEEE Symposium on Security and Privacy), одна - на USENIX.

Автоматизация вредительства
Команда из четырех человек, работающих в разных университетах США, разработала технологию автоматической генерации кода атаки на такую уязвимость в ПО, которая заранее неизвестна, а вычисляется путем сличения исходной и пропатченной версий программы ["Automatic Patch-Based Exploit Generation" by David Brumley et al.].

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

Разработанная ныне технология APEG (Automatic Patch-based Exploit Generation) позволяет за время от нескольких секунд до нескольких минут сгенерировать код атаки для большинства типов программных уязвимостей. По мнению разработчиков, это означает, что если корпорация Microsoft существенно не изменит способ распространения патчей среди клиентов, то последствия могут оказаться тяжелейшими. Ведь злоумышленники, заполучив в руки систему типа APEG, могут обнаружить уязвимость по свежевыпущенному патчу и провести атаку до того, как этот самый патч будет установлен на атакуемую машину.

Нельзя сказать, что APEG - принципиально новое слово в мире компьютерной безопасности - выявлением дыр по патчам, призванным их залатать, исследователи занимаются уже не первый год (см. врезку), но практически полностью автоматизировать этот процесс действительно удалось впервые. Для этого разработчики весьма своеобразно применили математические техники автоматического доказательства теорем и подтверждения корректности логики системы.


Патч как инструкция для злоумышленников
В 2005 году, когда корпорация Microsoft в очередной раз выдала публике скупую информацию о латании критической уязвимости в браузере Internet Explorer, специалист по обратной инженерной разработке Халвар Флэйк (Halvar Flake) решил выяснить, в чем там дело. Компания Флэйка SABRE Security разработала на продажу специальный аналитический инструмент BinDiff для выявления различий в бинарных кодах программ, исследователь продемонстрировал эффективность нового инструмента на примере сравнения исходной и пропатченной версии браузера Microsoft. Специфические отличия в версиях программ, указавшие на уязвимость в обработке графики формата PNG, были обнаружены и проанализированы меньше чем за двадцать минут. Конечно, столь впечатляющая скорость анализа не в последнюю очередь объясняется небольшими размерами PNG-патча, тем не менее демонстрация выглядела весьма эффектно и стала одним из первых наглядных примеров того, как код патча сам предоставляет информацию о скрытой в системе уязвимости.

После этой работы исследователи SABRE опубликовали еще несколько статей, где показали, как с помощью BinDiff по пакетам апдейтов Microsoft за несколько часов можно создавать вредоносные коды, эксплуатирующие разнообразные дыры в системе. Попутно выяснилось, что примерно тем же самым хакеры андеграунда занимались и прежде. Теперь же инструменты вроде BinDiff или функционально похожей программы IDA Pro с их дружественным пользовательским интерфейсом существенно раздвинули границы как технологии, так и круга лиц, владеющих подобным инструментарием.

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

Можно сказать, что алгоритм APEG работает как доказательство корректности системы, проводимое в обратную сторону. Сначала выявляются различия в исполняемых кодах программы до и после применения заплатки, а затем по ее коду анализируется, для чего она предназначена. Патчи безопасности обычно содержат тест, который определенным образом ограничивает допустимые значения на входе системы, но существует процедура из арсенала формального доказательства теорем, позволяющая пройти по коду и автоматически выявить набор входов, которые отлавливаются тестами нового патча. Когда это сделано, применяется специальный набор правил-эвристик для точной локализации места уязвимости, затем генерируется несколько вариантов кодов, потенциально способных эксплуатировать данную уязвимость, а тестовые испытания устанавливают, какой из кодов реально срабатывает.

Работоспособность APEG была проверена на пяти из недавних патчей Microsoft. После того как выявлялись различия в бинарных кодах исходной и пропатченной программ, системе требовалось от шести секунд до трех минут, чтобы сгенерировать вредоносный код, эксплуатирующий каждую из уязвимостей.

Строго говоря, нельзя утверждать, что APEG создает уже полностью готовые для реальной атаки средства. Не доказано и то, что технология универсальна, то есть может обнаруживать и использовать "в корыстных целях" любой тип уязвимостей. Тем не менее она показывает, что вредоносные коды на основе патчей действительно можно создавать очень быстро. А это значит, что Microsoft не предпринимает адекватных шагов для затруднения подобных атак (которые, повторим, не столь уж и новы). В качестве возможных шагов для улучшения ситуации с защитой разработчики APEG предлагают Microsoft несколько решений: искусственное "затемнение" кода патча командами-пустышками, шифрование патчей при рассылке с последующим распределением ключа для одновременной активации, использование пиринговых технологий для более быстрой повсеместной установки патчей.

Разумеется, ни одно из этих решений не устраняет проблему полностью, однако, по мнению ученых, делает ситуацию менее угрожающей.

Процессор враждебных намерений

Следующая работа - с майской конференции-се минара по крупномасштабным и новым компьютерным угрозам (USENIX workshop on Large-Scale Exploits and Emergent Threats [LEET]). Сотрудники Иллинойского университета (Урбана-Шампань) представили на удивление эффективный подход к добавлению аппаратных закладок в компьютеры общего назначения ["Designing and Implementing Malicious Hardware" by Samuel T. King et al.].

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

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

В работе ["Designing and Implementing Malicious Hardware" by Samuel T. King et al.] представлена общая конструкция и конкретные формы реализации так называемых IMPs (Illinois Malicious Processors, "иллинойских вредоносных процессоров"). Показано, что даже с учетом жестких ограничений по месту, его все равно достаточно для планирования разнообразных типов атак, а не одной узконаправленной. Такая гибкость схемы позволила разработчикам продемонстрировать две конкретные конструкции и реализовать их практически в конкретной системе FPGA-чипа, то есть процессора с перепрограммируемой логикой. Вот примеры, подтверждающие общую концепцию.

Эскалация привелегий. Используя механизм доступа к памяти, реализован вредоносный сервис, поднимающий привилегии пользовательского процесса до высшего (root) уровня. При выполнении такой атаки программа эскалации привилегий использует аппаратную закладку в процессоре для отключения защиты привилегированных областей памяти. Для реализации механизма доступа к памяти требуется увеличить число гейтов логики в процессоре меньше, чем на 0,05%. Он позволяет напрямую нарушать все предположения ОС относительно обеспечиваемой защиты памяти.

Входной бэкдор. Используя специально разработанный механизм теневого режима, разработчики реализовали вредоносный сервис, служащий постоянным "черным ходом" в систему. Чтобы начать атаку захвата, злоумышленник посылает сетевой пакет в систему жертвы, где ОС первым делом инспектирует этот пакет, проверяя контрольную сумму UDP. Сам акт проверки пакета (необходимый для принятия решения о том, следует ли его отвергнуть) запускает троянскую закладку в железе, а вредоносная программа интерпретирует содержимое пакета как новый код прошивки, который невидимо загружается в процессор. Операционная же система тем временем отбрасывает непрошеный пакет и продолжает работу, не заметив атаки.

Код прошивки, реализующий теневой режим, отслеживает login-приложение для входа в систему. И когда некто пытается войти с особым, заранее известным закладке паролем, та подменяетзначение функции проверки пароля на "правильный" и тем самым гарантирует доступ в систему любому, кто знает хитрость. Чтобы скрыть следы атаки, сразу после успешной попытки логина прошивка сама себя выгружает и отключает теневой режим, возвращая системе все ресурсы процессора. Таким образом, послав сетевой UDP-пакет и тут же войдя в систему, злоумышленник может сократить время работы теневого режима до минимума. Если же система жертвы не имеет выхода в сеть, то для включения закладки-бэкдора можно использовать похожий механизм на основе внешнего накопителя. Например, в USB-модуле флэш-памяти для этого подходит самый первый блок, необходимый для идентификации типа файловой системы. Механизм теневого режима увеличивает количество логических гейтов схемы всего на 0,08%, давая при этом неограниченный доступ к компьютеру без опоры на какие-либо программные уязвимости.



Оптический темпест
Побочные компрометирующие излучения в диапазоне видимого света можно именовать, по терминологии западных спецслужб, "оптическим темпестом" (словом "Tempest" в США и странах НАТО, начиная с 1950-х годов, стали называть утечки информации по побочным каналам). О том, применяются ли спецслужбами для шпионажа оптические темпест-устройства, сколь-нибудь достоверной информации нет (в отличие, скажем, от устройств электромагнитного радиодиапазона или особых акустических систем). Однако об открытых исследованиях академических институтов за последние годы опубликовано несколько весьма интересных работ, касающихся оптического темпеста.

Работающий в Кембридже немецкий ученый Маркус Кун в 2002 году показал, что имеется возможность с расстояния в несколько сотен метров восстанавливать картинку на экране телевизора или ЭЛТ-монитора по одному лишь мерцанию света в комнате. Куну для этого потребовались хорошая оптическая труба, качественный светочувствительный датчик и доскональное понимание тонкостей работы электроннолучевых трубок.

Примерно тогда же американский исследователь Джо Лоухри показал, что с помощью аналогичной техники - приличной оптики и светового сенсора - можно на расстоянии до полутора километров снимать данные с постоянно мигающих лампочек-индикаторов компьютерного оборудования. Например, в модемах, подключающих машину к сети, мигание светодиода соответствует битам проходящей через компьютер информации.

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

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

Ученые наглядно продемонстрировали, что для закладок, несущих серьезную угрозу, требуется на удивление мало места в общей схеме, что чрезвычайно затрудняет их выявление. Для login-атаки, к примеру, потребовалось всего 1340 гейтов, а в результате злоумышленник получает полный высокоуровневый доступ к компьютеру. Причем та же самая аппаратная база способна поддерживать широкий спектр разных атак и достаточно гибка для динамических модификаций функциональности. В целом же, по мнению авторов работы, злонамеренные процессоры оказываются более практичны, гибки и более трудны для выявления, чем можно было предположить при начальном анализе проблемы. Иначе говоря, вредоносные аппаратные закладки явно заслуживают пристального внимания и тщательного изучения.

Компрометирующие отражения, или от чайника до телескопа

Группа исследователей из Саарландского университета (Саарбрюккен, Германия) представила работу ["Compromising Reflections or How to Read LCD Monitors Around the Corner" by M. Backes et al.], достойную увековечивания в каком-нибудь шпионском триллере. С помощью свободно доступного оборудования ученые продемонстрировали, что картинку с компьютерных дисплеев можно считывать по крошечным отражениям в столь обыденных предметах, как очки, чайники, ложки, пластиковые бутылки и даже по отражению в глазу человека. Единственное, по сути, что для этого требуется, - современный телескоп. Чем он мощнее и дороже, тем больше расстояние, с которого возможен столь экзотический метод шпионажа.

Как рассказывают участники проекта, эта идея родилась случайно, в один из погожих летних дней прошлого года, во время послеобеденной прогулки по университетскому кампусу. Кто-то обратил внимание, как много компьютеров работает за окнами окружающих домов и как было бы круто вот так, мимоходом, заглянуть в монитор каждого из них и посмотреть, кто чем занимается.

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

С таким оборудованием, к примеру, на расстоянии около пяти метров по отражению на чайнике удалось получить вполне читаемое изображение текстового документа Word с размером шрифта 12 точек. При вдвое большем расстоянии размер все еще различимых букв составил 18 точек. Ну а когда через знакомых астрономов удалось раздобыть телескоп помощнее, модель Dobson за 27,5 тысячи долларов, то картинки-отражениявполне приличного для чтения качества стало возможным получать и при тридцатиметровом удалении.

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

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

Источник

суббота, июня 07, 2008

IT-Безопасность: Rustock.С



«Неуловимый» руткит



В декабре 2006 года в некоторых кругах исследователей проблемы руткитов (как blackhat, так и whitehat) стали циркулировать слухи о том, что кем-то создан и выпущен в свет «абсолютно неуловимый руткит» - Rustock.С, - который при активном заражении не способно обнаружить ни одно из существующих антивирусных или антируткит-решений.

Длительные поиски «мифического руткита» не увенчались успехом. Это привело к тому, что любая информация о «Rustock.С» стала восприниматься в околоисследовательских кругах как шутка. Так продолжалось вплоть до мая 2008 года.


Диагноз «Доктора»


В начале мая российская компания DrWeb заявила антивирусной общественности, что ее специалистами был обнаружен руткит Ntldrbot, он же Rustock.С. Новость столь же неприятная, сколь и сенсационная.
Согласно заявлению представителей DrWeb, этот руткит с октября 2007 года оставался неуловимым для всех антивирусных компаний. Выдвигалось предположение, что при помощи Rustock.C была создана одна из самых мощных на сегодняшний момент зомби-сетей, предназначенная для спам-рассылок. Приводились и ссылки на результаты исследования компании Secure Works, согласно которым бот-сеть, созданная Rustock, стоит на третьем месте среди крупнейших бот-сетей и способна рассылать ежедневно до 30 миллиардов спам-сообщений. Однако вряд ли оценки Secure Works могли иметь какое-либо отношение к найденному руткиту, поскольку он фактически был неизвестен до мая 2008 года. Скорее всего, эксперты Secure Works имели в виду сеть, созданную ранними вариантами Rustock – А и B (по классификации «Лаборатории Касперского» - Costrat и SpamTool.Win32.Mailbot).
Судя по опубликованной DrWeb информации, образец настоящего Rustock.С попал в руки специалистов компании в конце марта 2008 года, а на анализ кода руткита, создание и выпуск средств его детектирования и лечения им потребовалось более месяца. Только после этого о находке были извещены и другие антивирусные компании.
В описании руткита, сделанном DrWeb, оставалось слишком много белых пятен. И, в первую очередь, было абсолютно непонятно, каким способом и когда распространялся этот руткит и почему с октября 2007 года он не был никем обнаружен.
Образец тела руткита, распространенный сотрудниками DrWeb, представлял собой драйвер операционной системы Windows размером 244 448 байт.
К сожалению, отсутствовал так называемый «дроппер» - файл, который производит установку руткита в систему. Он мог бы значительно облегчить работу других антивирусных лабораторий при анализе и добавлении собственных процедур обнаружения и лечения Rustock.С, а также помог бы ответить на вопрос о способах изначального распространения руткита.
Отсутствовала также какая бы то ни было достоверная информация о наличии данного руткита «в дикой природе». Оставалась вероятность того, что Rustock.С является исключительно «коллекционной» разработкой и не имеет широкого распространения в мире – в таком случае был бы оправдан столь долгий период его поисков.



Лабораторный анализ


«Лаборатория Касперского» приступила к детальному анализу кода руткита 12 мая. Задача, стоявшая перед нашими экспертами, была действительно сложной. Код руткита был полностью зашифрован неизвестным способом и не поддавался обычным методам анализа упакованного кода и эмуляции. Проблема осложнялась еще и тем, что каждый файл руткита имел некую привязку к аппаратной части зараженного компьютера и не мог быть запущен и проанализирован на других компьютерах и виртуальных машинах.

Однако нашим специалистам удалось за два дня справиться с этими сложностями и, подобрав «ключ», расшифровать значительную часть тела руткита. Вечером 14 мая нам открылись участки настоящего кода Rustock.С.



Параллельно с решением этой сложной технической проблемы мы предпринимали попытки обнаружить файл, который устанавливал руткит в систему. Его наличие позволило бы не только значительно ускорить процесс анализа, но и установить источники распространения Rustock.С.

В результате проведенного исследования нами было обнаружено 599 файлов Rustock.С. Часть их представляла собой так называемое «чистое тело» руткита, а часть являлась зараженными системными драйверами. Фактически все файлы были результатом полиморфного изменения одного и того же кода.

Когда был создан руткит


Итак, у нас было шесть сотен файлов, которые отличались размерами и датами поступления в наши ловушки-сборщики файлов. Все найденные файлы попали в ловушки в период с 10 сентября 2007 года по 14 мая 2008 года. Забегая вперед, скажу, что в итоге ни одного образца Rustock.С, созданного ранее сентября 2007 года, нами так и не было обнаружено. Не исключено, что до этого момента действительно могли появляться какие-то более ранние его варианты - тестовые разработки и «пробы пера» автора. Но то, что DrWeb окрестил Ntldrbot, имеет совершенно четкую дату рождения – сентябрь 2007 года.

Как же быть с пресловутыми слухами о Rustock.С, относящимися еще к концу 2006 года? Мы считаем, что в то время никакого Rustock.С не существовало. Он был создан уже после своеобразного пиара в кругах исследователей руткитов – возможно, как реакция на истерию с его поисками. Косвенно этот вывод может подтверждаться и тем фактом, что в код руткита вписано имя вредоносной программы – «Rustock.С», что не соответствует тому названию, которое ранее автор давал вариантам Rustock.A и B («spambot» и номера версий). Название «Rustock» было дано компанией Symantec первым вариантам руткита, датированным 2005 и 2006 годами. Именно оно было принято в среде исследователей проблемы руткитов, и по аналогии с уже известными ранее вариантами Rustock.A и .B «неуловимый» руткит именовался Rustock.С. Так что назвать свой новый руткит именно так автор мог в подтверждение слухов о его существовании.

Так или иначе, первые «рабочие» образцы Rustock.С появились в сентябре 2007 года, а его разработка, очевидно, началась за несколько месяцев до этого.

Модификации


Анализ 599 файлов выявил много интересных деталей, которые ранее не были известны.

Нами было выделено 4 модификации Rustock.С.

Вариант С1 — мы датируем его создание 10-м сентября 2007 года. «Чистое тело» руткита имеет размер 244 440 — 244 512 байт и содержит драйвер и DLL. Именно эта модификация была исследована специалистами DrWeb и представлена другим антивирусным компаниям.

Вариант С2 относится к 26 сентября. Имеет размер 158 432 — 158 464 байт.

Варианты C3 и С4 относятся к 9-10 октября 2007 года. Их размер варьирует в пределах 158 400 — 158 496 байт.

Несмотря на то, что модификация С1 отличается от последующих почти на 100кб, принципиальных различий между ними нет. Автор лишь несколько оптимизировал алгоритм обфускации тела руткита. Все варианты имеют незначительные отличия, касающиеся изменений в коде DLL (спам-бота).

Спам-бот


В течение пяти дней мы проводили анализ руткита: руткит был полностью распакован и запущен на виртуальных машинах (несмотря на отсутствие у нас «дроппера»). Это позволило получить доступ и к коду DLL (спам-бота), обеспечение существования и защита которой является основной целью Rustock.С.



В ходе своей работы руткит извлекает DLL из себя и исполняет ее в системной памяти, внедряя в процесс winlogon.exe. Эта DLL никогда не существует в виде файла на диске и присутствует только в памяти компьютера. Ее задача – рассылка спама с зараженного компьютера. Для выполнения этой задачи она обращается к серверу 208.66.194.215 и получает оттуда шаблоны писем для рассылки. IP-адрес принадлежит американскому хостинг-провайдеру MCCOLO, на ресурсах которого уже довольно давно размещаются и вредоносные программы, и сайты киберпреступных группировок.

Детектирование и лечение


Несмотря на примененные автором средства защиты тела Rustock.С (протектор, криптор, ключ шифрования), с точки зрения добавления детектирования данного руткита в антивирусные базы «Лаборатории Касперского» не было никаких проблем. Складывается впечатление, что автор был настолько уверен в эффективности шифрования своего творения, что не придавал большого значения методам противодействия антивирусным продуктам. Его целью было максимально осложнить и отсрочить анализ кода (как антивирусными компаниями, так и представителями вирусописательских кругов) — именно на это были нацелены все крипто-технологии руткита.

Чуть сложнее обстоит дело с лечением зараженных руткитом системных файлов. Принцип действия руткита основан на заражении только драйверов Windows, созданных Microsoft и загружающихся при старте операционной системы. Именно таким образом руткит получал управление и успешно скрывал свое присутствие в системе. Оригинальный зараженный драйвер хранился в последней секции тела руткита и также был зашифрован.

Алгоритм, которым руткит шифровал тело зараженного драйвера, оказался довольно простым и не зависел от аппаратной части зараженного компьютера. Это позволило нам реализовать детектирование и полноценное лечение зараженных файлов.

Руткит был классифицирован как Virus.Win32.Rustock.a. Именно как вирус — поскольку Rustock является полноценным файловым вирусом, работающим в режиме ядра операционной системы.

Процедуры детектирования и лечения зараженных файлов были выпущены «Лабораторией Касперского» 20 мая 2008 года (через 8 дней после начала исследования).

Возможность детектирования активного руткита в зараженной системе и лечения зараженных файлов полностью реализована в новой версии нашего антивируса — KAV\KIS 2009. Пользователи других версий могут проверить свои компьютеры на наличие Rustock при помощи Rescue Disk с любой версией нашего антивируса. Они также могут обнаружить и вылечить подозрительные файлы при отсутствии активного заражения.


Вопросы и ответы


Казалось бы, задача решена – руткит повержен, и его жертвы получили надежное решение для выявления и устранения проблемы. Однако по-прежнему оставались открытыми главные вопросы: как распространялся Rustock, и действительно ли он существует «в дикой природе»? Найти ответы на эти вопросы и расставить все точки над i было для нас делом чести.


Распространение Rustock


В течение нескольких дней все имеющиеся у нас самплы руткита подвергались детальному анализу на предмет установления их «аппаратных настроек». Это могло дать хотя бы приблизительное представление о масштабах распространения Rustock. Все данные сопоставлялись с датами обнаружения самплов.

Выяснилось, что 590 из 599 самплов попали в наши ловушки с 10 сентября по 23 ноября 2007 года. И только 9 — в период с 23 ноября 2007 года до середины мая 2008 года.

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

Картина получилась следующая:
ВариантыДата обнаруженияПериоды появленияКоличество файлов
C110.09.200710-13 сентября 2007 года321
C226.09.200727 сентября — 9 октября 2007 года;
12 ноября — 22 ноября 2007
199
C39-10 октября 20079-17 октября 2007 года;
12 ноября — 22 ноября 2007
31
C49-10 октября 20079-17 октября 2007 года;
12 ноября — 22 ноября 2007
48

С 17 октября по 12 ноября 2007 года не было зафиксировано ни одного случая появления Rustock. Однако с 12 ноября по 22 ноября отмечен новый всплеск активности, причем в основном относящийся именно к варианту C2 (от 26 сентября) с незначительными добавлениями вариантов C3 и C4.

С 23 ноября 2007 года наступает долгий, на несколько месяцев, период затишья (или «смерти»?) Rustock.

Данные были весьма интересны, но масштабы и способы распространения Rustock по-прежнему оставались неизвестными. Несмотря на все усилия, так и не был обнаружен «дроппер» руткита.

Но в конце концов удача нам улыбнулась. Было обнаружено еще более 500 файлов руткита, и именно они дали нам все недостающие звенья цепи.

Ботнет


Наши выводы о том, что активное распространение Rustock началось 10 сентября 2007 года, полностью подтвердились. Теперь мы знаем в деталях, как, с каких серверов он загружался и как устанавливался в системы. Есть у нас и ответы на вопросы «А где же дроппер?» и «Действительно ли пользователи антивирусных продуктов были беззащитны перед «неуловимым» руткитом, который распространялся минимум три месяца?».

К сожалению, способ и каналы распространения Rustock заставят поволноваться многих экспертов информационной безопасности.Вот названия, хорошо известные любому антивирусному эксперту:
CoolWebSearch / IFrameBiz / Trafficadvance / LoadAdv.

Да, мы в очередной раз столкнулись с одной из самых известных киберпреступных группировок в Интернете, с которой ассоциируются эти названия. Все они относятся к их сайтам и их вредоносным программам. Банда существует как минимум с начала 2004 года и активна в настоящий момент. Самыми известными и получившими широкое распространение творениями группировки были такие троянцы, как Harnig, Tibs, Femad, LoadAdv и различные модификации Trojan-Downloader.Agent и Small, а также троянец Inject.

Эти умельцы всегда оказывались в авангарде всех вирусных новшеств: в свое время именно они первыми стали массово использовать троянские загрузчики в chm-файлах, именно на их серверах были обнаружены первые варианты эксплоитов уязвимостей в обработке ANI- и ICO-файлов. Они использовали троянские программы, написанные на Java (Trojan-Downloader.Java.ClassLoader), и они же задали моду на использование скриптовых загрузчиков.

«Фирменным» признаком группировки IFrameBiz долгое время были домены в зоне .biz и имена файлов вида loadadv*.exe.

Следы этой группы ведут в Россию. Большинство ее членов, несомненно, проживает именно здесь. На ранних стадиях своего существования группа активно использовала хостинг-ресурсы в Санкт-Петербурге. Также было отмечено ее взаимодействие с печально известной сетью RBN (Russia Business Network), которую многие эксперты также связывают с этим городом.

За 4 года существования группа создала одну из мощнейших систем распространения вредоносных программ. Ее ботнет, основанный на миллионах зараженных различными загрузчиками (в первую очередь Tibs и Femad) компьютеров, способен загрузить на инфицированные машины любую новую вредоносную программу в течение короткого периода времени. Именно такой способ сейчас является эффективной альтернативой рассылкам вредоносного кода по электронной почте, с которыми антивирусная индустрия давно научилась бороться.

Ботнет IFrameBiz активно используется как плацдарм для распространения новых вредоносных программ. Заказчик оплачивает период времени, в течение которого его троянская программа будет распространяться при помощи ботнета. После чего и начинается ее «заливка». Зачастую один и тот же загрузчик (например, Tibs) устанавливает сразу несколько троянцев от разных заказчиков. Услуга пользуется спросом, и даже такое одновременное выполнение нескольких заказов у клиентов не вызывает протеста.

К услугам IFrameBiz прибегали и прибегают как создатели множества Adware-программ, так и желающие создать свой собственный ботнет, спамеры, организаторы DDoS-атак и так далее. Если проводить параллели все с той же RBN, то можно сказать, что RBN — это аппаратная и техническая часть бизнеса вирусописателей, а IFrameBiz — программная начинка и пусковая кнопка для великого множества современных вредоносных программ.

Именно к IFrameBiz и обратились летом 2007 года авторы руткита Rustock с заказом на его распространение. Однако либо троянцы IframeBiz были неспособны незаметно активировать Rustock в системах, либо авторы руткита не хотели давать в руки исполнителей заказа сам код руткита, опасаясь кражи идей и технологий. Для «заливки» по каналам IFrameBiz был создан совершенно отдельный модуль!

Реконструкция событий


Рассмотрим на конкретном примере, что и как происходило в конце сентября 2007 года на одном из зараженных компьютеров, входящих в ботнет IFrameBiz.

Установленный в систему загрузчик (вероятно Tibs) обращается к одному из серверов ботнета в зоне .hk (Хорватия — домены в этой зоне стали использоваться группой в 2007 году) и пытается загрузить файл loadadv351.exe.

Данный файл является усовершенствованным модулем все того же ботнета. По классификации «Лаборатории Касперского», это Trojan.Win32.Inject.mt. Название отражает суть действий вредоносной программы — она внедряет («инжектирует») себя в процесс Explorer.exe, обходя таким образом многие сетевые экраны, и получает возможность для бесконтрольной загрузки файлов в систему.

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

Троянец загружает в систему несколько файлов с разных серверов — либо принадлежащих заказчикам, либо с используемых ими ресурсов на серверах IFrameBiz. В рассматриваемом случае файлы загружаются с ресурсов клиентов, арендованных ими у IFrameBiz (http:// *.biz/progs/*). Одновременно производится сбор и отправка данных о зараженном компьютере — операционной системе, жестком диске и прочее. Эти данные нужны для учета состояния бот-сети, ее географического распределения и так далее.

Итак, в системе появляются еще несколько файлов, из которых нас интересуют два — назовем их «1.exe» и «2.exe». Сейчас наше внимание будет направленно на 1.exe (к файлу 2.exe мы вернемся позже).

Это еще один загрузчик, однако весьма необычный. Первый его образец был обнаружен «Лабораторией Касперского» 10 сентября 2007 года — в тот же день, когда появились первые варианты Rustock. Это совпадение уже не кажется удивительным, не правда ли? С того же дня этот загрузчик детектировался нами как Trojan-Downloader.Win32.Agent.ddl.

Эта вредоносная программа содержит в себе драйвер, который загружается в ядро операционной системы (фактически мы уже имеем дело с руткитом!). Код драйвера зашифрован с использованием сложного алгоритма шифрования, очень напоминающего алгоритм, использованный при шифровании Rustock.

Снятие всех слоев защиты с драйвера приводит нас к самому интересному: это программа-загрузчик Rustock, не менее «мифическая», чем сам руткит.



Недостающее звено


Если про руткит слухи ходили еще с декабря 2006 года, то первое и единственное упоминание о загрузчике и самом факте его существования относится к концу октября 2007 года - спустя почти два месяца после того, как он был обнаружен и добавлен в наши антивирусные базы. Стоит ли говорить о том, что по причине «неуловимости» к тому моменту самого Rustock.C никто и не задумывался о существовании его программы-загрузчика.

Однако даже после детектирования Rustock.С, когда следовало найти его «дроппер», некоторые антивирусные компании остановились на достигнутом, ограничившись детектированием руткита. Они не стали тратить время на выяснение того, как руткит попадал на компьютеры и действительно ли пользователи были беззащитны перед «неуловимым руткитом».

Наше исследование дало нам ответ на эти два вопроса. Начиная с 10 сентября 2007 года, с первого же дня распространения через ботнет IFrameBiz руткита Rustock.С, «Антивирус Касперского» детектировал его «разносчика» - Trojan-Downloader.Win32.Agent.ddl. Позже детектирование этого троянца появилось еще у целого ряда антивирусных компаний.

В течение нескольких месяцев уберечь машины пользователей от заражения «неуловимым» руткитом могло только своевременное детектирование его загрузчика.

К сожалению, даже в настоящие время (начало июня 2008 года) некоторые антивирусные продукты по-прежнему не ловят Agent.ddl.

Загрузчик


Как было отмечено выше, троянец состоит из двух компонентов – основного тела и драйвера. Драйвер собирает информацию о системе: идентификаторы производителя и модель устройств на материнской плате, дату установки и точную версию операционной системы. Затем эта информация зашифровывается и пересылается на сервер автора (или заказчиков) Rustock: 208.66.194.215.

Содержимое буфера, передаваемого на сервер в зашифрованном (TEA) виде:

TSC, Bridge0, Bridge1, InstallDate, Version, ProductID.

Сервер, на который идет отправка данных (208.66.194.215), тот же, который мы уже видели в DLL (спам-боте) руткита — именно оттуда Rustock получает письма для рассылки. Однако метод взаимодействия драйвера загрузчика с сервером отличается от метода, использованного в спам-боте.

Драйвер Agent.ddl работает с виртуальным устройством TCP/IP напрямую из нулевого кольца, в результате чего исходящий с машины трафик при активном заражении невозможно обнаружить с помощью некоторых снифферов/межсетевых экранов. Agent.ddl устанавливает соединение на 443-й порт, пытаясь замаскировать данные под пакеты протокола HTTPS. В результате исследователь, даже перехватив трафик на шлюзе, не сразу поймет, что это никакой не HTTPS, а просто зашифрованные данные, собранные на зараженном компьютере.

Вот пример пакета с зараженной машины, который выдавался за HTTPS данные:

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

Следует отметить что авторы троянца-загрузчика явно старались максимально усложнить жизнь исследователям кода драйвера.

IP-адрес центрального сервера, как и порт, по которому будет обращаться драйвер, зашиты в тело программы, так чтобы скрыть их явное представление:

push 00000BB01 ; порт — 443

push 0E00C04E1
sub d,[esp],00849C211; Разность равна 0xD7C242D0, т.е. IP-адресу 208.66.194.215


Авторы поработали и над обфускацией кода. Например, простая операция

mov [eax], ecx

после обфускации выглядит так:

push ebx
mov ebx, 0x03451b8c
sub ebx,eax
sub ebx, 0x03451b8c
neg ebx
mov [ebx], ecx
pop ebx


Одна инструкция заменялась на семь. Можно вообразить, что из себя представляют остальные «внутренности» драйвера!

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

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

Сгенерированный файл руткита, «чистое тело», загружается на компьютер-жертву, где Agent.ddl производит его активацию в системе. Rustock.C заражает свой первый системный драйвер, и еще одним компьютером в новом спам-ботнете становится больше.

В настоящее время сервер заблокирован. Все пакеты, идущие к нему, фильтруются сетевыми маршрутизаторами. Должно быть, компетентные органы уже заинтересовались упомянутым IP-адресом.

Заключение


Реконструкция событий, выполненная нашими экспертами, доказывает факт активного распространения данного руткита в сентябре-ноябре 2007 года. С одной стороны, использованная для этого сеть IFrameBiz могла обеспечить ему действительно широкое распространение. С другой стороны, приведенные факты показывают, что «неуловимость» руткита была вызвана исключительно высоким уровнем шифрования его кода и использованием множества антиотладочных приемов, затруднявших его анализ для большинства экспертов.

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

Все это происходило с Rustock десятки раз, но детальный анализ его кода был сделан только в мае 2008 года.

Rustock.С действительно существует, и это не миф. А вот его «неуловимость» – миф, основанный не на каких-то реализованных в рутките сверхъестественных принципах сокрытия себя в системе, а все на тех же слухах, появившихся еще в конце 2006 года и играющих на руку только авторам вредоносной программы.

Любой руткит, создаваемый с учетом существующих средств детектирования, будет обходить защиту, которую эти средства обеспечивают. Война на уровне ядра операционной системы в конечном итоге сводится к решению одного вопроса: кто раньше получит управление — руткит или антируткит.

Целью автора Rustock было не создание недетектируемого в принципе руткита, а максимальное усложнение процесса анализа руткита после того, как он будет обнаружен. Именно это могло обеспечить некий временной выигрыш между периодом распространения и началом детектирования вредоносной программы.

Остается неясным только один вопрос: почему автор Rustock прекратил в середине октября 2007 года совершенствование руткита и выпуск его новых версий? Не означает ли это, что он занялся созданием нового проекта, и, возможно, где-то уже существует «Rustock.D»?

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

До тех пор, пока в Интернете продолжают существовать IframeBiz и аналогичные ей группы, ответственные за ежедневное распространение сотен новых вредоносных программ, за многочисленные взломы веб-сайтов и десятки эпидемий, праздновать успех в одной локальной победе никак нельзя.

P.S. Выше мы писали о том, что Trojan.Win32.Inject.mt устанавливал в систему два файла — 1.exe и 2.exe. Мы не рассказали о том, чем же был второй файл.

Он был очередным вариантом троянца-шпиона Sinowal. Тем самым Sinowal, который спустя пару месяцев после описываемых событий стал еще одной головной болью для антивирусных компаний и вошел в историю как «буткит».

И Rustock, и Sinowal распространялись одновременно и через один и тот же ботнет. Новые версии Rustock перестали появляться в середине октября 2007 года. Первые образцы «буткита» были обнаружены спустя месяц — в ноябре 2007 года.

Просто совпадение?

Возможно, мы когда-нибудь узнаем ответ и на этот вопрос.

IT-Безопасность: В Opera 9.5 появятся новые средства безопасности


В компании Opera Software сообщили, что в готовящейся к релизу версии браузера Opera 9.5 появится принципиально новый программный набор для предотвращения различных веб-атак, а также для сканирования входящего трафика на наличие злонамеренного программного обеспечения. Для реализации подобного функционала свои разработки предложила компания Haute Security.

Новые коды будут встроены в стандартные средства обнаружения мошеннических сайтов и программ браузера.

В Haute Security говорят, что их компания довольно давно производит дополнительные модули для браузеров, есть в портфолио разработчика и средства для защиты пользователей Firefox и Internet Explorer, однако впервые в истории Haute интеграция защитного ПО идет на уровне кода браузера, что даст больший прирост в производительности и не позволит мошенникам какими-либо способами отключить сканер.

В результате интеграции своей разработки в настольную версию Opera, Haute Security не получит каких-либо отчислений, так как браузер бесплатен, однако сразу после релиза настольной версии, норвежская компания начнет распространение мобильной версии Opera с кодами Haute. Мобильная версия, как известно, является платной, и с этих продаж разработчик уже получит свою долю.

В Opera говорят, что интеграция нового софта в данном случае направлена на конкурентную борьбу с Firefox, третья версия которого будет поставляться с разработками Google.

Источник: cybersecurity.ru

четверг, июня 05, 2008

IT-Безопасность: В интернете появился вирус-шантажист


"Лаборатория Касперского" сообщила о появлении новой версии опасного вируса-шантажиста, известного как Gpcode. Новая версия вируса получила название Virus.Win32.Gpcode.ak. Вирус шифрует пользовательские файлы различных типов (.doc, .txt, .pdf, .xls, .jpg, .png, .cpp, .h и др.) при помощи криптостойкого алгоритма шифрования RSA с длиной ключа 1024 бит.

До сих пор максимальная длина ключа RSA, который удалось "взломать" специалистам "Лаборатория Касперского", составляла 660 байт. На подбор ключа такой длины при помощи машинного перебора требуется около 30 лет работы одного ПК с частотой процессора 2,2Ghz.

После этого инцидента автор Gpcode выждал почти 2 года, прежде чем создать новую, усовершенствованную версию своего вируса, лишенную старых ошибок и использующую еще более длинный ключ.

На данный момент расшифровать пострадавшие файлы не удалось, поскольку новый вирус использует ключ длиной 1024 бит. Расшифровать зашифрованное вирусом Virus.Win32.Gpcode.ak сообщение можно, лишь располагая секретным ключом, которым в настоящее время, вероятно, обладает только автор данного вируса.

Аналитики "Лаборатории Касперского" продолжают анализировать обнаруженный вирус и искать способы дешифровки файлов.

К названиям зашифрованных файлов вирус добавляет подпись ._CRYPT и оставляет в той же системной папке текстовый документ !_READ_ME_!.txt, в котором сообщается о проведенном шифровании и предлагается купить у преступника дешифратор. Полный текст сообщения гласит:

"Your files are encrypted with RSA-1024 algorithm.
To recovery your files you need to buy our decryptor.
To buy decrypting tool contact us at:
********@yahoo.com"


Эксперты "Лаборатории Касперского" рекомендовали пользователям, увидевшим такое сообщение на своем компьютере, обратиться к экспертам компании, используя другой компьютер с выходом в интернет, по адресу stopgpcode@kaspersky.com, и сообщить о точной дате и времени заражения, а также последних действиях на компьютере за последние 5 минут до заражения. При этом не следует перезагружать или выключать зараженный компьютер.

понедельник, июня 02, 2008

IT-Безопасность: MediaDefender прокомментировала факт организации DDoS-атак на серверы Revision3


Антипиратская организация MediaDefender, как сообщается на сайте Wired News, дала комментарии по поводу недавних атак на серверы онлайновой телесети Revision3. Около недели назад сеть Revision3 подверглась массированным DoS-атакам, в результате которых была нарушена работа основного сайта компании, RSS-сервера и системы корпоративной электронной почты. Впоследствии выяснилось, что за атаками стоит существующая с 2000 года организация MediaDefender. Основная специализация MediaDefender - это борьба с пиринговыми сетями, через которые распространяется нелегальный контент. Для искоренения пиратства MediaDefender использует все доступные ей способы, включая технологический саботаж, то есть, подгрузку мусорного контента. Причем MediaDefender располагает весьма мощной аппаратной базой из 2000 серверов, подключенных к интернету посредством высокоскоростного соединения с пропускной способностью 9 Гбит/с. На прошлой неделе выяснилось, что организация MediaDefender без разрешения использовала открытый сервер Revision3 для распространения фальшивых торрентов. Когда это вскрылось, телесеть закрыла доступ к своему серверу, а MediaDefender в ответ ударила по Revision3 распределенными DoS-атаками. В результате, пользователи не могли получить доступ к последним эпизодам сериалов и телевизионных шоу. Расследованием происшедшего инцидента уже занимается ФБР, а MediaDefender, между тем, заявляет, что понятия не имела о принадлежности атакуемых серверов компании Revision3. По словам исполнительного директора MediaDefender Рэнди Саафа, его организация обнаружила открытый сервер, через который якобы распространялись пиратские материалы. При этом MediaDefender не скрывает факт размещения на сервере телесети Revision3 фальшивых торрентов. И после того, как доступ к серверу был закрыт, MediaDefender с целью его вывода из строя организовала DDoS-атаки. Так или иначе, но проведение DoS-атак в Соединенных Штатах запрещено законом. Поэтому пока не ясно, как власти отреагируют на действия MediaDefender.

источник: uinc.ru

воскресенье, июня 01, 2008

IT-Безопасность: На США и Китай приходится 30% хакерского трафика


Крупнейший мировой поставщик динамических веб-сервисов и систем для интернет-вещания компания Akamai Technologies сегодня опубликовала квартальный отчет "State of Internet" в котором отмечается, что на долю США и Китая приходится треть хакерского трафика в глобальной сети. Представители компании говорят, что на их площадках размещены многие динамические сайты, привлекающие миллионы пользователей, а также злоумышленников, пытающихся "свалить" тот или иной проект или похитить различные данные, поэтому на основе анализа сетей Akamai в нескольких странах можно получить довольно объективную картину.

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

В нынешнем отчете приводятся данные по 125 странам. Сразу за Китаем (16,77% хакерского трафика) и США (14,33%) расположились: Тайвань (11,82%), Венесуэла (8,89%), Аргентина (5,65%), Бразилия (4,75%), Япония (3,56%), Южная Корея (3,43%) и Индия (2,53%). На долю всех остальных стран, куда попала и Россия, приходится еще 25,61% хакерского трафика. В Akamai отмечают, что десятка стран-лидеров списка в общей сложности производят 75% "грязного" трафика.

Наиболее популярным среди хакеров оказался 135-й порт (Microsoft RPC) - на его долю пришлось 29,66% трафика злоумышленников. Далее идут такие популярные порты в системах как: 139-й (NetBIOS) - 13,27%, 22-й (SSH) - 12,08%, 445-й (Microsoft-DS) - 11,02%, 80-й (WWW) - 6,19%, 1433-й (MS SQL Server) - 6,12%, 2967-й (Symantec System Center Agents) - 2,93%, 4899-й (Remote Administrator) - 1,79%, 5900-й (VNC server) - 1,65%. На долю всех прочих системных портов пришлось 15,31% атак.

Также в компании подсчитали, что с января по март 2008 года около 2% от общего трафика составлял DDoS-траффик, единственная задача которого заключается в блокировке того или иного сервера.

Из наиболее заметных инициатив, оказавших влияние на посещаемость большинства международных сайтов, в том числе и мультимедийных, в Akamai называют обрыв кабеля, проходящего по дну Средиземного моря. Данный кабель связывал Европу, север Африки, а также страны Ближнего Востока вплоть до Индии. Всего в результате этого блэкаута в оффлайне оказались несколько сотен миллионов пользователей и более 1000 крупных сетей в Египте, Пакистане, ОАЭ и Кувейте. По данным со статистических серверов Akamai, на многих участках сетей скорость доступа к большинству сайтов на протяжении недели после поломки сократилась в 1,5 - 3 раза.

Для европейских пользователей наибольшее испытание, как ни странно, прошло без широкой огласки в прессе. 13 марта истек срок пирингового соглашения между телекоммуникационными компаниями Telia и Cogent. Стороны не стали его продлять сразу, в результате чего миллионы пользователей в скандинавских странах с трудом смогли попасть на ресурсы основных стран Европы и США, в свою очередь эти стороны также какое-то время "не видели" скандинавских серверов. Однако уже 28 марта компании все-таки решили возобновить соглашение в результате чего все вернулось на круги своя.

Рост глобального проникновения интернет-доступа за квартал в Akamai оценили в 5,3%. По данным компании, в конце 1 квартала было задействовано 329 059 516 уникальных IP-адресов, из которых 96,8 млн пришлось на США, 32,4 млн - на Китай, у Японии насчиталось 24,8 млн адресов, Германия и Франция замыкают пятерку лидеров с 22,8 и 16,4 млн действующих IP-адресов.

Источник: cybersecurity.ru