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

Вот пишут, что штатовский сайт Касперских сломали, утащив базу пользователей вместе с активационными ключами. Пока не ясно, насколько это соответствует реальности. Но если у Касперских на сайте ПО действительно допускает 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 с “закрытым кодом”, работающая неясным способом и “обложенная” изнутри какими-то якобы “защитными модулями”.

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

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

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

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

Интересно, что вот введут DNSSEC для доменов, появится возможность удостоверять ответы DNS. И на каком-то этапе нерадивая компания из сферы “безопасности” напутает с ключами – а уже даже самые “параноидальные админы” DNSу верят на слово. Вот будет неприятность, почище, чем с BGP.

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

В блоге от Symantec пишут, что новый червь Downadup для обновления своего кода помимо известного канала с DNS (через доменные имена) использует механизм типа P2P.

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

Что там авторы нового мощного ботнета подготовили, какую “деструктивную нагрузку” – пока не ясно.

Между прочим, нашумевший недавно случай с сетью “В контакте”, легко и намеренно положившей “DDoS-атакой” неграмотно настроенный сервер “Премии Рунета”, свидетельствует о том, что популярные “социальные сети” могут быть использованы в качестве “легальных” ботнетов, очень мощных.

Как было дело с “Премией Рунета”? Администрация “В контакте” разместила на веб-страницах своего сервиса небольшой фрагмент кода, который загружал изображения с сервера “Премии”. Таким образом, пользователи социальной сети, путешествуя по каким-то там своим делам внутри “В Контакте”, попутно нагружали своими браузерами сервер “Премии”.

Как можно развивать направление? Понятно как. Браузерные технологии, позволяющие использовать вычислительные ресурсы машины пользователя, развиваются. Одно дело – Javascript, который, впрочем, тоже позволяет, например, перебирать хеши паролей на стороне клиента. Совсем другое дело – такие средства, как Flash, позволяющий использовать C/С++ для создания “сценариев”, и новинка от Microsoft – Silverlight, где разработчиков, понятно, тоже не обидят возможностями. И Flash, и Silverlight стремятся работать у клиента быстрее, по понятным причинам. Можно многое посчитать, многое сделать. Вот вам и фундамент для “ботов” на базе компьютеров пользователей социальных сетей типа “Одноклассников”. Особых проблем с процессорным временем и локальными брандмауэрами – не будет, так как массовый пользователь охотно “зависает” внутри сервиса соц. сети надолго.

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

Возьмём для примера новостную обменную сеть “Новотеки” – http://nnn.novoteka.ru. Здесь есть услужливый интерфейс в click.cgi, полностью открытый. При передаче скрипту на сервере “Новотеки” специально подготовленного URI, этот скрипт отправит браузер клиента по заданному произвольному адресу. При этом пользователь будет видеть в адресе ссылки URL “Новотеки”. Выглядит это, скажем, так:

http://nnn.novoteka.ru/click.cgi?url=%68%74%74%70%3A%2F%2F%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D

По такой ссылке “Новотека” отправляет пользователя на www.google.ru. Понятно, что можно сделать так: http://nnn.novoteka.ru/click.cgi?url=http%3A%2F%2Fwww.google.ru. В первом случае скрипт просто услужливо разбирает закодированную строку. (Для запутывания пользователя можно приписать ещё какие-нибудь параметры к строке.)

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

Ботнеты активно используют DNS. В том числе для такой жизненно важной своей функции, как обеспечение связи с центрами управления. Вот в статье по ссылке разобран механизм генерации доменных имён червями ботнета Srizbi. (Текст по ссылке техничный, будет интересен только специалистам.)

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

Вообще, тут интересно отметить несколько моментов, которые, несомненно, определят развитие ботнетов уже в ближайшем, 2009, году.

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

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

Как это происходит? Регистрируется некоторый набор доменов второго уровня, возможно, с приватной или, скорее, с вымышленой персональной информацией об администраторе (доступно в самых разных зонах, в том числе в .com, и даже в .ru). Далее в этих доменах создаются зоны на несколько уровней ниже (третий, четвёртый, пятый и т.д.). Имена, понятно, регистрируются в соответствии с алгоритмами, заложенными в ботнет. Получается набор абракадабр, что-то типа f148.hsjo71gh.w2-8xnb.qf297dhna.com. При этом серверы имён, связанные тут с доменами уровнем ниже второго, постоянно изменяют информацию об адресах. То есть запросы по именам доменов ведут на самые разные машины в разные моменты времени (понятно, с учётом особенностей DNS).

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

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

Концы хорошо спрятаны.

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

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

Вот.

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

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

Как так? Очень просто: именно компьютер подключен к Сети, поэтому центр сбора и обработки результатов получает “сигнал” именно от компьютера. Что там за человеческий гражданин находился в момент голосования за компьютером, и находился ли он там вообще – об этом ничего не известно.

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

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

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

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

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

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

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