Como reportar una vulnerabilidad en un software o una web de forma efectiva

Muchas veces al navegar una web podemos encontrar errores, estos pueden ser simplemente de ortografía, un enlace roto o algún problema de seguridad.

Sobre los primeros problemas no habría mayor inconveniente, históricamente las webs tenían su famosa dirección "webmaster@...". Pero sobre los problemas de seguridad es un agujero negro en donde cualquier cosa puede pasar.

Al hablar de seguridad nos referimos a muchas cosas. Puede ser de una vulnerabilidad o problema inofensivo hasta algo realmente grave. Y hay muchas historias no muy agradables que hacen que muchos sean reticentes a reportar o que al hacerlo realicen ciertas acciones que generen más sospechas que tranquilidad.

Si bien no hay algo claro, definido y estándar, muchos aconsejan no reportar por experiencias negativas. Otros deciden hacerlo igualmente, pero en pocas palabras, todo depende de la situación.

Se puede recibir la grata respuesta de un agradecimiento, hasta una desagradable noticia de una acusación.

En principio no se debe considerar a la persona que reporta como un enemigo, ni tampoco como alguien que busca un perjuicio. Claro está todo depende de que es lo que reporta y que acciones realizó para llegar a esas conclusiones, si esas acciones son legales o no o en que circunstancias.

Podríamos escribir una guía o FAQ sobre cómo reportar bugs en Argentina minimizando riesgo legal del que reporta

— iarce (@4Dgifts) 29 de mayo de 2017

Una interesante guía para el reporte de vulnerabilidades es la que se encuentra en el GitHub de la Fundación Sadosky, la misma se denomina "Procedimiento para el reporte y difusión de vulnerabilidades" y permite aclarar un poco como manejarse de forma "correcta" evitando cualquier susceptibilidad.

Vale también aclarar que esto no quita que nuestra acción delate algún problema mayor o permita ser utilizada mal intencionadamente como chivo expiatorio de otra cuestión, es por esto que ya muchas personas han dejado de reportar, y de cierta forma termina volviendo todo más inseguro.

En 2011 Chema Alonso ha publicado algo al respecto muy interesante, crear un archivo similar a robots.txt pero para avisar las intenciones del administrador del sitio.

Por último una interesante guía es "The CERT Guide to Coordinated Vulnerability Disclosure", donde se desarrolla de forma bastante técnica el proceso de reporte de vulnerabilidades.

En conclusión, es importante entender las circunstancias y poder evaluar que es lo que corresponde, no hay de momento una receta ni esta todo tan estructurado de forma tal que otorgue garantías a ambas partes. Es por esto que si bien existen algunos documentos de referencia lo importante es la decisión que tome cada uno.

Cómo informarse de forma alternativa: por las redes sociales, por RSS y vía P2P

Tristemente los medios masivos de comunicación han caído en una decadencia de un nivel tan escandaloso que preocupa hasta al más desprevenido.

Ya las noticias relevantes se mezclan en una serie de noticias irrelevantes pero que llaman la atención, que generan click-bait o que simplemente están pensada para los anunciantes.

Esta realidad (terrible) está poco a poco afectando a los sitios de noticias en la web. Es decir, si bien uno podía escapar a la televisión de a poco las mismas técnicas se están utilizando en los principales portales de noticias.

¿Que alternativas tenemos?

Pues la solución es simple: participar.

Daré algunos ejemplos.

1. Podemos tener nuestro propio blog (se puede hacer gratis en Blogger o Wordpress.com), donde nos generamos nuestro recorte de las noticias que consideramos relevantes. Acá simplemente podemos compartir el titular con una síntesis y una reflexión propia, y el enlace a la noticia.
2. Participar en redes sociales (o agregadores de contenidos como reddit o meneame), donde compartimos lo del punto 1 y/o las noticias relevantes de los medios. Esto implica usar las redes para debates importantes y no superfluos o inconducentes.
3. Ayudar a otros bloggers a compartir su material relevante, esto lo podemos hacer con distintos sitios tomando su RSS y re publicándolo automáticamente en las redes de esta forma estamos dando una ayuda muy grande a estos usuarios. Claro está debemos confiar en el criterio de lo que publican.
4. Pensar en las redes sociales como el lugar donde está la gente, pero que el debate se de en nuestro sitio. Esto es así porque dado los algoritmos que utilizan las redes sociales para publicar el contenido algún material puede ser poco relevante y por lo tanto no publicarse. Si nosotros nos "aseguramos" un canal alternativo como RSS y/o la suscripción a una lista de correos es más probable que puedan acceder.
5. No alimentar sitios que no benefician la libertad de expresión, ni priorizan contenidos de calidad. Con esto me refiero a que pensemos que mucho contenido relevante puede estar perdido por no ser un sitio conocido, y a la vez se priorizan sitios "importantes" que no cuentan con contenidos de calidad u originales donde muchas veces solo buscan generar visitas.

En fin, esta pequeña lista nos puede ayudar para encontrar otra forma de ver la web, en la actual era de las redes sociales y los portales con contenido pobre.

Filtran el código fuente del sistema de Voto Electrónico utilizando en Salta (Argentina) y lo auditan públicamente usuarios de Twitter

Tal como se lee en el diario La Nación, han filtrado el código fuente del sistema de Voto Electrónico utilizado en la provincia de Salta.

Lo mismo dio pie a que muchos usuarios estudien el código en búsqueda de fallas.

Si algún diputado o senador o autoridad electoral contesta correctamente le regalo entrada a @ekoparty
Hay algún problema en este código? pic.twitter.com/OUqaFbaGBY

— iarce (@4Dgifts) 19 de agosto de 2017

Mirando 2 minutos el código de vot.ar encuentro este tipo de cosas en el primer archivo que miro. Va a ganar Ricky Fort las elecciones. pic.twitter.com/FkKTMD2qEg

— Manuel Aráoz (@maraoz) 19 de agosto de 2017

Desde el vamos tienen bugs conocidos a un bandit de distancia https://t.co/AY4Bk2IizL

— todoesverso (@todoesverso) 18 de agosto de 2017

Si bien es correcto que los elementos utilizados en una elección puedan ser auditables por toda la ciudadanía, al parecer esto no fue algo oficial, pero de cualquier forma plantea distintas cuestiones referentes al manejo de información que sufren los votantes de este tipo de sistemas.

Desafío para romper el "sistema a de Voto Electrónico inviolable" por parte de Blue Frost Security

Se acerca la conferencia de Seguridad Informática Ekoparty y uno de los sponsors ha decidido regalar entradas a quiénes realicen correctamente un desafío.

Se trata de un "sistema de Voto Electrónico inviolable" y se basa en realizar ingeniería inversa sobre un binario proporcionado en su sitio web.

Ganate entradas para la @ekoparty hackeando la inquebrantable máquina de votación. #eko13 https://t.co/uQYqOP83aB pic.twitter.com/m0pAyQXhtB

— Blue Frost Security (@bluefrostsec) 2 de agosto de 2017

Los guiños están por donde se los mire:

• Los candidatos son Trump, Menem y Zulma Lobato (?).
• El sistema es "inviolable" pero el desafío es romperlo.
• Hay una referencia a un sistema "sin memoria".

La empresa ya ha anunciado los ganadores en Twitter, los que accedieron a una entrada gracias a su capacidad de resolver este tipo de desafíos.

La historia de los legisladores antivacuna homeópatas en la Argentina

Cuando la ignorancia es grande, fácilmente la gente es engañada.
El tema surge cuando los que son engañados (o son participes del engaño) son nuestros representantes: los legisladores de un país.

Ese fue el caso que surgió en Argentina. A fines de Junio del 2017 se debatió en las redes sociales sobre un proyecto de ley presentado por la legisladora Paula Urroz en el cual la vacunación se transformaba en algo opcional por parte de los ciudadanos.

A ver, analicemos un poco.
La vacunación tiene la finalidad de proteger no solo al individuo que se la aplica sino a toda la población, es decir protege aspectos de la Salud Pública.
Si todos nos vacunamos hacemos que la población en general sea menos propensa a enfermarse.

Es ahí donde deja de ser un acto individual y pasa a ser algo colectivo en pos de toda la sociedad.

Bueno, los medios han tomado el debate y muchos médicos describieron el problema de hacer "opcional" la vacunación.

Los legisladores que avalaron esto, según la información de la entrada de Javier Smaldone, son los siguientes:

• Urroz, Paula Marcela.
• Acerenza, Samanta María Celeste.
• Villavicencio María Teresita.
• Nuñez, José Carlos.
• Schmidt Liermann, Cornelia.
• Barletta, Mario Domingo.
• Hernández, Martín Osvaldo.
• Goicoechea, Horacio.
• Wisky, Sergio Javier.
• Wechsler, Marcelo Germán.
• Lopardo, María Paula.
• Pretto, Pedro Javier.
• Sorgente, Marcelo Adolfo.
• Raffo, Julio.
• Poggi, Claudio Javier.
• Conesa, Eduardo Raúl.
• Martínez, Ana Laura.

Lo interesante de todo esto es lo que está detrás. En el fondo, la ignorancia de la gente y sus enfermedades terminaba siendo un nuevo negocio para una gran estafa de la homeopatia (una pseudociencia).

10 cosas que debes hacer para que tu trabajar en equipo sea tremendamente ineficiente

El trabajo en grupos de trabajo es muy enriquecedor, pero  ciertamente muchos no lo consideran así, y empiezan a tomar actitudes egoístas sin tener en cuenta que se perjudican a ellos también.

Una lista de NO recomendaciones al trabajar en equipo. Es decir, cosas que nunca deberías hacer, pero que (por desgracia) se  hacen frecuentemente:

1. Arma tu "quintita": aprende a hacer algo pero que solo tu lo puedas hacer y nadie más. Todos dependerán de vos. No habrá independencia y te asegurarás tu trabajo.
2. Genera la necesidad: no hay nada mejor que la gente sepa que necesita de vos. Para eso, puedes apagar uno o dos servidores de vez en cuando, total nadie entiende del tema.
3. ¡No Documentes!: documentar es para gente que quiere compartir su conocimiento en pos de la mejora de todo el grupo de trabajo... ¡uds. es egoísta!, revise el punto 1.
4. No hagas las cosas de inmediato: ya que si así lo hace le pedirán que tenga el mismo tiempo de respuesta ante incidentes similares. Demore más de lo necesario para que aprendan a valorar tu trabajo.
5. Nunca explique lo que hace o como soluciono el problema: no vaya a ser cosa que luego lo puedan resolver solos.
6. Cobre según el cliente: porque nosotros somos más listillos que ellos y sabremos que nunca se darán cuenta si hacemos estos cobros diferenciales.
7. Utilice palabras técnicas: sirve para que el cliente piense que sabemos mucho.
8. Di las cosas, pero no de forma completa, que tus compañeros no terminen de entender como se hacen las cosas: así siempre nos volverán a preguntar.
9. Muéstrate colaborador cuando te vean los superiores: por supuesto que ellos tampoco se darán cuenta, porque nosotros somos más inteligentes que todos.
10. Nunca piense en el cliente, solo piense en uds: porque como nosotros somos indispensables no vale la pena pensar en la calidad del servicio.

 Así que fácilmente con esta pequeña lista podrás ver como la empresa donde trabaja se desarrolla de forma muy lenta en comparación de otras donde la información fluye y realmente se trabaja en equipo considerando que TODOS ESTAMOS EN EL MISMO BARCO.

Malware en GNU/Linux

Uno de los grandes mitos informáticos es que en GNU/Linux no hay malware. La realidad es que esto no es así. En este sistema operativo hay malware. En otras palabras, cualquier sistema operativo puede ser susceptible a tener malware.

Se entiende como malware a cualquier programa "mal intencionado" es decir, que no hace las acciones esperadas o deseadas por los usuarios.

Linux no es la excepción, pero hay dos factores interesantes a considerar de porqué esto no sucede.

En primer término el sistema operativo no es usado de forma tan masiva como si lo son los sistemas de Microsoft (Windows), esto hace que para los atacantes no sea tan atractivo atacar sistemas operativos Linux.

Por otro lado hay otro factor a considerar. Dadas las propias características de como se estructura el sistema operativo desde su diseño, así como los sistemas de permisos en el sistemas de archivo, hacen que (en caso de que se use de forma correcta) sea bastante complejo que el malware genere ataques efectivos.

¿Pero porqué se dice "en caso de que se use de forma correcta"? Pues porque se debe contar con cierto conocimiento para poder hacer las cosas bien. Esto, por ejemplo, implica que cada aplicación que ejecuta un "daemon" lo realice con un usuario propio sin privilegios especiales, de esta forma nos aseguramos que solo podrá acceder a los lugares del sistema que debería acceder. Un error muy común es ver servicios ejecutas como "root".

En resumen, no hay que confiar ciegamente en cualquier programa de Linux, como tampoco en cualquier otro sistema operativo.

Una cuestión interesante es que los sistemas GNU/Linux soportan el comando chroot el cual permite "enjaular" un proceso para que no afecte al resto del sistema.

A su vez existen programas antivirus como ClamAV como antirootkit como rkhunter.

Saber paquetes instalados en distribuciones Debian / Redhat (y cantidad)

Las distribuciones de Linux manejan sistemas de empaquetados. Los mismos son utilizados para instalar el software desde los repositorios.

Un aspecto interesante a tener en cuenta es que es recomendable tener solo los paquetes necesarios, principalmente en servidores "en producción". ¿Porqué?, para tener el mínimo punto de exposición. Es decir que cuanto menos software se encuentre instalado o ejecutándose menos probabilidades de que existan fallas. Algo relacionado al concepto KISS.

Pues bien, para distribuciones basadas en Debian (paquetes .deb) podemos ejecutar lo siguiente:

dpkg --get-selections | grep -v deinstall

Ahora para distribuciones basadas en Red Hat (RPM) el comando es el siguiente:

yum list installed

Si a e estos comandos le agregamos " | wc -l " podremos obtener la cantidad de paquetes instalados.

¿Qué es la Capa 8?

La capa 8 es ud.
Si, si le dijeron que hay un problema en la capa 8, le quisieron decir que hay un problema entre la computadora y la silla.

En otras palabras.
Los sistemas no siempre están pensados para que sean usados por cualquier persona, en efecto... CUALQUIER PERSONA usa los sistemas, y eso los vuelve impredecibles.

Tal vez una de las cuestiones más complejas al desarrollar es entender que tantos errores puede cometer el usuario al usar el sistema para preverlos (por ejemplo en validación de campos).

En fin, no se ofenda si le dicen que el problema es de "Capa 8", es lo más común.

¿Y porqué capa 8? pues, por el modelo OSI, que es el que se utiliza para la arquitectura de las redes de computadoras.