Archive for setembre, 2006

Mandriva Linux 2007 publicada

Hui s’ha publicat la nova versió estable de la Mandriva linux, la anomenada 2007 una distribució de linux que com sabeu els que em conegueu, es la que recomane normalment per a us d’escritori.
Aquells que no siguen del club no podrán baixar les imatges iso fins d’aci un mes mes o menys -tampoc ho se segur, però sol ser així- pero en canvi com que els repositoris estan igualment oberts per a tots, supose que es podrà fer la típica instal·lació per internet -en el cas de tindre bon ample de banda- . Jo ho vaig fer així amb la 2006 i crec que ara amb la 2007 ho faré igual, encara que no se si ja està la iso netinstall (en la 2006 eren 12mb) necessaria per a instalar a través d’internet…

Per què? Perquè sols baixes allò que necessites i no tots els cd’s o el dvd per a després instal·lar sols una part… Inconvenients? Alguns,… tarda un poc mes a instalar ja que depèn de l’ample de banda.. però és mes ràpid que baixar-ho tot i instal·lar per cd’s (lògic)…

Anuniat en una notícia a Linux-wizard.net

Entre les novetats, está la utilització de Kde 3.5 i de Gnome 2.16.. Ademés de que comenten que integra molt bé l’XGL ademés de la forma fácil (gràfica) que ens té acostumats Mandriva.
Encara no la he probat (tinc el ordinador amb la font d’alimentació que no va i no hem duen la de recanvi…)

Quan la probe a fons ja comentaré alguna cosa mes sobre aquesta nova versió d’una distro (mai millor dit) Màgica
Podeu trobar mes informació a la pàgina oficial, o a Blogdrake.net d’on he tret la informació…

Feu un comentari

Comença l’institut

Hui 15/9/06 començe l’institut.. :(

segurament a partir d’ara disminuiré el ritme de publicacions al blog bastant…

Feu un comentari

Bug Bluetooth D.O.S. en un mòbil Sharp GX25

Després de que ahir em publicaren la traducció al castellà de jugant amb bluetooth II a la web de Bluehack, m’he animat una altra vegada amb el Bluetooth, després de passar-me el matí llegint sobre com les coses han avançat en pocs mesos (que han avançat bastant) en una casualitat de la vida, he descobert una vulnerabilitat Dos (de denegació de servei) del mòbil Sharp GX25 al ser-li enviat un paquet de ping mooolt gran per Bluetooth. ;)

Més concretament, el atac es paregut al famós “ping de la mort” aquella vulnerabilitat que tenien els molts sistemes antics en la qual si s’enviava un paquet “echo” molt gran podia provocar la penjada del sistema, això fa molt de temps que està resolt.. però qui ho anava a pensar, la història es repeteix..

Estava navegant en una web sobre bluetooth quan he vist un exemple on apareixia l2ping, al vore que era una ferramenta per a fer pings, he pensat que podria comprovar si el ping pujava conforme s’allunyava el telèfon… he fet alguns pings perà he volgut provar si el telèfon es tornaria lent al fer-li pings pesats ja que un telèfon com aquest com podeu comprovar no té una gran capacitat i normalment tenen característiques molt limitades..

Primer he fet un hcitool scan per a veure la adreça hexadecimal del telèfon..

vicent@ferrervicent:~$ hcitool scan

Scanning …

08:00:1F:85:4F:A1 GX25.D

Acte seguit he dirigit el l2ping cap a la adreça del telèfon:

vicent@ferrervicent:~$ sudo l2ping 08:00:1F:85:4F:A1

Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 44) …

0 bytes from 08:00:1F:85:4F:A1 id 0 time 128.62ms

0 bytes from 08:00:1F:85:4F:A1 id 1 time 51.11ms

0 bytes from 08:00:1F:85:4F:A1 id 2 time 49.90ms

0 bytes from 08:00:1F:85:4F:A1 id 3 time 76.45ms

0 bytes from 08:00:1F:85:4F:A1 id 4 time 78.75ms

0 bytes from 08:00:1F:85:4F:A1 id 5 time 48.18ms

0 bytes from 08:00:1F:85:4F:A1 id 6 time 56.75ms

0 bytes from 08:00:1F:85:4F:A1 id 7 time 56.02ms

0 bytes from 08:00:1F:85:4F:A1 id 8 time 36.44ms

0 bytes from 08:00:1F:85:4F:A1 id 9 time 52.51ms
Send failed: Connection reset by peer

Això era un ping normal, el telèfon seguia en vida… el que no entenc és perque sempre al cap d’uns segons talla la conexió.. és una cosa que ja passava quan vaig escriure Jugant amb bluetooth 1 i 2..

He mirat com gastar l2ping:

vicent@ferrervicent:~$ sudo l2ping

l2ping – L2CAP ping

Usage:
l2ping [-i device] [-s size] [-c count] [-t timeout] [-f]
<bdaddr>

Aleshores?, que pasaria si fem un:

vicent@ferrervicent:~$ sudo l2ping -s 50000 08:00:1F:85:4F:A1

Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 50000) …

no response from 08:00:1F:85:4F:A1: id 0

He ficat 50000 per ficar un valor arreu, tampoc sabia en quines unitats era ni res, aixina que es pot dir que han sigut bastants coincidències juntes… (despres he sabut que 50000 era una animalada…) :P

Pero vos preguntareu que li passa al telèfon al fer el ping ;)

Exactament això:

Com podeu vore al video, el mòbil es queda inactiu i no respon durant uns segons, parant tota operació que s’estiguera fent en el moment, (una cridada per exemple).. el mòbil torna a funcionar en uns segons…

Hi ha que tindre en compte que 50000 bits per a un ping… és bastant, el ping típic en l2ping és de 44.. :o

Per a fer una prova he provat a fer un ping normal (per xarxa ethernet) cap al Router amb el mateix tamany.. el cas es que el router no s’ha immutat però no m’ha contestat el ping.. això es el que hauria de fer el telèfon per a protegir-se… no desconnectar-se (no pareix molt bona tècnica)… ;)

Altre detall, es pot observar que conforme es va pujant el tamany del paquet de ping la contestació és mes llarga..

44 > de 47 a 96 ms (és el ping estàndard en l2ping)

500 > 76ms

1000 > de 139 a 169 ms

1500 > de 195 a 230 ms

1850 > de 231 a 246 ms

També he fet una prova de anar allunyant-se però la diferència és mínima i no pot ser mesurada amb precisió ja que els mateixos pings tenen molta diferència entre si.

No descarte fer una ampliació i millora de l’article en cas de que a la gent li interese el tema.

De moment soles ho he probat en aquest mòbil, algú s’anima a provar-ho en el seu? :D


EDITE 14/9/06:

Ahir per la nit vaig trobar que el bug SI estava documentat.. no per a aquest mòbil en concret sino que éra una clase d’atac a dispositius blutooth que ja estava documentada, l’atac s’anomena bluesmack. I es un bug del dispositiu en questió, no del protocol bluetooth.

… i jo que hem creia que havia descobert un bug nou… :( pero realment si, perque ningu avans havia probat aquest bug contra un sharp gx25 [si algu l'ha trobat, no l'ha ficat en internet].. aixina que al menys l’he descobert contra el sharp gx25 :D

Edite20/9/06:

Article enllaçat a tuxmobil.org.

Feu un comentari

Atac arp & spoof dns.

Anem a fer un atac mitjançant la tècnica coneguda com “Man in the Middle” o home en el mig. Potser per internet hi ha molts manuals sobre açò, pero jo vaig a fer el meu basant-se en la meua experiència, i animant a tot el que ho probe a comentar la seua.
L’objectiu d’aquest atac és demostrar que una xarxa local típica no és segura i que amb poques ferramentes i poc temps d’aprenentatge es possible extraure dades que viatgen per la xarxa en protocols no encriptats, ademés que aquest tipus d’atac és bastant dificil de detectar i parar si no es té coneiximent adecuat.

Aquest article està destinat a aquells usuaris (locals) i administradors que vulguen probar la seguretat de la seua pròpia xarxa i/o que tinguen intenció de desenvolupar tècniques per a estar preparats contra aquest tipus d’atacs, en ningun moment incite a provar-lo fora de la vostra xarxa, ja que podeu donar un mal de cap a mes d’un administrador i ademés no és molt étic espiar trafic sense permis.. i supose que serà il·legal ,així que, avisats esteu.

Com he comentat, la técnica utilitzada sera la de man in the middle. Aquesta te un funcionament bastant simple, hem de tindre primer una base de teoria de xarxes per a entendre aquest conceptes, així que abans de llegir aquest article, convindria repasar:

Una vegada dominats mes o menys aquestos temes (no fa falta saberho de memòria, simplement saber que és cada cosa i un poquet com funciona).

Segurament és te el mite de que una xarxa amb switchos és segura.Val, mes segura que amb hubs és, però pregunte: Absolutament segura?
Per a qui no ho sapiga, un switch (conmutador) té la diferència fonamental respecte a un hub de que actua en diferents capes de xarxa.. Els elements de una xarxa s’organitzen en capes, així, la capa 1 és la física (cables, conectors) la 2 la d’enllaç, la 3 la de xarxa.. etc etc..
Un hub actua com a repetidor de senyal,(és un enllaç físic) es a dir, envia les dades a TOTS els cables que te conectats, pero sols l’agafa l’ordinador al que van dirigides les dades… Un Switch en canvi fa de conmmutador, actua com si fora un entramat d’interruptors i envia cada paquet sols per el cable corresponent a la direcció mac de desti.

Fins ahi la teoria tot bé… Pero que passa si fem creure a un ordinador que nosaltres som el router, i fem creure al router que nosaltres som el ordinador victima?

Ahi es on entra el nostre paquet de ferramentes DSNIFF. En aquest cas he fet totes les probes sota una Ubuntu Linux dapper com a equip atacant, un Window$ 2000 sp4 com a equip victima, i un Linksys BEFSR41 com a router.
D’ara en endavant seràn, atacant, victima i router.

  • Atacant serà: 192.168.1.100
  • Victima serà: 192.168.1.101
  • Router serà: 192.168.1.1

En la primera part de l’atac anem a fer que el trafic de xarxa es desvie per el ordinador atacat i que el ordinador victima no es done compte de la situació. Partim del cas de que el ordinador victima està tranquilament navegant per internet.. pertant hem de preparar-ho tot per a que no note ninguna caiguda en el servei o si ho nota que siga mínima.
Ens fa falta: que el “atacant” done internet a “victima”, pertant el “atacant” farà de porta d’enllaç de la “victima”, encara que “victima” es creurà que seguix tinguent al router com a porta d’enllaç.

El que jo he fet ha sigut fer un redireccionament de ip, conegut com a ip fowarding, aixi a primera vista sona com molta cosa, pero realment és: Compartir el internet.

En ubuntu linux es fa de la seguent forma:

vicent@ferrervicent:/$ sudo echo "1" > /proc/sys/net/ipv4/ip_forward

si estiguerem en protocol ipv6 seria canviar ipv4 per ipv6, si no sas de que va, dixaho com està. Per a desactivar-lo canvia el “1″ per un “0″.

En aquest moment atacant està compartint conexió a internet. Hem de pensar bé la situació i tindre en compte moltes coses com per exemple que cara el proxy de xarxa o porta d’accés real qui estarà entrant a internet serà atacant, pero realment serà victima a través de atacant.. es soles una cosa a tindre en compte.

Val, ja estém compartint internet fins ara realment no hem fet res.. a continuació ens disposarem a començar l’atac a la taula arp de la victima. Recorde per als bagos, que convé saber algo de teoria de arp primer.

Farem creure a l’equip victima que la direcció mac del equip atacant correspon a la ip del router. i al router que la ip del victima correspon a la mac del atacant.

vicent@ferrervicent:/$ sudo arpspoof -i eth0 -t 192.168.1.101 192.168.1.1

En la forma:
arpspoof -i (interfície de xarxa) -t (ip_victima) (ip_router)
En aquest moment arpspoof començarà a enviar paquets malignes a la xarxa per a corrompre el arp i la consola donara algo paregut a d’açò:

0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
etc...

A l’equip victima no te perque haver ningun problema, creurà que atacant es el router.. pero ho creurà per la direcció mac, la direcció ip de la porta de enllaç continuarà sent la del router..

Una vegada aci ja podem dir que hem conclós el atac amb éxit, estem fent d’intermediari entre router i victima i per tant tot el trafic passa per nosaltres.. pero encara no tenim resultats.. faré una xicoteta mostra del que es pot fer, pero millor si gasteu la imaginació i inventeu les situacions possibles..

Podem enverinar les solicituds dns: amb dnsspoof podem redirigir noms de domini que busque l’ordinador victima fins a les ip que nosaltres vulguem.. jo per exemple he fet una copia de google en un servidor apache local, he creat el arxiu noms.hosts que conté:

192.168.1.100 *.google.com
192.168.1.100 google.com
192.168.1.100 *.google.es

És a dir, tot els subdominis de google.com/.es aniran redirigits a 192.168.1.100, on he instalat un apache i he fet una copia del html de google pero amb les imatges canviades…
I al executar dnsspoof:

root@ferrervicent:/home/vicent# dnsspoof -i eth0 -f noms.hosts

En quant la petició dns desde l’equip victima es realitze, en la nostra consola veurem coses com les seguents, ahi demana els dns a un servidor dns de internet i posteriorment validarà amb el arxiu (noms.hosts) i enviarà allò que convinga..

dnsspoof: listening on eth0 [udp dst port 53 and not src 192.168.1.100]
192.168.1.101.1306 > 62.42.230.135.53: 60923+ A? client.voipbuster.com
192.168.1.101.1308 > 62.42.230.135.53: 15610+ A? www.google.com
192.168.1.101.1311 > 62.42.230.135.53: 56060+ A? minijuegos.com
192.168.1.101.1321 > 62.42.230.135.53: 14079+ A? connectiontcp1.voipbuster.com

El resultat que veu el equip victima és aquest:

google

Com podem observar l’usuari de equip victima no notarà res estrany que no siga la modificació de les imatges que corresponen al nom de google.. bé i alguna cosa més.
Val, per a comprovar si ho heu entés, que passaria si ficarem en el arxiu noms.hosts el seguent:

192.168.1.100 *.*

:D

Hem de tindre en compte també que per a que aquest enverinament de la solicitud dns siga satisfactori el equip victima ha de tindre els servidors dns’s com a automàtics o els mateixos que la porta d’enllaç, en el cas de que la xarxa tinguera un servidor dns dedicat diferent de la porta d’enllaç, es podria fer altre enverinament de taula arp pero en la segona ip posariem la ip del servidor dns… bé tot açò és ampliació..

Pero deixem-se de tonteries com la del google i anem a coses mes series.. Que podriem fer?.. podem possar un sniffer i fer captura de tràfic… en poques paraules: sabrem tot lo que la màquina victima envia i rep de internet sempre que no siga tràfic encriptat (protocol https o ssh entre altres)
Pertant desactivarem el dnsspoof de moment.
Per a que siga més gràfic fare un sniff de tràfic amb Ethereal encara que amb tcpdump es pot fer igualment.. pero ho he fet amb Ethereal perque és gràfic i de segur que el trobeu més fácil d’entendre.

Ethereal

Com podeu observar tenim ací mooolt de trafic de xarxa (he capturat uns 3mb en pocs segons) , si l’analitzem veurem bastants coses, però això ja ho deixe per a que ho comproveu vosaltres mateixos.

De moment anem a capturar una contrasenya facileta va.. conectarem el dsniff.

Comprovat que la contrasenya de autentificació de el navegador cau (la tipica contrasenya de carpetes privades del apache..) en aquest cas és la de autentificació del router.

accedint al router

Supose que seguiré algun dia amb coses un poquet mes avançades de Dsniff (i més interesants).. que vos pareix capturar totes les contrasenyes de protocols no encriptats de forma fácil o simular una pàgina segura creant un certificat de xifrat pero en realitat agafar tot el tràfic? tècnica pareguda a fer un “monkey in the middle” i fer de repetidor de conexions ssh… i Dsniff te ferramentes per a tot això..

De moment sigau bons i no gasteu aquestos coneiximents per a fer mal eh? segur que algú ja estarà pensant en aplicacions “no étiques” de dsniff…

Salut i linux.

Feu un comentari