viernes, 13 de mayo de 2016

Medicinas para levantarle el ánimo a tu aplicación de código abierto (1)

Con frecuencia, quienes vulneran la seguridad de un sitio web introducen en él modificaciones sutiles, no visibles para los usuarios normales. Cambios que suelen pasar inadvertidos incluso a los administradores de sistemas con objeto de evitar ser eliminados. Un ejemplo sería la inclusión de enlaces invisibles con objeto de promocionar ciertas páginas web, técnica ampliamente utilizada por los amigos del lado oscuro del SEO. Vamos, lo que siempre se ha llamado "defacement" pero en plan discreto.

Tarde o temprano, estos individuos tenían que encontrarse con los repositorios de software libre, esos sitios web que tratan de convertirse en paraísos para los desarrolladores ofreciéndoles todo tipo de servicios y funcionalidades: trabajo colaborativo, gestión de versiones, repositorios de conocimiento, páginas web personalizadas para los usuarios y los proyectos, sistemas de gestión de bugs,... Cuanto pueda pensarse y un poco más.

Algunos son, además gratuitos. Tal es el caso de Github, SourceForge, o Bitbucket. Y "gratuito" es una palabra que, en lo que respecta a Internet, debe dar siempre que pensar.

Un servicio gratuito bajo un dominio que disfruta de buena reputación ante los buscadores y que permite crear sitios web personalizados, alojar ficheros de texto o con código y todo ello sin cometer delitos castigados por el código penal...

Muchas veces, cuando los ciberdelincuentes consiguen vulnerar un sistema, en lugar de modificar directamente su código según deseen, le añaden código que descarga desde un tercer sitio los cambios que hay que realizar. De ese modo tienen un "centro de mando" único desde el que actualizar sus redes de sitios web zombies. ¿Utilizará alguien algún repositorio de software libre para estos fines?

 Se puede comenzar tratando de buscar en Sourceforge documentos de texto que contengan código HTML con referencias a algún medicamento (por ejemplo, la Levitra) y enlaces:
site:sourceforge.net "levitra" "a href"

Lo que se encuentra, al menos cuando estoy escribiendo esto, no es exactamente lo que se pretendía:

ATENCIÓN: Pruebas como ésta hay que hacerlas con cuidado, que nunca se sabe quién anda detrás de todo esto. ¡NIÑOS: NO INTENTÉIS HACER ESTO EN CASA! Y si alguien lo hace, que tome sus precauciones y que no se extrañe si alguna vez le salta el antivirus. 

El caso es que si se hace clic en el enlace del resultado, que incluso tiene una buena valoración en SourceForge (4,6 sobre 5 y 705 reseñas) se descargará una página que ejecuta código JavaScript que descarga de un tercer sitio y que fuerza una redirección que al final te lleva a una página ajena a SourceForge:

La URL proporcionada por Google corresponde a la web de un  projecto de SourceForge llamado bombusmd. Como ya sabréis, para ver y/o descargarse el código de un proyecto de este repositorio se usa una URL que comienza por "https://sourceforge.net/projects/" y a continuación se pone el nombre del proyecto. No voy a ponerle un enlace aquí por razones obvias. Eché un vistazo y...

El proyecto está vacío: ni descargas, ni ficheros con código, ni wiki, ni tickets. Nada de nada. El autor tiene un segundo proyecto y ... lo mismo. Eso sí, el sitio web de este otro proyecto si lleva lo suyo

Es un argumento que se repite: creación automatizada de cuentas, creación de proyectos vacíos, población de los sitios web de los proyectos con contenidos para promocionar páginas web... y a volver a empezar. Y, mientras tanto, unas cuentas van votando a otras para ganar estrellas. Todo ello de forma automática.

¿Y por qué no? Al fin y al cabo, les sale gratis.

Otros, en lugar de aprovecharse del sitio web del proyecto, utilizan el de su cuenta de usuario:

Y hay más variantes. Ya las iremos viendo. Por hoy acabaremos con unas notas sobre una cosa que posiblemente sepáis, pero que creo que siempre está bien dejar por ahí. SourceForge tiene una API y un sitio donde leer su documentación y jugar con ella. Esto permite obtener, por ejemplo, datos sobre un desarrollador a partir de su nombre de usuario con URLs como:

https://sourceforge.net/rest/u/_nombre de usuario_

O
https://sourceforge.net/rest/u/_nombre de usuario_/profile

Claro está... los datos que él haya puesto.

jueves, 12 de mayo de 2016

Los cuñados de Facebook

Sigo aquí con otro pequeño truco por si alguien se encuentra con el mismo tipo de problemas que he ido viendo al hacer búsquedas en Facebook.

Comentaba hace poco que la búsqueda mediante URLs en Facebook no siempre funciona como es de esperar. Y que, en particular, dan problemas las relaciones familiares en las se distingue por sexo, tales como hermanos y hermanas, padres y madres, etc. Sus correspondientes operadores (bothers, sisters, fathers, mothers,...) al aplicarlos a un conjunto de resultados suelen obtener como respuesta una página con un indicador de progreso... que nunca llega a su fin.

En aquel post daba algún truco que me funciona cuando Facebook ofrece un operador de género neutro, tal como "parents" o "siblings". Pero hay ocasiones en que este enfoque no es aplicable. Así, Facebook ofrece los operadores "brothers-in-law" y "sisters-in-law". Pero, que yo sepa, no hay nada del tipo "siblings-in-law".

Tomemos, por ejemplo, a la propia Facebook. Si, desde España, visito "https://facebook.com/facebook", soy redirigido a "https://www.facebook.com/FacebookEspana/?brand_redir=20531316728". O sea, Facebook me redirige a la página de "Facebook España". Con eso tengo dos IDs para jugar: el 20531316728, correspondiente a la página genérica de esta empresa y el que puedo encontrar en el código fuente de la española, 171516302294. Sigamos con este último.

Si ahora quisiera obtener un listado de cuñados de personas que trabajan en Facebook, podría pensar en la URL

https://www.facebook.com/search/171516302294/employees/brothers-in-law

Pero, como en aquel post anterior, la respuesta se me queda atascada y no acaba de llegar:

Curiosamente, sí que se obtiene una rápida respuesta si la búsqueda incluye tanto a cuñados como a cuñadas. Para eso se puede usar el operador "union" que, aplicado a dos o más conjuntos de datos, proporciona todos los elementos pertenecientes a cualquiera de ellos:

https://www.facebook.com/search/171516302294/employees/brothers-in-law/171516302294/employees/sisters-in-law/union


Pero si después, de forma parecida a lo que comentaba en el post anterior, intento hacer la intersección de este resultado con "males" o "females", vuelvo a ser testigo de como un círculo no deja nunca de girar y los resultados no aparecen.

Así que hay que probar otras cosas. Por ejemplo, podemos preguntar a Facebook si conoce a alguien que se llame "aqzSEc" con

https://www.facebook.com/search/str/aqzSEc/users-named

Y la respuesta será que no:

Si ahora le pedimos que nos de una lista de las personas que se llaman "aqzSEc" o bien sean cuñados de gente que trabaje en Facebook...

https://www.facebook.com/search/171516302294/employees/brothers-in-law/str/aqzSEc/users-named/union

¡Tacháaaaaan!

Y, claro, si lo que buscas es cuñadas, te puede valer

https://www.facebook.com/search/171516302294/employees/sisters-in-law/str/aqzSEc/users-named/union

Este enfoque me puede servir también para otros operadores que den problemas al aplicarlos a grupos, tales como "hometowns", "current-cities", etc. Sólo que habrá que hacer la unión con un conjunto del mismo tipo de datos (lugares en los casos citados):

https://www.facebook.com/search/171516302294/employees/current-cities/str/aqzSEc/places-named/union

En cualquier caso, hay que decir que no es que se obtenga un gran número de resultados. Pero algo es algo...

martes, 10 de mayo de 2016

Un truco para las búsquedas en Facebook

Con frecuencia, los tests de penetración de hoy en día involucran ataques de ingeniería social. Y en estos casos puede ser de gran importancia conocer las relaciones personales y familiares de las pesonas que forman parte de la organización objetivo.

Una tarea en la que Facebook puede ser de utilidad. Así, si el ID de la página de Microsoft es 20528438720 y el de Madrid es 106504859386230, se puede obtener una lista de quienes trabajan en Microsoft y viven en Madrid con

https://www.facebook.com/search/20528438720/employees/present/106504859386230/residents/present/intersect


Y, en teoría, se podría obtener una lista de, por poner un ejemplo de relación familiar, sus hermanas con:

https://www.facebook.com/search/20528438720/employees/present/106504859386230/residents/present/intersect/sisters

Pero cuando lo intento, la página siempre se queda mostrando el típico indicador circular de progreso que no cesa de girar. Y nunca llega a mostrar los resultados.



En general, me ocurre con aquellas relaciones familiares que conllevan distinción de sexo: padres y madres, hermanas y hermanos, etc. O, si queremos citar los operadores utilizados en las URLs de búsqueda de Facebook: brothers, sisters, fathers, mothers, sons, daughters, aunts, uncles, etc. Y también con otras cosas, como las ciudades y otras ubiaciones geográficas (current-cities, current-regions, current-conuntries, hometowns,...).

Con lo de los familiares, al menos para ciertos tipos de relaciones, se puede recurrir a un pequeño truco: Existen otros operadores que no conllevan distinción de sexo: siblings, que engloba a brothers y sisters, parents, que hace lo propio con fathers and mothers, etc. Y también existen dos generadores de conjuntos, females y males, que, junto con el operador de intersección, pueden hacer el trabajo. Las URLs son algo más largas pero funcionan, que es lo que se espera de ellas.

Con esto, para la lista de hermanas de empleados y empleadas de Microsoft que viven en Madrid serviría algo del tipo:

https://www.facebook.com/search/20528438720/employees/present/106504859386230/residents/present/intersect/siblings/females/intersect


Quizá poco a poco, pero con esto sí que van apareciendo los resultados. Resultados que después deben ser objeto de comprobación y cotejo porque, como comentábamos hace poco, la gente suele poner cosas "ingeniosas" en sus datos de Facebook y no es raro que, sin ser cierto, indiquen que trabajan para una empresa popular.

Las aplicaciones seguras de verdad no se olvidan de las cabeceras HTTP

Heartbleed cambió algo en el "mercado" de la seguridad. Es verdad que vulnerabilidades con un llamativo nombre propio las hubo antes (se me viene a la cabeza aquel "Ping de la muerte" de finales del siglo pasado), pero Heartbleed llegó un momento en que el mercado de la seguridad mueve dinero y la publicidad es parte del negocio. Si previamente las cosas eran llamadas MS08-068 o por el estilo, ahora en cuanto se descubre algo, aunque no sea demasiado relevante, se le pone nombre, se le crea una página web e incluso se le compone una canción.

Y es que los nombres son importantes y pueden cambiar la forma en que vemos las cosas. Recuerdo los viejos tiempos, cuando supe por primera vez de las "Active Server Pages" (ASP) o, algo después, de PHP. A ambos sistemas se les categorizaba como "generadores de páginas web dinámicas".

Puede que a primera vista no lo parezca, pero llamarles de ese modo tiene sus implicaciones para la seguridad de los sistemas. Porque puede hacer que los desarrolladores centren su atención en sólo uno de los aspectos de la creación de aplicaciones basadas en estas tecnologías: la generación de páginas web. De código HTML. En otras palabras, en la creación de un documento.

Y, claro, se dejan atrás de otras cosas que también deberían ser parte fundamental del programa. Como la forma en que el documento es transmitido. Porque no se debe olvidar que existe un buen número de cabeceras HTTP cuya configuración puede afectar, y mucho, a la seguridad de la aplicación final.

Aunque ninguna protección es, por sí sola, suficiente para garantizar la seguridad de una aplicación, cosas como la cabecera de HTTP "X-Frame-Options" ayudan a evitar ser víctimas del ClickJacking. Igual que "X-XSS-Protection" puede configurar el comportamiento del navegador (si es que dispone de filtro anti-XSS) ante posibles XSS reflejados. O que "X-Content-Type-Options" puede evitar que el content sniffing se convierta en un problema con ciertas versiones de ciertos navegadores. O que "Cache-Control", o su hermana de HTTP 1.0 "Pragma", puede evitar que información confidencial quede guardada en los "archivos temporales de internet" o como en cada caso se llame. O que "Strict-Transport-Security" permite controlar el uso de HTTPS. Y, para acabar, ahí anda esa solución de carácter general, la Content Security Policy.

Y seguro que me he dejado un montón de cosas en el tintero. Un buen programa (y un buen programador) debería hacer uso de estas herramientas o, como poco, permitir al administrador de la aplicación configurar las cabeceras y avisarle en caso de detectar unos ajustes que pudieran suponer un riesgo.

Ciertamente, tratar con las cabeceras HTTP añade líneas de código. Y las cabeceras tienen sus variantes, derivadas de distintas versiones o de detalles de implementación propios de cada navegador, etc. Es necesario que la implementación tenga todo esto en cuenta y genere valores consistentes entre aquellas cabeceras que estén relacionadas entre sí o que configuran un mismo comportamiento.

Pero nadie dijo que esto de escribir programas fuera sencillo.

domingo, 8 de mayo de 2016

Según Facebook, la NASA es un lugar divertido donde trabajar

A veces uno tiene tiempo y no sabe qué hacer. Así que inicia sesión en Facebook y busca algo interesante. Por ejemplo, acerca de la NASA.

Los primeros pasos ya son conocidos a estas alturas: se pone "NASA" en la barra de búsqueda de la red social, se selecciona entre los resultados la página de la conocida agencia espacial y se localiza en su código fuente la cadena "fb://". Poco después aparecerá su ID.


El ID es, por tanto, 54971236771. Ahora se podría pensar en obtener una lista de empleados de esta organización con la URL:

https://www.facebook.com/search/54971236771/employees

Esto nos daría tanto el personal antiguo como el actual. Si sólo nos interesa quienes trabajan a fecha de hoy en la NASA se podría poner

https://www.facebook.com/search/54971236771/employees/present

Y, para los ya retirados

https://www.facebook.com/search/54971236771/employees/past

¿Que a qué viene todo esto? A una reflexión que quería hacer sobre el valor de la información obtenida en aquellas fases que conllevan obtención de datos. Habrá cosas en las que se pueda confiar y otras en las que no. Y será necesario saber determinar el grado de validez de cada una,

Por ejemplo, quizá sepas que los datos corresponden a una persona con unos determinados nombre y apellidos pero no tengas seguridad de que sea la misma sobre la que intentas informarte. O que los datos sean antiguos y pudieran haber cambiado desde entonces. A estas cosa, que nos dificultan una visión correcta del problema, las podríamos llamar "generadores de ruído".

Parte de este ruído es involuntario. Nadie ha hecho nada para que esté ahí. Quizá en su día fuera "información buena". Pero hay otro, que podríamos denominar "contaminación" que, ya sea con o sin intención de dificultar investigaciones, se ha introducido de forma deliberada. Y para muestra, ahí va un botón:

Igual que se obtuvo el ID de la página de Facebook la NASA, se puede conseguir el correspondiente a la página del puesto de trabajo "Stripper". Su URL es

https://www.facebook.com/pages/Strippers/112231702136450

Y el ID es, ¡oh, sorpresa!, 112231702136450. Por cierto, que ésta página es una de esas ocasiones que he tendrás de ver un topless en una página de Facebook.

Supongo que ya imaginaréis de que va el resto. Sabiendo el ID de la NASA y el ID de la profesión "Stripper", se puede sacar una lista de bailarinas y bailarines exóticos que trabajan en la agencia espacial americana con

https://www.facebook.com/search/112231702136450/employees/54971236771/employees/intersect

O

https://www.facebook.com/search/112231702136450/job-liker-union/employees/54971236771/employees/intersect

Todo va en una línea. No sé lo que hará Blogger con lo que escribo.

La verdad es que no salen demasiados resultados, pero algunos hay. Además, posiblemente haya varias páginas de profesiones con para "stripper", así que podemos hacer la búsqueda no por ID sino por cadena de texto

https://www.facebook.com/search/str/stripper/pages-named/employees/54971236771/employees/intersect

Y ahora sí que hay un montón


Seguro que a estas personas les pareció divertido poner este tipo de cosas.


La moraleja es que si alguien intentara obtener datos de empleados de la NASA, o de otras organizaciones populares, posiblemente debería mirar primero, en lugar de en Facebook, en LinkedIn, donde se suele mentir menos sobre los puestos de trabajo y mucho más sobre el nivel de Inglés hablado y escrito.

NOTA: No sé si a alguien le extrañará, pero en la NASA parecen trabajar más strippers hombres que mujeres, como puede comprobarse con las siguienes URLs, que aplican el operador "intersect" a tres operandos:

https://www.facebook.com/search/str/stripper/pages-named/employees/54971236771/employees/females/intersect

Y

https://www.facebook.com/search/str/stripper/pages-named/employees/54971236771/employees/males/intersect

jueves, 5 de mayo de 2016

No hace falta que tú lo hagas (9)

No quería acabar esta tanda de posts sobre Facebook sin mencionar otra fuente de fuga de datos relativos a personas que no han hecho nada para merecerlo. Porque no sólo de amigos se rodea uno.

Los grupos a que pertenece un usuario permiten determinar aficiones, gustos y actividades a las que se dedica tiempo. Y puede encontrarse un enlace que los muestra en la página del perfil, bajo el menú de "Más" ("More" en inglés).


En este caso aparecía sólo uno a un grupo de compra-venta de artículos. Relativamente poco revelador salvo. quizá. si en él aparecieran anuncios o comentarios realizados por la persona. Y las URL de búsqueda de Facebook también permiten localizar este tipo de cosas.

Para empezar, se necesita el ID del grupo, que puede ser obtenido de forma similar al de un usuario: mirando el código fuente de la página y buscando "fb://":

El número que sigue a "fb://group/" es lo que buscamos. Y armados con él es posible encontrar los posts publicados en él con una URL del tipo:


https://www.facebook.com/search/_ID del grupo_/stories-in

Por su parte, los posts publicados por una persona pueden localizarse con 

https://www.facebook.com/search/_ID de la persona_/stories-by
Y ahora viene lo bueno... el lenguaje de las URL permite obtener la intersección de dos conjuntos de resultados. Dicho en román paladino: aquellos elementos que son comunes a ambos. Y para ello se proporciona un operador llamado "intersect". Y, por lo general, este lenguaje utiliza lo que se llama "notación polaca inversa". O sea, que primero se ponen los operandos y al final se pone el operador, quedando

https://www.facebook.com/search/_ID del grupo_/stories-in/_ID de la persona_/stories-by/intersect


¡Quién sabe! Puede que en alguno de ellos haya una dirección o un teléfono u otro dato. Pero eso quedaría fuera del ámbito de esta serie.

Si en lugar de posts escritos por esta persona se deseara encontrar comentarios o posts a los que hubiera hecho un "like" bastaría con cambiar "stories-by" por "stories-commented" o "stories-liked".

Pero los grupos dan para más. Porque en el listado anterior no aparecía más que un grupo público. Pero con una URL de consulta como

https://www.facebook.com/search/_ID de la persona_/groups

... apareció además un grupo cerrado:


Y además uno con un nombre sugerente: "Family". Las relaciones, los comentarios, las informaciones publicadas en él o de él derivadas podrían ser consideradas "de alta calidad". Y si no se establecieron bien las configuraciones de privacidad, por muy "cerrado" que sea, los contenidos, parcicipantes, etc. podrían ser visibles para cualquiera...

Así, se podría obtener un listado de miembros con:

https://www.facebook.com/search/_ID del grupo_/members
... una lista de los sitios que estos miembros han visitado con 

https://www.facebook.com/search/_ID del grupo_/members/places-visited
etc., etc., etc., etc

No hace falta que tú lo hagas (8)

Dejamos el post anterior en el punto en que tocaba hablar de cómo la información publicada por tus "amigos" en Facebook puede revelar información sobre tí. Sigamos con ello.

En las pruebas realizadas para esta serie se tenía una persona que apenas publicaba nada que no fuera exclusivamente para sus amistades de la red social. Si se examinaban las fotos en su perfil, sólo aparecían dos. En ambas, con su pareja si bien el nombre de ésta no aparecía por ningún lado.

Sus historias publicadas eran también dos, aquellas en las que había colocado ambas imágenes en su perfil, como se podía comprobar con la URL de búsqueda:

https://www.facebook.com/search/_pon aquí el ID de la persona_/stories-by

Y sin embargo...

Para empezar, la gente puede publicar una foto tuya en Facebook. Y existe una URL para localizar aquellas fotos de una persona, las haya subido quien las haya subido, siempre que tengas permisos para verlas:

https://www.facebook.com/search/_pon aquí el ID de la persona_/photos-of

Con eso, del par de fotos inicial pasó a unas cuantas decenas. Y en ellas aparecían, por poner un ejemplo, tags que incluían el nombre de su pareja y, por supuesto, enlazaban con su perfil.

Y hablando de tags, se puede localizar todas aquellas fotos en las que etiquetaron a alguien con:

https://www.facebook.com/search/_pon aquí el ID de la persona_/photos-tagged
Claro que las fotos pueden ser antiguas y quizá en algunos casos sea difícil reconocer quién es quién. No es problema normalmente porque, como es sabido, cuando dejas el ratón en el nombre de una persona, Facebook marca su cara. Como en la imagen en que aparecen Mark Zuckerberg con  Kevin Systrom (cofundador de Instagram):


Las fotografías antiguas pueden mostrar la evolución de una persona: ¿perdió algunos kilos en su día? ¿los cogió? ¿llevaba gafas y ya no (lentillas u operación quizá)? Y las personas en ellas etiquetadas ayudan a determinar cómo evolucionaron las amistades reales y las relaciones personales.

Y Facebook las va guardando.

Con los videos se puede hacer lo mismo. Simplemente, susitúyase "photos-of" o "photos-tagged" por "videos-of" o "videos-tagged". Las historias, por su parte, también pueden estar etiquetadas y quizá alguien escribió una sobre algo en lo que la persona estudiada participó. Para comprobarlo, se puede visitar:

https://www.facebook.com/search/_pon aquí el ID de la persona_/stories-tagged

Quizá aparezca algo sobre alguna ocupación, actividad, afición o pasión: fútbol, música, arte, tradiciones,... Y quizá alguna foto relacionada con ella...


Por ir acabando, leer lo que de la persona se dice en historias y comentarios puede ser muy revelador. Quizá aparezca algún detalle que ponga en el camino de nuevas pistas y averiguaciones. En definitiva, en Facebook como en tantos otros sitios, no es sólo lo que tú digas, sino también lo que los demás digan de tí o publiquen sobre ti.