Olá, Eu sei que, nesse momento, todo mundo está preocupado com a eleição Dilma/Serra, mas a AMB acaba de divulgar uma nota sobre sua eleição interna que não posso deixar de comentar.
A comissão eleitoral da Associação dos Magistrados Brasileiros, AMB, voltou atrás e decidiu que fará mesmo pela Internet a eleição interna à presidência. Entre essa decisão e a eleição.... menos de um mês. Votarão mais de 14 mil associados pela Internet durante 3 dias, iniciando-se no dia 23/11. Em notas de 26/10 e 27/10 disponíveis em: http://amb.com.br/index.asp?secao=mostranoticia&mat_id=21581 http://amb.com.br/?secao=mostranoticia&mat_id=21596 é dito que será usado um sistema de votação pela Internet desenvolvido e gerenciado pelo TRE-DF e que: “Os técnicos do tribunal provaram que a eleição pela internet é segura” É aí que a coisa pega. Provaram como? Onde está descrita e apresentada essa prova? Quais foram os testes feitos? Que normas técnicas sobre sistemas eleitorais eles atendem? Eu duvido que essa tal prova exista de fato. Duvido que venha a ser apresentada ao público para escrutínio e avaliação se é prova mesmo ou só balela mercadológica. E quem provou que os desenvolvedores e gerenciadores do TRE-DF são absolutamente "seguros"? O TRE-DF tem competência técnica para desenvolver software complexo? Que outros sistemas de alta complexidade eles desenvolveram antes? (até onde eu sei: nenhum) E eles tem competência jurídica para oferecer esse tipo de serviço (desenvolvimento e gerenciamento de software) à sociedade privada? Pode um tribunal do governo "vender" direito de uso de software? E ceder gratuitamente? Recentemente, no Distrito de Colúmbia (EUA), se desenvolveu um sistema de votação pela Internet bastante similar ao que o TRE-DF alega ter desenvolvido. Ambos incluem o envio de senhas pelo correio e opção de voto pela Internet ou voto pelo correio. Antes de ser aprovado e dentro de um planejamento sensato, o sistema de Colúmbia foi submetido a um teste público de segurança durante 3 dias apenas e uma equipe da Universidade de Michigam, liderada pelo prof. Alex Haderman, demonstrou que era totalmente vulnerável a desvio e identificação do voto. Uma descrição sucinta desse caso está descrita abaixo (em inglês). obs.: a equipe do prof. Haderman já teve sucesso em muitos outros testes de segurança contra sistemas eleitorais digitais. Aí vem os "geniais" funcionários do TRE-DF e "provam", a portas fechadas claro, que desenvolveram um sistema de votação pela Internet 100% seguro!!!!!!!!!! Obviamente, ninguém pode ver qual é essa prova nem pode testar o sistema de forma livre. ... e tem magistrado que acredita numa bravata dessa! Planejamento de desenvolvimento e de testes, nenhum.... e a AMB resolve adotar um sistema assim, sem testar e nem avaliar, para votar em menos de um mês! Como se pode qualificar uma decisão dessa: Imaturidade? Incompetência? Ignorância? Burrice? Seita do Santo Baite? Visão estreita? Cabeça pequena? Má fé? Uma vez me disseram que não se deve atribuir à má fé o que pode ser explicado pela incompetência... mas, caramba, são juízes, magistrados... não posso deixar que imaginar que tanta incompetência aparente, junta num lugar só, não seja fruto de ma fé escamoteada. Se os magistrados do brasileiros decidem sua eleição, uma questão administrativa, com argumento de tão baixo nível técnico, o que se pode esperar de suas decisões judiciais. Diante de tamanha pataquada desfechada por excelentíssimos próceres, só tenho mais uma pergunta: Como é que eu vim parar num mundo desse? Eng. Amilcar Brunazo Filho membro do Comitê Multidisciplinar Independente - CMind O TSE pode fazer mais. Além da APURAÇÃO RÁPIDA DOS VOTOS, que já nos oferece, deveria propiciar uma APURAÇÃO CONFERÍVEL PELA SOCIEDADE CIVIL Conheça o Relatório do CMind _____________________________________________________________________________ http://freedom-to-tinker.com/blog/jhalderm/hacking-dc-internet-voting-pilot Home » Blogs » J. Alex Halderman's blog Hacking the D.C. Internet Voting Pilot By J. Alex Halderman - Posted on October 5th, 2010 at 9:07 pm The District of Columbia is conducting a pilot project to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they've invited the public to evaluate the system's security and usability. This is exactly the kind of open, public testing that many of us in the e-voting security community — including me — have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days' notice. I assembled a team from the University of Michigan, including my PhD students, Eric Wustrow and Scott Wolchok, and Dawn Isabel, a member of the University of Michigan technical staff. Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots. In this post, I’ll describe what we did, how we did it, and what it means for Internet voting. D.C.'s pilot system The D.C. system is built around an open source server-side application developed in partnership with the TrustTheVote project. Under the hood, it looks like a typical web application. It's written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database. Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site, http://www.dcboee.us/DVM/, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots. A small vulnerability, big consequences We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database. The problem, which geeks classify as a “shell-injection vulnerability,” has to do with the ballot upload procedure. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG. Internally, the server executes the command gpg with the name of this temporary file as a parameter: gpg […] /tmp/stream,28957,0.pdf. We realized that although the server replaces the filename with an automatically generated name (“stream,28957,0” in this example), it keeps whatever file extension the voter provided. Instead of a file ending in “.pdf,” we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename “ballot.$(sleep 10)pdf” would cause the server to pause for ten seconds (executing the “sleep 10” command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user. Our demonstration attacks D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks: * We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots. * We modified all the ballots that had already been cast to contain write-in votes for candidates we selected. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way. * We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy. * To show that we had control of the server, we left a “calling card” on the system's confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here's a demonstration. Stealthiness wasn't our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes — an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song. Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky. D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8. What this means for Internet voting The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We've found a number of other problems in the system, and everything we've seen suggests that the design is brittle: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I'm confident that we would have found another way to attack the system. None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today's security technology. We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper. — Professor J. Alex Halderman is a computer scientist at the University of Michigan. -- __________________________________________________ O texto acima e' de inteira e exclusiva responsabilidade de seu autor, conforme identificado no campo "remetente", e nao representa necessariamente o ponto de vista do Forum do Voto-E O Forum do Voto-E visa debater a confibilidade dos sistemas eleitorais informatizados, em especial o brasileiro, e dos sistemas de assinatura digital e infraestrutura de chaves publicas. __________________________________________________ Pagina, Jornal e Forum do Voto Eletronico http://www.votoseguro.org __________________________________________________ Você recebeu esta mensagem porque está inscrito no Grupo "VotoEletronico" em Grupos do Google. Para postar neste grupo, envie um e-mail para [email protected] Para cancelar a sua inscrição neste grupo, envie um e-mail para [email protected] Para ver mais opções, visite este grupo em http://groups.google.com/group/votoeletronico?hl=pt-
