Los años locos de la seguridad informática: De la camiseta prohibida al virus de una sola línea de código

Las líneas de código (es decir, los programas de computadores o el software) perfilan el mundo actual, de esto no hay duda. Desde un microondas, relojes, teléfonos, pasando por diferentes vehículos que usamos a diario como aviones, coches, etcétera, hasta complejas instalaciones como por ejemplo las centrales nucleares, hospitales (y su instrumentación) o fábricas, dependen de un programa de un ordenador. Y toda esta, digamos, dependencia y expansión, empezó justo después de la invención del primer microprocesador, el Intel 4004 en 1971, y desde entonces el software ha ido ocupando un sitio destacado y fundamental dentro de la tecnología y a su vez, de la sociedad.

Figura 1: Los años locos de la seguridad informática: 
De la camiseta prohibida al virus de una sola línea de código

Esto no quiere decir que antes no hubiera programas (de hecho, en este artículo aparecen algunos anteriores a esa fecha) ya que el primer, digamos “código”, se creó en 1715 … ahí lo dejamos ;) . En nuestro libro “Microhistorias: anécdotas y curiosidades de la historia de la Informática (y los hackers)” aparecen más historias como estas, tanto de ciberseguridad como de la informática y hackers en general.

Figura 2: Libro de "Microhistorias: anécdotas y curiosidades
de la historia de la informática (y los hackers)"

En este artículo hemos seleccionado algunos fragmentos de código que, de alguna u otra manera, han tenido impacto en el mundo de la seguridad informática y casi podríamos decir que en la sociedad. Desde instrucciones erróneas en vehículos espaciales que había que hacer un “bypass” (como el caso del Apolo 14) pasando por el curioso caso de la camiseta prohibida y el código de cifrado RSA, harán acto de presencia en este texto. Vamos a verlos un poco más en profundidad.

Sobrecarga (overflow) y engaño (deception) en el software del Apolo 11 y 14

En ambos viajes espaciales, un programa de ordenador estuvo a punto de echar al traste toda la misión. No fueron un problema técnico del vehículo, sino una mala interpretación de una señal en un caso y un error de programación o de interpretación de señales en el otro.

En el caso de la misión Apolo 11, a pocos minutos de aterrizar en la Luna, Buzz Aldrin dejó activo un radar del vehículo LEM que desbordó de información (overflow) el ordenador, activando las alarmas 1201 y 1202 que casi terminan con la misión. Menos mal que Margaret Hamilton y su equipo tenían previsto este contratiempo (esas alarmas indicaban justamente este problema de sobrecarga) y lo tenían bajo control.

Por otro lado, en el viaje del Apolo 14, también hubo un problema, esta vez relacionado con una señal de abortar que no debía de estar activa. En este caso fue Don Eyles, uno de los miembros del equipo de Margaret quien lo solucionó realizando un “bypass” o engañando al sistema. Tienes toda la historia al detalle en este enlace que publicamos.

Figura 3: Sección del código del fichero EXECUTIVE.AGC donde aparece la activación de la alarma 1202

En la imagen de la Figura 3 se puede apreciar la porción de código que activaba la alarma 1202 del Apolo 11 (el código fuente al completo está en GitHub). Una explicación a fondo de esta alarma y su funcionamiento la puedes encontrar en este enlace.

El gusano de Morris, el primer ataque a la red Internet

El 2 de noviembre de 1988, un joven estadounidense de 23 años, llamados Robert Tappan Morris, creó el primer malware de tipo gusano (programado en Lenguaje C) que provocó, según él, por accidente, el mayor ataque a la red Internet de la época. El 10% de los ordenadores conectados, unos 6.000 la mayoría servidores, provocando el mayor ataque tipo DoS de la historia (hasta ese momento).

El programa explotaba un agujero de seguridad en el modo debug del clásico programa de Unix llamado sendmail (el cual se ejecuta en el sistema operativo a la espera de recibir conexiones para recibir emails) y “bug” en el daemon del comando/protocolo finger, fingerd (encargado de gestionar dichas peticiones). Antes de infectar otro ordenador, el gusano comprobaba si estaba presente. En caso afirmativo, el gusano lo volvía a infectar una de cada siete veces (esto lo hacía por si acaso había otro gusano Morris modificado en ejecución y así sustituirlo).

Figura 4: Parte del código fuente del gusano encargado de probar
diferentes contraseñas por defecto para acceder a los servidores

Esto provocó que muchos usuarios se infectaran demasiadas veces por el malware, llegando a colapsar la máquina, dejando de funcionar. Hoy día Robert Morris es profesor de Informática en el MIT. En este enlace puedes ver el código fuente completo y en este otro un análisis en profundidad del mismo.

El virus de una sola línea (bomba fork)

La siguiente línea de código, en Bash, era capaz de bloquear o colgar un ordenador en versiones antiguas de Unix y muy posiblemente en algunos actuales con GNU/Linux, así que ten cuidado en ejecutarlo:

:(){ :|:& };:

bomb(){

bomb | bomb &

}
bomb

Figura 5: Bomba fork en Bash en una sóla línea Bash y abajo en formato más legible

Una bomba fork es un tipo de ataque cuyo objetivo es provocar una denegación de servicio, creando otros procesos (en concreto, a llamadas del sistema o system calls) de forma recursiva, colapsando la memoria del ordenador. Lo que hace especial este ataque, además de su extrema sencillez, es que demuestra la gran debilidad de los complejos informáticos actuales.

La bomba fork de una sola línea es una obra maestra de la programación ofuscada, aquí tienes una brevísima descripción de su funcionamiento:

1. “:()” significa que está definiendo una función llamada “:” 

2. “{:|: &}” significa ejecutar la función “:” y enviar su salida a la función ”:” de nuevo y ejecutarla en segundo plano. 

3. Dentro de la sección del punto 2 ocurre lo siguiente:

• “:” carga otra copia de la función “:” en memoria 

• “|” y hace un “pipe” de su salida hacia … 

• “:” otra copia de la función “:” la cual se tiene que cargar en memoria 

• Por lo tanto, “:|:” carga dos copias de ':' cada vez que se llama a “:” 

• “&” mata a las funciones, si la primera “:” es destruida, todas las funciones que ya se han iniciada no serán eliminadas. 

• “}” fin desde el “:” inicial

4. “;” separador de los comandos 

5. “:” ejecuta la función por primera vez

El código del cifrado RSA el Perl que se prohibió exportar … hasta en camisetas

El Gobierno de los Estados Unidos, durante un periodo de tiempo, aplicó un tratamiento casi de armamento militar a cualquier tecnología relacionada con el cifrado de información. Hasta ese momento, toda esta tecnología que rodeaba a cualquier dispositivo era costoso de implementar y programar. Hasta que apareció el algoritmo RSA de cifrado (el que es uno de los bloques fundamentales de la criptografía actual)

Figura 6: Libro de Cifrado de las comunicaciones digitales:
De la cifra clásica a RSA (2ª Edición) de 0xWord.

Este algoritmo se podía escribir en cuatro simples líneas de Perl y cualquier empresa, o particular podía, desde ese momento, y de manera sencilla utilizar sistemas de cifrado de alta seguridad en cualquiera de sus programas, lo que permitía añadir capas de seguridad a todas las partes de los sistemas de seguridad.

Figura 7: Código Perl del algoritmo de cifrado RSA en 4 líneas de código

En ese momento no se podía exportar fuera del país este tipo de código por Internet, pero claro, ahora era lo suficiente pequeño como para poder meterlo, por ejemplo, en una camiseta. Y eso fue exactamente lo que pasó, la gente comenzó a imprimirlo en camisetas (las originales se han convertido en objetos de coleccionistas, si lográis encontrarla) y esta forma poder exportarlo y venderlo por todo el globo. En la camiseta aparece el siguiente texto:

“WARNING: This shirt is classified as a munition and may not be exported from the United States, or shown to a foreign national”

El problema es que estas camisetas también se prohibieron, e incluso hoy día es posible que te paren en alguna aduana estadounidense si la llevas puesta (aunque estas restricciones están técnicamente retiradas). Eso sí, siempre te lo puedes tatuar donde quieras…

Figura 8: Parte delantera de la camiseta donde se aprecia el código en Perl y también el mensaje de prohibición

Este no fue el único caso, también podemos encontrar otro como el de DeCSS (cifrado de los DVD), el cual también se imprimió en una camiseta y fue incluso a juicio.

Y muchos más...

Hay muchos más programas interesantes relacionados con la ciberseguridad (que os contaremos siempre que os haya gustado este artículo) de los cuales, además de lo curioso y su valor histórico, podemos aprender mucho de ellos. Desde errores de programación trágicos (como el caso de Therac-25, que provocó la primera muerte “por código”) hasta malware clásico como por ejemplo Conficker, el gusano que infectó millones de ordenadores, entre muchos otros. Pero amigos, esas son otras Microhistorias … ;)

Happy Hacking Hackers!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

Brosec: Una mochila de pentester para almacenar payloads y personalizarlos automáticamente

Brosec es una herramienta que permite utilizar y generar diferentes payloads en diferentes ambientes o escenarios. Es decir, cuando estamos en plena auditoria o pentesting podemos necesitar código ejecutable en distintas plataformas. Brosec reúne esos códigos o scripts necesarios para poder explotar debilidades y vulnerabilidades. Está escrito en Nodejs y permite generar y configurar shells inversas en lenguajes como Python, Perl, Powershell, etcétera. Pero sin dejar de lado algunas otros payloads para web o, incluso, exfiltration data como pudimos ver en el pasado con DET.

Figura 1: Brosec: Una mochila de pentester para almacenar payloads y personalizarlos automáticamente

Brosec puede ser descargado desde su Github. Una vez descargado con git clone, necesita instalar una serie de dependencias para poder ser ejecutado correctamente. En primer lugar debemos ejecutar npm config set registry http://registry.npmjs.org. Posteriormente, se debe ejecutar npm install –g n. A posteriori, n latest. Para finalizar npm install y tendremos disponible la consola de Brosec.

Figura 2: Proceso de instalación de Brosec

Brosec tiene dos modos de ejecución. Con el primero se le pueden pasar por parámetro las acciones a realizar. Con el segundo, se puede ejecutar sin más el binario y acceder a un menú dónde se nos indican diferentes acciones, tal y como se puede visualizar en la imagen siguiente. Las opciones que tenemos disponibles en Brosec son:

Figura 3: Menú de opciones de Brosec

En la parte de (1) Information Gathering nos podemos encontrar la posibilidad de crear código en distintas plataformas para recopilar información de un sistema. En el caso de (2) Linux y (3)Windows tenemos la posibilidad de crear código Powershell, Python, WMI, etcétera, con el fin de ejecutar y obtener beneficio en la máquina. En el caso del apartado (4)Web, podemos generar payloads para SQLi y XXE. En (5) Miscelánea, podemos generar shells inversas en diferentes escenarios. El que quizá más me haya llamado la atención es haga uso del popular entorno AWK, el cual es una herramienta potente para el exploiting de sistemas GNU/Linux.

Brosec tiene un apartado de configuración, al cual se puede acceder ejecutando config sobre la línea de comandos. Para poder configurar parámetros como LHOST, LPORT, RHOST, RPORT, PATH, USER se debe indicar set [parámetro] [valor]. Estos parámetros se utilizarán cuando Brosec genere Pyaloads que los necesiten.

Figura 4: Configuración de parámetros en Brosec para los payloads

Ejemplo: Creando payloads en Powershell

Si elegimos la opción de plataforma Windows podemos ver diferentes opciones. Cada categoría genera acciones interesantes que se pueden ejecutar en esos ámbitos de Windows. Por ejemplo, si pulsamos sobre System Info podremos generar instrucciones o comandos útiles para obtener información en un sistema Windows. Esto también nos puede servir de biblioteca en un pentest. Hay que tener en cuenta que Brosec se encuentra en la versión 0.0.1, por lo que el proyecto está comenzando, pero ya dispone de una gran serie de acciones que se pueden generar y que pueden ayudar a un pentester en un proceso de ethical hacking.

Figura 5: Opciones del menú Windows en Brosec

Para ver un ejemplo, si pulsamos sobre el (5) de Powershell podemos visualizar las opciones que nos ofrecen. Como podemos ver en la imagen siguiente, tenemos el código que debemos ejecutar en una Powershell, o lo que puede ser mejor, en un payload que ejecuta una Powershell, en Metasploit tenemos alguno. Las opciones que nos proporcionan pueden ser interesantes si queremos descargar algún script o funcionalidad concreta y no podemos meterla en el equipo de otra manera.

Figura 6: Código disponible para configurar el payload con Brosec

Como se puede ver a continuación, tenemos un script creado. En este caso el script resultante se descargará código en remoto del parámetro URI que le hayamos indicado.

Figura 7: Payload generado con Brosec

Esta funcionalidad es muy interesante, y se pudo comprobar con la P.o.C. de PSBot, el poder que proporciona una Powershell a la hora de evadir firmas de soluciones antimalware y la posibilidad de ejecutar código de forma dinámica.

Ejemplo: Creando un HTTP Simple y FTP Fast

En algunas ocasiones es necesario montar un servidor HTTP y un FTP. En el lenguaje Python se dispone de SimpleHTTP y en Brosec se proporciona la forma de montar un servidor web de forma, casi, aún más sencilla. Para ver la facilidad de crear o disponer un servidor HTTP y FTP se pueden ver las siguientes imágenes.

Figura 8: Configurando un servidor HTTP con la aplicación bros

Como se puede apreciar, se invoca la aplicación bros y se pasa como parámetros http o ftp. En el caso del ftp se puede utilizar para la exilftración de datos en una organización.

Figura 9: Configuracndo un servidor FTP con bros

Ejemplo: Reverse Shells

Generar código de shells inversas puede ser muy útil, por ejemplo para exiltrar datos o para proporcionar el control remoto de una máquina fuera de los dominios de la organización durante la realización del pentesting. A continuación se muestran, como en el apartado (5) Miscelánea, se pueden conseguir diferentes tipos de códigos, en distintos lenguajes, con el objetivo de crear sesiones inversas.

Figura 10: Reverse shells disponibles

Aparte de las shells inversas, podemos ver el código que se puede obtener para exfiltrar datos. Se utiliza Python, principalmente. En algunos casos la herramienta genera instrucciones poco reales o poco usables. Si observamos en el caso (3) para descargar o subir un archivo vía SCP podría ser detectado por cualquier sistema de protección. Por otro lado, el uso de DET frente a Brosec como herramienta de exfiltración de datos no tiene ningún color. DET está mucho más orientada a no ser detectada.

Figura 11: Opciones de Exfiltración en Brosec

En el apartado (4) Web podemos encontrar payloads o instrucciones de ejecución para vulnerabilidades XML y SQLi. No muy extensa esta parte por ahora.

Figura 12: Opciones de explotación de vulnerabilidades web 

Como se puede ver Brosec aporta cierto conocimiento y comandos e instrucciones que pueden ser útiles en un momento dado. El objetivo de la herramienta es personalizar los parámetros en los casos necesarios y aportar el conocimiento en un momento dato que sea necesario.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”

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)

Averiguar la versión de un SQL Server

Para este día de Navidad, Nelson Brito (@nbrito) tenía preparada una nueva versión de SQL Fingerprinting Next Generation, una herramienta de la que ya os había hablado aquí para hacer Fingerprinting a servidores SQL Server. Como yo también soy un enganchado a esto del hacking y las tecnologías, aproveché el día de Navidad para probar la herramienta, así que igual que hice en la anterior ocasión, escanee unos segmentos buscando servidores SQL Server con el puerto 1433 abierto en Internet y lancé la herramienta.

Figura 1: Buscando servidores SQL Server con el puerto 1433 abierto a Internet

Esta versión está escrita en Perl y según cuenta en la descripción, es capaz de reconocer más de 500 versiones distintas de SQL Server con su Service Pack y conjunto de parches de actualización instalados. Basta con invocarlo con el nombre del fichero en Perl y la dirección IP a realizar el proceso de fingerprinting para obtener una versión y un grado de porcentaje de certidumbre, tal y como se ve en la figura 2.

Figura 2: MS SQL Server 2008 R2 RTM descubierto con ESF.pl

Si se quiere conocer el nombre del servidor SQL Server en la red, hay que establecer una cadena de conexión y analizar la respuesta, tal y como ya vimos en "Cómo conocer el nombre de un servidor SQL Server con una cadena de conexión". En esta herramienta, basta con utilizar la opción -d  de debug, y analizar la respuesta obtenida. En la Figura 3 ZitrXXXXX7C1.

Figura 3: Modo debugging de la herramienta. Permite averiguar el nombre del servidor SQL Server

Tal vez hubiera sido más cómodo que el nombre del servidor saliera en la respuesta por defecto de la aplicación al hacer el proceso de fingerprinting, pero hay que reconocer que parece funcionar muy bien con diferentes versiones de SQL Server.

Figura 4: Servidor MS SQL Server 2008 SP3 descubierto con ESF.pl

Para descubrir los servidores SQL Server en una red, además de hacer el escaneo con nmap que os he puesto en este ejemplo, se puede utilizar un escaner IPv6 como Topera para descubrir qué equipos están respondiendo por ese puerto, o utilizar trucos como la creación de un DSN en una red local o herramientas de administración como MyLittleBackup. La herramienta merece tenerla en cuenta para analizar las versiones de SQL Server, así que tenla presente en tu próximo pentesting.

Saludos Malignos!

No le vemos problema alguno a los reportes que nos envías

Hace unos dias, revisando unos scripts que realicé en Perl decidí adaptarlos con algunos modulos a una pagina shtml. Tenía montado un servidor Apache corriendo en mi maquina, aceptando scripts en CGI para poder probar las salidas que realizaban desde el servidor hasta el cliente. Decidí buscarme un alojamiento que me brindara la posibilidad de programar Perl en el servidor contratado.

Para mi sorpresa, al ejecutar uno de los scripts que subo descubro que tengo mas privilegios en el servidor desde mi cuenta gratuita de los que me esperaba. Tas reiterados correos electrónicos a la compañía durante dias advirtiéndoles de algunos errores en sus configuraciones, y la única respuesta que recibo es:

//No le vemos problema alguno a los reportes que nos envías//

Como no sé si esto es una cosa solo en mi cabeza, os paso algunos de los los reportes que he enviado que no son considerados como problema:

Reporte 1:

Esta empresa como muchas otras tiene un Panel de Control donde el cliente mantiene un usuario y una contraseña para acceder desde la pagina web del proveedor a sus servicios - facturaciones, dominios contratados, espacio contratado, etc. - y paralelamente acceso a su Cpanel para la configuración de sus servicios dado por otro usuario y otra contraseña.

Figura 1: Información en datos de cuenta

En el primer reporte podemos comprobar como en el Panel de Control del Site podemos ver en texto plano el usuario y la contraseña que da acceso al Cpanel de la configuración de todo nuestro sitio. ¿Realmente es un problema?¿Un error?¿Es normal? Si lo es no se porque tener dos usuarios y dos contraseñas distintas de acceso.

Reporte 2:

Programe un script que listase en una tabla los archivos de un directorio dado con su enlace, pero al hacerlo se me olvidó indicar el directorio a listar. Como aún no tenia claro qué directorios iba a emplear configuré un simple my $dir = '../'; con lo que me dí cuenta de la mala gestión del administrador del sitio.

Figura 2: Ejecución de un listado de ficheros desde Perl

Fue entonces cuando me picó en la nuca ese gusanillo que te hace la tipica pregunta de “¿Y si…?” Pues si. ¿Y si pruebo todo lo que puedo obtener de aquí para tener los suficientes argumentos y que la empresa a la que no le debo nada proteja a sus clientes? Por lo menos los clientes que tengan cuentas que estan pagando un dinero por tener sus ficheros protegidos.

Tras eso cree distintos scripts en Perl que ejecutaban comandos en el sistema. Y estos son los resultados.

Figura 3: Salida de un comando df -h

Figura 4: Salida de un cat /etc/passwd

Sin extenderme más, he de decir que abandono mi cuenta en este hosting, porque no me gustaría que cualquier pudiera acceder al código de mis programas, así que mejor no usar este servidor.

Terminando con este llanto a gritos

Llevo mas de dos semanas intentando de buena fe contactar por todos los medios con esta empresa que suministra espacio protegido a la gente. Me he tomado las molestias de recopilar todo tipo de información para que se guíen a la hora de ver qué ocurre, moletandome para nada, porque la única respuesta ha sido:

//No le vemos problema alguno a los reportes que nos envías//

Pues vale, sin problemas, aquí queda escrito, saludos a http://www.host-ed.net/ por la colaboración aen este articulo.

Saludos
Miguel Francisco Morata