Archivo

Archive for the ‘Seguridad’ Category

Interesante modo de monetizar dominios vencidos

diciembre 2, 2010 Deja un comentario

Una de las formas de generar inteligencia colectiva en la lucha contra el omnipresente spam, es usar blacklist (listas de IP de los que alguien ha reportado recibir spam). Hay infinidad de servicios de blacklist como SpamCop o SPAMHAUS, ambos muy populares. También hay servicios más pequeños e incluso mantenidos por usuarios independientes. La forma de implementarlos no es muy complicado ya que se usa el protocolo DNS para validar IPs, de alli deriva el nombre DNSBL (DNS Black List).

Básicamente la persona o institución que desea hacer público su blacklist debe levantar un servidor DNS que acepte peticiones regulares de resolución y retorne un valor válido si el IP está listado, dando la opción questionar a través de una solicitud “TXT” la razón de la inclusión en la lista. En principio todo muy sencillo, pero aclaremos la cosa con un ejemplo.

Supongamos que deseamos saber si el IP “100.110.120.130”  está listado en la base de datos de fuentes de spam en SPAMHAUS, para ello debemos hacer una solicitud de resolución DNS al servidor sbl.spamhaus.org. La única particularidad es que debemos hacerlo poniendo el IP en orden inverso y añadirlo al nombre de host al cual estamos haciendo la solicitud de esta manera:

$ nslookup -q=A 130.120.110.100.sbl.spamhaus.org

** server can’t find 130.120.110.100.sbl.spamhaus.org: NXDOMAIN

Si el IP no está listado deberíamos obtener un listado como el anterior. Pero a que viene todo esto, pues simplemente a que yo uso una gran colección de blacklist para proteger a mis servidores de correo del spam, y siempre estoy vigilando que ninguno de mis servidores esté listado en ellas, para tal fin tengo un script que corre cada hora y verifica que ninguno de mis servidores está listado, de estarlo inmediatamente me notifica con un mensaje SMS a mi celular. Entonces resulta que el día de hoy recibí la alerta de que uno de mis servidores estaba listado en “bl.csma.biz“, inmediatamente me puse manos a la obra para delistar mi IP del blacklist, pero grande fue mi sorpresa cuando encontré esto:

CSMA.BIZ Expired

Si adivinaron el dominio expiro y a los chicos de Network Solutions no se les ocurrió mejor idea para monetizar el tráfico que crear una respuesta válida a toda consulta DNS sobre dicho dominio, resultado ha sido para los que usamos la solución DNSBL, toda internet está incluída como fuente de spam en la lista administrada por el servidor bl.csma.biz.

Para demostrarlo hagamos un experimento. Por ejemplo hay IPs que nunca deben estar en un blacklist, este es el caso específico de todas las IPs privadas como 10.0.0.0/8, 172.16.0.0/12,  192.168.0.0/16, demás del localhost 127.0.0.0/8. Preguntado sobre esos valores el DNSBL del servicio bl.csma.biz simpre responde afirmativamente apuntando a la página que ofrece el dominio en venta.

$ nslookup 1.0.0.127.bl.csma.biz
Non-authoritative answer:
Name:   1.0.0.127.bl.csma.biz
Address: 209.62.105.19

$ nslookup 1.0.0.10.bl.csma.biz
Non-authoritative answer:
Name:   1.0.0.10.bl.csma.biz
Address: 209.62.105.19

$ nslookup 1.0.16.172.bl.csma.biz
Non-authoritative answer:
Name:   1.0.16.172.bl.csma.biz
Address: 209.62.105.19

$ nslookup 1.0.168.192.bl.csma.biz
Non-authoritative answer:
Name:   1.0.168.192.bl.csma.biz
Address: 209.62.105.19

No interesa que pongan delante del nombre bl.csma.biz, el DNS atumáticamente apunta a la página de la publicidad. Esto me parece sorprendente de una compañía que tuvo la exclusividad de la venta de dominios .com, .net y .org durante muchos años. Acaso no hay nadie que sepa que hacer esto puede tener efectos colaterales como el hecho de generar rechazo de correos o el que muchos correos terminen en el “Junk Folder” de muchos servicios de correo, o simplemente no interesa la usabilidad y solo desean más tráfico para monetizar la publicidad en los dominios.

Espero que el propietario del dominio csma.biz lo habilite, por lo menos yo como contra medida lo ha retirado de la lista de servicios DNSBL que utilizo.

Nook 2 + hack = Tablet de $250

diciembre 1, 2010 Deja un comentario

El día de hoy la web está llena de artículos (ver ITWorld, Android and Me, Andronica y Android Central) sobre como la gente de xda-developers, una comunidad de fans de smartphones Windows Mobile y Andorid de casi 3 millones de personas alrededor del mundo, consiguieron ganar privilegios de root en el Nookcolor (aka Nook 2) y pueden instalar cualquier tipo de aplicaciones en eBook de Barnes & Noble, con lo cual un eBook de $250 con el hack apropiado puede ofrecer las mismas funcionalidades que una tablet de $600 como es el Samsung Galaxy Tab.

El procedimiento para ganar privilegios de root aún no es sencillo, pero está documentado con todo detalle en la wiki de NookDevs, los detalles técnicos del Nookcolor se pueden encontrar en el website de Barnes & Noble, pero hay que aclarar que la única desventaja de usar un Nookcolor como tablet es el hecho de que no tiene cámara de video, algo que al parecer no ha alejado a muchos del iPad, hasta la fecha el tables más vendido.

Como prueba de su logro la gente de xda-developers ha subido un video a YouTube en donde se puede apreciar un Nookcolor siendo usado para popular jugar Angry Birds. Aquí el video:

 

 

La pregunta es si Barnes & Noble no hará nada al respecto y dejará que sean los entusiastas quienes decidan el destino del Nookcolor, o tratará de cerrar las puertas a futuros hacks y mantendrá al eBook como lo que es, para evitar entrar en competencia con jugadores más técnicos como son los fabricantes de tablets, por sólo mencionar algunos Apple, Dell, Samsung o HP.

Lo que si está claro es que no hay razones ni técnicas, ni tampoco económicas para que las tablets con Android tengan precios tan elevados como los actuales, definitivamente si la Nookcolor con este hack gana popularidad, todos los demás fabricantes de tablets deberán de comenzar a reformular sus estratégias de mercado, recordemos que estamos en un entorno donde todos los compradores están buscando como maximizar el poder de compra de su dinero.

El nuevo rootkit TLD4 amenaza millones de PC con Windows 7 y Vista

noviembre 16, 2010 Deja un comentario

Me he enterado a través del blog ThreatPost, que existe un nuevo rootkit llamado TLD4 que resulta ser una variante de un rootkit anterior, pero que ahora tiene la habilidad de poder evitar una de las mayores medidas de seguridad que traen tanto Windows Vista como Windows 7. Como ya muchos sabran Microsoft introdujo una serie de nuevas características de seguridad diseñadas para evitar que el código malicioso llegue a ejecutarce, algo que Microsoft ha llamado "Kernel-Mode Code Signing Policy" (o Política de firma de código en el modo-Kernel). Sin embargo, los atacantes están continuamente encontrando nuevas formas en evitar a estas medidas de protección, y el ejemplo más reciente es un rootkit que puede pasar por alto la protección de firma de drivers de Windows.

La funcionalidad se encuentra en TDL4, que es la última versión de un viejo rootkit también conocido como TDSS o Alureon. TDSS ha causado serios problemas para los usuarios durante más de dos años, y es un ejemplo de un tipo particularmente pernicioso de rootkit que infecta el sector de arranque de un PC. A este tipo de malware se le llama a menudo "bootkit" y puede ser extremadamente difícil de quitar una vez que se detecta. Las versiones anteriores de TDSS – TDL1, TDL2 y TDL3 – son detectados por la gran mayoría de los antivirus actualmente, pero el más problemático ahora resulta ser TDL4.

TDL4 tiene una función específica que está diseñada para evitar una protección en Windows 7 y Windows Vista que requiere que el código a nivel de kernel para ser cargado en una máquina debe estar firmado. Esta política de fima de código para todo programa en Windows en modo Kernel es también aplicable a las máquinas de 64 bits.

El rootkit TDL4 ha implementado una función que permite evadir esta protección, cambiando el proceso de arranque en máquinas protegidas, de acuerdo con un análisis del TDL4 de Sunbelt Software. El rootkit logra su cometido a través de la modificación de cuales programas Windows permite cargar como drivers sin firmar.

Aquí lo que escribió Chandra Prakash de Sunbelt Software en su análisis del TLD4:

"La opción de inicio es cambiada en la memoria del código ejecutado por un MBR infectado. Durante el arranque se configura el valor de una opción de configuración llamado ‘LoadIntegrityCheckPolicy" que determina el nivel de la validación de los programas de inicio. El rootkit cambia este valor de configuración y lo ajusta a un nivel bajo de la validación que efectivamente permite la carga de un archivo malicioso sin firma dll que resulta ser el rootkit y que se llama kdcom.dll, esta es una versión infectada de la normal kdcom.dll que se incluye con Windows."

Si eres usuario de Windows Vista o Windows 7, tal vez te convendría ver la presentación que hizo Joe Johnson de Microsoft sobre Alureon donde detalla la forma de operación del rootkit.

Categorías:Microsoft, Seguridad, Windows

¡Peligro Will Robinson!

noviembre 9, 2010 Deja un comentario

Microsoft publicó la semana pasada un boletín de seguridad para alertar al usuario a una falla en Internet Explorer 6, 7 y 8, que permite la ejecución remota de código. En el momento de la advertencia, la falla estaba viendo la explotada de una forma limitada con ataques dirigidos. Esta situación podría cambiar ahora ya que en el blog de AVG se reporta la existencia de un kit para hacer uso de dicha falla de seguridad.

El resultado es que cualquier persona con unos pocos cientos de dólares podría tener acceso a un ataque de día cero al Internet Explorer, abriendo la puerta a un uso generalizada del ataque a este popular navegador. Un código de prueba de concepto ha estado disponible desde la aparición del boletín oficial de Microsoft, pero la inclusión de la vulnerabilidad en el Eleonore exploit kit hace que sea mucho más fácil para los hackers poco cualificados desarrollar exploits monetizable.

Peligro Will RobinsonA pesar de que hubo reportes que los ataques iniciales fueron bloqueados por contramedidas tales como DEP y por lo tanto no podía ser aprovechado en Internet Explorer 8 en su configuración predeterminada, esto también podría cambiar a medida que la falla se combina con las soluciones DEP. El actual código de prueba de concepto deja como un ejercicio propuesto para el lector la solución a las contramedidas DEP.

Aunque Microsoft es consciente de la falla, un parche para la misma no ha sido incluido en los parches distribuídos por Microsoft el día de hoy martes (9 de noviembre 2010). Hasta el momento, la compañía no ha dicho cuándo un parche para esta vulnerabilidad estaría disponible, aunque la inclusión de un exploit en un kit de herramientas significa que va a estar bajo una presión adicional para liberar un parche en lugar de esperar a principios de diciembre fecha en que tocaría liberar los siguientes parches de los martes.

Una recomendación es que para evitar ser infectado de esta manera sería preferible usar otros navegadores como Firefox, Chrome u Opera.

Como hackear webcams usando Google

octubre 30, 2010 Deja un comentario

En la actualidad es muy común que muchas personas pongan webcams en sus casas para vigilarlas mientras están fuera, esto es posible en parte a dos factores, el primero es el increíble abaratamiento del acceso a Internet desde casa con suficiente velocidad para mantener el streaming de video y el segundo es el bajo costo de las webcams, que pueden ser adquiridas con tan poco como $15.

En principio usar una webcam para controlar lo que pasa en la oficina o casa cuando no estamos puede parecer una buena idea para aquellos que son fanáticos del control total, algo que no existe, pero que muchos desean. El problema es que muchos de estos aspirantes a dictadores, son lo suficientemente listos para saber que producto comprar y como configurarlo, o al menos tienen el suficiente dinero para pagarle a alguien que sea lo suficientemente listo para hacerlo; sin embargo son lo suficientemente tontos para olvidar ponerle password a la cámara, con lo cual cualquiera que conozca el URL de la misma podría tener acceso a ver el contenido transmitido por la webcam. Es en este escenario donde entra en juego Google, el gran indexador de la web.

La verdad es que el método descrito aquí no permite hackear una webcam en si misma, sino que nos permite usar Google para encontrar todas aquellas webcams (miles al parecer) que están desprotegidas y sólo confían en que nadie accederá a ellas porque se esconden en puertos no estándares o crípticas direcciones URL. El problema es que Google sistemáticamente explora toda la web e indexa todas las direcciones que encuentra, entonces lo único que es necesario saber para encontrar estas webcams vulnerables es qué secuencia de caracteres buscar. En este URL encontré una primera pista, pero luego de averiguar un poco más encontré que se pueden ubicar estas cámaras desprotegidas usando estos criterios de búsqueda en Google:

inurl:"axis-cgi/mjpg"
inurl:"ViewerFrame?Mode="

inurl:"view/index.shtml"

inurl:"MultiCameraFrame?Mode="

Quiero resaltar que esto lo hago público con fines de divulgación, que no promuevo el hacking en ninguna forma y que sólo deseo despertar el interés público por la seguridad en la web, ya que es en nuestros días es una parte muy importante de nuestras vidas, recordemos que lo que pongamos en la web queda para siempre y el olvido ya no existe en el siglo XXI, algo que comenté en un post anterior de este blog llamado "El fin del olvido".

Categorías:Actualidad, Google, Seguridad

Vampiros vs. Hombres Lobo

octubre 3, 2010 1 comentario

El presente título copia el de un post del blog Coding Horror, en el cuál Jeff Atwood nos cuenta como muchas veces los programadores (que el asocia con los vampiros) entran en conflicto con los system administrators (que son representados como hombres lobo). La pregunta que origino el post de Jeff, fue formulada por su sysadmin Kyle Brandt en el blog de Server Fault, que tanto control se le debe dar a los programadores sobre servidores en producción.

Aunque como dice tanto Jeff, no hay una respuesta simple y por el contrario en lugar de buscar este conflicto entre sysadmin y programadores, lo que dbe haber es una autoridad superior que defina objetivos claros para la empresa y los haga trabajar juntos en busca de un objetivo común, en lugar de que inicien discusiones unos contra otros. Jeff dice claramente que en muchos lugares donde esto ocurre es simplemente porque la división del trabajo no ha sido hecha adecuadamente y hay demasiado tiempo libre para perderlo en disputas sin sentido.

Por otro lado algo que no se discute en el post es que suscede en la empresas pequeñas, en donde los roles se vuelven más difusos debido a las limitaciones de presupuesto. Es en las pequeñas empresas donde por lo general el programador hace las veces de sysadmin o puede suceder que un sysadmin termina convertido en un programador por acceidente.

Yo, soy por definición un sysadmin, ya que tanto por vocación, como por formación soy un ingeniero (mecánico electricista para más señas). Es decir carezco del sentido estético del que muchos programadores se enorgullecen. Por el contrario yo estoy más enfocado en eficacia y eficiencia, es decir terminar el proyecto dentro del presupuesto, en el tiempo estimado aunque haya que aplicar ciertos ajustes (muchas veces recortes) en el camino, ya que una solución parcial es infinitas veces mejor que una solución perfecta en un futuro distante.

Por el contrario muchos de los programadores con los que me he topado, suelen por lo general querer inventar la rueda, no desean usar código de otros programadores y sienten un profundo rechazo a documentar su código, algunos dicen que eso les reduce su productividad y hay que casi amenazarlos de muerte para que lo hagan.

En fin, este es un debate abierto ya que cada lado puede señalar los defectos del otro, sin embargo hay que sobre todo ser tolerantes y aprender a convivir en una empresa que necesita que ambos roles trabajen juntos, en lugar de estar tratando de demostrar quien tiene la razón.

Una mente brillante no significa un buen corazón

septiembre 15, 2010 1 comentario

La noticia más importante de los últimos días para mi, no está relacionada con la manipulación de las bolsas de valores, la destrucción del valor de la moneda a nivel mundial o Google Zeitgeist, sino la historia de David Barksdale, un ingeniero de Google que aprovechó su posición para acosar menores de edad (la motivación sexual no es clara, aunque no se descarta), espiando en su cuentas de Google Voice (telefonia/SMS) y Google Talk (chat). Aquí algunos links donde leer más sobre este asunto:

Algo interesante que he descubierto es que si se google por el nombre "David Barksdale", lo primero que encontraremos es un link de wikipedia a un líden de pandillas de Chicago conocido como King David, supongo que esto es debido a que esto es algo reciente y los autómatas de Google aún no registran todo el jaleo que hay debido al caso del otro David Barksdale, el ingeniero que tuvieron que despedir.

Google, siempre nos cuenta que su proceso de selección de personal está basado en un conjunto de filtros que garantizan que ellos contratan a lo mejor de lo mejor, es más ayer Don Dodge (ex-Microsoft y ahora ferviente Googler) en su blog "The next big thing", nos comenta extensamente lo meticuloso, extricto y a prueba de fallos que resulta el proceso de selección de Google. Lo cual me parece bien, ya que por su posición, cualquier persona que trabaje en Google tiene acceso a muy importante y muchas veces privada información.

Una golondrina no hace verano, cualquier ser humano o institución (que al final es un conjunto de seres humanos), puede cometer errores; en este caso Google se equivocó al contratar a una persona que podría ser tecnicamente capaz, pero emocional y moralmente disfuncional. Un caso no pueder ser usado como una prueba de que Google está lleno de sociópatas, pero es una llamada de atención al hecho de que ahora somos más dependientes que antes de servicios como Facebook, Google Voice, Gmail o GTalk, que no están regulados y por lo tanto estamos en las manos de las empresas que los proveen.

La moraleja que puedo extraer de esta historia es que necesitamos crear una regulación para este tipo de nuevas tecnología que permitan definir responsabilidades y proteger a los más débiles, en este caso los ciudadanos que confiadamente creen en los servicios de estas compañías.