El viernes 29 de marzo, mientras realizaba tareas de rutina, un ingeniero de Microsoft descubrió, con una mezcla de suerte y buen olfato, uno de los ciberataques más sofisticados de la historia directo al corazón de Linux. Un ataque que literalmente ponía al mundo entero en peligro. Y no estoy exagerando.
Porque de haberse completado, los atacantes habrían tenido acceso a infraestructuras de bancos, de gobiernos, de los mayores proveedores de Cloud Computing o de las empresas más poderosas del mundo. Porque habrían tenido el control de Linux, y Linux es el sistema operativo más usado del mundo (y sí, ya sé que Linux es un kernel y no un Sistema Operativo 🙄. Suéltame el brazo).
Pero lo más sorprendente de esta historia, no es el daño que hubiera causado el ataque, sino que fue planificado y elaborado minuciosamente durante años sin que nadie lo notara y aparentemente financiado por un gobierno. ¿Quién podrá ser?
Esta historia lo tiene todo: un plan macabro de 3 años para dominar el mundo, una persona que por casualidad descubre una conspiración mundial y la detiene, un programador acosado psicológicamente para que entregue los accesos de su proyecto y una red mundial de héroes anónimos que salvan el mundo sin que nadie se entere y sin recibir reconocimiento. Es Misión Imposible pero en versión programadores.
Así que en este blog, te contaré toda la historia y no te preocupes si no eres programador y no entiendes mucho de tecnología, porque lo explicaré con manzanitas para que todos lo puedan entender. Porque tu sabes que en español, #EDteamExplicaMeejor.
1. ¿Cómo pudieron hackear Linux si es el sistema más seguro?
Es cierto que Linux es, probablemente, el sistema más seguro que existe. Y es por eso que los atacantes no apuntan al kernel. Es decir, al núcleo de Linux, porque es imposible meterse ahí. Sino que usan una técnica llamada “Ataque a la cadena de suministro”, que significa atacar algún componente o librería que no es parte del núcleo pero es muy usado dentro del sistema y no tiene los mismos controles de seguridad.
Es más, suelen estar mantenidos por desarrolladores independientes, que no reciben ni un centavo por su trabajo y lo hacen como pasatiempo. Y no exagero, porque ya hemos visto esto antes, los dos casos más sonados fueron el de Heartbleed de 2014 y Log4Shell en 2022. Y en ambos casos se trató de vulnerabilidades en librerías específicas que le daban a los atacantes acceso al sistema. Esas librerías eran usadas por empresas millonarias, pero mantenidas por un pequeño grupo de desarrolladores, sin un pago y haciéndolo por puro hobby. Y en el caso del que vamos a hablar en esta oportunidad, la librería atacada fue liblzma, que es parte de XZ Utils.
XZ Utils es un conjunto de herramientas de compresión de archivos disponible en Linux, Mac y Windows. A diferencia de otras opciones como zip, gzip o tarball, XZ usa un formato de compresión sin pérdida por lo que es ampliamente usado en Linux para comprimir y distribuir paquetes de software o imágenes del kernel.
¿Una librería muy usada en los sistemas Linux, sin actualizaciones por 7 años y mantenida por una sola persona en sus ratos libres? Suena a la receta perfecta para un ataque a la cadena de suministro. Solo faltaba el lacito de regalo.
2. ¿Cómo se llevó a cabo este ataque?
Ya tenemos el objetivo: XZ Utils, un conjunto de herramientas muy usado en las distribuciones Linux y con un solo mantenedor.
Pero, pero, pero…. Aunque sea una sola persona quien mantenga el proyecto, la cantidad de capas por las que hay que pasar para llegar al objetivo final, que es meterse en una distribución Linux, hacen que sea prácticamente imposible. Entrar a la librería sería solo burlar al vigilante en la puerta mientras los jefes están dentro del edificio.
Porque primero tienes que conseguir que el mantenedor te apruebe los cambios, cambios con código malicioso pueden ser detectados en un santiamén. Y suponiendo que lo consigas, esos cambios tienen que enviarse a los repositorios oficiales, luego, ser implementados en las distribuciones de Linux en sus fases iniciales y sobrevivir hasta la fase de producción de esas distribuciones que es cuando al fin son lanzadas a la comunidad tecnológica.
Es como La casa de papel versión programador. ¡Pero SÍ lo lograron! Con un plan magistral que duró, agárrate, más de tres años.
El cerebro maestro detrás de este ataque es una persona (o un grupo, porque se desconoce su identidad) con el nombre Jia Tan. El programador Evan Boehs se dio el trabajo de hacer de detective y unir los pedazos para contar la historia completa de Jia Tan en su blog. Historia que comienza en 2021. Déjame explicartelo:
2021
El 2 de noviembre de 2021, el usuario de Github JiaT75 (Jia Tan) envió un Pull Request al proyecto libarchive. Lo curioso aquí es que su contribución agregaba código inseguro a la librería y fue fusionado a la rama principal sin discusión, es decir, que nadie se dio cuenta. Este cambio pasó años sin detectarse y se ha parchado solo después de descubrirse el ataque a XZ Utils.
Lo más probable es que Jia Tan hizo este Pull Request para probar que tan fácil, o que tan difícil, era insertar código inseguro o malicioso en un proyecto Open Source.
2022
Es en 2022 cuando empieza el ataque coordinado, pues Jia Tan envía un parche para XZ. El contenido del parche no era muy importante pero lo que sigue después, sí lo es.
Luego de enviado el parche, aparecieron dos usuarios que empezaron a presionar a Lasse Collin, el mantenedor oficial del proyecto para que apruebe el parche diciéndole cosas como:
*Fecha: 27 de abril de 2022. *
No testeé tu código pero si funciona supongo que solo necesita ajustes menores en el formato. Tus esfuerzos son buenos (le dice a Jia Tan) pero basado en el lento calendario de lanzamientos, pasarán años hasta que la comunidad obtenga esta feature. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00555.html)
Jia Tan responde:
Fecha: 28 de abril de 2022
Agradezco tus comentarios. La próxima versión debe salir este año, no creo tarde tanto como tú dices. Quienes contribuyen al proyecto lo hacen como pasatiempo y no podemos esperar que le dediquen 40 horas a la semana para hacer lanzamientos rápidos y de alta calidad. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00556.html)
Jigar contesta, echando más leña al fuego:
Fecha: 28 de abril de 2022.
Los parches se quedan años en esta lista. La versión 5.2 fue de hace 7 años, así que no hay motivo para pensar que algo vaya a cambiar pronto. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00557.html)
Luego pasa un mes sin novedades en la lista y el 27 de mayo, Jigar dice:
Fecha: 27 de mayo de 2022
Va a ser un mes y ni cerca de fusionarse. No me sorprende. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00565.html)
Casi un mes después, el 22 de junio, Jigar vuelve a escribir:
Fecha: 22 de junio de 2022
Hola, ¿hay algún progreso en esto? Jia, veo que tienes cambios recientes. ¿Por qué no puedes encargarte de esto tú mismo? (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00570.html)
Hasta ahí llega este hilo de correos. Que, a mi modo de ver, son perfectamente coordinados: un usuario desconocido envía un parche a un proyecto sin mantenimiento (porque es un proyecto estable), luego aparece otro usuario desconocido para agradecer al primero y decirle que no espere nada. Y las fechas son demasiado coordinadas.
Días después, otro usuario, también desconocido, aparece en la lista de correo de XZ para Java:
Fecha: 19 de mayo de 2022
¿Aún se mantiene este proyecto? Hice una pregunta aquí hace una semana y no he recibido respuesta. Y cuando veo el registro de Git, me doy cuenta que no ha sido actualizado en más de un año. (Texto:https://www.mail-archive.com/xz-devel@tukaani.org/msg00562.html)
Lasse Collin, el mantenedor del proyecto, responde:
Fecha: 19 de mayo de 2022
Sí, si alguien informa de un error me encargo de arreglarlo. Pero el desarrollo de nuevas funciones definitivamente no es muy activo. :-( Jia Tan me ha ayudado con XZ Utils y podría tener un mayor papel en el futuro. Está claro que mis recursos son demasiado limitados y por eso tengo muchos correos sin responder. Espero poder cambiar eso a largo plazo. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00563.html)
¿Lo vieron? Jia Tan, el hacker boss de esta historia, se está ganando la confianza del mantenedor del proyecto.
Días después, regresa Jigar (el que envío el primer parche) y ataca directo al corazón:
Fecha: 7 de junio de 2022
No habrá progreso hasta que no haya un nuevo mantenedor. Dennis (le está hablando al que abrió el hilo, ignorando completamente a Collin), es mejor que te esperes a que aparezca un nuevo mantenedor o tú mismo te conviertas en mantenedor. Enviar parches aquí no tiene ningún sentido porque al mantenedor actual ya no le interesa mantener. Es triste ver un repositorio como este. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html)
Auch. Y logró su objetivo porque el siguiente mensaje de Collin lo deja vulnerable y fácil de atacar.
Fecha: 7 de junio de 2022
No he perdido el interés pero mi capacidad de atención ha sido bastante limitada principalmente por problemas de SALUD MENTAL y otras cosas. Recientemente trabajé un poco fuera de esta lista con Jia Tan en XZ Utils y quizás tenga un papel más importante en el futuro. Ya veremos. También tengan en cuenta que se trata de un proyecto de hobby no remunerado. (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html)
Lo consiguieron, derrumbaron al hombre que ahora prefiere cederle el mantenimiento del proyecto a Jia Tan para cuidar su salud mental. El burnout en el mundo de la programación es real y terrible. Y si se le suma el estrés personal y de proyectos secundarios, la combinación es explosiva.
Entonces, Jia Tan vuelve a atacar y le dice:
Fecha: 14 de junio de 2022
Con el ritmo actual dudo mucho que veamos un nuevo lanzamiento este año. Ignoras los muchos parches que se están pudriendo en esta lista te de correo. Ahora mismo estás ahogado en tu repositorio. ¿Por qué esperar a la próxima versión para cambiar de mantenedor en vez de hacerlo ahora mismo? (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00568.html)
Y Dennis Ens le dice:
Fecha: 21 de junio de 2022
Lamento tus problemas de salud mental pero es importante ser consciente de tus propios límites. Entiendo que es un proyecto de hobby pero la comunidad quiere más. ¿Por qué no pasas el mantenimiento a otra persona? (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.html)
El siguiente mensaje de Collin demuestra que se logró el objetivo:
Fecha: 21 de junio de 2022
Encontrar otro mantenedor es algo que ha estado en mi mente mucho tiempo. Y como insinué en correos anteriores, Jia Tan puede tener un papel importante en el futuro. Ha estado ayudándome fuera de esta lista de correo y prácticamente ya es un co-mantenedor :-) (Texto: https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html)
Y manda una carita feliz al final. Una persona estresada, con problemas de salud mental que cree haber encontrado al fin a quien lo ayude. Esto es demasiado.
Y lo consiguieron porque 3 días después se aprobó el primer commit de Jia Tan en XZ Utils y automáticamente Jigar y Dennis desaparecen del mapa. Nunca más escriben en la lista de XZ ni en ninguna otra. ¿Coincidencia? No lo creo.
2023
El 7 de enero de 2023, Jia Tan fusiona su primer commit (él mismo), lo que demuestra que se había ganado la confianza suficiente para tener esos privilegios y en marzo cambia el correo principal del proyecto del de Collin al suyo.
Con el control del proyecto, Jia Tan empieza a incrustar código malicioso. Primero, un usuario con el nombre Han Jansen envía un commit que Jian Tan aprueba y en julio se envía otro PR que supuestamente corregía un problema con el commit anterior. Pero que en realidad estaban preparando el terreno para introducir el código malicioso.
2024
Y por último, a finales de febrero de este año se agregó el código con los pasos finales del ataque. Dicho código estaba lo suficientemente ofuscado para que sea muy difícil detectarlo.
Este código malicioso creaba una puerta trasera capaz de secuestrar conexiones remotas con SSH. El objetivo es que esta versión infectada se publique en las versiones finales de Debian y Red Hat, las dos distribuciones de Linux más usadas a nivel empresarial.
Pero justo antes de que ocurra, un ingeniero de Microsoft, con 50% de talento y 50% de suerte, les arruinó 3 años de planes.
3. ¿Cómo se descubrió el ataque?
Cuando ya todo estaba listo para lanzar el ataque a nivel masivo, este fue descubierto de la forma menos esperada. Para que te hagas una idea, es como si un detective con muchos años de experiencia fuera al hospital y notara que la enfermera le hace un gesto extraño al saludarlo. Un simple gesto que para todo el mundo pasaría desapercibido pero él, con su experiencia, huele que algo anda mal. Empieza a investigar y encuentra una red mundial de tráfico de órganos que opera en los principales hospitales del mundo. Y todo, a partir de un gesto de la enfermera.
¿Suena exagerado? Pues exactamente así fue como un ingeniero de Microsoft descubrió este ataque.
Andres Freund, ingeniero de Microsoft que trabaja en el desarrollo de Postgres y que ahora ha pasado al nivel de leyenda, estaba realizando pruebas de rutina y vio algunas cosas raras como que el inicio de sesión con SSH consumía más CPU y memoria de lo normal y que demoraba mucho tiempo.
Volviendo aquí. ¿Cuánto más se demoraba SSH y por qué este ingeniero decía que es mucho tiempo? ¿Eran segundos? ¿Minutos? ¿Horas? No. Solo 5 décimas de segundo más. No 5 segundos, 5 décimas de segundo.
Link: https://www.openwall.com/lists/oss-security/2024/03/29/4
¿Ahora entiendes la metáfora de la enfermera?
Empezó a tirar de la cuerda y llegó a la librería libzma parte de XZ Utils y descubrió una puerta trasera tanto en el repositorio original como en los tarballs distribuidos (los que se incluyen en los sistemas operativos).
Esta puerta trasera se activaba al compilar XZ en sistemas Linux, especialmente Debian y Red Hat y el inicio de sesión con SSH es 0.5 segundos más lento porque el código malicioso se inyecta en el momento.
Lo primero que hizo Freund cuando lo descubrió fue dudar: ¿acabo de descubrir una puerta trasera en Linux? ¿En las dos distribuciones más usadas por empresas en el mundo? ¿A solo días de su lanzamiento oficial? ¿He descubierto una conspiración mundial? ¿Acabo de detener un ciberataque de escala mundial? Reconócelo, es difícil creértelo.
Pero la evidencia estaba ahí, así que publicó sus hallazgos en la lista de correo OSS-Security, uno de los foros más importantes en temas de seguridad de software Open Source y en su cuenta de Mastodon. Correo: https://www.openwall.com/lists/oss-security/2024/03/29/4
Cuando la comunidad de desarrolladores conoció el caso, se encendieron las alertas, la cuenta de Jia Tan en Gihub fue suspendida (por él mismo y desapareció del mapa), se desactivó el repositorio de Github y la página oficial del proyectoy Lasse Collin, que solo quería descansar un poco por su salud mental tuvo que ponerse a revertir los cambios contra reloj. Puso la página del proyecto en construcción y dejó este mensaje diciendo que para saber novedades, deberían recargar la página cada 48 horas.
Link: https://tukaani.org/xz-backdoor/
Hasta ahora no se sabe la identidad de Jia Tanni si es una persona, un grupo o un gobierno, aunque según Costin Raiu, exjefe de seguridad de Kapersky, por la meticulosidad, el tiempo invertido y las capacidades técnicas del ataque, puede ser un grupo respaldado por un estado como China, Rusia o Corea del Norte.
Además, que según los commits, gran parte del trabajo se hacía en horario laboral, de 9 a 5. Así que eran personas que recibían un pago por esto.
Como anécdota, en 2016, Víctor Buso, un argentino aficionado a la Astronomía, estaba probando su nueva cámara en su telescopio y capturó el nacimiento de una supernova. Un hallazgo nunca antes visto e increíble para la comunidad científica y que tuvo mucho de estar en el lugar correcto y en el momento correcto. Tal como pasó con Andres Freund y este ataque a Linux.
4. ¿Cómo funciona la puerta trasera y que medidas se tomaron?
¿Y qué hacía esta puerta trasera y por qué era tan peligrosa? Como ya te expliqué, una puerta trasera consiste en dejar una puerta secreta en un sistema para que los atacantes ingresen. Y Linux es el sistema operativo en el mundo. Así que la combinación es explosiva.
Y considerando el meticuloso trabajo de 3 años que les tomó a los hackers construir esta puerta trasera, de haber tenido éxito podrían haber estado años sin ser detectados y haciendo lo que les dé la gana en servidores de cloud computing, empresas gigantes, bancos o servidores gubernamentales.
Podían hacer, literalmente, lo que quisieran, desde corromper sistemas, robar información, espionaje, manipular el mercado o iniciar una guerra. Y nos salvamos por un pelito.
El desarrollador Thomas Roccia ha publicado esta infografía con la explicación detallada del funcionamiento de este backdoor y es impresionante.
Link: https://infosec.exchange/@fr0gger/112189232773640259
En el área superior de la infografía, vemos un resumen de lo que ya hablamos en este blog. Que se inyectó una puerta trasera en XZ Utils y que fue descubierta por Andres Freund el 29 de mayo. La siguiente sección muestra una línea temporal de las acciones de Jian Tan (que también hemos visto en este blog).
La siguiente sección, explica que al compilarse XZ Utils se ejecuta automáticamente el script malicioso build-to-host.m4 que estaba escondido en el código. Este script verifica ciertas condiciones, como la arquitectura del sistema y si se está construyendo un paquete para Debian o Red Hat. Si eso se cumple, vamos al siguiente paso.
Dentro del código de XZ Utils había dos archivos de prueba, los que se usan para probar la calidad del código. Estos pasaban por inofensivos pero de una forma demasiado ingeniosa, se convertían en archivos maliciosos con tan solo cambiar algunos caracteres. Así que el primer script convertía a un archivo de prueba en otro script malicioso y este a su vez convertía al segundo archivo de prueba en otro script malicioso.
Así que los hackers tenían una doble capa de seguridad para esconder su código y que no sean descubiertos.
Con el último script se crea el objeto maclicioso liblzma_la_crc64-fast.o que se incluye en el proceso de compilación de liblzma.
Este objeto busca archivos específicos para comprobar en qué sistema se está ejecutando. Si encuentra estos archivos, bingo, puede activarse y secuestrar conexiones SSH.
La puerta trasera, ha sido abierta.
Lo interesante es que liblzma no se conecta directamente con SSH sino que hay distribuciones de Linux que usan un parche de OpenSSH que se conecta a systemd-notify, que es una herramienta que lanza notificaciones para iniciar otros servicios cuando se inicia la conexión ssh. De esta manera se inicia libsystemd, que es una herramienta que controla a otros servicios y es quien carga a liblzma.
El siguiente paso es que liblzma utiliza la función de C ifunc para redireccionar las claves de autenticación de SSH y dárselas al hacker. Esto porque ifunc es la función que SSH utiliza para comunicarse con la herramienta que encripta las claves.
La cantidad de detalle es impresionante.
Si tu equipo usa las versiones 5.6.0 y 5.6.1 de liblzma, debes actualizar automáticamente. También puedes revisar si tu equipo está comprometido en esta página: Binarly XZ backdoor detector.
O con este protocolo xzbot: https://github.com/amlweems/xzbot.
Y algo más impresionante es que le pregunté a Claude como se podría crear un backdoor a SSH usando liblzma, cuando no hay una conexión directa entre ambos componetes y me dijo casi lo mismo que se hizo en este caso. Impresionante.
Pero como les decía, Andres Freund, el ingeniero de Microsoft que descubrió el problema y evitó un ciberataque de escala mundial ha pasado al nivel de leyenda entre la comunidad de desarrolladores. Su prestigio ha sido tal que el mismísimo Satya Nadella, CEO de Microsoft, lo premió. ¿Con qué lo premió? Con un tweet. ¿Mínimo un cheque no?
Son la empresa más valiosa del mundo. O sea, entiendo que el hecho de que el CEO de una empresa con miles de empleados te mencione directamente y te felicite públicamente es muy gratificante, pero se me hace poquito.
Aunque también entiendo que los equipos de seguridad de Microsoft están conformados por muchas personas resolviendo problemas y mitigando ataques (muchos de ellos muy graves) y que quizás este caso no parezca tan relevante a primera vista.
Pero el suceso me hace pensar en el problema de fondo: la cantidad de desarrolladores que sin reconocimiento y sin pago son los que hacen que Internet y el ecosistema de software funcione.
Estos héroes anónimos no reciben un pago ni reconocimiento y cuando ocurre un problema les toca pasar noches sin dormir, corriendo por corregir algo de lo que muchos se benefician y recibiendo tan solo palmaditas en la espalda. Mientras, como ya vimos, sufren estrés y problemas de salud mental.
Por ejemplo, en 2014, se descubrió una de las más grandes vulnerabilidades de la historia: Heartbleed. Un problema en OpenSSL, la librería que permite tener HTTPS en nuestros sitios web,
Si no sabes qué es HTTPS, tenemos un video en nuestro canal de Youtube, con la mejor explicación en español: ¿Qué es y cómo funciona HTTPS?
Heartbleed permitía que un atacante extraiga información privada del servidor. ¿Y qué pasó? Los mantenedores del proyecto corrieron para corregirlo. Prácticamente salvaron el mundo de gratis.
Ese mismo año se creó la CCI (Core Infrastructure Initiative) que buscaba recaudar dinero para financiar a los proyectos Open Source claves para el funcionamiento de la tecnología a nivel global. Sonaba muy bien pero desapareció en 2020 y se reemplazó por la OpenSSF (Open Source Security Foundation) que se ocupa de muchas cosas, entre ellas, ahí al fondo de todo, el financiamiento.
Hace dos años se hizo famoso el caso de un desarrollador que corrompió sus propias librerías y fue baneado de github por eso, pidiendo que las empresas que usen su trabajo o les paguen o que hagan un fork y que mantengan ellas mismas su fork. Te contamos toda esta historia en nuestro video de Youtube: Un dev corrompió sus librerías Node.js y afectó a miles de proyectos en GitHub | #EDchismes
Y también en 2022 se descubrió la peor vulnerabilidad de la historia de Java: Log4Shell, que permitía a los atacantes tomar el control del sistema y que alcanzó un pico de ¡24600 ataques por minuto! ¿Y qué creen? Los mantenedores de la librería Log4J eran programadores que usaban su tiempo libre para desarrollarla y que se pasaron 3 días sin dormir parchando el problema (y recibiendo mensajes de odio). Conoce toda la historia en nuestro video de Youtube: Log4jshell, la vulnerabilidad en Java que puso en peligro a medio internet | #EDchismes
Es una tema complejo que no se puede solucionar con un blog, pero al menos podemos ser útiles para impulsar la toma de conciencia sobre la cantidad de héroes anónimos soportando internet. Tal como esta imagen de xkcd, toda la infraestructura digital moderna está mantenida por un tipo cualquiera en Nebraska. O en Latinoamérica.
Link: https://xkcd.com/2347/
Y para terminar, la otra reflexión de este caso es que demuestra nuevamente la importancia de los programadores humanos en el mundo digital en el que vivimos. Ni siquiera tengo que explicarte por qué la Inteligencia Artificial no habría podido hacer nada en esta situación. Lo que sí podría recordarte es la cantidad de vulnerabilidades que puedes dejar en tu sistema si tu estrategia es copiar y pegar de ChatGPT y repetir como loro que la programación se acabó porque tú sin saber programar ya creaste un tres en raya.
¿Tú qué opinas?
Si este blog te gustó, síguenos en nuestras redes sociales para que la cantidad de horas y las noches sin dormir invertidas investigando hayan valido la pena. Tenemos toda esta explicación también en nuestro canal de Youtube. No te olvides de compartir esta información con todos tus conocidos para que se enteren que en español, #EDteamExplicaMejor.
Y cuando te pregunten como sabes tanto sobre el hackeo a Linux, responde que #LoAprendisteEnEDteam.
Y visítanos en ed.team para que aprendas programación e inteligencia artificial con las mejores explicaciones en español. Recuerda que puedes ver gratis las primeras clases de cualquier curso para que descubras por ti mismo por qué en español, EDteam explica mejor.