Рука наперсточника

Изучая возможности манипуляции с итогами голосования нашла это. ......

"Какие уязвимости в программном коде КОИБов видны вам как программисту?

Есть ли возможности для манипуляций и фальсификаций результатов голосования?

-Я не стану утверждать, что описанная ниже уязвимость — это намеренно оставленный бэкдор, лазейка для посвященных. Вполне возможно, что это просто промах разработчиков. Но учитывая, что код КОИБов проходил аудит на соответствие требованиям безопасности, это уже двойной промах — и разработчиков, и аудиторов. Что наводит на мысли о том, что все так и было задумано. Если говорить техническим языком, то найденная уязвимость относится к классу code injection. Она позволяет в момент формирования итогового протокола при помощи специальным образом подготовленных для КОИБ исходных данных выполнить на компьютере, встроенном в КОИБ, произвольный код. В том числе и такой, который изменит количество голосов, отданных за кандидатов. Утром в день голосования председатель УИК вставляет в КОИБ «ключевой носитель», представляющий собой обычную флешку, которую заранее выдают в вышестоящей комиссии. На этой флешке сохраняется XML-файл с полной информацией о выборах: когда начинается и заканчивается голосование, какой есть список кандидатов, какого формата бюллетени и много других данных. Примеры записей взяты из технического задания, которое было размещено на госзакупках: Однако кроме вышеперечисленных (очевидных) параметров в том же файле сохраняется информация о правилах заполнения протокола: сколько в нем строк, какой текст должен быть написан в этих строках, по каким формулам вычисляются числовые значения и так далее.

Взглянем на пример исходных данных, по которым КОИБ формирует строки протокола: Код, который выполняет замену строк типа{BlankType=NoMarks,VotingMode=Portable} на соответствующий им программный код, находится в файле Common/Voting/Line.cs. Затем после подстановки значений код передается в компилятор C# (Common/Voting/SourceData.cs строка 434), где он будет скомпилирован и отложен до окончания голосования. Когда голосование заканчивается и формируется протокол, строка за строкой скомпилированная программа выполняется (Common/Voting/Line.cs, строка 262). Здесь-то и оказалась запрятана уязвимость. В формулу можно подставить вызов любой функции, в том числе которая будет менять итоги выборов:

Managers.VotingResultManager.VotingResults.SetNewVotesValue(111, 100500)

Например, таким образом можно проставить кандидату #111 (из примера выше) 100 500 голосов. Кому-то добавить, кому-то отнять. Причем логику прописать любой сложности, которая будет проверять текущий процент за каждого из кандидатов, принимать решение, сколько голосов перекинуть и так далее.

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

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

-Де-факто выходит, что, не нарушая целостности пломб на КОИБе, можно повлиять на результат голосования. Как непосредственно это можно сделать?

-В программном коде КОИБа есть описанная выше логика, позволяющая исполнять программный код с флешки. Само по себе это очень серьезная дыра в безопасности. Однако для того чтобы воспользоваться таким способом фальсификации, нужно, чтобы подмененные данные каким-либо образом попали в КОИБ. Согласно инструкции по эксплуатации КОИБ, с утра в день голосования оператор должен включить КОИБ и загрузить в него исходные данные: «После запроса «Вставьте Flash» вставить ключевой носитель в главное сканирующее устройство (сканирующее устройство, к которому подключен принтер) и нажать клавишу «ДА» на задней панели сканирующего устройства. После этого на информационном табло главного сканирующего устройства появится сообщение «Загрузка исходных данных...».

Ключевой носитель (флешка) выдается председателю УИК накануне выборов в вышестоящей ТИК, чтобы можно было провести тестовое включение КОИБ, убедиться в его работоспособности. Ответственность за сохранность ключа с этого момента лежит на председателе УИК. Но самое интересное, что закон даже не требует от него хранить ключ-флешку в сейфе! Председатель может взять ключ домой и внести в него нужные изменения. Хотя я не исключаю, что для сохранения данных «от председателей» используются и дополнительные уровни защиты, которые сделают такую «лобовую» атаку невозможной. Например, флешка, на которой хранятся данные, вполне может содержать в себе криптоконтейнер, например, выпускаемый какой-либо отечественной компанией, который не позволит посторонним лицам (председателю УИК) подменить данные. Однако никакого контроля со стороны наблюдателей за тем, кто имеет право шифровать и подписывать исходные данные для флешек, законодательно не установлено. Это значит, что лица, которые имеют доступ к криптографическим ключам, все равно могут изменить данные так, как им заблагорассудится. Какая бы совершенная криптосистема ни использовалась, все равно ее стойкость ограничена уровнем доверия к тем, кто формирует исходные данные. Пусть их готовит хоть сама ЦИК. Кто может гарантировать, что вводимые ею исходные данные кристально честные? ....