domingo, 13 de noviembre de 2016

Voto encadenado

El voto encadenado es un viejo y eficaz método de fraude de baja incidencia. No es que me preocupe mucho, pero se usa como argumento a favor del voto electrónico/boleta electrónica diciendo que estos lo evitan. Como ya he dicho [1], no pienso que los argumentos técnicos sean los más importantes en el método de elección.


Sin embargo, por una perversión que los que ordenan sus libros por colores o formas o no pisan las rayas de las baldosas pueden perfectamente comprender, pudiendo atar este cabo suelto, lo intentaré. Esto va dentro del espíritu que me transmite la frase de Herzog: "conquistador de lo inútil".

Nota desde el futuro: al terminar de escribir todo esto me dí cuenta que hay una solución MUCHO MÁS SENCILLA, así que todo lo que sigue, más que una propuesta es la historia de la evolución de un pensamiento.


Voto encadenado


El ataque consiste en conseguir un sobre firmado. El Atacante le promete a su Mulita una recompensa si introduce en la urna el sobre cerrado que el Atacante le entregue. Luego la Mulita le trae el sobre abierto que recibió y así se encadena con la siguiente Mulita.



Este ataque se basa en un mecanismo de protección existente que sirve para evitar que se introduzcan votos

Mitigación al voto encadenado


El esquema que se me ha ocurrido y no he hallado en Internet tras buscar unos minutos, lo que no quita que:

  • esté reinventando la rueda
  • esté reinventando una rueda pinchada
  • esté inventando una rueda pinchada

consiste en lo siguiente:

El Elector NO recibe el sobre para votar, si no un sobre sin marcas identificatorias. En el cuarto hay más sobres equivalentes. Pone su voto en este sobre, sale y lo cierra en presencia de la Mesa.

El Elector toma uno entre varios sobres firmados que la Mesa le ofrece, introduce allí su sobre anónimo y vota.

La clave de esta mitigación es que el Atacante no recibe prueba del voto, no puede comprobar que ha hecho la Mulita, pues el ataque original se basa en la dificultad de conseguir sobres firmados abiertos por fuera del circuito y los sobres anónimos son tan fácil de obtener como las boletas electorales.

¡Quitemos los sobres firmados! No, por que los sobres firmados mitigan la aparición de votos extra.


Contraataque al voto encadenado


Para realizar este ataque es necesaria una gran confianza entre los participantes y tener a la mayor parte de la mesa asociada. No me parece que sea ilegal, pero igual preferiría no participar, el Atacante podría ofenderse y tomar represalias ilegales.

La Mesa le entrega a cada Mulita dos sobres firmados, uno para que vote lo que quiera (o lo del partido que organiza el contraataque, en este caso sin duda es ilegal) y otro para que le dé al Atacante, cobre su dinero y lo reparta con la banda contraatacante.

Se destruye el sobre fraudulento, nos hacemos unos pesos, no hay fraude, el que roba a ladrón tiene cien años de perdón, decían...


Boleta Única



Este esquema, el de mitigación no el de contraataque,  se podría adaptar a Boleta Única, pero me parece que no vale la pena. En conversación con HacKan Iván él dudó por un momento si BU era susceptible al voto encadenado, pero no lo es, ya que conseguir boletas en blanco debería ser algo permitido, de modo tal que el Atacante no pueda obtener prueba la prueba indirecta del voto.



Solución MUCHO MÁS SENCILLA


El Elector está obligado a ingresar al cuarto oscuro y permanecer más de un tiempo prefijado, como pueden ser 30 segundos. Esto le da tiempo a hacer lo que quiera. El tiempo mínimo es para que el Atacante no le pueda exigir que entre y salga sin oportunidad de cambiar la boleta que le pueda haber dado al Atacante.

El Elector DEBE cerrar el sobre firmado en presencia de la Mesa, mostrándolo de modo tal que se vea que está abierto pero sin exponer su interior, para proteger el secreto del voto en blanco, vacío o el de los que ponen papeles que no son boletas.

El ataque encadenado no es posible, pues el Atacante no tiene garantías de que la Mulita no haya cambiado la boleta.

Si se hallara una boleta pegada a un sobre, el voto debería impugnarse, pues es el mecanismo restante del Atacante para evitar el cambio de boleta.

De todos modos, insisto, quien quiera hacer fraude lo va a lograr por el simple método de cambiar los votos durante el momento del recuento. O amenazar con tomar represalias contra los electores de las mesas donde no gane. O hacer una campaña electoral engañosa. Todo esto es un ejercicio intelectual, divertido y vano.


[1] https://seguridad-agile.blogspot.com/2016/10/voto-electronico-no.html








Ekoparty 2016

Por motivos logísticos tanto laborales como familiares, en esta edición sólo pude asistir al training y casi nada a la conferencia.

El training, ingenieria inversa aplicada al analisis de malware [1][2],
dictado por Luciano Martins y Gabriela Nicolao, me encantó, me hizo sentir que me he equivocado en la vida por el camino que tomé. Recién el sábado recordé los dos hechos que me desviaron de ese camino:

El libro de assembler del 8086 [3] que salia 100. No sé que eran esos 100, pero era mucho. Mi familia me dijo "te lo compramos, pero es muy caro, ¿estás seguro?" y yo, un tanto tímido ante tamaña responsabilidad, juiciosamente dije que no, grave error.

El segundo fué que yo usaba el debug de D.O.S. para escribir programitas muy chiquitos en assembler e intentar comprender lo que hacían los ejecutables ajenos, no sabía nada de disassemblers, compiladores, estructuras internas de ejecutables y no me crucé con nadie que me diera una guía, era un camino muy difícil y desistí.


El curso estuvo muy, muy bueno, muy atrapante, con una única crítica que ya repetiré cuando me llegue el mail de encuesta. No soy muy partidario de la nivelación curricular sino de la on-demand, o sea, vamos explicando el tema y si hace falta nivelamos. Es método elegido fué nivelamos primero y vemos el tema despues.

No ha sido el caso, pero he asistido a cursos que han fallado por esto.

El otro inconveniente, ajeno al curso es que en el trabajo necesitaría dedicar el 80% de mi tiempo durante tres meses para poder adquirir y fijar los conocimientos para poder análisis rudimentarios y esto nunca va a ocurrir.



Tan mal quedé, que como no quería reescribir en minúscula en título para ponerlo acá y repudiando mi php, escribí en C un programa para convertirlo:


#include <ctype.h>
#include <stdio.h>

unsigned char buffer[] = "INGENIERIA INVERSA APLICADA AL ANALISIS DE MALWARE";

int main(int argc, char* argv[]) {
   for (int i=0; i < sizeof(buffer); i++) {
      buffer[i]=tolower(buffer[i]);

   }

   printf("%s\n", buffer);
   return 0;
}


Por supuesto, me equivoqué en un tipo, char * buffer en lugar de char buffer[] y aproveché para practicar con ddd (frontend gdb)

Pero esto es de blandengue y no tiene mucho que ver con el curso y de algún modo tengo que justificar estar escribiendo esto, así que lo volví a escribir pero en assembler:

[mainAS.c]

#include <stdio.h>

unsigned char buffer[] = "INGENIERIA INVERSA APLICADA AL ANALISIS DE MALWARE";

void tolowerAs(unsigned char * buffer, int size);

int main(int argc, char* argv[]) {
   printf("%s\n", buffer);
   tolowerAs(buffer,sizeof(buffer));
   printf("%s\n", buffer);
   return 0;
}


Yo soy un eterno principiante de assembler pues no lo puedo practicar y terminar de asimilarlo, así que a lo script kiddie me busqué un ejemplo de algo parecido y por supuesto no funcionó. Estaba sacando los parámetros del stack, pero con gdb ví que estaban en dos registros.




 Quise comprobarlo con objdump:


mainAS.o:     file format elf64-x86-64
Disassembly of section .text:

0000000000000000 <main>:
   0:    55                       push   %rbp
   1:    48 89 e5                 mov    %rsp,%rbp
   4:    48 83 ec 10              sub    $0x10,%rsp
   8:    89 7d fc                 mov    %edi,-0x4(%rbp)
   b:    48 89 75 f0              mov    %rsi,-0x10(%rbp)
   f:    be 33 00 00 00           mov    $0x33,%esi
  14:    bf 00 00 00 00           mov    $0x0,%edi

  19:    e8 00 00 00 00           callq  1e <main+0x1e>
  1e:    bf 00 00 00 00           mov    $0x0,%edi
  23:    e8 00 00 00 00           callq  28 <main+0x28>
  28:    b8 00 00 00 00           mov    $0x0,%eax
  2d:    c9                       leaveq
  2e:    c3                       retq 


Me imagino que donde dice mov $0x0, %edi al hacer el linkeo se pone el valor de donde realmente está el buffer. Lo mismo con los callq.

Entonces escribí esto:


[tolower.s]
.globl tolowerAs

# esi has the size
# edi has a pointer to the buffer

.text
tolowerAs:
   push %rax           # we will use %rax
   xor %rax,%rax

start_loop:            # start loop
  dec %esi               # point to last unprocessed position in buffer
  mov (%rsi,%rdi),%rax   # load that position
  cmp $32,%al            # skip if it is an space
  jz continue
  add $32,%rax           # convert to lower case
  movb %al,(%esi,%edi)   # put it in the buffer
continue:
  cmp $0,%esi            # finished?
  jz loop_exit
  jmp start_loop         # keep going

loop_exit:
  pop %rax
  ret



$  gcc -ggdb -std=c99 mainAS.c tolower.s -o tolower && ./tolower
INGENIERIA INVERSA APLICADA AL ANALISIS DE MALWARE
ingenieria inversa aplicada al analisis de malware


Magia, funciona. Ya sé que tendría que controlar que estuviera en el rango de las mayúsculas más que solamente el espacio, pero es una POC.


A la conferencia asistí una hora, una hora y tres horas. Sólo vi las charlas "Multiple vulnerabilities in Schneider Electric PLC", que sirve para mejorar mis conocimientos básicos para el proyecto CIAA y "Look Mom, I don't use  Shellcode: Browser Exploitation Case Study for IE 11" que sirve para apreciar cuanto hay por aprender.

Nos vemos la próxima, espero poder asistir a toda la conferencia.




[1] https://www.ekoparty.org/ingenieria-inv-malware.php
[2] cuando sigas leyendo verás por qué está sin acentos
[3] http://compusaurios.blogspot.com.ar/2012/10/libro-disco-para-pc-ensamblador-8088.html