RTFM.WIKI

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== Skype - скрытая угроза ======

Автор: (c) [[kk@sendmail.ru|Крис Касперски ака мыщъх]]

//Skype представляет собой одну из самых популярных VoIP-программ, установленную на миллионах компьютерах по всему миру, владельцы которых даже и не подозревают, какая опасность им грозит, а опасность им грозит весьма серьезная - от утечки конфиденциальной информации до проникновения червей и "попадания" на трафик, не говоря уже о таких мелочах как нежелание Skype работать при активном Soft-Ice. Но мыщъх все это благополучно разгрыз и теперь предлагает продукты своей жизнедеятельности на всеобщее обозрение.//

===== Введение =====

Созданный отцами-основателями скандально известной **Kazaa**, Skype работает по принципу самоорганизующийся распределенной пиринговой сети (distributed self-organized peer-to-peer network, P2P), унаследовавшей от своей "родительницы" самые худшие ее черты.

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

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

Skype активно изучается в хакерских лабораториях и security-организациях по всему миру и большинство исследователей единодушно сходятся в том, что Skype - это дьявольски хитрая программа, написанная, бесспорно талантливыми людьми в стиле Black Magic Art, т.е. не брезгующая грязными трюками, создающими огромные проблемы, о которых мыщъх и собирается рассказать.

===== Где брать Skype =====

Последнюю версию Skype всегда можно скачать с официального сайта: http://www.skype.com. Она бесплатна, но исходных текстов нет и никогда не будет. Судя по всему, компания прячет в недрах кода что-то очень серьезное. Может быть, это back-door? Как знать...

Тем временем, на волне взрывной популярности Skype-сеть стремительно увеличивается в размерах и Skype-клиенты выпущены практически под все операционные системы какие только есть: Windows, Linux, Mac OS X и различные мобильные платформы.

===== Возможности, предоставляемые Skype =====

Skype предоставляет внушительный ассортимент возможностей, часть из которых бесплатна, а за часть приходится платить по прайсу, но цены все равно в разы ниже, чем при использовании обычной телефонии, впрочем, и качество (соответственно) тоже:
  * Бесплатные возможности:
  - Видеочат и конференции;
  - Прием и отправка файлов;
  - Мгновенный обмен сообщениями;
  - Голосовые звонки на Skype-клиенты;
  - Перенаправление звонов другим Skype-клиентам;
  * Платные услуги:
  - Отправка SMS;
  - Голосовой e-mail;
  - Прием входящих звонков с обычных телефонов;
  - Совершение исходящих звонов на обычные телефоны;

===== Анализ исполняемого файла =====

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

Двоичный файл полностью зашифрован и динамически расшифровывается по мере загрузки в память (см. рис. 1), причем сброс дампа невозможен, точнее - затруднен тем обстоятельством, что стартовый код после выполнения очищается, в результате чего мы получаем неработоспособный exe, который не запускается (однако все же остается пригодным для анализа в IDA Pro с ручной загрузкой FLIRT-сигнатур).

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

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

А вот про отладчик следует сказать особо. Skype распознает Soft-Ice (даже при наличии установленного IceExt), наотрез отказываясь запускаться, что раздражает не только хакеров, но и честных программистов, многие из которых постоянно держат Soft-Ice загруженным для решения совсем далеких от взлома задач. К счастью, уже появились патчи, отламывающие у Skype проверку на Soft-Ice (см. "Как заставить Skype работать под Soft-Ice").

Забавно, но для взлома самого Skype отладчик Soft-Ice не очень-то и нужен, поскольку существуют и другие инструменты подобного рода, среди которых в первую очередь хотелось бы отметить **"The Rasta Ring 0 Debugger"** или, сокращенно, **[RR0D]**, не обнаруживаемый Skype-клиентом и, как и следует из его названия, работающий на уровне ядра. В принципе, можно воспользоваться и отладчиком прикладного уровня (например, стремительно набирающим популярность OllyDbg), только при этом главное помнить, что Skype легко обнаруживает программные точки останова, представляющие собой однобайтовую машинную инструкцию с опкодом CCh, записываю поверх отлаживаемого кода. А для предотвращения пошаговой трассировки, Skype осуществляет замеры времени выполнения определенных участков кода, для прохождения через которые приходится использовать полноценные эмуляторы PC с интегрированным отладчиком, например, знаменитый BOCHS (отладчик не входит в дистрибутив бинарной сборки и чтобы его установить, программу приходится собирать вручную из исходных текстов).

Попадаются и другие антиотладочные трюки, но они не так интересны: Skype очень активно использует прием передачи управления через структурные исключения. Защита устанавливает SEH-обработчик, делает что-то непозволительное (деление на ноль или обращение по несуществующему адресу), вынуждая систему передать управление SEH-обработчику, который модифицирует регистры/память и продолжает выполнение с прерванной точки или передает его куда-то еще. Такая техника чудовищно осложняет статический анализ (т.е. дизассемблирование), но для современных отладчиков практически "безвредна".

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

{{ :security:skype_hidden_threat_1.jpg |}}
<WRAP centeralign>
Рисунок 1. Последовательность распаковки исполняемого файла.
</WRAP>

===== Как заставить Skype работать под Soft-Ice =====

Смириться с тем, что Skype-клиент не работает под Soft-Ice, программисты, естественно, не могли и потому начали его ломать, хотя... исправление заведомых дефектов трудно назвать взломом. Как бы там ни было, проверка на присутствие Soft-Ice, выполненная в классическом миссионерском стиле - по наличию устройств \\.\Siwvid, ntice.sys, iceext.sys (см. рис. 2) - обнаруживается элементарной трассировкой в любом другом отладчике, например, в OllyDbg (см. рис. 3).

{{ :security:skype_hidden_threat_2.jpg |}}

<WRAP centeralign>
Рисунок 2. Анти-отладочные приемы, с помощью которых Skype обнаруживает загруженный Soft-Ice.
</WRAP>

Проблема в том, что Skype следит за своей целостью как непорочная дева Мария, забеременевшая от Святого Духа, явившегося в форме Голубя, и попытка исправления jnz на jmp short работает только до первого входящего звонка, после которого Skype падает и обратно уже не поднимается. Специально для таких хитроумных защит еще во времена MS-DOS была разработана техника on-line patch'а, при которой "исправление" программы осуществляется непосредственно в оперативной памяти, а после "успешного" прохождения проверки на наличие Soft-Ice, совершается "откат", чтобы не волновать процедуру проверки целостности.

Один из таких патчей, созданных французским хакером по имени Gery Casiez, выложен в открытый доступ на его собственном сервере: http://gcasiez.perso.orange.fr/skypeloader.c (исходные тексты) и http://gcasiez.perso.orange.fr/skypeloader.zip (откомпилированный файл).

{{ :security:skype_hidden_threat_3.jpg |}}

<WRAP centeralign>
Рисунок 3. Беглая трассировка Skype с помощью OllyDbg быстро выявляет защитный код, выполняющий проверку на присутствие Soft-Ice.
</WRAP>

===== Архитектура распределенной сети =====

На атомарном уровне структура skype-сети состоит из **//обычных узлов//** (normal/ordinal node/host/nest), обычно обозначаемых аббревиатурой SC, расшифровываемой как Skype Client, и **//super-узлов//** (super node/host/nest), которым соответствует аббревиатура SN. Любой узел, имеющий публичный IP-адрес (т.е. тот, который маршрутизируется в Интернет) и обладающий достаточно широким каналом, **//автоматически//** становится super-узлом и гонит через себя трафик обычных узлов, помогая им преодолеть защиты типа брандмауэров или трансляторов сетевых адресов (NAT) и равномерно распределяя нагрузку между хостами. В этом и состоит сущность самоорганизующейся распределенной децентрализованной пиринговой сети, единственным централизованным элементом которой является **//Skype-login сервер//**, отвечающий за процедуру авторизации Skype-клиентов и гарантирующий уникальность "позывных" для всей распределенной сети (см. рис. 4).

Важно подчеркнуть, что связь между узлами осуществляется не напрямую, а через цепочку super-узлов. "Серверов" в общепринятом смысле этого слова (таких, например, как в сети eDonkey) в Skype-сети нет и любой узел с установленным Skype-клиентом является потенциальным сервером, которым он автоматически становится при наличии достаточных системных ресурсов (объема оперативной памяти, быстродействия процессора и пропускной способности сетевого канала, не защищенного никакими средствами защиты).

Каждый узел Skype-сети хранит перечень IP-адресов и портов известным ему super-узлов в динамически обновляемых **//кэш-таблицах//** (Host Cache Tables, HC-tables). Начиная с версии Skype 1.0, кэш-таблицы представляют собой простой XML-файл, в незашифрованном виде записанный на диске в домашней директории пользователя.

{{ :security:skype_hidden_threat_4.jpg |}}

<WRAP centeralign>
Рисунок 4. Структура децентрализованной самоорганизующийся пиринговой Skype-сети.
</WRAP>

Помимо вышеперечисленных элементов, в Skype-сети присутствуют и другие централизованные узлы, в частности **//PC2PSTN//** и **//PSTN2PC//**-сервера, воздвигающие мосты между Skype-сетью и обычной телефонией. Аббревиатура PSTN расшифровывается как Public Switched Telephone Network (Телефонная Сеть Общего Пользования) и в общем случае представляет собой набор АТС и прочего коммуникационного оборудования.

Skype-клиенты за отдельную плату (см. рис. 5) могут принимать входящие звонки с обычных телефонов (технология SkypeIn, описанная на http://www.skype.com/products/skypein/) и совершать звонки самостоятельно (технология SkypeIn, описанная на http://www.skype.com/products/skypein), однако в PC2PC-обмене эти сервера никак не участвуют, поэтому мы не будем на них останавливаться.

{{ :security:skype_hidden_threat_5.jpg |}}

<WRAP centeralign>
Рисунок 5. Помимо звонков внутри Skype-сети пользователи могут принимать/совершать звонки и на обычные телефоны.
</WRAP>

====== Как skype обходит брандмауэры ======

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

Сразу же после своего запуска Skype-клиент открывает TCP и UDP порты, номера которых случайным образом задаются при инсталляции и могут быть в любой момент изменены через диалог конфигурации, что затрудняет блокирование Skype-трафика на брандмауэре. Помимо этого, Skype открывает 80 (HTTP) и 443 (HTTP-over-TLS) порты, однако они не являются жизненно важными и, даже если их заблокировать, Skype ничуть не огорчится.

{{ :security:skype_hidden_threat_6.jpg |}}

<WRAP centeralign>
Рисунок 6. Структура IP-пакета при работе skype по протоколу UDP.
</WRAP>

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

{{ :security:skype_hidden_threat_7.jpg |}}

<WRAP centeralign>
Рисунок 7. Механизм шифрования, используемый Skype.
</WRAP>

Skype-клиенты крайне деликатно обходятся с брандмауэрами и трансляторами сетевых адресов (т.е. NAT'ами), "просачиваясь" сквозь них через хорошо известные протоколы **STUN** и **TURN** (см. рис. 8). Протокол STUN уже вошел в Библию Интернета и подробно описан в RFC-3489 (http://www.rfc-archive.org/getrfc.php?rfc=3489). Что же касается TURN'а, то он все еще находится в разработке и в настоящее время доступна лишь черновая версия стандарта: http://www.jdrosen.net/midcom_turn.html.

Так что, с юридической точки зрения действия Skype весьма "политкорректны" и не попадают под статью. STUN расшифровывается как: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) - Простое Проникновение Дейтограмм Протокола UDP через Транслятор Сетевых Адресов (NAT) и представляет собой отличное средство, однако страдающее рядом досадных (для Skype!) ограничений и не работающее в следующих случаях:
    * Путь во внешнюю сеть прегражден злобным брандмауэром, режущим весь UDP;
    * На пути во внешнюю сеть стоит симметричный транслятор сетевых адресов;

Ну, с брандмауэром все понятно. Если UDP закрыт, то никаким хвостом его не откроешь. А вот симметричный транслятор сетевых адресов (symmetric NAT) - это что за штука? Не углубляясь в технические детали, симметричный NAT представляет собой разновидность обыкновенного транслятора, требующего, чтобы целевой IP-адрес и порт транслируемого пакета совпадали с внешним (external) IP-адресом и портом. Если один и тот же узел посылает пакеты с одинаковыми исходными IP-адресами и портами по разным направлениям, NAT будет вынужден транслировать их на другие порты. Таким образом, чтобы отправить внутреннему узлу UDP-пакет, внешний узел должен первым делом получить "запрос" от внутреннего узла. Самостоятельно инициировать соединение внешний узел не в состоянии, поскольку NAT просто не знает, на какой внутренний IP и порт следует транслировать неожиданно сваливавшийся UDP-пакет.

Эта проблема решается протоколом TURN (Traversal Using Relay NAT - Проникновение Использующее Транспортный NAT), технические подробности работы которого описаны в вышеупомянутой ссылке и большинству читателей совершенно неинтересны. Гораздо важнее другое - протокол TURN значительно увеличивает латентность (промежуток времени между посылкой запроса и получением ответа) и теряет большое количество UDP пакетов (packet loss), что далеко не лучшим образом сказывается на качестве и устойчивости связи, но полное отсутствие связи еще хуже! Так что пользователям Skype стоит радоваться, а не жаловаться!

{{ :security:skype_hidden_threat_8.jpg |}}

<WRAP centeralign>
Рисунок 8. Структура Skype-сети, в которой присутствуют Skype-клиенты за NAT'ми и брандмауэрами.
</WRAP>

Вот только администраторы этой радости почему-то не разделяют, наглухо закрывая UDP-трафик (тем более, что большинству нормальных программ он не нужен). Немного поворчав для приличия (замуровали, демоны!!!), Skype автоматически переключается на чистый TCP, отрубить который администратору никто не позволит, правда, немного поколдовав над брандмауэром, он может закрыть все неиспользуемые порты, но... в том-то и подвох, что "неиспользуемых" портов в живой природе просто не встречается! При соединении с удаленным узлом, операционная система назначает клиенту любой свободный TCP/UDP-порт, на который будут приходить пакеты. То есть, если мы подключаемся к Web-серверу по 80 порту, наш локальный порт может оказаться равным 1369 или 6927 или еще каким-нибудь другим. Закрыв все порты, мы лишимся возможности устанавливать TCP/UDP-соединения!

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

{{ :security:skype_hidden_threat_9.jpg |}}

<WRAP centeralign>
Рисунок 9. Skype, работающий через Proxy-сервер, конфигурация которого прочитана из настроек браузера.
</WRAP>

===== Как заблокировать skype-трафик =====

Разработчики Skype предостерегают администраторов от попыток выявления и блокирования его трафика (типа, "все равно у вас ничего не получится") и - действительно, распознать Skype-трафик очень сложно, а заблокировать его можно только по содержимому, которое зашифровано (в большинстве случаев 256-битным алгоритмом AES) и не содержит (по замыслу разработчиков!) никаких предсказуемых последовательностей. К счастью для администраторов, создатели Skype, при всей своей гениальности, допустили ряд оплошностей, оставив часть трафика **//незашифрованной//**!

UDP-соединение использует открытый протокол для получения публичных IP-адресов super-узлов, что вполне может быть выявлено анализатором трафика. Это - раз. TCP-соединение использует один и тот же RC4 поток **//дважды//**, что позволяет нам восстановить 10 первых байт ключа, расшифровав часть постоянных полей заголовков Skype-протокола (см. рис. 10). Это - два! Кстати, весьма полезная вещь для шпионажа за чужими разговорами! Тем не менее, мыщъху не известен ни один готовый "блокиратор" Skype-трафика, а писать свой собственный - лениво, да и времени нет.

{{ :security:skype_hidden_threat_10.jpg |}}

<WRAP centeralign>
Рисунок 10. Повторное использование RC4-потока позволяет восстановить 10 байт ключа из 12, расшифровывая часть Skype-трафика.
</WRAP>

Распознать и заблокировать UDP-трафик намного проще: каждый фрейм начинается с двухбайтового идентификационного номера (ID) и типа пакета (payload). В UDP пакет вложен 39-байтный NAck-пакет, пропущенный через "обфускатор" и содержащий следующие данные (см. рис. 11):
    * Идентификатор пакета (непостоянен и варьируется от одного пакета к другому);
    * Номер функции (func), пропущенный через обфускатор, но func & 8Fh всегда равно 7h;
    * IP-отправителя;
    * IP-получателя;

Таким образом, чтобы заблокировать UDP-трафик, генерируемый Skype, достаточно добавить в брандмауэр следующее правило:

<code>iptables -I FORWARD -p udp -m length --length 39 -m u32
--u32 '27&0 x8f=7' --u32 '31=0 x527c4833 ' -j DROP
</code>

Листинг 1. Правило для iptables, блокирующее UDP-трафик Skype-клиентов.

{{ :security:skype_hidden_threat_11.jpg |}}

<WRAP centeralign>
Рисунок 11. Структура NAck-пакета.
</WRAP>

К сожалению, блокировка UDP трафика ничего не решает, поскольку Skype автоматом переходит на TCP, но(!) тут есть одна небольшая зацепка. Заголовки входящих IP-пакетов, относящиеся к протоколу обмена SSL-ключами (SSL key-exchange packets) содержат нехарактерный для "нормальных" приложений идентификатор **170301h** (см. рис. 12), возвращаемый в ответ на запрос с идентификатором 160301h (стандартный SSL версии 3.1).

Таким образом, блокирование всех входящих пакетов, содержащих в заголовке 170301h серьезно озадачит Skype и текущие версии потеряют работоспособность. Вот только надолго ли...

{{ :security:skype_hidden_threat_12.jpg |}}

<WRAP centeralign>
Рисунок 12. Распознание Skype-трафика по необычному идентификатору во время обращения к Login Server'у при обмене SSL-ключами.
</WRAP>

Для детектирования и блокирования Skype-трафика можно использовать и другие программно-аппаратные средства, как, например, **PRX** от Ipoque или **Cisco Network-Based Application Recognition** (NBAR), однако все они недостаточно эффективны, особенно в свете того, что разработчики Skype не сидят сложа руки и если кому-то удастся найти надежный способ блокировки его поганого трафика, в следующих версиях поганец появится вновь.

===== Армии дронов или как зомбировать Skype =====

Дешевизна голосовых звонков (между PC2PC-клиентами, определяемая только стоимостью трафика) вызвала взрывной рост популярности Skype, сеть которого на 27 апреля 2006 года по официальным данным составила свыше 100 миллионов зарегистрированных пользователей, а сегодня свыше 700 тысяч людей совершают, по меньшей мере, одни Skype-звонок в день! Несложно спрогнозировать, что в скором будущем в Skype войдет львиная доля узлов Интернета, что несет в себе не только преимущества, но и проблемы.

Хакеры уже давно догадались использовать Skype для распространения вирусов и организации распределенных атак, которым очень сложно воспрепятствовать: Skype-трафик надежно зашифрован и не может быть проанализирован антивирусами, заблокирован брандмауэрами или распознан системами обнаружения вторжения (напомним, что Skype очень деликатно определяет тип брандмауэра или NAT, за которым он находится).

Естественно, чтобы захватить Skype-узел, хакер должен найти способ передать на него зловредный код, что при соблюдении всех мер безопасности он ни за что не сможет сделать, но... как и всякое другое программное обеспечение, Skype подвержен ошибкам, в том числе и ошибкам переполнения, одна из которых была обнаружена 25 сентября 2005 года. Сейчас она уже давно исправлена и представляет лишь исторический интерес, но, тем не менее, с ней все-таки стоит познакомиться поподробнее (а подробности можно найти здесь: skype.com/security/skype-sb-2005-03.html или здесь: seclists.org/fulldisclosure/2005/Oct/0533.html).

Возможность передачи управления на shell-код позволяла атакующему "овладевать" любым Skype-узлом, а также всеми известными ему super-узлами и т.д... Над распределенной сетью нависла глобальная угроза, и просто чудо, что она не закончилась катастрофой, однако, как показывает практика, там, где есть одна ошибка, рано или поздно появляются и другие. Закрытость исходных текстов и множество антиотладочных приемов (затрудняющих тестирование программы) этому только способствуют!

<code>// read a VLD from input stream
// return 0 on error
int get_vld(unsigned int *);

unsigned int object_counter;
unsigned int i;
unsigned int *tab_objects;

// read object count (M)
if (get_vld(&object_counter) == 0)
        fault();

// allocate memory to store sub-objects
tab_objects = HeapAlloc(sizeof(unsigned int) *object_counter);
if (tab_objects == NULL)
        fault();

// read and store M sub-objects
for (i = 0; i < object_counter; i++)
{
        if (get_vld(&tab_objects[i]) == 0)
                fault();
} </code>

Листинг 2. Реконструированный фрагмент Skype (переведенный из ассемблера на Си), содержащий ошибку переполнения.

Другая опасная "вкусность" Skype заключается в открытости его API. Пойдя на встречу сторонним разработчикам, создатели Skype предусмотрели возможность интеграции любой прикладной программы со Skype-клиентом. Правда, при этом на экран выводится грозное предупреждение, что такая-то программа хочет пользоваться Skype API: разрешить или послать ее нафиг? Естественно, большинство пользователей на подобные вопросы отвечают утвердительно. Уже привычные к надоедливым предупреждениям, они инстинктивно давят "yes" и только потом начинают думать, а что же они, собственно, разрешили?

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

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

{{ :security:skype_hidden_threat_13.jpg |}}

<WRAP centeralign>
Рисунок 13. Географическое распределение super-skype-узлов по планете.
</WRAP>

===== Заключение =====

Перед тем как закончить эту статью, мыщъх хотел бы спросить: что же все-таки скрывают (или пытаются скрыть) создатели Skype в недрах своего кода? Почему, распространяя программу бесплатно, они зажимают исходные тексты и используют закрытый протокол, вызывая тем самым недоверие специалистов по безопасности? Для чего бесплатной программе столь навороченная защита, снижающая производительность и потребляющая большое количество памяти, ведь ломать ее никто не собирается? Почему вообще Skype-клиент реализован как Черный Ящик?!

Вопрос остается риторическим, то есть безответным. Но чует мой хвост, ох и неспроста все это!

===== Ссылки по теме =====

    * General Skype Analysis:
      Мини-портал с кучей ссылок на статьи и прочие ресурсы, посвященные анализу Skype и методам борьбы с ним (на английском языке): http://www1.cs.columbia.edu/~salman/skype/;
    * Silver Needle in the Skype:
      Подробный отчет об исследовании Skype, выполненный двумя французскими хакерами Philippe Biondi и Fabrice Desclaux из корпорации EADS Corporate Research Center - DCR/STI/C IT sec Lab Suresnes, FRANCE и зачитанный ими на европейской конференции BlackHat в марте 2006 года (на английском языке): http://www.secdev.org/conf/skype_BHEU06.pdf;

    * Skype Trojan:
      Тезисная презентация Walter Sprenger, показывающая как можно использовать Skype-сеть для распространения червей и прочей заразы (на английском языке): http://www.csnc.ch/static/download/misc/2006_skype_trojaner_v1.1.pdf;
    * How to use Skype with Softice?
      Любопытная статья, рассказывающая почему Skype-клиент не работает при установленном Soft-Ice и как это побороть (на английском языке): http://gcasiez.perso.orange.fr/skypeandsoftice.html;
    * Skype Reads Your BIOS and Motherboard Serial Number:
      Заметка на блоге, разоблачающая махинации, скрытно проделываемые Skype, читающего BIOS и серийный номер материнской платы (на английском языке): http://www.pagetable.com/?p=27;
    * Why Does Skype Read the BIOS?
      Развернутая дискуссия на тему, зачем Skype-клиент читает BIOS и какую информацию ему удается извлечь (на английском языке): http://it.slashdot.org/it/07/02/07/0146245.shtml;