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

Разный бывает фишинг: веб-сайты и домены-обманки – лишь одна из его граней. Вот у вас корпоративная сеть с Wi-Fi, значит, могут прийти под окно люди со своей точкой доступа, поименовать её похожим образом (или точно так же), а потом вашу подавить на некоторое время (есть готовое оборудование). Обеспокоенные пользователи тут же станут коннектиться к чужой точке. Фишинг? Фишинг. А отчего-то мало кто задумывается о таком варианте.

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

Популярное англоязычное понятие “security through obscurity” можно выражать на русском разными способами, например “безопасность через неизвестность”, или “безопасность с помощью незаметности”, или ещё как-то, главное, сохранить смысл концепции, в которой для обеспечения безопасности используется сокрытие некоторой информации о мерах защиты.

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

Мы тут обсуждаем смартфоны и сходную продукцию (ключевые слова: Apple, Android), в том смысле, что если сильно беспокоиться о том, что подобные устройства активно шпионят за “носителем” и “сливают информацию в центр”, то совсем нельзя пользоваться современными, удобными технологиями коммуникации. Действительно, удобно – и альтернативы нет. Куда податься? Ответ теоретика такой: в сторону открытых аппаратных платформ (ОС с открытым исходным кодом и так уже есть).

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

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

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

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

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

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

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

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

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

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

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

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

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

А занятнее всего тут то, что такой смартфон ещё и собирает сведения о местоположении других, так сказать, “абонентов поневоле”, которые даже и не догадываются о происходящем, и вообще не подписывались под всеми этими соглашениями. Например, приложение в смартфоне собирает MAC-адреса замеченных в эфире точек доступа Wi-Fi и, привязав их к координатам, полученным от GPS, отправляет “в центр”. История известная.

Так что сведения, доступные оператору связи, не только оказываются менее подробными (учитывайте и точность GPS), но и риски несут совсем другие, если сравнивать с продвинутыми мобильными программными платформами, которые, при этом, никто особенно и не регулирует, не ограничивает.

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

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

Зато в такой схеме пользователь может легко отозвать авторизацию у потерявшей доверие организации, а те, кто не вписан в базу данных, вообще не смогут совершить каких-то транзакций, украв пользовательские данные. Естественно, схема подразумевает наличие на стороне пользователя некоторого неотчуждаемого секрета, которым подписываются (удостоверяются) запросы в трастовый центр (ну или нужно его называть более правильно: удостоверяющий центр). Этот секрет может выдаваться в виде индивидуальной смарт-карты. В мире платёжных систем такое давно пытаются ввести. Но, видимо, выгода пока не перевешивает затраты на ввод в строй и эксплуатацию схемы. Конечно, переложить часть рисков на самого пользователя, это дешевле.

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

Вопрос в том, должны ли быть некие центральные хранилища, соответствующим образом сконструированные?

Часто в разных СМИ и даже в презентациях на популярных конференциях можно услышать про ботнеты, насчитывающие миллионы компьютеров. (Например, на РИФе называли кто 30 млн, кто 50 млн – в общем, получается, кто больше.)

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

Итак, если узлы ботнета-миллионника в течение суток придут равномерным потоком в центр за новыми указаниями, то это будет – около 12 запросов в секунду, минимум. Нужно брать место в дата-центре или арендовать мощности в сервисах типа Amazon EC. А для того, чтобы боты приходили в центр равномерно – должен быть реализован очень хитрый алгоритм распределения нагрузки.

Если узлы ботнета-миллионника обмениваются данными внутри и каждый перешлёт десяти другим один килобайт, то – трафик составит около 10 Гб. То есть, это такиой примерный трафик, который должен пройти по сетям, если ботнет обновляется по правильной технологии разновидности P2P. В зависимости от топологии размещения узлов ботнета и частоты обмена пакетами такой трафик может быть хорошо заметен в статистике интернет-провайдеров. Хотя, конечно, не является заметным в масштабах Интернета. Продолжим про трафик и вычислим 10 гигабайт другим способом: если для заражения одного компьютера требуется разовая пересылка кода червя, а этот код занимает 10 килобайт (сейчас “черви длинные”), то опять будут потрачены те же 10 Гб, состоящие только из данных программного кода. И никто из антивирусных компаний, выходит, не смог ничего выудить?

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

И это только теоретический устойчивый ботнет с числом узлов в миллион. Понятно, что для 30 млн – ситуация принципиально иная: рост сложности управления в подобных случаях не линеен.

Насколько можно преуспеть в реальности, показывает опыт добровольных сетей распределённых вычислений. Даже учитывая полное доверие и желание сотрудничать со стороны участников – сетей-миллионников здесь практически нет, и все те, которые есть, растут из старых, годами хорошо раскручиваемых, проектов, например, SETI@Home. Но в большинстве случаев, хороший результат – сотня тысяч участников.

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

Недавно в прессе широко обсуждались некие “DDoS-атаки”, в результате которых был недоступен сервис LiveJournal.com (то есть, ЖЖ). Правда, про связь атак с недоступностью сервиса как-то очень смутно рассказывали и журналисты, и представители самого ЖЖ. Но речь не об этом. Речь о том, что в СМИ быстро пришли к выводу, что, якобы, DDoS – это такой инструмент для прекращения доступа пользователей к кому-то неугодному сервису. Вывод очень спорный, если только речь не идёт о небольшой домашней страничке. Но интересно поразмыслить над тем, каким методом, и кто может эффективно прекращать доступ к веб-ресурсам.

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

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

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

В результате без всякого DDoS ресурс фактически отключен.

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

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

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

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