Nivel de seguridad inalambrica en la ciudad de Valencia

El pasado fin de semana estuve dando un paseo portátil en mano por la ciudad de valencia obteniendo resultados aterradores. Las capturas de datos en el escenario de pruebas ofrecieron la posibilidad de establecer una categorización del uso de los métodos de cifrado inalambrico por parte de la población consultada, permitiendo medir el nivel de seguridad de las redes Wireless en la capital del Turia.

Se obtuvieron como resultado cuatro grandes grupos: redes abiertas “OPN”, Access Points (AP) con seguridad WEP, redes que hacen uso de WPA, y puntos de acceso con WPA2. Los datos recabados reflejan el grado de seguridad de las conexiones inalámbricas que utilizan el estándar IEEE802.11, estimando de esta forma la exposición de riesgo de la población que hace uso de este tipo de tecnología. El gráfico de la izquierda establece el porcentaje de uso de cada protocolo obtenido de una muestra de 2658 puntos de acceso tomada en el escenario de pruebas, con la siguiente distribución:

» 538 puntos de acceso sin cifrado de datos.
» 1514 con seguridad WEP.
» 513 redes con el protocolo de seguridad WPA activado.
» 93 AP’s que usan WPA2.

Como se puede observar, el 20% de los puntos de acceso no contempla ningún tipo de cifrado de datos o control de acceso. El 57% utiliza seguridad WEP, mientras que el 19% hace uso de WPA en su punto de acceso inalámbrico. En último lugar aparece WPA2 con un escaso 3% de uso.

Teniendo en cuenta estos datos, podemos casi asumir con certeza que el 99% de los puntos de acceso con WEP son explotables de forma exitosa. Me aventuraré aún más y diré que el 15% de los puntos de acceso con WPA pueden ser atacados con resultados positivos. De la misma forma, el 15% de los AP’s con WPA2 lo son también, debido a que los métodos de ataque son los mismos: diccionario y Rainbow tables (precomputación del SHA-1 (guardado en forma de listado hash) de WPA y WPA2 para acelerar el proceso de crackeo; véase este enlace). Si a ello le sumamos el porcentaje de las redes abiertas obtenemos el siguiente resultado:

Podemos decir por tanto que sí, el 80% de las redes inalámbricas en la ciudad de Valencia son potencialmente vulnerables.

La convergencia de Boeing

Leía en El Mundo (elmundo.es) un peligroso ejemplo de convergencia (¿recuerdan que les hablamos de ello?). Parece ser, siempre teniendo en cuenta que las diferencias entre lo publicado en medios de propósito general y la realidad tecnológica suelen ser considerables, que a los señores ingenieros de Boeing no se les ha ocurrido más que unir, en ciertos puntos, las redes de datos y control de sus aviones con las redes de propósito general que dan acceso a Internet para los pasajeros durante el vuelo. Si simplemente hubiéramos visto la noticia en el periódico, seguramente lo habríamos achacado al sensacionalimo o desconocimiento de quien ha escrito el artículo, pero resulta que en el mismo hay un enlace a Cryptome.org (algo más serio en materias de seguridad) en el que se publica el supuesto informe de la FAA (Federal Aviation Administration) que hace referencia a este problema.

Teniendo en cuenta que el propio informe de la FAA indica que es necesario seguir analizando el problema para determinar el posible impacto del mismo, por lo que es posible que finalmente un potencial intruso simplemente pueda tener acceso a cosas irrelevantes para la seguridad del vuelo (consulta de la temperatura en cabina, lectura de parámetros de vuelo, captura pasiva del sistema de megafonía…), nos importa mucho el hecho en sí, como ejemplo de convergencia. Si un intruso ataca una red de datos desde su ordenador, podrá interferir generalmente en actividades de índole lógica, perjudicando la imagen de la víctima, la integridad de sus datos, la confidencialidad de su cartera de clientes, etc.; pero si esta red da acceso a sistemas de control, la cosa cambia. En este caso, pensemos en que el atacante podría distorsionar datos de vuelo o proporcionar datos falsos a los elementos de control; sin duda es aventurarse mucho, pero como ya adelantamos, este tipo de cosas —quizás, y esperemos que así sea, no en aviones, por las medidas de seguridad que se introducen en estos medios de transporte— acabará pasando. Cuando conectamos elementos de control físico con redes fácilmente atacables, nos exponemos a riesgos que tal vez no sean los esperados.

Por si acaso, yo trataré de volar lo menos posible. Eso sí, no por esta noticia, sino porque nunca me ha gustado el avión.

(N.d.E.) Actualización 10:00h: Leo a través de Barrapunto que al parecer, un hacker polaco ha materializado en el sistema ferroviario polaco una amenaza parecida [The Register, en inglés].

¿Steal my Wi-Fi? No, thanks.

Comentaba Enrique Dans hoy un artículo de Bruce Schneier en Wired, titulado “Steal This Wi-Fi“. Básicamente, éste (Schneier) viene a defender los argumentos por los que tiene su Wi-Fi abierta a todo aquel que quiera utilizarla, y aunque algunos de los argumentos me parecen correctos, con otros discrepo profundamente, así que no me he podido resistir a escribir algo. Aprovecho además para recomendar a nuestros lectores, habituales y esporádicos, que si han decidido no dejar abierta su Wi-Fi, cambien de WEP a WPA, sí o sí. Las molestias del cambio es mínimo, y el incremento en seguridad, muy sustancial (vean este artículo del propio Schneier si no se lo creen, como apunta un comentarista por allá).

Pasando al artículo, el primer y creo que principal argumento de Schneier para dejar la Wi-Fi abierta es la cortesía con los invitados; si alguien recibe calefacción, agua y una taza de café, ¿porqué no Internet? Admito que el argumento es correcto, pero en mi caso, nunca he tenido un invitado que haya tenido la necesidad de acceder a Internet con su propio dispositivo, por lo que esa cuestión nunca se me ha planteado. Por supuesto, si de manera frecuente tuviese amigos que necesitasen acceso a Internet, me plantearía alternativas. También afirma, en referencia a la seguridad de los datos propios, que, puesto que se conecta a menudo con Wi-Fis de aeropuertos y hoteles, la seguridad debe residir en el PC, y no en la red. Estoy de acuerdo, pero no es mi caso; apenas utilizo el ordenador cuando no estoy en casa, y no acostumbro a usarlo en hoteles o aeropuertos, por lo que la exposición de los datos que conservo en éste a terceros está limitada por elementos que controlo: la red y el propio PC. Si tuviese que viajar a menudo, me abstendría de utilizar servicios como la banca electrónica u otros en los que el dispositivo es un mero transmisor; llámenme paranoico si quieren. Por último, hablando del robo de ancho de banda, estoy de acuerdo en que resulta más una molestia que otra cosa, excepto en aquellos casos en los que la otra persona decide abusar de tu generosidad; que alguien te quite ancho de banda no supone demasiado, la verdad.

Hasta aquí, los argumentos en los que puedo estar más o menos de acuerdo o no se aplican a mi caso. Sin embargo, hay otros con los que estoy mucho menos que de acuerdo, y hay uno en particular que es para mí, la principal razón para evitar tener tu Wi-Fi abierta. Éste se basa en la posibilidad de que alguien efectúe actos delictivos mediante tu equipo: pornografía infantil, estafa, intrusión en empresas, etc. Alguien puede pensar que el hecho de tener tu Wi-Fi abierta puede servir como defensa frente al juez, algo así como un “yo no he sido”. Este es un argumento más defendido por Dans que por Schneier. El caso es que a no ser que a las tres de la mañana entren en tu casa los GEOs y confisquen de repente todo tu equipamiento informático, si un buen día recibes una citación judicial, iba a ser complicado un mes después convencer al juez de que tu Wi-Fi se encontraba abierta. Es algo como decir que te habían robado el coche cuando te llega una multa dos meses después de la infracción. No conozco demasiado el sistema de registro de los Access Points, pero me juego un brazo a que no guardan en una memoria no volátil las modificaciones en la configuración (para demostrar, por ejemplo, que el proveedor te lo instaló abierto en origen), y me juego el otro a que nadie o casi nadie tiene configurado el sistema de syslog del Access Point, que por otra parte esté probablemente muy limitado en el tipo de eventos que genera. Y aún en el caso de que el juez admitiese que el Access Point estaba abierto, te tocaría demostrar que efectivamente, no has sido tú el autor de las acciones delictivas (lo más normal es que tus potenciales vecinos se desmarcasen del uso de tu Wi-Fi, si ven el panorama feo). En definitiva, que lo más posible es que acabes delante de un juez, lo que te robará tiempo, dinero, te meterá en un lio que puede ser considerable, y si el juez en cuestión decide que puesto que la conexión está a tu nombre por contrato, te toca apechugar con la culpa, te costará más dinero o cosas peores.

Por último, se hace mención a los problemas (actuales o futuros) que puede tener WPA, y en esto también incide Dans más que Schneier, que es muy consciente de las fortalezas y debilidades de WPA. Por supuesto que WPA tiene sus limitaciones de seguridad; básicamente igual que muchas tecnologías y protocolos seguros, pero eso no es suficiente para afirmar, como dice Enrique Dans, que no sirve para evitar el crimen por sus problemas de seguridad, que es lo mismo WPA que nada. No. Quizá WEP sea casi lo mismo que no tener nada (y ni aún así), pero WPA es lo suficientemente seguro para que no sea nada nada fácil romperlo si se hace uso de una clave robusta. De hecho, hay que tener mucho interés, bastante tiempo y unos no despreciables conocimientos técnicos para intentarlo; y eso no asegura que se consiga. Y si pasamos a WPA2, les puedo asegurar que pueden dormir tranquilos. Por supuesto que tiene sus limitaciones y saldrán problemas técnicos en el futuro, al igual que los tienen el ssh o el https, pero eso no evita que sigamos utilizando la banca electrónica, ¿verdad?

En mi opinión, aunque tener tu Wi-Fi abierta es un signo de generosidad hacia otras personas, y algo que algunos agradeceríamos cuando nuestro proveedor decide cortarnos la conexión un sábado por la mañana, puesto que después de todo desconocemos que hace “el otro” a través de tu AP, creo que los riesgos exceden las ventajas, aunque después de todo es una decisión personal. No es cuestión de pensar que todo el mundo es malo, pero tampoco que todo el mundo es “güeno”. Simplemente porque meterse en un proceso judicial, aunque salgas indemne, debe ser ya de por sí algo bastante traumático (y costoso). Y tampoco se fíen, en el lado contrario, y como les decía José Selvi hace unos días, de todo aquel que tiene su red abierta, porque no todo es lo que parece.

El lunes, más. Como siempre, pasen todos un buen fin de semana.

FSM criptoanálisis WEP (y III)

Si recuerdan, y no se nos han perdido por el camino, en la entrada de ayer nos quedamos con el cálculo de SA+3[A+3] (es decir, elemento A+3 del array S en la iteración A+3) mediante el algoritmo PRGA. No obstante, como les decíamos, no parece muy factible asumir que los valores de S[0], S[1] y S[A+3] permanecerán quietos tras el barajado de KSA. Y aquí es donde entra en juego la estadística; FMS calcularon mediante la fórmula

formula.jpg

que un 5% de las veces dichos valores no se veían alterados, mientras que el 95% restante no permanecían en las posiciones deseadas. Esto aunque no lo parezca es un dato muy alentador en cuanto a la ruptura del algoritmo se refiere, ya que con una cantidad muy grande de paquetes (del orden de 2000000) se puede detectar que el valor que devuelve el PRGA es nuestro SA+3[A+3].

En este punto recordemos una de las dos premisas que presentamos al comienzo del análisis: conocemos el texto plano del primer byte del paquete, ya que corresponde con el valor 0xAA. Realizando un XOR de ese byte con el primer byte encriptado podemos conocer un 5% de las veces el valor de SA+3[A+3]. Retrocediendo aun mas con este valor podemos calcular el jA+3 y con ello determinar el valor de Clave[A+3]. Una vez determinado el byte A, podremos ir incrementando el valor del índice (A+1) para buscar el siguiente byte de la clave [A+3+1, 255, X], y vuelta a empezar. Poco a poco incrementaremos el valor de A averiguando por completo el total del vector Clave[].

Existen posteriores mejoras del algoritmo FMS que identifican un mayor numero de IVs débiles y que producen como resultado una determinación de la clave con un menor número de paquetes. Personas como KoReK introdujeron nuevas capacidades al algoritmo permitiendo la recuperación de una clave de 128 bits con 800000 IVs y de una de 65 bits con 200000 IVs.

Se ha seguido trabajando en la mejora de este algoritmo, y la universidad de Darmstadt (véase este enlace) ha conseguido rebajar el número de paquetes considerablemente mediante la creación de la herramienta PTW. Haciendo uso de su aplicación es posible conseguir la clave de cifrado (128 bits) con tan solo 50000 IVs. Y con este, queda finalizada la serie de tres “capítulos” sobre porqué no es nada recomendable utilizar WEP (teniendo en cuenta además que WPA suele estar disponible en la mayoría de dispositivos) y porqué su mala fama sí es justificada; pueden obtener más información de este completo artículo de Linux Magazine [PDF] y de innumerables sitios en Internet.

FSM criptoanálisis WEP (II)

Tras la introducción de ayer y la descripción de la relación que existe entre la clave de cifrado maestra y los IVs de la cadena que conforma la entrada al algoritmo KSA, hoy continuaremos con el análisis del algoritmo KSA. El código de éste se puede observar a continuación.

     KSA

     for i = 0 to 255
          S[i] := i
     j := 0
     for i = 0 to 255
          j := (j + S[i] + Clave[i mod “tamañodelaclave"]) mod 256
          Intercambia(S[i], S[j])

Vemos que principalmente esta compuesto por dos bucles; un primer bucle que inicializa un vector de enteros S, muy importate como posteriormente veremos, y una segunda iteración que tiene como objetivo desordenar el vector anterior en función de la clave maestra. En este caso el valor de la variable “tamañodelaclave“ será 5 para 64 bits y 16 para 128 bits. Realicemos una pequeña traza de las tres primeras iteraciones que nos ayudaran a comprender su funcionamiento. En el estado inicial, tras la inicialización del vector S, el valor de las variables es el siguiente:

     Clave[] = (A+3, 255, X, Clave[3], …, Clave[A+3], …)
     S[] = (0, 1, 2, …, A+3, …, 255)

Partiendo de este estado vamos a aplicar las tres primeras iteraciones para observar el comportamiento del algoritmo.

     Iteración 0
     
     i = 0
     j = 0 + 0 + Clave[0] = A+3
     S[] = (A+3, 1, 2, ..., 0, ...) 

     Iteración 1

     i = 1
     j = (A+3) + 1 + 255 = A+3                  [Ya que se aplica “j mod 256"]
     S[] = (A+3, 0, 2, ..., 1, ...)

     Iteración 2

     i = 2
     j = (A+3) + 2 + X
     S[] = (A+3, 0, S[j], ..., 1, ...)

[Read more…]

FSM criptoanálisis WEP (I)

Es de sobra conocido que el algoritmo de seguridad inalámbrica WEP presenta numerosas vulnerabilidades que hacen que su despliegue en redes 802.11 represente una puerta abierta a cualquier atacante. Una de ellas y quizás la mas significativa es la que utiliza técnicas estadísticas y de fuerza bruta para recuperar completamente la clave de cifrado. A continuación, y en sucesivas entradas, trataremos de determinar los entresijos de estas técnicas.

La vulnerabilidad descubierta por Scott Fluhrer, Itsik Mantin y Adi Shamir, y a la que a partir de ahora nos referiremos como FMS, trata de explotar diversas carencias en el algoritmo RC4 que permiten la obtención de la clave de cifrado utilizando para ello ataques estadísticos. Con la diferencia de que este ataque supone una vulnerabilidad total del sistema de cifrado WEP, ya que no sólo es posible desencriptar un paquete de datos, sino que es posible obtener la clave permitiendo el acceso total a la red inalámbrica y a los datos que por ella circulan. Son muchos los estudios posteriores que se han realizado a partir de la investigación de Fluhrer, Mantin y Shamir (FMS, en adelante), y que mejoran su trabajo reduciendo el tiempo de recuperación de la clave. Básicamente esta vulnerabilidad se centra en el modo de operación de RC4 y sus dos módulos KSA y PNRG ya comentados en secciones anteriores. El estudio demuestra matemáticamente la existencia de un vulnerabilidad en la fase KSA del algoritmo RC4. Trataremos de evitar —dentro de lo posible— la complejidad matemática asumiendo algunos hechos que pueden ser consultados y analizados mas a fondo en el artículo de FMS.

Pasemos a definir qué es lo que hace tan vulnerable a este algoritmo de cifrado, estableciendo dos premisas claves. En primera instancia como ya sabemos, todo texto plano a trasmitir lleva como prefijo 3 bytes del vector de inicialización IV y que hacen única a la trama. Por otra parte FMS observaron mediante el estudio del tráfico de una red 802.11, que los tres primeros bytes de la trama en texto plano generalmente son los mismos: “0xAA:0xAA:0x03”. Dichos bytes son los pertenecientes a la cabecera SNAP (Subnetwort Access Protocol. Véase B. Schneier. Applied Cryptography. Protocols, Algorithms, and Source Code in C. John Wiley & Sons, Inc. 1994.) e identifican al protocolo. Dadas estas dos premisas analizaron la relación que existía entre los IVs de la cadena que conforma la entrada al algoritmo KSA y la clave maestra de cifrado, observando que ciertos IVs reflejaban información acerca de dicha clave. A estos vectores de inicialización los llamaron WeakIV o IVs débiles. Pudieron llegar a la conclusión, y esto se reserva como consulta a su articulo, de que los IVs débiles tenían la forma

[A+3, 255, X]

donde “A” es el índice del primer byte de la clave maestra y “X” es un valor cualquiera. Así pues, para un valor de “A = 0″ estaríamos haciendo referencia al primer byte de la contraseña. Como ya comentamos anteriormente, estos 3 bytes de forma característica, son concatenados a la clave maestra formando la cadena de entrada al algoritmo KSA, por lo que una encriptación WEP de 64 bits tendría como vector de entrada la siguiente cadena:

[A+3, 255, X, ?, ?, ?, ?, ?]

donde los signos “?” representan la clave que tanto la estación como el Acess Point conocen. Cabe destacar que para una encriptación de 128 bits los caracteres “?” se extenderían hasta 13. Y con esto lo dejamos por hoy. Mañana entraremos a analizar el algoritmo KSA, para rematar el viernes con el último capítulo de la serie.

Ni tanto ni tan calvo…

La semana pasada un compañero de trabajo, J., me contaba que había decidido empezar a utilizar la banca electrónica, y evitar de este modo tener que desplazarse a la oficina o al cajero para realizar consultas o transferencias económicas. Puesto que no le era posible realizar la consulta personalmente, le había pedido a su progenitor que se acercase a la sucursal y se informase de toda la documentación y trámites necesarios para activar el servicio en cuestión, servicio que sabía que su entidad bancaria ofrecía gratuitamente.

Y así lo hizo éste.

Ese mismo día, al llegar a casa, su padre le entrega todo el papeleo que le habían entregado en el banco: información identificativa como el nombre, apellidos, y DNI, más otra algo más sensible: número de cuenta del cliente y todos los códigos necesarios para la realización de trámites por Internet. Todo ello obtenido sin necesidad de presentar ningún documento que acreditase la identidad de ninguna de las dos personas, ni ninguna declaración de autorización ni fotocopia del DNI; y tampoco porque hubiese una relación de amistad entre el empleado del banco y el padre de mi compañero (que ni aun así, pero bueno…). No; todo lo que hizo falta fue decir un nombre y apellido.

Aunque es cierto que, en mi opinión, las medidas de seguridad de las entidades bancarias suelen estar a la altura de las circunstancias (más les vale), casos como este son una de las razones para no bajar nunca la guardia. Y es que teniendo en cuenta lo que se juega uno, no es como para tomárselo a broma…

(Si quieren saber el final del cuento, J. puso una queja formal, tras la que recibió una llamada del director de la sucursal pidiendo disculpas y asegurando que algo así no volvería a pasar).

Usuario: mhyklo Password: 1234

Muchos usuarios de sistemas informáticos debemos almacenar en nuestra memoria gran cantidad de contraseñas, que pueden llevarnos a malas prácticas como por ejemplo: usar siempre la misma contraseña para todo, utilizar contraseñas derivadas de una que ya tenemos, contraseñas de longitud corta para poder acordarnos, utilizar alguna contraseña relacionada con nosotros como puede ser nuestra fecha de nacimiento o DNI, etc.

La solución a este problema puede encontrarse almacenando estas claves en un dispositivo que siempre llevemos con nosotros y que permita almacenar las contraseñas de manera segura, lo que implica que si alguien que no somos nosotros accede al dispositivo no pueda disponer de ellas. Entre estos dispositivos podemos encontrar Blackberrys o PDAs, que disponen de software con esta funcionalidad, entre otros. Aún así no todos los usuarios disponemos de este tipo de dispositivos, y plantearse una inversión en un “trasto” así para únicamente almacenar las contraseñas no parece del todo coherente. Entonces cabe plantearse la siguiente pregunta: ¿existe algún dispositivo que todo usuario lleve siempre consigo y en el cual almacenar las claves pueda ser rápido, cómodo y seguro? Esta pregunta hoy en día tiene respuesta: el móvil.

Para poder almacenar de manera segura las contraseñas en el móvil existe entre otros, el software “Freesafe. Únicamente se deberá disponer de una contraseña “muy fuerte” que dé acceso al resto de contraseñas. Este software utiliza la librería criptográfica “The Legion of the Bouncy Castle“. Este sistema cumple los requisitos que comentábamos, ya que el móvil a día de hoy es parte prolongada de cualquiera de nosotros, y el software indicado almacena las contraseñas de manera segura en nuestro móvil. El único inconveniente de este software es que está por el momento limitado a ciertos móviles, pero todo es cuestión de “Bucear por Google” y encontrar un software que realice estas funciones para el nuestro.

Con esta solución (aunque seguro que existen más alternativas) uno puede disponer de contraseñas robustas y diferentes en todos los accesos que realice, sin la excusa de tener poca memoria.

Nunca es tarde si la dicha es buena

Queridos lectores, vuelvo de mi baja temporal (“cervicalgia aguda con impotencia funcional“), mis vacaciones y un “de moderado a intenso” dolor de cabeza con la sorpresa —noticia que probablemente muchos de ustedes ya conozcan— de que el pasado 21 de diciembre fue finalmente aprobado en el Consejo de Ministros el Nuevo Reglamento de la LOPD, que como saben carecía de uno y hacía uso del reglamento de la derogada LORTAD.

Puesto que al parecer no se ha publicado éste aún en el BOE, y como es pronto y sería algo insensato por mi parte ponerme a reflexionar sobre las modificaciones que introduce, les dejo el enlace de la Moncloa donde pueden al menos ir abriendo boca; estarán ansiosos por leerlo. No se preocupe, seguro que tenemos tiempo para alabar y demonizar las novedades del nuevo texto.

Nada más. Felices vacaciones a los privilegiados que las estén disfrutando, y feliz año 2008 al resto, como antes, con un poquito de retraso.

Falsos positivos

Esta mañana he tenido que realizar la visita a un cliente. El problema que me comunicó ayer por la tarde es que su navegador web no le mostraba ninguna de las páginas que solicitaba, pero en cambio el cliente de correo funcionaba sin problemas. Curioso, comprobé que no era problema de DNS, ya que el nivel de seguridad estaba configurado igual que en el resto de navegadores que su red local. La única pista que tenía era que suponía que todo se había producido tras una actualización del sistema operativo.

Así que acudo a la cita para solucionar el problema, puesto que se trataba de una persona de cierta responsabilidad y no debía realizar gestiones a través de internet desde otro equipo que no fuera el suyo. Tras darle un par de pensadas y comprobar que efectivamente la configuración de red era la correcta, recordé un caso que me había pasado hace tiempo.

Me dirijo a la configuración del software antivirus (que incorpora funcionalidad de firewall personal) y ahí estaba el problema. Este programa había detectado la actualización del navegador como un cambio en un software que solicita salida a internet, como un si se tratara de un troyano; mi cliente había confiado plenamente en el corttafuegos personal y éste había tomado la decisión por sí mismo de bloquear el ejecutable.

Es necesario recordar algo que se menciona en numerosas ocasiones; este tipo de herramientas, así como las de detección de intrusos y similares, se mueven por patrones de comportamiento, pero es un entrenamiento adecuado de dicho software el que puede conseguir, que por sí solo, se comporte con la inteligencia y la capacidad de decisión que esperamos de él. Mientras esto no sea así, no dejemos de lado al operador humano y echemos un vistazo por si las moscas.

(N.d.E.: Nos van a disculpar si la frecuencia de actualización disminuye —quizá de manera sensible— durante estos días, pero entre el turrón, los Reyes Magos, unas cosas y otras, no sabe uno de dónde sacar el tiempo para todo…)