Problemas FireVault: 10.7 a 10.8

Despúes de un tiempo analizando si realmente valía la pena la actualización de Apple Mac Os X de 10.7 a 10.8, ya que en mi opinión, me parecía caro pagar $20 por las nuevas mejoras ofrecidas, es que ni por el GateKeeper lo valia.

Al final en un ataque de capitalismo decidí adquirir la actualización de Lion a Mountain Lion, es decir de 10.7.5 a 10.8.2. La primera sorpresa llego cuando una vez descargado todo, reiniciarse el equipo y proceder a instalar , pasado 2 minutos el instalador me indicaba que no se podia continuar debido a un fallo. Reiniciandose el equipo pero ya no se podía acceder a la versión anterior del entorno, dejando el sistema inconsistente. 

El error exacto que me daba el entorno era el siguiente:

Despúes de muchas vueltas, leer foros, rescatar el entorno con Time Machine, modificación manual de las particiones etc. Realice la última prueba, reinstalar el sistema desde TM pero sobre una partición no cifrada, sin FireVault. Una vez reinstalada sobre esta partición intente instalar el 10.8 y esta vez sin problemas, funciono todo a la primera. 

Por tanto si os pasara lo mismo, la solución es desactivar el FireVault, actualizar y luego volverlo a activar. En mi opinión FireVault tiene muchisimos fallos básicos de incompatibilidad, lo que me demuestra que los desarrolladores de Apple no emplean esta caracteristica en sus equipos, o al menos para hacer las pruebas. En el siguiente enlace teneis el reporte del fallo.

Hace aproximadamente 4 meses ya escribí una entrada donde ponia de manifiesto que a raiz de una actualización básica, el juego de caracteres del teclado asignado por defecto para poder acceder a tu entorno, para introducir la contraseña, estaba en inglés por lo que si usabas simbolos siempre te decía que la contraseña era incorrecta.

Menos IOS y más Os X, Apple lo tiene totalmente abandonado.

Consulta DNS con Snort

Recientemente un usuario del blog pregunto por qué en las reglas de detección de Malware con Snort, cuando se quiere detectar la consulta DNS hacia ciertos dominios sospechosos, se emplean ciertos caracteres y condiciones como la comprobación "byte_test:1, !&, 0xF8, 2;".

Para explicarlo vamos a tomar como ejemplo la siguiente regla VRT para la detección del malware Gauss:

alert udp $HOME_NET any -> any 53 (msg:"BLACKLIST DNS request for known malware domain bestcomputeradvisor.com - Gauss"; flow:to_server; byte_test:1,!&,0xF8,2; content:"|13|bestcomputeradvisor|03|com|00|"; fast_pattern:only; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, service dns; reference:url,gauss.crysys.hu/; reference:url,www.securelist.com/en/blog/208193767

En la regla anterior lo único que se esta comprobando es que se trate de una consulta DNS al dominio "bestcomuteradvisor.com". Para evitar falsos positivos se emplean tres restricciones en la creación de la misma:

La primera es comprobar que se trate de un paquete UDP al puerto 53 procedente desde nuestra red interna.

La segunda comprobación radica en el pripio "content" donde se tiene en cuenta el valor hexadecimal de inicio y final de la consulta DNS. Como sabemos un dominio esta separado por "." por ejemplo: "correo.empresa.es". Los paquetes DNS en vez de indicar este punto lo que hacen es indicar mediante un byte (dos números hexadecimales) la cantidad de caracteres que le preceden. 

En el ejemplo vemos que comprueba que haya primero un "13" en hexadecimal, es decir, que la parte del dominio que viene a continuación sean 19 caracteres (13 en hexadecimal). Si contamos el número de caracterers de la cadena "bestcomuteradvisor" tiene efectivamente 19. Luego comprueba que viene 3 caracteres pertenecientes a "com". Ademas comprueba que la consulta DNS termina siempre con el valor "00", indicando que no hay más caracteres en el dominio a consultar. 

La tercera y última, es donde tenemos el famoso "byte_test:1, !&, 0xF8, 2;". ¿Qué es esto del byte_test? No es nada mas ni nada menos que algo que nos permite coger una cantidad de bytes del paquete a partir de una posición y comprobar si coincide con otro valor. 

En "byte_test" lo primero que tenemos que mirar es el último campo, en nuestro caso 2. Esto indica la posición dentro del paquete donde nos situaremos, teniendo en cuenta que siempre el primer byte vale 0. Por tanto el valor 2 del cuarto campo nos indica que se situará en el 3 byte del paquete. Es muy importante entender que en Snort siempre que nos refiramos a posiciones del paquete ya se ha descontado lo empleado por las cabeceras de enlace, red y transporte. Por tanto el 3 byte ya implica haber descontado la cabecera IP y la cabecera UDP, es decir, ya se está trabajando sobre la cabecera DNS. 

Este el motivo por el cual cuando se emplea filtros BPF en herramientas como TCPdump, donde se tiene que hacer referencia al protocolo. Tomando el ejemplo anterior, en vez de buscar el 3 byte, se buscará en el 11 byte a partir del inicio de la cabecera UDP (udp[10]). Si la cabecera UDP de normal son 8 byte, comprende por tanto udp[0-7], el 1 byte del protocolo DNS es udp[8], el segundo udp[9] y el tercero es udp[10]. Por eso indicar en Snort el 3 byte con "2" es lo equivalente a indicar udp[10] en filtros BPF, recordar que en ambos caso se empieza contando siempre desde 0.

Por tato con "byte_test:1, !&, 0xF8, 2;" nos situamos en el 3 byte del protocolo DNS. Luego se debe mirar el primer campo de byte_test, en este caso 1. Esto indica cuantos byte vamos a coger a partir de la posición "2". En este caso su valor es 1 y por tanto un 1 byte es lo que se coge. En pocas palabras vamos a trabajar con el 3 byte del protocolo DNS. Si buscamos en google la cabecera DNS podremos obtener imagenes explicativas, como por ejemplo la obtenida de www.troyjessup.com:

Como vemos el byte que se está comprobando esta formado por lo siguientes campos:

• Bit 7: QR
• Bit 6-3: OpCode
• Bit 2: AA
• Bit 1: TC
• Bit 0: RD

Ahora se debe coger el segundo campo del byte_test cuyo valor es "!&", esto implica que con el valor del paquete se va a proceder a realizar una operación binaria "AND negada" sobre el valor indicado en el tercer campo de byte_test: "0xF8". Si se cumple la condición la condición sera correcta, si no se cumple, la condición no será correcta y por tanto no encajar en la regla.

Siempre que se empleen operaciones binarias de tipo AND u OR lo que se busca es que el valor de un campo sea uno en concreto o que al menos algunos de los campos tenga un valor. En nuestro caso lo que se esta buscando es F8, en binario "1111 1000". Por tanto se va a trabajar con los bits del 7 al 3 asignados al campo QR y OpCode. 

Si la comprobación fuera únicamente una operación AND ("&") la regla lo que estaría inentado comprobar es que el campo QR valga 1 y que el campo OpCode valga "1111". Pero al ser un AND negado lo que hace es lo contrario, busca que ambos campos valgan 0. Si se revisa el protocolo DNS ambos campos valen 0 cuando se trata de una consulta DNS (query). Por tanto "byte_test:1, !&, 0xF8, 2;"  lo único que hace es verificar que se trata de una consulta DNS.

Saludos hexadecimales.

Detectar Mandiant APT1

Buenas de nuevo. Como siempre escribo más tarde de lo esperado, pero por fin he terminado el paper y ya estoy en Advanced :-) (no me lo creo ni yo jaja).

Hace un par de días el mundo se revolucionaba con el informe de Mandiant, el APT1 y el posible expionaje del gobierno Chino. Aunque no he tenido tiempo de leerme el documento integro, si he visto que se han proporcionado una lista de dominios DNS consultados por este Malware. Por tanto si se detecta estas consultas podriamos detectar, en principio, que equipos de nuestra infraestructura están infectados.

Desde el blog de mi antigua empresa, mis excompañeros Raúl y Roberto han creado un fichero de reglas para Snort que comprueba si se hace una consulta DNS a los servidores de cualquiera de estos dominios. Desde la entrada en el blog podeis descargaros el fichero y probarlo. 

Posiblemente, y como han indicado varias personas, una solución que requiere menos consumo, ya que está diseñado para ello, es la implantación de un DNS Sinkhole, tal como se indico hace un año en el blog a traves de esta entrada. El DSN Sinkhole no es más que un DNS Bind con un listado de dominios prohibidos, de forma que cuando alguien consulta esos dominios, en vez de darle la dirección real del dominio se le da una IP de un servidor interno. Este servidor registra cualquier tráfico de red hacia él de forma que se pueda generar una alerta si algun equipo intenta conectarse a él.

Ahora bien, como mucho de nosotros conocemos, no siempre es posible la implantación de lo que queremos en una empresa. Siempre estamos sujetos a diseños anteriores, a la aceptación del cliente y a muchos otros aspectos más realcionados con la politicia de la empresa, el departamento de sistema, el tiempo requerido para su implantación y el desembolso económico requerido. 

La instalación de un IDS únicamente necesita que nos habiliten un puerto espejo en algún router o switch. Incluso con el uso de TAPs ni se requiere practicamente la intervención de un técnico de comunicaciones. Así mismo, la caida del IDS afectaría "únicamente" a la detección de alertas pero no a la disponibilidad del entorno. 

En cambio, la implantación de un DNS Sinkhole ya requiere dos servidores (DNS primario y secundario), puesto que, la caida de los servidores DNS afectaría totalmente al trabajo de la compañia. Así mismo, requiere un cambio en la arquitectura de red de la empresa, o al menos, la arquitectura de los servidores DNS, siendo necesaria la participación del departamento de sistemas. A su vez, se deben definir nuevas reglas en los firewall y modificar las anteriores, por tanto requiere tiempo de técnicos de comunicaciones. Además, sería necesario cambiar la politica de todos los equipos de los empleados para que tomen la IP del DNS Sinkhole como DNS valido. Si la empresa ya usaba un DNS interno se podría cambiar la IP de ese servidor DNS y asignarle esa IP al DNS Sinkhole para evitar tener que recurrir a micro.

Por tanto sí, DNS Sinkhole es mejor solución que emplear reglas de Snort, pero para ello es necesario una modificación en la arquitectura que no siempre es posible. Por tanto, sí disponemos de DNS Sinkhole pues volcamos los dominios a la lista negra y listo, si no disponemos de DNS Sinkhole pero si de Snort, es una buena idea aplicar las reglas indicadas al principio. Al fin y al cabo el asunto es disponer de algun mecanismo que nos permita detectar el Mandiant APT1.

Como mola esto de tener ya varias opciones para detectar estas cosas, hace unos años tendríamos que haber diseñado algún parche sucio y temporal para estas cosas. Nos leemos ;)