Archivo de la categoría ‘Seguridad’

HTTPS no añade legitimidad o credibilidad a una Web, brinda seguridad

Share on Google+Share on FacebookTweet about this on Twitter

Llevo ya días que al despertarme me topo con alguna noticia relativa a HTTPS, supongo que los responsables son Mozilla y Google, que desde primeros de años decidieron aplicar algunas medidas coercitivas en sus navegadores, lo que sucede es que como siempre si el usuario medio no entiende lo que quiere decirle un cartel de advertencia, al final da igual.

 

Brevemente, sobre el mensaje “nuevo” que estas dos compañías han instaurado. Es un ejemplo más que muestra el trabajo que cuesta a veces a los usuarios de perfil medio la diferencia entre seguridad y legitimidad de una página. Muchos empezaron a decir incluso que Google iba a advertir con mensajes a los usuarios sobre que una web no era segura… no tiene nada que ver con eso, de echo tanto Firefox como Chrome muestran exactamente lo que tienen que mostrar, la lectura que otros le quieran dar es diferente:

La primera es el mensaje que muestra Firefox, el segundo Chrome, este último también traslada un mensaje en la URL. En esencia dicen exactamente lo mismo. Ambas compañías simplemente muestran en pantalla ese mensaje cuando se dan dos circunstancias: La primera, estamos en un formulario que se reconoce un campo de contraseña donde vamos a introducirla. La segunda es que la Web en cuestión en la que vamos a introducir dicha contraseña no está bajo HTTPS con un certificado válido. Dicho de otro modo, al no estar la web bajo HTTPS, los datos que pongamos tanto en la contraseña como en el nombre de usuario, es posible que sean enviados en “texto plano”, es decir, tal como los introducimos, y por ende podrían ser potencialmente interceptados por alguien que “pinchase” la conexión en cualquier punto de esta.

Hay que entenderlo, no significa que la web sea insegura realmente, o que no sea legítimas. Lo que nos avisa es que si nuestra red no es segura (nos están robando WIFI, tenemos un familiar/amigo travieso conectado a ella, usamos una red pública…), alguien podría potencialmente leer ese tráfico, y claro… a lo mejor no importa tanto saber que visitas una web concreta o incluso el contenido de ella, pero si importa y mucho si lo que capturan es la contraseña de tu correo electrónico, de acceso a un servicio. Pero repito, nada tiene que ver con legitimidad o fiabilidad, y es más, esa advertencia puede no ser importante si sabemos perfectamente desde donde nos conectamos.

 

Volviendo al asunto original del artículo, estoy aburrido de leer “noticias” sobre HTTPS, Certificados TLS/SSL, “seguridad”… y casi todos ellos sesgados. El último ha sido esta tarde… no me gusta tirar tierra a nadie y respeto el trabajo de cualquiera, pero creo que hay que ser más riguroso en lo que se escribe, y por citarlos, hablo de un artículo en Xataka. A veces una coma o el modo de decir las cosas no importa y se sobre entiende, pero otras veces el significado es muy diferente sólo con que falte un acento. En este caso, y cito textualmente encontramos el problema de siempre, algunas frases muy poco afortunadas:

“Esto quiere decir, que una dirección web en la que tengas que empezar escribiendo https:// en vez del clásico http:// será siempre mucho más segura, ya que certifica que la web visitada es legítima…”

“Chrome están empezando a señalar como inseguras todas las páginas que no lo utilicen”

No voy a valorar el resto del artículo, por supuesto dice cosas totalmente ciertas, el problema es que hay otras que no lo son.

Por un lado, sobre el comentario que se hace de Chrome, es falso, siempre he dicho que una media verdad no deja de ser una mentira, intencionada o no. Chrome NO SEÑALA las webs como inseguras cuando no están bajo HTTPS, Chrome, al igual que Firefox, lo que hacen es mostrar un aviso en el campo contraseña (y Chrome también en la URL) cuando existe un campo contraseña, y ese aviso, aunque pueda usar la palabra “insegura”, especifica bien claro a que se refiere, al envío de información cuando se rellena un formulario o cualquier otra cosa. Este aviso no aparece si dicha web carece de cualquier campo de este tipo, esté en HTTPS o no.

Sobre la primera frase, realmente es lo que me llevó a volver al blog, no por Xataka realmente, lo de ellos ha sido una noticia más haciendo alusión a eso de dar legitimidad a una web o no.

 

¿Qué es y qué no es HTTPS?

HTTPS se basa en autentificación y cifrado entre el equipo de origen, y el servidor destino, de forma bilateral (por lo general la autentificación la realiza sólo el cliente, no el servidor). Que un servidor use HTTPS para servir sus webs, poco o nada tiene que ver con que esa Web sea más segura, o que dicha web sea quien dice ser, con la única excepción de que use certificados tipo EV en todo caso (en lo relativo con la identidad, es decir legitimidad).

La necesidad de HTTPS nace precisamente de los cartelitos que ahora muestran Firefox o Chrome. Cada vez más usamos las conexiones inalámbricas, cada vez más hay desconfianza de los ISP (proveedores de internet) e incluso de los propios estados!! Quien no conoce a día de hoy los casos de Wikileaks y tantos otros. El cifrado no es algo nuevo, y creo que todos lo entendemos bien… algo que no esté cifrado no significa que no sea seguro, significa que si alguien lo intercepta lo va a poder leer.

No veamos HTTPS como un ente tan extraño, se puede simplificar enormemente, pensemos en vez de HTTPS y páginas web en una carta, en que quiero hacer llegar una carta a mi amada, y para ello no tengo más opción que dársela a un amigo para que a su vez se la entregue a ella. A nadie se le escapa el problema, incluso si pusiésemos un lacre sellado, mi amigo podría abrirla y leer el contenido, y si el contenido de la carta no usa un código secreto que sólo entendiese ella y yo, pues mi amigo se enteraría de todo. En función de la relevancia de las letras que ponga en esa carta, usar un código secreto entre los dos puede ser simplemente un juego, a ser totalmente necesario.

En Internet, el amigo puede ser tu hermano conectado a tu misma red, puede ser un vecino que te roba WIFI, puede ser un desconocido conectado a la misma red pública (WIFI o cable), puede ser incluso si quisiese tu ISP, por supuesto el gobierno… y eso sin contar absolutamente cualquier punto por el que tus datos son transferidos hasta llegar al servidor final. Al margen de conspiraónicos y que los gobiernos y los ISP nos espíen, el principal problema no son ellos, son las redes en las que nos conectamos. Puede que no me haga gracia que, en caso de hacerlo, un gobierno quiera interceptar mis comunicaciones, pero a fin de cuentas tampoco tengo nada que considere “personal” para ellos, más me preocupa que desconocidos puedan conocer mis datos personales, cuentas y otros.

 Sí, el cifrado puede ser algo positivo, pero desde luego desde mi punto de vista indispensable cuando manejamos información personal o evidentemente confidencial, y HTTPS soluciona esto. Ya hablé en su día largo y tendido sobre ello en uno de mis artículos, y recientemente también en el de Let’s Encrypt, donde por encima explicaba todo esto, aunque en menor medida.

Inicialmente hablaba de legitimidad… HTTPS trata sobre cifrado de datos, no sobre legitimidad. Sí, el servidor se autentifica/identifica de cara al usuario, pero no para certificar que el contenido de la página es legítimo, ni siquiera que la propia web lo sea!! Lo que certifica en todo caso (de tener un certificado digital reconocido y excluyendo los certificados EV que veremos luego) es que dicho certificado fue emitido para dicho dominio específicamente, nada más. Dicho de otro modo, que el certificado que nos llegue a nuestro equipo, poder ser validado para estar seguros que quien nos los mandó es la web que tenemos delante.

Y en ese párrafo está toda la madre del cordero. Xataka dice que certifica que la web que tenemos delante es legítima… no es cierto, la web puede decir que es Paypal, la web puede ser un calco perfecto de cualquier página de un banco, e incluso podrían tener un dominio similar!! y por supuesto, podrían usar perfectamente un certificado digital (y usar HTTPS) validado. Evidentemente a mi modo de ver las cosas, no considero eso como una web legítima. Esto es algo que se está empezando a hacer de forma masiva, por la falsa creencia precisamente del usuario de creer que si ve el candado verde la web es fiable, y es un error de base. Sí, la comunicación con dicha web se hace de forma cifrada y ningún vecino nos intercepta la comunicación, pero los datos que enviamos llegan igualmente al servidor, y si esa web la hace una persona malintencionada, evidentemente tiene acceso a dichos datos, datos que nos acaba de robar por creer nosotros que por tener candadito verde la web era legítima de fiar.

Pero por supuesto, que son unas letras sin una buena imagen. Ni siquiera he tenido que invertir tiempo en hacer una prueba propia sobre esto, simplemente me ha bastado con  mirar en cualquiera de los servidores usados para los registros de transparencia de certificados (por ejemplo https://crt.sh), que registran los certificados emitidos por las diferentes agencias CA que los usan, y mirar los dominios para los cuales se registran. Yo he buscado por Paypal, que contengan los dominios “Paypal”, por ejemplo, y el primer certificado que he encontrado que contenía su nombre ha sido el que pongo ahora en la imagen:

Antes de terminar de escribir este artículo, habré reportado dicha web, con lo que es posible que si alguien intenta acceder Google SafeBrowser la esté ya indicando como página de Phising, pero ahora mismo esta totalmente operativa. Como podemos ver perfectamente, la web está protegida por HTTPS, con su candadito verde, su “Es seguro”, con una URL similar a alguna que pueda tener una página real de Paypal, y por supuesto su contenido un calco. Bien, este es un ejemplo sencillo, poco o nada tiene que ver con que esté bajo HTTPS y el certificado sea válido, el contenido puede ser totalmente fraudulento. Ni que decir tiene que posiblemente de meter ahí los datos, se los enviaríamos a una personal mal intencionada, pero muchos creerían que como la URL parece ser “buena”, y que pone “es seguro”, es de fiar. ERROR!!

 

Let’s Encrypt, el CA del que ya hemos hablado en otra ocasión, está siendo foco de grandes críticas por muchos (no hace falta ser un genio para saber que la mayoría de todas ellas por no decir todas vienen de los otros CA). Se les acusa de emitir certificados fraudulentos. Bien, primero tendríamos que matizar que es un certificado fraudulento, porque el ejemplo que he puesto anterior de Paypal, no es un certificado fraudulento, es un certificado totalmente legítimo, lo que no es legítimo y lo que es fraudulento es el contenido de la web mostrada, así como el uso evidentemente de la propiedad intelectual de Paypal y la suplantación de identidad. El certificado es legítimo siempre y cuando quien lo solicitó demostrase que era el dueño de dicho dominio, y recordemos que el dominio no es Paypal.com, el dominio comprado en este caso es “paypal-secure-info.gq”. Dado que las normativas sobre dominio permiten el registro de dicho dominio (lo cual es normal, no pueden vetar un dominio simplemente porque contenga una palabra que es marca comercial), sería totalmente injusto vetar la emisión de un certificado para dicho dominio. El problema no es el dominio, el problema no es el certificado… el problema es el uso que se haga de ello.

Algunos dicen que Let’s Encrypt en la “poca” vida que llevan, ya ha emitido muchísimos más certificados de este tipo que llaman “fraudulentos” que el resto de CA juntos. No lo dudo, es muy posible, pero por una razón sencilla… con los otros CA tienes que rascarte el bolsillo, 50-100€, pero te los emitirían igualmente por mucho que digan algunos que no permitirían certificados en dichos dominios, a fin de cuentas si el dominio está registrado correctamente, la emisión de un certificado estándar (de tipo DV, validación de Dominio) solo requiere para cumplir con las estrictas normas de seguridad la validación del propio dominio, nada más.

Ante esto Let’s Encrypt ya ha dicho más de una vez lo mismo. Ellos no son la policía ni el organismo competente para censurar el uso que puedan o no dar otros a las web, eso será cuestión de otros, y que por suerte herramientas como Google SafeBrowser o Internet SmartScreen, están para eso. Repito, lo mismo sucede con cualquier otro CA. De echo, para curarse en salud, Let’s Encrypt tan solo emite certificados DV.

Muy diferente es el caso cuando se desea un certificado EV, esos certificados que añaden antes de la URL el nombre de la compañía. Esos certificados emitidos por un CA requieren una serie de verificaciones y burocracia muy superior, que precisamente buscan eso, que se pueda tener cierta confianza de que la web visitada corresponde al contenido que tienen. En el caso de la web de paypal fraudulenta puesta arriba, les sería imposible lograr que pusiese delante de la URL lo que realmente veríamos en una web de Paypal:


El contenido es exactamente el mismo, y al margen de que la URL sean diferentes, evidentemente, en esta vemos el “sello” del certificado EV “Paypal, Inc. US”. La anterior sería imposible que lo lograse, incuso lograr algo similar sería casi imposible, a caso iban a crear una empresa llamada Paypal Secure bla bla bla y lograr todo lo que se requiere?? No, no lo lograría. Pero eso no invalida el certificado DV, ni tampoco le quita la gran importancia/necesidad que estos certificados (DV) tienen. De echo, como explicaba en el artículo de Let’s Encrypt, los certificados EV son muy caros, y la mayoría de entidades no los usan por no ser necesarios, mucho más importante que mirar el sello EV es mirar la URL, que ojo… puede engañar también (otro día hablaré de ello), pero pensar que si tomásemos una empresa no conocida podría tener legítimamente su sello EV y ser igualmente fraudulenta por el contenido que tiene.

 

Hace unos días apareció la noticia de que Google castigaba duramente a los certificados EV de Symantec (uno de los grandes CA) por detectar durante años la emisión de EVs de estos sin las necesarias y más estrictas condiciones. Recordar que un CA es fiable sólo en la medida que los navegadores Web y otros software se fían de ellos y añaden en sus productos los certificados raíces de estos. Dicho de otro modo, en cualquier momento tanto Google, Mozilla, Microsoft… podrían bloquear/anular los certificados raíces del CA que quisieran, dejando los miles o millones de certificados emitidos por ellas totalmente inservibles. Es por eso que son aquellos que crean el software que nos conecta los que deciden que certificados añadir y que normas y condiciones tienen que cumplir para permitirles estar dentro de su software, y si no lo cumplen o detectan irregularidades, no tienen problemas en eliminarlos o castigarlos del modo que estimen. Y sí, han caído empresas grandes cuyo principal volumen de ingresos era la emisión de certificados porque los navegadores los bloquearon por emitir certificados fraudulentos.

Vale, pero he dicho que los certificados fraudulentos no son tales… en que quedamos. Bueno, he dicho que el ejemplo anterior no es un certificado fraudulento, pero claro que se pueden emitir certificados fraudulento. El ejemplo más sencillo, si mañana me pongo en contacto con un CA y les pido que me emitan un certificado para google.es, y me lo mandan, es un certificado fraudulento, y no porque ya exista uno legítimo, eso es indiferente, es fraudulento porque el dominio google.es no es mío, e incluso un certificado DV se debe de emitir sólo si se puede verificar la propiedad de dicho dominio. Peor aun si hablamos de certificados OV o EV.

En el caso de Google y Symantec, según se ha dicho en la nota de prensa, Google detectó irregularidades en la emisión de certificados tipo EVs, y ha optado por medidas bastante serias, y durante un año irá invalidando dependiendo de las fechas de emisión de estos, los certificados EVs de Symantec (si leí bien). Y esto no es poca cosa, eso causa un daño enorme a Symantec. Es en una de esas pocas cosas que vemos el tremendo poder que puede tener una empresa que desarrolla una navegador Web para con otras multinacionales de gran peso e importancia.. bueno, google es un gigante, pero pensemos en Google como desarrollador de Chrome. Por supuesto Symantec les ha respondido, que han exagerado los datos, que les parece un “castigo” desmedido, que en el peor de los casos que Google lo lleve a cabo re-emitirá certificados nuevos para todos los afectos para que no se vean afectos… etc etc etc.

 

Conclusión

Por supuesto la credibilidad y fiabilidad de un sitio es o debería de ser muy importante, el problema es que no existe un sistema para ello. La mejor forma de legitimar una web es conociéndola, mirando siempre muy bien las URL, usar tecnologías como Google SafeBrowser (usada en Firefox o Chrome) o Smart-Screen usada en Internet Explorer. Tener siempre la seguridad, sobre todo cuando vamos a introducir cualquier dato sensible que la web que tenemos delante ES la web que dice ser, y no fiarnos de si usa HTTPS para eso o no. HTTPS nos asegura un cifrado, no la identidad que pueda parecer decir ya sea por el contenido o por la URL. Eso no invalida para nada la necesidad de HTTPS, puesto que incluso aunque una web sea fraudulenta, puestos a escoger, dentro de los males el menos malo sería que usase HTTPS, al menos tendremos la seguridad de que los datos sólo nos lo roba quien hizo la web fraudulenta, y no además otro que nos espíe la conexión por no usar HTTPS.

Con la aparición de Let’s Encrytp la web ha dado un buen giro, y donde antes nadie usaría certificados, ahora el uso se está expandiendo enormemente, ya sea un blog personal (ya, lo sé, no se lo tengo puesto al blog, en casa del herrero cuchillo de palo), ya sean empresas, tiendas online… y eso es bueno, con independencia de que algunos los quieran usar para otros fines.

Pero no nos equivoquemos, la culpa no la tienen esos desalmados, ellos simplemente se aprovechan como siempre del desconocimiento de los usuarios, las empresas de CA se han empeñado durante años a decir que los certificados son necesario para la confianza, para la fiabilidad… y muchas campañas se han hecho acerca de esto, así que el usuario normal ha tomado por válido ciertas cuestiones, como que si la web tiene un certificado seguro, la página es segura = fiable = de_confianza.

HTTPS sí, siempre que sea posible y el certificado sea válido, pero por favor… no dejéis nunca de revisar bien y mucho ante la duda la web que los use.

¿Son realmente necesarios los Antivirus? ¿Causan más mal que bien?

Share on Google+Share on FacebookTweet about this on Twitter

Buenas compañeros.

Es de estas veces que… digamos que estás haciendo alguna cosa sin demasiada importancia y sin necesidad de atención, mientras lees algunas publicaciones aquí o allí. Y de pronto me he topado con un artículo publicado por Robert O’Callahan, persona bien conocida (en el mundillo) y que sigo desde hace tiempo, con un gran talento como ingeniero de software, y un poco siempre controvertido. Robert O’Callahan ha sido Ingeniero de Mozilla durante muchos años, siendo una pieza fundamental de ellos, un gran programador, experto en seguridad y bueno… creerme, es cierto que siempre ha sido políticamente incorrecto, pero sabe de lo que habla.

El artículo no tenía desperdicio, animo a todos a leerlo: “ Disable Your Antivirus Software (Except Microsoft’s)“. Cuando cualquiera escribe sobre temas que conoce (o cree conocer), sus palabras pueden ser más o menos escuchadas y tenidas en cuenta por un grupo de seguidores o lectores, pero cuando personas de cierto y conocidas por su trabajo hacen comentarios tan tajantes, se arma un revuelo… y no es para menos.

Para quien no quiera leerse el artículo o vaya regular en Ingles, se lo resumo de forma sencilla:

En primer lugar, O’Callahan aprovecha para recordar que al no estar de momento en Mozilla (espero sinceramente que vuelva), tiene “libertad” en poder expresarse de forma abierta ya que a fin de cuenta no representa ni la opinión ni palabras de Mozilla y está desvinculado de ellos. Esto nos dice que muy posiblemente Mozilla piensa igual en general, sólo que como es normal no puede hacer afirmaciones tales por las repercusiones que tiene, como veremos luego.

A continuación, hace un pequeño resumen exponiendo que los Antivirus, lejos de hacer nuestros sistemas más seguros, por lo general lo que logran es hacerlo más inseguros, crearle agujeros de seguridad, son invasivos, matan el rendimiento y generalmente por raro que parezca no cumplen las normativas básicas de seguridad de software, con un código mal optimizado y problemático. Y desde el punto de vista de ellos como desarrolladores de software, específicamente navegadores Webs, afirma también que una parte muy importante del tiempo dedicado por los desarrolladores es precisamente tener que lidiar con los fallos de seguridad y otros de los propios antivirus, por supuesto da ejemplos de ello.

Muchos han visto esto como un guiño a Microsoft, por Windows Defender, pero en lo personal no creo que sea así, y en parte lo explica. La gran diferencia entre Windows Defender (En Windows) y cualquier otro AV como pueda ser Symantec, Avira, Avast… (pongo 3, pero en general cualquiera), es que Defender en primer lugar está integrado en el sistema y mucho más optimizado, en segundo lugar Microsoft por política somete a todo su software a estrictos controles de seguridad y estándares que deben de seguir, cosa que la mayoría de empresas de software no hacen, y en tercer lugar porque para lo que sirve un AV, Defender cumple con lo que necesita cualquiera. Dicho de otro modo… Windows ya tiene su propio AV/AntiMalware que funciona bien, para que usar software de terceros que puede provocar todo tipo de problemas.

Bien… cualquier que me conozca, sabrá lo que pienso al respecto: Estoy totalmente de acuerdo con sus palabras.

Es complicado hacer este tipo de afirmaciones y más para ellos, como bien dice. los desarrolladores de Software tienen que trabajar a fin de cuenta codo con codo con los desarrolladores de AV, y es evidente por qué… creéis que a cualquier desarrollador de software le gustaría que un AV salte una advertencia de seguridad o que hagan un comunicado diciendo que el software de X no es seguro?? Es indiferente si dicha afirmación o dicha alarma es cierta o no, el daño lo hacen, porque son compañías que tienen mucho peso. Yo puedo hacer los comentarios que quiera, puedo dar mi opinión y ninguna empresa de AV puede “influenciarme” de ningún modo, pero la mayoría no puede hacer eso.

Las empresas de AV se aprovechan de la historia y del desconocimiento de los usuarios, intentando venderte no su software, sino la idea de que si no usas un AV, tu equipo está desprotegido, y que el suyo es el mejor. Y esto es falso… al menos de un punto de vista global, y he hablado de ello muchas otras veces. Los AV tienen su utilidad, pero es limitada en el mejor de los casos, y por lo general causan un mal mucho peor que la posibilidad de coger algún tipo de malware. El desconocimiento es tal, que por paradójico que sea, la mayoría deshabilita las actualizaciones de Windows para mantener su equipo en buena forma y seguridad, mientras que usan AV para “protegerlo”, cuando es exactamente al contrario!! Lo más importante para la lucha contra CUALQUIER tipo de malware, es TENER ACTUALIZADO EL SOFTWARE empezando evidentemente por el OS.

Pues han pasado unos días desde que el señor O’Callahan escribiese dicho artículo, y al margen de lo polémico que ha sido muchas veces (que no es sinónimo de no tener razón), esta vez se le ha unido incluso algunos Ingenieros de Google, que aunque han sido algo más suaves, han venido a darle la razón, aludiendo que al margen de las estadísticas y otros que sacan las propias empresas de AV, ellos tienen sus propios datos que muestran que tales afirmaciones son ciertas, y que duela a quien duela, Defender es digamos mucho menos problemático que el resto de los AV.

No es normal que expertos de cierto calibre hagan afirmaciones tales: “Deshabilita/Desinstala tu Antivirus”, pero me alegra que por fin algunas voces se atrevan a decirlo. Como queda dicho, hay demasiados intereses económicos, y luchar contra empresas de importante tamaño te puede pasar factura, sobre todo si tu producto puede verse afectado por el producto de otro.

 

Mi opinión personal es bien conocida para todos mis círculos, y alguna vez la he expresado aquí. Cualquier tipo de Malware es introducido en el equipo o por interacción directa del usuario o por algún agujero de seguridad. Lo primero se evita con una educación mínima de como usar Internet y otros, a fin de cuenta repito entra porque el usuario instala o ejecuta algo que no debía. Lo segundo se evita actualizando el Software, sobre todo cualquier programa de cara a Internet, como navegadores Web, Sistema operativo y otros. Y no, en ninguna de esas dos luchas contra el malware aparece un AV. Sí, en algunos momentos específicos puede ser bueno poder disponer de un AV para analizar un archivo del cual no estamos seguro o dudamos… pero para eso tenemos una herramienta mejor a todo ello:

http://virustotal.com/

Tengo que decir que siempre que tengo que recomendar configurar un equipo, software a instalar… o incluso a amigos/familiares que soy quien se encarga de ello, el AV lo tengo vetado. Por lo general, es cierto que les dejo habilitado Defender, aunque en mi círculo más cercano, también lo tengo deshabilitado. Esto no es una recomendación ni lo deja de ser, porque al final como dice también O’Callahan, si recomiendas algo y alguien termina con problemas por ello, se contará siempre la negativa y no la positiva, sólo digo que a todo en lo que tengo o pueda tener mano, los AV de terceros están totalmente vetados, y en mis círculos más cercanos, todos.

Por supuesto… cada cual es libre de creer, hacer 🙂

Let’s Encrypt

Share on Google+Share on FacebookTweet about this on Twitter

le-logo-wide

Llevo ya un tiempo queriendo escribir algunas palabras sobre esto por dos motivos. El primero, debido a la gran importancia que a día de hoy debería de ser mantener las comunicaciones seguras entre los equipos de los usuarios y los servidores remotos, y en segundo lugar por lo que, desde mi opinión claro está, es la gran labor que han llevado a cabo y están realizando todos los que están detrás del proyecto de “Let’s Encrypt”.

Como es costumbre, vamos a hacer una pequeña introducción para explicar en primer lugar un poquito de todo esto para quienes no sepan de ello, y para los que sepan y aun estén recelosos clarar algunas dudas.

 

¿Que es Let’s Encrypt?

La versión corta y reducida es la que podemos encontrar en su propia web: https://letsencrypt.org/:

“Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open” (Let’s Encyrpt es una nueva Autoridad de Certificación. es gratuito, automatizado y abierto).

Internet no se construyó en su origen para ser seguro, de tal modo que en su versión simplista se trataba de poder enviar información desde un punto a otro. Los años, y más los tiempos que corren, demostraron que eso está muy bien, pero se hacía necesario algún sistema de cifrado punto-a-punto que asegurase dicha comunicación. Los cifrados punto-a-punto se denominan así (ahora de moda con las aplicaciones de mensajería instantánea) porque el contenido se cifra/descifra en los extremos, es decir… se cifra en nuestros dispositivos y circula de ese modo hasta llegar al destino, haciendo que sea, en teoría siempre, poder “leer” dicho tráfico si alguien intercepta la comunicación en cualquier punto de dicha travesía. De este modo tan solo el origen y el destino de dicha comunicación podrían entender lo que están enviando/recibiendo. Esto fue vital para Internet, y así nació HTTPS, que todos estamos hartos de ver.

HTTPS se fundamenta en el uso de los protocolos TLS y SSL, los cuales a su vez su funcionamiento radica en el uso de lo que llamamos certificados digitales para poder crear un entorno de cifrado asimétrico (ya sea RSA, ECC…). Esto ya hablé bastante en su día, así que no voy a repetir el grueso de todo aquello, quien le interese, creo que estaba en el artículo de Seguridad: Encriptación y Autentificación (cap 4). Abreviando mucho, digamos que, al menos, el servidor al cual los usuarios se conectan para iniciar su comunicación de forma segura debe de poseer un certificado digital que será enviado al cliente al iniciar la conexión y que le dará a este toda la información necesaria para realizar esa conexión, como la clave pública que usará el cliente para cifrar la clave simétrica de sesión, los algoritmos a usar para el cifrado… e igualmente importante, los datos necesarios para que el usuario PUEDA VERIFICAR LA CORRECTA IDENTIDAD DEL SERVIDOR AL QUE SE CONECTA, empezando por el CA (Autoridad de Certificación) que emite dicho certificado.

El cifrado es esencial si queremos que nuestras comunicaciones no puedan ser leídas en ningún punto hasta su destino (evidentemente sobre todo cuando estamos transmitiendo información que pueda ser confidencial o importante como usuarios/contraseñas, tarjetas de créditos, datos personales..). Esto no es un problema para TLS/SSL, y a día de hoy si la implementación TLS/SSL es buena y usando las versiones más actuales y otros, el cifrado es, en la práctica, imposible de romper (no vamos a entrar en teoría de computación cuántica, errores de implementación, ataques de tiempo y otros). Pero el cifrado es solo la mitad del problema, porque nada podría impedir igualmente a quien quisiese interceptar la comunicación, suplantar el servidor destino haciendo de “hombre en medio” y mandar su propio certificado al usuario, creyendo este que es legítimo, y por otro lado este atacante se comunicaría hacia el servidor real, y como el es en ambos casos extremo de la comunicación, podría leer perfectamente toda la información cifrada tanto por uno como por otro. Incluso como muestra la siguiente imagen, se podría hacer uso de esto con fines igualmente legítimos: (Nota: La imagen está sacada de otro sitio, no tenía ganas de hacer una similar)

interceptionproxy

Este esquema muestra el problema que indicaba. Un cliente podría querer comunicarse con el servidor remoto www.example.com, pero un tercero que quisiese interceptar la comunicación (aka SSL Interception proxy) podría enviar su propio certificado (emitidio por Corporate CA) al cliente, recibir la comunicación por parte de este, y a su vez conectarse al servidor remoto real, que le enviaría su certificado real (emitido por Real Public CA) para reenviar lo que el cliente le mandase a él. Todo iría cifrado, desde el Cliente al intermediario, y del intermediario al servidor final. Problema?? Que realmente no sería un cifrado punto-a-punto, ya que en medio se habría colocado un tercero que podría estar leyendo absolutamente todo el tráfico que pasase por él.

¿Como se soluciona esto? Aquí es donde radica todo. La solución es que los clientes, cuando usan cualquier aplicación para conectarse a servidores remotos por conexiones seguras TLS/SSL (ya sea un navegador web, un gestor de correos, una aplicación de mensajería instantánea, un juego, un…) posee una “base de datos” propia que puede venir con el sistema operativo o con la propia aplicación, en la que se especifica claramente que Autoridades Certificadoras se aceptan como seguras. Realmente lo que contiene dicha base de datos son los certificados públicos de todos los CA válidos.

Así pues, si nuestro navegador web solo tuviese en su base de datos como CA a la FNMT (por poner un ejemplo), tan sólo los certificados emitidos por el certificado Raiz de la FNMT (o los secundarios que dependan de este si lo tienen permitido), serán validados y dados por bueno por el navegador del usuario, de lo contrario el navegador directamente nos pondrá en aviso, denegando por defecto la conexión. En el ejemplo anterior, el cliente quiere acceder al servidor www.example.com y lo que recibe es un certificado emitido por un tal “Corporate CA)” que dice ser el certificado de www.example.com. Si el cliente posee dicho CA en su base de datos como autoridad válida, no habrá problemas porque el cliente confía en que los certificados emitidos por dicho CA se pude confiar en ellos, y la comunicación se hará sin problemas. PERO!! Si la base de datos del cliente no tiene ninguna constancia del CA en cuestión, o el certificado que posee la base de datos del cliente del CA difiere al que el emite… la conexión muy probablemente no se realizará.

Eso significa que al final, además del cifrado hace falta la cuestión de confianza, que en última instancia viene dada por el CA que emite dicho certificado.

¿¿Que es Let’s Encrypt?? Un CA, ni más ni menos. Actualmente actúa como CA “intermedio”, no posee un certificado Raiz que sea “universalmente” aceptado, y depende de la generosidad en este caso de IdenTrust, que es el certificado Raiz, que a su vez emitió el Certificado CA de Let’s Encrypt que permite a estos emitir certificados. Por poner un ejemplo de si esta práctica es habitual o no, todos los certificados que usa Google usan esta misma política, Google no tiene certificado raiz propio, sino que su certificado CA intermedio está emitido/firmado a su vez por GeoTrust.

Pero hay cientos o miles de CA, ¿cual es su importancia?

 

El principal problema con los certificados digitales

Lo ideal es que el 100% de todas las comunicaciones fuesen cifradas punto a punto, en cambio el uso por servicios/webs es muy bajo en comparación al tráfico sin cifrar. ¿Por qué?

Bueno es simple. Cualquiera puede crear en cuestión de segundos un certificado digital para su empresa, para firmar código, para un servidor web… se tardan segundos, pero dicho certificado sólo será creíble de puertas para fuera si está emitido por un CA de confianza. Así que eso sólo deja dos opciones:

A) Convertirnos nosotros mismos en un CA de confianza y emitir los certificados que queramos.
B) Obtener el certificado que queremos usar de un CA de confianza

La opción A se antoja cuanto menos casi imposible. Llamamos un CA de confianza, básicamente a un CA que es universalmente reconocido por la gran mayoría de todos los desarrolladores, empresas y otros que hacen uso de certificados, evidentemente empezando por las empresas que están detrás de los navegadores Webs, de los Sistemas operativos… Es decir, que si cualquiera quisiera crear una empresa que se dedicase a actuar como CA, además de toda la infraestructura de emisión, revocación… tendría que ir solicitando prácticamente uno a uno la inclusión de su CA en el software/hardware del desarrollador/fabricante que fuese, y estos a su vez aplicarían y obligarían a cumplir con las normas más estrictas de privacidad y seguridad que estimen. Es un proceso muy largo (años perfectamente), y como digo no existe una base de datos oficial universal, sino que cada desarrollador/compañía mantiene aquellos CA que estima.

Como sencillo ejemplo, pongo por caso el problema que tenemos aquí en España con el DNI electrónico o los certificados CERES. Ni la FNMT que lleva muuuuchos años emitiendo certificados (y hablamos de una entidad totalmente seria, respetable y a nivel nacional) ha logrado ser incluido como un CA de confianza. Sólo hace unos días precisamente, han logrado por fin la inclusión en Mozilla, y después de al menos de 2 años de trabajo y ajustes de todo tipo en sus infraestructuras para tener la luz verde de Mozilla. Y eso tan solo se aplica a Mozilla (Firefox, Thunderbird…), porque si la FNMT quiere que Google o Microsoft incluyan su certificado, deben de solicitar su inclusión de forma similar a la que hicieron con Mozilla, y de nuevo someterse a todos los controles de estos. Como actualmente ese CA no está en nuestros navegadores, todos hemos sufrido aquí montones de veces lo que sucedía cuando accedíamos a páginas de las propias instituciones Españolas: Certificado no válido, error de comunicación… por qué?? Porque los certificados que usan son emitidos por CA que no están por así decirlo universalmente aceptos, así que es necesario instalar manualmente los certificados de dichos CA, especificando que dichos CA serán válidos para nosotros.

Actualmente, Let’s Encrypt tiene ya el visto bueno a su vez de la gran Mozilla, lo cual es un inmenso salto, y en conversaciones con Google/MS para sus respectivos navegadores/plataformas/software. Como he dicho actualmente actúa como CA intermedio, ahora busca independencia total, pero eso, aun teniendo ya luz verde por Mozilla, será un camino largo. Aun con todo, para tener en cuenta lo complicado que es esto, ni siquiera aquellos que incluyen tu CA como CA Raíz te dan un cheque en blanco, son necesarias auditorias externas cada X, especificar bien claro el uso que se le va a dar y que limitaciones, que tipo de certificados va a emitir… y aun con todo en cualquier momento, si de detecta cualquier fallo que los desarrolladores/compañías estimen, ni que decir tiene que la supresión del CA Raiz sería inmediata.

Pero es que la importancia es capital. Tener un certificado CA, ya sea Raiz reconocido (cosa muy muy compleja) o tener un CA intermedio firmado por un CA raíz, implica poder, en teoría claro está, emitir los certificados que se quisiesen para la tarea que se quisiese y para los dominios que se quisiese. Es decir… el sueño de cualquier Hacker, ya que con uno en su poder cualquier ataque de interceptación de tráfico por ejemplo, sería extremadamente efectivo y sencillo, y también simplificaría mucho los engaños y sitios fraudulentos. Así que es normal que las grandes no se tomen eso de admitir un CA Raíz así como así.

 

La opción B es la que a día de hoy hace uso el 99% de todos. En realidad tan solo las grandes instituciones, multinacionales o empresas que se dedican precisamente a la emisión de certificados, optan o pueden optar por la opción A, todos los demás lo que hacemos es obtener certificados emitidos por los CA de confianza, o en el caso de grandes empresas en todo caso lograr un CA intermedio (auditado y vigilado) por lo general para emitir sus propios certificados. En principio, cualquiera puede solicitar sin ningún tipo de problema un certificado a un CA para el uso que estime, ya sea un servidor Web, firmar código o lo que sea. Aquí nos vamos a centrar a servidores Web por ser además el uso mayoritario. La pregunta entonces se derivaría, una vez descartada la opción A, en cual es el motivo entonces, si virtualmente cualquiera puede solicitar un certificado a un CA de confianza: Dinero, el más viejo y conocido de todos, el señor billete, Cash, Money.

 

Tipos de Certificados (para Servidores Web)

A día de hoy existen básicamente 3 tipos de certificados para servidores Web, que se diferencia en función de la información que el cliente quiere por así decirlo validar ante el CA. Como al final todo es una cuestión de confianza, cuanta más información te valide el CA sobre tu persona/empresa, más fiabilidad dará dicha persona/empresa de cara a todo el mundo:

 

-Certificados de Validación de Dominio (DV):

Actualmente más del 60% de todos los certificados que podemos encontrar en la web corresponden a este tipo. El CA que lo emite sólo valida/garantiza que es emitido para el dominio en cuestión, sin aportar absolutamente ninguna otra información identificativa de dicho dominio. Es decir, por lo general basta ser tan solo el dueño o el administrador de un dominio para poder cumplir con los requerimientos que pueda exigir un CA en la emisión de un certificado de este tipo. Ojo!! Eso no significa que estos certificados sean malos, ni mucho menos, aunque se ha hecho muy mala prensa de ellos, pero por cuestiones principalmente de marketing indigno por parte precisamente de los propios CA para que los clientes adquieran certificados que veremos a continuación… que son mucho más caros.

Si visitamos una web, cualesquiera, accedemos por HTTPS y el certificado está validado por un CA de confianza, aun siendo de tipo DV podemos tener la certeza de que el certificado es de quien dice ser. Si un atacante intentase replicar dicho certificado e intentase usar el dominio original, tendría que poder controlar y tener acceso a la configuración del propio dominio para poder lograr un certificado emitido por un CA de confianza, de lo contrario aunque su certificado dijese que es para la web en cuestión, dicho certificado sería rechazado por los navegadores, aplicaciones… del cliente. Esto es importante, porque precisamente hace relativamente poco se culpaba a este tipo de certificados a que se había logrado realizar un ataque a gran escala, pero de nuevo el artículo era sesgado y creado por un CA de prestigio para desprestigiar a otros, si un atacante logra hacerse con el control total de un dominio, da igual al CA de confianza que acuda para la emisión de un certificado DV, porque se lo darán sin problema.

Los certificados DV, a efectos visuales, estamos hartos de verlos en los navegadores web: Candadito Verde, sin más.

certificado DVPor supuesto, siempre suponiendo que son emitidos por un CA válido, de lo contrario tendríamos advertencias de seguridad, candadito rojo o cualquier otro identificativo.

Certificado Info DV

-Certificados de Validación de Organización (OV):

Son el segundo grupo de certificados más usados en la actualidad, y en realidad muy similares a los DV. El CA en este caso emite los certificados no solo validando por los medios oportunos el dominio, sino que además solicita información adicional de la organización/empresa que hay detrás de dicha solicitud, lo que hace necesaria la aportación como es lógico de documentación legal y otros, necesario para que el CA pueda verificar la autenticidad de dicha empresa/organización.

No obstante a efectos visuales para el usuario son prácticamente iguales a los DV, y sería necesario mirar el Certificado directamente para ver la diferencia, que radica en que este tipo de certificados incluye en su variable O (Organization) precisamente la compañia a la que pertenece. En las dos pantallas que puesto anteriormente, no se podría saber si el certificado que he puesto es un DV o un OV, ambos tendrían el mismo aspecto.

Un ejemplo sencillo de certificado OV es el de Google: https://google.es. Pero sería necesario acceder al certificado en cuestión para ver que efectivamente está verificada la organización:

Certificado OV

Si nos fiajos en la pantalla de la derecha, Google Inc. está incluido dentro de la variable O del certificado, aunque sólo es visible si accedemos al visionado directo del certificado. En este caso particular vemos si miramos un poco mas abajo información del propio emisor (CA) del certificado, y básicamente se repite porque Google a su vez es un CA universalmente reconocido, con lo que evidentemente emite sus propios certificados. Cabe indicar que Google no es en sí un CA raiz, OJO!! A su vez depende del certificado Raiz de GeoTrust, aunque Google puede emitir sus propios certificados. Pero la parte que nos atañe aquí es el primer bloque.

 

-Certificados de Validación Extendida (EV):

Son como es natural los más caros, e igualmente los que en teoría ofrecen el mayor grado de confianza para los usuarios. En este caso el CA deberá de verificar mucha más información relevante sobre la propia compañía, siendo el proceso de verificación mucho más lento y profundo. La finalidad es clara, que el usuario final tenga la plena y total seguridad de que la web a la que está accediendo es 100% confiable. Aun con todo al final siempre es todo muy relativo, porque en cuanto a seguridad se refiere podría dar la misma seguridad un certificado tipo DV y OV. Si los certificados EV se crearon exclusivamente por cuestiones de marketing y como excusa de embolsar más dinero para los CA, lo dejo en manos de los lectores. En lo personal, aunque por supuesto estoy totalmente de acuerdo a que la fiabilidad que pueda otorgar un certificado EV es como es natural mayor a un certificado DV, eso no implica que un certificado DV no me de confianza alguna.

Está claro que un hacker, aun logrando acceso y control al dominio le sería virtualmente imposible o cuasi imposible lograr que emitiesen para el otro certificado EV para un subdominio de dicho dominio o cualquier cosa similar, o intentar crear una web con nombre similar e intentar que la organización y otra información pusiese en el certificado que es otra que se quiere suplantar. Eso es evidente, cuantos más controles sometan los CA a los clientes para emitir el certificado, este será más  confiable, pero lo siento… no soy de esos que aconseja por ello que cualquier tienda tenga que tener por obligación un certificado EV, como si hacen la mayoría de todos los CA (teniendo en cuenta que el precio es mucho mucho mayor)

En este caso, los certificados EV no obstante si son tratados de un modo más… especial por los navegadores Webs. Son muchas menos web en los que los hemos visto, pero no son extraños a día de hoy encontrar algunas webs sobre todo que los usan (curiosamente, muchas de ellas son empresas que actúan también como CA). Uno de los ejemplos más “estrella” de ello, es la archiconocida PayPal, que desde luego pocos sitios han sufrido más intentos de phising y SCAN. Podemos saber perfectamente si es un certificado EV porque la propia barra del navegador web cambia para mostrar una barra adicional verde que incluye directamente la información de la propia compañía:

Certificado EV

Esa “barra verde” que hace acopio en este caso Firefox automáticamente nos dice que estamos ante un certificado EV, y ni siquiera hace falta acceder a la información del propio certificado para ver que directamente nos da la información en el propio Firefox sin ir mas profundamente, mostrando la compañía e incluso la dirección de esta.

Muchos se preguntarán que por qué Google u otros grandes como Facebook no usan este tipo de certificados. Bien, oficialmente no existe una respuesta ante esto por sus partes, pero desde mi punto de vista es obvio, y viene a colación de lo dicho anteriormente. Los certificados EV, pese a mostrar más información directamente en los navegadores y que los CA necesiten más datos para emitirlos, no aportan por sí mismos nada más, no dan más seguridad ni más nada, sino que son un reclamo al público para decir: “Ei, mira, uso un certificado EV, tienes que fiarte de mi”. O por ejemplo: “Ei, ves?? Soy el mas guay y el mejor porque uso el certificado EV”. Google tiene nombre propio y en mayúsculas, su propia marca es él mismo y no hay persona que tenga un PC que no conozca quienes son. Evidentemente para ellos no es cuestión de dinero.

Como dije antes y lo reitero, que cada cual saque sus propias conclusiones sobre la necesidad, o no, de que los sitios como tiendas de comercio electrónico y otros requieran un EV, o les sea más que suficiente con un OV. No tiene nada que ver con la seguridad/cifrado, es sobre todo una cuestión de marketing, tanto para los CA que los venden, como para aquellos que quieren parecer mejores por tenerlos. No estoy en contra de los certificados EV, son importantes en muchos casos, pero la gran mayoría están movidos o por el propio marketing que quieren hacer ellos mismos para con el público, o por desconocimiento de quien los adquieren. Como siempre… es mi opinión.

 

 Let’s Encrypt

Bueno, y ¿qué tiene que ver todo esto con Let’s Encrypt?. Básicamente, que Le’ts Encrypt ha sido la primera iniciativa real y usable de que prácticamente cualquiera que tenga un dominio/hosting mínimamente decente, poder adquirir un certificado válido emitido por un CA de confianza (en este caso Let’s Encrypt, aunque de momento actúa por encima de ellos el certificado Raiz de IdentTrust), sin siquiera invertir un solo euro, y de manera además totalmente transparente, es decir… toda infraestructura que usan es de código abierto y puede verificarse, cumpliendo con todos los requisitos de seguridad que puedan cumplir igualmente cualquier otro CA. Eso sí, OJO, Let’s Encrypt SOLO EMITE CERTIFICADOS DV.

Para poner todo esto un poco desde cierta perspectiva. Tomemos los precios por ejemplo de un CA conocido como pueda ser Godaddy (iba a coger Symantec pero los preciso son mucho mayores.). Evidentemente estos datos no son extrapolables a otros CA, cada uno tiene sus propios precios, tomo los de Godaddy por ser relativamente conocidos y porque sus tablas de precios son muy claras. Sus precios anuales (redondeados) para un solo dominio sin incluir subdominios son los siguientes:

-Certificado DV: 85€
-Certificado OV: 110€
-Certificado EV: 227€

A nadie se le escapa que si quisiésemos por ejemplo un certificado que cubriese también todos los subdominios la gracia se nos iría a 330€ en el caso de los DV (siempre tomando de ejemplo los precios de Godaddy. Sí, prácticamente todos los CA que “venden” certificados garantizan con un seguro el certificado, pero no dejan de ser precios importantes a desembolsar de manera anual. No estoy en contra para nada de este tipo de certificados, no estoy endemoniando a Godaddy, Symantec, Comodo… para nada, ojo, son empresas en su mayoría muy profesionales y con grandes servicios, solo quiero poner en perspectiva todo el asunto que nos trae.

¿Que sucede? Pues que evidentemente una empresa no tiene problema en gastarse en sus presupuestos uno dos o los certificados que necesite, sean DV o incluso si se quieren dar la fardada y la presuntuosidad EV. ¿Pero que pasa con las Pymes?? ¿Que pasa con bloggers, autónomos y básicamente el gran grueso de la población? Que costearse incluso un certificado DV puede ser costoso para el poco uso que creen poder darle, y eso acompañado al desconocimiento es lo que hace que a día de hoy má del 60% de todas las web no soporten HTTPS. Y el problema por supuesto se multiplica si lo que se requieren son certificados wildcard/multiples subdominios o múltiples dominios.

Let’s Encrypt por otro lado, como digo, ha hecho posible que prácticamente cualquiera tenga acceso a certificados DV, sin importar el número de subdominios que se requieran o el número de certificados a necesitar por poseer múltiples dominios. Se ha criticado que el proceso sea relativamente automático, pero no nos engañemos… todos los CA usan procedimientos igualmente automatizados para ello (certificados DV), pero de nuevo es normal, a fin de cuenta una organización sin ánimo de lucro alguno está ofreciéndote los certificados DV que quieras a tus dominios y subdominios.

Por supuesto, no es oro todo lo que reluce, y Let’s Encrypt (a partir de ahora LE) puede no ser la mejor opción para todos. Vamos a ver que puntos son o deberían de ser de gran interés para el usuario:

-LE sólo emite certificados DV
-LE sólo emite certificados de 3 meses de vigencia (es lo habitual por otro lado, pero eso obliga a automatizar el proceso de renovación/instalación)
-LE requiere que tengamos como es normal acceso y control sobre el dominio, y si queremos que sea sencillo acceso root en el hosting en cuestión, de lo contrario el proceso puede ser más complicado.
-Muchas compañías de Hosting NO PERMITEN este tipo de certificados por cuestiones obvias, ellos mismos los venden. Aunque cualquier servicio de hosting en el que tengamos acceso al propio servidor como Root no debería de ser problema. Por suerte, y dada la gran aceptación que ha tenido muchas empresas de hosting de siempre están viéndose obligadas a permitir de forma “sencilla” su uso y su automatización completa.
-LE requiere que se tenga por lo general un conocimiento mínimo de que estamos haciendo, de que es un certificado digital y de como usarlo.

 

No obstante tampoco es tan malo como lo pitan algunos:

-LE permite emitir usar tanto certificados RSA como ECC (certificados mas pequeños, y más seguros)
-LE instalado correctamente permite automatizar todo el proceso de forma sencilla, con lo que la renovación no es un problema
-LE Es totalmente gratuito
-LE actualmente usa actualmente un certificado Raiz que generosamente les emitió un certificado intermedio para poder hacer funcionar la cosa, actualmente YA TIENEN el certificado propio CA Raiz aceptado por Mozilla (un gran paso), con lo que a medio-largo plazo serán incluso un CA de confianza de todo derecho.
-La gran aceptación ha “obligado” a grandes como Godaddy, OVH, WordPress… permitir su uso o directamente o indirectamente. Otros por desgracia como 1and1 y algunos otros, de momento al menos, no tienen intención. Siempre como digo en alojamientos web “estándares”, ya que cualquier servicio de hospedaje “completo” tipo servidores virtuales o dedicados, deberían de poder usarlos sin problema alguno.

 

Instalación/Uso

Esto me temo que depende enormemente de donde y como se quiera realizar. En su versión más simplista, suponiendo un control completo del propio servidor. Lo más simples es el propio “cliente” que aconseja Le, llamado Certbot, que tienen instrucciones sencillas para su instalación prácticamente en cualquier distribución linux y servidor Web que se use. Teniendo en cuenta la gran variedad, es obvio que no voy a explicar como donde y cuando.

No obstante, y con la idea en mente que pueda ser usado en la mayor cantidad de sitios posibles, se han creado diferentes clientes muy dispares que aprovechan las diferentes opciones de verificación de dominios que obliga, como es natural, LE para la expedición de los certificados. Así por ejemplo, CertBot requiere que se posean permisos de administrador, mientras que las herramienta acme.sh (hay otras) que podemos encontrar AQUI permite su instalación y uso sin necesidad de Root, aunque pueda ser necesario como es natural instalar uno mismo los certificados donde correspondan

Así tenemos muchos hospedajes Web “baratos” en el mercado que no permite root en sus servidores pero si especificar los certificados TLS. Gracias a herramientas como Acme.sh se pueden ejecutar por SSH en los servidores, lograr que LE nos expida los certificados y posteriormente instalarlos en los paneles de control que nos permita el proveedor. Quizás no es en este caso 100% automatizado, pero si hace que sea viable su uso, que a fin de cuenta es lo que importa. A medida que más proveedores se usan, más sencillo será tanto para administradores como para los propios chicos de LE automatizar las expediciones e instalaciones, y no dudarlo, mejorar con creces la seguridad global dentro de Internet.

 

Conclusión

Al final la idea es la misma: Que aquellos administradores o pequeñas/grandes empresas donde no se han usado certificados para asegurar el tráfico por HTTP por motivos económicos o por infraestructuras, les sea rentable y lo más sencillo posible. Esto no quiere decir que los certificados de cualquier otro CA tengan menos valor, repito. LE no es para todos, y lo comprendo. Pero eso no quita que alabe la gran idea y el gran trabajo que están realizando, y que sirva igualmente de tirón de orejas al resto de CA que hasta ahora han podido imponer un poco los precios que han querido, a fin de cuenta quien se iba a meter en emitir certificados desde un CA reconocible de forma gratuita.

Recomiendo a cualquiera que tenga dominio/hospedaje propio al menos informarse un poco al respecto, merece la pena, y que se plantee realmente si es viable o no su uso en cada caso. En lo personal lo tengo claro… quitando casos concretos, todos los dominios y otros que pueda gestionar irán poco a poco usando certificados de LE, siempre que crea que es necesario claro, gran prueba es que este mismo blog no solo no va sobre HTTP plano sino que no tiene opción (actualmente). Forzar HTTPS en cualquier sitio que pueda enviar información confidencial de ida o vuelta es mandatorio, al menos desde mi punto de vista, y más aun cuando hay datos sensibles. Un DV suele ser más que suficiente para la gran mayoría de casos, así que no hay motivo para no tomar LE muy muy enserio como opción.

Y sí, aunque theliel.es aun no está “asegurado”, ya empecé hace unas semanas con la implementación de LE en todos los dominios que están bajo mi control, que no son pocos, aunque eso no quiera decir que fuerce las conexiones HTTPS por defecto en todo momento. A fin de cuenta los procesos es mejor hacerlos poco a poco…

Desde aquí, aunque posiblemente no me lean, sólo dar la enhorabuena al trabajo que están realizando, creo sinceramente que es de esas iniciativas que sí cambian las cosas.

eMail: SPF+DKIM = DMARC

Share on Google+Share on FacebookTweet about this on Twitter

Una pequeña reflexión antes de empezar

No sé como evolucionará la tecnología en el modo que nos relacionaremos unos con otros digitalmente dentro de unos años, pero me gustaría pensar que el eMail seguirá teniendo ese papel imprescindible. No son pocos los que año tras años auguran su muerte en pos de la mensajería instantánea. Es cierto que para la mayoría de adolescentes y jóvenes, el uso que puedan darle al correo electrónico es anecdótico, y generalmente para realizar reservas, compras y otros. Llamadme nostálgico o de la vieja escuela, pero pese a las virtudes que nos brinda la mensajería instantánea (la cual por supuesto uso de forma constante), lo único que supera a un buen correo electrónico cargado de contenido es una carta matasellada. Por supuesto no entramos en el mundo laboral/escolar/empresarial, donde a día de hoy el eMail sigue siendo completamente indiscutible.

Dicho esto, recordemos que el eMail no es algo nuevo, que data al menos desde 1970!! y poco cambiado desde entonces. Eso son casi 50 años, y evidentemente desde entonces todo ha cambiado.

 

Como funciona a groso modo el eMail

Como siempre, antes de entrar en materia “pesada”, para los que aun andan un poco despistados, un pequeño resumen rápido de como funciona el eMail, importantísimo para comprender la importancia de tecnologías como SPF, DKIM o DMARK.

El eMail, pese a que pueda parecer algo complejo es un sistema de mensajería tremendamente sencillo, se basa posiblemente en unos de los protocolos más simples que podemos encontrar a día de hoy como puede serlo SMTP. Otra cuestión que la mayoría desconoce es que pese a que tenemos proveedores de eMail a lo largo y ancho de todo el mundo, en realidad cualquiera puede enviar un eMail sin tener siquiera una cuenta propia, y que incluso podría crearse una sin demasiada complicación. Esto es así porque el eMail se creó como modo de comunicación sencilla, sin mirar cuestiones de seguridad o las posibilidades en la suplantación de identidad o…

La Wikipedia nos deja una imagen que ilustra bastante bien el funcionamiento del eMail:

correo

Un usuario envía un texto correctamente formateado a un servidor SMTP para que realice el envío (1), indicando entre otras cosas quien lo manda y a quien se lo mandamos. Este servidor SMTP lo primero que hace es consultar el destino de dicho correo, para lo cual lee el realm de la dirección de destino, es decir, el dominio al cual se envía, la parte derecha de la dirección, y realiza una consulta DNS al registro MX de dicho dominio, pues dicho registro se usa precisamente para ello, para conocer donde se encuentra el servidor de Correos de dicho dominio (2). El servidor DNS de dicho dominio devuelve la dirección de su servidor de correos (3) al servidor SMTP. Este al conocer ya el servidor al que debe de enviarlo, conecta directamente con el y entrega el correo en dicho servidor (4). Dicho servidor debería de reconocer la dirección de correo a la que está destinado, así que lo colocaría en su bandeja, a la espera de que el destino lo reclamase por medio de POP/IMAP (5).

Esta otra imagen muestra lo que sería un esquema más real de todo ello, más completo (no tenía muchas ganas de crear un esquema propio, así que espero que no se moleste oasis-open.org)

howemailworks

El usuario envía un correo a través del MUA (el cliente email que use) y posiblemente a través de SMTP a su MTA/MDA (Mail Transfer/Delivery Agent). Aquí se almacenará posiblemente en su bandeja de enviados, y como dijimos anteriormente se resuelve la dirección de destino y se procede a su envío, conectando al MTA de destino y entregando el mensaje allí. El MTA de destino lo manda ya por su red al buzon correspondiente y el destino lo recoge de ahí.

No obstante, este funcionamiento tan sencillo deja la puerta abierta a muchas preguntas concernientes a la seguridad de los propios correos electrónicos. Algunas cuestiones de gran importancia:

-Los correos no se mandan cifrados? No, por defecto el correo es un texto plano, si se quisiese cifrar se debería de realizar de un modo punto a punto, con tecnologías como PGP o similar, que a día de hoy siguen sin ser usadas de forma global por la complicación que implica el “compartir” las claves públicas. Lo mismo sucede si mandamos un archivo protegido por contraseña la otro extremo, tendríamos que mandarle la contraseña para poder ver dicho archivo. Eso significa que quien accediese tanto a nuestra bandeja de entrada como la de salida podría ver siempre el contenido de los correos.

-La comunicación se realiza de forma segura?? En su modo más simple no, al ser un texto plano, en cualquier punto se podría escuchar la comunicación y con ello el mensaje. La mayoría de servidores SMTP a día de hoy permiten realizar las conexiones por medio de TLS/SSL, pero… resuelve esto completamente el problema?? Tampoco, el mensaje podría llegar de forma segura al MTA, pero para que TODA la comunicación fuese segura, el MTA debería de mover el correo por su propia red de forma segura también, y transmitirlo al MTA destino de forma segura (que no todos los MTA origen/destino permiten), y el MTA destino por su parte volver a moverlo en su red interna de forma segura, y por último el destinatario recibirlo en su MUA por medio de POP/IMAP usando TLS/SSL. Por lo general el único dato que ve el usuario es si se conecta al servidor SMTP de forma segura o no, pero nada más, y eso es sólo el primer salto.

Pero quizás, el principal problema que se abre en el eMail, es la capacidad de poder crear un eMail desde el remitente que se quiera y poder enviarlo al destinatario que se quiera, es decir, la posibilidad de suplantar la identidad del remitente. Uno podría pensar que para que eso fuese posible se tendría que poder hackear/acceder a la cuenta de un usuario para poder enviarlo desde su cuenta, pero nada mas lejos. Sí, necesitaríamos acceder a la cuenta de un usuario para poder enviar un correo desde dicha cuenta DESDE EL MTA DE SU PROVEEDOR, pero… y si nos saltamos los pasos 1, 2 y 3 de la primera imagen?? Podemos consultar directamente el servidor de correo de cualquier dominio, es algo público, y podemos conectarnos a él directamente para dejar en su bandeja de entrada el correo que queramos, usando de remitente lo que nos de la gana. Y sí, es así de sencillo, tal y como suena. No hace falta decir la importancia de esto, de poder suplantar la identidad de un correo… es decir, poder mandar un correo a quien queramos haciéndonos pasar por cualquier otro..

Debido precisamente a esto, empezó una larga guerra contra el SPAM y el fraude, y se empezaron a crear mecanismos para combatir esto, lo que al final nos llevará a DMARC. Sí, es importante que la comunicación sea segura, pero cuando tenemos encima de la mesa la posibilidad de poder engañar a quien queramos, todo se centró en ello. Recordemos que hace ya tiempo escribí un artículo precisamente hablando de todo esto, de la suplantación del eMail que podemos ver AQUI. Así que hoy veremos precisamente lo contrario, como evitarlo en la medida de lo posible. Para ello vamos a ver las “armas” más habituales de las que disponemos:

  • “Filtro” IP del origen: Listas negras/grises/blancas
  • SPF
  • DKIM
  • DMARC

Antes de seguir, todo lo que veremos a continuación es interesante sobre todo desde el punto de vista de proveedores de correo de nuestros propios dominios. Es aplicable igualmente a los proveedores “públicos” como Gmail, Hotmail… pero estos sistemas son configurados y gestionados por ellos, con lo que usen o no SPF, DKIM, DMARC… no podremos hacer nada, no es algo que podamos habilitar o deshabilitar. Eso sí, recomiendo en este caso usar proveedores que realmente se tomen la seguridad en serio y apliquen los máximos estándares de seguridad.

 

Listas Negras/Blancas/Grises en función del Origen de la IP

Estas listas se llevan usando desde hace ya muchísimos años, y prácticamente todos los proveedores conocidos las usan de un modo u otro. No obstante, aun existen muchos correos empresariales o “domésticos” que carecen de ellas, y aun así, su utilidad como veremos es relativa.

La idea es muy simple… si en teoría cualquiera puede conectarse al MTA de cualquier dominio, vamos a configurar esos MTA para que sólo acepten conexiones desde IPs que ellos consideran legítimas. El problema es que Internet es dinámico, y que no puedes crear una lista blanca rigurosa, porque a fin de cuentas Internet también es “abierto” y cualquiera podría legítimamente querer enviar un correo desde su propio servidor a otra dirección. Así que estas listas se sostienen un poco siempre por pelos, aplicando reglas muy generalistas.

Por ejemplo, casi siempre se impide el entregar un mensaje a cualquier IP que en una de sus listas esté identificada como “dinámica”, pues se supone que si es una IP dinámica debe de ser un usuario malicioso desde su conexión el que quiere entregar el mensaje, y no un MTA legítimo. Otra norma habitual es meter en listas blancas los MTA mas conocidos de los proveedores de correo para asegurarse que estos no se filtren nunca, o meter en lista negra aquellas IPs o rangos IPs que se conocen que proceden de servidores con una fama bastante importante en el uso de SPAM y otros.

Pero como digo estas listas son de todo menos fiables, tal es el caso que por lo general puedes acceder a las web donde las gestionan para indicar falsos positivos, o registrar tu propia IP en caso de ser legítima, o que un rango que antes era sospechoso ahora es válido, o al contrario… Además estas listas no evitan el uso de conexiones Proxy desde otros lugares, es decir, un atacante podría estar realizando la conexión usando un tunel o un proxy o cualquier otra técnica desde servidores o redes que no estén filtradas, y creerme… no suele ser nada complicado encontrar una red o host que puda evadir estas listas.

Un ejemplo de estas listas son las que proporciona Spamhaus, pero hay muchas otras. Estas se implementan a nivel del MTA, comprueba la IP de la conexión que se está realizando y la cruza. Si esa IP intenta entregar un mensaje en dicho MTA y está en una de sus listas negras, denegará directamente la entrega. El mensaje no es que termine en SPAM, es que no atravesará siquiera el MTA de destino. Es un modo muy eficaz de filtrar, pero por desgracia no es muy efectivo cuando uno sabe bien lo que está haciendo. .

Además, este sistema tiene otro problema añadido… un usuario podría estar usando un proveedor de correo legítimo, y usar una conexión SMTP a su proveedor para colocar el mensaje en otro MTA modificando el remitente del correo. Este tipo de correos pasarían completamente este filtrado basado en listas, ya que la IP de origen sería la del MTA legítimo.

 

SPF

LLegamos a la primera gran parte de este artículo.

Pese a que la mayoría ni siquiera sabrá que existe, gracias a SPF me atrevería a decir que más del 80% de los correos SPAM y fraudulentos, acaban precisamente en las bandejas de SPAM, y no penetran a nuestras bandejas de entrada. Se creó como sistema de defensa ante precisamente los intentos de suplantación de correos. Por supuesto tiene sus puntos débiles y SPF no nos protege de todo, pero respecto a aquello para lo que fue diseñado, desempeña su papel muy bien.

Al contrario de como sucedía en el sistema de listas, SPF requiere de cierta configuración/preparación no sólo por parte del MTA de destino, que debe como es natural ser compatible con esta tecnología y poder tomar decisiones en función de SPF, sino que además el dominio del remitente del eMail debe de estar configurado y preparado para ello. Es necesario así un trabajo conjunto de las dos partes. El resultado en cambio es sorprendente. Aquí no se protege realmente a las cuentas de destino propiamente dicho, sino lo que se intenta es que a las cuentas de los destinatarios no lleguen correos que suplantan la identidad de otros dominios, con lo que realmente se está protegiendo a los dominios que quieren usar para suplantar.

Con las listas teníamos el problema de no saber nunca bien si la IP de quien enviaba el correo era legítima o no… SPF viene a solucionar este problema de raíz. Básicamente de lo que se trata es de configurar el servidor DNS del dominio de origen de los correos para indicar precisamente desde que direcciones IP/dominios se permiten enviar dichos correos. Esto puede sonar un poco lioso, pero es muy simple, veamos un ejemplo sencillo:

Sin SPF:

Digamos que Pedro, cuya dirección de correo es pedro@pedrito.com, usa Paypal para realizar compras, algo muy habitual a día de hoy. Bien, pues un atacante quiere intentar engañar a Pedro, y para ello quiere enviar un correo a Pedro haciéndose pasar por Paypal. Es muy facil, saca la dirección del MTA de pedrito.com con una consulta a su registro MX, y se conecta directamente al MTA para redactar su mensaje, y escribe lo siguiente:

mail from: Servicios Paypal <servicio@paypal.es>
rcpt to: Pedro <pedro@pedrito.com>
data

from: Servicios Paypal <servicio@paypal.es>
to: Pedro <pedro@pedrito.com>
subject: Verificación de contraseña

Por favor verifique su contraseña en el siguiente enlace, bla bla bla
.

Aun cuando el MTA de Pedro usase listas, si el atacante es listo habrá sabido como evitarlas, así que a todos los efectos el correo parece legítimo, a fin de cuentas cuando Paypal manda un correo legítimo a Pedro puede ser de echo exactamente igual. El correo podría entrar en la bandeja de entrada perfectamente, y Pedro hacer caso de lo que dice el correo, a fin de cuenta el remitente está claro que es Paypal.

Con SPF:

Supongamos el mismo caso, pero en esta ocasión el dominio paypal.es tiene configurado SPF. Evidentemente es igualmente importante que el MTA de Pedro sea compatible con SPF. Bien, Paypal que sabe la importancia y lo que le interesa de que nadie suplante sus correos, hace una pequeña modificación en su servidor DNS, y establece que sólo las IPs 100.100.100.0/24 (por poner un ejemplo) tienen autorización para mandar mensajes.

El atacante escribiría lo mismo y enviaría el mensaje, y se frotaría las manos pensando que lo ha triunfado. No obstante una vez enviado, el MTA que usa SPF, realiza la rutina pertinente. Lee el realm del remitente y anota la IP de este, en este caso paypal.es y pongamos que la IP del atacante fuese 1.1.1.1. Conecta a su servidor DNS (al de paypal.es) y busca a ver si existe un registro TXT que identifique como un registro SPF. Lo encuentra, y obtiene que sólo el rango IP 100.100.100.0/24 tiene autoridad para enviar correos con ese dominio. El MTA compara las dos IPs, ve que la IP del atacante no está dentro de las que el servidor DNS le ha dicho. Paypal indicaba una política estricta SPF (aparece en el mismo registro DNS), así que como no se cumple el criterio establecido, el MTA manda sin pensarlo el correo a la bandeja de SPAM de Pedro, y marca el mensaje con un FAIL en SPF.

 

Gracias a SPF los administradores de los dominios pueden garantizar, hasta cierto punto, que los correos que dicen ser de ellos, sean realmente de ellos, y que de lo contrario sean tratados como SPAM, o sometidos a un escrutinio mayor. La ventaja de SPF es que requiere de muy poco para cualquier dominio implementarlo, no requiere una configuración especial en su MTA, sólo requiere el poder añadir un registro TXT en su servidor DNS. La otra mitad será tarea del MTA de destino, que por cierto a día de hoy la inmensa mayoría usan

Como se hace?? Los registros DNS SPF son sencillos. Lo que necesitamos es crear un registro TXT con el siguiente formato:

"v=spf1 [IP/Dominios permitidos] [Politica a aplicar si no está en permitidos]"

Por ejemplo, si el correo de nuestro dominio está gestionado por Google Apps y queremos añadir como protección SPF, tendremos que crear un registro SPF que permita el envío de los correos por los servidores de Google Apps. Google nos dice que ellos aúnan todos sus rangos bajo el dominio _spf.google.com, así que si añadimos dicho dominio a nuestro registro SPF, realmente estaríamos añadiendo todos los rangos IP que existiesen en el registro SPF de dicho dominio. Pero esto sólo no sirve, con eso tendremos las direcciones que están permitidas, así que hay que decidir que se quiere hacer con aquellas que no cumplen dicho criterio

“v=spf1 include:_spf.google.com ip4:100.100.100.0/24 ~all”

“include:_spf.google.com” indica a otros MTA que reciban un correo de su dominio, que lo acepten si el origen de él está dentro de los registros SPF de _spf.google.com

“ip4:100.100.100.0/24” a lo anterior, se suma a aquellos correos cuyo origen se encuentre entro de ese rango IP

“~all” indica al MTA de destino que hacer con esos correos que lleguen de parte de su dominio en caso de no coincidir con alguna IP anterior. En este caso la tilde expresa un softfail, un fallo, pero no “radical”, a modo que el MTA destino lo tenga en cuenta a la hora de decidir si lo manda a SPAM o no. Si se usase un signo menos, sería un FAIL estricto. Por lo general suele ser más seguro un softfail, por si las políticas del MTA de destino son muy estrictas y eliminan directamente el correo, a fin de cuenta el administrador del dominio de origen podría a ver olvidado alguna IP o malconfigurado el registro SPF. También se podría usar el signo + para identificar un PASS o un ? para indicar un “Neutral”.

El MTA, en función de la política indicada por el dominio marcará dicho correo como Pass, Neutral, Softfail, Fail… y en función de dicho “marcado” actuará de un modo u otro, ya sea entregando el correo en la bandeja de entrada por creerlo legítimo, marcarlo como SPAM, simplemente ignorar SPF y usar otros modos AntiSPAM…

La mayoría de proveedores de correo usan SPF para aplicar diferentes políticas de SPAM. Por lo general cualquiera puede comprobar esto, sólo tiene que mirar la cabecera de cualquier correo que le llega. Tomemos por ejemplo uno de Paypal, y encontramos lo siguiente en su cabecera:

Received-SPF: pass (google.com: domain of servicio@paypal.es designates 173.0.84.226 as permitted sender) client-ip=173.0.84.226;

Es decir, Google ha marcado como Pass dicho correo, puesto que la IP del emisor, 173.0.84.226, dice estar dentro de las permitidas por el dominio origen, Paypal.es. Si mirásemos el registro TXT de Paypal, nos encontraríamos con un registro SPF donde se encontraría incluida dicha IP. Es decir, dicho correo ha sido enviado por un equipo que tiene permitido enviar correos en nombre de paypal.es, Google lo reconoce y lo trata como un correo legítimo.

SPF funciona francamente bien, no obstante no soluciona algunos otros problemas. Por ejemplo SPF no puede garantizar la integridad del mensaje, y basa “solo” su legitimidad en el origen de la IP, que como siempre puede ser relativo. Con esto en mente nació DKIM

 

DKIM

DKIM no viene a sustituir SPF, sino más bien a complementarlo, aplicando una capa de seguridad diferente. DKIM lo que realiza es básicamente un firmado digital del correo que se envía, de modo que el MTA de destino puede verificar su autenticidad leyendo la firma DKIM incluida en la cabecera del correo. Además, no solo puede verificar el dominio emisor, sino también si el mensaje ha sido modificado en lo más mínimo, ya que aunque se modificase una sola coma, la firma se invalidaría, con lo que también garantiza su integridad.

DKIM hace uso de infraestructura de clave pública (cifrado simétrico) para realizar el firmado. Debido a esto, por desgracia, no sólo nos vale con añadir una entrada en el servidor DNS, como hacíamos con SPF, sino que nuestro MTA debe de permitir DKIM, puesto que deberá de firmar todos los correos que enviemos con él. Si nuestro MTA no permite DKIM no podremos hacer uso de esta tecnología.

Como cualquier infraestructura de clave pública, para que funcione el sistema se requiere de una clave publica y una privada. En este caso nuestro MTA generará ambas, guardará de forma segura la clave privada y nos dará a nosotros la clave pública para que la pongamos en el servidor DNS a modo de registro TXT. La idea es simple… el MTA firmará con la clave privada todos los mensajes que enviemos, de tal forma que tan solo la clave pública asociada a nuestra clave privada podrá verificar la firma. Esto requiere que los MTA de destino puedan tener acceso a nuestra clave pública, así que esta es “publicada” en nuestro servidor DNS, a modo similar que se hacía con SPF.

Como toda firma digital, esta no solo verifica que el emisor del correo es efectivamente quien dice ser, sino que si en cualquier momento existe cualquier modificación del mensaje, la firma quedaría rota, con lo que el cliente podría darse cuenta.

Por supuesto tiene sus defectos, de ahí que lo ideal sea combinarlo junto a SPF. Por ejemplo, alguien podría interceptar el mensaje, modificarlo, cambiar el dominio de origen de la firma y volver a firmarlo con una clave privada propia. El MTA de destino podría ver que la firma proviene efectivamente de donde dice venir y la verificaría con su clave privada, mientras que el remitente seguiría siendo el del origen. Pero si se está aplicando al mismo tiempo SPF, este no daría por válido el origen de dicho correo, pues pertenecería a otra IP de las permitidas (a menos que dicha IP se recogiese también en SPF)

En este caso, no se usa DKIM tan extensamente como SPF para clasificar el correo como SPAM, pero sí para crear dominios de… “confianza”. Los MTA ponderan muchas variables a la hora de determinar si un correo es SPAM o no, ó peor incluso, si es un Phising/Scam. DKIM es el modo que tenemos de decir: Ei, este dominio es mío realmente y todos mis correos que voy a enviar van a ir firmados. Eso crea una cadena de confianza, y garantiza en la medida de lo posible que nuestro dominio no sea objeto de suplantaciones.

Como se configura un dominio para usar DKIM?? Bueno, como he dicho son dos partes. En primer lugar se debería de poder configurar el MTA para firmar los correos con DKIM. No todos los proveedores lo permiten, aunque la mayoría de ellos (al menos los más importantes) sí. Tomemos por ejemplo Google Apps, una vez configurado un dominio allí podremos instruir a Gmail para firmar los correos que enviemos desde nuestro dominio. El primer paso por tanto es iniciar la autentificación para dicho dominio que realmente lo que hará será crear las claves públicas y privadas, mostrándonos la clave pública que deberemos añadir a nuestro dominio en forma de registro TXT. Con dicha clave pública, tan solo tendremos que crear un registro TXT asociado a un selector concreto. Por normativa, DKIM almacena en el servidor DNS la entrada TXT bajo el subdominio asociado a dicho selector con el siguiente formato: selector._domainkey.midominio.es.

En “selector” podremos por lo general poner lo que deseemos, incluso podemos usar diferentes selectores, pero el resto es invariante. Esto es así porque cuando nuestros correos se firmen el MTA de destino debe de conocer donde mirar para obtener la clave pública, y el único dato que se suministra en la firma es el selector. Es decir, si usamos en Google Appls como selector “google”, tal como estoy diciendo, la clave pública se podría consultar mirando los registros TXT del dominio en cuestión en google._domainkey.midominio.com. Hagamos la pruena… cojamos cualquier correo que nos hayan enviado desde Gmail y miremos su cabecera. Ahora busquemos en la cabecera la firma, puesto que por suerte y por seguridad todos los correos de gmail se firman, y nos encontramos con esta sección:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=nzLCaIESeBg8KtAGcaKCJbAggDVfBjZVSa6oLSVMOfU=;
        b=HBNSvMfDejs8TIHnh3vtDeXrtYuRKNivRUm4WMlBo7HWc7+ClZTVosOwheoajzuXZ8.. 

la d indica que dominio está firmando el correo, la s es el selector, la bh el hash del cuerpo del mensaje, la b la firma… Con esos datos, el MTA de destino puede acceder a la clave pública asociada a la clave privada que firmó el correo:

dig 20120113._domainkey.gmail.com txt

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;20120113._domainkey.gmail.com. IN      TXT

;; ANSWER SECTION:
20120113._domainkey.gmail.com. 299 IN   TXT     “k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87…”

Como digo, cualquiera puede hacer la prueba, y ver si los correos que le mandan usan DKIM o SPF, o ambos. Os sorprendería ver la cantidad de proveedores que incluso a día de hoy no usan estos sistemas. Esto toma aun importancia mayor en el mundo empresarial, por lo general usan proveedores o servicios de correo muy deficiente y con unos estándares de seguridad de risa. El uso de DKIM o de SPF debería de ser de obligado cumplimiento para cualquier administrador más o menos competente.

Por desgracia no siempre es viable DKIM. Mientras que por lo general SPF suele ser bastante simple de implementar y general pocos problemas (algunos sí), DKIM es más limitado. Muchas veces no sólo usamos nuestros MUA o el acceso web para enviar correos desde nuestro dominio, muchas veces hacemos uso de herramientas como PHP Mail() que suele ser raro que firmen los correos y además conocer bien el dominio de origen, o usamos forwarders de correo para enviarlos de un lado a otro con lo que no siempre se respeta las cabeceras  o a lo mejor una suite AV en el servidor del trabajo que analiza todos los correos al llegar y modifican su cuerpo indicando que ha pasado ciertos controles, rompiendo también DKIM. Y todo ello sin contar con la aun gran cantidad de servidores que no lo usan, ya sea porque no pueden configurarse para firmar los correos o ya sea porque cuando les llegan correos firmados no realizan ningún tipo de verificación.

 

DMARC

Por último, llegamos al némesis del SPAM y de la suplantación de correo. En realidad DMARC es más la unificación de SPF+DKIM trabajando juntos que una tecnología propia. SPF es muy efectivo para filtrar los correos ilegítimos, DKIM es un genio validando los correos y asegurando si integridad… los dos juntos pueden hacer muy complicada la labor al hacker de turno poder usar un dominio protegido correctamente con fines de SPAM o suplantación de identidad. DMARC no requiere de ambos modos, pude usar uno, el otro o ambos, a fin de cuenta como hemos dicho no siempre puede usarse SPF y no siempre puede usarse DKIM. Hay que entender que nosotros con nuestro dominio podemos enviar un correo desde el mediante infinidad de formas como se ha dicho… podríamos enviar un correo del modo tradicional por SMTP, podría enviarlo el servidor Web que tenemos para enviar notificaciones, podría ser usado nuestro dominio para usar listas de distribución usando servicios externos, o usar servcios de correo marketing como MailChimp para el envío masivo de correos, y todos ellos usarían direcciones de nuestro propio dominio!! Es decir, a veces algunos de los correos incluso que mandemos de forma legítima no seremos capaces de protegerlos mediante SPF y DKIM. DMARC pude ser suficientemente inteligente para entender estos pormenores.

Pero al margen de este baile entre SPF y DKIM, DMARC tiene algo que no tiene ninguno de los sistemas vistos hasta ahora. DMARC está preparado para que sí así lo configuramos, indicar al destinatario que si no es capaz de lograr un “pass” en DMARC, el correo lo tome por ilegítimo y LO ELIMINE. Es decir, no a SPAM, no a devolver, simplemente eliminación silenciosa de él. Os lo imagináis?? Si por un momento todos los proveedores de correo usasen correctamente DMARC y Paypal usase esta tecnología correctamente, cualquier que intentase falsificar un correo haciéndose pasar por paypal cuya dirección de correo fuese loquesea@paypal.es, jamás llegaría a su destino, el dominio de Paypal quedaría prácticamente blindado y nadie podría usarlo de forma ilícita. Sí, podría usar otro correo parecido, pero no el mismo dominio.

Otra característica especial de DMARC que lo hace único, es que se diseñó de tal modo que los MTA de destino compatibles con DMARC generan reportes diarios que envían al origen del dominio indicando datos valiosísimos, como por ejemplo la cantidad de emails que ha llegado a sus puertas usando dicho dominio, cuantos lograron pasar DMARC y si pasaron SPF o DKIM o ambos… y todo esto es de forma casi automática, el MTA de destino cuando lee un correo con DMARC (y si es compatible con él), además de leer los datos SPF  y DKIM también accede al servidor DNS para recuperar los datos relativos a DMARC, y de allí saca la política a aplicar y como tratar DKIM y SPF de dicho correo, y por supuesto la dirección de correo a la que enviar los reportes diarios. Nada se escapa a DMARC.

Como de útil es esto de los reportes?? Esencial. Los MTA de destino no tienen por qué ser compatibles con DMARC y por tanto generar reportes, pero si tenemos en cuenta que la mayoría de cuentas a día de hoy son correos tipo Gmail, Hotmail, Yahoo… y que todos ellos lo hacen, podemos tener una visión bastante buena de si se están usando nuestros dominios para fines de suplantación o no. Si a esto le sumamos que existen herramientas que nos permiten centralizar todo esto y ordenar y analizar nuestros reportes, el resultado es más que interesante. A continuación algunas imágenes de unos cuantos dominios que tengo que usan DMARC (Y SPF/DKIM):

En primer lugar, para los que creen que eso de suplantar identidades es cosa del pasado y que nadie se centra en hacer estas cosas… esta primera imagen da una visión general, y viene a decirnos que sí, que es necesario usar este tipo de tecnologías:

Captura

Como vemos en la leyenda, en verde tendríamos aquellos correos que fueron enviados y el MTA de destino pudo dictaminar que pasaban DMARC, y por tanto eran legítimos. En un porcentaje pequeño lo que llamamos forwarders, por lo general son correos legítimos pero que son reenviados por diferentes hosts para fines diversos. Y por último en rojo aquellos que fueron enviado supuestamente en nombre de nuestros dominios, pero que al comprobarlos los MTA de destino dictaminaron que no podía pasar DMARC. En todos los casos esta información se extrae de los reportes generados por los MTA de destino, y aunque en dichos reportes no se indica como es natural destinatarios o cuerpos de mensajes o… si se indica las direcciones IP de origen, entre otras cosas, con lo que podemos ver también que host/dominio está enviándolos. Como vemos, en estos 7 días de intervalo seleccionado, yo diría que un 40% han sido correos no legítimos. Dado que ninguno de mis dominios usa actualmente una política DMARC de rechazo, esos correos posiblemente lleguen aun todos ellos a los destinos, aunque casi seguro siempre a la bandeja de SPAM. Con el tiempo, cuando cambie a una política más restrictiva, ninguno de esos correos llegará siquiera a los destinatarios.

En segundo lugar vemos realmente todos los correos que se han enviado clasificados según su origen, y a la derecha un dato interesante… todos ellos pasaron DMARC, pero no significa que todos pasasen simultaneamente SPF y DKIM. Dado que las reglas de mis dominios son “laxas” DMARC puede pasar cuando uno de ellos falla.

Captura2

Por ejemplo, vemos que los que se origina en Godaddy cumplen el 100% SPF, pero no se firman. En cambio con MailChimp pasa exactamente lo contrario, todos son firmados pero SPF no pude verificarse… esto sucede porque MailChimp usa varios dominios como origen, y aunque se pueden añadir las diferentes IPs, el dominio emitido por MailChimp no coincide con el usado en el remitente real, así que SPF falla.

Podemos ver algo similar con los Forwarders:

Captura3

Los Forwarders reenvían los correos, generalmente esto no es malo, lo que pasa es que no todos funcionan igual. Por ejemplo hay Forwarders que preservan la firma y no la alteran, mientras que otros alteran el cuerpo del mensaje de algún modo y rompen la firma.

Y para acabar, por supuesto, tenemos aquellos que quieren usar nuestros dominios como origen de correos fraudulentos:

Captura4

Y no, no son pocos.

 

Desde el punto de vista del administrador del dominio, no requiere nada para habilitarlo en su dominio, sólo crear la entrada TXT correspondiente en su servidor DNS, similar a como se ha realizado anteriormente. Eso sí, si el MTA de destino no es compatible con DMARC simplemente ignorará las directrices configuradas en el registro TXT del servidor de correo, y tampoco generará reportes.

Un ejemplo real de esto.. supongamos q pedro@pedrito.com usa DMARC, y manda un correo a lacasito@gmail.com. Gmail es compatible con SPF, DKIM y DMARC. Pedro firma su correo por DKIM y también usa SPF y DMARC. Cuando el correo llega a Gmail: a) Verifican que SPF es correcto como hemos comentado antes, y lo marca como superado (Pass). b) Verifica la firma y la integridad del correo como hemos dicho anteriormente, como es correcto de nuevo lo marca como superado (Pass). Por último, mira las políticas DMARC que hace Pedro, y lee algo como:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Dado que tanto SPF como DKIM han dado de resultado un superado (Pass), y no hay nada que impida en las políticas DMARC de pedrito que falle DMARC, DMARC se marcará igualmente como superado, y Google enviará un correo a reportes@pedrito.com al final del día con todos los correos que fueron enviados por direcciones de pedrito.com a sus servidores.

Pero que pasaría si DKIM o SPF fallan?? Bueno, aquí depende de como se configuren las políticas. Por defecto, son relajadas, si fallase alguna de las dos por lo general DMARC seguiría siendo superado, aunque como digo esto puede configurarse. Y que pasa si DMARC falla?? Si falla se aplica la política que hay en el registro DNS. En el caos anterior aplica la política “reject”, es decir… si DMARC falla el MTA de destino debe de borrar el correo, rechazarlo. Se podría usar none, y simplemente DMARC no haría “nada”. Esto es muy útil sobre todo al principio de implementar DMARC, a fin de cuenta si de primeras decimos que se rechacen, posiblemente perderíamos muchos correos legítimos por una mala configuración de DKIM/SPF o de alguno de nuestros servicios. Es práctica común usar “none” durante un tiempo de meses, comprobar que funciona todo bien, y pasar poco a poco a rechazarlos.

El formato a usar en el servidor DNS es similar a los anteriores, aunque en este caso de nuevo por normativa se usa el subdominio _demarc. Es decir, que la entrada DNS irá ubicada en _dmarc.midominio.es. Hemos visto arriba como sería, en su versión más simple:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Donde p es la política y rua la dirección de correo para los reportes.

Cualquiera que mire la cabecera de un correo que le ha llegado, pude igualmente ver si su MTA verifica de algún modo estas tecnologías. Por ejemplo si miramos un correo entrante de una cuenta de google.coml, vemos algo así (aunque sería similar en las de GMAIL)

Authentication-Results: mx.google.com;
       dkim=pass header.i=@google.com;
       spf=pass (google.com: domain of ...;
       dmarc=pass (p=REJECT dis=NONE) header.from=google.com

Vemos que Google, en los correos de sus dominios si fuerza una política de Reject. Esto hace que si alguien intenta usar su dominio para falsificar una dirección de correo en su remitente, el MTA de destino si es compatible con DMARC lo eliminará instantáneamente. Vemos igualmente que ese correo ha logrado pasar DKIM, SPF y por tanto DMARC


 

Conclusiones

De verdad aun hay quien cree que no necesita saber nada sobre SPF/DKIM/DMARC?? Está claro que para los usuarios que usen correos ordinarios tipo gmail, hotmail y otros no es tan importante, además ellos no pueden configurar nada, solo tener la esperanza que sus proveedores usen los mejores estándares de seguridad. En este caso Gmail posiblemente es pionero, mientras que Hotmail por ejemplo no los firma y bla bla bla. Pero para el resto de usuarios que usan cuentas personalizadas, o empresariales, o de cualquier otro tipo, es aun más importante usar estas tecnologías. A fin de cuentas, al final, cualquier usuario puede crear una cuenta de gmail o hotmail para enviar o intentar enviar correo falsificado a otra cuenta con el mismo dominio, pero nadie puede crear cuentas de un dominio propio. Además, es evidente que es mucho más… jugoso para los hackers/spammers y otros atacar cuentas personales/profesionales independientes, sobre todo a la hoar de intentar suplantar la identidad de alguien.

Router Mitrastar HGW-2501GN-R2: Shell e Ingeniería inversa (para crear firmwares modificadas, por ejemplo) (Actualizado)

Share on Google+Share on FacebookTweet about this on Twitter

mitrastar
Introducción

La historia es sencilla. Aunque en la medida de lo posible siempre uso mis propios dispositivos, me gusta igualmente exprimir cualquier otro chisme que tenga por casa. Unos fuman… yo cacharreo.

En este caso, este fue el router que me entregó el ISP para mi conexión de Fibra, Mitrastar HGW-2501GN-R2. Duró conectado a la línea el tiempo de irse el instalador, pero lo saqué recientemente del “trastero” al ver por los foros de soporte oficiales (y no oficiales) que estaba dando un sin fin de problemas a los usuarios. Como siempre he dicho, opinar podemos hacerlo todos, pero si queremos dar soluciones que sean lo más acertadas posibles, es mejor comprobar las cosas por uno mismo y poder estudiarlas como dios manda. Así que le saqué el polvo y me puse a desentrañar sus más y sus menos.

Un dispositivo es bueno o malo sencillamente a razón de dos cuestiones sencillas, y es lo bueno o malo que sea su hardware y su software. Si el hardware es “malo” las ataduras de manos siempre son mucho peores, porque salvo modificaciones directamente en el hardware poco podemos hacer. Un hardware bueno tampoco hace del dispositivo algo bueno, es fundamental el Software, y sobre el software podemos decir lo mismo.

En el caso del Mitrastar, tenemos un poco de todo. Respecto al hardware no es ni mucho menos de lo peor que podemos encontrarnos en un router como muchos puedan pensar, pero eso no quiere decir que no se hubiese podido mejorar sustancial, sobre todo lo referente a su interfaz wifi. Eso no podemos cambiarlo, tenemos que aguantarnos con lo que hay. No he conectado aun el router por puerto de serie ni lo he sacado de su carcasa, así que los siguientes datos pueden no ser exactos del todo. Por lo que podemos saber el hardware se compone de una arquitectura MIPS:

CPU1: Ralink RT63368F (En Placa)/RT63365 (En Software)
Switch: Realtek RTL8368MB
Wl0: Ralink RT5392
RAM: 128MB
Flash: 64MB

El Switch debe de contar con unos 7 puertos diferentes, apoyado principalmente por el SOC RT63365. El adaptador inalámbrico dista mucho de ser una maravilla, nos encontramos ante un disposotivo 802.11n de dos streams unibanda. Por otro lado contamos con una cantidad más que suficiente de RAM y Flash para todo, lo cual siempre se agradece el no ir siempre bajo mínimos.

El principal problema que se ha tenido es que el software del router (la firmware) ha estado lejos de ser aceptable, salvaguardando por supuesto las propias limitaciones del hardware. Entre las quejas más frecuentes han sido los enormes problemas de batería causados por el router a dispositivos portátiles, la interfaz web de configuración con constantes problemas… En un mundo ideal, como se trata de Software, en el peor de los casos podríamos decir: “Pues si no quieren hacer ellos su trabajo, al menos voy a ver si puedo yo mejorar o corregir alguno de esos problemas de software”. Pero nunca suele ser tan sencillo, las firmwares y los sistemas se protegen precisamente para impedir cualquier tipo de modificaciones al software, siguen sin entender que cuanto más abierto sea un software más probabilidad hay que funcione mejor y con menos fallos/problemas.

 

Acceso Básico

Manos a la obra, partamos desde cero. Instalamos el router, lo tenemos todo funcionando… ¿ahora que?. Aquí entra en juego el primer escollo, y la culpa de esto la tiene principalmente los ISP, nada que ver con los fabricantes del hardware o el software que se instala (por lo general). Los dispositivos que nos entregan actualmente (No solo Movistar) vienen precargados con una configuración básica por defecto con los ajustes básicos de la compaña, como puedan ser los SSID, ajustes de WAN… ahora debido a los servicios avanzados como VoIP o IPTV suele ser necesario además de todo esto ajustes adicionales específicos para cada cliente, así que el router está preparado para conectar a los servidores de ellos después de un reset o cada X tiempo para reconfigurarse con los datos de la línea del cliente. Esto es perfecto porque evita configuraciones manuales uno a uno.

Lo primero que quiero o puede querer cualquiera es realizar pequeños ajustes a nuestro router, ya sea abrir un puerto, configurar una IP diferente… eso lo hacemos como toda la vida de dios, lo más básico y sencillo: La interfaz web del Router. El problema aparece porque la mayoría de los ISP se preocupan y hacen TODO LO POSIBLE para que el usuario, el cliente, tenga acceso a cuantas menos funciones posible del router mejor. Esto se hace por lo general con la creación de usuarios con permisos mucho más restrictivos a los usuarios tipo admin/root con acceso completo. Estos usuarios que crean tienen al final acceso para modificar 3 parámetros y medio y no poder consultar muchas otras configuraciones que pueden ser de interés, con lo que nos limita enormemente, incluso a usuarios con un perfil básico. Esto es algo que la mayoría no toma en cuenta cuando contrata un ISP u otro, pero para mí es esencial y marca mucho el tipo de compañía que tienes delante. Muchos de los amigos que me leen saben mi opinión sobre Apple, y se resumen sencillamente en que no permito que una compañía me diga que puedo hacer o no hacer con mi hardware.

Dependiendo del dispositivo que tengamos instalado y dependiendo del ISP, podremos acceder de mejor modo o no la configuración de nuestro router. En el caso concreto del Mitrastar, tengo que decir sinceramente que chapó por Movistar, ha hecho lo que tenía que haber echo hace tiempo y hacer TODOS. El Mitrastar, como viene siendo ya costumbre desde hace tiempo en los dispositivos de Movistar tiene dos interfaces web, una sencilla para usuarios nóveles que quieren cambiar 3 cosas (llamada Movistar Home Station, aka mhs, y una avanzada. El Mitrastar posee 3 usuarios (en realidad son 4, pero el usuario samba lo obviamos), cada uno con permisos diferentes enfocados a necesidades diferentes:

-“admin”: La contraseña de este usuario podemos encontrarla debajo del router en una pegatina. Este usuario y contraseña nos da acceso a las dos interfaces del router. Es el acceso normal a la interfaz mhs, y si accedemos a la avanzada a través de mhs (o a través de la dirección http://IP/cgi-bin/main.html) nos encontraremos con limitaciones en cuanto que podemos modificar. Esta cuenta por otro lado carece de acceso por terminal (SSH/Telnet…)

-“1234”: La contraseña coincide con la contraseña anterior, y en este caso sería lo más similar a un usuario root. Tiene acceso completo a las opciones de configuración de la interfaz, y es la cuenta que usa el portal Alejandra igualmente para configurar de forma remota nuestros dispositivos (si los tenemos asociados al portal).

-“supervisor”: La contraseña en este caso es siempre la misma, zyad1234, y posee permisos similares al usuario 1234, con el añadido de que con este usuario se tiene acceso por la interfaz web a poder modificar los permisos de los otros usuarios y de sus contraseñas igualmente.

mhs
web

Ahora entenderéis porqué digo que en este caso chapó por Movistar. Cualquiera puede tener acceso completo (al menos por web) al Mitrastar, sin hacer cosas extrañas, sin tener que pelearse, sin acudir a… dicho de otro modo, los técnicos de Movistar no tienen un mejor acceso que nosotros. Gracias a estos usuarios podremos no sólo consultar la mayoría de todas las configuraciones del router, sino que también ajustarlas a nuestro antojo.

Por otro lado, lo primero que se le ocurre a cualquiera es ver como son los archivos de configuración (backup) del router, así que como primer paso para entender un poco todo lo que cualquiera haría sería descargar dicho archivo desde mantenimiento, quizás sea legible o haya algo o algún ajuste que pueda ser de interés. El archivo de configuración del Mitrastar, por suerte, no está cifrado y parece ser un xml totalmente legible, pero que algunas opciones curiosamente las enmascara, todas aquellas donde hay contraseñas. Por qué es esto interesante?? Bueno, yo he dicho que la contraseña de admin y 1234 es la misma, pero a veces no es tan sencillo como prueba/error, o mejor dicho… a veces es más sencillo no tener que estar probando… pero como vemos el archivo de configuración no permite ver estos datos. En cualquier caso, vemos que estos campos llamados “encrypted” comienzan todos por: “41455300”, casualidad que 41 45 53 = AES, lo cual nos daría a pensar que el resto es posible que sea el texto codificado en AES.

 

Acceso Limitado por Terminal

El 99% de las veces nos sobra la interfaz web, pero que pasa cuando nos gustaría poder modifica o consultar cualquier cosilla que no esté presente o tengamos acceso por la interfaz web?? A fin de cuenta presuponemos que nuestro router estará corriendo algún tipo de Linux debajo de él. Para eso es indispensable acceso mediante SSH o Telnet. El problema es que como aplican la mayoría de fabricantes, para negarnos la posibilidad de toquetear las tripas, lo que nos dan es acceso es a una shell limitada… muy limitada. Así, en el caso del Mitrastar si intentamos acceder mediante supervisor o 1234, nos encontramos ante un panorama… “triste”:

ssh

Así pues podemos acceder con las credenciales por defecto, pero los únicos comandos que nos muestra la interfaz como válidos son: ?, exit, save, sys, restoredefault, lan, igmp, wlan, nat. La mayoría de todos ellos tienen subcategorías. No hay nada interesante a priori que podamos hacer desde la shell que no podamos hacer desde la interfaz web. Dos comandos “al azar” muestran dos resultados interesante: mtd y sh, ninguno de los dos listados en los comandos disponibles. El primero nos devuelve que el comando está prohibido, el segundo directamente que introduzcamos una contraseña… ¿quizás existe una contraseña para poder acceder a la shell que hay debajo? Por descontado ninguna de las contraseñas que disponemos es aceptada como válida.

Algo relativamente común a las shell limitadas es que permiten realizar copias de la configuración. A priori podríamos pensar que esos “dump” son iguales que los que podemos obtener desde la interfaz web, pero… que pasa si introducimos por shell limitada “sys dumpcfg”?? Sí, nos devuelve en la consola exactamente el archivo de configuración que pudimos descargar con anterioridad… pero con una salvedad, en esta ocasión los campos de contraseña están en texto plano. Bingo!!

username=”supervisor” web_passwd=”zyad1234″ console_passwd=”zyad1234″

La contraseña es la misma, pero en cambio en el archivo de configuración cifrado vemos que el “resultado” es diferente. Asumimos que además de poder estar cifrado con AES usa algún tipo de SALT, y no sólo una key cualquiera. Aun así esto tampoco nos abre la puerta a mucho más, esta contraseña es de hace mucho conocida y compartida en muchos productos.

 

Acceso a la Shell que hay debajo

Lo que nos interesa es acceder detrás de la shell limitada a la que tenemos acceso. Parece que para esto existe directamente un medio para hacerlo, a través del comando “sh” desde la shell limitada, pero esto nos solicita una contraseña que es totalmente desconocida para nosotros. Aquí empieza realmente el trabajo duro, ingeniárselas de algún modo para poder acceder debajo, aunque sólo sea una vez, y poder echar un vistazo desde una shell completa. No voy a detallar, por cuestiones de seguridad, como logré ese primer acceso, pero sí de que se trata.

Presuponemos que tenemos Linux debajo, con lo que realmente lo primero que desearíamos sería echarle un ojo al archivo /etc/passwd y/o /etc/shadow. Estos dos archivos, en linux, son los que contienen las credenciales de los usuarios y sus contraseñas (cifradas claro está). Pero además contienen la shell que será ejecutada a cada usuario. Es posible que el router posea otro usuario/contraseña que desconocemos o a saber…

Pongamos que gracias a la interfaz web logramos ejecutar de algún modo algún comando dentro de la shell y sacar los datos por el navegador. “cat /etc/shadow” cat /etc/passwd” sería sin duda alguna las primeras pruebas, y pongamos que en un momento dado la interfaz web nos devuelve lo deseado, nada para shadow, y para passwd:

1234:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
admin:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/sh
supervisor:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
samba:$1$$xxxxxxxxxxxxxxxxxxxx:500:500:Linux User,,,:/home/samba:/bin/sh

Bingo!! (de nuevo). Parece ser que además de existir un cuarto usuario, samba, el usuario 1234 y el usuario supervisor (que son los dos únicos que tienen acceso por shell) ejecutan una shell extraña llamada “cmdsh”. Sea como sea, si logramos ejecutar con suerte cat, podríamos igualmente intentar sobrescribir el contenido del archivo, igual no existe una protección contra escritura… como dicen, probar no cuesta nada… usando incluso de nuevo cat, se puede enviar el mismo archivo pero modificando la shell a ejecutar, en vez de /bin/cmdsh, /bin/sh. Lanzamos la petición, volvemos a lanzar otra para ver el contenido y… se ha modificado!!. Ejecutemos de nuevo una sesión Telnet/SSH, usuario 1234 (es al usuario que le cambie la Shell), su contraseña… y efectivamente no más shell limitada:

login as: 1234
1234@192.168.1.1’s password:
# ls
bin      boaroot  dev      etc      lib      linuxrc  proc     sbin     sys      tmp      userfs   usr      var
# uname -a
Linux MitraStar 2.6.36 #1 SMP Thu Aug 13 14:04:19 CST 2015 mips unknown
#

 Llegados a este punto ya lo tendríamos todo?? Sí y no. Esto habría que repetirlo siempre, porque si reiniciásemos el router veríamos que el cambio que habíamos realizado al archivo passwd se perdería, teniendo que repetir todo el proceso constantemente. Aun así al menos ya habríamos logrado acceder a la Shell de debajo con plenos permisos administrativos. ¿Podemos mejorar esto? Por supuesto.

Lo primero que viene a la cabeza es: Bien, puedo acceder gracias un exploit, pero parece ser que la shell cmdsh tenía un comando “sh” que solicitaba una contraseña para acceder, y no hay que ser muy listo que lo que permite es acceder precisamente a una shell completa. ¿Donde puede estar esta contraseña? Personalmente el primer lugar donde miraría, teniendo en cuenta que no parece existir otros usuarios en el archivo /etc/passwd, es en el binario de la propia shell, o sino este sabrá de donde obtenerla, dado que es esta shell la que lo solicita. Ya sabemos donde está, así que sólo tenemos que extraerlo. Esto puede hacerse de mil y una forma, dependiendo de las herramientas que tengamos disponibles claro está en la firmware del router:

-ssh/sftp/ftp/scp
-curl/wget
-netcat/nc
-base64
-usb
-…

Cualquier sistema nos vale para enviar donde queramos el archivo en cuestión y poder manipularlo en condiciones, la elección de un sistema u otro dependerá de las utilidades que tenga la firmware y de lo sencillo o no que nos resulte a nosotros mover los archivos. Una vez tengamos el archivo, tan solo tendríamos que decompilarlo y echar un vistazo rápido. Vamos a lo sencillo, si cuando introducimos a través de sh una contraseña cualquiera recibimos: “Password incorrect !” Podemos empezar buscando por ahí, o mirar directamente las posibles funciones… eso nos lleva al siguiente trozo de código:

diss

Curiosamente, justo unas líneas de ahí encontramos una extraña cadena alfanumérica. Bueno, además de que el código en ensamblador es bastante legible, lo que está claro es que compara un string (lo que introducimos por teclado) con el string “c93vu02jp4z04“. Si la comparación es incorrecta, vemos que salta a la posición 0x00402408 (=contraseña incorrecta), mientras que salta a otra posición en caso de que la comparación sea acertada. Dicho y hecho, tan solo tenemos que verificar que ese string es realmente la contraseña para acceder a la shell completa desde la shell limitada. Y no hace falta decir que efectivamente esa es la contraseña de acceso a la Shell.

Llegados a este punto lo tenemos todo, hemos podido acceder gracias a un exploit, hemos podido extraer la contraseña que nos da acceso a la shell completa, con lo que podemos ya hacer con nuestro router lo que deseemos… ¡No tan rápido! ¿Seguro que ya tenemos total libertad?.

 

Acceso (y modificación) a la “nvram” – Autentificarse

Como vimos en la parte del exploit, y si empezamos a jugar con la shell interna, antes o después nos topamos con un problema bastante importante. Sí, podemos usar todas las utilidades de nuestro router, podemos añadir reglas a iptables, ver el estado de todo, controlarlo todo!! ¿Pero como podemos hacer para que los cambios que hagamos sean persistentes?

Vimos que si intentábamos modificar el archivo passwd este volvía de nuevo a su “ser” al reiniciar. Esto nos dice que al menos la raiz de la firmware está protegida contra escritura de algún modo, y de echo no hay que ser demasiado imaginativo para ir entendiendo que el sistema de archivo del router usa SquashFS, un sistema de archivos de sólo lectura que se monta en cada inicio. Ademeás, si miramos realmente la ubicación de la carpeta /etc tenemos esto:

# ls -la /etc
lrwxrwxrwx    1 1234     root            8 Aug 13  2015 etc -> /tmp/etc

La carpeta /etc desde la cual accedemos a /etc/passwd ni siquiera se encuentra en el sistema de archivos SquashFS, sino que el bootloader/kernel genera el archivo de algún modo en cada inicio, por eso pudimos modificarlo con el exploit entre otras cosas, está fuera de la “prisión” de SquashFS. Se genera en cada inicio, con lo que nuestros cambios se pierden. Pero sabemos que todo no es tan negro, porque en realidad debe de existir una zona o partición donde se puedan inscribir datos y estos sean persistente, o algún sistema para poder hacerlo, ya que a fin de cuenta podemos configurar el router a través de la interfaz web, y los datos son persistentes a cada reinicio. Si cambiamos por ejemplo la contraseña del usuario 1234 dicho archivo al iniciar será diferente al original y reflejará el cambio que hicimos por la interfaz Web. Quizás no podamos modificar el sistema de archivo raiz (lo haremos, pero más adelante), pero cuanto menos en teoría deberíamos de ser capaces de realizar cualquier cambio persistente que permita la interfaz web, y eso como mínimo, porque es de suponer que esté donde esté ese “espacio” contendrá quizás otros datos de interés.

Así es realmente como funcionan la mayoría de dispositivos. Los routers suelen tener una zona llamada nvram (RAM no volatil), que contiene parámetros que pueden ser leídos y almacenados con independencia del sistema de archivos. Esto es necesario para poder realizar configuraciones de cualquier tipo, pero incluso el propio router necesita este “espacio” para poder funcionar y configurarse a sí mismo. En muchos dispositivos es bien conocida la herramienta “nvram”, pero si lo intentamos veremos que aquí al menos no disponemos de una herramienta similar. Así que queda hacer un poco de detective y ver si disponemos de alguna utilidad que nos brinde algo similar.

Como podemos acceder a la shell podemos recorrer rápidamente los directorios donde sabemos que es más que posible que se encuentren: /bin, /sbin, /usr/bin… la mayoría de todas las utilidades podemos conocerlas los amantes de linux y muchas otras deducirlas. Otras en cambio podemos ir directamente probando a ver que pasa. Si no damos con la “tecla”, tenemos otro sistema sencillo para hacernos una idea… si la interfaz web cambia los ajustes, la interfaz web debe de saber o tener idea de como realizar esto. Antes o después llegaremos a la conclusión de que hay ciertos binarios que parecen ser los encargados de manejar todo esto, aquellos que empiezan por “tc” que es el acrónimo de TrendChip. Si nos movemos por las carpetas de la interfaz web (/boaroot) veríamos también rápidamente las referencias constantes a tcwebapi, y mira tu por donde tenemos un binario llamado: “tcapi”. Si lo invocamos:

# tcapi
set unset get show commit save read readAll staticGet

 Parece ser que hemos dado con la interfaz que interactúa con la nvram. Con un poco de paciencia y de estudio aprendemos a usar esta interfaz. tcapi funciona de un modo similar a nvram, con show podemos mostrar lo que deseemos (no existe un show all), pero tenemos que especificar que nodo queremos visualizar. Los nodos son precisamente las etiquetas xml que están dentro de nuestros archivos de configuración. Si miramos nuestro archivo de configuración veremos por ejemplo uno de los primeros nodos, “Wan”, así que “tcapi show Wan” nos devuelve efectivamente todo lo almacenado en ese nodo. Podemos pensar que esto no tiene demasiada utilidad ya que a fin de cuenta tenemos el archivo de configuración, pero no hay que ser muy listo para presuponer que el archivo de configuración es sólo una parte de todo. De echo podemos almacenar los valores que queramos en la nvram existan o no existan en el arcivo de configuración, o modificar cualquier otro.

Si alguien ha usado anteriormente nvram (la utilidad) sabrá que para que los cambios se apliquen hace falta realizar un “commit” y seguido de un “save” si se quiere que los cambios se guarden (aplicar no significa guardar, y viceversa). Aquí tenemos lo mismo. “tcapi save” guarda todos los cambios realizados en la nvram, mientras que “tcapi commig nodo” aplica los cambios efectuados al nodo citado. Cuidado!! Estamos modificando la nvram, si guardamos los cambios y estos han sido incorrectos podemos encontrarnos en que sea necesario resetear el router para que vuelva a sus ajustes por defecto.

Quien llegue a este punto se habrá dado cuenta que, de echo, aunque puede usar show, no puede realizar un save y peor aun, un set, devolverá lo mismo que sucedía cuando intentábamos teclear mtd. El acceso por alguna razón a ciertos comandos, incluso teniendo permisos administrativos y a la shell completos, siguen estando restringidos, hace falta algo más para desbloquear esto. Aquí tendríamos de nuevo que empezar a investigar donde buscar y encontrar esto. Podríamos empezar por cmdsh y encontraríamos referencias a un supuesto archivo llamado “/tmp/Authentication”. Antes o después (grep es un gran amigo), daríamos con el binario /usr/bin/syscmd. Si decompilamos y echamos un ojo llegaríamos pronto a una sección bastante interesante:

auth

Vemos demasiada información, pero todo de gran utilidad. Por un lado vemos que aparece de nuevo el archivo nombrado, pero esta vez precedido de un comando completo, y además curiosamente justo encima vemos un “Correct Key imput. Auth…”. Eso ya nos está diciendo que el sistema parece importarle más que el usuario esté “autentificado” ante ciertos comandos que cualquier otra cosa, y que parece que lo verifica seteando el archivo /tmp/Authentification con authenticated. Podríamos hacer la prueba: “echo authenticated > /tmp/Authentication” y veríamos que funcionan mágicamente a partir de este momento tcapi set/save y otros

Antes de irnos a otro lado, podemos ver igualmente en el trozo desensamblado de nuevo la contraseña de acceso a la Shell, y un “EncryptKey” y un “Account_Common”. Quien haya estado ya jugando con la nvram sabrá que en esta se separan los nodos de otros subnodos con guiones, así que por curiosidad si miramos la información del nodo “Account_Common” con tcapi:

# /userfs/bin/tcapi show Account_Common
EncryptKey=MSTC

El resultado es un string: MSTC, que según aparece en la nvram es un “EncryptKey”. Demasiado cerca del código que hace estar autentificado para no tener nada que ver. Si vemos desde la shell que podemos hacer con syscmd, vemos que existe curiosamente un comando que es authKey, y que efectivamente:

# syscmd authKey
Error!
# syscmd authKey MSTC
Correct key input. Authentication done.

Así que en realidad el proceso “real” implicaría autentificarse a través de syscmd con la EncryptKey almacenada en la nvram, MSTC, y eso a su vez produce que el sistema setee el archivo anteriormentes citado. Así que en realidad podríamos realizar la autentificación de cualquiera de las dos maneras: por lo “legal” y a lo “bruto”. Ahora sí, después de esto, podríamos usar algunos de los comandos más particulares (y también peligrosos), como puedan ser: sys memwl, sys memww, sys erase, sys romd, tcapi set, tcapi save…

La nvram permite acceder a todos los parámetros almacenados en nuestra configuración, y además acceder a otros parámetros que podrían ser interesantes, pero eso para otro día. Veamos mejor que más podemos hacer… podemos modificar la nvram, podemos ejecutar cualquier herramienta que tengamos dentro del router, ahora iremos un pasito más, esta vez como poder “modificar” lo que nos queda, el sistema de archivos, e incluso poder instalar/actualizar componentes en ella.

 

Ejecución de comandos desde el archivo de configuración (Nuevo)

Por azares de la vida, me topé días después con que resultaba relativamente sencillo realizar ejecución de código directamente desde el archivo de configuración del router, que no deja de ser gran parte de la nvram. El secreto reside en el nodo “Autoexec”, que si miramos en nuestro archivo tan sólo existe como cierre.

El cfg_manager, por suerte para nosotros, parsea el cfg en cada inicio para cargarlo a la nvram. Al llegar a dicho nodo, si no está vacío, pasa TODO lo que hay en él (sin el nombre de la entrada, sólo los valores de estas) a un archivo llamado autoexec.sh en /etc/, le da permisos de ejecución y acto seguido lo ejecuta. Dicho de otro modo, podemos añadir todo el código que queramos ahí, que será ejecutado al inicio en el Router. Evidentemente de saber esto anteriormente, el proceso de acceso inicial al router hubiese sido mucho más sencillo.

El potencial de esto ya no está realmente en los expertos que sepan modificar la firmware o entrar y salir del Router de forma sencilla, sino que el usuario novel puede de forma sencilla gracias a esto solucionar problemas que pueda tener en el router, o aplica ajustes concretos especiales.

El formato que siguen estas instrucciones es similar al de otros nodos:

<Autoexec>     <Entry
arp_fix=”sysctl -w net.ipv4.neigh.br0.mcast_solicit=0″
dhcp_fix=”echo ‘* * * * * ebtables -D FORWARD -p ipv4 –ip-proto 17 –ip-source-port 67:68 -j DROP’ &gt; /etc/admin; crond -c /etc/” />
</Autoexec>

Ese por ejemplo sería el bloque modificado para realizar dos fixs a la firmware B21, uno el problema de la batería y otro el problema que posee el router que bloquea todo el tráfico DHCP que no sea el suyo propio. Es sólo un ejemplo sencillo, en realidad podríamos realizar casi cualquier cosa. Como vemos la entrada en sí no importa su nombre, es su contenido el que será pasado al archivo autoexec.sh. Tan sólo hay que añadir el bloque que queramos, guardar, cargar la configuración y solucionado.

 

 

Modificando el sistema de archivos raíz

El router usa como hemos dicho SquashFS para montar su raíz. El problema que esto nos origina es que no podemos realizar cambios en él directamente. Para poder hacer esto, en principio, lo que se necesita es modificar directamente la imagen SquashFS con los cambios que deseemos y volver a cargarla. En un sistema más potente o con otras herramientas podríamos incluso pensar hacer el proceso directamente bajo la misma shell, pero aquí estamos limitado tanto en espacio, herramientas y memoria del router, con lo que esta opción no es muy viable. La opción que nos queda es realizar la modificación fuera del router, y volver a escribir el sistema de archivos de vuelta al router.La teoría en realidad es sencilla, la práctica es algo más complicada porque hay que ver como podemos hacer esto.

A priori se me ocurren dos formas. Una, extrayendo en la partición que se encuentre (en caso de ser así) el sistema de archivos, modificarlo, copiarlo de nuevo dentro y volver a copiarlo a su partición con dd/mtd (lo cual puede resultar bastante peligroso si hacemos algo mal y tampoco tengo claro que pueda realizarse sin hacerlo desde el bootloader), o aprovecharnos del propio sistema de actualización de firmware del router, es mucho más seguro pero implica conocer bastante bien como es la imagen de actualización, para poder no solo modificarla, sino también hacer que el router la acepte. Yo he tomado la segunda opción, no quiero tener que llamar a Movistar para decirles que misteriosamente el Mitrastar ha muerto.

Dicho esto, se abren por desgracia una serie de puntos que pueden ser “largos”, pero necesarios. Si queremos modificar la firmware, lo primero que necesitamos es precisamente al firmware, el binario de actualización, y dado que las actualizaciones se realizan por telecarga puede no ser tan sencillo tener una copia de ella, a menos que conozcamos a algún amigo de un amigo que buenamente nos la suministre. Por suerte… hoy tenemos respuestas y medios para todos.

 

Estructura interna de las particiones de memoria

Antes que nada hay que “estudiar” como está organizada la memoria flash del router, hay que ver realmente que particiones hay:

# mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 “bootloader”
mtd1: 00020000 00020000 “romfile”
mtd2: 0014e7e3 00020000 “Kernel_main”
mtd3: 01090000 00020000 “Rootfs_main”
mtd4: 00006292 00020000 “Defcfg_main”
mtd5: 01d40000 00020000 “Tclinux_main”
mtd6: 0014e7e3 00020000 “kernel”
mtd7: 010b0000 00020000 “rootfs”
mtd8: 00006292 00020000 “defcfg”
mtd9: 01d40000 00020000 “tclinux”
mtd10: 00020000 00020000 “romd”
mtd11: 00020000 00020000 “second_romfile”

Con eso tenemos una visión más que completa del mapa del router, de como se compone internamente.Efectivamente comprobamos que la partición raiz es SquashFS, las particiones /sys, /proc son las habituales. A parte de ello se monta una partición como “ramfs” que como vimos contenía el archivo /etc/passwd, y por otro lado uan con el extraño nombre “usbfs”… es posible que el router tenga internamente puertos USB después de todo, y de echo la interfaz tiene configuraciones para SAMBA.

Lo que se refiere al particionado de la Flash, vemos hasta 12 particiones, y por suerte para nosotros los nombres son relativamente descriptivos. Vemos además que las particiones mtd2-5 estan duplicadas, o al menos eso parece, lo que nos hace pensar en un sistema de doble imagen, muy usado en los sistemas para evitar una mala actualización. Bootloader, kernel, rootfs y rom/cfg parecen evidentes su contenido, mientras que tenemos otra partición algo más extraña con el nombre de tclinux. El tamaño de las diferentes particiones también nos dan otra idea, siendo tclinux la partición más grande con diferencia, más que la suma de las demás, lo que posiblemente nos indique que tclinux es de algún modo “todo”, y de echo, lo es.

Pero pongamos por caso que tenemos la imagen de actualización, nos será más sencillo para explicar su estructura, y más adelante veremos como poder extraerla si queremos desde el router, que es secundario.

 

Estructura de la imagen de la firmware

Actualmente tan sólo existe una firmware completamente oficial, la B14, aunque la B21 se ha distribuido a muchos usuarios debido a los problemas ocasionados por la B14:

Mitrastar b14 113WJI0b14.bin b79d53bb663cbae480532942cc0e961a
Mitrastar b21 113WJI0b21.bin 770a5a52069066dc87978dba949cb1fd

Tomemos la segunda por caso. En lo personal, me gusta siempre antes de cualquier otra cosa, echarle un vistazo a través de un editor hexadecimal a ver que veo. Haciendo un barrido sin demasiada observación, vemos en primer lugar lo que parece claramente una cabecera al comiendo de la imagen, y curiosamente al final de todo el archivo nos encontramos también que termina con “</ROMFILE>” que es precisamente como termina también nuestro archivo de configuración. Si hacemos una pequeña búsqueda con esto, podemos localizar también el inicio de esta parte, que parece que tiene una pequeña cabecera que lo precede especificando que está comprimido y el tamaño que posee, eso lo vemos en el offset 0x011d27d6.

firmware

Como sabemos también que se supone es una imagen SquashFS, podemos buscar su cabecera y ver si se encuentra alguna correspondencia, buscando por los valores “68737173”, y sí… encontramos también una correspondencia de este en el offset ox0014e7e3, que termina de echo justo cuando comienza el archivo de configuración antes citado. Con esto tenemos prácticamente, y sin necesidad de usar ninguna utilidad, el contenido completo de la firmware (aunque queda ver y analizar aun unas cuantas cosas). Lo único que nos queda es una parte, que se encuentra después de la cabecera y antes de la imagen squashfs. Teniendo en cuenta que tenemos la información anterior de las particiones mtd, la respuesta es evidente: Es el kernel. Recordemos que en las particiones teníamos 3 en concreto que estaban duplicadas con el mismo nombre, con la única diferencia a priori de que las particiones más bajas tenían la coletilla main. Bien, por pura lógica asociamos defcfg al archivo de configuración que hemos encontrado, roofs a la imagen squashfs y el otro pedazo que nos queda es el Kernel. Además, como tenemos el tamaño de las particiones vemos también que efectivamente, si dividimos cada parte independientemente, corresponden sus tamaños a los tamaños de las particiones (ojo que dado que el tamaño de erasesize es de 0x00020000, el espacio de las particiones es múltiplo siempre de este valor, con lo que el tamaño excedente se rellena). Con este pequeño análisis, podríamos ya extraer la imagen squashfs a nuestro equipo, y a priori modificarla como nos diese en gana, volver a crear la imagen squashfs y ver como poder volver a montar la imagen de actualización con todo sin romper nada.

 A partir de aquí, tendríamos el trabajo farragoso. Es necesario comprender las cabeceras, el contenido tan sólo es lo sencillo. Diseccionar las cabeceras es un trabajo más meticuloso y estar haciendo comprobaciones, sumas, cuentas, mirar binarios del router en busca de más información… es tedioso. En mi caso empiezo siempre desde el comienzo, identifico lo que parecen ser los “Magic Number”, cadenas de texto descriptivas que pueden indicar versiones, conjuntos de bytes que indiquen tamaños y desplazamientos, checksums… en definitiva, lo que se puede esperar de cualquier cabecera. Diseccionar totalmente la cabecera (las dos que hay) fue lo que más tiempo me llevó. Os desgloso lo que sería la estructura integral de la firmware, incluyendo por supuesto la estructura de su cabecera. Digamos que la imagen de actualización se compone de tres “partes”. La cabecera, la firmware en sí (compuesta de kernel+rootfs/sistema_archivos) y el archivo de configuración:

0x00000000 Header
    0x0000 Cabecera “Magic Number” 04 D0 FC 9C
    0x0004 chipID = “36 33 33 36 38 00 00 00” = 63368 (8Bytes)
    0x000C Padding (16 Bytes)
    0x001C ModelID = 5A596004 (4Bytes)
    0x0020 Tamaño total archivo .bin, incluído cabeceras (4Bytes)
    0x0024 Offset en Memoria rootfs (0x40000 + offset bin) | 0x40000 = Bootloader 0x20000 + romfile 0x20000
    0x0028 Tamaño Rootfs (4Bytes)
    0x00CC Offset en Memoria Kernel
    0x0030 Tamaño Kernel (4Bytes)
    0x0034 Offset en Memoria cfgfile
    0x0038 Tamaño cfgfile (4Bytes)
    0x003C ¿Magic Number?? 01 00
    0x003E Tipo de imagen | main (0x0003),  esclava (0x0002), bin de actualización (0x0001)
    0x0040 Versión Firmware (32Bytes)
    0x0060 Descripción Firmware (32Bytes)
    0x0080 Checksum Rootfs (4Bytes)
    0x0084 Checksum Kernel (4Bytes)
    0x0088 Checksum cfgfile (4Bytes)
    0x008C Padding

0x00000100 Firmware
    0x00000000 Header
        0x000 Cabecera “Magic Number” 32 52 44 48 (4Bytes)
        0x004 Tamaño de cabecera (4 Bytes)
        0x008 Tamaño de la “Firmware” incluyendo su cabecera
        0x00C checksum SquashFS, las particiones _main no llevan CRC, la firm no lo computa en cualquier caso.
        0x010 versión de 2rdh?? Termina con salto de linea (32Bytes)
        0x030 “Salto de linea”/padding (32Bytes)
        0x050 Offset squashfs/tamaño kernel (4Bytes)
        0x053 Tamaño squashfs (4Bytes)
        0x058 Padding
        
    0x00000100 Kernel, lzma
    0x0014e6e3 rootfs Squashfs 4.0 lzma | Sistema de archivos

0x011d27d6 Configuración romfile
    0x0000 Header
    0x0028 romfile comprimido.  ¿Algoritmo fastlz?

 

 Modificación/Creación de una firmware nueva

Bien, teniendo toda la estructura de la imagen de actualización, debería de ser trivial realizar cualquier cambio (añadir, eliminar, modificar) dentro de la firmware. Con linux tan sólo necesitaremos tener las herramientas para crear y extraer squashfs, teniendo en cuenta que la imagen original fue creada en SquashFS 4.0+, usando la compresión LZMA. Esto significa que si no usaron un SquasFS modificado tuvieron que usar SquasFS 4.1, 4.2 o 4.3, ya que hasta la versión 4.1 no se dio soporte oficial a LZMA. Yo lo he realizado todo con SquasFS 4.3, usando como compresor LMZA el SDK de 7zip. Es necesario eso sí, modificar el makefile para habilitar lzma.

Extraída la imagen en nuestro equipo y modificada a voluntad (o añadido los archivos/paquetes que deseemos…) volvemos a empaquetar nuestra imagen squashFS. De nuevo, recordemos que debemos de usar LZMA y realizar la creación sin el padding a 4K. Llegados a este punto, como tenemos toda la estructura de como tiene que la estructura de la imagen de actualización, tan sólo tenemos que realizar el proceso inverso y corregir todas las cabeceras que sean necesarias. Sería muy sencillo crear una pequeña utilidad que pasándole la imagen modificada, el kernel y el archivo de configuración nos crease el archivo final de actualización con todas las cabeceras corregidas. Pero ni he tenido tiempo ni tengo ganas de hacerlo. Así que sigamos.

Con la imagen SquashFS ya modificada, podemos empezar a empaquetar nuestra nueva imagen de actualización. Por suerte para nosotros, la cabecera de la sección perteneciente al kernel+rootfs no se verifica en ningún momento, y aunque podemos por supuesto calcularla, no es necesario ser muy rigurosos. La parte más tediosa es el cálculo del checksum, así que podemos establecerlo tan ricamente como “00 00 00 00” y no pasa nada.

Añadimos al final de la imagen squashfs el archivo de configuración previamente extraído de la imagen inicial. Añadimos encima de este el kernel, y encima del kernel la cabecera secundaria. No es necesario, pero por tener un mínimo de decencia corregimos en esta el tamaño de la “firmware” (que es el tamaño de la cabecera secundaria+kernel+squashFS), el checksum no nos complicamos y lo dejamos en 00 00 00 00, el offset de squashfs no ha cambiado con lo que lo dejamos igual y modificamos el nuevo tamaño que tiene nuesetra imagen squashfs (ahora sí, tan sólo el tamaño de nuestro squashfs modificado)

Por último queda realmente lo que es más delicado, que es reconstruir realmente la cabecera que va a judgar si nuestra firmware es válida, por no decir que si metemos la pata siempre podemos bloquear e inutilizar el router, así que cuidado aquí. Los valores a modificar en realidad son pocos, si tan sólo hemos tocado el sistema de archivos:

    0x0020 Tamaño total archivo .bin -> Es necesario modificarlo porque el tamaño de nuestro squashFS será diferente
    0x0028 Tamaño Rootfs -> El valor es el mismo que se puso en la cabecera secundaria, y hay que modificarlo por lo mismo que el anterior
    0x0034 Offset en Memoria cfgfile -> Al cambiar el tamaño del rootfs, el offset del archivo de configuración cambia. Recordemos que hay que sumar siempre 0x40000
    0x0080 Checksum Rootfs (4Bytes) -> Que checksum??

Bien, tenemos todo menos el checksum de rootfs, el resto son los mismos porque no hemos realizado ninguna modificación. La pregunta del millón es como diablos calcula Mitrastar este valor, puesto que ha podido usar cualquier técnica conocida o desconocida. La mala noticia es que usa un algoritmo propio para calcularlo, la buena noticia es que ya lo tengo recreado, y la mejor noticia es que incluso nos podemos ahorrar su cálculo si sabemos donde mirar (una pena que descubriese esto último más tarde, pero al menos tengo igualmente el algoritmo.

El checksum usado por Mitrastar es una modificación al conocido CRC32, usando una lockup table para agilizar los cálculos, y podemos encontrarlo en el binario cfg_manager. Se puede buscar la función y decompilarla. Es necesario este valor porque el bootloader y el propio cfg_manager comprobarán dicho valor, y si no corresponde al que ellos calculan, el router rechazará dicha imagen. No sólo se usa este checksumo para verificar la firmware, igualmente se verifican tamaños y otros, pero ya hemos dado por supuesto que la cabecera la hemos calculado bien.

Bien, he dicho que aunque tengo creado el algoritmo para calcular el crc32 modificado no es necesario. Esto es porque por suerte para nosotros ya lo calcula el cfg_manager por nosotros. Cuando actualizamos el router (o lo intentamos), justo antes de que este se reinicie (sea la firmware válida o no) escupe en la consola de registro los cálculos pertinentes, sacando por pantalla los checksum calculados y los que tenemos en nuestra firmware. Dicho de otro modo… si actualizamos aun con la cabecera con los checksum incorrectos, y mientras esta el proceso miramos el registro con dmesg, obtendremos algo como esto:

***** MitraStar Confidential Firmware *****
compressedLen = 25194
pTag->kernelChksum = 11b8cc8b
pTag->rootfsChksum = da3878fa
pTag->defcfgChksum = 35842e0b
cal kernelChksum = 11b8cc8b
cal rootfsChksum = da3878fa
cal defcfgChksum = 35842e0b

pTag->modelId = 5a596004
pTag->chipId = 63368
len = 011d8a68
mrd->modelId = 5a596004
mrd->chipId = 63368

Update slave image version

Ready to flash image…

Si los checksum calculados no se corresponden a los nuestros, el proceso fallará, pero podremos anotar el crc calculado, modificar los nuestros para que correspondan y volver a actualizar. Eso le quita a cualquiera tener que decompilar el código en cfg_manager, extraer el algoritmo de verificación y recrearlo en C o en el lenguaje que le guste. Por supuesto el echo de que se calcule el CRC no hay que verlo sólo como para impedir que se realicen modificaciones, sino para garantizar la integridad de estas y evitar una mala actualización.

Si todo ha ido bien, el cfg_manager copiará la imagen de actualización a 4 particiones esclavas, mtd6-9, cada una con su contenido. Al reiniciar el router, el bootloader realizará comprobaciones similares a las realizadas por cfg_manager, y si todo es correcto procederá a copiar las particiones esclavas mtd6-9 a las principales mtd2-5. Si el router se reiniciase (funcionando) sin aparentemente ningún cambio efectuado, posiblemente el bootloader encontró algún problema en la firmware modificada y anuló la copia a las particiones principales, con lo que habría que ver el problema, solucionarlo y volver a cargarla.

Si todo ha sido correcto, llegados a este punto, tendríamos nuestra propia firmware modificada con lo que necesitásemos, ya fuesen arreglos de los problemas que tiene la firmware oficial o nuestros propios añadidos.

Recordemos que dije que no es necesario tener una imagen de actualización. Podemos extraerla a partir de las particiones mtd5 o mtd9, tan sólo con una apreciación: Las particiones mtd5 y 9 estarán posiblemente padeadas para rellenar el resto del erasesize, con lo que hay que eliminar dicho bloque. Por otro lado hay que modificar un byte en la cabecera que especifica el “tipo de partición”. El archivo de actualización tiene que estar en 01, no en 02 o 03. Quitando estos dos cambios, el resultado será una copia 1:1 (exacta) del archivo de actualización original. No es mal truco después de todo.

 

¿Instalación/Actualización de componentes y otros paquetes?

Ahora mismo no he añadido ningún componente extra, pero es más que factible. Hay que tener en cuenta que el router usa una arquitectura MIPS, y que tendríamos que recompilar cualquier paquete o binario para esta arquitectura. Aquí la idea he de decir que no fue mía y me llegó leyendo a un blogero en algún lado, y es que el router usa uClibc como motor, y el proyecto uClibc posee por suerte para nosotros imágenes listas para iniciar desde linux en las que podremos tener las herramientas necesarias para compilar el códígo y paquetes que deseemos, y una vez realizado sacarlo de ahí y meterlo en nuestra firmware modificada:

http://www.uclibc.org/downloads/binaries/0.9.30/


 

Conclusión

Bien, creo que eso ha sido todo. Sin duda alguna un buen entretenimiento del que siempre se aprende, y yo el primero. Quizás lo más útil en este caso no es instalar paquetes o actualizar otros (al menos en principio), pero puede que sí lo sea el poder realizar pequeños cambios aquí y allá, instalar algunos binarios extras como tcpdump, aplicar configuraciones específicas, filtros… tenemos espacio en memoria de sobra a fin de cuenta, y posiblemente tardemos nosotros mismos menos tiempo en corregir algunos de los problemas de la firmware, que esperar que Mitrastar los arregle por nosotros y que Movistar la distribuya.

Por ejemplo, para corregir el problema de la batería de los ARP en la B21, bastaría en principio con hacer el siguiente cambio permanente:

echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit

Aunque como digo, tan solo es un ejemplo más…

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

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