dxdt.blog: занимательный интернет-журнал

Предположим, что некий сервис распространяет программу для мобильных устройств, предлагающую какие-то услуги и при этом передающую обратно провайдерам сервиса данные о положении мобильного устройства (используется GPS-модуль). За примерами не нужно далеко ходить: вот вам “Мобильные Яндекс.Карты” – там, очевидно, передача сведений о местоположении устройства-носителя “на центральный сервер” в разные моменты времени используется для построения карты “свободных дорог”.

Допустим, что само мобильное приложение – “анонимное”, при загрузке из Интернета не требует идентифицировать загружающего. Можно ли позже, с помощью анализа перемещения устройства, выяснить, с хорошей точностью, персональные данные пользователя? При этом, понятно, никаких исходных персональных данных программа не собирает: это же не программа-шпион, правда? В записной книжке коммуникатора приложение не роется, каких-то уникальных параметров-идентификаторов из сети оператора связи не получает, и вообще, возможно, код приложения полностью открыт – всё должно быть строго, иначе такую программу перестанут использовать.

На первый взгляд, подобная задача может показаться невероятно сложной, даже неразрешимой: “чистая” программа, анонимная загрузка – есть только данные о вероятном местонахождении конкретного владельца. Как тут этого владельца-то вычислить?

Прежде, отметим один момент: формальной анонимности пользователя вовсе не противоречит создание на сервисе уникального аккаунта, привязанного к данной копии программы. Это необходимо и для обновлений, и для придания устойчивости системе в целом (помогает бороться с “поддельными запросами” злых хакеров и т.д.) Только по аккаунту личность пользователя установить нельзя.

Теперь о том, как же вычислить пользователя. Вот как: фиксируются его места пребывания в рабочее время, и в не рабочее время. Приехал человек на работу, находится долго “на одном месте” – несложно вычислить и место, и, собственно, рабочее время, так как людям свойственно действовать по некоторому графику. Вычисляется всё автоматически, никакой “сложной эвристики”.

Аналогично определяется вероятное место жительства – после работы люди едут домой, понятно. Итак, есть уже пара “точек на карте”, привязанных к одному пользователю. Понятно, что координаты у этих точек размытые, но “размытость” тут будет близка к масштабу с разрешающей способностью типа “с точностью до дома”. То есть, один-два дома вероятного пребывания определить можно в очень многих случаях. Опять же, определяется всё автоматически, “сложной эвристики” – снова не требуется.

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

Действительно, если известен только приблизительный район места жительства пользователя, то “идентифицировать” его персону, по крайней мере, в случае с современным мегаполисом, невозможно: в том же районе прописаны тысячи людей. Но эти тысячи людей совсем не обязательно и работают в одном и том же небольшом районе. Поэтому добавление к “запросу” второго параметра – приблизительный адрес места работы, район – моментально урезает число вариантов до минимума.

Пользователь “вычислен персонально”.

Более того, можно составить чёткие критерии, когда программа “извлечения данных” определила пользователя точно, а когда – нет: просто учитывается число оставшихся возможных вариантов.

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

Главное тут вот что: в приведённом решении хитрой задачи достигается “полная анонимность”, “полное обезличивание” на этапе сбора исходных данных; а позже, совсем другими серверами, из этих “обезличенных данных” восстанавливаются вполне точные персональные данные. Такая вот реконструкция алгоритмами data mining.

Кому интересно, вот ссылка на работу с исследованием этой темы: On the Anonymity of Home/Work Location Pairs. Также, около года назад, я писал про очень логически близкие к только что описанной технологии построения поведенческих профилей посетителей веб-сайтов.

Для тех, кто предпочитает сразу тему развивать: подумайте, что, в теории, аналогичная схема сработает и при анализе пользовательского интернет-трафика.

Сегодня немного “техничная” записка. Есть такой положительно оцениваемый админами и, очевидно, отличный продукт: веб-сервер nginx, единолично поддерживаемый автором – Игорем Сысоевым. Nginx очень популярен, используется массово.

Ну, думаю, понятно, что как всякий нормальный “интернетовский” серверный продукт nginx работает на платформе Unix/Linux. И вот на ReMIX в этом году Сысоев анонсировал бинарную версию nginx для Windows.

Что в этом особенно интересного?

А вот что: есть такая технология в DNS, называется fast-flux. В рамках этой технологии штатными средствами DNS быстро меняется соответствие конкретного доменного имени и IP-адреса сервера. Я как-нибудь напишу про fast-flux в подробностях, сейчас важен лишь один момент: fast-flux активно используется злоумышленниками для размещения вредоносного и просто “неправового” контента в Интернете. Злоумышленникам, fast-flux, применяемый вместе с ботнетом, позволяет скрывать следы и преодолевать провайдерские фильтры, блокирующие доступ по IP-адресам.

Важно: при этом сама технология fast-flux – не является “зловредной”, не использует какие-то уязвимости в DNS, а вполне “легитимна”. Но злоумышленники нашли ей своё применение.

Я только что упомянул ботнет, важный для “зловредного” fast-flux: элементы этого ботнета либо сами раздают “нехороший контент”, либо работают proxy, то есть, передают запросы-ответы между клиентом и каким-то скрытым веб-сервером, где плохой контент лежит. И в первой, и во второй схеме требуется специальное ПО на заражённой машине: веб-сервер, либо реверсивный proxy. Нужно ли говорить, что nginx отлично работает и в первой роли, и во второй? Наверное, нет – сами догадались. (При этом nginx ещё умеет и нагрузку балансировать, и кешировать.)

Специалисты из рабочей группы ICANN, занимающейся fast-flux, включили nginx, отвечающий на http-запросы под “исследуемым доменом”, в список признаков “злонамеренного fast-flux”. Это произошло ещё до выхода Windows-версии nginx. И казалось странным. Но, вообще говоря, появление такого пункта указывало на то, что в Сети есть некоторое заметное число захваченных злоумышленниками unix-серверов.

Ну да, уязвимости есть в разных ОС.

При этом, естественно, подавляющая масса компьютеров, составляющих ботнет работает под управлением Windows.

Для хостингов, для нагруженных серверов веб-сайтов – ОС линейки Windows пока не актуальны. Но, понятно, для Microsoft, особенно в Рунете, портирование nginx под Windows – это важное событие: MS активно пробирается на “хостинговый” рынок. Поэтому, можно предположить, что Microsoft активно поддерживала идею пересаживания nginx на дополнительную платформу (хотя, сам автор nginx говорил на ReMIX, что исходная задумка очень старая; но факты таковы: бета-версия появилась только в 2009 году и анонсировалась на майкрософтовской конференции).

Если взглянуть на практическую сторону: довольно сложно придумать, где бы, на каком бы узле системы предоставления услуг типичного современного хостинг-провайдера windows-nginx мог с выгодой крутиться (за исключением, разве что, windows-хостеров). Дело в том, что там же везде и давно FreeBSD, ну или что-то близкородственное. И nginx давно есть.

Зато вот для использования в ботнетах, работающих на fast-flux, где Windows безоговорочно лидирует – очень кстати соответствующий “бинарник” nginx. Вот такой выходит неожиданный поворот.

Ещё раз отмечу, чтобы избежать кривотолков: nginx – очевидно, хороший эффективный рабочий инструмент, который злоумышленники просто возьмут на вооружение. (Nginx даже гораздо “легитимнее” fast-flux, если так можно сравнивать.) А интересным аспектом здесь будет то, у кого же больше окажется востребована версия nginx под Windows.

В конце апреля “Би-Би-Си” процитировали штатовского полковника (Charlie Williamson), который в выступлении по радио высказывался за создание “официальных” ботнетов (ну, почему-то именно ботнетов) и средств нападения в киберпространстве Интернета.

Понятно, конечно, что использование термина “ботнет” можно воспринимать как утрированный пример, приведённый полковником для публики. Но вообще – ситуация интересная, ведь понятно, что такие публичные заявления не делаются на пустом месте. Вспомним известный вариант: самая распространённая в мире персональных компьютеров ОС – разработана, тиражируется в США и автоматически ходит обновляться на серверы, подконтрольные известной штатовской “микропрограммной” компании. Ну чем не потенциальный ботнет? И даже не нужно находить уязвимости.

Другой момент (обсуждающийся в речах пентагоновских “спикеров”): если появятся “официальные” программы-зловреды, лицензированные на деятельность в интересах правительства США, то как будет решаться вопрос с производителями антивирусного ПО? Надо же им будет как-то выдавать сигнатуры “своих” агентов и регулировать “взаимодействие”. (При этом, как и пишут/говорят, нелицензированные зловреды уже используются специальными службами – ну и это не удивительно, конечно.)

Ещё интереснее: как будут взаимодействовать с независимыми разработчиками, которые возьмут лицензированные штатами зловреды, исследуют их и выпустят бесплатное противодействующее ПО? Наверное, нужно будет как-то поправлять законы в США?

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

Telnic для использования нового домена первого уровня TEL предлагает плагин к MS Outlook. Плагин, понятно, для того, чтобы сразу загружать контактные данные, размещённые под доменом .tel, в Outlook (обратную функциональность также обещают). Напомню, что TEL – он позиционируется как глобальное хранилище контактных данных, использующее для хранения этих данных DNS.

Как это связано с безопасностью? Очень даже напрямую: данные из .tel передаются через запросы DNS, которые, хоть и уже являются источником “дыр” на клиентской стороне, но пока что носят “вторичный характер” в качестве потенциала “угроз”. Плагины (и другое ПО), обрабатывающие информацию .tel – это новый источник “дыр”. При этом плагин для Outlook – это дополнительный программный код, исполняемый на клиентской машине (ну почти что браузер).

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

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

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

Туннели организуются для “обычных” DNS-записей, с использованием подконтрольного злоумышленнику сервера имён, на котором настраивается зона для, опять же, подконтрольного злоумышленнику домена. Но в случае с .tel сам сервис предоставляет богатые возможности по размещению дополнительной информации внутри зоны. Да, эту информацию придётся оформлять как “контактную”. Но нет технологических запретов, которые не позволят записям содержать программный код зловреда, оформленный тем или иным образом.

То есть, предположим, внутри ПО для работы с адресной книгой (пусть это и не плагин для Outlook, про который не известно, что там и как) есть уязвимость. Злоумышленнику остаётся заманить пользователя атакуемой системы на специально подготовленный домен .tel, после чего, по известному из браузерной действительности сценарию, на клиентскую машину проталкивается червь. Но, в отличие от браузерной действительности, червь проталкивается через DNS, так что в итоге на клиентскую машину его засунет вполне “доверенный” DNS-сервер, который обычно даже и находится в локальной сети с атакуемой машиной (а значит тут действуют другие политики безопасности). Ну и напомню ещё раз, DNS-трафик мало кто фильтрует.

Вот такие новые угрозы с новыми доменами.

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

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

По вполне понятным причинам, примеры давайте возьмём не из области систем ПВО, а из другой области. Так, наработан целый пучок использующих аппаратные особенности работы микропроцессоров атак на реализации RSA, AES и других широко распространённых криптосистем. Это именно атаки на конкретные реализации алгоритмов, использующие, например, анализ характеристик энергопотребления процессора во время работы процедур шифрования/дешифрования или умело эксплуатирующие работу кеша процессора в многопотоковой среде ОС. Грубо говоря, сам криптографический алгоритм весьма стоек (например, RSA с длинным ключом), но во время вычисления шифрованных данных “внешние признаки” работы процессора позволяют атакующему получить важную дополнительную информацию, с помощью которой с небольшими вычислительными ресурсами можно систему взломать.

Другой пример: известна атака на защищённые сети Wi-Fi (Wi-Fi chopchop), которая основана на том эффекте, что многие точки доступа Wi-Fi по-разному отвечают на верный по структуре, но “не авторизованный” пакет, и на пакет с ошибкой в структуре (в атаке используются контрольные суммы). Понятно, что речь о пакетах данных в эфире. Такое поведение устройства позволяет атакующему свободно изменять “по кусочкам” перехваченные пакеты и тестировать изменённые пакеты на “верный/дефектный”, частично раскрывая содержимое трафика, даже не зная ключа доступа (собственно, атака вообще не направлена на ключ, но позволяет читать данные).

Да, рассуждая на затронутую тему, можно заметить, что общедоступные коммуникационные устройства проектируют гражданские инженеры – и это другая ситуация, отличная от разработки военного оборудования. Отчасти это так. Но, с другой стороны, военные системы, во-первых, используют либо те же самые процессоры (см. пример с криптосистемами и процессорами), либо близкородственные процессоры – индустрия тут становится всё более “однородной”. Во-вторых, тот же Wi-Fi вполне себе используется в системах вооружений (там просто немного другой стандарт на защищённость оборудования). Ну и ситуация сильно меняется, если речь – о системах “на экспорт”: всё ж работать с “коммерческим железом” – проще, дешевле, удобнее, а для экспортных систем ограничения специальных военных гос. структур, обусловленные национальной безопасностью, отменяются. А кроме того инженеры-программисты “разных заказчиков” бывают очень схожи.

Так что судите сами, насколько же реальны “вторжения в систему управления комплекса ПВО”.

Вот пишут, что штатовский сайт Касперских сломали, утащив базу пользователей вместе с активационными ключами. Пока не ясно, насколько это соответствует реальности. Но если у Касперских на сайте ПО действительно допускает SQL-инъекции, то это ой-ой как плохо – потому что тогда придётся отказываться от их антивирусных-защитных продуктов.

Действительно, ведь их клиентское ПО ходит обновляться на их сервер. Если злоумышленник укатит логины/ключи с сервера, то до перехвата канала обновления уже совсем не далеко. В результате, доверенное ПО на компьютере получает возможность делать что угодно – вот вам и поддельный антивирус.

Update (07/02): Продолжение от The Register, сведения подтверждаются. (Вообще, SQL-инъекция – это, конечно, сильнейший удар по репутации, тут сказать нечего.)

Популярный сетевой червь Downadup (или Net-Worm.Win32.Kido, а также Conficker), между прочим, на практике демонстрирует разнообразие своего сетевого инструментария.

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

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

Самое интересное, что W32.Downadup/Net-Worm.Win32.Kido ещё и умеет анализировать сетевую инфраструктуру. Алгоритм заражения, включающий несколько этапов, требует, чтобы заражаемая машина инициировала соединение через Интернет с заражающей и скачала к себе основной код вируса. Понятно, что брандмауэры, установленные в модемах и маршрутизаторах, обычно противятся такой активности локальных машин. Более того, заражённые машины вероятно располагаются за NATом. Поэтому код Downadup предварительно обнаруживает шлюзы в локальной сети, проверяет их настройки (всё через UPnP), организует себе такой канал, который шлюз будет пропускать в обратном направлении (из внешней сети вовнутрь) и уже с использованием этого канала заражает другие машины.

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

До сих пор в Интернете популярна авторизация по IP-адресу, например в тех же CMS (но не только). Например, помимо предъявления авторизационного куки-файла, для авторизации требуется, чтобы и запрос был с заданного IP-адреса, скажем с того же, с которого делался логин, породивший куку, или просто готовится “белый список” допустимых IP-адресов.

С одной стороны, это увеличивает “стойкость”, так как, на первый взгляд, если злоумышленник “угнал куки” или подслушал снифером пароль, то авторизоваться в системе со своей машины он не сможет, так как у этой машины, предположительно, другой IP-адрес.

А вот с другой стороны в реальности есть хитрости. Например, пользователи, которым требуется авторизация в “защищаемой системе”, могут располагаться за тем или иным NATом – это приводит к тому, что извне IP-адрес соединения пользователя будет выглядеть другим, нежели внутренний адрес этого пользователя. Но не это главное. Главное, что “внешний” адрес разделяется между многими пользователями внутренней сети, то есть с точки зрения внешнего сервера разные компьютеры всех этих пользователей будут выглядеть как имеющие один и тот же IP-адрес. Это сейчас очень и очень распространённая ситуация и в корпоративных сетях, и у “домовых” интернет-провайдеров: IP-адреса – ресурс дефицитный. При этом пользователь, не будучи подкован в технических вопросах, может и не подозревать о том, как хитро всё работает и что он разделяет с соседями один “внешний” IP-адрес.

Теперь приплюсуем сюда такой момент: прослушивать, с целью похищения “куков и паролей”, сетевой трафик данного пользователя минимальными затратами, скорее всего, могут его соседи по сети (скажем, “хакеры-пионеры” балуются в плохо настроенных “домовых сетях”). Выходит, что похитивший авторизационные данные нехороший сосед, очень вероятно, автоматом имеет возможность работать с внешним сервером с того же IP-адреса, что и пострадавший пользователь.

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

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

Кстати, важный аспект, в смысле помехопостановки и использования всяческих ложных целей, – вычислительная мощность компьютеров, и, кроме того, оптимальные алгоритмы.

Например, комплекс ПВО: тут требуется вычислять параметры цели, сопровождать её перемещение (а это означает, что необходимо записывать данные о скорости цели, аппроксимировать траекторию и т.п.). Теперь предположим, что одну реальную цель сопровождает множество ложных. Достаточно большое количество более или менее хитрых ложных целей будет перегружать вычислительную систему комплекса уже задачей распознавания того, что эти цели ложные (даже, если комплекс научили их распознавать). Конечно, совсем простые “обманки” не помогут: можно так настроить радар, что сигналы от них будут отсеиваться ещё на самых ранних этапах обработки. Но, как говорится, беспилотники в помощь.

Другой пример: перспективные спутниковые системы слежения за передвижением объектов на больших территориях. Для чего такие системы мониторинга строятся? Вовсе не для изучения миграций тюленей или круторогих северных оленей. Строятся они для оперативного мониторинга перемещения мобильных ракетных комплексов (с МБР, конечно). Тут куда как более серьёзные требования к вычислительным системам – требуются суперкомпьютеры.

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

При этом точность определения местоположения мобильного объекта целиком и полностью зависит от “глубины” и непрерывности записанной в базах данных “истории” этого объекта перемещений (вчера, два дня назад, месяц назад и т.д.). А ещё нужно сводить воедино сведения от разных датчиков и спутников, учитывать прогнозы (и погоды, и перемещений).

Впрочем, вычислительные мощности и дисковое пространство для долговременного хранения данных теперь сильно подешевели.

Вновь приходится слышать от разработчиков CMS старую песню: “мы закрываем исходный код, потому что там наверняка уязвимости, а в закрытом коде найти их сложнее”. Речь о коммерческой CMS, о PHP, а “закрывают код”, понятно, с помощью Zend Optimizer.

А вот интересно разобраться, кому в действительности нужно, чтобы код был закрыт подобным образом. Разбираемся. Например, раз уязвимости есть (а они есть), то наверняка среди них полно шаблонных решений. Разработчики-то, собственно, нормальные, как и у других продуктов, поэтому нужно ожидать неистребимых SQL injection и далее по списку. То есть, обнаружению и использованию типичных уязвимостей закрытый код не помешал. Не удивительно – ведь от того, что код закрыт, дыры не исчезли, их просто хуже видно.

Но это одно дело. Теперь предположим, что некий квалифицированный специалист-хакер решил найти особую дыру в данной конкретной CMS. CMS эта не самая распространённая, а значит специалиста заинтересовала не просто так, но с точки зрения атаки конкретного сервера. Потому что ради спортивного интереса специалисты не работают по мелочи, а вот под заказ – вполне. (Заказ может быть и “имиджевым”, кстати. Для этого сайт-цель должен быть очень известным.) Специалист либо приобретает демо-версию, либо покупает лицензию – и, так как он специалист, “раскрывает для себя” исходный код и исследует его. То есть, особенных препятствий нет, и специалисту “закрытый код” не очень помешает – всё ж технологии используются известные. Так что опять концепция “спрятанных под Zend`ом дыр” промахивается.

А вот “хакеры-дети” (“пионеры”), которым не все технологии понятны – может, им помешает “закрытый код”? Нет, оказывается, что “пионеры” либо используют готовый инструментарий, который ищет шаблонные уязвимости (от доступности исходных кодов не зависят), либо просто отправляются атаковать другой сервер. Предположить, что этот тип атакующего станет тратить сутки на тщательный аудит кода одной CMS, когда на сайтах вокруг полно других соблазнов, будет, мягко говоря, странным – потому что это уже не начинающий хакер выходит, а тот самый спец, работающий под заказ. То есть, “закрытый код” тут просто не играет роли, которую ему приписывают.

Итак, против кого работают “спрятанные дыры”? Оказывается, что только против добропорядочных веб-мастеров и админов, которые хотели бы поверхностно взглянуть, что же там внутри CMS, которую планируют поставить на свой любимый сервер. Хотя бы с целью оценить стиль, прикинуть возможности “адаптации”, а вовсе и не для поиска дыр. Для них создаются дополнительные трудности, вполне ощутимые.

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

Так вот. Требуйте открытых исходников CMS – проще будет эксплуатировать ПО.

Кстати, особенностей CMS касается вот какой момент. CMS, в подавляющем большинстве случаев, служат для управления веб-сайтом, который предназначен для публикации (то есть распространения) данных через Интернет – всё это очевидно. Так что “дыра”, уязвимость в CMS годится не только для того, чтобы просто “взломать сайт”. Как показывает практика, нынче уязвимость CMS оказывается более востребованной в качестве инструмента рассаживания червей и вирусов с добропорядочного сайта.

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

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

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

А при этом механизмы автоматического обновления всё популярнее у создателей CMS. Есть “самообновляющиеся” коммерческие CMS. Для планирования рисков, связанных с корпоративным сайтом, хорошо бы знать, откуда и как получают свои обновления эти системы? Насколько надёжен канал? Когда его захватят злоумышленники, чтобы успешно рассадить трояны по многим сайтам? Всё это хитрые вопросы. Ответы на которые ещё сложнее отыскать, если используется CMS с “закрытым кодом”, работающая неясным способом и “обложенная” изнутри какими-то якобы “защитными модулями”.