New question

Question:

Date: 07-04-2016 04:56:53 (In Spanish)

Debate sobre el Hacking de Panama Papers: malas prácticas y tecnologías solidarias[Resolved]

Este tema tiene algo de offtopic como así también de tecnología, seguridad, desarrollo, mejores prácticas, etc., y más alla de las implicancias mediáticas, abro un debate sobre las malas prácticas y tecnología solidaria que habilitaron el hacking.

Junto con Marcelo Pedra estabamos compartiendo ideas en Facebook, abro también el juego para La Comunidad, estos temas nos ayudan a pensar y repasar nuestras implementaciones (si todavía no sos parte de la comunidad, sumate aquí)

Transcribo mi comentario de Facebook:
Nota: contextualizo el comentario con un titular que decía "Outdated and Vulnerable WordPress and Drupal Versions May Have Contributed to the Panama Papers Breach"
Mi comentario: ...también hay que considerar tecnologías solidarias, en este caso quieren hacer titular con WordPress y Drupal, pero donde está el firewall? cómo el acceso a ese tipo de información no se bloquea por IP de Intranet (?), está lo publico y privado en el mismo servidor (?). Hay muchos aspectos a considerar a nivel infraestructura, como así también en desarrollo y customización de herramientas de terceros...

Espero que se pueda dar un debate profesional en todos los aspectos, cuidemos lo básico de la escritura y si tenemos dudas usemos el mataburros.

Muchas gracias por compartir opinión.

Saludos!
Tags: Best Practices - Debate - Drupal - Hacking - OFFTOPIC - Opinion - Penetration testing - Security - The Community - WordPress Votes: 4 - Answers: 3 - Views: 18 Share on: Google Facebook Twitter LinkedIn Link
 

Answers:

  • Date: 07-04-2016 05:23:08 Creo que el problema en casos como el que planteamos surge cuando una organización tiene que brindar acceso web a una intranet. La gente en general tiene la idea de que una intranet es sinónimo de "algo" que funciona en una red interna, privada. Pero la realidad es que la mayoría de los casos no sólo no hostea en la empresa la intranet, sino que muchas veces, --y sobre todo con la simplicidad que CMS modernos como WordPress permiten crearlas--, la intranet no es más que una sección de contenidos protegidos con un login. Y para colmo, muchas veces en un hosting compartido (shared), como fue el caso de Mossfon.com.

    Al menos nos sirven de excelente MAL EJEMPLO, por haber intentado proteger información sensible con versiones de CMS anticuadas.

    Muchos pueden alegar que cuanto más antiguo es el sistema en uso, más simple es su mantenimiento porque los hackers no esperan que uses una antigüedad para manejar sistemas críticos. Al menos eso es lo que piensan en la Fuerza Aerea de EEUU (ver nota), y eso puede ser válido cuando la interfaz de control no está conectada a Internet ni a ninguna red...

    Pero cuando manejamos aplicaciones web, la seguridad no debe ser algo secundario. Yo por ejemplo gestiono varios servidores web y es increible la cantidad de escaneos de vulnerabilidades que veo interceptar al firewall: no hay un solo minuto en que no estén intentando penetrar el sistema buscando todo tipo de vulnerabilidades, ya sea probando contraseñas por fuerza bruta, escaneando puertos abiertos, buscando open relays de smtp, buscando nombres de scripts y plugins en sitios web, e incluso tratando de adivinar rutas de login administrativo... Y doy fe que cuando una empresa usa un hosting shared no tiene noción de todas estas amenazas que ocurren tras bambalinas, pero que si bien la empresa de hosting puede hacer lo posible por detenerlos, nada impide que si tu contraseña es 12345 o si la aplicacion pública tiene vulnerabilidades, será cuestión de tiempo hasta que el bot correcto encuentre la combinación correcta.

    Y por último, en el caso de WordPress que es mi especialidad, dos medidas que dan mucho resultado sin ser complicadas son:
    1) Modificar la ruta de login. Cuando el login admin deja de ser wp-login.php ya los bots no tienen donde intentar logins.
    2) Modificar el prefijo de la base de datos. Porque incluso si hay una vulnerabilidad en plugins o themes, los intentos de XSS que van a hacer los bots van a apuntar a wp_nombretabla, pero si dejamos de usar "wp" como prefijo, ya toda query que intenten será infructuosa.
    Y lo más gracioso es que estas medidas pueden implementarse en tan sólo 10 minutos... Pero son muchas las empresas donde el encargado de la web no conoce esta información.

    Y recuerden, no todas las aplicaciones son inseguras. El problema se debe casi siempre a malas prácticas de los usuarios/admins. Y aprender a corregir eso puede un día salvar la empresa para la que trabajes.

    Saludos!
      Votes: 4 - Link answer
     
  • Date: 10-04-2016 00:52:35 Recapitulando el tema, me parece interesante aportar dos teorías que posiblemente convivan en la filtración de datos de los papeles de Panamá.

    La síntesis, recogida de dos enlaces, corresponde a lo expresado en diferentes artículos confrontados:

    ¿Cómo lograron 'hackear' los 'papeles de Panamá'?
    'Plugin' desactualizado
    "... La filtración de documentos pudo deberse a un 'plugin' desactualizado de WordPress llamado Revolution Slider y a una versión antigua de Drupal, un marco de gestión de contenidos usado por la firma en uno de sus sitios web.
    WordFence emitió un extenso blog explicando que los dos sitios web principales de Mossack Fonseca –una vitrina de sus servicios, basado en WordPress y un portal para clientes cuya finalidad era compartir información confidencial– usaban software que en algunos casos llevaba más de dos años sin actualizar, dejando abiertos varios atajos, que fueron los que usaron los hackers para robar la información.
    Por su parte, 'Wired' informa que Mossack no había cambiado su nombre de usuario en su portal web desde hacía tres años, algo que muchas empresas deben hacer de manera obligatoria, a veces incluso cada 30 días. El servidor del portal también usa el protocolo SSL v2, un protocolo de comunicaciones obsoleto que es susceptible de ser objeto de un ataque DROWN, un medio para cifrar mensajes individuales de un servidor. "


    Paralelamente, Jorge Luis Lara describe su teoría de la filtración.
    "... La respuesta para muchos podría ser que la información ventilada en el caso "The Panama Papers" la obtuvo uno o varios hackers sin embargo, Jorge Luis Lara explica que por la cantidad de datos revelados (2.6 terabytes), resulta casi imposible pensar que toda se consiguió a larga distancia.
    2.6 terabytes de datos no se mueven fácilmente de un lado a otro, dijo Jorge Luis Lara, experto en seguridad informática.
    Indicó que probablemente la filtración fue el fruto de una actividad realizada dentro de la firma Mossack Fonseca en Panamá o en alguna de las tantas oficinas que tienen en el mundo.
    Pero no solo el tamaño de la información es lo que sustenta la teoría de Lara, sino que muchos de los datos son antiguos, lo que indica que tal vez estaban guardados físicamente en dispositivos de almacenamiento como cintas magnéticas, discos duros y otros, que al sacarlos de las oficinas pudieron copiarse fácilmente."


    En todo caso, parece que el 'hackeo' de los 'papeles de Panamá' no fue extraordinariamente complicado salvo por su volumen.
      Votes: 2 - Link answer
     
  • Date: 10-04-2016 19:18:32 Que tal. Aporto una nota más que interesante sobre el tema:
    http://www.forbes.com.mx/asi-llegaron-los-panama-papers-la-nube-amazon/
      Votes: 2 - Link answer
     
To actively participate in the community first must authenticate, enter the system.Sign In