Archivo

Archivo para la Categoría "seguridad"

El vídeo del interrogatorio de la infanta, y la [des]protección de las fuentes

febrero 11, 2014 8 comentarios

Ayer me desayuné con el vídeo del interrogatorio de la infanta, me sorprendió. Pero no por lo que dijo, era de esperar, sino por la forma en que se ha divulgado, especialmente por El Mundo, sin tomar medidas previas para asegurar el anonimato de los autores. Es un tema ya debatido, la responsabilidad y la protección cuando se divulga información que puede poner en problemas a las fuentes. Ocurrió con Wikileaks y el soldado Manning, a pesar de todos los recaudos que tomaron, al final la única víctima de la liberación de esa documentación fue el/la pobre soldado.

Con el tema del vídeo de la Infanta pasó algo similar, pero mucho más chapuza e irresponsable. Me explico:

  1. Las imágenes del vídeo permiten localizar con precisión de centímetros a la posición de la cámara grabadora.
  2. No sólo está rodeado de testigos, también hay cámaras grabando (y seguramente fotografías), por lo que conocida la posición de la cámara se puede saber quién era el portador de la misma. Adiós cualquier indicio de anonimato.
  3. Se sube el vídeo “anónimamente” a una web de una empresa española, con sede y servidores en España, la justicia lo tiene muy sencillo para solicitar los datos con que se dio de alta el usuario y desde dónde subió el vídeo. La empresa no se puede negar a entregar esos datos, por lo que los que grabaron y/o subieron el vídeo lo tienen aún más complicado para defenderse.
  4. Parece (dicen, no confirmado) que se subió vía una conexión 3G, por lo que -dependiendo de operador, pero la mayoría lo permiten- se puede ubicar qué dispositivo es el que lo subió. No es lo mismo que ocurre con conexiones hogareñas con routers WiFi, donde no se puede conocer con precisión al dispositivo/ordenador que se conectó a un servidor externo. Actualización: parece que se hizo usando una VPN.

Para proteger el anonimato de las fuentes tendría que haberse eliminado las imágenes, haber subido a un servidor de otro país (preferentemente sin convenios de colaboración con España o Europa) mediante TOR o servidores anonimizadores en otros países. Aún así todavía es posible obtener la dirección IP de origen (por eso es mejor hacerlo desde conexiones “colectivas”), pero requiere mucho más esfuerzo, que quizás no compense por la tontería de información que se divulgó.

En resumen, se divulga un vídeo -que aporta nada de información que no se supiese o esperase- sin tomar los mínimos recaudos para proteger a las fuentes. Los más probable (a menos que encuentren otras relaciones e intereses) es que El Mundo o Wouzee no sufran las consecuencias legales, sólo el “pringao” que grabó ese vídeo, que creyó que ya aseguraba su anonimato subiéndolo con un nombre de usuario falso. Una gran irresponsabilidad de unos, y una ignorancia casi infantil de otros.

Otra prueba de que la tecnología por sí misma no soluciona los problemas políticos ni nos da más libertad automágicamente, ni para los más tecnoutópicos. Los que a esta hora están siendo investigados (y quizás hasta interrogados) lo habrán aprendido por experiencia propia. Por eso cabe más responsabilidad de los que se han lucrado (en dinero o clics) con este vídeo: han dejado a sus fuentes en pelotas y casi sin defensas para informarnos de lo obvio. Un coste enorme para unos, un beneficio casi cero para los demás. Una irresponsabilidad.

Accidentes de transportes: evitar que se repitan, no buscar el linchamiento ipso facto

julio 29, 2013 10 comentarios

Hace 23 días ocurrió el accidente del vuelo de Asiana en el aeropuerto de San Francisco, las primeras investigaciones demuestran que hubo fallo del piloto en su aproximación visual. También se sabe que ese día el sistema ILS (Instrumental Landing System) de esa pista no funcionaba en ese momento por mantenimiento programado y anunciado. Este instrumento es de gran ayuda a los aterrizajes ya que indica (y dispara alarmas) si el avión se encuentra fuera de la dirección y pendiente adecuada (glide slope) para el aterrizaje, incluso sirven para que el avión aterrice automáticamente sin intervención manual. Sin embargo, los pilotos están capacitados para aterrizar sólo en aproximación visual (i.e. sin ayuda de este instrumental) cuando se dan las condiciones climáticas adecuadas (como era el caso).

La prensa norteamericana e internacional fue muy prudente, no se dedicó a buscar un único culpable a quién linchar públicamente como está pasando en España por el accidente del Alvia de Santiago. Podrían haber acusado al piloto, o podrían haber acusado a la administración y al aeropuerto de ser los culpables por no tener en funcionamiento un sistema tan básico (y antiguo, su primer uso data de 1938) como el ILS. Sólo imaginad qué hubiese pasado si el accidente de Asiana hubiese ocurrido en España. O peor, que hubiese ocurrido en algún pequeño aeropuerto español sin ILS (ahora mismo estoy en Santiago del Estero, Argentina, llegué en avión, su aeropuerto no tiene sistema ILS, nunca me preocupó, los pilotos están formados para aterrizar aquí sin su ayuda).

Algo similar pasó con el accidente de Spanair en Barajas. Hubo acusaciones de todo tipo, se culpó al piloto, a la empresa, a AENA, y finalmente al técnico. Pero la realidad es que fueron una desafortunada y larga cadena de errores en un sistema muy complejo: de problemas de diseño del MD, de un error de un relé, de un técnico que deshabilita alarmas básicas, y pilotos que no repasan toda la checklist antes del despegue por interrrupciones de comunicación, por lo que intentaron despegar sin los flaps desplegados sin alarma que les avisara.

La aviación, como el ferrocarril, es un sistema de transporte muy seguro y a la vez muy complejo (sociales y de ingeniería). Cuando ocurre un accidente nunca hay un único culpable, ni siquiera cuando parece obvio. A veces, como parece ser el caso de Asiana, el culpable parece obvio, el piloto, pero suelen encontrarse otros motivos que ayudaron a que se produzca: fallos en la formación, en el entrenamiento, en un disciplina demasiado estricta, problemas psicológicos, sobre carga de trabajo, problemas de comunicación, etc.

Con el incremento de la automatización de los sistemas se están conociendo otros factores humanos, por ejemplo, la excesiva dependencia en los sistemas electrónicos, al punto de que los pilotos o conductores pierden hasta las habilidades básicas de poder volar un avión que está en perfecto estado para hacerlo. Esto lo saben bien los fabricantes de aviones, especialmente Airbus, y una de las posibles causas en el vuelo Air France 447 que se estrelló en el Atlántico. Con el transporte ferroviario está ocurriendo algo similar, existen problemas de factores humanos de adaptación al pasar de un sistema altamente automatizado a uno que exija mayor concentración del conductor. Por ello se cambian las normas para exigir una mayor participación manual de los conductores:

But not all system failures—or solutions—are technological. “The problem is that you are setting up people to fail,” says railroad systems engineer Felix Schmid, of the University of Birmingham, in the England. “You have a very-high protected railway connected virtually straight into a less-protected railway.” The shift is similar to a car driver exiting smooth traffic on a highway for the less predictable gridlock of a city center.  “It’s the change from low demand to high demand which is sometimes quite difficult to manage,” he adds.

New York City’s Metropolitan Transit Authority learned to cut open-door accidents (in which doors open mistakenly when trains are not safely parked at a platform) by adopting a Japanese human-factor innovation: requiring drivers to signal by hand when they reached the appropriate platform marker for opening the doors.

Las autoridades de seguridad en el transporte (como la famosa FAA de EEUU) no están interesadas en encontrar un culpable penal, sino en identificar la cadena de errores que llevaron al accidente, para modificar o implantar procedimientos que eviten que se vuelva a producir. Por eso tenemos estos transportes tan seguros, como explica Taleb en su último libro, es un sistema claramente “anti frágil”: los errores del sistema se usan para evitar que se vuelvan a producir, por lo que cada error aumenta la seguridad del sistema, a pesar de ser un sistema muy complejo (y por lo tanto con tendencia a “escaparse” de nuestro control).

En el caso del accidente del Alvia, el propio maquinista reconoció su error, un despiste, no se dio cuenta que estaba en ese tramo del trayecto. Pero seguramente no fue el único responsable, o mejor dicho, no es el único error de la cadena. Con toda seguridad se sumaron otros fallos, quizás fallos de alarma, o de necesidad de más balizas y avisos, y hasta quizás factores humanos: entrenamiento, cansancio, estrés… o la excesiva confianza en los sistemas automáticos. Se pueden especular de muchos factores, pero no se sabrá con certeza hasta después de una investigación compleja cuyo principal objetivo será evitar que vuelva a ocurrir. Apuesto a que no habrá una respuesta simple (salvo los que se lo cojan con papel de fumar), pero que servirá para mejorar la seguridad ferroviaria en todo el mundo.

Mientras tanto, los lectores y no iniciados somos testigos de una parte de la prensa linchando al maquinista basados en un comentario en Facebook donde se muestra orgulloso de su trabajo, y otra parte de la prensa que por llevar la contra levanta el dedo acusador contra Renfe y Adif basados en opiniones de presuntos ingenieros expertos que se esconden en el anonimato… vaya deontología y responsabilidad profesional.

La culpa tampoco es de los medios, la redes sociales se llenaron de expertos en seguridad e ingeniería ferroviaria con opiniones tan categóricas como ignorantes de llegar a comparar el sistema de seguridad de un tren de cientos de toneladas circulando sobre una vias metálicas con el sistema de aparcamiento automático de un coche. Como dijo @apuente, es “no caber un tonto más”.

Toda la experiencia y reconocida complejidad de la seguridad del transporte aéreo, y con todas las barbaridades que se dicen en cada uno de ellos, y que los humanos somos falibles al igual que nuestra ingeniería, ¿no sirvieron para aprender nada sobre la cautela a la hora de opinar, encontrar culpables inmediatos o elaborar teorías de la conspiración? ¿Creen que así disminuirán el dolor de las víctimas? ¿O que los organismos de seguridad internacionales tomarán en cuenta esas teorías de desinformados para evitar que se vuelva a producir? ¿O es sólo para obtener páginas vistas? ¿O son campañas políticas -a favor o en contra- interesadas?

Sea como fuese, es desolador. Es leer un artículo sobre el tema en la prensa y saber que no puede confiar en casi nada de lo que te cuentan.

Categorías:medios, prensa, seguridad Etiquetas: , ,

Respuesta al director de Change.org España

febrero 6, 2013 39 comentarios

En lainformacion.com publican unas respuesta de Francisco Polo, director de Change España, que responde a mi apunte crítico anterior. Primero aclararé lo fundamental en temas técnicos, para que quede claro quién habla con pruebas, y quién suelta rollos vacíos intentando desacreditar al otro:

  1. Sí es posible que una persona firme varias veces con correos electrónicos diferentes, sin que se verifique ni que los datos (ni siquiera el código postal) correspondan.
  2. No hay verificación de los datos del formulario, ni siquiera para esos emails que ya tienen cuenta creada en change.org.
  3. No hay verificación de que el email pertenece a la persona que lo pone, y que esa personas tenía la intención de “firmar”.
  4. Sí es sencillo “firmar” automáticamente con un programa.
  5. Aunque creador de la petición recibe la lista (en PDF) de “firmantes” (con los datos falsos y sin especificar el email), y que change.org está en EEUU, argumentan que no pueden hacerla pública por la LOPD. Hay algo que no cuadra ¿no?.

A las pruebas, breves y preparadas sólo para esta respuesta, me remito.

Repito, a las pruebas me remito.

Actualización (Feb 7, 10 hs): Por el comentario de Carles Mateu, he modificado el bot, y he logrado cientos de “firmas válidas” y confirmadas con una única dirección de email (desde ayer no puedo acceder a change.org desde la IP de casa, han puesto mis peticiones de prueba con captcha, y eliminaron esas firmas con gallir+xxxx, espero que sea porque solucionaron este problema en general).

Creo que son bastante claras: un programa que demuestra los 5 puntos anteriores (que ya había explicado en el apunte anterior). Solo puede negar estos hechos alguien que ni siquiera conoce en profundidad el funcionamiento técnica de la plataforma, no le interesa averiguar, y que se intente ocultar los serios problemas de poner un sistema de “firmas” en Internet (que no hace el mínimo de verificaciones para asegurarse por lo menos que la dirección de email es de la persona que lo puso. Un requerimiento básico).

Ahora paso a contestar cada una de las respuestas relevantes de Francisco Polo.

Ahora bien, si vuelves a poner todos tus datos, la plataforma te ‘loguea’.

No sé qué explica esto, pero tampoco funciona así, si no sería un problema de seguridad. Podéis probar que sucede “firmando” con mi email -por ejemplo-, os saldrá mi avatar (¿?), pero no estáis logueados con mi usuario.

 Una petición no se puede firmar dos veces, ni tres, ni cuatro con el mismo correo. Con lo cual, lo que se ha dicho este fin de semana es falso.

Falso, demostrado arriba. Y en el apunte anterior, no se hablaba de correos duplicados, sino de la misma persona con correos diferentes, y de hacerlo con programas. El primer programa con el que hice esas primeras generaba -adrede- direcciones muy poco probables agregando un número de varias cifras (más de 4) al final sólo para evitar llenar de “spam” a la gente que le coincidiera la dirección de email. Es muy fácil que coincidan direcciones como josemaria en gmail.com o mariagarcia en hotmail.com, o imaginaros que tuviese a disposición una lista de emails… no es nada complicado, también se compran, o se obtienen de “tu empresa”.

En este terreno nosotros tenemos un sistema de detección automática de ataques de spam. Cuando nuestro sistema aprecia que hay unas firmas de carácter continuado, generalmente desde una misma IP y siguiendo un patrón definido, lo detecta y las retira. Además tenemos sistemas manuales de comprobación. Comprobamos que no haya correos electrónicos extraños, o similares a los que utilizan para hacer ataques de spam, muchas firmas desde una misma dirección IP, etc. De hecho, en peticiones con tanto flujo mediático como puede ser la de la petición de la dimisión del PP, lo hemos pedido.  La respuesta de la comprobación manual fue que no había ningún indicio de ataque de spam. Con la mayor de las probabilidades podemos afirmar que las firmas que hay en esa petición son fidedignas.

El 100% de las peticiones de arriba no son “fidedignas”, además de demostrar que una persona puede firmar con muchos emails diferentes, como si fuesen “personas diferentes”, y que cuentan en el final. Tampoco hubo intervención manual, y no sé cuánto personal tienen para analizar cientos de miles de firmas.

En el caso de esta petición, hay “firmas fraudulentas”, la mía y de varias personas, pero siguen allí, y sin dar explicaciones. Responde como si estos casos no existiesen, roza el absurdo.

Nosotros no buscamos iniciar un proceso jurídico.

Ya, pero no se privan de contactar a todos los medios y agencias de noticias con titulares como Más de 700.000 personas firmaron la petición. Nadie firmó nada, y ni siquiera se puede asegurar que fueron todas “personas”, ni que los propietarios de las cuentas de correo siquiera hayan oído hablar de la petición.

Nosotros lo que hacemos es que después de firmar una petición el sistema te envía un correo electrónico de agradecimiento por firmar la petición. Si este correo se envía a una dirección inexistente, el mail rebota. Por lo que, entre cinco minutos y dos horas, esa firma falsa se retira.

Demostrado que se pueden usar emails diferentes, que son fáciles de generar “emails válidos” (imaginad que saque la lista de emails de mi buzón de entrada, puedo generar decenas de miles de “firmas válidas” en poco tiempo usando TOR (el ejemplo de arriba usa TOR, y ni detectan que sean IPs de TOR).

En el corro que envían tampoco hay un enlace para eliminar la “firma” de esa petición, solo para “anular” tu email (como creo que me pasó con gallir en uib.es del ejemplo).

En el caso de que tú introdujeras por ejemplo 20 correos electrónicos de gente que existe nosotros realizamos una comprobación manual y podemos ver que esos correos electrónicos provienen de la misma IP, entonces los retiramos. En el caso de que una persona firme por ti,

No lo he visto, ni explican cómo lo hacen, ni cuantas IPs diferentes tienen, por ejemplo, en sus peticiones más populares.

estamos ante un caso de “suplantación de la identidad”, algo que puede ocurrir en Twitter, Facebook… y que a nosotros nos ha pasado en un puñado de ocasiones desde la existencia de Change.org.

Ahora la culpa es de los demás, no de la debilidad de sus sistema de votos, diseñado específicamente para minimizar la “resistencia”, por lo que se fomenta este tipo acciones, que afortunadamente -¡oh, casualidad!- hacen subir los contadores. Además, no es suplantación de identidad, ni tiene nada que ver con Twitter o Facebook: se pueden poner datos falsos, y nunca hubo que confirmar ni un correo electrónico (como hacen todas las plataformas “serias”, desde Facebook hasta oiga.me).

Cuando eso ha ocurrido la persona se pone en contacto con nosotros y lo que hacemos es comprobar qué ha pasado. Si ha sido una verdadera suplantación, ayudamos a esa persona a hacer todas las comprobaciones y retiramos su firma. En el caso de que esa persona quisiera poner una querella contra quien ha suplantado su identidad, nosotros como cualquier otra organización, colaboraríamos con la justicia para esclarecer el caso.

Falso otra vez.

Todo esto comenzó porque detecté que usaron mi email para firmar la “famosa” petición al PP, es público, me respondieron (con excusas por Twitter y Google+), y me está respondiendo su director en un medio de comunicación. Pero no se pusieron en contacto conmigo para informarme nada de lo que había pasado, ni sé quién, dónde o cómo firmaron “en mi nombre” (esa y las demás que usaron también mi email). Otras personas también se quejaron de lo mismo, no he visto tampoco ninguna explicación sobre esas firmas falsas. Como si nunca hubiese ocurrido… exigen transparencia pero no dan ningún dato real, sólo excusas en el aire.

Si no tienes idea de la técnica, no publiques excusas tontas para desacreditar a un programador que te está indicando los problemas que tienes. No vaya a ser que se rebote y haga el programa para demostrarlo. En serio, es ridículo, y desperdiciamos tiempo todos.

Categorías:ética, internet, seguridad Etiquetas: , ,

“Firmas” falsas, falta de transparencia y controles en change.org, pero mucho autobombo

febrero 4, 2013 31 comentarios

ActualizaciónRespuesta al director de Change.org España

Hace dos días me quejé públicamente de que en change.org cuentan como que “firmé” peticiones aunque no lo había hecho, incluso la tan mediática del millón de firmas por la dimisión de la cúpula del PP. En el blog Ciencias y cosas recogieron esa info y la ampliaron con más casos. En vez de reconocer el problema, me acusaron de mentir y no comprobar antes de acusar, por lo que hice un vídeo demostrando lo fácil que era. Aún así, responsables de comunicación de change.org España negaban lo evidente y ponían excusas ridículas, llegando a decir que hay que confiar en la honestidad de los usuarios, y que tiene medidas de seguridad para evitar las firmas falsas.

A pesar de lo expuesto, sigo apareciendo como firmante en peticiones que nunca firmé (de todas en la que aparezco como firmante, sólo voté la primera, de hace más de un año, por la ley de transparencia) sin que haya un mínimo control, y a pesar de que tengo usuario creado (por lo que el control es más sencillo, exigir que esté autentificado). Responsables de change.org España reconocieron que es un problema, que “alguien votó por mí” (aunque otros llegaron a decir que “tengo problemas de seguridad con mi email” [sic]), pero ante la petición que hagan pública la lista de votante  la respuesta fue que no les permite la LOPD. Podría ser, pero en ese caso tampoco deberían pasar, como hacen, la lista al que inició una petición. No es de la empresa, es un tercero sin relación, y aún así accede a los datos.

Es ridículo lo de exigir transparencia y no cumplirla. Es ridículo saber que se pueden hacer trampas de forma tan sencilla, y aún así seguir saliendo en los medios asegurando que “más de 700.000 personas firmaron” cuando:

  • No es ninguna “firma”.
  • No se hacen controles para minimizar los abusos.
  • Hay evidencias de que hay “firmas” falsas, y lo reconocen (con la boca pequeña).
  • No hay el mínimo de transparencia, ni en el código ni en la lista de “firmantes”, en un sitio que presume de acciones éticas.

Están engañando deliberadamente.

A pesar de ello, no se hizo nada, ni se dieron respuestas. Ayer domingo me puse a trabajar analizando los controles que hacen en la web al momento de “firmar” una petición. El resultado fue un bot que publiqué anoche, que es capaz de firmar decenas de veces por minuto (sólo depende de la red y velocidad de servidores, en el ejemplo puse un retraso deliberado, para no sobrecargar los servidorees de change.org). Cuando lo publiqué había llegado a casi 100 votos de una petición “de prueba” en pocos minutos, inmediatamente empezaron a reducirse, no sé si por los controles “a posteriori” (aunque el contador ya se había incrementado). Luego hice pruebas con otra petición (creada por Alejandra Ventura), y se llegó al objetivo rápidamente, desde una instancia de Amazon en Irlanda.

Es decir, se pueden hacer trampas fácilmente, por el propio diseño e implementación de change.org. Ellos lo saben perfectamente, aunque lo nieguen en público, hay suficientes evidencias,  se niegan a ser transparentes poniendo como excusa la LOPD (que es razonable) al mismo tiempo que se contradicen permitiendo que un tercero baja la lista completa en PDF, pero no cesan en el autobombo y ruido mediático hablando de “personas que han firmado”.

Si exiges transparencia y ética, comienza por dar el ejemplo. Sobre todo si ya hay personas que se están quejando de sus “firmas” fraudulentas, y tu negocio se basa en hacerte publicidad con titulares mediáticos gracias a  la indignación y desgracias de los demás.

Tampoco vale lo de justificar mentiras y trampas porque el objetivo de las campañas son peores, no puedes ir exigiendo ética, responsabilidad y transparencia con métodos que se saltan las tres. Por otro lado, como dice Nicholas Taleb:

Si ves fraude y no le llamas fraude, eres un fraude.

Un podcast para sysadmins

noviembre 19, 2010 22 comentarios

Hay personas de tu “quinta” a las que conoces hace más de una década por su actividad en Internet y el software libre. Algunas de ellas son personas que casi nadie conoce, salvo un grupo de frikis informáticos (o fotógrafos) que le tienen un respeto casi reverencial. Algunas de ellas las aprecias como amigos de verdad aunque nunca tengas contacto directo, y sólo algún que otro comentario cruzado en algún foro.

Así pueden pasar años sin saber nada de esa persona, y un día, estando en apuros, esa persona te llama para apoyarte, ofrecer ayuda y darte información importante. Así, con el paso de los años descubres que el “mundo virtual” sí crea amistades reales, aunque nunca has podido desvirtualizarlas. Es eso lo que me pasó con David Hernandez, más conocido como Dabo.

Hace una semana por fin pude hacer algo, una tontería, por él (aunque no sé si es al revés). Dabo me pidió hacer un podcast sobre temas para sysadmins donde contase mi experiencia con Menéame, Amazon AWS, MySQL, servidores webs, etc. etc. Por supuesto le dije que sí. Dabo se preparó un enorme guión, lo trabajamos, nos enviamos decenas de correos, grabamos un día (más de tres horas), decenas más de correos, se tomó muchísimo curro para revisar la grabación, editarla y generar un índice de contenidos.

Finalmente acaba de publicarlo, un enorme podcast de 2 hs y 37 min: Kernel Panic, especial SysAdmin.

Yo no puedo escuchar mi voz, me descompone físicamente, así que no sé si es “digerible”, tampoco soy un gran sysadmin –lo hago porque es inevitable, aunque también tiene su punto de diversión y desafío– pero espero que sea útil. Para mi no fue ningún esfuerzo: hice lo que me divierte, hablar de lo que hago. El enorme trabajo es de Dabo.

Disfrutadlo, padecedlo, o pasad de él. Pero no echéis la culpas a Dabo, hizo lo que pudo ;-)

Mis dudas sobre el deface de Promusicae

diciembre 4, 2009 34 comentarios

Se está hablando mucho, y condenando, el deface al web de Promusicae. Dado el historial de manipulación de información, dilapidación de dinero público, falsas acusaciones, mala fe procesal de estos lobbies no me acaba de convencer del todo que haya sido un deface, es el momento demasiado oportuno para demostrar a los medios cuán malos son los “piratas”.

Así que me puse a mirar lo básico, descubrí que el deface era muy tonto. Esto es lo que encontré en la página principal (un fichero index.php):

La redirección hacia el fichero espanol.html (que tiene una copia del manifiesto) se hace en las primeras líneas, específicamente en:

<script type="text/javascript">
parent.location.href='espanol.html';	</script>

Es decir son dos líneas de JavaScript que las inserta un fichero PHP. Luego parecen estar los datos completos. Lo comparo con la versión actual del sitio ya “recuperado” y es el mismo código. Es decir, no se modificó el fichero index.php, sólo el espanol.html.

El fichero original (y actual) es sólo:

<html>
<head>
<title>Promusicae</title>
<!-- revised Mar 5, 2007 - Powered by www.dasai.es -->
<link rel="shortcut icon" href="favicon.ico" >
<link rel="P3Pv1" href="/w3c/p3p.xml">
<meta http-equiv="P3P" content='CP="CAO PSA OUR" policyref="/w3c/p3p.xml"'>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<frameset rows="*,0" frameborder="NO" border="0" framespacing="0">
<frame src="flashpage_pruebas.php?lang=espanol" name="flashframe" frameborder="NO">
<frame src="0.html" name="historyframe" frameborder="NO"></frameset>
<noframes><body bgcolor="#FFFFFF">
</body></noframes>
</html>

Un fichero muy pequeño que sólo define los frames y llama a otros dos ficheros.

Es decir, el deface consistió en subir y cambiar el fichero espanol.html al directorio de la página principal. Para ello se necesita un método para escribir ficheros en el directorio, bien porque tiene un problema de seguridad o porque tiene acceso como usuario del sistema, con privilegios para escribir en el directorio correspondiente.

Pero, ¿por qué no grabar ese fichero como index.html o index.php? Es lo habitual en estos caso, y se obtiene el resultado deseado de forma muy rápida, en poco tiempo y pocas conexiones.

Otra duda. Como se hackeó un sistema propietario no se tiene acceso a scripts ya preparados para atacar, por lo que el que lo hizo debía saber ser un especialista que no quiso causar más daños (podría haber borrado los demás ficheros). Este tipo de gente suele dejar mensajes llamativos y además firmado (del tipo “Lo hizo el Hax0rs Turkish t34M“) para que sus colegas del ambiente pudiesen verificar su logro. Pero tampoco hay ningún mensaje, el HTML que se subió es muy mecánico, con errores (por ejemplo le falta <body></body>) y que por las etiquetas parece un copy&paste chapucilla del manifiesto desde algún blog (y además se tomó el trabajo de borrar el nombre del programa generator):

Otras duda. El servidor estuvo con ese fichero varias horas, hasta que cerca de las 23 hs lo han parado completamente, pocos minutos después ya estaba nuevamente en marcha. Es decir, en poco tiempo han podido analizarlo, estar seguros que no hay otros ficheros modificados ni problemas de seguridad que permitirían repetir el ataque rápidamente. Si ha sido tan rápido tienen buenos técnicos, ¿por qué han esperado tantas horas para arreglarlo?

Entonces, ¿podemos estar seguros que fue un deface externo? No. Es muy raro la forma en que se hizo, el que lo hizo tuvo la elegante y solidaria precaución de no eliminar ficheros más complejos a pesar que el fichero del manifiesto podría haberse grabado directamente con index.php o index.html, no tiene “firma” habitual y lo han podido recuperar rápidamente… después de un tiempo prudencial sin tomar ninguna medida correctiva (¿el necesario para que saliese en la prensa?).

Con esas rarezas y el historial de manipulación, falsas acusaciones, mala fe procesal, etc. etc. de estos lobbies tengo mis serias dudas que sea un deface “de verdad” y no una “broma interna” [*] que podría generarles muy buenos titulares a favor. Hasta que la policia no intervenga y encuentre a los culpables no me creeré que haya sido un haxor, y si lo fue deberían agradecerle, fue muy benevolente y sólo se cargó un fichero irrelevante de 10 líneas, quizás sea un buen amigo.

Por ello me resistía a condenar el deface, porque sí que se es una mala táctica y perjudica a nuestros intereses, pero también sé que es muy fácil fabricarse [**] uno para lograr los mismos objetivos. No me extraña nada que la prensa lo haya dado por cierto (o caer en la propaganda en varios sitios [***]) sin siquiera recabar un poco de información, pero nosotros no deberíamos ser tan incautos con tanta experiencia a nuestras espaldas.

En todo caso, lo mío puede ser conspiranoia, sed escépticos y aplicad la Navaja de Occam (o recordad el Maine y la monja :-) )

[*]  Uso la palabra “broma” sólo porque existe una posibilidad de que tengan informáticos muy cachondos que quisieron gastarle una broma a sus jefes… o echarles una mano.

[**] Mucho más fácil y limpio que otras suciedades procesales, conseguir cientos de miles de euros en subvenciones para un sitio web cutre, o meter modificaciones a un proyecto de ley.

[***] Ya estamos acostumbrados a que equiparen copiar con robar, o a la propiedad intelectual con la de elementos físicos, pero que equiparen el borrado de un fichero con matar policías ya se sale de toda escala.

Categorías:blogs, internet, seguridad Etiquetas: ,

La larga cadena de errores del accidente del avión de Spanair

agosto 18, 2009 7 comentarios

Devoré entero Informe interino A-032/2008 (vía) sobre el accidente del avión de Spanair. El informe es apasionante a los que nos gusta el tema de la aviación. Pero además muestra claramente como los accidentes son una larguísima cadena de errores. En este caso la cadena comienza desde el propio diseño de sistema de la MD80, de los manuales, de las listas de comprobación, inconsistencias de las normativas y finalmente de los pilotos.

Intentaré resumir de forma sencilla lo que dice el informe. Perdón por los posibles errores o imprecisiones, lo escribo de memoria de las 96 páginas –bien densas– y [desfortunadamente] no soy piloto :-(

Básicamente el accidente se produjo porque los pilotos no habían desplegado los flaps (los alerones posteriores de las alas) y los slats (los delanteros) necesarios para el despegue. A eso se sumó un fallo del TOWS (Take-off Warning System), el sistema de aviso de configuración de despegue, que no indicó con alarmas que el avión no estaba preparado para despegar.

Por las conclusiones preliminares del informe, los pilotos han interrumpido la verificación de la lista After Start (después del arranque de los motores y de verificar que la zona está “limpia”). Justo antes de llegar a la verificación de los flaps la verificación se interrumpe para pedir autorización para rodaje. Luego no se vuelve a oir la palabra flaps. Éste fue básicamente uno de los problemas, pero no es totalmente achacable a los pilotos. Las listas de verificación no estaban bien diseñadas ya que items críticos están muy atrás en la lista y se produce en momentos que hay mucha actividad e interrupciones. Además hay que tener en cuenta que era la segunda salida después de la avería de sobrecalentamiento de la sonda de temperatura de aire exterior.

Como decía el TOWS que debía haber hecho sonar la alarma al acelerar los motores no funcionó. La razón era bien sencilla: estaba en “configuración de aire”. Hubo un fallo de un relé, el R2-5, que es parte del sensor de tierra del tren de aterrizaje delantero: cuando se detecta presión en el amortiguador se pone en estado de “sensación de tierra”, el TOWS sólo se activa en esta situación.

Pero aquí hay varios problemas. Según los manuales y normativas, el TOWS sólo debía verificarse al inicio del primer vuelo del día (ya lo han cambiado después del accidente para que se haga antes de cada vuelo) y los TOWS de los MD80, 727 y 737-200 no tienen un sistema para alertar a los pilotos que no funciona correctamente. Aunque hagan la comprobación el sistema podría fallar hasta el momento del despegue y los pilotos no se darían cuenta.

¿Por qué no tiene indicadores? Porque estaba considerado como un equipo de barrera adicional (backup), no como esencial, por lo que no tenía redundancia ni indicadores especiales (pero la otra contradicción es que está en la normativa como “Lista de Equipamiento Mínimo Maestra” –MMEL– por lo que es indispensable para poder despegar).

Y el problema de la falta de redundancia es que por el fallo de un simple relé –el R2-5– hizo que fallase el TOWS y no había forma que los pilotos se enterasen. Pero hay otra triste paradoja relacionada con este fallo que podría haber dado pistas pero que no estaba explicado en ningún manual.

Ese avión tuvo que abortar el despegue porque la sonda de medición de temperatura exterior –RAT (Ram Air Temperature probe)–  estaba dando mediciones muy altas –hasta 105 grados–. Eso ocurría porque se puso en marcha la calefacción estando en tierra cuando sólo debe funcionar en el aire, para evitar el congelamiento.

¿Por qué se encendió en tierra? Porque también depende de la misma configuración de vuelo o tierra que depende el TOWS. Este mismo avión había tenido ya varias averías de ese tipo –son difíciles de debuggear, más aún con el fallo intermitente del R2-5–. Tendría que haber dado una pista que el sistema se sensación de tierra estaba fallando, pero no estaba indicado en ningún manual.

Es sorprendente como un accidente tiene siempre una cadena de errores, incluso tan larga como éste (y abrevié bastante) que comienza con el propio diseño de algunos sistemas del avión y las imprecisiones y errores de normas y procedimientos. Son los problemas de ingeniería  de sistemas tan complejos, con interacciones humanas –las que hacen que funcione todo el sistema de navegación aérea– aún más complejas.

La buena noticia de este desastre es que a partir del accidente de Spanair se han lanzado varias recomendaciones para evitar que vuelva a suceder. La otra buena noticia es que los aviones más modernos tienen ordenadores que hacen varios de los controles que antes se hacía manualmente. Esos ordenadores llegan a simular el movimiento hacia adelante de los mandos aceleradores para verificar que el TOWS funciona correctamente.

Por último, me ha soprendido gratamente el informe. Me da la impresión que la investigación fue (y es, todavía continua) muy profesional y meticulosa. Además está escrita en un lenguaje tan simple que hasta un juez o fiscal podría entenderlo… bueno, perdón por la exageración :-)


Informe interino
A-032/2008

Mentalidad de seguridad

marzo 26, 2008 18 comentarios

[Esta forma de pensar]… No es natural para los ingenieros. La buena ingeniería incluye pensar cómo hacer funcionar las cosas; la mentalidad de seguridad en cómo hacer que fallen.

Frase concisa y cierta del ensayo de Bruce Schneier The Security Mindset. No puedo estar más de acuerdo, conozco a unas pocas personas –algunas de ellas amigos míos– que piensan de esa forma tan “retorcida” desde mi punto de vista [de pobre ingeniero].

De esta lógica, que me parece razonable, se deduce: los buenos ingenieros/programadores harán programas valiosos, pero por su propia forma de pensar tendrán bugs de seguridad.

Moraleja: busca el consejo de unos cuantos amigos/programadores/empleados que tengan “mentalidad de seguridad”, no vayas de chulo diciendo que tu software no tiene bugs hasta que lo hayan mirado y probado esos puñeteros retorcidos :-)

Gracias.. y perdón

febrero 27, 2008 55 comentarios

Hoy a las 12 hs entregué un largo resumen de 23 páginas como ampliación de las denuncias por los ataques DDoS (además del primer informe y de los resúmenes diarios que enviaba vía email).

Espero con esto dar por cerrado mi “trabajo” sobre el tema, y que pueda empezar a dedicarme a programar las cosas pendientes del Menéame y de mi minivaporware. No daré más detalles porque algunas de las acusaciones que hago son muy serias, incluyen amenazas graves a varias personas. Ahora que la policia y los jueces hagan su trabajo, que será largo y complejo por la cantidad de información. Pero estoy seguro que el resultado final de su trabajo tiene altas probabilidades de ser portada de periódicos.

Así que sólo me queda por agradecer a muchas personas, algunas de ellas:

  • Joel Chornik, de elserver.com, fue el que llevó toda la parte “policial” y legal en Argentina debido a que su empresa recibió largos ataques de DDoS. Joel gastó mucho tiempo y dinero para obtener información y además permitir que su empresa siga funcionando bajo la tormenta. Además lo hizo estando en un “entorno hostil”, asumiendo riesgos económicos y personales importantes. (Me parece que piensan instalarse en EEUU y España, os lo recomiendo, gente muy cachonda pero seria, enrollada y profesional).
  • A la gente de Ferca/Veloxia porque nos han permitido poner en línea otra vez el Menéame en menos de tres horas en medio de un ataque que duró cuatro días.
  • A un grupo de gente de aquí, del Menéame y de Argentina que colaboró en recopilar información e incluso en presentar denuncias y evidencias.
  • A todos los bloggers (módulo bobobloggers) que se han solidarizado, envíado emails o llamado por teléfono para dar apoyo e interesarse por el problema. Otros duplicaron la información de mi blog, aun a riesgo de sufrir ataques DDoS (algunos lo han recibido y han tenido el blog inaccesibles durante algunos días).
  • A la gente de WordPress que tuvo la “valentía” de permitirme seguir con mi blog a pesar de ser el objetivo de ataques DDoS, además lo han hecho sin pedirme nada a cambio, ni siquiera que cambie una coma de mis apuntes.
  • A la gente de Delitos Telemáticos –especialmente a Juan Salom– y a la Unidad de Policía Judicial de Baleares por interesarse por el tema y abrirme todos los “canales de comunicación directos” con ellos.

También pido perdón:

  • A la gente de Ferca y Veloxia porque los ataques afectaron a toda su infraesctrutura cuando podían hacer lo que es bastante habitual: cerrar al objetivo de los ataques.
  • A la gente de WordPress por lo mismo.
  • A la gente de Delitos Telemáticos, evidentemente no están dotadas para este tipo de problemas, seguramente les ocasionamos algunos agobios y frustraciones.
  • A los lectores de mi blog por dar el coñazo con el tema. Como atenuante podría explicar que fue algo al que dediqué mucho esfuerzo y que no podía dejar de comentarlo en mi blog, especialmente desde el momento en que han intentado confundirme o que no divulgue lo que sabía. Si lo hice en mi blog personal y no el Menéame es porque sabía que me movía en terrenos pantanosos por lo que quería hacerme único responsable de mis más que probables errores.
Categorías:blogs, internet, legales, seguridad Etiquetas: , ,

Ejercicio super mega interesante ¿saes? (los autores de los ataques DDoS)

febrero 16, 2008 183 comentarios

¿Cuál es la fake? Morgan versus Norman.

Por supuesto que está relacionado con los ataques DDoS, además al mejor estilo culebrón sudamericano. Tenemos los nombres, direcciones, teléfonos, direcciones IP… de todos los involucrados –el trío de oro– en los ataques a Genbeta, Weblogs, Menéame, elserver.com y decenas de sitios más.

Aunque ya están denunciados en España y Argentina, queremos hacer las últimas comprobaciones por nuestra cuenta. Las dos imágenes anteriores dan una buena idea de las dificultades televisivas que tenemos. Bueno, vale, aquí va un teaser al mejor estilo Play Boy. Para empatar.

Todo es dulce, como un río, como el azúcar de Cuba, modélico, y de la aldea de largas siestas. Que poético me salió el trailer :-P

Actualización: Morgan (se llama Cristian) me dejó este aviso, donde se confirma la IP que teníamos. Ya me cansaron estos niñatos que van de aprendices de mafiosillos. Cristian, llamé a tu casa (7:05 horas en Buenos Aires), no habías regresado de “bailar” por lo que no pude hablar contigo, pero tuve una agradable conversación con tu madre, ya sabe que estás denunciado. Habla con ella, hasta tiene mi teléfono.

Nota mental: para ser un buen mafioso lo primero es irte de las casa tus papis para que no les caigan marrones por algo que no tienen la culpa. También porque mafiosillos que viven con sus papis no es la imagen que se busca :roll:

Otra actualización: hace unos minutos, 7:35 horas de Buenos Aires, Cristian David me llamó por teléfono, sólo para amenzarme que iba a tirar mi blog si decía cosas que no le gustasen. Lo peor que podría haber hecho, no acepto que intenten “censurarme” con amenazas, y lo principal, es la confirmación que necesitaba. Ahora publico parte de los datos que tengo de estos personajes (algunos detalles omitidos para preservar la privacidad de su familia) y que los denuncié a la Guardia Civil como los sospechosos de estar relacionados con los ataques DDoS (además de presuntas amenazas y extorsiones):

Cristian Alberto David, alias Morgan, de 18 años, hermano de la conocida modelo
Cuba 2xxx piso xxxx
Capital Federal
Dirección IP, de Fibertel: 200.126.251.40
Una entrevista reciente donde cuenta sus “éxitos” (la han borrado, aquí la copia PDF, en estos momentos el sitio securityadiction.com está alojado en la IP 200.58.119.20, propiedad de Dattatec.com según el whois).

La primera imagen de arriba es una captura del momento que Morgan ejecutaba el ataque DDoS (de flood UDP) contra una IP alojada en elserver.com. El ataque es similar al que hicieron contra Menéame, Genbeta y otros blogs (me acabo de enterar que otro más hará la denuncia a la Guardia Civil).

El “norman” de la segunda captura retocada (su aprendiz según Cristian) es:

Omar Alejandro Brandán, alias Norman
Barrio Misky Mayu
La Banda, Santiago del Estero
Trabaja en el cibercafé La Aldea, en Belgrano 1116, Santiago del Estero

El tercero del trío es el ya mencionado Emilio Ribera, alias F3n|x, también de Santiago del Estero.

Ahora sí espero haber hecho los méritos suficientes para que Cristian David cumpla su amenaza de “dejarme sin mi blog” :roll:

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 428 seguidores