Empujando a Latch fuera de Matrix

Acabé el 2013 diciendo sobre Latch que me parecía la mejor idea ese año y, después de conocerlo, lo hemos implantado en nuestras vidas cotidianas protegiendo archivos, servicios, cuentas bancarias, identidades digitales ..etc..

Son varias las características que nos atraen de esta herramienta: su fácil manejo, su cuidada estética, su genial simpleza... Pero si hay algo con el que nos tuviéramos que quedar sería su flexibilidad. Esta es la cualidad que te hace pensar y te divierte... y sin duda su mayor activo de cara al futuro (desde la humilde opinión de un servidor).

Y también es  la razón que te lleva a ...¿por qué no?.. empujarlo a otro plano para el que fue concebido (que me perdonen Eleven Path), sacarlo del plano virtual y permitirme un par de hacks (esto es Hackplayes no?)...

Las dos prácticas que propongo son muy simples en cuanto a su desarrollo y a un muy bajo coste. Aunque como siempre lo podemos complicar o desarrollarlas muchísimo más.

Para este pequeño laboratorio vamos a necesitar:
- Latch
- Unos pequeños conocimientos de electrónica
- Y nociones de programación PIC.
  
En la primera vamos a dotar mediante Latch de una capa extra de seguridad a una puerta electrónica.
Y en la segunda vamos a utilizar Latch a modo de telemando, inicializando una acción automatizada.

Os dejo todos los archivos necesarios aquí. Aunque lo mejor sería bajaros el repositorio en vuestra carpeta preferida :

git clone https://tosesoscuervos@code.google.com/p/latches/ 

Dado que vamos a necesitar un servidor para la parte informática y éste va a estar alejado cierta distancia del objetivo final, vamos a hacer un simple control por bluetooth que paso a explicar en breve (aunque podríamos hacerlo por cable, pero la entrada no sería ni la mitad de efectista).

Parafraseando a MASTERCARD:

Un pic 16f628a: 2,5 euros.
Modulo bluetooh hc06: 4 euros
Resistencia 100K ohmios:  0,20 euros
Un transistor:  0,60 euros
Un relé: 1 euro

Poder encender cualquier cosa por bluetooth .....no tiene precio.

La idea es sencilla tenemos un servidor que comprueba el estado de Latch. Si Latch esta ON manda una señal por bluetooth a nuestro módulo el cual cierra un contacto del relé. 

Para que este simple circuito funcione necesitamos programar el pic 16f628A. Esto lo llevaremos a cabo con la herramienta MPLABX.

También necesitaremos  un puerto serie y un programador pic.

Yo he utilizado uno que estaba dando vueltas ya unos años por casa, el stm1, pero podéis utilizar el que mas os guste.
Para el que no este familiarizado hay
mucha información de como utilizar este programador, no es nada complejo.

PROGRAMADO DEL PIC 

Un PICmicro es un circuito integrado programable.Programable quiere decir que se puede planificar la manera como va a funcionar, que se puede adaptar a nuestras necesidades. El integrado es capaz de modificar su comportamiento en función a una serie de instrucciones.

En otras palabras; tenemos un pequeño ordenador con 35 instrucciones a 1MHZ  (utilizando su oscilador intern , si optamos por un oscilador externo podemos multiplicar la velocidad x5) en el pulgar de nuestra mano. 

El pic16f628a es un microcontrolador de 8 bit, posee una arquitectura RISC avanzada así como un juego reducido de 35 instrucciones , capacidad de interrupción y una pila de 8 niveles. Este microcontrolador es el reemplazo de mi querido pic16f84a.

Lo que lo hace más interesante:

• opciones de oscilador externo e interno:
     - Precisión de fábrica del oscilador interno de 4 MHz calibrada a ± 1%
     - oscilador de 48 kHz De bajo consumo interno
• Modo de ahorro de energía en modo sueño
• resistencias programables pul-ups del PORTB
• Multiplexado del pin reset / Entrada-pin
• Temporizador Watchdog con oscilador independiente para un funcionamiento fiable

EL PROGRAMA  

Para nuestra prueba de concepto bastará con un simple código. Dejo en el repositorio los formatos C, HEX y ASM.

Mi consejo, si no os queréis complicar mucho, es que abráis el archivo .HEX con icprog (windows) por ejemplo o MPLABX (en linux) y "queméis" el PIC directamente.

Si queréis compilar el código desde C tendréis que utilizar CCS  compiler.

PREPARANDO LA COMUNICACIÓN CON EL MODULO BLUETOOTH
  

Poc de nuestro Modulo BT

apt-get install bluez minicom 

Para comunicarnos con nuestro módulo bluetooth deberemos preparar un puerto de comunicación y más tarde emparejarnos; lo cuál haremos desde la consola. 

Abrimos una consola y escaneamos para encontrar nuestro dispositivo y determinar el canal

Con estos datos editamos /etc/bluetooth/rfcom.conf y lo dejamos de la siguiente manera:

#
# RFCOMM configuration file.
#

#rfcomm0 {
#       # Automatically bind the device at startup
#       bind no;
#
#       # Bluetooth address of the device
#       device 11:22:33:44:55:66;
#
#       # RFCOMM channel for the connection
#       channel 1;
#
#       # Description of the connection
#       comment "Example Bluetooth device";
#}
# HC-06 98:D3:31:20:09:18
rfcomm1 {
bind yes;
device 98:D3:31:20:09:18 ;
channel 1;
}

Guardamos y reiniciamos el bluetooth:

/etc/init.d/bluetooth restart

y ahora emparejamos el dispositivo:

hcitool cc 98:D3:31:20:09:18; hcitool auth 98:D3:31:20:09:18
Nos pedirá el pin de emparejamiento. Por defecto y en mi caso es 1234 (luego por cuestión de seguridad lo cambiaremos).

Sencillo, ¿no? 

CAMBIANDO LA CONFIGURACIÓN DEL MODULO BLUETOOTH  

Para cambiar la configuración que trae el modulo bluetooth HC-06 necesitaremos que no este emparejado y conectarlo por usb mediante un usb serial. No es necesario para nuestro pequeño taller, pero os dejo la info por si alguno la necesitase. Desde aquí podemos cambiar parámetros como el pin por defecto, nombre del dispositivo ...etc. 

El módulo HC-06 acepta un set muy básico de comandos (algo raros por cierto) que permite pocas configuraciones, pero que sin duda será útil para personalizar este económico módulo y configurarlo para satisfacer las necesidades de la aplicación.
Los comandos que soporta son:

• Prueba de funcionamiento:
  • Envíar: AT
  • Recibe: OK

• Configurar el Baudrate:
  • Envíar: AT+BAUD<Numero>
  • El parámetro número es un caracter hexadecimal de ’1′ a ‘c’ que corresponden a los siguientes Baud Rates: 1=1200, 2=2400, 3=4800, 4=9600, 5=19200, 6=38400, 7=57600, 8=115200, 9=230400, A=460800, B=921600, C=1382400
  • Recibe: OK<baudrate>

• Configurar el Nombre de dispositivo Bluetooth:
  • Envíar: AT+NAME<Nombre>
  • Recibe: OKsetname

• Configurar el código PIN de emparejamiento:
  • Envíar: AT+PIN<pin de 4 digitos>
  • Recibe: OK<pin de 4 digitos>

• Obtener la versión del firmware:
  • Enviar: AT+VERSION
  • Recibe: Linvor1.8

Si ya hemos trabajado con comandos AT observaremos que los comandos están lejos del estándar, lo más obvio es que:

• No es necesario finalizar el comando con \r\n, pero si es necesario ingresar los comandos con todos los caracteres seguidos sin pausas. NO hay necesidad de dar “enter” para finalizar un comando. El modulo tiene un Temporizador que hace necesario introducir el comando de una sola vez, sin pausas entre los caracteres.
• Por lo anterior, si utilizamos un emulador de terminal hay que pegarlos en leste y no escribirlos uno a uno con el teclado.
• Hay que tener cuidado de introducir TODAS LAS LETRAS DEL COMANDO en MAYÚSCULAS, ya que de lo contrario, no funcionarán.
• Las respuestas no parecen respuestas estándar a comandos AT.

EL SERVIDOR  

Ya tendríamos preparado nuestro pequeño ingenio de control a distancia. Os recuerdo que no es del todo necesario porque podemos hacerlo directamente por cable desde el server, pero creo que sera útil y entretenido y aparte nos confiere una gran versatilidad..

Como solución portable y económica para el server podríamos usar una Rasberry pi...con Raspbian, por ejemplo. 

Pasamos a la parte del servidor. Para esta fase lo que haremos será aprovechar alguna que otra entrada de las que ya vimos en Hackplayers con algún que otro retoque...

Con el fin de no ser muy extenso no voy a explicarlo del todo. No es nada que no hayamos visto antes en el blog por lo que, mirando los scripts y releyendo alguna entrada nos debería bastar para comprender el funcionamiento. 

Para instalar nuestro peculiar server; en el proyecto tenéis un script de instalación y unos bonitos README (que nunca leemos), situados en la carpeta server. Así que abrir la consola y typear: 

chmod +x Install.sh
./install.sh 
Y recibiremos un 'Done'.

Cuando tengamos que arrancar el servicio o pararlo:

/etc/init.d/latcheserver start
/etc/init.d/latcheserver stop

La función del server es comprobar el estado de nuestros latches cada 30". Se puede retocar este tiempo en el script timer.sh que una vez instalado se encuentra en vuestra carpeta /bin. 

PROBANDO EL CONJUNTO LATCH-BLUETOOTH

Lo primero que necesitaremos en una cuenta de desarrollador en https://latch.elevenpaths.com/www/.

Luego crearemos nuestra aplicación en el server de latch lo cual nos dará nuestro aplication ID y el secrect

Después iremos a nuestra carpeta /home/Hackplayers y arrancaremos reg.sh y le proporcionaremos el application ID y el SECRET...

Arrancaremos latcheserver

/etc/init.d/latcheserver start

Y vemos el resultado... 

A partir de aquí ya solo nos para nuestra imaginación...

PRACTICA Nº1

Implementamos Latch más aun en nuestra vida. Todos conocemos esas puertas de cochera que van con mandos RF, si eres un paranoico y no duermes tranquilo pensando en esos barredores de frecuencia que abren las puertas como cuchillo caliente la mantequilla tu solución es Latch!!

En el esquema presento el conexionado que integra nuestro controlador con la puerta. De manera que para abrirla tenemos que tener permiso previo del servidor de Latch, el cual controlamos desde nuestro smartphone con la aplicacion de Latch..

Cabrían más posibilidades como no actuar sobre el mecanismo de apertura y que Latch solo fuese un "chivato" y nos avisara al móvil cada vez que la puerta abriese.

PRACTICA Nº2

Son las 4 de la tarde agosto y recordamos que no hemos regado nuestras "plantas". Como es obvio no las tenemos próximas a nosotros e imaginemos que por cuestiones legales las tenemos a unos cuantos cientos de kms o nos hemos ido de turismo a Japón. 

Estaría bien poder regarlas desde el móvil ¿no?...Latch nos confiere una gran capacidad de comunicación siempre y cuando tengamos una conexión a Internet. Vamos a aprovecharla:

CONCLUSIÓN

Visto que con muy poco dinero, media neurona y la versatilidad que nos ofrece Latch, podemos incluir sus cualidades en nuestros proyectos de andar por casa.

Lo importante de ésto es ver el horizonte que nos puede ofrecer esta herramienta, que no tiene por que quedarse ahí,  sino que con algo de  imaginación podría ofrecer infinidad de servicios...



Fuente

Análisis de un 0-day de Buffer Overflow en BASH 4.3

Un día con tiempo, te pones a revisar código de diversas aplicaciones. Muchas veces vas con la idea de que no encontraras ninguna vulnerabilidad, pero claro, ningún código o programa es perfecto. ¿Qué pasaría si encuentras un 0 Day mientras te paseas por el código fuente de la ultima versión de alguna aplicación? Eso me paso a mi hace unos días, y en este artículo analizaré ese mismo 0 Day que encontré en la última versión disponible de BASH la 4.3 y explicaré un poco el proceso que seguí para crear un exploit en Linux.

1.- Creación del laboratorio

Voy a explicar todo el proceso que hice para saber que impacto tenia mi descubrimiento y como podría ser aprovechado si era posible. Nuestro entorno controlado será un pequeño “laboratorio” que utilizara: · VirtualBox + Guest Additions por mayor comodidad. En él instalé una imagen de Ubuntu Desktop 14.04.1 LTS arch:i386.

Figura 1: Instalación de Ubuntu 14.04 sobre Virtual Box en el laboratorio

Una vez configurada e instalada la imagen sobre VirtualBox, instalamos las Guest Additions para una mayor comodidad con el entorno. ¿Por que hacemos esto? Pues simplemente para que si se nos va de las manos, no salpique a nuestro sistema operativo de uso diario y así evitar posibles futuros problemas. 

2.- Descargar y analizar el código vulnerable

Para descargar la aplicación usaremos el comando apt-get o en su defecto aptitudepara descargar el código fuente mediante el uso del parámetro source de la siguiente manera: 

Figura 2: Descarga del código de fuente de bash con apt-get

Ahora ya podemos pasar a analizar el código vulnerable que esta alojado en la siguiente ruta: bash4.3ubuntu1.tar\bash-4.3\lib\sh\unicode.c linea 65: 

static char charsetbuf[40];


static char *stub_charset ()
{

char *locale, *s, *t;

 locale = get_locale_var ("LC_CTYPE");
if (locale == 0 || *locale == 0)
{

strcpy (charsetbuf, "ASCII");
return charsetbuf;

}
s = strrchr (locale, '.');
if (s)
{

strcpy (charsetbuf, s+1);
t = strchr (charsetbuf, '@');
if (t)
*t = 0;
return charsetbuf;

}
strcpy (charsetbuf, locale);
return charsetbuf;

}


Se puede observar una evidente vulnerabilidad en el tratamiento de las variablescharsetbuf y locale, y el bug puede reproducirse de la siguiente manera: Todo lo que se tienes que hacer es configurar LC_CTYPE o LC_ALL con un string muy largo pasando por la función de tratamiento de caracteres Unicode y usando printf. Con una simple linea se puede observar el desbordamiento:

$ bash -c "LC_CTYPE='$(printf %40s)' printf '\U876543210'"

Figura 3: Explotación del bug con bash -c "LC_CTYPE='$(printf %40s)' printf '\U876543210'"

Hay que tener en cuenta que esta vulnerabilidad solo esta presente en sistemas que no implementen locale_charset en libc/libintl/libiconv. 

3.- En busca del 'Program received signal'. 

Juguemos ahora un poco con los caracteres y observemos las diferentes salidas mediante una gran herramienta, GBD:

Program received signal SIGABRT, Aborted in 0xb7fdd424 in __kernel_vsyscall ()

Figura 4: SIGABRT mediante bash -c "LC_CTYPE='$(printf %40s)' printf '\U876543210'"

Program received signal SIGSEGV, Segmentation fault in __gconv_close (cd=cd@entry=0x0)

Figura 5: SIGSEGV mediante bash -c "LC_CTYPE='$(printf %40)' printf '\U876543210'"

Es curioso, que solo cambiando un carácter %40s a %40 salgan salidas distintas. En la primera salida pone __kernel_vsyscal, que para los que no lo sepan es el método utilizado por linux-gate.so, una parte del kernel de Linux, para hacer una llamada al sistema usando el método más rápido disponible, usa preferentemente la instrucción SYSENTER. En la segunda salida, en el archivo gconv_close.c en linea 35pertenece a una función encargada de abortar calls, y posteriormente liberar todos los recursos.

4.- Preparando y analizando el binario en nuestro entorno controlado.


Vamos a ver qué protecciones tiene este binario y qué podemos y qué no podemos hacer. Para ello, podemos usar checksec.sh para comprobar las implementaciones de seguridad que tiene este binario de fabrica.

Figura 6: chechsec.sh sobre el binario de Bash 4.3

Ahora vamos a comprobar si ASLR esta activado: 

Figura 7: Comprobación de estado de ASLR

Por ultimo comprobamos si tiene el SetUID o el SetGID activado: 

Figura 8: Comprobación de estado de SetUID y SetGID

A primera vista, el escenario de ataque sobre el que hay que trabajar a partir de ahora se queda con las siguientes implementaciones de seguridad:

Partial RELRO: GOT no modificable.
STACK CANARY(ProPolice): No hay nada que hacer..
NX: Stack no ejecutable.
ASLR: 'Random' Memory.
SETUID: No esta activo.

La pregunta que hay que hacerse a partir de este punto es ¿se puede hacer unbypass a estas protecciones? La respuesta es: Sí, pero NO. Veamos por que:

5.- ¿Que implementaciones de seguridad nos 'molestan' realmente?

Tanto a NX como ASLR se les puede hacer un bypass mediante una técnica llamadaROP. Ahora veremos qué fácil es crear un payload en ROP de forma automática gracias a ROPgadget una gran herramienta que también nos permite hacer búsqueda de gadgets. 

Hay otras herramientas como ropeme la cual ofrece la búsqueda de gadgets en el binario y también la creación de payload de forma automática. Hay que destacar que estas dos grandes herramientas solo pueden generar payload de arquitecturasx86, veamos cómo.

Iniciamos ROPgadget con la opción '--ropchain' para que genere nuestro payloaddel binario bash.

$ python ROPgadget.py --ropchain --binary /bin/bash

Figura 9: ROPchain mediante ROPgadget

Teniendo esto, solo habría que guardarlo en un archivo *.py y cambiar el padding a:p = 'A' * 40 y ya tendríamos nuestro payload funcional. Se pueden dar algunas situaciones con las que tendríamos que lidiar:

- STACK CANARY o ProPolice nos frena en seco: una solución no perfecta es cambiar el valor de canary mediante un proceso hijo, y volverlas a cambiar por el valor canary original antes de que esta sea comprobada de nuevo si no, se detectaría un error. 

- RELRO nos implementa un nivel de seguridad más: Cuando el binario es ejecutado y trasladado a la memoria, se hace una llamada a Procedure Linkage Table o PLT que posteriormente hace un jmp a la GOT. Básicamente RELRO nos impide modificar GOT. 

6.- Conclusiones

Esto artículo quiere demostrar que no debemos confiar en ningún programa, porque nunca son 100% seguros, somos humanos y por tanto hacemos cosas imperfectas.

En este caso hemos visto un 0 Day, en concreto un Buffer Overflow en la ultima versión de BASH, la 4.3. Hemos seguido unos pasos para comprobar su protección, entender cómo funcionaba, y saber qué podríamos y qué no podríamos hacer.

Hemos visto que hacer un bypass de NX y ASRL no es demasiado complicado, queRELRO no nos molesta demasiado, y que STACK CANARY nos frena en seco toda la diversión. Además, aunque no hubiese estado, simplemente podríamos conseguir un ejecución de código arbitrario, pero no podríamos haber hecho un Privilege Escalation ni nada por el estilo ya que no esta el bit SetUID activado. 

En este caso, esta vulnerabilidad se 'salva' de ser completamente explotada debido aSTACK CANARY, pero hemos visto que el proceso de investigación es divertido y curioso. Solo nos faltaría informar a los encargados de seguridad de este proyecto, de forma responsable, y dejarles un tiempo para corregirla, en mi caso fueron avisados hace 2 semanas aproximadamente, y me dieron ya el consentimiento para hacer la divulgación publica. 

Espero que este articulo anime a personas jóvenes como yo, y no tan jóvenes a adentrarse en el mundo de la seguridad informática y el exploiting de Linux. Un saludo muy grande de un chico de 16 años que a veces piensa.

Fuente

¿Qué no llevas un condón USB en la cartera?

Recuerdo que allá por el año 2012 en cierta conferencia de seguridad había un mueblecito con un varios cables para cargar móviles, de hecho puedes ver la foto en una viñeta de nuestras crónicas gráficas. Como soy bastante paranoico y llevaba en el bolsillo una segunda batería no llegué a utilizarlo. De hecho ni siquiera llegué a usar esa segunda batería porque apagaba continuamente el smartphone... carajo, ¡estaba en un congreso de hackers!. Todos los que estábamos ahí lo sabíamos pero la necesidad imperiosa de permanecer continuamente conectado empujo a muchos a arriesgarse. El resultado ya puedes imaginarlo... más tarde en una presentación se mostraron en el proyector las fotos personales de los incautos que accedieron a mostrar en público sus vergüenzas.

Un año antes en la Defcon 19, también instalaron un kiosko de recarga de batería malicioso y el resultado fue el mismo, todos cayeron en lo que se conoce como ataque de'Juice-Jacking': robar datos o instalar malware cuando la víctima conecta su dispositivo a un puerto USB extraño.

En ninguno de los casos hubiera pasado si entre el cable y el smartphone hubiesen puesto un "condón USB".

Suena sexy y es sencillo: realmente sólo es un dongle que puentea los pines de alimentación cortando la interconexión de los pines de datos D+ y D-, es decir, sólo permite la carga eléctrica.

¿Y es caro un condón de éstos? Pues te resultará más barato que los que podrás comprar en la farmacia: por menos de 10 euros en Amazon o en usbcondoms.com y podrás reutilizarlo las veces que quieras XD!


Fuente