Kickstarter hackeado, hechos y conclusiones

Kickstarter (www.kickstarter.com) una de las webs de crowdfunding online está ahora en la lista de sitios web hackeados y se considera que ha sufrido una brecha de seguridad de criticidad alta. Los hackers obtuvieron acceso ilegal al sitio web y robaron información de los usuarios, incluyendo nombres de usuario, contraseñas cifradas, direcciones de correo electrónico y números de teléfono. Sin embargo, entre la información robada parece que no hay ningún dato de tarjetas de crédito.

La compañía reveló en una nota que los hackers tuvieron éxito en la obtención de acceso a dos cuentas. La compañía recomendó a los usuarios que cambiaran su contraseña de inmediato. Incluso la empresa dijo que si los usuarios estaban utilizando la misma contraseña para otros sitios web, debían cambiarla de inmediato para mantener la seguridad.

Las contraseñas robadas se cifran utilizando SHA-1, y la compañía avisó a los usuarios del cambio de contraseña con el propósito de login. Sin embargo, la compañía no almacena el número de tarjeta de crédito completo, aunque sí almacena la fecha de caducidad y los últimos cuatro dígitos de su tarjeta de crédito.

Después de la revelación de tal actividad, la compañía parece que ha dejado atrás el ataque, pero informaba a los clientes que el sábado 15 de febrero 2014: "Sentimos mucho que esto haya sucedido. Tenemos el listón muy alto en la forma en la que servimos a nuestra comunidad, y este incidente es frustrante y molesto." la empresa justifica en un blog. La compañía ha respondido a más de 5.000 consultas sobre esta noticia.

Kickstarter aprendió de este ataque, y ha puesto su atención en la mejora de sus procesos de seguridad y de sus sistemas de seguridad de muchas maneras. La compañía también está haciendo todo lo que está su alcance para evitar este tipo de ataques en el futuro próximo.

Los increíbles cinco hechos acerca de este informe:

• Kickstarter no sabía que habían sido hackeados, hasta que la autoridad policial les informó.
• No hay información robada de tarjetas de crédito excepto nombres de usuario, contraseñas, direcciones de correo electrónico, etc.
• La compañía no ha revelado la cantidad de datos robada.
• Las contraseñas se protegen criptográficamente (hash) lo que hace a los hackers difícil romperlas.
• La reutilización de una contraseña en múltiples sitios es peligrosa y así lo comunicó la compañía.
• Por último, la compañía reveló todos los detalles después de cuatro días del ataque.

En conclusión:

La cibercrimen es una preocupación creciente en el mundo de Internet, y nos estamos dando cuenta que el año pasado se robaron millones de datos y que todavía estas brechas e incursiones siguen vigentes en el actual 2014. De los puntos anteriores, sólo podemos mantener la esperanza de que la empresa encuentre el verdadero culpable detrás de este ataque, y que pueda recuperar la confianza y la fe de sus clientes.

English version:
 
Kickstarter (www.kickstarter.com) one of the online crowdfunding website is now in the list of the hacked websites, which is to be stated a high-profile website breach. Hackers gained illegal access of the website and stole user’s information, including usernames, encrypted passwords, email address, and phone numbers. However, during this data breach there is no harm caused to the credit card data.

The company revealed in a note that the hackers were successful in gaining access of two accounts. The company said to users to change their password right away for the website. Even the company said to users that if users were utilizing the same password for other websites, then users should change immediately for better security. 

The stolen passwords were encrypted using SHA-1, and the company said to users to apply new password for login purpose. However, the company does not store the full credit card number, but only stores expiry date and the last four digits of credit card.

After revelation of such hacking activity, the company has overcome from the breach but informs customers on Saturday, 15 Feb. 2014. "We’re incredibly sorry that this happened. We set a very high bar for how we serve our community, and this incident is frustrating and upsetting." the company justifies in a blog post. The company has responded to more than 5000 inquiries about this news.
 
Kickstarter learned from this attack, and improved their security processes and security systems in many ways. The company is also doing everything within their power to avert such attacks in the near future.

The amazing five facts about this report:

•    Kickstarter did not know that they had been hacked, but the law enforcement authority informed them.
•    No credit card data was breached except username, passwords, email address, etc.
•    The company has not disclosed the amount of breached data.
•    The passwords were not encrypted but cryptographically hashed, which made it difficult for hackers to break them.
•    Reusing a password in multiple sites is dangerous so stop using them as per company statement.
•    Finally, the company revealed all the details after four days of the attack.
 
In the conclusion:
 
Cyber crime is a growing concern for internet world, and we have noticed millions of data breach happened in the past year and is still prevailing in the current 2014 year. From the above points, we can only keep hope that the company will find the real culprit behind this attack, and can restore faith in customer’s community.

About Author 
 

Abel Wike is a head of fraud prevention team at ClickSSL.com She enjoys the challenges of creativity and attention to detail. Advance Technology has always a source of wonder for her, sparking her research, to extend her sympathetic and knowledge of this earliest progress. In so doing she has focused with a deeper insight into various technologies. Follow her on Facebook, Twitter & LinkedIn


Fuente

Prescinde de tu Sistema Operativo, si puedes...

Imaginemos la siguiente situación: Usted tiene la intención de realizar un ataque de fuerza bruta sobre una contraseña aplicando un algoritmo dado. Entonces debe de tomar algunas decisiones importantes que influirán en el rendimiento y el tiempo de ejecución que su programa de crackeo tardará en completar el proceso. A pesar de que puede escribir su aplicación ayudado por las facilidades de algún lenguaje interpretado (como Perl o Python), se da cuenta de que escribir el código en C y obtener un binario compilado puede brindarle algunas mejoras significativas en lo que a performance se refiere.

Finalmente, y antes de correr el programa, cierra todas las aplicaciones y procesos que pudiesen estar consumiendo recursos del sistema: el navegador web, el procesador de textos y quizás hasta su preciado antivirus. Ahora ya puede dejar que su ordenador haga todo el trabajo y sentarse en el sofá a la espera de resultados, al fin y al cabo su procesador se encuentra ocupado únicamente con el algoritmo de bruteforce, ¿verdad?

La cruda realidad no muestra una cara tan bonita, por desgracia. Puede regresar a su equipo y abrir el monitor de procesos/administrador de tareas, tranquilamente otros 20 procesos podrían estar ejecutándose además del suyo, y algunos de ellos ni siquiera pueden “matarse” sin cargarse el sistema. Pero esto no es más que la punta del iceberg, su SO está gestionando por detrás múltiples hilos de kernel, interrupciones, mecanismos de entrada/salida (I/O), y si todavía no se ha desconectado de Internet, atendiendo a todos los paquetes que entran y salen por la interfaz de red.

Y hay más, muchísimo más, su querido sistema multitarea realiza controles de colas, intercambio de stacks entre procesos, IPC, y está haciendo verdaderas virguerías con la paginación y gestión de memoria virtual ayudado por el hardware subyacente. Digamos que cada 100ms una interrupción se genera en el procesador (ticks de reloj) y el núcleo del sistema retoma el control e invoca el scheduler para comprobar cuál es el próximo proceso que merece su tiempo (slice). Desde luego, esto es lo que hace un sistema operativo moderno, y otra infinidad de tareas que de forma intencionada nos dejamos en el tintero, pero usted solo quería crackear una contraseña, todo lo demás es “tiempo perdido”.

Bajo esta premisa decidí realizar la siguiente demostración. Cree un pequeño programa que aplicara la conjectura de Collatz para los primeros cincuenta millones de números. Al igual que un algoritmo de bruteforce, esto proporciona alimento suficiente para el procesador. El cálculo es sencillo, se selecciona un número, si es par se divide entre 2 y si es impar se multiplica por 3 y se suma 1, y se vuelve a aplicar el mismo proceso sobre el resultado. La conjetura dice que para todos los números naturales la secuencia siempre termina en 1. Observe el siguiente programa:

#include <stdio.h&gt
#include <stdlib.h>
#include <string.h&gt
#include <time.h>
void print_time(void)
{

char buff[32];
time_t now;
memset(buff, 0, 32);
now = time(0);
strftime (buff, 32, "%H:%M:%S", localtime(&now));
printf("%s\n", buff);

} 

int main(int argc, char *argv[])
{

unsigned int i, n;
print_time();
for ( i = 1; i < 50000000; i++ ) {

n = i;
while ( n != 1 ) {
if ( n % 2 == 0 )

n = n / 2;

else

n = n * 3 + 1;

}

}
print_time();
return 0;

}

Luego lo ejecutamos en una distribución Ubuntu 12.04 (3.5.0-40) sobre un procesador Intel(R) Core(tm)2 Duo T8300 2.40 GHz con 3GB de memoria RAM. La imagen muestra el resultado.

Figura 1: Tiempo de ejecucion del programa de ejemplo

 

El cálculo se ha prolongado por 50 segundos del reloj. Y ahora viene la pregunta clave, ¿qué ocurriría si pudiésemos hace que el procesador dedicase todo su tiempo a nuestro algoritmo? La solución pasaba por crear un bootloader en el primer sector de un disquete o USB que simplemente crease una GDT básica para pasar del modo real al modo protegido (facilitando así la posibilidad de ejecutar código C) y luego aplicar el mismo algoritmo.

No tenemos la intención de mostrar aquí el código completo, solo lo suficiente para que comprenda la explicación. He aquí la primera parte del proceso de boot en ensamblador. En lo que nos concierne, no hace falta que lo comprenda, digamos que simplemente pasa al modo protegido y luego llama a una función bootmain().

.code16
.globl start
start:

cli
xorw %ax,%ax
movw %ax,%ds
movw %ax,%es
movw %ax,%ss

clear_scr:

movb $0x06,%ah
movb $0x07,%bh
xorw %cx,%cx
movb $24,%dh
movb $79,%dl
int $0x10

seta20.1:

inb $0x64,%al # Wait for not busy
testb $0x2,%al
jnz seta20.1
movb $0xd1,%al # 0xd1 -> port 0x64
outb %al,$0x64

seta20.2:

inb $0x64,%al # Wait for not busy
testb $0x2,%al
jnz seta20.2
movb $0xdf,%al # 0xdf -> port 0x60
outb %al,$0x60
lgdt gdtdesc
movl %cr0, %eax
orl $CR0_PE, %eax
movl %eax, %cr0
ljmp $(SEG_KCODE<<3), $start32

.code32
start32:

movw $(SEG_KDATA<&lt3), %ax # Our data segment selector
movw %ax, %ds # -> DS: Data Segment
movw %ax, %es # -> ES: Extra Segment
movw %ax, %ss # -> SS: Stack Segment
movw $0, %ax # Zero segments not ready for use
movw %ax, %fs # -> FS
movw %ax, %gs # -> GS
movl $start, %esp
call bootmain

spin:

jmp spin

.p2align 2
gdt:

SEG_NULLASM # null seg
SEG_ASM(STA_X|STA_R, 0x0, 0xffffffff) # code seg
SEG_ASM(STA_W, 0x0, 0xffffffff) # data seg

gdtdesc:

.word (gdtdesc - gdt - 1) # sizeof(gdt) - 1
.long gdt # address gdt

Y ahora la función bootmain() en C que finalmente ejecuta la Conjetura de Collatz e imprime el rango de tiempo:

#include "types.h"
static ushort *crt = (ushort*)0xb8000; // CGA memory
void
bootmain(void)
{

unsigned int n, i;
unsigned short segundos = 0x00, minutos = 0x00, horas = 0x00;
asm volatile ("xorb %%al,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(segundos));
     asm volatile ("movb $0x02,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(minutos));
asm volatile ("movb $0x04,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(horas));
crt[160] = ((horas >> 4) + '0') | 0x0a00;
crt[161] = ((horas & 0x0f) + '0') | 0x0a00;
crt[162] = ':' | 0x0a00;
crt[163] = ((minutos >> 4) + '0') | 0x0a00;
crt[164] = ((minutos & 0x0f) + '0') | 0x0a00;
crt[165] = ':' | 0x0a00;
crt[166] = ((segundos >> 4) + '0') | 0x0a00;
crt[167] = ((segundos & 0x0f) + '0') | 0x0a00;
for ( i = 1; i < 50000000; i++ ) {

n = i;
while ( n != 1 ) {

if ( n % 2 == 0 )
     n = n / 2;
else
     n = n * 3 + 1;

}

}
asm volatile ("xorb %%al,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(segundos));
     asm volatile ("movb $0x02,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(minutos));
     asm volatile ("movb $0x04,%%al;"
     "out %%al, $0x70;"
     "in $0x71, %%al": "=a"(horas));
crt[240] = ((horas >> 4) + '0') | 0x0a00;
crt[241] = ((horas & 0x0f) + '0') | 0x0a00;
crt[242] = ':' | 0x0a00;
crt[243] = ((minutos >> 4) + '0') | 0x0a00;
crt[244] = ((minutos & 0x0f) + '0') | 0x0a00;
crt[245] = ':' | 0x0a00;
crt[246] = ((segundos >> 4) + '0') | 0x0a00;
crt[247] = ((segundos & 0x0f) + '0') | 0x0a00;
return;

}

En el centro de este código observamos el mismo bucle for() que en el programa original que ejecutamos en Linux, todo lo demás son las virguerías que hay que hacer para interactuar con los puertos y obtener la hora de la máquina. Recuerde que lo que estamos haciendo en realidad es programar un “mini sistema operativo” que únicamente ejecuta nuestro algoritmo y luego entra en un bucle infinito. Una vez que compilamos todo el tinglado y lo insertamos en un disquete (obviamos este proceso en el artículo), accedemos a la BIOS para indicarle que arranque desde el floppy. En la imágen el resultado:

Figura 2: Resultado obtenido prescindiendo del sistema operativo

El proceso ha durado tan solo 30 segundos frente a los 50 invertidos por el sistema operativo. Sorprendentemente hemos realizado la misma tarea en un 60% del tiempo inicial, lo cual quiere decir, de forma aproximada, que un ataque de bruteforce que se prolongase por 24 horas, podría realizarse en unas 14 horas “si prescindimos del sistema operativo”.

Otra prueba sobre Windows XP con un procesador AMD Athlon(tm) 64 3000+ 1.81GHz y 512 MB de RAM, proporcionó un resultado de 46 segundos frente a los 68 que tardaba la aplicación en la shell del sistema operativo.

¿Qué es un sistema operativo? Pues esos 22 segundos “fantasmas” de diferencia que usted no sabía que podía ahorrarse.

Obviamente, esta demostración y el artículo que está leyendo no son más que una demostración curiosa. Usted necesita un sistema operativo para trabajar y créame que hoy en día estos invierten ese tiempo fantasma de una forma más económica y elegante que hace algunos años.

Las pruebas se han realizado sobre sistemas operativos de 32 bits, con un procesador x86_64 y un Windows 7 de 64 bits (por poner un ejemplo), seguramente habría que trabajar sobre long mode para poder realizar comparativas fiables...

Entienda que estamos programando la máquina desde cero, y no disponemos de ninguna de las facilidades que un sistema operativo le ofrece al programador, no existen librerías del sistema y todo debe hacerse a bajo nivel, pero no sería descabellado crear un sencillo framework con un bootloader básico que cargase un kernel mínimo en el que usted pueda insertar su algoritmo. Funciones de manejo de cadenas y otras de salida por pantalla pueden ser creadas de antemano sin mucho esfuerzo y proporcionadas por anticipado. No es más que una idea... interactuar directamente con la GPU de la tarjeta gráfica siempre parece más atractivo.

Toda esta teoría también podría aplicarse a un dispositivo Raspberry Pi si usted es capaz de crear un bootloader para ARM, prescindiendo así de la distribución Raspbian de Linux. Estos aparatos pueden realizar algunas tareas costosas si se combinan en un potente cluster, pero si usted no es un gurú o un ninja de la programación, será realmente complicado comunicar entre sí todos los dispositivos y realizar cualquier tipo de procesamiento paralelo.

Por lo demás… Happy Hacking!

by blackngel (blackngel@blackbycode.com)

HTML Injection en la aplicación Google Play Store

Miguel Ángel Jimeno es un joven aprendiz de seguridad informática de La Rioja que con 17 años se ha abierto un blog llamado "Researching for fun" en el que está publicando los primeros bugs de XSS que ha encontrado. Por el momento ha publico un Stored XSS en Avast, un XSS en Tumblr, un XSS en Shaukk y un Stored XSS en un dominio de Google usando un fichero en Flash. El último de sus descubrimientos fue un fallo de tipo HTML Injection en la aplicación Play Store de Android que reportó al equipo de Google. Han pasado un par de meses y parece que ya debería estar arreglado, así que aquí está la información del bug y su experiencia en el reporte del mismo.

HTML Injection en la aplicación Google Play Store

Para reproducir el fallo se debe ir desde el terminal Android en Play Store a Mis Aplicaciones y pulsar sobre cualquier aplicación. Se selecciona la opción para dar tu opinión y solo es necesario rellenar un número aleatorio de estrellas, poner el resumen que quieras y en el apartado que dice “Comentar” escribir cualquier código HTML. Para la prueba de concepto yo utilicé <img src=”a”/>. Y ya puedes publicar el comentario con el HTML Injection.

Figura 1: Publicando un comentario con HTML Injection en Play Store

En este ejemplo se puede ver un cuadrado con la imagen en fondo azul claro, que demuestra que se podía inyectar un código HTML en el comentario. Esto solamente es una prueba de concepto, pero podría publicarse casi cualquier etiqueta HTML, sirva como ejemplo publicidad de una app infectada propia entre etiquetas, seguro que más de un curioso la descargaría, o como forma de distribuir troyanos para terminales Android. La prueba está hecha con un Nexus 4 en 4.4.2.

Figura 2: El comentario queda publicado

Como información, les dejo cómo fue la cronología del reporte por si alguien tiene una experiencia similar. Tras varias respuestas automáticas se pasa el fallo al equipo de seguridad de Android el 14/12/2013.

Hello, 

Thank you for the report, I have forwarded it on to the Android security team.

Regards,

Se pasa el caso al equipo encargado del Play Store el 16/12/2013:

Thank you very much for the report, Miguel. I've forwarded it to the Google Play team. I'll keep you posted. 

Best Regards,

Desde el Android Security Team el día 26/12/2013 dicen estar probando un parche:

Hi Miguel, 

The Play team is now testing a fix -- I should know the expected live date for the change soon after the holidays. 

Thanks,

El 7/2/2014 dicen que el fallo debería estar ya arreglado, aunque aún no sé cómo y dónde, pues parece que aún funciona.

Hi Miguel, 

This issue should now be fixed. Thank you very much for your assistance.

Android Security Team

Tras preguntar sobre mi elegibilidad para el Hall of Fame de Google, obtengo esta respuesta:

Hi Miguel, 

We appreciate you reporting this issue to us, but unfortunately most non-web applications other than Google Wallet and Google Chrome are excluded from the Vulnerability Rewards Program. More info on what's in scope for the program is available here: http://www.google.com/about/appsecurity/reward-program/index.html. Thanks! 

Regards,

Más o menos yo imaginaba ya la respuesta cuando leí los términos de su programa de recompensas. Mi conclusión: si deseo alguna recompensa por parte de Google, debo seguir intentándolo, pero al menos fui capaz de encontrar un fallo en un software de Google, lo que no está nada mal.

Autor:
Miguel Ángel Jimeno (@migueljimeno96)

 

Fuente

Desarrollan malware capaz de capturar gestos ¡bienvenidos a la era de los touchloggers!

Neal Hindocha y Nathan McCauley han desarrollado junto con sus colegas de Trustwave y Square respectivamente una prueba de concepto de malware capaz de capturar las acciones de los usuarios en los dispositivos de pantalla táctil, dijese sobretodo smartphones y tablets.

El código malicioso es funcional para dispositivos Android 4.1 y 4.3 rooteados, dispositivos Android sin rootear conectados al PC, e incluso dispositos iOS 7.0 con jailbreak.

Los prototipos de los llamados "touchloggers" son capaces de capturar todo lo que un usuario hace en un dispositivo con pantalla táctil y no sólo cuando un usuario toca la pantalla, también pueden tomar capturas de pantalla que pueden superponerse con la información de las coordenadas para averiguar exactamente lo que alguien está haciendo, al menos en teoría.

Aunque todavía esta vía de ataque está "en pañales" y parece inviable, sin duda se trata de un aviso para navegantes, una llamada de atención para empezar a desarrollar las defensas oportunas antes de que los desarrolladores de malware se adhieran a esta idea. Ni que decir tiene lo "jugosos" que son los terminales punto de venta en los entornos comerciales y que cada vez más y más se apuesta por la tecnología de pantalla táctil, vease Windows 8 por ejemplo.

A finales de este mes en la conferencia RSA en EE.UU., Neal y Nathan presentarán esta nueva amenaza y esbozarán algunas medidas para protegerse contra posibles ataques.

Fuente: Put down that iPad! Snoopware RECORDS your EVERY gesture, TAP on iOS, Android

Reflection Attack NTP

Fuente

En diciembre de 2013, Symantec ya advirtió que los ciberdelincuentes estaban abusando cada vez más de Network Time Protocol (NTP) para lanzar ataques distribuidos de denegación de servicio (DDOS). 

Durante el presente mes, tuvieron lugar diversos ataques distribuidos de 
denegación de servicio sobre redes de servidores de juegos. La lista de juegos atacados incluye a World of Tanks, League of Legends, Free Realms, DC Universe Online, PlanetSide 2 y Everquest. Empresas como EA, Sony, Blizzard, Valve y Microsoft han sido impactadas por los ataques lanzados por un grupo llamado DERP Trolling. La razón:  “for lulz” XD que jodidos!!. 

La noticia ha levantado bastante polvo en Internet y ha propiciado una supuesta actualización de estos servidores.

Para los expertos NTP no representaba una amenaza seria y a menudo es descuidado por los administradores de sistemas ( xD si ya descuidaban DNS...) a pesar de que la vulnerabilidad ya aparecía en 2010. Por cierto, incluso tiene un CVE asociado, el CVE-2013-5211), DERP Trolling ha dejado patente que tenemos que cambiar la visión que tenemos frente a este protocolo.. 

Hoy veremos como se lleva a cabo este tipo de ataque (bastante sencillo)...
 
Antes de nada veamos qué es NTP:

Network Time Protocol (NTP)  es un protocolo estándar para la sincronización de relojes de máquinas interconectadas a través de redes de datos, en particular Internet. Este protocolo permite que el reloj de un sistema mantenga una gran precisión, independientemente de su calidad y de las condiciones de la red. Para el que quiera una mayor información del protocolo: ntp.org.

También quiero advertir que si queremos llevar acabo esta prueba de concepto, lo hagamos bajo un entorno seguro y nunca en Internet; si no queremos vernos en la tesitura de tener que responder ante la justicia por llevar a cabo un ataque DDOS con los consecuentes prejuicios que nos pueda suponer...

Manos a la obra!!!

¿CÓMO FUNCIONA EL ATAQUE?

 
No vamos a entrar en mucho tecnicismo, ya que el objetivo de esta entrada (y de todas la que hago) es que cualquier persona o la mayoría pueda entenderlas (o casi entenderlas)  y concienciarse de lo importante que es la seguridad...
para hacer más segura la red para todos, se generen más puestos de trabajo y me saque alguien del paro XD, me pueda comprar perro, casa, coche, tener hijos y no verme obligado a migrar a Londres a poner café.

Esta técnica aprovecha varios factores para generar un tráfico no solicitado de una manera "lícita", es decir, no aprovecha ningún tipo de infección, botnet ...o bug.... sino de la falta o descuido de configuración de los servidores de terceros. 

En teoría lo que tenemos que hacer es, pedirle cierta información a varios servidores NTP como si fuésemos otra máquina (la víctima)...a  fin de que la "el objetivo" la reciba.

A cuantos más servidores le pidamos esta información, mayor será el numero de respuestas , en consecuencia, mayor será el volumen de datos,  pudiendo llegar a colapsar la máquina atacada...

Lo primero que necesitamos es un servidor NTP. Esto no es muy difícil, pero si hacemos una consulta normal a estos servidores recibiremos una respuesta estándar, con un tamaño de información escaso; pero para "noquear" a la víctima necesitaríamos muchísimas peticiones ...
 
AMPLIFICANDO EL ATAQUE:
 
Es aquí donde entra en juego una de las capacidades del protocolo NTP: por cada petición, por ejemplo de 8 bytes, puede llegar a generarse una respuesta hasta casi 60 veces mayor (esto ya nos cuadra mas).

Pero esta respuesta no es la habitual de un servidor NTP sino que es una característica del protocolo que ahora ha sido parcheada para evitar este tipo de ataques. (O_o) seguro?

Creerme que no es difícil encontrar servidores no parcheados sobre todo si nos vamos al país del sol naciente...

Para conseguir este tipo de respuesta el servidor tiene que responder al comando mon_grelist. Con este comando lo que conseguimos es que nos mande una lista de todos sus clientes...

Para ver si el servidor es vulnerable podemos utilizar nmap con su script ntp-monlist.nse.

nmap -sU -pU:123 -Pn -n --script=ntp-monlist.nse <servidor NTP>

 
Para hacernos una idea del tráfico que podemos llegar a generar podemos hacer una consulta lícita al servidor con ntpd.

 #ntpdc -c monlist <servidor>

Una vez provisto con unos cuantos de estos server (en diez minutos y sin buscar mucho he encontrado unos 50).

Pasamos a la segunda fase de nuestro ataque.  
 
PoC DEL ATAQUE
 
Vamos a ver dos maneras de hacer esto: la rápida y la que explica el ataque por sí sola.

Quizás la manera mas gráfica y sencilla de comprender este proceso sea capturando y falseando un paquete NTP con la petición monlist. Esto requiere conseguir un paquete líicito para su posterior modificación, luego veremos como crearlo desde cero. 

Para ello utilizaremos el paquete que hemos enviado para hacernos una idea del tráfico:

Preparamos tcpdump para que capture el paquete y nos lo guarde con el nombre NTP_pakete

#tcpdump -i <interfaz>   -x -n -e -l -w NTP_pakete -c1 host <nuestra ip> and port 123

En otro terminal ejecutamos el comando de consulta con ntpd.

#ntpdc -c monlist <servidor>

Y ya tendríamos nuestro paquete para analizarlo y para juguetear con él...(podemos ayudarnos de wireshark para ubicarnos en el paquete).

 

Para manipular muy fácilmente el paquete podemos utilizar packeth, aunque podríamos hacerlo a pelo con Hexedit.


Retocaremos y guardaremos tantos paquetes como a servidores NTP queramos hacerles la "consulta" cambiando la ip origen por la de la victima y la ip destino por la ip de los servidores NTP que hemos encontrado previamente.

Packeth nos da también la opción de mandar los paquetes, aunque seria algo lento... es preferible la herramienta tgn con la cual podemos hacer un script con poca dificultad y automatizar el proceso de consulta a los servidores NTP.....

Creando el paquete NTP desde 0  y realizando el ataque con scapy

Para hacer el proceso anterior muchísimo mas rápido, tenemos un montón de opciones, aquí me decanto por scapy.

Podemos generar el paquete en scapy de la siguiente forma, siendo dst la ip del servidor y src la ip del objetivo.

Desde este punto no sería difícil construir un script que automatizara el ataque al máximo. Mandando varias peticiones a varios servidores y focalizando las respuestas sobre un objetivo. 

Un saludo, sed buenos ;D

>>> paquete = IP(dst='59.xxx.xxx.245',src='192.168.1.190')/UDP(sport=48947,dport=123)/Raw(load=str("\x17\x00\x03\x2a") + str("\x00")*4) 
>>> send(packet,loop=1)

https://thedaywefightback.org/

dSploit: Pentesting & Hacking WiFi desde Android (2 de 2)

- Sesiones: A partir de la release de finales de diciembre, esta herramienta está comenzando su integración con Metasploit, por lo que se ha añadido la opción de Sessions que permite manejar sesiones abiertas de MSF en un determinado host.

- MiTM:  Bajo esta opción se guardan todas las posibles formas de atacar conexiones en la red WiFi. Todas ellas se realizan en el protocolo IPv4 - habrá que esperar a una versión de Evil FOCA para Android -. Las acciones que se pueden hacer solo causan efecto sobre conexiones no cifradas. Las acciones de MiTM que posee esta herramienta pueden apreciarse en la siguiente imagen. 

Figura 7: Acciones que se pueden hacer en ataques Man in the middle

Esta son la lista de herramientas que tiene introducidas dSploit en el equipo, y por lo que le hace tan poderoso y peligroso en un red WiFi en la que se conectan usuarios libremente cuando hace el ataque man in the middle entre la puerta de enlace y el objetivo seleccionado.

A) Sniffer simple: La herramienta redirecciona el tráfico del equipo seleccionado a través de ella a la vez que realiza la captura de éste y lo almacena en un archivo pcap que pueda ser analizado posteriormente en detalle por un poderoso WireShark. También arroja estadísticas de las direcciones IP detectadas junto con el ancho de banda que consumen y el total de bytes trasmitidos por cada una de ellas.

Figura 8: Sniffer simple

B) Snifffer de contraseñas: Realizará la misma acción que la anterior con la diferencia de que solo se ocupará y almacenará los datos relacionados a credenciales de autenticación de distintos protocolos, entre los que están aplicaciones que hagan uso de HTTP, FTP, IMAP, IMAPS, IRC, etcétera.

C) Sessión hijacker: dSploit captura las cookies de  sesión que circulan por la red, permitiendo secuestrar las sesiones activas. La aplicación lista todas las cookies capturadas una vez se inicie la acción y si se presiona sobre alguna de ellas permite realizar el secuestro de la sesión seleccionada.

Figura 9: Sesiones abiertas con cookies seguras o inseguras

Una vez pulsada una de estas sesiones capturadas se abrirá automáticamente dentro de la aplicación una vista de la web a través de la cual se puede navegar con la sesión seleccionada. El concepto es un hijacking de sesión clásico, pero con la facilidad que propuso Firesheep cuando se presentó oficialmente. Hoy en día existen multitud de herramientas automatizadas que hacen el Session Hijacking con la misma simpleza.

Figura 10: Sesión de Windows Técnico que iba por HTTPs secuestrada

D) Bloqueador de conexiones: la aplicación descarta todos los paquetes que recibe de la víctima, resultado esto en un bloqueo de la conexión del equipo sobre el cual estamos realizando el ataque.

E) Redirector: la herramienta redirige toda la navegación web de la víctima a una web que se le especifique sin importar la petición que se realice. Útil cuando se quiere lanzar un exploit de client-side para explotar un bug en el navegador sí o sí.

Figura 11: Opciones de redirección a una URL 

 

F)Reemplazar imágenes/vídeos: esta herramienta se encarga de sustituir todas las imágenes o vídeos que puedieran contener las páginas web consultadas. Se le debe especificar a la aplicación la imagen por la cual se deben sustituir las originales, ya sea a través de una dirección URL o mediante la selección de una imagen local del propio terminal móvil.

Figura 12: Artículo de Windows Técnico con las imágenes cambiadas por el mitm

Una vez aplicada esta acción, cada vez que se consulte una web no cifrada se sustituirán todas las imágenes que contenga la web, haciendo que la víctima cada vez que intente abrir una página con imágenes obtenga el siguiente resultado. Como puede observarse todas las imágenes de la web fueron sustituidas por una que se especificó a través de una dirección URL.

G)Inyector de scripts: la herramienta inyectara un código script en todas las páginas web visitadas por la víctima, haciendo que este se ejecute automáticamente antes de que el usuario pueda visualizar la web. Un ejemplo de ello podría ser un simple JavaScript con un alert (‘hola mundo maligno’) obteniendo el siguiente resultado.

Figura 13: Script inyectado en página web vista por la víctima

H) Filtro personalizado: la aplicación es capaz de reemplazar el texto de las web. Para ello se le debe especificar a la herramienta el texto que se desea buscar y el texto por el cual debe reemplazarlo.

Estas acciones de cambiar imágenes, texto, vídeos, código HTML o inyectar Scripts, fueron todas presentadas hace tiempo con The Middler, un framework para hacer justo esto, pero de forma masiva, pudiendo inyectar, entre otras cosas, el payload de BeeF Project y hacer así una JavaScript Botnet. Aquí tienes la presentación de la DefCON 17.

Figura 14: Conferencia sobre The Middler 2.0 en DefCON 17

- Packet forger: La última de las opciones que se pueden hacer sobre un objetivo - ya fuera del menú Man in the Midlle, es esta que permite crear y enviar un paquete personalizado al (ya sea TCP o UDP) objetivo seleccionado para poder hacer ataques personalizados cuando así se requiera.

Conclusiones

A groso modo estas son las acciones que se pueden realizar con esta herramienta. Como puede verse es una aplicación bastante potente y variada con la que se puede realizar distintos tipos de pruebas de la seguridad en redes desde un dispositivo móvil. Además, es una aplicación gratuita y de código abierto, lo que significa que es posible colaborar y seguir de cerca la evolución de esta herramienta a través de su página de Github.

La manera en cómo puedes colaborar reportando fallos, mejorando implementación del código de la aplicación, traduciendo la herramienta a idiomas no soportados o mejorando las traducciones ya realizadas, etc. Si estáis interesados en formar parte y colaborar con esta herramienta todo lo que necesitas saber lo puedes conseguir en la página web de dSploit.

Por otro lado, también la herramienta pone en manos de cualquiera un conjunto de potentes herramientas que se manejan de manera muy sencilla, así que ten cuidado si te conectas a una red WiFi pública, ya que puedes ver qué fácilmente te pueden hacer ataques que puedan dañarte.

Autor: Umberto Francesco Schiavo de Eleven Paths

**********************************************************************************
- dSploit: Pentesting & Hacking WiFi desde Android (1 de 2)
- dSploit: Pentesting & Hacking WiFi desde Android (2 de 2)

**********************************************************************************

China: Políticos aplican censura de contenido en Internet

La importancia de nacer en un lugar u otro va a ser crucial para el resto de tu vida. Tus expectativas de futuro están más que ligadas a tu origen de cuna y al lugar donde esa cuna estuviera. No es más que una sencilla ecuación matemática que tiene que ver con el dinero y el poder que floten al rededor de la cuna. Son los menos los que, con esfuerzo, tesón y haciendo algo de magia, consiguen burlar al destino y camuflarse en lugares en los que no se les esperaba y - me atrevo a decir - no se les tenía en estima.

Una de las herramientas más utilizadas por los de cuna de cartón es, por supuesto, la información. El conocimiento del medio que les rodea, el saber qué es qué, quién es quién y cómo funcionan las cosas, desde las más pequeñas y sencillas - como un bolígrafo - hasta las más complicadas y escondidas - como el sistema financiero - es lo que les permite actuar en pro de otro destino. Conocer da poder, pero también energía para querer cambiar las cosas cuando se descubre uno engañado.

Las castas gobernantes de los pueblos sometidos, buscan controlar la información, por todos los medios, e Internet se convirtió en un canal que atenta contra su control dejando fluir información de todo tipo a todo el mundo. Las dictaduras - y algunas no tan catalogadas como tal -, procuran controlar ese flujo de información, ya sea cortando el acceso a la misma o por medios tan variopintos como matándola en origen - por ejemplo rompiendo los equipos de informáticos de un periódico con la esperanza de destrozar las fuentes originales de información -.

En el caso de China, la censura es clara y directa - no como en otros países -. Aquí no hay trampa ni cartón. Ellos deciden qué se puede leer en Internet y qué no se puede leer de forma clara. Los vídeos publicados ahora deben ir con nombre y apellidos, para evitar que alguien diga algo que no guste al gobierno, y cuando salga una información en Internet  que no guste, como el informe del ICIJ que habla de cómo se han llevado y se llevan el dinero los que mandan en China - se bloquea y punto.

 

Figura 1: Bloqueo del informe del ICIJ en China

 

 

 

 

 

El bloqueo se puede constatar con Greatfire.org, donde basta con poner una dirección URL y ver si está siendo cortado su acceso o no. En el caso del periódico The Guardian, que también se hizo eco de la noticia en un extenso artículo, se pudo ver cómo la dirección donde se había publicado dicho informe estaba bloqueada totalmente.

Este sitio, GreatFire.org, monitoriza el número de URLs que desde China se bloquean utilizando el Great Firewall of China, y puede verse que no se escapa casi ningún lugar de Internet. En el Top de Alexa, páginas de la Wikipedia, búsquedas en Google y más de 20.000 dominios. Por supuesto, los sitios con SSL que hagan uso de Certificate Pinning y no permitan la inspección tampoco son muy bien vistos.

 

Figura 2: Listas de sitios bloqueados

 

Por suerte, mi rincón de Internet personal aún sigue siendo un lugar que puede ser visto desde China, lo que deja a las claras lo que le importa a lo que mandan allí lo que yo publique. Y como se puede comprobar, para que la gente esté tranquila, se sigue permitiendo el porno... pero no la privacidad.

 

Figura 3: El lado del mal se ve en China. Hola!

 

Creo que deberíamos trabajar para que en la ONU - o en la organización mundial que sea donde no haya derecho a veto por parte de los más poderosos - se debería empezar a tratar Internet como lo que debería ser: Algo que garantice la libertad de comunicación del ser humano a través de las tecnologías. No sería suficiente, seguro, pero ayudaría un poco a esos que que quieren escaparse de la cuna que los vio nacer.

 

No se debería permitir que a su antojo, un gobierno de un país pudiera tomar la decisión de coartar que información debiera ser vista o no por sus ciudadanos. O aún peor, vulnerar Internet mancillando su funcionamiento o matarlo desconectando la red del país tal y como ya se ha hecho en alguna ocasión. Y que se deberían aplicar sanciones de algún tipo a todos los países que lo dañen de alguna manera.  Por desgracia, hay tantos derechos aún que defender, que el derecho a un Internet como debiera ser parece quedar aún muy lejos de poder conseguirse.

 

 

 

Fuente

Spoiled Onions: un proyecto para identificar los relays de salida maliciosos en la red Tor

En enero de 2014, la red anónima Tor se compone de 5.000 relays de los cuales casi 1.000 son de salida. Como se muestra en el diagrama de la derecha, los relays de salida cierran la brecha entre la red Tor y la Internet "abierta". Como resultado, los relays de salida son capaces de ver el tráfico de red anonimizado enviado por los clientes Tor.

Aunque la mayoría de los relays de salida son inocuos y dirigidos por voluntarios bienintencionados, hay excepciones: en el pasado, se documentaron algunos relays de salida que han esnifado y manipulado el tráfico retransmitido. Los ataques expuestos en su mayoría son MiTM de HTTPS, inyección HTML y SSL tripping.

Existe un proyecto de investigación bautizado como Spoiled Onions, que ha desarrollado un escáner rápido y modular escrito en Python para detectar estos relays de salida maliciosos: exitmap. Está disponible en GitHub bajo licencia GPLv3:

git clone https://github.com/NullHypothesis/exitmap.git

Desde septiembre de 2013 ha estado monitorizando todos los relays de salida con el fin de exponer, documentar y frustrar los relays maliciosos o mal configurados. En su lista negra también incluyen relays de salida que involuntariamente interfieren el tráfico de red debido a la censura de DNS.

Así que, si utilizas Tor, ¿a qué estas esperando para echar un vistazo a esta lista?

Web del proyecto: http://www.cs.kau.se/philwint/spoiled_onions/

Paper de investigación: Spoiled Onions: Exposing Malicious Tor Exit Relays [pdf, bib]

Port knocking con un sólo paquete cifrado (SPA)

Tradicionalmente hablamos de port knocking o golpeo de puertos como un mecanismo para abrir puertos mediante una secuencia de conexiones preestablecida a otros cerrados. Por ejemplo, para abrir el puerto TCP 22 de SSH tendremos que intentar conectarnos primero al 7000, luego al 8000 y finalmente al 9000. Esto lo hemos visto recientemente con Knockd para securizar openssh en modo paranoico y hace tiempo en nuestra pequeña Raspberry Pi...

Pero "aporrear" varias veces la puerta para entrar es muy escandaloso y poco caballeroso ¿verdad?. Existe una forma más fina y elegante mediante Single Packet Authorization (en adelante SPA), una variante de port knocking con la cual sólo será necesario un sólo 'knock' mediante el envío de un único paquete cifrado.

Para ello utilizaremos fwknop (FireWall KNock OPerator), la herramienta de facto que implementa este esquema de autenticación y que por tanto nos permitirá, con un sólo paquete, abrir un servicio oculto detrás de un firewall que por defecto deniega su acceso (INPUT a DROP). Básicamente por defecto el cliente mandará al puerto UDP 62201 un paquete cifrado con Rjindael (simétrico) o GnuPG (asimétrico), no reproducible y autenticado por medio de HMAC. Mientras, el servidor fwknopd estará esnifando el tráfico de forma pasiva mediante libpcap y, si el paquete es válido, ejecutará el iptables, PF o ipfw de turno para permitir el acceso al puerto durante el tiempo especificado.

Además, la cantidad de información que puede ser incluída en el paquete sólo se encuentra limitada por su MTU, es decir, además de la información de acceso también podríamos incluir en el paquete comandos que sean ejecutados en el servidor SPA. Y al usar un único paquete será más difícil de detectar y mucho más rápido. Todo ventajas.

Bien, ya nos hemos convencido de las bondades de fwknop y ahora nos preguntamos cómo hemos podido ser capaces de seguir con nuestras mundanas vidas sin utilizarlo... vamos a ponerle remedio...

En nuestro escenario de ejemplo vamos a configurar port knocking con SPA entre un servidor fwknopd en una máquina virtual con Kali Linux y un cliente fwknop en Windows 7 (so nativo). También y para más seguridad, usaremos cifrado asimétrico con claves GnuPG.

Lo primero que debemos hacer es generar un par de claves en cada máquina.

Generando las claves GnuPG en el cliente y en el servidor 

En el caso del cliente, si ya tienes una clave GnuPG para el correo electrónico (o cualquier otro) la podrás utilizar con seguridad porque sólo se usará para la firma de mensajes de fwknop. Si por el contrario todavía no la tienes, puedes crearla fácilmente con la herramienta Kleopatra que viene con Gpg4win (puedes ver un tutorial en este enlace):

Una vez creadas las claves, no olvides exportar tu clave pública a un fichero ascii:

Ahora le toca el turno al servidor fwknopd. En este caso si tendrás que crear una clave de GnuPG que se utilice exclusivamente para las comunicaciones de fwknop. La razón es que la contraseña utilizada para desbloquear esta clave debe estar almacenada en texto plano en el archivo /etc/fwknop/access.conf porque fwknopd la utilizará para descifrar los mensajes que hayan sido cifrados por el cliente fwknop con la clave pública del servidor. 

Es recomendable que el tamaño de la clave sea 2048 bits o menos porque les recordamos que los mensajes SPA deben caber en un sólo paquete IP.

root@kali:~# gpg --gen-key
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Vicente
Email address: hackplayers@ymail.com
Comment: 
You selected this USER-ID:
    "Vicente <hackplayers@ymail.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 283 more bytes)

gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 04E602A1 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/04E602A1 2014-01-20
      Key fingerprint = 4F3E 847C EE9B EB8C DFD4  F86E 467A CF40 04E6 02A1
uid                  Vicente <hackplayers@ymail.com>
sub   2048R/71374B8D 2014-01-20

Después de completar el proceso comprobamos que las claves se han generado con éxito:

root@kali:~# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/04E602A1 2014-01-20
uid                  Vicente <hackplayers@ymail.com>
sub   2048R/71374B8D 2014-01-20

Y también y al igual que con el cliente, exportamos la clave pública generada a un fichero ascii:

root@kali:~# gpg -a --export 04E602A1 > servidor.asc

root@kali:~# cat servidor.asc 
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

mQENBFLdoG4BCAC6Tz7R9tlpuGsUpt9r/OlcEK8QpsIC5BjtYAZuzBqoav8Ce4vH
1VbXtTPwYwqqj7MkCz79/RKTBfQN+2CyJzSXmLCShJ+W6py9K/sjPx4AWH9KFwHy
IUQowTQbD6LssOF/fJZjKxQhqZGc8McPAFvxTogRdUFMSF01augPM/iYqx27/TZL
MqVUnVR2v47PQ93Ge1wS6dh2qRKyrd+KWtMC7x3ZQAfqw6VEPQG3cWmS6is3mVdK
M7dYxicVJWG7tkAF9o0ZU7kJp/bQrs39IKUNjFosMHMnIq966E38sBNd6SOuUYN+
CVEArizrTieG7NTbWn/uosL+4PfX6/XDt1XnABEBAAG0H1ZpY2VudGUgPGhhY2tw
bGF5ZXJzQHltYWlsLmNvbT6JATgEEwECACIFAlLdoG4CGwMGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJEEZ6z0AE5gKhGJwH/Rr/SIZNEXNHhioh8Ufnv9uOMg74
+2XB2k7Icl2sB7vdGIyVKiC9nDVLHr0w2+fMddTyF7Q+JyNhepcHbwYNT025ol6J
V4TNiFRplfvoac3aOdzuga/LfYYax72OVYbJ/i5rMmFrCN1NXuXJPGMle6y2UYw8
LwTWqG1UCkXhn3zZ+cq3HlT4bugUmrW+uLwTs8ul3rZJOlOx0ZI7UDJ3UAmSG7cr
14FjNS5ypj1JDpCDd2es2c7OO554utMT7OIFQyIzCTDCBXe88eRd2hJM8/sQztge
+VXD1/3lrUWWbRRFEjRsTyBjayATgTTqMxnHOgbbd3m/EPe+sUKR/CzDYUm5AQ0E
Ut2gbgEIAJxbLq3urlQbEkxI0rTN2vrdRwYGyn4J+N+1zoNdXB9i2f6sfOWZrkmz
UnL+QL4SddE3op/c+YnYLk3lKVwTVUO5aiXANiVy4IkNqyT6JBJKK4nHHHwxS5g3
5aWwL9p4CDkul88KQB9k5aQa71/ftaZINSfXejnLSZIyWKLk+glTsZbzTuktLDjv
5f0F9ZAjd+nKL10d46GmstC63A8x87ZpFJfMsnEfRM0l3ZfRIcYyIaruPiisvH4s
1jaS+1CE5lyDWmRRfkEZ6VxFPsy+JL3YqlxGc0ycWx8QlOgn1DGfRi4FCBsWGR4T
TLR46Yu9ZWHwOIo3fRl41NIRLOLzPV0AEQEAAYkBHwQYAQIACQUCUt2gbgIbDAAK
CRBGes9ABOYCoc8SB/sEOJycx6p9JPwo/eN1PP9DDyBQ73ZIpgMTcRCg6fneJ8hq
4LoHMy5Y/o5+gwhwkZzv7lp7yeMP5CPD+7NQ/ggoWMOHRXXiwIWwfPBF94VCGaJk
GjLU9zsI0yWv6GXmzdgFw5zrkx9psLnuK/GipshBbvyc+0lK4HpMLWHAHtkFpW9q
bAZvFGNpmYa0uLBeScSJdXcEBA6eu9hUgZohP1zChXIlcYXdCSC3QOVBwt/qdQCg
PzUHdGGR7mhI15Fowug3hULhejH1La7hNeXBDQICC/BQWumu6wuc/T+Tz13WKnUR
imSmtFemZ7DtjDdj+gBefGopd5QnfT0//E/+Bj+S
=pBiY
-----END PGP PUBLIC KEY BLOCK-----
root@kali:~#

Una vez que hayamos creado las claves necesarias en el cliente y en el servidor, tendremos que intercambiar las públicas por scp (o por donde quieras) y firmarlas.

En el servidor importamos y firmamos la clave pública del cliente:

root@kali:~# gpg --import cliente.asc
gpg: key 68E338DE: public key "Vicente2 (Cliente) <hackplayers@ymail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

root@kali:~# gpg --edit-key 68E338DE
gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  2048R/68E338DE  created: 2014-01-20  expires: never       usage: SCE 
                     trust: unknown       validity: unknown
[ unknown] (1). Vicente2 (Cliente) <hackplayers@ymail.com>

gpg> sign

pub  2048R/68E338DE  created: 2014-01-20  expires: never       usage: SCE 
                     trust: unknown       validity: unknown
 Primary key fingerprint: 9757 064C 2B1B 843C 4ACB  401E 1545 3B76 68E3 38DE

     Vicente2 (Cliente) <hackplayers@ymail.com>

Are you sure that you want to sign this key with your
key "Vicente <hackplayers@ymail.com>" (04E602A1)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "Vicente <hackplayers@ymail.com>"
2048-bit RSA key, ID 04E602A1, created 2014-01-20

Y en el cliente importamos y firmamos la clave pública del servidor:

Instalando y configurando el servidor fwknopd

Una vez intercambiadas las claves, vamos a instalar y preparar fwknopd en el servidor:

root@kali:~# apt-get install fwknop-server libpcap-dev

Empezamos editando el fichero /etc/default/fwknop-server e indicamos que fwknopd se ejecute al inicio:

START_DAEMON="yes"

El siguiente paso será especificar el interface y el puerto a la escucha editando el fichero /etc/fwknop/fwknop.conf:

PCAP_INTF                   eth0; 
PCAP_FILTER                 udp port 62201;

 
Finalmente sólo nos queda configurar las directivas de /etc/fwknop/access.conf de tal manera que fwknopd use GnuPG para verificar y descifrar los paquetes SPA. Fíjate que el ID de la clave del servidor es 04E602A1 y el ID de la clave del cliente es 68E338DE:

SOURCE: ANY;
OPEN_PORTS: tcp/22;
DATA_COLLECT_MODE: PCAP;
GPG_REMOTE_ID: 68E338DE;
GPG_DECRYPT_ID: 04E602A1;
GPG_DECRYPT_PW: password123;
GPG_HOME_DIR: /root/.gnupg;
FW_ACCESS_TIMEOUT: 60;

Probando el acceso al servicio ssh mediante SPA

Si habrás seguido estos sencillos pasos ya tendrás todo el entorno montado. Para probarlo vamos a arrancar fwknopd y configurar el firewall del servidor con una política por defecto de denegación en la entrada:

root@kali:~# service fwknop-server start 

root@kali:~# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
root@kali:~# iptables -A INPUT -i ! lo -j DROP

Como puedes comprobar, el acceso al puerto SSH desde el cliente está inicialmente cerrado:

C:\Users\vmotos>nmap -p 22 192.168.225.129

Starting Nmap 5.51 ( http://nmap.org ) at 2014-01-21 00:57 Hora estßndar romance

Nmap scan report for 192.168.225.129
Host is up (0.00s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh
MAC Address: 00:0C:19:8D:52:DC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 3.55 seconds

Ahora tendremos que generar y enviar desde el cliente el paquete SPA correspondiente. Para ello utilizaremos Morpheus, un IU para Windows escrito por Daniel López que además es de código abierto.

Como verás en el siguiente pantallazo, su configuración no puede ser más simple. Especificaremos el puerto y la dirección IP que podrá acceder a fwknopd, el tipo de cifrado PGP y la ruta de la clave privada del cliente y la clave pública del servidor:

Al introducir la frase de paso enviaremos el paquete SPA y, casi por arte de magia, el puerto 22/TCP del servicio SSH se abrirá durante el perido de tiempo especificado:

Puedes comprobarlo volviendo a escanear el puerto:

C:\Users\vmotos>nmap -p 22 192.168.225.129

Starting Nmap 5.51 ( http://nmap.org ) at 2014-01-21 01:12 Hora estßndar romance

Nmap scan report for 192.168.225.129
Host is up (0.00038s latency).
PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 00:0C:19:8D:52:DC (VMware)

Nmap done: 1 IP address (1 host up) scanned in 3.23 seconds

C:\Users\vmotos>

Y bueno, para terminar verificamos el log en el servidor...

root@kali:~# tail -f /var/log/syslog | grep fwknop

Jan 20 19:00:47 kali fwknopd[13583]: SPA Packet from IP: 192.168.225.1 received.
Jan 20 19:00:48 kali fwknopd[13583]: Added Rule to FWKNOP_INPUT for 192.168.225.1, tcp/22 expires at 1390262508
Jan 20 19:01:48 kali fwknopd[13583]: Removed rule 1 from FWKNOP_INPUT with expire time of 1390262508.

...  así como las reglas de iptables creadas:
 

root@kali:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
FWKNOP_INPUT  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FWKNOP_INPUT (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  192.168.225.1        anywhere             tcp dpt:ssh /* _exp_1390262645 */

Sencillo ¿verdad? 

¿A qué hora llamarás a las puertas de tus servicios más sigilosamente? ;)

 
Fuentes: 

- Single Packet Authorization - A Comprehensive Guide to Service Concealment with fwknop
- fwknop: Single Packet Authorization y port knocking
- Firewall improvement with fwknop  
- Fwknop versus Knockknock
- SinglePacketAuthorization