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