Seguridad en el Uso del Software Libre.

¿Deben las empresas usar software libre? Esa ya no es la pregunta, sino más bien: ¿Bajo qué criterios se debe usar el software libre? Uno de esos criterios es la seguridad, y es a lo que nos enfocaremos a lo largo de esta lectura.

SW libre: una realidad.

No invertiremos párrafos enteros analizando si se debe de usar o no el software libre en las corporaciones, ya que en las grandes y las pequeñas su uso es una realidad: desde algunos módulos en códigos de desarrollo, pasando por librerías y claro está, aplicaciones. Desde robustas soluciones como JBoss, hasta programas como FireFox o librerías de Java, difícilmente una organización podría afirmar que se mantiene “libre” del software libre. Inclusive el Departamento de la Defensa de los EUA lejos de negar una realidad, la acepta y mejor decide establece las reglas para su uso (DoD Guidance Regarding Open Source Software).

Ahora bien, entremos en materia. La seguridad del software libre presenta una:

Problemática.

+ El código del software libre está disponible para que “n” personas (principalmente desarrolladores/analistas de seguridad) lo analicen y verifiquen su seguridad, identificando debilidades para su corrección. Lo cierto es que si bien el código está disponible, no hay ninguna garantía de que sea revisado y/o corregido. Tampoco se puede asegurar que el código se revisó por personas conocedoras en la materia. Un código popular como Linux será retomado ciertamente por gente que tratará de identificar sus debilidades, pero no podemos esperar la misma suerte para todo tipo de librerías, miles de rutinas y objetos disponibles en Internet y listos para ser usados en las empresas.

+ No hay un indicador de que el software libre sea más seguro que el software comercial. Ambos casi siempre tienen el objetivo de ser funcionales, mas no necesariamente seguros. ¿En dónde hay más debilidades: en el código libre o comercial? No me atrevería a inclinarme a favor de uno u otro, hay de todo en ambos mundos: los hay con “n” debilidades y los hay con un número reducido de éstas.

+ El código del software libre, al estar disponible, tiene más riesgos ya que al poder ver sus “entrañas”, se pueden descubrir “fácilmente” sus debilidades. Pues bien, como es sabido, no se tiene disponible el código de aplicaciones comerciales y también se pueden identificar debilidades si uno sabe lo que hace.

+ Al estar disponible el código fuente, es posible alterarlo para insertar una puerta trasera o un troyano y (por ejemplo) re-publicarlo en otro sitio para que se baje. Por otro lado, se supone que el software comercial “jamás” traería una puerta trasera si uno lo adquiere legalmente del fabricante; al menos eso dice la teoría.

+ El software libre no siempre tiene un responsable y muchas veces nos podemos encontrar con comunidades sin nada más que buenas intenciones y que se encargan de actualizar el software para corregir vulnerabilidades. No hay a quien reclamarle (o no es práctico hacerlo) ni a quien exigirle. En el software comercial, habrá un fabricante o proveedor con quien inclusive exista un contrato de por medio. Uno de los casos excepcionales podría ser por ejemplo el software libre de RedHat donde hay sí hay una entidad responsable con quien se pueden hacer tratos formales.

Ok, qué hacer?

Ya vimos un panorama resumido de la problemática que se puede presentar en relación a la seguridad del software libre; pues bien, y ahora qué hacemos? ¿Cómo lo incorporamos de manera segura al desarrollo corporativo?

+ Registro del SW libre usado en la empresa. Nos referimos a tener identificado claramente dónde se está usando el software libre dentro de la empresa: ¿es un módulo dentro de un código? ¿Es una librería? ¿Es una aplicación? Se debería de saber en todo momento ubicar este software dentro del SW desarrollado en la corporación. El objetivo de tenerlo identificado es que será mucho más sencillo actualizarlo cuando exista una nueva versión que dé solución a debilidades. Otra ventaja sería poder identificarlo ante una auditoría (ok, creo ningún auditor en México lo pediría, sólo digo que si yo lo fuera, lo haría) : -).

+ Analizarlo con una herramienta automatizada sería un “must”. En el mercado existen diversas herramientas que revisan el código fuente en busca de vulnerabilidades; se pueden encontrar varias opciones en el “Gartner Magic Quadrant for Static Application Security Testing”. La idea sería correrle una de estas herramientas al código y tomar una acción adecuada con las debilidades encontradas.

+ Capacitación en codificación segura. Idealmente todos los desarrolladores deberían estar capacitados en cómo codificar de manera segura para evitar vulnerabilidades. Y al menos uno de ellos debería de estar mucho muy bien capacitado y más que desarrollar, su papel se convertiría en el de “revisor”. ¿Todo esto suena como a un “sí claro, con qué dinero”? Ok, por eso usé la palabra “idealmente”. Y por cierto, aunque es la medida que menos podría ser llevada a cabo de las aquí mencionadas ($), realmente es una de las opciones más beneficiosas.

+ Reputación. ¿Se podría tener un listado de las fuentes (sitios) confiables desde donde se puede bajar software libre? Tal vez este listado se crearía y mantendría entre el área de seguridad y la de desarrollo.

+ Documentación de características de seguridad. ¿El desarrollador que puso a disposición el software libre se preocupó por documentar las características de seguridad de su código? Esto sería un indicador de que al menos existe esta preocupación por parte del creador y nosotros podríamos revisar esas características para ver si son adecuadas para el negocio.

+ Contacto para solucionar debilidades. Si alguien en Internet encuentra una debilidad en el código del software libre, es posible contactar exitosamente al creador o comunidad del SW para informarle de la debilidad con el fin de que se le dé solución? Si no se puede establecer contacto, nos quedaríamos con una pieza de SW libre desactualizado y sin mantenimiento: cualquier debilidad identificada probablemente no se solucionaría (a menos que sea retomada por alguien más). Si no hay manera de contactar, no hay intención de actualizar.

+ Preferir código fuente sobre binarios: al menos con el código fuente tenemos la oportunidad de revisarlo; con los binarios no sabes lo que estás bajando (o es mucho más difícil averiguarlo).

+ Nessus y Wireshark. No está de más que una vez que el software libre se pone en operación se le pase un Nessus a ver si lograra encontrar alguna debilidad y por otro lado poner un sniffer como Wireshark para ver si -en un periodo de algunos días- el código instalado no ha llamado a la nave nodriza.

Conclusiones (al fin).

¡Uf! Sí que fue una entrada extensa, pero de vez en cuando no hace daño (espero no haberlos aburrido). He descrito algunos puntos de la problemática de usar software libre de manera segura en las corporaciones; no todas pueden ser relevantes para todo tipo de empresas y claro, se pueden encontrar más. Lo mismo para las medidas propuestas, algunas aplican, otras no. De todo lo que se leyó, qué te sirve a ti para tu empresa? Eso es lo más importante. O si nada te sirve pero te preocupó el tema para discutirlo en tu empresa, me doy por bien servido. Nos vemos en línea www.twitter.com/FaustoCepeda.

Documentos de Interés:

Fortify: CISO's Guide To Open Source Software Security.

SANS: Security Concerns in Using Open Source Software for Enterprise Requirements.

Coverity: Scan Open Source Report 2009.

Secure Programming for Linux and Unix HOWTO: Is Open Source Good for Security?

Fortify: Open Source Security Study.

“Jailbreikea” e inféctate.

¿Por qué tanto lío por el primer gusano para iPhone? Eso es lo primero que pensé al enterarme la semana pasada de esta noticia, pero en seguida supuse que lo “primero” siempre llega a los titulares, aunque realmente no represente un riesgo importante.

El SANS reportó el 8-11-09 sobre el primer gusano para iPhone, el cual infecta teléfonos con ciertas características:

+ Que estén “jailbreikeados” (término que se refiere a dispositivos hackeados para obtener libertad de instalar lo que se quiera sin interferencia del fabricante).

+ Que cuenten con el servicio de SSH (Secure SHell) habilitado y también que conserven la contraseña por default “alpine”.

En una entrevista con “ikee”, quien aparentemente es el creador del gusano, se establece que la intención del cracker es infectar teléfonos en Australia, pero hay indicios de que la infección ha aparecido en otros países.

Al momento de infectar, el gusano termina el servicio de SSH para prevenir que otros gusanos utilicen este medio para lograr infecciones exitosas y por otro lado cambia la imagen del fondo del teléfono. Y eso es todo (bastante simple). ¿Peligroso? Por sí mismo no, pero pone un precedente.

Ahora bien, en mi opinión, este tipo de noticias se deben de poner en contexto y no alarmarse e ir gritando por ahí que el iPhone es muy inseguro y que ya se le debe de poner un antivirus urgentemente; esto último es lo que algunas compañías antivirus les gustaría hacernos creer y de hecho un par de ellas andan cacareando aquí y allá este noticia, será que ya vieron un nicho?

Si tuviera un iPhone sin “jailbreikear”, no me preocuparía por el momento y lo seguiría usando con singular alegría; tal vez me preocuparía más el hecho de perderlo en caso de que ahí recibiera mi correo de la empresa o que tuviera otro tipo de datos sensibles.

Y para los que tienen un “jailbreak”, tal vez la recomendación sería darle un vistazo a sus contraseñas que tienen por default.

Finalmente, se ha enaltecido (¿indebida/innecesariamente?) la labor del creador de este gusano al identificar y anunciar su cuenta de Twitter y la de MySpace. No es un rockstar y de hecho viendo su código, no demostró una gran pericia. Pero sin lugar a dudas, conseguirá un buen número de followers, eso que ni qué. A ver si el largo brazo de la ley no lo sigue también, pero a su casa para acomodarle un susto (él mismo ya lo notó: “Which has kinda got me worried about legal implications?”).

Agrega Seguridad Total 2009 a tu Lista.

¿Deberíamos contar con Total Security 2009? Sólo si deseamos pagar $79.95 dólares por un scareware que se adelanta un paso al resto del código malicioso de su especie. Quien se haya enfrentado a los muy molestos Antivirus 2009 o SpywareGuard sabrá que no es nada grato tenerlos en el sistema. Y sin embargo, el Total Security 2009 es una pizca más molesto.

Todo empieza con la instalación de un programa (*.exe) con un extraño e incoherente nombre que puede llegar por diversas vías (adjunto en correo, bajado de Internet, etc.) y que tiene un icono de candado muy apropiado. Una vez que se ejecuta el infame programa en una computadora sin antivirus o con antivirus pero desactualizado, la “magia” empieza.

Total Security 2009 intercepta y bloquea absolutamente cualquier programa del sistema a excepción de Internet Explorer. ¿Office, Firefox, Adobe Reader? Olvídenlos, al querer arrancarlos aparece una ventanita que insta al usuario a comprar el “producto” Total Security 2009 a un precio de $79.95 dólares, con posibilidad de desembolsar $19.95 más en caso de que se desee un servicio “premium”. Lo único que se puede arrancar es Internet Explorer para hacer el pago correspondiente vía Internet con tarjeta de crédito.

En pocas palabras, han secuestrado a nuestra computadora, ya que no se pueden acceder a los documentos o los programas del equipo. A menos, claro está, que se pague por la “protección” de Total Security 2009, que más bien es un rescate por recuperar nuestros datos y programas.

Eso sí, una vez que se hace el pago, recibimos un código que amablemente nos permitirá hacer uso de nuevo (y en adelante) del equipo.

Si alguien ha sido víctima de esta Seguridad Total 2009 y tenía un antivirus actualizado, sería mejor pensar en la conveniencia de seguir con esa marca de antivirus. Por otro lado, si estaba desactualizado, supongo que tendremos más cuidado en el futuro. Pero si ya nos infectamos, qué podemos hacer?

Una opción es apagar Windows y encenderlo a modo prueba de fallos; una vez ahí, instalar/actualizar el antivirus y tratar de limpiar el sistema. Una segunda opción es introducir los códigos que exige el sacareware pero sin pagar el rescate: Panda ha publicado estos códigos que deberían de servir para desbloquear el equipo y posteriormente limpiarlo. Otra opción que me encontré en la red es instalar Linux o usar OS X para evitar estos problemas J.

Agrega Seguridad Total a tu lista, pero a la de programas indeseados que ni son seguros ni totales.

Sé normal, Java.

¿Qué podríamos pensar de una aplicación que al actualizarse no desinstala versiones anteriores? Desde el punto de vista operativo, nos preocuparía que esté ocupando espacio necesario en nuestro equipo de cómputo. Desde el punto de vista de seguridad, podría ser posible que se invocaran a las versiones anteriores para explotar esas antiguas vulnerabilidades?

La versión más reciente de Java JRE es la 6-16 y al instalarla no remueve ninguna versión anterior de este programa que esté presente en el equipo. La idea de actualizar o parchar es remover las debilidades encontradas en las versiones anteriores de un programa, pero si la versión anterior vulnerable permanece “viva” en el sistema, entonces sirve de algo instalar el programa más reciente?

Java de alguna manera inhabilita –en la navegación web- las versiones anteriores al momento de instalar la más reciente; sin embargo, ya ha sido posible en el pasado invocar a versiones vulnerables anteriores y explotar sus debilidades, haciendo inútil el intento del usuario por permanecer al día.

Por ejemplo, hace un par de años, el Bug ID 6281384 del fabricante describía cómo era posible para un applet decidir qué versión de Java usar dentro del sistema. Claramente, lo anterior permitiría a un atacante fabricar un sitio con un script malicioso que precisamente decidiera usar las viejas versiones de JAVA para explotar sus debilidades y a partir de ahí llevar a cabo acciones no autorizadas. El bug fue resuelto, pero siempre está latente que alguien encuentre un nuevo bug que permita lo ya descrito.

Algunos programadores que desarrollan programas en la empresa (in-house), se podrían quejar de que sus aplicaciones dejan de funcionar si se desinstalan las versiones anteriores de Java, ya que la ejecución de lo que han desarrollado se “amarra” a una de las viejas versiones.

Una buena práctica es no anclar de esta manera a las aplicaciones e invocar y usar en todo momento la versión más reciente de Java; esto da libertad operativa y propicia un ambiente más protegido.

La recomendación para ambientes caseros y empresariales, es desinstalar manualmente -siempre que sea posible- las versiones anteriores de Java, ya que esto no sucede automáticamente como se podría esperar. A mí me dejó tres versiones anteriores de Java en un equipo, las quité y no experimenté ningún problema. ¿Y ustedes, a cuántas versiones de este programa le dan hospitalidad en sus equipos?

Volvámonos invisibles ante sus ojos.

¿Permitiríamos que nos robaran aún pudiendo hacer algo al respecto? No voy a repetir lo que hemos escuchado cientos de veces respecto a lo “malignas” que son las amenazas en línea ni de la necesidad de extremar precauciones online. Ha llegado la hora de ir más allá, a territorios inexplorados; a tierras donde seremos “invisibles”.

Usar esa computadora donde trabajamos, navegamos, jugamos, bajamos e instalamos todo tipo software y ¡ah!, también hacemos transacciones en línea, es hoy en día estar jugando a la ruleta rusa. ¿Problema exclusivo de usuarios caseros? Ya no tienen la exclusividad.

Pymes: el objetivo (también).

Las empresas pequeñas y medianas en EUA están perdiendo millones de dólares debido al código malicioso que se centra en transacciones en línea. Son ya un objetivo debido a que las PyME (en cualquier parte del mundo) manejan mayores montos de dinero que un usuario y es más lucrativo encargase de ellas, a la vez que no tienen departamentos de TI y/o de seguridad robustos para hacerle frente de manera eficaz a los criminales en línea como lo hacen los corporativos con más recursos.

Amenazas: las sabemos.

No voy a repetir que este año aparecieron troyanos que intervienen la sesión del navegador “on the fly” de la transacción (retirando montos tal cual fuera el usuario mismo, como reportó la revista del MIT), tampoco que han crecido los correos phishing o que varios sitios “buenos” alojan código “malo”, sin mencionar las decenas de vulnerabilidades que diariamente salen a la luz.

En fin, el punto es que por diversas causas, el crimen en línea sigue prosperando con quien se deje, tanto que se ha dicho que rebasa al narco. ¿Qué hacer? Cambiar de paradigma.

La solución.

Nuevo paradigma: invisibilidad. Olvidémonos de Windows o de mantener un antivirus actualizado. Olvidémonos de conseguir costosas soluciones de seguridad y aún seguir con la maldita duda de si nuestro equipo está infectado; tener miedo de iniciar esa transacción en línea porque navegué a ese sitio inapropiado. Hoy en día hasta los sitios apropiados pueden resultar peligrosos (¿verdad NYT?).

Usemos un live CD de Linux. Eso es todo. Podría dejar de escribir en este momento, pero ahondaré.

Problema: usar la misma computadora para el quehacer diario y también para transacciones financieras; uno nunca sabe qué es lo que se pudo haber instalado, si el sitio a donde navegamos era malicioso o si aquel CD pirata contenía algún regalito o si ese USB prestado que usamos era más peligroso que la death star.

Solución: un live CD de Linux (mi preferido es Ubuntu) que inicia un sistema operativo limpio en cada ocasión y la propuesta es usarlo solamente para hacer las transacciones en el sitio financiero; cuando acabamos, lo apagamos y regresamos a nuestra computadora de siempre. Recordemos que un live CD es aquel que puede “bootear” -iniciar- un sistema operativo (en este caso Linux) desde la memoria del equipo sin instalar nada en el sistema, dejando intacta nuestra computadora.

Problema: prácticamente todo el código malicioso (incluido obviamente el dedicado a robar dinero), está escrito para trabajar con Windows y al usarlo, navegamos con un barco de madera en un río de lava, esperando que las protecciones aguanten el incesante deseo de la roca ardiente por tomar el control.

Solución: un live CD de Linux. Este sistema no es objetivo de los atacantes y aunque lo fuera (hipotéticamente), recordemos que en este live CD nos iremos directamente a hacer las transacciones deseadas; no es para navegar, leer correos, jugar o instalar; nace para nuestro propósito y muere una vez que se logra.

Conclusión.

Un antivirus ineficaz o inexistente, un antivirus no actualizado, tal vez un parche de seguridad no instalado. Una des-habilitación momentánea del firewall personal, un CD pirata, un USB contaminado, un “sí” al sistema cuando debimos de decir “no”. Un descuido de un segundo, una confusión, un error pequeño: es todo lo que se requiere para perder el control del sistema ante un poderoso Troyano.

Si usamos la sesión del live CD de Linux únicamente para hacer las transacciones financieras en línea, estaremos reduciendo enormemente el riesgo y seremos casi invisibles ante los ojos de los atracadores digitales. Restaría fijarse en el certificado digital de la página web para completar el círculo de invisibilidad.

¿En qué me baso? Ya había pensado en este tipo de solución que de hecho es la que yo uso para mis transacciones personales. Pero fue hasta que leí un ensayo del SANS (Protecting Your Business from Online Banking Fraud) que mis ideas aterrizaron ya que ahí se analiza precisamente este esquema (entre otros) y donde se establece que la problemática ya no sólo es del usuario, sino de los corporativos también.

¿Suena ridículo? ¿A mucho trabajo? ¿Con un buen antivirus y/o un firewall personal es suficiente? ¿En nuestra corporación se tienen todo tipo de protecciones? No hay problema, olvídense de lo que dije, ni vale la pena poner un cometario de lo absurdo que suena todo esto. En cuanto a mí, prefiero pecar de precavido. “Sabed, piratas, que os costará trabajo arrebatarme mi oro, porque he logrado convertir mi navío en algo fuera de este mundo: un barco fantasma; invisible para sus ojos inundados de avaricia. Id a otras aguas, allá encontrareis fortuna”.

Estás perdiendo tiempo en el tráfico.

¿Cuántas horas pasamos en el tráfico a diario? Muchos de nosotros tenemos que gastar un tiempo considerable (¿dos horas por día?) en medio del tráfico. ¿Pérdida de tiempo? Sí, porque es un tiempo improductivo. Algunos escuchan noticias tratando de sacarle algo bueno a esta situación, tú haces algo para no perder sino ganar tiempo?

Yo escucho podcasts de seguridad. Me compré un iPod, bajé el iTunes y me dediqué (lo sigo haciendo) a buscar podcasts que me interesaran, en este caso, de seguridad y de tecnología. Quisiera enlistar algunos de los podcasts de seguridad que escucho a ver si se animan a copiar la idea y convierten así un tiempo perdido en un tiempo ganado. Ya no le temo al tráfico, lo veo como una oportunidad de ponerme al día.

Recomendaciones.

1.- Security Now [inglés]: definitivamente el mejor podcast de seguridad que he escuchado. Afortunadamente se publica semanalmente y de forma amena y profunda, Steve Gibson (acompañado de Leo Laporte) nos explica todo tipo de temas, desde tecnologías de seguridad informática hasta las noticias relevantes semanales. Podemos encontrar temas como “Crackeando GSM”, “Hackeando máquinas de votar electrónicas” o “Protocolo SSL/TLS” entre muchos otros temas muy interesantes. Yo me podría perder todos los podcasts menos este: http://www.grc.com/securitynow.htm

2.- The Silver Bullet Security Podcast [inglés]: mensualmente, Gary McGraw nos entrega una entrevista con líderes de seguridad como Ed Amoroso, Eric Cole, Peter Neumann, Dorothy Denning o Bruce Schneier. Definitivamente resulta interesante lo que estos líderes de opinión nos quieren decir: http://www.cigital.com/

3.-The SCMagazine Podcast [inglés]: en este podcast se tratan las noticias relevantes de seguridad informática de manera semanal.

4.- CERT’s Podcast Series Security for Business Leaders [inglés]: si bien se tratan temas de seguridad corporativos interesantes, lo cierto es que no lo hacen de una manera amena para el podescucha, cuestión que también es importante para mantener el interés del público.

5.- SANS Internet Storm Center Threat Update [inglés]: la reconocida organización de seguridad SANS nos trae diariamente las noticias relevantes de la semana en menos de diez minutos. Al igual que el podcast del CERT, aunque aborda temas interesantes no lo hacen de una manera muy amena que digamos, habrá que escucharlo y decidir.

Conclusiones.

El mensaje al final es que aprovechemos el tiempo escuchando estos podcasts mientras manejamos, hacemos ejercicio, viajamos en el metro o mientras regamos el jardín.

Por cierto, también hay otros podcasts que si bien no son de seguridad, son de tecnología en general y pueden resultar de interés, como Dommo con Javier Matuk y Ricardo Zamora, el New York Times Tech Talk o Byte con David Ochoa.

Yo sólo los escucho mientras manejo y creo que aprovecho bien esas horas, ya no lo veo como pérdida de tiempo, sino como una inversión para estar al tanto de temas de mi interés y lo mejor es que en lugar de estar horas leyendo, estoy horas escuchando. Es un buen negocio. ¿Y ustedes matan el tiempo o lo aprovechan?

Una propuesta que cambiará el mundo.

Al menos, cambiaría el mundo de la seguridad de la información. Mi propuesta es simple: un actualizador global de aplicaciones. Le podríamos llamar “Total Updater” o “Global Updater” y sería el encargado de actualizar todas las aplicaciones de un sistema de forma automática y transparente. ¿Les suena interesante?

 

Codificar es un proceso complejo y eso influye enormemente en las debilidades que son diariamente encontradas en todo tipo de aplicaciones. Los sistemas ejecutan decenas de ellas y de todo tipo. Ya sean procesadores de palabras, lectores de PDF o navegadores y todas estas aplicaciones requieren ser actualizadas más temprano que tarde.

 

Las empresas por lo general de alguna forma u otra le siguen el paso a las debilidades de su infraestructura y parchan. ¿Y los usuarios caseros? ¿Cómo saber que hay una nueva versión de nuestro antivirus o de ese programa con el cual disfrutamos de nuestros videos?

 

Mi propuesta: un software encargado de identificar todas las aplicaciones instaladas en un sistema y en base a ello que no sólo “sepa” de cada nueva versión, sino que se  encargue de bajarla y de instalarla, no importa de qué fabricante sea. Y preferentemente, que este proceso de actualización sea transparente para el usuario.

 

¿Ventajas? Una sola y muy poderosa: que todas las aplicaciones de un sistema se mantengan actualizadas, librando al usuario de diversas afectaciones derivadas de vulnerabilidades. Sería un gran mitigador de riesgo y al menos habríamos minimizado un vector de ataque.

 

Claro, este “Global Updater” también se actualizaría a sí mismo y la pregunta que queda en el aire es: quién debería de desarrollar esta “aplicación de aplicaciones”? ¿Los fabricantes de los sistemas operativos? ¿Un tercero? ¿Ya existe algo así? No sé de una solución que haga todo lo que aquí describimos. Por ejemplo el PSI de Secunia (gratuito) identifica parches faltantes de las aplicaciones, pero no los busca en los sitios de los fabricantes para instalarlos.

 

Cambiaría el mundo de la seguridad “casera” como lo conocemos, ya que este “Total Updater” sería el dolor de cabeza de los crackers y demás atacantes, que verían sus poderes reducidos. Encontrarían otras maneras, lo sé, pero pondríamos más piedras en su camino. El reto es que la mayoría de los equipos lo tuviera, pero eso escapa ya de las manos de este humilde bloguero.