2018/04/30

TLS Kill Switch

Entre otras tantas funciones en el trabajo tengo la de gestión de vulnerabilidades, lo que incluye descubrir, reportar, recibir reportes, evaluar, seguimiento y colaborar en la solución.

Hubo un caso interesante en iOS que consiste en que un malware podría hacerle creer a una aplicación que se está conectando a un sitio legítimo cuando éste no lo es. Conversé con la gente apropiada y le recomendé, ¡oh pecado! usar una variable global para solucionar el problema. Pero esto fué completamente intuitivo, casi irresponsable diría, así que me puse a estudiar un poco más el asunto, intentando reproducir el comportamiento en una plataforma a mi alcance como CLI en linux.

La idea es que se precargan (LD_PRELOAD) funciones en lugar de las provistas por las librerías del sistema. Esto es muy útil no sólo para TLS Kill Switch sino para lo que fueron ideadas originalmente: hotpatching de código que no deseamos o no podemos recompilar, hacer debug, instrumentar análisis de performance.

Preparé una charla y unos workshops para compartir internamente en el trabajo y luego lo mostré en OWASP Latam Tour 2018 BsAs[2], que fue una experiencia muy amena..., amenazadora, es que la última vez que había expuesto en OWASP[3], en el momento del máximo climax de la demo, en el que iba a mostrar la respuesta a todas las preguntas, no pude encontrar el payload que tenía preparado, pese a que tenía escrito en un papel delante de mis ojos su ubicación.

Esta vez todo salió bien, incluso los jocosos momentos en que no pude agrandar la letra.

Volviendo a la precarga, se pueden reemplazar las funciones que querramos, así que si vas mirando los ejemplos [4], podrás jugar con el azar, construir un sencillo keylogger y finalmente sabotear TLS.


Por si te lo perdiste, el viernes 2018-05-04 lo presentaré[5] en el marco de Los Viernes Ñoños de CADIEEL [6]


Cualquier duda, me preguntas.



[1] https://github.com/nabla-c0d3/ssl-kill-switch2
[2] https://www.owasp.org/index.php/LatamTour2018#tab=ARGENTINA_-_Buenos_Aires

[3] https://seguridad-agile.blogspot.com.ar/2014/05/el-error-ajeno.html
[4] https://github.com/cpantel/TLSKillSwitch
[5] https://goo.gl/forms/7CCn26DDLOJbfiVs2
[6] https://groups.google.com/forum/?hl=en#!topic/embebidos32/88bOqO63eWw




2016/11/13

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