Archivo de la categoría ‘Internet’

Seguridad: Spoofing. Capítulo Tercero -> Web Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

ATENCIÓN!! El Phishing creado para este capítulo tan tiene carácter didáctico, no se permite su uso fuera de este ámbito. El Phishing es completamente ilegal.

 

Web Spoofing

Aunque el Phishing no es más que un tipo de Web Spoofing, podemos afirmar sin duda alguna que es la práctica más común. Por Web Spoofing entendemos la modificación o suplantación de una página web que evidentemente no es nuestra. Phishing es la suplantación de una web con fines íntegramente delictivos, para poder obtener datos de usuarios que infelizmente caen en las redes de estas páginas y no son capaces de diferenciar lo uno de lo otro. Es decir, el Phishing es tan solo una singularidad dentro de Web Spoofing, aunque es sin duda su mayor uso.

Aquí tendríamos que hacer una diferencia muy importante. Desde mi punto de vista, el Spoof implica la modificación de algo que es nuestro, como son los casos que hemos visto: IP Spoofing (Modificamos nuestra IP), MAC Spoofing (Modificamos nuestra MAC), Phishing (Modificamos nuestra web)… pero en ningún caso estamos modificando aquello que no lo és. Es decir, no estamos modificando la IP de un usuario, no estamos modificando la MAC de un usuario, no estamos modificando la Web de un usuario. Esto es algo muy importante de entender, con Spoofing tan solo engañamos. Existen técnicas para modificar aquello que no está bajo nuestra “propiedad”, como pueda serlo XSS, envenamientos… técnicas que serán relatadas en otros artículos. Hablemos por tanto tan solo de Spoofing.

Los objetivos de Web Spoofing son claros:

  • Phishing, obtención de credenciales de otros usuarios
  • Reivindicaciones y Mofa
  • Estafa

Como hemos dicho el objetivo principal y sobre lo que vamos a centrarnos principalmente es el Phishing. Para que un ataque de Phishing se lleve a cabo son necesarias 4 fases. Primero un atacante debe de copiar lo más fidedignamente posible la página web que desea suplantar, al menos tan solo en apariencia, no es necesario un plagio completo de todo el site. Segundo, debe de modificar dicha web para que el usuario al introducir sus datos, estos queden almacenados de algún modo para poder recuperarlos el atacante. La tercera fase es realizar un proceso de URL Spoofing y por último utilizar alguna técnica que le permita engañar a los usuarios para acabar en su web falsa.

Redactar sobre Web Spoofing o Phishing es un problema. Mi intención es la de explicar, enseñar y así poder evitar ataques similares. El problema es que igualmente que esto puede servir con fines didácticos, cualquier persona podría adaptar estas letras sin problema alguno para pertrechar un ataque real, al igual que con los Spoofing expresados anteriormente. A diferencia del resto, hoy en día está de moda el Phishing, y la ingenuidad de las personas es aun demasiado alta. Si combinamos esto con las secciones siguientes (En particular con eMail Spoofing) sería dejar demasiado facil a un usuario mal intencionado poder realizar un ataque efectivo. Por ello al menos, voy a omitir todo código php y realizar algunos pequeños cambios para dejar claro que esto tan solo tiene fines didácticos. Aun así se incluirá al final del todo de esta sección, el enlace a una web creada con fines didácticos de lo que podría ser un Phishing en toda regla, y se incluirá del mismo modo un enlace al archivo donde se podrán obtener las identificaciones introducidas.

Para esta ocasión quería basarme en lo que sería un Phishing sobre

, una red social en España. Me puse en contacto con el gabinete legal de ellos y no les pareció una buena idea. Como les comuniqué, es normal, normalmente se es reacio a que puedan leer vulnerabilidades de sus propios servicios. Así que aunque tenga que modificar el artículo ya redactado, será sobre FaceBoock, la red social mayor que existe ahora mismo.

 

Fase 1: Creación de un site igual al del objetivo

Como ya he explicado, en el Phishing no importa recrear la web (que puede ser compleja) completamente, el objetivo es tan solo engañar al usuario que accede a ella. El hábito de un usuario normal es visitar la web e incresar su usuario y su contraseña para acceder. Si nos equivocamos, lo normal será volver a introducir los datos. Es decir, normalmente no nos preocupamos de ir a otros enlaces como “ayudas”, “Ha olvidado la contraseña” ni similares. Dado qeu ese comportamiento se repite para el 99% de los usuarios, tan solo tenemos que hacer creer al usuario que la web que está visitando es realmente ella. Dado que no tenemos por detrás una base de datos original, es evidente que se introduzcan los datos que se introduzcan, jamás logrará el usuario acceder al site, lo cual hace que sea común redirigir a dicho usuario despues de enviar los datos al site original para que no sospeche.

¿Pero como se puede copiar un site?

Dependiendo del grado de exactitud que necesitemos, puede ser más rápido o más lento el proceso:

  • Clonación de un site completamente independiente (físicamente estéticamente claro, no funcionalmente)
  • Creación de un site completamente dependiente al original, exceptuando la página de acceso.

En primer lugar, la clonación de todo un site de forma manual, o incluso a través del propio navegador, no es factible. Con clonar un site me refiero a crear un site con el mismo contenido que el original, enlaces, imágenes… pero accediendo a todo ese contenido de forma local. Es decir, podemos plasmar una imagen en nuestro Phishing, pero esta puede venir desde nuestro propio host donde tenemos alojados el Phishing o cargarla directamente desde el Host original. Crear una clonación tiene sus ventajas, por ejemplo es independiente a cualquier cambio que pueda realizar el site original, dado que scripts, html, imágenes y otros de tu propio site estarán almacenados en tu host, no en el de ellos. Por otro lado, es posible navegar por las diferentes secciones del site sin redirigirse al site original, que de otro modo produciría que un usuario que accediese a otro enlace perder el Phishing.

Pero todo no es positivo. La creación completa (o al menos lo más fiel posible) de un site (una página web) incluye tener en nuestro host muchísima más información, lo que produce un aumento considerable de espacio en disco, de ancho de banda usado y que además, es posible que el site original tenga conexiones más veloces que las nuetras, lo que haría que la navegación por nuestro site sería mucho más lenta para el usuario víctima. Por supuesto, la clonación, no es tan sencilla de llevar a cabo, y la mejor forma de hacerlo suele ser a través de un Web Spider, o quizás sea suficiente con wget.

Un proceso manual incluiría ir buscando uno a uno cada elemento e ir almacenándolos, después editarlos para que cada ruta especificase una ruta relativa a nuestra clonación y así poder montar la web. Pero esto evidentemente no es muy práctico. Yo voy a usar Teleport en Windows para este caso y para el segundo Firefox en Windows. Tampoco voy a detallar paso a paso que hacer, puesto que si se ha llegado aquí, presupongo que uno sabe más o menos moverse por cualquier programa o al menos comprende lo que está haciendo:

El tamaño de todo el site descargado para Tuenti, no llega a los 3MB y son más de 400 archivos. En el caso de Facebook, son más de 5000 archivos y unos 200MB. Esto os da una idea de lo bueno y malo de este proceso. 3MB pueden ser asumibles, 200MB para un Phishing es algo impensable. En contra partida, podemos navegar por gran parte de la web sin abandonar nuestro site clonado. En la siguiente imagen se puede observar esto:

En el ejemplo se puede ver que no solo se está emulando el site principal, sino que se puede navegar por el site y que al menos aparentemente todo muestra ser exactamente igual al original. Como puede verse en la barra de direcciones se conserva incluso la misma estructura de carpetas y archivos, aunque en el ejemplo se está haciendo una exploración en local, es decir, no se ha subido nada a ningun servidor externo.

Hay que tener en cuenta que la clonación jamás será exacta. Podemos extraer imágenes, contenido audiovisual, scripts… pero todo aquello que queda detrás y procesado tan solo por el servidor (como por ejemplo contenido dinámico, php, bases de datos…) no puede ser emulado de ningún modo. Es decir, podemos calcar pixel a pixel si deseamos el aspecto visual, pero nada más.

En el caso de la clonación de FaceBook, es un site demasiado complejo (sin entrar en bases de datos o PHP), 200MB sería demasiado para un Phishing, y más para un ejercicio. Quizás sea más. Quizás nosotros tan solo necesitamos lo fundamental, es decir, la pantalla de inicio de sesión y nada más. El resto del contenido podría ser simplemente enlazado con la web original, y mantener tan solo en nuestros servidores el html principal. De este modo ganamos en velocidad, comodidad, ahorramos en ancho de banda, en espacio… En contrapartida, estamos a merced de lo que haga el site original o peor aun, que la víctima pueda acceder a algún contenido desvinculado de nuestro site falso, lo que produciría que este se quedase fuera del Phishing.

Dependiendo del site, se podría realizar desde Firefox y usar la opción “Guardar Como…”. Como tan solo sería necesario la “cara”, nos basta con guardar únicamente la página HTML, de forma que los enlaces se conserven tal cual están. Haciendo este procedimiento pasamos a tener tan solo 1 archivo html de 30KB, el resto del contenido se cargaría desde la web original de FaceBook, lo cual es una ventaja. El problema es que si modificasen algo en el HTML, el site falso podría dejar de funcionar correctamente:

Como se puede apreciar tanto en la URL como en el destino del enlace seleccionado (aunque no aparezca, se está señalando la imagen grande de arriba “facebook”, y como se ve, no está apuntando a ninguna ruta local, sino al enlace real. Tan solo con dicho html tenemos lo mínimo necesario para poder realizar el Phishing.

Por otro lado, usar la mínima expresión a la hora de crear el Phishing, tiene la ventaja de que las URL señaladas a cada enlace corresponden a las originales, luego todas ellas no incurren en el problema de tener que usar URL Spoofing (Que se verá en la fase 3º). Una vez terminado este sencilo proceso, deberíamos de tener una copia (ya sea completa o parcial) del site objetivo, en este caso ejemplo, de Facebook. Tan solo bastaría subir nuestro site a cualquier hosting o copiarlo a nuestra carpeta principal de nestro servidor web. Si cualquiera accediese a ella en este punto, tendríamos una pantalla de acceso exactamente igual a la original, aunque si introduciésemos culaquier dato o fuesemos a cualquier enlace, nos redirigiría al site original.

 

Fase 2: Modificación

La segunda fase podría considerarse realmente el Web Soofing o Phishing. En realidad podría crearse la web desde cero si por cualquier aspecto no fuese posible “clonar” la web objetivo. El problema que ello tendría que posiblemente en algún detalle esta sería diferente a la original. Cuanto más fidedigna sea la copia, mejor resultado tendrá para un atacante, puesto a fin de cuentas todo objetivo es que el usuario no se de cuenta del engaño.

Pero tal y como hemos llevado el ejemplo, no serviría de nada. El objetivo es que el usuario cuando introduzca los datos en nuestro site falso, estos de alguna manera puedan ser accedidos después por el atacante. Ahora mismo se me ocurren tres formas para hacerlo:

  • Tener una BD debajo del site donde almacenar los nombres de usuarios y contraseñas
  • Tener un motor SMTP debajo del site para enviar por correo al atacante los datos
  • Escribirlos directamente en un archivo en nuestro servidor

El más eficiente de todos para un atacante sería almacenarlo todo en una base de datos, en la cual podría además registrarse fecha/hora o cualquier otra información de utilidad. La desventaja es que el atacante tendría que tener disponible no solo algún tipo de hosting (ya sea local o no), sino que posiblemente soporte para PHP y bases de datos. No voy a explicar como sería este caso por varias razones. Principalmente porque he dicho que por cuestiones de seguridad no voy a transcribir nada en PHP, luego prácticamente cualquiera de los 3 casos lo veríamos igual. Segundo porque tendríamos que estar manejando bases de datos y sería extendernos más de lo necesario.

En segundo lugar tendríamos una solución mucho más cómoda para el atacante. Cada vez que un usuario cometiese el error de caer en la trampa, el atacante recibiría un correo electrónico con las credenciales de dicho usuario. Esto que puede parecer algo muy complejo no lo es en absoluto, tan solo es necesario usar por debajo php para enviar un correo o programar un pequeño motor SMTP con los datos de nusetro correo gmail (por ejemplo) para realizar la tarea. No pensar en una web como algo estático. Cuando un usuario ingresa los datos, dispararía una serie de acciones que acabarían con el envío de un correo al atacante.

En último lugar y el que usaremos aquí consistiría en registrar los datos introducidos por el cliente en un archivo de texto. Principalmente usaremos este método para que aquél que lo desee, al final de estas letras pueda verificar que efectivamente funciona, y que la única diferencia de un Phishing real a este es el fin por el que se ha creado. Aun así como he dicho no se incluirá le código PHP para ello, sería demasiado fácil para quien pueda tener malas intenciones.

Visto esto, tendríamos que pensar como podríamos realizar esto. En mi caso concreto, las modificaciones realizadas al código fuente de mi Facebook.html han sido mínimas:

  • Modificación de la barra de título para dejar claro que es un Phishing didáctico, sustituyendo “Bienvenido a Facebook en Español (España)!” por “ESTE SITE/PHISHING TAN SOLO TIENE FINES DIDACTICOS”
  • Modificación del valor por defecto de “correo electronico” y “Contraseña” por: “Introduce correo de prueba” y “Introduce contraseña de prueba”
  • Renombrar Facebook.html por index.html para evitar la necesidad de apuntar a un html
  • Modificación de la acción que se realizaría al entrar en facebook por mi propio código
  • Creación e incorporación de mi código php, que escribirá los datos introducidos en un archivo de texto y redirigirá al usuario de nuevo a esta entrada

Mi intención es clara, que nadie pueda usar este Phishing didáctico para otros fines.

Sobre cada uno de los pasos realizados, sería entrar en programación html y php, y para ello ya tenemos innumerables libros que nos explican como hacer lo que deseemos hacer. Es decir, no voy a ir ahora explicando como realizar dichas modificaciones, no es el objetivo de estas letras. La cuestión es que al acabar, deberíamos de tener el Phishing completado. A partir de este momento, tan solo se trataría de aplicar diferentes técnicas para poder engañar de forma más fiel al incauto. ¿Por qué? En este momento lo que tenemos creado es lo siguiente:

Automáticamente nos llama la atención la extraña dirección que he usado. Dado que todo el Phishing lo tengo alojado en un hosting, tengo la posibilidad de crearlo en un subdominio o meterlo dentro de la ruta que yo desee. De este modo primero oculo por ahora la ubicación del Phihing, y la segunda la importancia de la fase 3º que aun no hemos hablado de ella. Tan solo verificar por la imagen que el site es tal y como se ha descrito y a su lado un documento de texto con los 3 primeros datos pruena introducidos.


Fase 3º: URL Spoofing

Podríamos dedicar en este mismo artículo un apartado específico para URL Spoofing, dado que no deja de ser un Spoofing más. Pero creo que su ámbito debe de ser también el de Web Spoofing, a fin de cuenta URL Spoofing podría ser perfectamente otra singularidad más de este. Sea como sea he preferido incluirla aquí.

A fin de no entrar en matices técnicos sobre URI, URL o URN, podemos definir de forma simple que una URL (dentro de internet) no es más que la dirección de un recurso, y el URN el recurso en sí. URI por tanto sería el conjunto entre URL y URN. Esto no tiene mayor complicación:

URI: blog.theliel.es/favicon.ico, URL: blog.theliel.es, URN: favicon.ico

Tener en cuenta que aunque a veces se omita el URN no implica que no exista, tal es el caso de los html tipo index.html, en los que su nombre se omite por defecto, pero están presentes igualmente.

Con esto, el término de URL Spoofing queda claro. Sería la técnica de modificar de algún modo o hacer parecer nuestra URL como otra, con el fin normalmente de aproximar al máximo nuestra URL con la de un site original.

Imaginar por ejemplo que tengo alojado el Phishing en:

“http://blog.theliel.es/docencia/66666666666666666666666666666666666”.

Evidentemente cualquier usuario que accediese a mi Phishing lo primero que podría notar extraño es el por qué está intentando acceder a “facebook.com” y en vez de ello está accediendo a un dominio diferente y una extraña sucesión de seises consecutivos. Evidentemente esto choca enormemente y sería complicado que un usuario pudiese percatarse de la trampa. Con URL Spoofing se trataría de modificar lo máximo posible dicha URL para asemejarse lo más posible al original. Y para esto existen numersas técnicas que son usadas por los atacantes:

  • Uso de nombres de archivos y estructuras de carpetas similares al site original
  • Usar dominios o subdominios lo más aproximados posible al original, o al menos ser inteligentes en su elección, uso de los ccTLD
  • Aprovecharse de los IDN (Nombres de dominios internacionales)
  • Ejecución de Scripts en el site para ocultar la verdadera URL del Phishing
  • Usar técnicas de redirección
  • Envenenamientos DNS

Algunas de dichas técnicas son simples, otras tremendamente complejas o costosas. La mayoría de los Phishers (Si es que ese nombre existe) no suelen complicarse tanto la vida, y tan solo se quedan en los dos primeros puntos. Un ataque más sofisticado posiblemente implicaría el uso de los puntos listados más abajo.

Tal y como estamos exponiendo el problema, lo primero sería reconstruir la URL de forma similar a la de la original. Si miramos la URL de tuenti (la de facebook no tiene ninguna “carpeta” anadidad a ella, tenemos que es la siguiente:

“http://www.tuenti.com/?m=login”

luego tan solo tendría que renombrar o mover los archivos en mi servidor a otra carpeta, siendo esta nueva carpeta llamada “?m=login”

blog.theliel.es/?m=login

Así me he evitado una parte, pero aun queda la otra… que es más complicada de eliminar. Lo cual pasaríamos al punto segundo, como poder modificar el dominio, o como podría un atacante intentar engañarnos. El problema es que un dominio no puede modificarse, con lo que la primera opción a la que se recurre es al uso de subdominios con la esperanza de no notar demasiado el cambio. En nuestro ejemplo podríamos intentar hacer alguna variante tal que así:

“http://tuenti.theliel.es/?=login”, “http://acceso.tuenti.theliel.es/?=login”, “http://www.tuenti.theliel.es/?=login”…

creo que se comprende perfectamente la idea. Evidentemente esto no es demasiado profesional cuando se requierer realizar un Phishing perfecto, pero en cambio es el sistema usado la gran mayoría de las veces, y aunque suene ridículo, suele funcionar bastante bien para los atacantes. Existe multitud de trucos a este aspecto. Por ejemplo otra práctica habitual es sustituir el nombre del dominio por su equivalente en IP, dado que a fin de cuenta un nombre de dominio no es más que una IP asociada a ella. Es decir, se puede expresar la dirección real de “facebook” en este caso de cualquiera de estas dos formas:

http://www.facebook.com

http://69.63.189.11

Las dos formas son completamente válidas, solo que con la segunda forma, el nombre queda completamente oculto. Luego una buena forma de ocultar la URL sería usar su equivalente IP. Y por último, otra técnica para intentar “esconder” la URL o al menos hacerla menos visible sería el uso de la sintaxis para introducir autentificación en una web, FTP… la forma que tendría esta tipo de dirección sería algo así:

http://facebook@theliel.es/

http://acceso:facebook@theliel.es/

Cuando se expresa una URL de dicho modo, lo que se está enviando a la web theliel.es que se desea acceder con el nombre de usuario “facebook”. En el segundo caso sería exactamente lo mismo, solo que en este caso el nombre de usuario sería “acceso” y la contraseña “facebook”. La idea de esto no es iniciar sesión en dicho lugar Phishing con credenciales de ningun tipo, sino de nuevo ocultar en la medida de lo posible la URL para que el objetivo no se percate. Se podría construir una URL con los dos métodos anteriormente explicados:

http://facebook@188.121.46.128/

Otra forma común de intentar engañar es con el uso de caracteres que se traducen por otros en la web. Por ejemplo, el caracter “%20” se traduce en una URL como un espacio. el %20 corresponde al número ascii 0x20, que corresponde al espacio. Es decir, se podría construir la URL de una web, codificada directamente en ASCII, de esa forma se ocultaría también cualquier cosa que no nos gustase

“http://facebook%2E74%68%65%6C%69%65%6C” se podría traducir como “facebook.theliel.es”, claro está que este sería un ejemplo extremo. Esto suele ser muy común más que nada para evitar ver los puntos de separación (Expresados en ASCII como %2E), los espacios (%20), las barras (%2F)….

Otra técnica ampliamente usada es la elección de dominios que puedan llegar a ser confundibles. El dominio no podemos modificarlo, pero que sucede si en vez de registrar theliel.es hubiese registrado el dominio “theliel.com”? Sería ya un paso. Pero y si el dominio registrado es por ejemplo “facebook.co.uk” “facebook.es” (En caso de que facebook.es no estuviese ya registrado), “facebook.org”, “facebook.com.es”… es evidente que el dominio ya se parecería muchísimo más al original, y por consiguiente llamaría menos la atención.Y es que gracias a los dominios ccTLD, aquellos que tienen dos letras tan solo, que son asignados solo uno a cada pais, tienen esta ventaja. ¿Ventaja? Claro. Normalmente registras un dominio. Pero la gran mayoría de TLDs son los ccTLD, si existe uno por cada país, el abanico es mucho más amplio que tan solo los gTLD. Esto quiere decir que aun cuando existan dominios como “facebook.org” “facebook.com” o muchos otros registrados todos a la misma entidad, seguro que tendremos multitud de ellos disponibles en ccTLD. En caso de facebook sin ir mas lejos, creo que tiene registrado a su nombre todos los gTLDs (si no se me escapa alguno), pero ni mucho menos tiene registrados todos los ccTLD. Sería facil mirar alguno que fuese similar.

Para quien no lo sepa, TLD se traduce como Top Level Domain, es decir, la parte más derecha de una URL. Estos se clasifican principalmente en 3. TLDs reservados, TLDs genéricos (gTLD) y TLD de paises (ccTLD). Dentro de los reservados tendríamos .test, .arpa… Dentro de los ccTLD .es, .fr, .gb… Y dentro de los gTLD los clásicos .com, .org, .net…

Una técnica mucho más refinada es aprovecharse del uso de los IDN. Dado que cada país posee un ccTLD, es igualmente razonable que la ICANN no solo permita la escritura o el registro de URL en el alfabeto nuestro, Latino, que posiblemente sea el alfabeto más usado del mundo. Con alfabeto me refiero ni mas ni menos a A B C D… pero incluso en algo tan sencillo como esto, rápidamente recordamos que nosotros tenemos la “eñe”. Sería justo por tanto que la ICANN nos permitiese poder usar la “eñe” en un dominio: “www.coño.es” en vez de “www.cono.es”. Pero esto tan solo es la punta del iceberg. Si se permiten otros alfabetos, podemos pensar que existen URLs en chino, árabe, cirílico…

¿Que importancia tiene esto? Una enorme. Si se permiten caracteres pertenecientes a otros alfabetos, podríamos construir una url incluso IGUAL a una legítima. ¿Como es esto posible? Porque es posible que en un alfabeto una letra tenga la misma representación gráfica que en otro alfabeto, pero en cambio el código UNICODE de dicho caracter sea completamente diferente, con lo que a efectos prácticos ambas direcciones pueden convivir. El mejor ejemplo de esta técnica sería registrar el siguiente dominio:

“fаcebook.com”

A efectos gráficos el nombre es exactamente el mismo!! pero no lo es. La “a” no pertenece a la “a” latina, sino al caracter “a” cirílico. Nuestra “a” corresponde al valor UNICODE U+0061, mientras que la “a” cirílica “а” corresponde al código UNICODE U+0430. Esta técnica es muy sofisticada y como puede apreciarse casi imposible de detectar.

Pero aun podemos complicar más el URL Spoofing y dar un paso más allá. A fin de cuentas el uso de IDN no siempre es posible si no existe algún carácter con correspondencia en un alfabeto u otro o no podemos registrar dicho dominio por la razón que sea. Una solución más compleja pero más versátil sería el uso de Scripts creados en JavaScript, ActiveX, extensiones para firefox… para, de algún modo, evitar que el objetivo de un atacante pueda darse cuenta de la dirección real. Existen 3 prácticas mayoritarias en este aspecto, en los que su efetividad depende más que de cualquier otra cosa del navegador usado y como esté configurado.

La primera sería la clásica apertura de Popups, ventanas emergentes Mediante una simple llamada en JS (No voy a escribir en estos casos código alguno), es posible cerrar la página actual (para que no se pueda leer la URL real) y acto seguido reabrirla sin barra de dirección. Esto la mayoría lo ha visto muchas veces, sobre todos en los tiempos de la hegemonía de Internet Explorer y la publicidad emergente. Gracias a dios, con los navegadores actuales este tipo de prácticas quedan tan solo efectivas para un reducido número de personas.

La segunda opción implicaría haciendo uso de JS algún otro lenguaje, la aplicación de una pequeña “capa” (por así decirlo) a la barra de direcciones. Es decir, literalmente se pegaría una imagen con la URL del sitio original encima de la barra de direcciones de nuestro navegador. De este modo se oculta URL real y aparenta ser la URL legítima. Alguna vez he podido apreciar este tipo de Phishing, pero sinceramente no sabría ahora mismo como crear el código necesario para realizarlo. Pero como hemos dicho, depende enormemente de la configuración de nuestro navegador y de cual usemos.

La tercera opción, es similar a la segunda. En este caso se insertaría un objeto (se llama así) texto en nuestra barra de direcciones, que al tener el fondo blanco y en el texto la URL legítima, a todos los efectos nusetra URL parecería completamente real. Este escenario es peor que el segundo, dado que percatarse de ello sería mucho más complicado. Al final de la sección hablaremos de las medidas a tomar en cada caso.

Llegados a este punto tan solo quedarían dos técnicas para poder realizar un URL Spoofing. Realmente las dos técnicas implicarían algo más que Spoofing. Ya dije que para mi el Spoofing es engaño, modificar algo que tenemos, jugar con nuestras cartas… en cambio las dos técnicas restantes: Redirecciones y Envenenamiento, implicaría cambios más radicales por así decirlo. Sería necesario modificar o inyectar código propio en otro site en el caso de las redirecciones, o modificar el caché DNS de los usuarios. Estas dos cuestiones se tratarán en los envenenamientos y en XSS. En cambio si existe una redirección típica que si podemos comentar aquí, y que por cierto es la más usada. En realidad se aprovecha normalmente de forma conjunta con eMail Spoofing.

En HTML existen formas de poder ir hacia otro lugar, lo conocemos simplemente como enlace. Pero una cosa es el destino al que deseamos llegar y otra el texto del enlace. Así por ejemplo podría escribir:

http://www.facebook.com

http://www.facebook.com

Y aun cuando en las dos direcciones se puede leer exactamente lo mismo, la primera lleva al site original de facebook y la segunda a mi blog. Esto que parece tan simple es usado constantemente, todos los días en millones de correos fraudulentos. Aunque parezca mentira, la gran mayoría de todos los problemas de seguridad existentes son debidos tan solo a la malinformación del usuario, de una mala praxis. Imaginar por ejemplo que en vez del ejemplo mostrado, el segundo enlace en vez de ir a mi blog, fuese a mi Phishing.

 

Fase 4º: El gancho

Aun cuando el atacante tiene todo perfectamente planeado y preparado queda lo más obvio. Que un usuario caiga en la trampa y visite dicho lugar. La forma más simple de producir esto es por medio de eMail Spoofing, que será tratado más adelante. Otros medios usuales es la mensajería instantanea, virus, foros, blogs… Por ejemplo, podría enlazar mi blog a un supuesto enlace a Facebook para promocionarlo, pero la verdad es que iría directo a la trampa. Como digo veremos esto en gran detalle en eMail Spoofing.

 

Llegados a este punto, el atacante comenzaría a recibir nombres y usuarios sin parar de las víctimas, y lo peor de todo es que una vez todo en marcha, el proceso es todo automático. Tan solo la buena educación y el cuidado hacen que este tipo de ataques tenga el menor impacto posible.

Para quien quiera verificar como podría ser un Phshing real, quitando algunos detalles como ya he explicado, puede verlo aquí, así como el documento de texto donde quedarán almacenados los credenciales introducidos:

 

http://theliel.webege.com/DIDACTICO_FACE/

http://theliel.webege.com/DIDACTICO_FACE/fac.txa (es un archivo txt renombrado a txa por razones que ahora no importan)

 

Bueno, pero ahora… ¿como evitar el Phishing?

Evitar el Phishing es algo fundamental estos días de hoy, en los que posiblemente el Phishing se lleve la mayor parte de los actos no civilizados (por así decirlo). Si comprendemos cada paso que debe de dar un atacante para poder realizar un Phishing de forma satisfactoria, podemos ver claramente cada uno de los pasos que podemos realizar nosotros para evitarlo. Es cierto que nosotros como usuarios o como Webmasters, no podemos hacer nada evitar que alguien pueda simplemente copiar un sitio. Es cierto que no podrán montar debajo la base de datos o el código php que sea necesario, pero al menos la apariencia física es imposible de evitar. Por otro lado tampoco podemos evitar que un atacante modifique a su gusto su propio site para intentar que caigamos. Pero a partir de aquí, por listo que pueda ser el atacante, podemos impedir sin mucha complicación cualquier tipo de Phishing, y es aquí donde reside nuestra “defensa”. Al explicar las diferentes técnicas de IP Spoofing o de ganchos, un usuario debería de ser más que capaz por tanto de saber diferenciar un site real de uno que no lo es. Voy a dar algunas indicaciones básicas:

  • Uso de conexiones seguras siempre que sea posible
  • Usar un Navegador que sea fiable
  • Conocer las URL legítimas de los sitios visitados de forma habitual
  • No fiarse de las redirecciones, comprobarlas siempre
  • No permitir por defecto Scripts de ninguna clase
  • No permitir por defecto Cookies de ninguna clase

 

El uso de conexiones seguras a día de hoy es fundamental, sobre todo cuando vamos a ingresar en algúna web que requiera de credenciales. Por regla general soy extremadamente crítico con aquellas web que no usan sistemas de certificados SSL/TLS cuando se trata de datos confidenciales. En caso de Webs como redes sociales parece que aun no está muy implantado el uso de conexiones seguras, pero jamás deberíais acceder a alguna web de banca electrónica si esta no está amparada por un certificado digital que la acredite. De esto hablaremos en otro artículo.

Un navegador fiable es fundamental. Muchas web de Phishing pueden aprovechar agujeros de seguridad o vulnerabilidades de estos por ejemplo para poder modificar la URL que aparezca en nuestro navegador. Cualquier truco es válido a la hora de que el site falso pase por el original. Actualmente el navegador más veloz a la hora de renderizar una web es Chrome (De Google) con mucha diferencia. No obstante Firefox es un navegador mucho más sofisticado y con posibilidades, maduro y con una escalada imparable en su gran uso. También hay que tener en cuenta que actualmente Firefox no soporta multiprocesador, lo cual quiere decir es que en cuanto esté terminado el soporte completo para este, sy velocidad se multiplicará aproximadamente x3, a la par de su seguridad. Si tengo que escoger uno sin duda alguna es Firefox, después Chrome, después Opera, IE y para terminar Safari. Safari es mejor navegador que IE en realidad, pero es mucho más vulnerable también.

No sucede nada por conocer las URL visitadas de forma habitual. Si sabemos que la URL de facebook es “http://www.facebook.com” es esa, no es otra. Aquí hay que explicar algo para aquellos que no lo sepan. Una URL se lee siempre de derecha a izquierda. No estoy hablando de la URI que hablamos más arriba, tan solo de la URL. La otra parte de la URI, la URN si se lee de izquierda a derecha. Como digo una URL se debe de leer de derecha a izquierda, cada sección separada por un punto es un dominio/subdominio. Por ello, se llama TLD a los dominios .es .com .org etc, dado que es lo primero que encontramos si leemos de derecha a izquierda: “Top Level Domain”. De este modo podemos decir que todos los dominios de primer nivel son aquellos que están justo después del primer “.”. “theliel.es” sería un dominio de primer nivel. Es evidente que prácticamente cualquier site estará alojado en un dominio de primer nivel. Esto es un indicativo fundamental. Si hacemos caso a esto, prácticamente ninguna variante de las que hemos hablado con anterioridad sería válida. A esto debemos sumar que ningun site original usaría su IP directamente para acceder a su site. La única razón por la que esta podría ser usada sería ante problemas de DNS, pero esto a día de hoy es prácticamente impensable. Otro motivo por el cual jamás fiarse de una URL dada en IP.

“http://facebook.theliel.es”, “http://facebook@theliel.es”, http://facebook@188.121.46.128/

Los tres ejemplos anteriores, si leemos de derecha a izquierda nos encontramos con el truco. En el primer caso se está accediendo primero a un dominio de primer nive .es, y después a un subdominio de este llamado facebook. Evidentemente facebook nunca sería un subdominio.

En el segundo ejemplo, el primer dominio que nos encontramos es de nuevo “theliel.es”, da igual lo que exista a la derecha, el dominio es ese. Además, dependiendo del navegador que usemos, puede incluso darse cuenta de esta pequeña trampa, pues nos advertirá de que el site al qu ese quiere acceder no requiere de autentificación.

El tercer caso es el mismo que el segundo… tan solo con la modificación del dominio “theliel.es” por su IP. Da igual a quien corresponda la IP, lo mejor no es fiarse, o si se está seguro de la legitimidad de dicha IP, una consulta ping sobre el dominio en cuestión nos devolverá la IP de dicho dominio. Si no coincide listo. Otra opción sería verificar la IP en un servidor Whois y comprobar a quien pertenece dicha IP

Las redirecciones es un problema con mayúsculas. Parece increíble que a estas alturas los usuarios no se fijen en la dirección de destino real, no lo que podemos leer como texto. Antes de seguir un enlace del cual no estamos seguro su procedencia, comprobar el destino del enlace. Cualquier navegador hace esto, tan solo se necesita pasar el ratón sobre el enlace para que nos aparezca (normalmente debajo del navegador) el salto a efectuar. Esta práctica es diaria cuando se intentan realizar ataques de eMail Spoofing. Cuando tratemos esto más adelante se comprenderá mejor.

El uso de Scripts o Cookies es algo normal en internet. Pero dichas cookies y Scripts pueden ser usados de forma maléfica contra nosotros. Es cierto que a día de hoy prácticamente cualquier web requiere aunque sea de pequeños scripts para poder desde visualizar correctamente el contenido a ejecutar cualquier acción. Pero aun así, desde mi punto de vista es mejor prevenir que curar. Soy más partidario de las listas blancas que de las listas negras. Es decir, mis políticas siempre son las mismas: Partir de un sistema completamente cerrado e ir abriendo lo que se va necesitando. En este aspecto, implicaría bloquear por defecto todas las cookies y todos los scripts, e ir habilitando tan solo aquellos que van siendo necesario. Aquellos que conozco y comprendo que son seguro los puedo habilitar de forma indefinida. Esto que parece un chiste, es la causa de que prácticamente cualquier PC del mundo, tenga alguna cookie de seguimiento o espía. Además, gracias a código en JS malicioso y aprovechando vulnerabilidades de webs, de navegadores… aparecen problemas mayores como XSS, URL Spoofing, exploits… La regla siempre debería de ser de bloque total, y solo habilitar cuando sea estrictamente necesario. Si estamos seguros de la “legitimidad” del sitio y nos fiamos, permitimos para siempre dicho script o dicha cookie. Para tal, personalmente uso NoScript y Cookie Monster (Los dos para Firefox)

Evitar el Phishing es algo simple si se tiene algo de cuidado. No hace falta mucho, tan solo conocer que es, como funciona y el objetivo que se busca. Si se sabe todo ello, evitarlo es facil.

 

Para terminar del todo con Web Spoofing, citar un par de detalles más. El Phishing no es el único Web Spoofing que se conoce. Aunque normalmente el objetivo es el explicado, a veces el objetivo no es la obtención de datos de los usuarios, sino que tiene fines reivindicativos, de mofa o incluso de estafa. Por ejemplo si estoy completamente en contra del LHC, una forma de mostrarlo o criticarlo sería crear un site igual que el oficial pero con contenidos de protesta. Si se quiere mofar sobre por ejemplo una ley o algo similar podría realizarse un Web Spoofing para calcar un blog o un site de dicho político en el que se hablase jocosamente sobre ello.

Una última utilización de Web Spoofing sería cuando tan solo se pretende crear un negocio, alguna clase de venta… de algo que no existe. Pongamos por ejemplo que creo un site prácticamente igual y copiado a Amazon. En él publico libros o productos que quiera. El proceso es todo muy similar al original, solo que dicha web tan solo es una mera estafa, o a lo mejor es real, y se aprovecha del nombre, diseño, métodos… de otra que ya existe.

 

Seguridad: Spoofing. Capítulo Segundo -> MAC Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

MAC Spoofing

Mientras que podemos decir que la IP es la dirección de nuestros dispositivos y nodos de red, esto tan solo es cierto a partir del nivel 3 del modelo OSI (Nivel de Red). Por debajo del nivel 3 (el Nivel 2 o Nivel de Enlace de datos y Nivel 1 o Nivel físico), tan solo se entiende de direcciones MAC. La dirección MAC es un ID compuesto por 6 octetos que es grabado a cada dispositivo de red en fábrica. Así, los 3 primeros octetos son asignados a cada empresa (las empresas deben de comprar su ID), y los siguientes 5 octetos son administrados por la empresa como ella quiera, normalmente según modelos y otros. No obstante, en el primer octeto (el más significativo) queda reservado sus dos últimos bits. Si el bit 7 es un ‘1’ la MAC establecida no pertecene a nadie, usada para asignación manual y ‘0’ si pertenece a una empresa (o aun está disponible para comprarla para ser asignada). Si el bit 8 del primer octeto es un 1, la direccin MAC pertenecerá a una dirección Multicast (Mismo grupo de direcciones, para poder enviar datos simultaneos a varios clientes), mientras que si es ‘0’ la dirección será Unicast, es decir, individual.

Sabiendo esto, hay que comprender la importancia de una dirección MAC. Dependiendo del ámbito en el que estemos, tendrá una importancia mayor o menor. Si nos encontramos en una red Local ethernet su importancia es mayor incluso a la IP, dado que incluso la IP de cada dispositivo podemos decir que está “asociada” a cada MAC (luego veremos esto en detalle). En cambio, por encima de nuestra red local su importancia puede ser mucho menor. Por ejemplo, para nuestro ISP ADSL la MAC de nuestro router no es importante, dado que la IP que nos asigna nuestro proveedor no está basada en MAC alguna, sino que la IP se asigna mediante protocolo PPPoE (usuario y contraseña) y la conexión es directa a nuestra casa. En cambio en conexiones cables sí la MAC es importante, dado que es esta la que suele reconocer el proveedor por cable para asignar incluso la velocidad de conexion.

¿Cual es el sentido pues de MAC Spoofing? El mismo que en IP Spoofing básicamente:

  • Suplantación de identidad
  • Acceso a servicios no contratados
  • Evasión de filtros MAC
  • Anonimato
  • Envenenamiento ARP


Hay que tener en cuenta que las direcciones MAC suelen actuar a un nivel más básico que IP, esto puede ser bueno o malo según se mire. Para poder entender la importancia de estas direcciones, hay que entender como funcionan o por qué. ¿Como sabe un Router o un Switch a que destino enviar un paquete? La respuesta que se pueda esperar es la IP de dicho cliente claro, pero esto no soluciona el problema. Para que el paquete se dirija a una IP concreta, esa IP debe de estar asociada de alguna manera a un medio físico, un ID único… y esta es la MAC. Dado que la MAC en teoría es única, los dispositivos de red guardan tablas de equivalencias entre estas IPs y sus respectivas MACs. Si un paquete llega a un Switch, el Switch mirará en su tabla que puerto ethernet (en redes ethernet) corresponde a la MAC destino, y será por dicho puerto o interfaz por donde envíe el paquete. Se podría pensar que la IP por tanto podría suprimirse, pero nada mas lejos!! al igual que la MAC es completamente necesaria. Cuando un dispositivo se conecta a un Switch pro ejemplo, lo único que posee este es una MAC. El Switch registra esta MAC en su tabla y de este modo conocerá en que puerto está conectado. A partir de este momento se realiza la asignación de IPs y bueno… esto se comprenderá mejor cuando se explique el envenenamiento ARP (ARP es un protocolo para asociar IPs a MACs, por así decirlo).


Por tanto, al igual que con IP Spoofing, el empleo de MAC Spoofing puede ser usado para la suplantación de identidad. Si la dirección MAC es única a cada dispositivo, podemos suponer que esta virtud puede ser usada en multitud de sistemas para mejorar la seguridad de estos. Uno de los usos más extendido de esto es la misma premisa que con IP Spoofing. Si podemos ocultar nuestra MAC podemos ocultar un ID que es único para nuestro adaptador. También podemos cambiarlo por otro que pertenezca a un cliente legítimo para hacernos pasar como si fuésemos ellos mismos. Un ejemplo extendido a esto, cuando se desea engañar a un router que esté asignando direcciones IPs de forma estática dependiendo de su dirección MAC. Dicha IP concreta tan solo es posible obtenerla con una MAC concreta, y con dicha IP concreta y MAC concreta podremos simular ser un cliente quizás legítimo en la red.

Veamos un ejemplo de MAC Spoofing para obtener una IP que no podríamos obtener de forma legítima:

La red está configurada para asignar IPs de forma dinámica por medio de DHCP dentro del rango 192.168.2.100-192.168.2.150. Por otro lado la red está configurada para que el rango 192.168.2.2-192.168.2.20 tenga acceso tanto al router como a otras tareas de administración. Por seguridad, dicho rango tan solo es asignado de forma estática por el router según la MAC del cliente. Aun cuando se intentase una asignación IP manual dentro de dicho rango, si la MAC no pertenece a dicha IP, el router no le concederá acceso a la red. A través de MAC Spoofing modificaremos nuestra MAC para que coincida por la de un cliente válida.

 

Fase 1: Conexión estandar al router de un cliente cualquiera:

Anarchy:/home/theliel# nmap -n -sP 192.168.2.1-255

Starting Nmap 5.21 ( http://nmap.org ) at 2010-01-30 23:18 CET
Host 192.168.2.1 is up (0.00057s latency).
MAC Address: 00:25:9C:11:22:33 (Cisco)
Host 192.168.2.2 is up (0.00055s latency).
MAC Address: 00:24:8C:11:22:33 (Asustek Computer)
Host 192.168.2.3 is up (0.00016s latency).
MAC Address: 00:24:8C:22:33:44 (Asustek Computer)
Host 192.168.2.8 is up (0.0092s latency).
MAC Address: 00:1C:BF:11:22:33 (Intel Corporate)
Host 192.168.2.13 is up (0.00039s latency).
MAC Address: 00:1D:60:33:44:55 (Asustek Computer)
Host 192.168.2.131 is up.
Nmap done: 255 IP addresses (6 hosts up) scanned in 3.94 seconds

Con el escaner anterior tendríamos listados todos los host conectados, así como la dirección MAC de cada uno de ellos. Para el último host, no se muestra su MAC dado que es el “atacante” que ha realizado el escaner. Como se puede obsevar tenemos host pertenecientes a la red “segura” y la IP del atacante asignada por DHCP. Por otro lado los datos de red del atacante:

Anarchy:/home/theliel# ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
inet addr:192.168.2.131 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fefe:567d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4323 errors:0 dropped:0 overruns:0 frame:0
TX packets:5107 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5075469 (4.8 MiB) TX bytes:433030 (422.8 KiB)

 

C:\Users\Theliel>ipconfig /all

Configuración IP de Windows
Adaptador de Ethernet Local Area Connection:

Sufijo DNS específico para la conexión. . :
Descripción . . . . . . . . . . . . . . . : Marvell Yukon PCI-E Gigabit Ethernet Controller
Dirección física. . . . . . . . . . . . . :
00:11:22:33:44:55
DHCP habilitado . . . . . . . . . . . . . : sí
Configuración automática habilitada . . . : sí
Dirección IPv4. . . . . . . . . . . . . . : 192.168.2.131(Preferido)
Máscara de subred . . . . . . . . . . . . : 255.255.255.0

 

Fase 2: MAC Spoofing

Con los datos de los hots anteriores, podemos realizar el cambio de MAC de una forma muy simple por otra que corresponda a un host que pertenezca a la sección segura. Por razones evidentes, lo ideal es realizar el cambio en un momento en el que el host a sustituir no esté conectado en dicho momento, sino produciría un conflicto entre los dos hots. En este caso vamos a hacernos con el host 192.168.2.13.

Anarchy:/home/theliel# ifconfig eth0 hw ether 00:1D:60:33:44:55
Anarchy:/home/theliel# ifconfig
eth0 Link encap:Ethernet HWaddr
00:1D:60:33:44:55
inet addr:192.168.2.131 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fefe:567d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4466 errors:0 dropped:0 overruns:0 frame:0
TX packets:5197 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5091981 (4.8 MiB) TX bytes:445543 (435.1 KiB)


Adminsitrador Dispositivos -> Adaptador de red -> Propiedades


Fase 3: Renovación IP por DHCP.

Dado que la IP ha sido asignada previamente por DHCP, es necesario renovar la IP para que el router reasigne la IP de la MAC falseada:

Anarchy:/home/theliel# dhclient

Internet Systems Consortium DHCP Client V3.1.3
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:1D:60:33:44:55
Sending on LPF/eth0/00:1D:60:33:44:55

Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPNAK from 192.168.2.1
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.2.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.2.1
bound to 192.168.2.13 — renewal in 2147483648 seconds.


C:\Users\Theliel>ipconfig /renew

Configuración IP de Windows
Adaptador de Ethernet Local Area Connection:

Sufijo DNS específico para la conexión. . :
Dirección IPv4. . . . . . . . . . . . . . : 192.168.2.13
Máscara de subred . . . . . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . . . . . : 192.168.2.1


Esto que parece realmente muy sencillo, puede resultar tremendamente útil para un atacante en multitud de escenarios. Por ejemplo cuando se desea evadir un filtrado MAC (típico en las conexiones WIFI) para poder acceder a la red. Numerosos AP de bares, particulares, redes públicas… poseen filtrados MAC para permitir o denegar la conexión a sus redes. Dado que no estamos conectados físicamente a la red no podemos hacer uso de escaneos de puertos y otros sistemas, pero en cambio podemos usar utilidades para poder escanerlas, como por ejemplo Airodump-ng. Una vez optenidas MAC válidas que pueden conectarse al AP, podemos proceder a modificar la nuestra tal y como se ha explicado con anterioridad:

CH 13 ][ Elapsed: 30 sec ][ 2010-01-31 01:57 ]

BSSID                                      PWR           Beacons         #Data,       #/s        CH        MB         ENC      CIPHER        AUTH     ESSID

00:25:9C:11:22:33 –                   -70                    120              57          0           13          54e     WPA2 CCMP            PSK         Theliel

BSSID                                STATION                           PWR          Rate           Lost           Packets        Probes

00:25:9C:11:22:33–          00:1C:BF:11:22:33 –           32            54-0                7                     245      Anarchy
(not associated)               –
00:1C:BF:22:33:44 –             7            11-0                5                        23

Anarchy:/home/theliel#airodump-ng -c 13 -w dump wlan0

 

Dentro también de las aplicaciones prácticas de ello podría incluirse la piratería de conexiones a Internet instaladas por algunos ISP de cable. Esta tecnología suele usar un cable de fibra óptica que es común a una zona de abonados. La conexión a estos ISP es simple, tan solo hace falta un módem suministrado por ellos y un terminal que conectar a dicho módem. Luego la pregunta es inmediata. Si el cable es común a todos los abonados y no se requiere de ningún tipo de identificación ¿Cómo conoce/diferencia el ISP al cliente conectado o que servicios tiene contratado? Por la MAC de dicho módem, ni más ni menos. Si se modificase la MAC de nuestro módem por una que tenga contratada 10MB, en teoría, a efectos prácticos nuestro ISP nos daría esos 10MB. El problema evidentemente es modificar la MAC de dichos Módem, los cuales la mayoría de las veces es necesario realizarlo mediante una modificación hardware.

Por último, la técnica de MAC Spoofing juega un papel fundamental en los ataques de envenenamientos ARP, pero esto será tratado en otro artículo.

 

Hemos hablado de aplicaciones prácticas, pero ¿Cómo podemos evitar este tipo de ataques a nuestros sistemas? Al igual que dijimos en IP Spoofing, usar siempre que sea posible protocolos seguros como IPSec en los que sea necesario tunelizar todo el tráfico dentro de una misma red. Por otro lado separar físicamente las redes que serán usadas para propósitos diferentes, y si se requiere, colocar un firewall en la puerta de entrada a las partes sensibles de nuestra red. Por otro lado, si la estructura de nuestra red es relativamente estable, el uso de tablas MAC estáticas asignadas específicamente a cada uno de los puertos de nuestro Switch.

En cambio proteger nuestra red contra MAC Spoofing es más complicado, por ello la única seguridad que podemos aplicar es en primer lugar no permitir conexiones wifi cuando sea posible, y si se deben de usar, usar siempre un nivel de encriptación mínimo de WPA2-PSK, siendo prácticamente obligado el uso de WPA2 más algún protocolo EAP, trabajando así con servidores Radius y certificados digitales. Pero desde luego nunca presuponer que un filtrado MAC garantizará absolutamente nada.

 

 

Seguridad: Spoofing. Capítulo Primero -> IP Spoofing

ATENCION: Los ejemplos que se van a mostrar y “tutoriales” tan solo tienen carácter educativo. En ningún aspecto comparto filosofías de invasión a la intimidad, ataques contra un sistema informático o cuestiones similares. En la medida que sea posible siempre se usarán ejemplos y formas que puedan ser usados por cualquier persona, de forma que pueda verificar los contenidos escritos. No obstante, por motivos más que obvios, materiales como contraseñas, nombres de usuarios o de hosts, serán omitidos o modificado en las capturas de pantallas realizadas (o las lineas escritas). Es decir, los ejemplos serán completamente reales, los datos mostrados a vosotros necesarios para poder pertrechar estos ejemplos no siempre lo serán (Sí lo serán los resultados). Para que esto conste de forma clara, todo material sensible modificado o falso estará resaltado en ROJO. Por motivos de seguridad, todo el material que sea expuesto aquí (exceptuando software propietario o libre, citaciones expresas o código de terceros) tanto texto, imágenes y código son propiedad del autor y está completamente prohibido su reproducción completa o parcial en otros lugares, espero que se comprenda.

 

IP Spoofing

Por IP Spoofing entendemos la técnica por la cual falseamos una IP origen (normalmente) con el objetivo habitual de burlar Firewalls, ocultar la identidad (Decoy), poner aprueba nuestros propios servidores, evitar que puedan ser bloqueados por sistemas de filtrados IPs…

A estas alturas todos deberíamos de saber que es una IPv4 y la importancia que tiene. Cualquier equipo conectado a Internet posee una dirección única llamada dirección IP. Por lo tanto, no es ninguna extrañeza poder modificar esta IP para los medios explicados. Si una dirección IP es falseada, se podría por consiguiente engañar al enrutador que se encuentre por encima de dicha persona, de forma que para el destino alcanzado el origen no sea realmente el atacante, lo que brinda diferentes capas de seguridad.


Quizás el ejemplo más extendido a todo esto no deja de ser lo que comúnmente conocemos por servidores Proxys. Los servidores Proxys es un servicio instalado (Proxy) en un servidor (generalmente) que actúa simplemente como intermediario de cierto tipo de peticiones a través de la red. Dado que se encuentra en medio de un cliente y un destino, este Proxy puede realizar cualquier tipo de modificación en los datos recibidos (tanto por el origen como el destino). Por ejemplo pueden usarse para filtrar Spam, cambiar Users Agents, eliminar o añadir publicidad… aunque quizás su uso más extendido es el evitar los filtros en Internet basados en IP, es decir… actuar como sistemas de IP Spoofing. ¿Por qué? Es simple. Cada vez que realizamos una petición web (por ejemplo) a un servidor, este recibe la IP de origen. El servidor por tanto puede actuar según esa IP:

  • Conexiones por tiempo limitado a dicha IP. Pasado X tiempo no es posible volver a conectar por dicha IP.
  • Seleccionar el contenido según la IP: Si la IP pertenece a españa contenido A, si la IP pertenece a Francia contenido B.
  • Filtrar el contenido: Si la IP pertenece a españa, no hay filtración, si la IP pertenece a China, filtrar contenidos en contra del régimen Chino.
  • Etc…

¿Pero qué sucede cuando dicha conexión la realizamos a través de un servidor Proxy?

Si el servidor se encuentra en nuestra misma red, la IP pública saliente de nuestra red sería la misma. Por el contrario, si el servidor proxy al cual accedemos se encuentra situado por ejemplo en francia, todas nuestras peticiones que salgan de él (o no, dependiendo del tipo de servidor proxy que sea) tendrán la IP “falsificada”, más correctamente, “modificada”, de forma que de cara al servidor web del que deseamos información, tan solo obtendrá la IP del servidor proxy intermediario. El límite de la aplicación práctica de esto tan solo lo tiene la imaginación. Tener en cuenta que prácticamente cualquier “ataque” o investigación que se quiera hacer de forma efectiva, la primera pauta es la invisibilidad y no llamar la atención. También hay que tener en cuenta que esto no garantiza en modo alguno el anonimato pleno. Hay servidores Proxys que no son realmente anónimos, e incluso los que puedan ofrecer la mejor anonimidad (por ley) suelen guardar registros que pueden ante una orden judicial obtener el origen real.


Veamos un ejemplo de IP Spoofing por medio de un servidor Proxy. Para tal efecto y comprender el alcance de este tipo de prácticas, voy a dirigirlo hacia una cuenta de correos Gmail. Para quien no lo sepa, Gmail guarda un registro de las IPs que han accedido a dicha cuenta, de forma que podríamos saber (con suerte) si alguien está accediendo a nuestra cuenta. Para ello ilustraremos dos accesos. El primero un acceso normal a través de mi dinámica de telefónica, y en segundo lugar un acceso a través de un servidor proxy de Korea:

 

Fase 1: Conexión Normal, Petición de mi explorador:

Host mail.google.com <- Host al que se solicita la conexión, IP del destino la corespondiente a dicho host: 209.85.229.19
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100128 Minefield/3.7a1pre
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive


Fase 1: Conexión Normal, respuesta de Gmail:

Access Type [ ? ] (Browser, mobile, POP3, etc.) IP address [ ? ] Date/Time (Displayed in your time zone)
Browser * 79.145.120.209 6:33 pm (0 minutes ago)

This computer is using IP address 79.145.120.209


Fase 2: Conexión mediante Proxy, Petición de mi explorador

Host mail.google.com <- Host al que se solicita la conexión, IP del destino NO corespondiente a dicho host: 121.128.203.159
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100128 Minefield/3.7a1pre
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive

Podemos observar la IP por ejemplo con un Sniffer:

Fase 2: Conexión mediante Proxy, respuesta desde Gmail:

Access Type [ ? ] (Browser, mobile, POP3, etc.) IP address [ ? ] Date/Time (Displayed in your time zone)
Browser * 121.128.203.159 6:33 pm (0 minutes ago)

This computer is using IP address 121.128.203.159


Si realizásemos una consulta en servidores Whois para determinar la localizción de cada una de las dos IPs registradas en Gmail, obtendríamos lo siguiente:

Whois 79.145.120.209

IP address: 79.145.120.209
ASN Name: Telefonica-Data-Espana (Internet Access Network of TDE) <- Pais y proveedor de dicho acceso a Gmail
Registrar (per ASN): RIPE
Country (per IP registrar): ES [Spain]
Country IP Range: 79.144.0.0 to 79.159.255.255
Country fraud profile: Normal
City (per outside source): Sevilla, Andalucia <- Este dato NO es fiable. En mi caso es cierto, podría obtener también Ciudad.
Private (internal) IP? No
IP address registrar: whois.arin.net
Known Proxy? No


Whois 121.128.203.159

IP address: 121.128.203.159
ASN Name: KIXS-AS-KR (Korea Telecom) <- Callejón sin salida, la conexión se realizó desde Korea Telecom [Korea]
Registrar (per ASN): APNIC
Country (per IP registrar): KR [Korea-KR]
Country Currency: KRW [Korea (South) Won]
Country IP Range: 121.128.0.0 to 121.191.255.255
Country fraud profile: Normal
City (per outside source): Unknown <- Sin ciudad aproximada
Private (internal) IP? No
IP address registrar: whois.arin.net
Known Proxy? No


¿Como podemos evitar que puedan usar contra nosotros Proxys? ¿Como podemos protegernos o descubrir la identidad de aquellos que actuan detrás? No podemos. Dado que las conexiónes Proxys se realizan a equipos físicos externos, a veces será posible detectar que dicha persona se encuentra detrás de un Proxy e incluso su IP real, y a veces en el mejor de los casos podremos conocer tan solo que dicho usuario accedió por medio de un Proxy. De nuevo en dicho caso, tan solo en el mejor de los casos podríamos conocer a dicho atacante por medio de una orden judicial siempre y cuando dicho servidor proxy detectado guardara Logs y otros que puedan identificar el verdadero origen.

En caso de Proxys trasnparentes existen técnicas para intentar detectar a los clientes, por ejemplo mediante el uso de resoluciones DNS inversas, scripts, scan a puertos específicos de dicha IP para ver si pueda tratarse de un servidor proxy… etc. Eso deja muy pocas opciones para la detección, tan solo bases de datos actualizables con listados de servidores proxys que se desean filtrar.

Por otro lado el uso de servidores proxys es peligroso y son lentos. Son lentos dado a que tus peticiones tienen que circular mucho más allá que meramente el host destino, y además depende de la capacidad del servidor proxy. Por otro lado son altamente inseguros, dado que la confianza la depositas a un equipo que no conoces. Este servidor proxy puede ser creado con fines malignos por ejemplo, y registrar todo el tráfico que circula por ellos, recolectando por ejemplo todo tipo de usuarios o contraseñas que sean transmitidos en formato plano.


Pero no todo se cierne sobre servidores Proxys. Otro uso habitual es la ocultación de huellas que puedan ser dejadas bajo un ataque. Dado que cualquier actividad en Internet deja el rastro de la IP, si cualquier usuario quiere pertrechar un escaner, un ataque, un acceso… lo último que a dicha persona le gustaría sería ser detectado. Por supuesto siempre se podría intentar eliminar los registros de entrada… pero aun así, sería un suicidio actuar por medio de su IP real. Para ello existen dos métodos clásicos. PCs Zombis e IP Spoofing. Un PC zombi no es más que un PC que por una cosa u otra está a mercé de un atacante, ya sea porque se ha tomado control de él anteriormente o por otras técnicas. Estos PCs zombis se usan mas tarde para realizar desde elilos los diferentes escaners o ataques, de modo que a todos los efectos, dicho PC Zombi es el culpable de todo.

Si bien hemos usado proxys como tecnicas de Spoofing, esto no es estrictamente cierto, al igual que no lo sería un PC Zombi, dado que no estaríamos modificando la IP (modificando los frames in situ), tan solo nos valemos de dichos servidores y usuarios para ello.

Mostraré por tanto lo que sí sería estrictamente realizar IP Spoofing. Para mostrar esto, se realizará un simple escaner de puertos (cosa que será tratado en otro artículo). Primero se realizará un escaner normal, a continuación un escaner ocultando nuestra IP (IP Spoofing), y para finalizar un Decoy. Decoy no implica un IP Spoofing necesariamente, un Decoy es una técnica por la cual se puede ocultar el origen real haciendo que este se pierda entre una “nube” de otros “atacantes”, ya sean estos ficticios o reales:

Host Origen: 192.168.2.2, Host Destino: 192.168.2.5


Fase 1: Escaner estandar de los puertos 21, 22 y 80 mediante la técnica TCP Syn sin IP Spoofing:





nmap -p21,22,80 192.168.2.5





Como se observa en la imagen, queda registrado que la IP origen (192.168.2.2) es quien realiza el escaner. Primero se realizan los intentos de sincronización por parte del origen. Si el destino contesta con una señal de reset [RST] el puerto está cerrado. Si el destino responde con un [ACK] indicará que el puerto está abierto. Si no responde nada, el destino está “muerto” (al menos en apariencia). Así los puertos 21 (ftp) y 80 (web) responden cerrados, y el puerto 22 (SSH) responde abierto. Todo esto se tratará en detalle en otro capítulo que no nos atañe ahora.

 

Fase 2: Escaner estandar de los puertos 21, 22 y 80 mediante la técnica TCP Syn CON IP Spoofing:





nmap -p21,22,80 -e eth7 -S 192.168.2.222 192.168.2.5





En cambio, como se puede apreciar la supuesta IP origen ahora es 192.168.2.222, host que no existe siquiera. El verdadero host origen (192.168.2.2), el que pertrecha el escaner, queda completamente oculto.

 

Fase 3: Escaner estandar de los puertos 21, 22 y 80 mediante la técnica TCP Syn CON Decoy:





nmap -p21,22 -e eth7 -D 192.168.2.3,192.168.2.4,192.168.2.8 192.168.2.5





En esta ocasión, el escaner aparenta venir desde muchos host simultaneamente. El objetivo responderá las peticiones de cada host. Aunque solo es un concepto realizando un Decoy simple (y lleno de fallos) desde UN MISMO host (192.168.2.2) se puede hacer mucho daño. Imaginar por ejemplo aumentar el número de host a 100, 200… los que sean necesarios.

 

Todo tiene su utilidad, sus ventajas… pero también sus inconvenientes. Para poder realizar las técnicas descritas, no se puede realizar un Spoofing de la IP que se desee, si se usa una IP que no se encuentra dentro de la misma subred que el enrutador que esté por encima del atacante, este no sabrá que hacer con los paquetes enviados desde el origen con una IP falsa. Esto hace que el ámbito de IP Spoofing explicado en el escaner o en otros posibles “ataques”, sea útil tan solo efectuado sobre una red local, dado que el router por encima de esta posíblemente no sería capaz de reenviar los paquetes (o recibirlos). Por supuesto siempre se podría escapar de esta limitación con una conexión directa a Internet, con lo que la subred por encima podría ser toda la subred del ISP del atacante.

En cualquiera de los casos, el IP Spoof no solo tiene como objetivo ocultar. Existe otra utilidad quizás más importante. Evitar los Firewalls o poder acceder a recursos que de otro modo no sería imposible. Por ejemplo imaginar una sección o subred de una LAN que está protegida por un Firewall, el cual no permite el acceso a IPs por debajo de 192.168.2.50 (por ejemplo). Falseando nuestra IP podríamos alcanzar el otro lado.

Sobre Decoy exactamente lo mismo. En el ejemplo ilustrado se realiza desde el mismo Host, pero imaginar un Decoy realizado por un conjunto de 2000 PCs Zombis repartidos por todo el mundo, los cuales de forma sincronizada realizan un acceso, un escaner, un ataque hacia un servidor concreto. Aun cuando mirasen en los registros tendrían 2000 posibles IPs, de las cuales quizás tan solo una sería el origen de todo. O evidentemente siempre se podría realizar las dos técnicas simultaneamente, las aplicaciones son innumerables.

¿Pero como se puede evitar este tipo de técnicas hacia nosotros? En caso de Decoys, habría que examinar con determinación los logs de accesos con la esperanza de notar algún comportamiento anómalo o diferente de alguna de ellas… aunque siempre se podría realizar de tal forma que fuese complicado de poder localizarlo, por ejemplo aumentando el número de hosts, usando accesos entre otros hosts… ¿Y sobre IP Spoofing? Usar tablas MAC estáticas o puertos ethernet fijos para subredes delicadas, usar protocolos de encriptación, acceso a ciertas redes tan solo por medio de certificados…

 

En los próximos días

Aprovechando estos días en los que tengo más tiempo libre por un lado, y que tengo que preparar cierta documentación sobre seguridad para cierto cliente, voy a dejar un pequeño resumen de lo que tengo pensado que irá siendo estos días. Principalmente estará todo orientado a la seguridad informática, aunque posiblemente abriré algunos paréntesis para otros temas.

Hay algo curioso cuando se habla de seguridad informática. Parece que aun cuando existe mucha información sobre cualquier cuestión en la red, rara vez encuentras casos reales. Una cosa es la teoría, otra cosa es la práctica. Así que lo que pretendo será crear una serie de boletines pseudo-prácticos. Y digo Pseudo pq no pretendo enseñar a nadie como intentar asaltar un sistema informático, sino más bien lo contrario, como protegernos de ellos, o al menos conocer un poco más sobre todo este mundo underground. Es posible que la lista crezca, disminuya o simplemente se agrupen varios temas en el mismo, pero esta es la idea por ahora:

  • El tablet de Apple
  • iPhone OS 4.0 ¿?
  • Spoofing  (Publicado)
  • Encriptación y Autentificación (Publicado)
  • DDOS
  • ARP
  • Sniffers
  • Bash
  • Scanners de puertos/Scanners de vulnerabilidades
  • Floods (Recordar ICMP)
  • Inyección SQL / XSS
  • DNS
  • Envenenamientos
  • Firewalls
  • Otros

Seguro que se me olvida algo. Algunos “boletines” podrán ser completamente prácticos, e intentaré mostrar vulnerabilidades REALES y potencialmente aplicables. Otros serán tratados en mejor profundidad tanto por el peligro que podría ocasionar como por supuesto la imposibilidad por mi parte (primero no quiero, segundo no se si podría) para reproducir un ataque completo, por ejemplo realizar un ataque DDOS. La idea es que aquel que le interese pueda más o menos verificar y comprender las cuestiones que se tratan… y no se aburra demasiado.

El problema es que cada cuestión podría abarcar desde unas simples letras descriptivas a casi un solo libro para ello. Así que cuando no esté con alguna noticia digna de mención (como el lanzamiento del Tablet PC de Apple que desde mi punto de vista será algo absurdo), iré entrando en materia sobre los temas citados. Posiblemente cuando termine todo (si lo acabo) lo recolecte todo en un documento.

Por supuesto si alguien tiene interés concreto en algo… puede dejar su sugerencia.

Eso es todo amigos.

HTML 5, H264 y YouTube

Hace una semana aproximádamente, Google sacó una interesante noticia sobre que su portal YouTube estaba probando una nueva versión de este sin el uso de flash, solo usando el nuevo estandar HTML5. Vamos a explicar un poco que pasa y que es esto.

HTML5 es una nueva especificación HTML (el lenguaje de programación usado en la red) que sustituye a la actual HTML4 con el fin de hacerla más independiente a otras extensiones o funciones implementadas por terceros que no son estándares. Así, HTML5 implementa una gran cantidad de funciones y posibilidades que actualmente no están disponible para HTML4. Por desgracia no es facil poner de acuerdo a todos los interesados para crear unas especificaciones que gusten a todos, y más cuando hablamos de un estandar que será usado en muy poco como algo prácticamente mandatorio.

El problema? Implementar un estandar nuevo en los navegadores no es algo tan sencillo. Lo bueno es que no se requieren de nuevos servidores Web, pero los navegadores si quieren poder interpretar las nuevas páginas, tienen que estar adaptadas a ello.

Hay que tener en cuenta que actualmente no existe ningun navegador en el mercado que sea completamente compabiel con HTML5, ni mucho más lejos!! hay navegadores que tienen ya implementadas ciertas, repito, ciertas especificaciones y funcionalidades de HTML5.

El problema lo ha ocasionado esta vez Google con YouTube. Entre las muchas características que tiene HTML5 es la posibilidad de incrustación de videos sin necesidad de pasar por tecnologías de terceros como Flash, SilverLight… sino que el mismo motor de renderizado (layout) del navegador sería el que sabrái interpretar el video y tendría los codec necesarios para poder visionar el contenido. La idea es muy buena, por ejemplo de este modo no sería necesario ya tener que pagar licencias flash para crear contenido y poner videos en dicho formato. ¿Pero cual es el problema entonces? El problema es decidir que Codecs tomar por estándares en HTML5. Y aquí comienza la guerra.

Mozilla desde la versión 1.9.1 de Gecko (su layout, lo que fue la versión 3.1 de Firefox) soporta la funcion de HTML5 de videos, pero tan solo implementa el codec de Video Theora y el Codec de Audio Vorbis. Esto no es una decisión precipitada ni mucho más lejos, lo que sucede es que ambos codec son de uso completamente gratuito, así como su implementación a todos los niveles. En su contra tiene que no son los mejores Codec del mercado ni mucho menos.

Ópera por su parte hizo exáctamente lo mismo desde la versión 2.5 de Presto (su layout o engine), implementando los mismos codec que Firefox.

Google Chrome (o Safari, los dos comparten el mismo layout) por su parte no estaba muy de acuerdo, y en WebKit 525 implementaron tanto Therora/Vorbis como H264/AAC.

Internet Explorer por contra, y su Engine Trident, no soporta directamente ni uno ni otro, no es compatible con esta función de HTML5, de echo a penas implementa nada de HTML5.
————-

Sin duda alguna H264, aka MPEG4 part 10, aka AVC, es el mejor codec ahora mismo que existe para el vídeo, dejando muy atrás a Theora. El problema sin embargo es que está fuertemente patentado. En realidad el sentido común nos dice que si lo que se pretende es crear un estandar, este estandar deberá de ser abierto, no tendría mucho sentido crear un estandar que los propios desarolladores tendrían que pagar para poder usarlo si quieren publicar un video en h264. Por otro lado tampoco tiene sentido que Mozilla o Google tengan que pagar la friolera cantidad de 5 Millones de dolares al año en concepto de licencia para poder implementar este codec. Si, no he nombrado ni Apple ni MS por una sencilla razón. Tanto Apple como MS son por así decirlo vendedores de licencias de la MPEG LA, con lo que casi con toda seguridad ellos o no tendrían que pagar nada o tendrán seguro contratos mucho más permisivos y cuotas igualmente rebajadas.

El problema salta estos días pq YouTube ha sacado una nueva versión específica con soporte para HTML5 pero usando h264, por lo que tan solo aquellos que usen ahora mismo Chrome o Safari podrían usar dicho sitio.

Es complejo… por un lado yo soy defensor aférrimo de los estándares… pero tb lo soy de H264. Usar Theora es un retraso en cuanto a tecnología se refiere, pero es cierto que la licencia de uso de H264 no será liberada hasta finales de 2010. Lo ideal sería evidentemente que la MPEG LA concediese licencias gratuitas o llegan a acuaerdos con Mozilla, pero esto es complicado y poco creible. Y no solo afecta a los propios navegadores!! Ahora mismo si has comprado la suite Flash puedes crear un video flv codificarlo en H264 y publicarlo. En cambio si lo haces sobre html5 no hace falta pagar a Adobe por flash… pero si es un vide “comercial” tendrías que pagar licencias igualmente a la MPEG LA para poder publicarlos… lo cual es como digo absurdo para un estandar. Apple evidéntemente prefiere H264 por uan cuestión de que ellos no tienen que pagar nada, y MS ni siquiera soporta actualmente HTML5. ¿Pero porqué entonces Google ha comenzado abriendo este portal en h264 para HTML5?

Es facil… H264 es mucho mejor codec, lo que implica que para la misma calidad obtienes videos más pequeños, lo que se traduce en menos ancho de banda para Google y menos espacio para sus videos. Si tenemos en cuenta la embergadura de YT, no estamos hablando de unos cuantos megas al año. Y por otro lado, google ya tiene su propia plataforma para codifiación de h264, no olvidemos que flash desde hace ya tiempo usa h264 como codec. Para Google es mucho más comodo y mejor.

Aun no se sabe como va a acabar todo. El sentdo común nos dice que se debería de usar Theora… al menos un año más hasta que vayan cumpliéndose las patentes. Tb sabemos que Google no suele tener problemas en rectificar, y sinceramente si ve que es un problema, se adaptará a Theora, no tienen los remilgos e historias de Apple. Aun así… habrá que esperar. Si se extendiese el uso de HTLM5 con H264 supongo que al fina Firefox se vería obligado a pagar los 5Millones de dolares al año… aunque esto sería una carga al final para todos.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.