Ya tenemos antivirus… estamos salvados.

El pasado sábado la versión electrónica del periódico local valenciano Levante EMV daba la noticia de que un virus había causado el caos en la Escuela Oficial de Idiomas de Valencia. Al parecer, y según el diario, éste «provocó que las citaciones con el mismo número se duplicaran e incluso se triplicaran en algún caso». No niego que, aún desconociendo la aplicación y el procedimiento de citación, me parece sumamente interesante que un virus pueda actuar de forma tan «inteligente» y llegue a ese nivel de interacción con los datos, pero dejando polémicas, suspicacias y sospechas aparte, la cuestión es que me da la sensación, y entramos en el terreno de la opinión personal, de que para el público en general, y no tan general, los virus suelen residir en un universo independiente al del concepto «puro» de seguridad.

Es decir, que mientras éste parece estar más relacionado con grandes corporaciones, con hackers y crackers, intrusiones, robo de información privilegiada, IDSs, análisis forense, cortafuegos o gestión de contraseñas, los virus, troyanos, gusanos, spam y demás fauna relacionada son una molestia perrmanente y casi necesaria, fácilmente solventable con un antivirus y algún programa de malware. Parece, como digo, que políticas, procedimientos, y todas aquellas medidas típicas de un entorno seguro, orientado a evitar —mitigar— los riesgos relacionados con la seguridad de la información, están «de más» cuando se trata de controlar a estos no siempre pequeños y nunca inofensivos «bichos». Vamos, resumiendo, que en ese caso no son necesarias.

Desgraciadamente, las cosas no funcionan exactamente así. No sólo es mucho más probable sufrir una infección vírica masiva que sufrir una intrusión o un ataque DoS por alguna banda criminal de Europa del Este (por no salirme de los tópicos), sino que las consecuencias pueden ser igualmente fatales. Y es que aparte de un siempre necesario antivirus, actualizado periódicamente e inmune a las manipulaciones del usuario más molesto, son imprescindibles políticas que gestionen los privilegios de acceso a los recursos compartidos, el control de acceso a los dispositivos, la gestión de permisos y usuarios, las políticas de uso de soportes como USBs, CDs o DVDs,… Y como siempre, es necesaria la concienciación del usuario. Porque las fotos de la última convención no siempre son las fotos de la última convención: las cosas no son siempre lo que parecen aunque a menudo lo descubrimos un poco tarde.

Todo sea, al menos, por no ver aparecer por la puerta de la empresa a doscientas personas pidiendo matricularse en clase de mandarín, ¿no les parece?

¿Es el correo electrónico un medio de comunicación seguro…?

mail.jpgLeía hace unas semanas una noticia que decía “La policía danesa detiene a un hombre por acceder a los correos electrónicos de Michael Rasmussen» y seguía “La policía danesa ha arrestado en Herning, en el oeste de Dinamarca, a un danés de 30 años por introducirse en el correo electrónico del ciclista Michael Rasmussen e intentar vender a un periódico la información que obtuvo».

Esta noticia me ha hecho reflexionar sobre la seguridad general del correo electrónico que transita por el mundo y el negocio lucrativo que algunas mentes enfermizas pueden obtener por el hecho de fisgar en el correo ajeno.

Nuestros equipos de trabajo han analizado en bastantes ocasiones la seguridad del correo electrónico desde la óptica, por ejemplo, de la Ley Orgánica de Protección de Datos y de las medidas de seguridad que el Reglamento nos exige. ¿Podemos enviar información de carácter personal por el correo electrónico? ¿Cumple el correo electrónico las medidas básicas de seguridad para proteger la información que contiene? ¿Cómo podemos hacer uso del correo electrónico como canal de comunicación seguro? Las respuestas no son desde luego triviales para el gran público.

Pero el foco del análisis ha sido siempre distinto. Nos hemos enfrentado a infraestructuras corporativas de correo electrónico con servidores de correo, a evitar que el correo sea interceptado dentro y fuera de las organizaciones y a garantizar unas medidas de protección para determinado tipo de información que viaja en nuestros sobres electrónicos, pero, al menos yo, no me había planteado el interés que los correos electrónicos personales pueden llegar a tener en función de los dueños de las cuentas y, por tanto, la necesidad de que los que hospedan estas cuentas de correo ofrezcan a sus clientes servicios que garanticen la seguridad de sus comunicaciones.
[Read more…]

Pescando…

Imagino que la mayoría de ustedes conocen el sistema de mensajería instantánea Microsoft MSN. Seguramente sabrán también que puede uno cambiar el nombre o «nick» con el que le «ven» los demás, que es posible «bloquear» a otros usuarios de manera que para ellos aparezcas a todos los efectos desconectado y no puedan hablar contigo, y que el MSN y la cuenta de correo de Hotmail comparten el identificador de usuario y la contraseña. Dicho esto, hace unas semanas, mi novia —que comprueba que no la estoy mirando cada vez que introduce su contraseña de correo, a pesar de que lo consulta desde mi portátil— me saludó una mañana con el siguiente mensaje como nombre:

«www.QuienTeAdmite.com < -- Fijate quien te elimino y quien te desadmitio en el MSN, enterate TODO"

Aunque ya había visto eso antes, en este caso indagué un poco y llegué a sitios web como www.quienteadmite.com o blockoo.com, aunque hay muchas más, en las que aseguran que proporcionando el usuario de Hotmail y la contraseña, muestran qué personas tienen «bloqueado» a tu usuario en el MSN. Pese a que el método de proporcionar tu usuario y contraseña puede considerarse cuanto menos sospechoso y nada recomendable, no voy a entrar a cuestionar hasta qué punto el sistema funciona o no. Cabe decir, no obstante, que incluso aunque funcionase, eso no elimina los riesgos de «regalar» libremente el acceso a tu correo personal.

Lo que me llama la atención es que a pesar de que las «víctimas» de este tipo de iniciativas son por lo general usuarios experimentados de Internet (menores de treinta años) que conocen o deberían conocer los —a menudo exagerados— «peligros» de este medio, acaban confiando en una página web sin ninguna garantía que les pide su usuario y contraseña de correo personal. Lo que en mi opinión demuestra que, teniendo en cuenta que en gran parte de las relaciones a través de MSN la amistad y la confianza tienen un papel importante (y que el hecho de que una persona bloquee a otra se considera una afrenta relativamente seria), sólo hay que buscar el reclamo adecuado para que cualquier persona, en cualquier momento, revele información personal a extraños o sitios web desconocidos.

No me sorprende, por tanto, que el phishing funcione, y como es habitual, aunque no voy a aconsejarles que como suele decirse, no se fíen ni de su padre, cuando se trate de asuntos privados —finanzas, correo privado, datos personales…—, desconfíen. Esa suele ser siempre una buena política.

Ataques de Inyección SQL (III)

Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad «for educational purposes only» aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

En primer lugar, destaca Sqlninja como detector de vulnerabilidades de Injección SQL en servidores basados en Microsoft SQL Server. Esta herramienta es capaz de lanzar diversos exploits que atacan directamente al gestor de base de datos demostrando el grado de seguridad y hasta qué punto puede quedar nuestro servicio comprometido. Es una herramienta muy completa y fácil de utilizar, y cuenta con menus que resultan bastante intuitivos.

Absinthe es otra aplicación de fácil manejo, y que cuenta con interfaz gráfica de usuario, que destaca por la sencillez y rapidez a la hora de parametrizar una auditoría. Admite auditorías sobre varios gestores de bases de datos, como pueden ser Postgres, MySQL, MS SQL, etc…

SQL Power Injector es otra aplicación completísima desarrollada con el lenguaje C# bajo la plataforma de desarrollo de .NET. La interfaz gráfica posibilita realizar una auditoría de forma rápida e intuitiva. Es válida para varios gestores de bases de datos.

Más que una aplicación, SQLIer puede considerarse un script que utiliza un ataque de tipo verdadero-falso para determinar usuario y contraseñas de las bases de datos. Es por tanto un script a nivel informativo, con el que se pueden determinar la fortaleza de las contraseñas utilizadas y el grado de defensa contra ataques de este tipo.

Por último, SQL Injection Pentesting TooL es otra utilidad con interfaz de usuario muy completa para la realización de auditorías. Aunque a diferencia de las anteriores en este caso no se dispone del código fuente de la aplicación, y únicamente se puede ejecutar bajo entornos Windows, su descarga es totalmente gratuita.

Como es habitual, desgraciadamente nada es perfecto y a pesar de las facilidades que estas herramientas introducen, será necesario auditar de forma manual todas las implicaciones que conlleva todo lo relacionado con la conexión, acceso y tratamiento de la base de datos. Por poner un ejemplo, en Java se deberían buscar todas las llamadas execute(), prepareStatement() y prepareCall(), y hacer una traza de las mismas. El uso combinado de estos dos tipos de auditorías, la realizada de forma manual y la automática a través de las aplicaciones mencionadas, nos ayudarán a filtrar todos aquellos “bugs» no tratados durante el proceso de codificación de la aplicación, obteniendo así una aplicación relativamente protegida frente a estos ataques de Inyección SQL.

Y de momento, esto es todo. Como suele decirse, to be continued

Cuidado: cuando borra, no siempre borra

Si alguna vez piensa usted en sacar un dinerillo vendiendo ese ordenador, esa llave USB o ese disco duro cuya capacidad es ya irrisoria o que no le sirve de nada, acuérdese de borrar los datos que contiene, porque con toda probabilidad, aparte del teléfono de su suegra o de su ex, no querrá que sus correos personales, las fotos de su pareja o los teléfonos de sus amigos acaben en manos de un desconocido, ¿verdad?

Y le digo esto porque, aunque no sea usted el gobernador de Arkansas, estoy seguro de que se aprecia sus datos tanto como él. Ah, y por si hay alguna duda, cuando hablo de «borrar», no quiero decir borrar. Quiero decir «hacer los datos irrecuperables».

Visto en Kriptópolis.

(Buen fin de semana a todos)

Escuchas telefónicas made in USA

Aunque no pensaba actualizar hasta mañana al menos, y no acostumbro a poner nada en inglés, no me he podido resistir a esto, que describe el impresionante y complejo sistema de escuchas telefónicas montado por el FBI, basado en un informe de cerca de mil hojas hecho público gracias a la Freedom of Information Act (FOIA) y destinado a la Electronic Frontier Foundation (EFF). Les recomiendo que vayan al artículo de Wired, mucho más completo y realmente interesante:

The FBI has quietly built a sophisticated, point-and-click surveillance system that performs instant wiretaps on almost any communications device, according to nearly a thousand pages of restricted documents newly released under the Freedom of Information Act.

The surveillance system, called DCSNet, for Digital Collection System Network, connects FBI wiretapping rooms to switches controlled by traditional land-line operators, internet-telephony providers and cellular companies. It is far more intricately woven into the nation’s telecom infrastructure than observers suspected.

It’s a «comprehensive wiretap system that intercepts wire-line phones, cellular phones, SMS and push-to-talk systems,» says Steven Bellovin, a Columbia University computer science professor and longtime surveillance expert.

DCSNet is a suite of software that collects, sifts and stores phone numbers, phone calls and text messages. The system directly connects FBI wiretapping outposts around the country to a far-reaching private communications network.

Visto en el blog de Bruce Schneier.

Asimetrías en las transacciones digitales futuras

El pasado mes de junio se aprobó la Ley de acceso electrónico de los ciudadanos a los Servicios Públicos, en la que se establece que la Administración no es que sólo «pueda», sino que «debe» ofrecer todos sus servicios de manera electrónica. Sin ninguna duda, esta ley acompaña de manera definitiva al DNI electronico, y a otras opciones de certificación digital como puede ser la ACCV. No hay ninguna duda de que todas estas iniciativas pueden mejorar en mucho los trámites de los ciudadanos, pero por otro lado abren una gran cantidad de incógnitas frente a las garantías que tienen los ciudadanos al realizar trámites de manera digital, entre las que queremos destacar la asimetría de las transacciones digitales en la presentación de la declaración de Hacienda.

Recientemente muchos contribuyentes han realizado su declaración de Hacienda de manera digital a través de Internet. El proceso de presentación telemático asociado tiene visos de ser bastante completo: los usuarios deben acreditarse para obtener su certificado digital (formado por una clave pública y una privada), y la clave privada es generada por el PC particular de cada uno, con lo que este certificado digital permite que el usuario «firme digitalmente» su declaración. Todo ello a traves de la Fábrica Nacional de Moneda y Timbre, una autoridad de certificación con en principio todas las garantías.

Hasta aquí, todo bien (en realidad, no esta bien «del todo» al ser un certificado software, pero la tecnología que le sucederá en breve como es el DNI digital, sí tiene características como para considerarse firma electrónica); el proceso en su conjunto parece que sigue técnicas en principio bastante robustas en cuanto a los aspectos de seguridad, tanto organizativa como técnicamente.

Ahora analicemos el proceso de presentación de la declaración: preparamos ésta con el programa PADRE y nos conectamos a la página web de Hacienda donde nos aparece un applet, mediante el cual firmamos digitalmente nuestra declaración, y puesto que la firma digital equivale a la firma manuscrita, esto constituye en última instancia el equivalente a la entrega de nuestra declaración firmada. Ahora sólo cabría esperar que Hacienda tambien nos firmara (o cuñara) nuestra declaración con la misma robustez como nosotros se la hemos firmado, mediante un documento firmado digitalmente por la Administración (por la aplicación) que justifique que hemos entregado nuestra declaración. No obstante, en su lugar lo unico que recibimos es un número de registro, no firmado digitalmente ni de ninguna manera: un simple número de serie.

Por ello la autentificación y firmado de la declaración se produce de una manera completamente asimétrica: mientras que el ciudadano se autentica con ciertas medidas criptográficas y de seguridad, el justificante que obtiene es técnicamente muy debil, y con evidentes riesgos sobre su validez en caso de problemas. Y esta es la principal razón de que año tras año no presente la declaración por Internet sino a través del banco, del que al menos recibo un documento cuñado por la oficina con el que demostrar que la he presentado en caso de presentarse problemas futuros, ya que este documento sellado es a mi entender bastante más robusto que un simple número.

Muchos de los lectores podrían pensar que el tema de la declaración no tiene al fin y al cabo demasiada importancia, y quizá tengan razón, ya que al fin y al cabo Hacienda también permite maneras poco robustas de aprobar borradores de declaración como puede ser a través de SMS o medios similares. Pero el problema reside en que es esta es la tecnología que viene, y esta es por tanto la asimetría con la que nos vamos a encontrar en los futuros desarrollos con firma digital, como por ejemplo el nuevo DNI; ¿se imaginan ustedes firmando un contrato con algun operador de Telecomunicaciones en el que el usuario firma el contrato digitalmente y el operador simplemente entrega una hoja para imprimir? No parece un procedimiento demasiado apropiado, ¿verdad?

A la vista de este tipo de problemas que van apareciendo, no cabe duda de que los usuarios tendremos que estar alerta ante las futuras transacciones basadas en firma digital, que seguro que con el nuevo DNI electrónico van a comenzar a surgir.

Ataques de Inyección SQL (II)

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Sea la siguiente sentencia para mostrar el perfil de un determinado usuario en una página web:

SELECT * FROM users WHERE name = '"+ userName +"';

El atacante manipula la sentencia de esta manera…

SELECT * FROM users WHERE name = 'a' or 't'='t';

(En rojo y negritas, código inyectado por el atacante)

Mientras que la sentencia anterior debería mostrar las características de un único usuario, al incrustar el atacante un operador “or» con una condición que siempre es cierta, consigue que la sentencia sea cierta para todos los usuarios, devolviendo la base de datos por tanto todos los datos de la tabla users.

Como medida de seguridad, los distintos entornos de programación poseen ciertas funciones en las que se revisa estos tipos de entrada para evitar que lleguen a la base de datos. Por poner algunos ejemplos, en PHP por ejemplo existe la función mysql_real_escape_string para MySQL, en JAVA tenemos la función PreparedStatement, en Mono y C# de .NET se trata con las funciones SqlCommand (para Microsoft SQL Server) y OracleCommand (para gestores Oracle). De esta forma, si validamos tanto las entradas de primer orden como las de segundo, es decir, no sólo los posts, gets, cookies, sino también las que provienen de lectura de ficheros, bases de datos, etc… conseguimos filtrar instrucciones no deseadas, errores por tipos de datos, y manejo de tablas de la base de datos.

Como complemento de la seguridad en la aplicación, es recomendable generar las consultas de forma estática en la medida de lo posible, es decir, si predefinimos las consultas obligaremos al usuario de la aplicación únicamente a interactuar con los parámetros, por lo que no existe la posibilidad de que éste modifique las sentencias.

Hay muchas otras recomendaciones, como por ejemplo no acceder a la base de datos desde la aplicación con una cuenta de usuarios con privilegios de administrador, o hacer un uso restringido y controlado de los llamados “procedimientos almacenados», pero de eso hablaremos en la tercera parte de esta serie.

Security Theater

No sé si conocen el concepto de «Security Theater», y permítanme que no traduzca la expresión. La idea, acuñada por Bruce Schneier, viene a representar la presencia de medidas de seguridad que aportan poca o nula protección, pero por contra son publicitadas ostensiblemente dando una falsa sensación de seguridad. De ahí la combinación de «seguridad» con «teatro». Por ejemplo, hace unos días Bruce Schneier puso en su blog un caso que estoy seguro de que se repite en otros lugares: nadie vigila las 178 cámaras de seguridad de San Francisco, y en varios casos en los que diversos crímenes se realizaron frente a ellas, estaban incorrectamente orientadas. Por si esto no fuese suficiente, al parecer la visión «nocturna» es de ínfima calidad, lo que resta validez a las grabaciones. Por supuesto, como todo, este concepto tiene un efecto positivo, y uno negativo.

Empecemos por el segundo. En el caso mencionado, el ciudadano mira, y más allá de consideraciones de privacidad, ve las cámaras que le observan y en cierto modo, se siente seguro, protegido. Sin embargo, su sensación es simplemente una ilusión. Y eso le puede llevar a realizar acciones y correr riesgos que de otro modo no correría; no cambiarse de acera al cruzarse con alguien «sospechoso», por ejemplo. Otro efecto negativo de estas instalaciones, sobre todo a partir del 11S, es la limitación de la libertad de las personas, sobre todo al otro lado del charco; con toda probabilidad muchas de las medidas de seguridad que se aplican en los aeropuertos contra ataques terroristas son inútiles, a causa de la complejidad y tamaño de éste, pero sirven como excusa para coartar la libertar y privacidad de las personas, y generar una falsa sensación de miedo en la persona; que esta consecuencia sea intencionada o un producto de la incompetencia administrativa es algo que no voy a entrar a considerar.

Como aspectos positivos, los security theaters tienen la facultad de actuar, siempre que el criminal no conozca la realidad de las medidas de seguridad, como algo parecido a los espantapájaros: al generar esta falsa sensación de seguridad, impiden que los criminales se sientan seguros para llevar a cabo sus planes. Siguiendo con el ejemplo anterior, la presencia de una cámara de vigilancia puede disuadir al delincuente de atracar a alguien. Otro ejemplo, más allá de la seguridad personal, son los sistemas antirrobo que hay a las puertas de muchas tiendas pequeñas; la mayoría hemos visto alguna vez el sistema de alarma sonando mientras alguien sale de la tienda, pero la mayor parte de las veces, no sucede nada. No hay guardas de seguridad, ningún dependiente sale a mirar, nada; la persona se gira, hace una mueca extraña de sorpresa o sonrojo, y sigue su camino sin que nadie le diga nada o le detenga. A pesar de ello, pueden apostar a que mucha gente que se siente tentada a realizar pequeños hurtos abandona la idea a causa de estos sistemas.

En la misma línea, hoy leía en El Economista que el Departamento de Homeland Security (DHS) de los EEUU está desarrollando un nuevo sistema de seguridad a implantar en los aeropuertos, que se basa en estudiar a distancia todos los indicadores corporales de una persona para conseguir «adivinar» si tiene intención de atentar o no; había leído antes sobre esto, pero no recuerdo donde. Hace poco, un niño de siete años y su familia pasaron un mal trago por la simple cuestión de llamarse éste igual que un paquistaní deportado (Javail Iqbal) por los EEUU [elmundo.es]. Y el mes pasado, salió a la luz que el aeropuerto de Phoenix pasaba 4,5 horas totalmente desatendido en materia de seguridad (ver también el comentario de Bruce Schneier, que entra además en otras consideraciones). Así que pienso que hay cuestiones más importantes a considerar —y solucionar— que este tipo de tecnologías invasivas y casi de ciencia ficción.

Aunque por supuesto, en un cierto sentido paranoico, una cuestión adicional a considerar en algunos de estos security theaters que les comentaba es quién y porqué, o en otras palabras, el coste y empresa encargada de la tecnología, y la razón política o económica detrás de ella.

Y la culpa será del cambio climático II…

cpd.jpgLa verdad es que hay veces que nos pasa poco respecto de lo que nos podría llegar a pasar. En el fondo el ser humano tiene un cupo de suerte razonable, aunque siempre nos parezca poca. No son pocas las organizaciones que gastan sumas importantes de dinero en productos y servicios que incrementan, aparentemente de forma proporcional, la disponibilidad de la información, la confidencialidad y su integridad en el perímetro interior de las organizaciones. Muchos gestores TIC centran sus políticas de seguridad en la protección puertas adentro pero ¿es realmente efectiva, en los tiempos que corren, una política de seguridad que solo contemple el perímetro físico interior de nuestra organización?

En mi opinión no, y si no, piensen ustedes en qué les sugieren las dos imágenes que incluimos en este comentario.

He observado varias reacciones al respecto de esta pregunta, además de la mía propia por supuesto. La reacción inicial dibuja una leve sonrisa en la cara del observador. Al cabo de unos segundos el gesto sonriente se torna en serio, mostrando una cara de preocupación. ¿Será tal vez porque vea a su organización identificada? Pues… tal vez.

mascara.jpgEl hecho cierto es que esta situación se repite constantemente, y no sólo con los hogares de directivos y de personal técnico con privilegios suficientes para tumbar las infraestructuras de su empresa. Las fronteras han caído (ver la entrada «La caída de las fronteras digitales») y desde las áreas de seguridad debemos extender nuestras preocupaciones y ocupaciones allende los muros de hormigón de nuestros despachos. Debemos llegar, virtualmente hablando, a la casa de nuestro Director General, a la casa del Director de Recursos Humanos, a la oficina de la gestoría que nos hace las nóminas o a la red de la empresa que está desarrollándonos esa aplicación para la gestión de clientes.

En el caso del “home office» somos nosotros los responsables de establecer las políticas, de implantarlas y hacer que se cumplan. En el caso de proveedores que tratan información de nuestras organizaciones también somos nosotros los “responsables» de marcar las pautas y, aunque sea el proveedor el responsable de aplicar las medidas oportunas, nosotros deberemos velar por el cumplimiento de las mismas “deber in vigilando»

La verdad es que es sorprendente lo duras que pueden llegar a ser las medidas de seguridad puertas adentro de una organización y lo descuidadas que pueden llegar a estar las mismas organizaciones en su seguridad en el exterior. Pero no se preocupen ustedes, si hay algún problema, como ya les dije la otra vez, siempre podremos decir que la culpa es del cambio climático…