25 noviembre 2014

Posible intrusión y fuga de datos en Sony Pictures Entertainment.


Aunque ya han pasado 3 años desde la guerra que mantuvo Sony con Geohot, Lulzsec y centenares de anonymous, parece que le siguen apareciendo cadáveres en los armarios. En este caso, uno realmente grande, ya que según informó "el amigo de un empleado" de la compañía, los trabajadores veían una imagen en pantalla con una terrible amenaza

Mediante una nota en Reddit se da a conocer lo que parece una escandalosa intrusión en la compañía Sony Pictures Entertainment realizada por un grupo autodenominado #GOP o "Guardians of Peace" y en la que reclaman que se cumplan sus requisitos o publicarán sus secretos. Como prueba, publican dos ficheros, "list1.txt" y "list2.txt", con la información que han robado. 

Aun no se conocen muchos más detalles, salvo que a los empleados se les ha solicitado apagar sus equipos, desactivar la wifi de sus móviles y, a algunos de ellos, volver a casa.

Si el listado de ficheros es real (y lo parece), Sony Pictures tendrá un problema muy muy serio, ya que contiene miles de archivos que, por el nombre, parecen muy comprometedores. Personalmente me parece imposible que esta cantidad de información vea la luz, si lo hace, seguro que supone el cierre de la compañía.

Imagen de #GOP

También se ha visto en Twitter alguna cuenta hackeada.

Cuenta de twitter comprometida

Como decía, en los listados de archivos hay cosas muy interesantes y ahora voy a poner unos cuantos ejemplos que me han llamado la atención. A tener en cuenta que en total hay más de 37.937.159 de ficheros y que muchos de ellos llevan el día, mes  y el año en el título, por lo que parece que son realmente actuales, por ejemplo:

list2.txt:LBL_2014-11-27_LBL BLACK FRIDAY PROMO_v1.xlsb
list1.txt:Bill Backup 2014-11-01.xls
list1.txt:Closer - Icarus Prods tolling 2014-11-20.pdf

Como sé que os gustan los detalles y aquí no estamos para repetir lo que se lee en todas partes, vamos a ver un poco de sangre.

Sony y su preocupación por la piratería (pequeño ejemplo):

list1.txt:Netflix Is Killing BitTorrent in The US _ TorrentFreak.pdf
list1.txt:Torrent Spy Damages List.xls
list1.txt:Article- Hollywood Studios Fuming Over BitTorrent, Cinedigm 'Deal With the Devil'-TheWrap-4-24-13.doc
list1.txt:Article-File-Sharers Will Not Be Held Liable For Piracy, Russia Says-Torrentfreak-4-8-13.doc
list1.txt:Article- Operator of Germany's Torrent.to Gets Prison Sentence Amid Piracy Crackdown-THR-5-6-13.doc
list1.txt:Article-France Set To Dump 3 Strikes Anti-Piracy Law But Automated Fines Will Live On-TorrentFreak-5-14-13.doc
list1.txt:MASTER TORRENT STATS SHEET_021712.xlsx
list1.txt:extratorrent.021910.vs.doc
list1.txt:torrenthandler.040910.vs.doc
list1.txt:CONF-BitTorrentDistAgmt.doc
list1.txt:15_RE_ Sony Classics on torrent sites.pdf
list1.txt:TORRENT INCIDENT DEC 2011.docx
list1.txt:Training-bittorrent.ppt
list1.txt:DMCA 10.22.07 extratorrent - SPC.pdf
list1.txt:Korea torrent site action - Sony Pictures title list.xlsx
list1.txt:Torrentz titles - MS.xlsx
list1.txt:6.25.13 BitTorrent litigation MPA call notes.docx
list1.txt:DMCA 10.22.07 extratorrent - SPC.doc
list1.txt:TorrentIncident_121311_A.docx
list1.txt:BitTorrent Issues 07.17.06.doc
list1.txt:Sony-BitTorrent ODRL Distribution Agreement (OD2) HOLD ON THIS VERSION.doc
list1.txt:LokiTorrent Settlement Agr-02-08-05.pdf
list1.txt:BitTorrent ODRL Distribution Agreement (5.12.06).doc
list1.txt:The Pirate Bay - The galaxy's most resilient bittorrent site.pdf
list1.txt:CPII & TSP Verifications - TorrentSpy.pdf
list1.txt:TorrentSpy Stats Study (Sony Titles).xls
list1.txt:TorrentSpy Decl. - SPE 11.29.pdf
list1.txt:MTORRENTEMIP-TV.DOC
list1.txt:BitTorrent-Garfield-2-09-05.DOC
list1.txt:Torrentspy Pleadings.doc
list1.txt:Torrentspy Discovery.doc
list1.txt:TorrentSpy_Parker_POC_TriStar_012809.pdf
list1.txt:Bittorrent Blocking Meeting.pptx
list1.txt:Bittorrent-Emule Report -2012-02-21 thru 2012-02-27.pdf
list1.txt:Bittorrent Report - 2012-04-15 thru 2012-05-15.xlsx
list1.txt:torrentz 3.13 vs.doc
list1.txt:torrentreactor 7 15 vs.doc
list1.txt:torrentreactor net 11 19 vs.doc
list1.txt:02.06 torrentmatrix.vs.doc

Aunque como siempre... Luego pasa lo que pasa (una muestra de lo que hay):

list2.txt:vmware3_keygen.zip
list2.txt:keygen.exe
list2.txt:Final_Draft_7.0.0.40_Keygen.zip
list2.txt:Writers.Cafe.v1.20.WinALL.Incl.Keygen-ViRiLiTY.zip
list2.txt:Corel Draw X5 with Keygen.lnk
list2.txt:Keygen.exe


Unos cuantos de los centenares de ficheros de documentación compartida con SGAE:

list1.txt:Complete SGAE list from ACCESS Tables 20110624.xlsx
list1.txt:sgae-pc-mar09-sony.xlsx
list1.txt:SPAIN - SGAE.docx
list1.txt:Copy of sgae-bo-dec09-sony.xlsx
list1.txt:es-sgae-catalogue November 2010-sony.xlsx
list1.txt:SGAE Access query.docx
list1.txt:sgae-rl-jun10-sony-FINAL-sent 11-18-2010.xlsx

Documentos de seguridad (pequeña muestra):

list1.txt:IT Production Security Guidelines MPP v 1_32.docx
list1.txt:Susan Email - Fw_ Security Penetration Test - 11-17-06.pdf
list1.txt:Penetration Test I.pdf
list1.txt:Onapsis NDA for SAP Penetration Test 2-1-2012.pdf
list1.txt:Sony Pictures Physical Penetration Test.xls
list1.txt:Japan penetration testing SPE results.xls
list1.txt:DDoS 2010 notes.docx
list1.txt:DDoS 2010.docx
list1.txt:DDOSS_Audit_10112006.xls
list1.txt:Akamai Kona-DDOS Quote 10-23-2012.docx
list1.txt:Web Application Penetration Test.doc
list1.txt:Penetration Test Request Form- SISC.doc
list2.txt:SPE - SAP Penetration Testing - Technical.zip
list1.txt:Access Info for Web App Vuln Zip Files - from PenTester 4-26-2010.docx
list1.txt:IT Production Security Guidelines v 1_41 12 21 11.pdf
list1.txt:RSIG SECURITY - PO 1273.pdf
list1.txt:Weekly Audit and Security Log Review for Solaris - 1-5-07.pdf
list1.txt:Aaron Email - Network Security - Document Request - 9-25-06.pdf
list1.txt:Counterpoint - Data Protection  Information Security Rider 7-11-2013 (2).docx
list1.txt:VM - Bash_Exploit - CVE_2014_7169.xlsx
list1.txt:VM - Bash_Exploit - CVE_2014_7169 v1.xlsx
list1.txt:VM - Bash_Exploit - CVE_2014_7169 - Rajesh.xlsx
list1.txt:VM - Bash_Exploit - CVE_2014_7169 - Sept 30 Status.xlsx
list1.txt:cve-2014-0160 v2.xlsx
list1.txt:McAfee Internet Anti-virus.doc
list1.txt:McAfee AV Renewal.pdf
list2.txt:McAfeeHIP_ClientSetup.exe
list1.txt:SPE Corporate Firewall Interfaces - 7-7-06.pdf
list1.txt:EIS - GNS ExtranetFirewall_Policy-041508.doclist1.txt:CHG0047105  DBB WAN Firewall Rules_final (20120213).xlsx

Ejemplos de archivos de contraseñas:


list1.txt:Login and Passwords.xlsx
list1.txt:passwords.doc
list3.txt:GTS Intel Keepass Access Certification Review - 04232014.xlsx
list2.txt:DavidNelson.kdbx
list3.txt:GNS.kdbx
list1.txt:Copy of FY10 Salary Planning - password - manson08.xls
list1.txt:Digital User Name and passwords.xls
list1.txt:FTP passwords col.xls
list1.txt:FTP passwords phil.xls
list1.txt:DAAF Passwords.doc
list1.txt:UserNames&Passwords.xls
list1.txt:ResearchPasswords.xls
list1.txt:UserNames&Passwords.xls
list1.txt:ZetaMail Master Password List.doc
list1.txt:ZetaMail Master Password List.doc
list1.txt:Forgot password.doc
list1.txt:territoriespassword.xlsx
list1.txt:group password list.xls
list1.txt:2-Copper2.0_ChangePassword.ppt
list1.txt:Covenant MS pages passwords.doc
list1.txt:Username_Passwords_Intern.doc
list1.txt:PASSWORD PALABRA SECRETA NISSAN.xlsx
list1.txt:Online Passwords.xls
list1.txt:Passwords.xlsx
list1.txt:Passwords_110408.xls
list1.txt:Passwords.xls
list1.txt:Digital User Name and passwords.xls
list1.txt:PwC 2007 Report_PASSWORD_pwcemc60.pdf
list1.txt:FTP passwords malaysia.xls
list1.txt:FTP passwords thailand.xls
list1.txt:FTP passwords indonesia.xls
list1.txt:FTP passwords CTHE Hong Kong.xls
list1.txt:FTP passwords thailand pacific.xls

Hacking, como todo lo anterior, lista no completa:

list1.txt:psp hackers.xls
list1.txt:PlayStation Hacking Suit.docx
list1.txt:credit card hacking.doc
list1.txt:hacking_exposed_linux_3rd_edition.pdf
list1.txt:Hacking_The_Next_Generation.pdf

Documentación sobre el cifrado:

list1.txt:FY08 Budget DMI Asset Encryption v2.xls
list1.txt:FY10 GISP Encryption Strategy Budget.xls
list1.txt:Inventory-encryption SPE full.xls
list1.txt:Inventory-encryption SPE Other.xls
list1.txt:Inventory-encryption SPE HR.xls
list1.txt:080128 Laptop Encryption CBA.xls
list1.txt:McAfee_Encrypted_USB_1_1_User_Guide.pdf
list1.txt:IDM Responsible Party DRM - Email Encrypt - 7-Zip Inquiry.docx
list1.txt:081120 Laptop Encryption - PGP Technical Installation Guide v3.doc
list1.txt:Encrypted Satellite Rider - Italy.docx
list2.txt:reports_encrypted5254.zip
list2.txt:reports_encrypted3529.zip


Código fuente (solo en .class hay 204.000 ficheros)

list2.txt:Java2SecurityManager.class
list2.txt:SecurityBO.class
list2.txt:EncryptService.class
list2.txt:EncryptServiceImpl.class
list2.txt:StringToEncryptedStringMigrator.class
list2.txt:APEUserHasPassword.class
list2.txt:NewUserPasswordGenerator.class
list2.txt:ARBPasswordManagementVisibilityCondition.class

Contratos de confidencialidad (NDA), en las que por ejemplo sale el nombre de un periodista del mundo de los videojuegos. Espero que el contrato sea porque tiene los juegos antes de tiempo y no por el tipo de críticas :-)

list1.txt:Geoff Keighley Non Disclosure Agreement - SPT FINAL.pdf
list1.txt:Anne Cox release form non disclosure agreement.pdf
list1.txt:Karen Payne release form? non disclosure agreement.pdf
list1.txt:Geoff Payne release form? non disclosure agreement.pdf
list1.txt:Anne Cox release form? non disclosure agreement.pdf
list1.txt:Maura Gallagher release form? non disclosure agreement.pdf
list1.txt:Jay Tomlinson release form? non disclosure agreement.pdf
list1.txt:Non Disclosure Agreement B.Zamzow.pdf

Porno, como no podría ser der otra manera.

list2.txt:vanessahudgens_nude_03.jpg
list2.txt:vanessahudgens_nude.jpg
list2.txt:vanessahudgens_nude_04.jpg
list2.txt:Felicia Goldstein Susan Rudow Nudelman Elaine Trapasso .jpg
list2.txt:Felicia Goldstein Susan Rudow Nudelman Sandra Brauer Udasco Elaine Trapasso.jpg
list2.txt:big_pic_nude copy.jpg
list2.txt:big_pic_nude copy.jpg
list1.txt:Youporn Materials Release.pdf
list2.txt:30 MINUTES OR LESS SPIKE FINAL-PORN.mov
list2.txt:30min-SP-2-Porn 7-27.mov

Tambien es curioso ver cookies de usuario, lo que tal vez sirva a los investigadores para saber que PCs se han comprometido, aunque podría ser un simple backup:

list2.txt:amilano@www.espn.go[1].txt
list2.txt:esitaras@www.eshop.msn[2].txt
list2.txt:esitaras@www.eshop[1].txt
list2.txt:esitaras@www.essential-oil[1].txt
list2.txt:mccallahan@www.eslcafe[1].txt
list2.txt:mccallahan@www.eslemployment[1].txt

Podría continuar y continuar, el listado es para no terminar, SQLs, scripts, ficheros con la cadena "confidential", "private", claves privadas...,  pero seguro que poco a poco otros blogs también muestran otras cosas.

Nube de letras de los ficheros de Sony.

Esperemos que acabe todo bien.


Leer más...

24 noviembre 2014

Entrevista a Alfonso Muñoz (@mindcrypt)

Hoy tenemos el placer de poder entrevistar al Dr. Alfonso Muñoz @mindcrypt en twitter, co-editor de CRIPTORED que compagina con su trabajo en el departamento de investigación de la empresa 11Paths.

Uno de los “expertis” de Alfonso es la protección de información (criptografía/esteganografía) y sus publicaciones en ese campo son reseñables.

1- Alfonso, todos conocemos tus contribuciones en el mundo de la criptografía, hemos visto tus charlas y tus trabajos, pero si te tocase presentarte a ti mismo ¿Cómo lo harías?

Antes de nada, gracias por la invitación. Un placer compartir líneas con amigos y profesionales que habitan y se acercan a este blog.

¿Presentarme a mí mismo? Eso es fácil, soy guapo, alto, superdotado, bien dotado... En realidad, es bastante incómodo hablar de uno mismo. Diría que soy una persona sencilla, curiosa y trabajadora. Una de mis pasiones es viajar, aspiro a ser feliz y me gusta contribuir para hacer de este mundo un lugar mejor.

2- El mundo de la criptografía ha generado un montón de noticias últimamente. ¿Crees que es un tema pasajero o que va a ser algo de lo que hablemos a menudo?

Es un tema interesante el que planteas y está muy vinculado con la sensación de privacidad y protección de las comunicaciones que percibe la gente. Desde 1999 cuando Duncan Campbell escribió el informe COMIT titulado Interception Capabilities 2000 para el parlamento europeo, donde se detallaba mucha información del programa Echelon, todo el mundo debería ser consciente que el espionaje masivo aplicado al mundo civil y económico-industrial es real.

No importa si tu información es o no importante, no importa si tu eres o no relevante, nadie te va a pedir permiso en recolectar tu información y si es necesaria analizarla en detalle.

Lo curioso de todo esto es que han tenido que surgir casos como Wikileaks, filtraciones de Snowden o mil problemas de seguridad relacionado con el mal uso de la protección de las comunicaciones para que la gente sea consciente de lo expuesta que está su vida y que la criptografía bien utilizada y trabajada es una excelente herramienta para mitigar a los curiosos de lo ajeno.

Cada vez somos más dependientes de la criptografía o de muchos de sus principios que permiten por ejemplo la generación segura de números pseudoaleatorios. Es vital en el comercio electrónico, en el e-goverment, en la validación de procesos y sistemas operativos, etc.

Sin duda, es algo que tendremos que añadir a nuestro día a día, al igual que la vulneración de redes informáticas o cualquier otra tecnología de interés en este campo.

En cuanto a qué noticias nos esperan. Yo auguro que en poco tiempo empezaremos a ver ataques avanzados, algún “careto versión plus” utilizando colisiones al algoritmo SHA-1, al igual que pasó con MD5 en casos tan famosos como el virus Flame. El coste de tal hazaña podría rondar el millón de dólares y bajando.

3- Como bien sabes, a raíz de las revelaciones de Snowden, se ha puesto en tela de juicio la fiabilidad de los algoritmos y sobre todo, de las personas encargadas de implementarlos. ¿Cuál es tu posición en este tema? ¿das crédito a la existencia de 'topos' a sueldo de gobiernos que
degradan programas y algoritmos?

Siento no ser conspiranoico, en este sentido, sigo confiando en las matemáticas, como diría Bruce Scheneir.

Creo firmemente que debemos diferenciar avances cuantitativos de cualitativos. Organizaciones con grandes recursos y equipos capaces son muy proclives a conseguir avances cuantitativos (el gap clásico que existe de unos 5 a 10 años en el descubrimiento de vulnerabilidades en sistemas y protocolos).

Sin embargo, los avances cualitativos, como pueden ser encontrar procedimientos para anular los principios fundamentales en los que se apoyan muchos de los algoritmos criptográficos estándar, son otra cuestión. Es posible, lo fue en el pasado, pero creo que no es ni mucho menos común.

Existen auténticos genios dedicados a la criptografía en el mundo civil, sus investigaciones son públicas y los algoritmos son analizados por una gran comunidad a nivel mundial. Por suerte, el dinero no lo soluciona todo, el talento está en todas partes y a menudo los genios suelen ir por libre.

Sin duda, el mantra a seguir sería: la criptografía no se ataca, se esquiva. En este sentido, la historia ya nos lo ha demostrado, el problema no recae en los algoritmos sino más bien en cómo se implementan, quien lo implementa, características adicionales añadidas que reducen su seguridad o cualquier otro artificio en esta dirección.

Hay intereses claros en introducir características que reduzcan la seguridad intrínseca de los algoritmos y protocolos. ¿Existen topos? Bueno es un poco más complejo que eso, pero la realidad es que hay personas que colaboran consciente o inconscientemente en esta tarea, y hasta ahí puedo leer. Todos conocemos programas como BULLRUN de la NSA. No es la única agencia que realiza esto ni mucho menos.

4- Al hilo de este tema, valora del 1 al 5 (siendo 1 muy poco probable y 5 altamente probable) el grado de paranoia que te merecen los siguientes casos:

a) Goto Fail de Apple

5

b) El 'escándalo TrueCrypt'

3

c) El caso 'heartbleed'

2

d) El caso 'Random Number Bug' de Debian

3

5- Se acaba de publicar que nuestro querido Whatsapp va a implementar un esquema de cifrado que, en teoría, protege a los usuarios finales. ¿Realmente esto supone que la información intercambiada va a estar a salvo y sobre todo, va a ser privada?

Creo que en este punto mi opinión no va a ser muy enriquecedora. Por definición, no me fio nada de ningún software que implemente criptografía que no haya sido mínimamente auditado por la comunidad (el código sea accesible) o que posea al menos algún tipo de certificación que refleje que, como mínimo, saben lo que están haciendo.

Vamos a esperar a que se publiquen análisis en esta dirección. De momento, creo que el Whatsapp está bien para lo que está, quedar con amigos, enviar fotos graciosas y compartir la lista de la compra...

6- También ha sido noticia la iniciativa impulsada por Mozilla, Cisco y otros sobre una 'gran CA', libre, gratuita y que va a proveer de certificados para todo el mundo. ¿Te suena al mito de la fusión fría o realmente este proyecto va a cambiar las cosas?

El problema fundamental de las CA, como bien sabes cuándo hiciste la gran herramienta SSLCop, es que ya no es cierto eso de “tercera parte de confianza”. Hay demasiadas CAs, en muchas de ellas su seguridad es cuestionable y muchas han sido vulneradas (emitiendo certificados falsos con lo que ello ha implicado), no tenemos confianza de que las CAs no estén colaborando con organizaciones facilitándole certificados y ataques MiTM a gran escala, y sobre todo, es triste decirlo, existen tantos elementos intermedios, que no son validados, que a día de hoy las PKIs y la CAs deben ponerse en cuarenta.

La industria lo sabe, multitud de propuestas están surgiendo: certificate pinning, certificate transparency, TACKS, DANE, etc. En cuanto a la propuesta de la “gran CA”, de momento soy cauto. A corto plazo no veo que solucione los problemas conocidos.

7- En un mundo ideal, todas las URLs empezarían por https y no http,
pero parece que nadie se para a pensar en el 'coste' que supone migrar a un protocolo cifrado. ¿Cualquiera puede abordar la transición al mundo SSL? ¿Que le dirías a una organización que esté valorando ese cambio?

La respuesta aquí sería cual es el “coste” de no migrar a un protocolo cifrado. Esto varía en función de la organización pero la bibliografía de muestra que el riesgo de vulneración de comunicaciones, falta de privacidad, infección masiva o enumeración y explotación de recursos internos de una organización o red doméstica es enorme.

Por desgracia, aun implementando TLS/SSL no se puede bajar la guardia (BEAST, CRIME, BREACH, POODLE...).

8- Desde tu punto de vista profesional, ¿Cuales son los errores más típicos que te encuentras cuando revisas una implementación criptográfica (ya sea una instalación SSL o un desarrollo que implemente cifrado?

Depende un poco de lo que hablemos, creo sinceramente que implementar bien un algoritmo de cifrado es complejo, no por el hecho de implementarlo según defina un estándar dado sino sobre todo por gestionar adecuadamente todo tipo de ataques de lo más particulares, por ejemplo side-channel attacks diversos, gestión efectiva de la información temporal (¿qué hacemos con el fichero en claro una vez se obtiene su versión cifrada?), como se gestionan las claves y números aleatorios en la memoria, etc.

En función del lenguaje de programación y el sistema operativo deberemos tener cuidado de las librerías criptográficas que utilicemos y especialmente de la fuente de números “pseudoaleatorios” que se utilicen para generar las claves de cifrado.

En resumen, buenas prácticas y estar al día de los ataques “prácticos” a los algoritmos a utilizar.

9- Se habla mucho de la criptografía de curva elíptica ECC, pero parece que no goza del apoyo que sí tiene la 'tradicional'. ¿Cual es tu posición al respecto?

Diría que la criptografía de curva elíptica es el futuro, aunque en realidad es uno de los presentes más interesantes que tenemos. El problema fundamental, al menos si lo vemos desde el punto de vista de Internet, es que existen algoritmos que todavía siguen dando la batalla como ese el caso de RSA.

Su sustitución no es evidente y entran en juego diversos factores económicos. Quizás si se publica algún fallo significativo en los algoritmos de clave pública más famosos (factorización, logaritmo discreto, etc.) o la computación cuántica avanza quizás se le dé más visibilidad vía algoritmos criptográficos post-cuánticos

Existen múltiples algoritmos y recomendaciones (NIST, ECDSA, ...), software y hardware los implementan cada vez más y se puede encontrar en lugares nada sospechosos como en GPG.

De hecho, estos últimos días se ha estado hablando sobre una nueva curva introducida: "Curve25519".

Y lo mejor de todo, sé que esto gustará a los amantes de las conspiraciones, organizaciones como la NSA está apostando fuertemente por este tipo de criptografía. Algunos criptógrafos afirman que su naturaleza matemática le facilitará ataques no conocidos en el mundo civil, otros, me siento más cómodo en este razonamiento, que es un claro ejemplo de cómo los algoritmos criptográficos de clave pública más extendidos por Internet no son todo lo seguros que pensamos.

10- ¿Cómo formarme en criptografía? ¿Algo para leer en estas navidades?

Por supuesto, alimentemos el grado de masoquista de cada uno :D. Una lectura amena puede ser “Codigos Secretos” de Simon Singh o “The Codebreakers” de David Kahn.

Un buen material técnico, gratuito, en español es el libro electrónico de seguridad informática y criptografía de mi buen amigo y compañero de batallas Dr. Jorge Ramió, o los documentos que hay publicados por la comunidad científica en Criptored o en el proyecto Crypt4you.

En función de los gustos y la especialización hay otros libros recomendables: Criptografía digital: fundamentos y aplicaciones (Jose Pastor et al.), detalles de pkis y certificados digitales en el libro Seguridad en redes Telemáticas (Justo Carracedo) o muchos otros.

Si nos vamos a la lengua de Shakespeare un referente sin duda es el libro “Applied Cryptography” de Alfred Menezes que se puede obtener gratuitamente aquí o cursos online vía MOOCs, por ejemplo, el del Dr. Dan Boneh de Standford (cryptography – Coursera).

Si te gusta el criptoanálisis una forma “curiosa” de introducirse es con los textos de Military Cryptanalysis de William F. Friedman (https://www.nsa.gov/public_info/declass/military_cryptanalysis.shtml)

Muchas gracias Alfonso, ha sido un verdadero placer poder contar contigo.

Gracias a vosotros. Una última cosa:

kdbfrvdvtxhvdehprvtxhvdehprvwdpelhqkdbfrvdvghvfrqrflgdvfrqrflgdvhvghflutxhvdehprvtxhkdbdojxqdvfrvdvtxhqrvdehprvshurwdpeléqkdbfrvdvghvfrqrflgdvtxhghvfrqrfhprvodvtxhqrvdehprvtxhqrvdehprv

Leer más...

23 noviembre 2014

Enlaces de la SECmana - 251

Leer más...

21 noviembre 2014

Probando aplicaciones de auditoría web con Google Web "Firing Range"

Google anunció el pasado martes en su blog Google Online Security la publicación de una aplicación online (con su código fuente correspondiente) en la que se recopilaban diferentes pruebas de concepto relacionadas con vulnerabilidades típicas web, con especial hincapié en todas las variantes posibles para la ejecución de Cross-Site Scriptings. Actualmente Google se encuentra desarrollando una herramienta de auditoría de vulnerabilidades para uso interno (a la que llaman Inquisition) para la cual necesitaban casos reales de vulnerabilidades para probar su eficacia.




Disponemos de páginas preparadas para probar vulnerabilidades de los siguientes tipos hasta el momento (y dentro de cada tipología con multitud de pruebas posibles a realizar):
  • Cross-Site Scripting Address DOM
  • XSS de redirección
  • XSS reflejados
  • XSS basados en Tag
  • Cross-Site Scripting escapados por el servidor
  • XSS de inclusión remota
  • Cross-Site Scripting de DOM
  • Vulnerabilidades relacionadas con CORS (Cross Origin Resource Sharing)
  • Inyección Flash
  • Contenido mixto
  • ClickJacking inverso
Casos de pruebas dentro de la sección "Escape XSS"

Como podréis observar, el diseño no es lo más relevante, ya que lo que prima en este caso es tener un banco de pruebas sobre el que lanzar herramientas de detección de este tipo de vulnerabilidades y probar su eficacia, además de obviamente poder realizar pruebas de manera manual para conseguir el objetivo de un famoso alert() u otros tipos de acciones más interesantes.

Tenéis más información en el post de Google Online Security escrito por Claudio Criscione (Security Engineer en Google), así como en el repositorio de código del proyecto.

[+] Firing Range (Google) https://public-firing-range.appspot.com
Leer más...

20 noviembre 2014

x87 FPU, MMX, SSEs & AVX: primera parte

Tengo la impresión de que algunas personas que hacen ingeniería inversa habitualmente conocen bien la CPU pero no tanto la x87 FPU, MMX, SSEs, AVX y sus posibles aplicaciones. Por eso en esta serie de artículos vamos a explicar como funciona todo esto en x86 y x86_64.

Además se explicará como jugar con todo esto desde el sistema operativo Windows y desde la perspectiva de un depurador.

Introducción:

Ojeando un poco de la wikipedia sobre las extensiones multimedia:

x86 (current):
  • MMX (1996)
  • 3DNow! (1998)
  • Streaming SIMD Extensions (SSE) (1999)
  • SSE2 (2001)
  • SSE3 (2004)
  • Supplemental SSE3 (SSSE3) (2006)
  • SSE4 (2006)
  • SSE5 (2007)
  • Advanced Encryption Standard (AES) (2008)
  • Advanced Vector Extensions (AVX) (2008)
  • F16C (2009 (AMD), 2011 (Intel))
  • XOP (2009)
  • FMA instructions (FMA4: 2011, FMA3: 2012 (AMD), 2013 (Intel))
  • Bit manipulation instructions (ABM: 2007, BMI1: 2012, BMI2: 2013, TBM: 2012)
x86 (planned)  
  • AVX-512 (2015)
Para esta serie de artículos nos vamos a centrar de momento solo en:

x87: es un subconjunto de coma flotante del conjunto de instrucciones de la arquitectura x86. Se originó como una extensión del conjunto de instrucciones del 8086 en la forma de un coprocesador opcional de coma flotante que trabajó en paralelo con el correspondiente CPU x86. Las instrucciones x87 no son estrictamente necesarias para construir programas funcionales, pero proporcionan implementaciones de hardware y microcódigo de tareas numéricas comunes, permitiendo a estas tareas desempeñarse mucho más rápido que las rutinas correspondientes en código máquina. El conjunto de instrucciones x87 incluye instrucciones para operaciones de coma flotante básicas tales como: adición, sustracción y comparación. Así como también para operaciones numéricas más complejas como por ejemplo el cálculo de la función tangente y su inversa. Desde el Intel 80486, la mayoría de los procesadores x86 han tenido estas instrucciones x87 implementadas en el propio CPU. Los registros principales de x87 son un total de 8 registros desde el ST(0) hasta el ST(7). Se puede acceder directamente a estos registros usando un desplazamiento relativo al tope de la pila, así como también se permiten apilados y desapilados en la pila. x87 proporciona aritmética de coma flotante binaria de simple precisión, doble precisión y precisión extendida de 80 bits según el estándar IEEE 754-1985. Por defecto, todos los procesadores x87 usan internamente la precisión extendida de 80 bits.

MMX: es un Conjunto de instrucciones SIMD (Single Instruction, Multiple Data) diseñado por Intel e introducido en 1997 en sus microprocesadores Pentium con tecnología MMX. Fue desarrollado a partir de un set introducido en el Intel i860. Ha sido soportado por la mayoría de fabricantes de microprocesadores x86 desde entonces. MMX define 8 registros desde el MM0 hasta el MM7. Para evitar problemas de compatibilidad con los dispositivos de conmutación contexto en los sistemas operativos existentes, estos registros eran los alias de los registros de pila FPU x87 existentes. Por lo tanto, cualquier operación con los registros que se haga en la FPU x87 también podrá afectar a los registros MMX y viceversa. Sin embargo, a diferencia de los registros internos x87, los registros MMX son directamente accesibles. Cada registro MMX es de 64 bits.

SSE (Streaming SIMD Extensions): es una extensión al grupo de instrucciones MMX para procesadores Pentium III, introducida por Intel en febrero de 1999. Las instrucciones SSE son especialmente adecuadas para decodificación de MPEG2, que es el códec utilizado normalmente en los DVD, procesamiento de gráficos tridimensionales y software de reconocimiento de voz. Con la tecnología SSE, los microprocesadores x86 fueron dotados de setenta nuevas instrucciones y de ocho registros nuevos: del XMM0 al XMM7. Estos registros tienen una extensión de 128 bits. Las extensiones AMD64 de AMD (llamado originalmente x86-64) añaden otros ocho registros desde el XMM8 al XMM15. También hay un nuevo registro de control y estado de 32 bits llamado MXCSR. Los registros del XMM8 al XMM15 son accesibles sólo en modo de 64 bits.

AVX: (extensiones vectoriales avanzadas) es un juego de instrucciones de 256 bits desarrollado por Intel Corporation como una extensión al conjunto de instrucciones x86 utilizado en procesadores de Intel y AMD . Provee nuevas características, instrucciones y un nuevo esquema de codificación. El ancho del registro SIMD es incrementado de 128-bits a 256-bits, y renombrado de XMM0-XMM15 a YMM0-YMM15. En los procesadores que soportan AVX, el juego de instrucciones SSE (que anteriormente operaba en los registros XMM) pasa a operar en los primeros 128-bits de los registros YMM. Los registros del YMM8 al YMM15 son accesibles solo en modo de 64 bits. Además, se espera la inclusión de vectores de 512 (AVX-512) e incluso 1024 bits.

x87 FPU conceptos básicos:

En mi opinión la forma más sencilla de entender la pila de la x87 FPU es pensar en el cañón del revólver. Los registros ST0-ST7 serían los huecos donde se alojan las balas y las balas serían el contenido de los registros.

El registro interno de la FPU que se encuentre ese momento listo para ser disparado sería el registro ST0 y los demás serían relativos a ésta posición (el TOP de la pila). Hemos hecho una imagen que muestra esta idea y con un incremento y un decremento de la pila x87:



A la hora de programar el soporte básico x87 FPU para el x64dbg se me ocurrio que mostrar la representación interna de los registros de la FPU era buena idea para saber en todo momento a qué registro interno corresponde cada ST, el Ollydbg muestra los registros en referencia a su ST, vamos con un par de imágenes de lo que quiero decir:



Como se puede apreciar en el x64dbg se puede ver la relación directa entre los registros internos de la FPU x87r* y que ST tiene asignado en ese momento y se puede ver de una manera más clara (en mi opinión) cosas como que la pila se ha movido de un primer vistazo. Además tiene la ventaja que un registro MMX pertenece siempre a un x87r* correspondiente, por ejemplo la parte baja del registro interno de la FPU x87r0 siempre será MM0, x87r1 siempre será MM1, etc.

Además de los 8 registros de 80 bits en la x87 FPU también se encuentran tres registros de 16 bits: Control Word, Status Word y Tag Word. En este apartado de conceptos básicos vamos a explicar que es cada uno de estos registros y sus bits correspondientes.


Control Word: se utiliza para seleccionar entre los distintos modos de cálculo disponible en la FPU y para definir qué excepciones deben ser manejadas por la FPU o por un manejador propio de excepciones.

A continuación vamos a explicar todos los campos:

El campo X (tambien se puede encontrar como IC) corresponde al bit 12, se le denomina Infinity Control y permite dos tipos de aritmética infinita los valores que puede tener son:
  • 0: -infinity y +infinity son tratados como "unsigned infinity" (estado inicializado).
  • 1: -infinity y +infinity
Nota: este campo se mantiene para guardar la compatibilidad con 287 y las FPU anteriores. En las FPU "modernas" este bit se ignora.

El campo RC corresponde a los bits 10 y 11, se le denomina Round Control y sirve para indicar como debe la FPU redondear los resultados. Los valores que puede tener son:
  • 00: Redondeo al más cercano (or to even if equidistant). Este es el estado inicializado.
  • 01: Redondeo al infinito negativo (toward -infinity)
  • 10: Redondeo al infinito positivo (toward +infinity)
  • 11: Truncar (toward 0)
El campo PC corresponde a los bits 8 y 9, se le denomina Precision Control y sirve para determinar a qué precision se deben redondear los resultados después de cada instrucción aritmética. Los valores que puede tener son:
  • 00: 24 bits (REAL4)
  • 01: Not used
  • 10: 53 bits (REAL8)
  • 11: 64 bits (REAL10). Este es el estado inicializado.
El campo IEM corresponde al bit 7, se le denomina Interrupt Enable Mask y sirve para determinar si alguna de las "interrupt masks" se activarán o no. Este es otro de los bits que se guardan por compatibilidad con las FPUs antiguas y no se usa. Los valores que puede tener son:
  • 1: Las "interrupt masks" están activadas. Este también es el estado inicializado.
  • 0: Todas las "interrupt masks" están desactivadas.
Los bits que van del 0 al 5 son las llamadas "interrupt masks". En el estado inicializado todas valen 1, esto quiere decir que la FPU manejará todas las excepciones. Cuando alguno de estos bits tiene el valor 0 la FPU generará una interrupción cuando la excepción se detecta y el programa podrá ejecutar el código deseado antes de devolver el control a la FPU. De momento no vamos a entrar en más detalles sobre este tema. Las "interrupt masks" que hay son:
  • IM (bit 0) también llamado Invalid operation Mask.
  • DM (bit 1) también llamado Denormalized operand Mask.
  • ZM (bit 2) también llamado Zero divide Mask.
  • OM (bit 3) también llamado Overflow Mask.
  • UM (bit 4) también llamado Underflow Mask.
  • PM (bit 5) también llamado Precision Mask.
Status Word: almacena el estado actual de la FPU. Así que muchas de de las instrucciones van modificando los bits de éste registro al igual que ocurre con los FLAGS de la CPU.

A continuación vamos a explicar los campos de este registro:

El campo B corresponde al bit 15 y se pone a 1 cuando la FPU está ocupada o a 0 si está en espera (idle).

Los campos C3 (bit 14), C2 (bit 10), C1 (bit 9), C0 (bit 8) son flags condicionales que se usan por ejemplo para comprobar el resultado de una comparación. De momento no se explicará más sobre esto.

El campo TOP corresponde a los bits 11, 12 y 13 y almacena que registro interno de la FPU es el ST0 actual, es decir qué registro interno está en el TOP de la pila.

Nota: un ejemplo del uso y explicación de este campo se puede encontrar en el apartado "Obteniendo y entendiendo el CONTEXT en Windows: I".

El campo ES también llamado IR o Interrupt Request corresponde al bit 7 y tiene el valor 1 si una excepción está siendo manejada y tiene el valor 0 cuando se ha acabado de manejar.

Los bits del 0 al 6 son flags que son manejados por la FPU cuando detecta una excepción.

El campo SF corresponde al bit 6, tambien es llamado Stack Fault Flag y se pone a 1 cuando se intenta cargar un valor en un registro que no está libre.

El campo PE corresponde al bit 5, también es llamado Precision Exception Flag y se pone a 1 cuando la precisión se ha perdido en alguna instrucción aritmética.

El campo UE corresponde al bit 4, también es llamado Underflow Exception Flag y se pone a 1 cuando un valor es demasiado pequeño para poder ser representado.

El campo OE corresponde al bit 3, también es llamado Overflow Exception Flag y se pone a 1 cuando un valor es demasiado grande para poder se representado.

El campo ZE corresponde al bit 2, también es llamado Zero Divide Exception Flag y se pone a 1 cuando se intenta dividir por 0.

El campo DE corresponde al bit 1, también es llamado Denormalized Exception Flag  y se pone a 1 cuando se intenta operar en un "denormalized number" o el resultado de una operación es un "denormalized number".

El campo IE corresponde al bit 0, también es llamado Invalid Operation Exception Flag se pone a 1 cuando se realiza una operación inválida para FPU.

Tag Word: contiene información sobre cada registro de 80 bits de la FPU. Hay 3 bits para indicar el estado de cada registro de 80 bits de la FPU. Y estos corresponden a la posición fija del registro NO al ST(n) actual. Es decir TAG(0) siempre se referirá al registro interno 0 de la FPU independientemente de que ese registro sea actualmente ST0 o ST5.
Cada TAG puede tener los siguientes valores:
  • 00: También llamado valid: el registro contiene un valor que no es 0.
  • 01: También llamado zero: el registro contiene un valor 0.
  • 10: También llamado special: el registro contiene un valor especial (NAN, infinity...).
  • 11: Tambien llamado empty: el registro está vacío.

MxCsr

Este registro de 32 bits tiene una función parecida al registro Control Word y al Status Word de la x87 FPU: mantiene toda la información de enmascaramiento y flags para su uso con operaciones de coma flotante SSE. Los bits del 16 al 31 están reservados y causarán una excepción #GP si se intentan activar.


A continuación vamos a explicar los campos del MxCsr:

El campo FZ también llamado Flush to Zero corresponde al bit 15 activa el modo en el que todas las operaciones donde ocurra un underflow valdrán 0. Esto hace que el tiempo de procesado sea más rápido pero se pierde precisión.

El campo RC corresponde a los bits 13 y 14, se le denomina Round Control y sirve para indicar como deben redondear los resultados. Los valores que puede tener son:
  • 00: Redondeo al más cercano
  • 01: Redondeo al infinito negativo (toward -infinity)
  • 10: Redondeo al infinito positivo (toward +infinity)
  • 11: Redondea a 0 (toward 0)
Los bits que van del 7 al 12 son las llamadas "interrupt masks". En el estado inicializado todas valen 1, esto quiere decir que el programa no manejará las excepciones. Cuando alguno de estos bits tiene el valor 0 se generará una interrupción cuando la excepción se detecta y el programa podrá hacer lo necesario antes de devolver el control. En esta parte del post no vamos a entrar en más detalles sobre este tema. Las "interrupt masks" son:
  • IM (bit 7) también llamado Invalid Operation Mask.
  • DM (bit 8) también llamado Denormalized Operand Mask.
  • ZM (bit 9) también llamado Zero Divide Mask.
  • OM (bit 10) también llamado Overflow Mask.
  • UM (bit 11) también llamado Underflow Mask.
  • PM (bit 12) también llamado Precision Mask.
El campo DAZ corresponde al bit 6, también es llamado Denormals Are Zeros, este campo no estaba disponible en la primera versión de SSE. Al igual que el modo Flush To Zero (FZ) el modo DAZ es más rápido pero también pierde precisión. Si el bit 6 está activado el modo DAZ es soportado.

El campo PE corresponde al bit 5, también es llamado Precision Exception Flag y se pone a 1 cuando la precisión se ha perdido en alguna instrucción aritmética.

El campo UE corresponde al bit 4, también es llamado Underflow Exception Flag y se pone a 1 cuando un valor es demasiado pequeño para poder ser representado.

El campo OE corresponde al bit 3, también es llamado Overflow Exception Flag y se pone a 1 cuando un valor es demasiado grande para poder ser representado.

El campo ZE corresponde al bit 2, también es llamado Zero Divide Exception Flag y se pone a 1 cuando se intenta dividir por 0.

El campo DE corresponde al bit 1, también es llamado Denormalized Exception Flag y se pone a 1 cuando se intenta operar en un "denormalized number" o el resultado de una operación es un "denormalized number".

El campo IE corresponde al bit 0, también es llamado Invalid Operation Exception Flag se pone a 1 cuando se realiza una operación inválida para FPU.

Obteniendo y entendiendo el CONTEXT en Windows: I

Para el código de esta parte del artículo voy a basarme en el soporte FPU XMM, MMX, x87 & AVX programado para el x64dbg (An open-source x64/x32 debugger for windows). Actualmente x64dbg usa por debajo como debugger el proyecto Open Source Titanengine Community Edition y es en este donde realmente se encuentra la parte de código que nos interesa.

Para obtener el contexto de un hilo en Windows se usa la API GetThreadContext:
    BOOL WINAPI GetThreadContext(
    _In_     HANDLE hThread,
    _Inout_  LPCONTEXT lpContext
    );
Para simplificar usaremos un CONTEXT_ALL para obtener toda la información del hilo. Hay que suspender el hilo antes de obtener el contexto con la API SuspendThread, un ejemplo de código sin comprobar errores de las llamadas a las APIs podría ser:
    SuspendThread(hThread);
    CONTEXT Context;
    memset(&Context, 0, sizeof(Context));
    DBGContext.ContextFlags = CONTEXT_ALL;
    GetThreadContext(hThread, &Context);
    ResumeThread(hThread);

Nota: Para acceder a Intel AVX hay otras APIs.

CONTEXT_ALL tiene la siguiente pinta (recomiendo leer en la msdn más sobre el tema si se tienen dudas):
    
    #define CONTEXT_ALL (CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS | 
            CONTEXT_FLOATING_POINT | CONTEXT_DEBUG_REGISTERS | CONTEXT_EXTENDED_REGISTERS) 
 
Para saber si una característica está disponible se puede usar la API IsProcessorFeaturePresent con la característica a comprobar. Si retorna 0 la característica no está disponible:
  • PF_MMX_INSTRUCTIONS_AVAILABLE: disponible MMX.
  • PF_XMMI_INSTRUCTIONS_AVAILABLE: disponible XMM.
  • PF_XMMI64_INSTRUCTIONS_AVAILABLE: set de instrucciones SSE2 disponible.
  • PF_SSE3_INSTRUCTIONS_AVAILABLE: set de instrucciones SSE3 disponible (Característica no disponible en Windows Server 2003 and Windows XP/2000).
  • PF_3DNOW_INSTRUCTIONS_AVAILABLE está disponible 3DNOW.
  • PF_XSAVE_ENABLED el procesador implementa las instrucciones XSAVE y XRSTOR.
Para obtener los registros MMX de la estructura CONTEXT de Windows hay que tener en cuenta que vienen desordenados y además vienen dentro de los registros x87 (80 bits). Así que hay acceder a la parte baja del registro x87 para obtener los 64 bits de cada registro MMX.

El orden en el que vienen los registros MMX es el que hay en la pila FPU x87 en el momento de obtener el CONTEXT. Para calcular a qué MMX se está accediendo es necesario obtener el campo TOP del registro StatusWord de x87.

El campo TOP ocupa 3 bits y corresponde a las posiciones 11, 12 y 13 y almacena qué registro x87 se encuentra primero en la pila, por ejemplo si el TOP es 3, quiere decir que en el TOP de la pila está el registro 3 de x87, así que el registro MMX que obtendremos en la parte baja del primer registro x87 del stack será MM3.

De tal forma que los registros MMX vendrían en la estructura CONTEXT en el siguiente orden: MM3, MM4, MM5, MM6, MM7, MM0, MM1 & MM2. Como los registros ST vienen siempre en orden de ST0 a ST7, en este caso, la correspondencia de los registros ST con los MMX sería: ST0: MM3, ST1: MM4, ST2: MM5, ST3: MM6, ST4: MM7, ST5: MM0, ST6: MM1 & ST7: MM2.

El principal problema es que en las versiones de 32 bits de Windows se accede a través del campo FloatSave y ExtendedRegisters de la estructura CONTEXT y en 64 bits se debe usar el campo
FltSave.

Además Microsoft a partir de Windows 7 SP1 ha añadido una nueva forma de acceder al contexto para obtener los registros AVX: XState functions.

A continuación vamos a explicar como acceder a los diferentes CONTEXT:

Para obtener los registros AVX YMM de 256 bits será neceserario obtener las funciones en tiempo de ejecución con GetModuleHandle y GetProcAddress ya que no existe SDK para Windows 7 con SP1. Para ello lo primero será crear los punteros a funciones e inicializarlos al valor correspondiente. Hay que tener en cuenta que esto solo funcionará desde Windows 7 SP1:
    typedef DWORD64 (WINAPI *PGETENABLEDXSTATEFEATURES)();
    typedef BOOL (WINAPI *PINITIALIZECONTEXT)(PVOID Buffer, DWORD ContextFlags, 
        PCONTEXT* Context, PDWORD ContextLength);
    typedef BOOL (WINAPI *PGETXSTATEFEATURESMASK)(PCONTEXT Context, PDWORD64 FeatureMask);
    typedef PVOID (WINAPI *LOCATEXSTATEFEATURE)(PCONTEXT Context, DWORD FeatureId, 
        PDWORD Length);
    typedef BOOL (WINAPI *SETXSTATEFEATURESMASK)(PCONTEXT Context, DWORD64 FeatureMask);

    PGETENABLEDXSTATEFEATURES pGetEnabledXStateFeatures;
    PINITIALIZECONTEXT pInitializeContext;
    PGETXSTATEFEATURESMASK pGetXStateFeaturesMask;
    LOCATEXSTATEFEATURE pLocateXStateFeature;
    SETXSTATEFEATURESMASK pSetXStateFeaturesMask;

    kernel32h = GetModuleHandleA("kernel32.dll");

    pGetEnabledXStateFeatures = (PGETENABLEDXSTATEFEATURES)GetProcAddress(kernel32h, 
        "GetEnabledXStateFeatures");
    pInitializeContext = (PINITIALIZECONTEXT)GetProcAddress(kernel32h, 
        "InitializeContext");
    pGetXStateFeaturesMask = (PGETXSTATEFEATURESMASK)GetProcAddress(kernel32h, 
        "GetXStateFeaturesMask");
    pLocateXStateFeature = (LOCATEXSTATEFEATURE)GetProcAddress(kernel32h,         
        "LocateXStateFeature");
    pSetXStateFeaturesMask = (SETXSTATEFEATURESMASK)GetProcAddress(kernel32h, 
        "SetXStateFeaturesMask");
Otro de los problemas que se nos presentan es que el valor para CONTEXT_XSTATE cambió de Windows 7 a Windows 7 SP1. Así que para evitar problemas si usamos un SDK u otro añadimos el código directamente, además también añadiremos otras constantes que pueden no estar presentes en nuestro SDK y necesitaremos XSTATE_AVX y XSTATE_MASK_AVX:
    #undef CONTEXT_XSTATE
    #if defined(_M_X64)
    #define CONTEXT_XSTATE                      (0x00100040)
    #else
    #define CONTEXT_XSTATE                      (0x00010040)
    #endif
    #define XSTATE_AVX                          (XSTATE_GSSE)
    #define XSTATE_MASK_AVX                     (XSTATE_MASK_GSSE)
Una vez obtenidos los punteros a las funciones que usaremos en tiempo de ejecución y hemos comprobado que hemos podido obtener todas, es el momento de obtener el CONTEXT. Para ello primero necesitamos saber el tamaño llamando a la API InitializeContext de la siguiente manera:
    DWORD ContextSize = 0;
    BOOL Success = pInitializeContext(NULL, CONTEXT_ALL | CONTEXT_XSTATE, NULL,
         &ContextSize);
Si ha ocurrido algún error obtendremos en Success un valor TRUE o el Last Error será
ERROR_INSUFFICIENT_BUFFER.

En caso de que todo vaya bien reservaremos la memoria para el CONTEXT y lo inicializaremos:
    PCONTEXT Context;
    void * buffer = malloc(ContextSize);
    if buffer != NULL)
    {
        Success = pInitializeContext(buffer, CONTEXT_ALL | CONTEXT_XSTATE, &Context, 
                &ContextSize);
    }
Si todo ha ido bien Success tendrá el valor TRUE y será necesario llamar a SetXStateFeaturesMask. Antes de obtener el contexto de un hilo con la API GetThreadContext (según Microsoft) debemos usar SetXStateFeaturesMask para verificar que tipo de funcionalidad queremos obtener o cambiar.
    Success = pfnSetXStateFeaturesMask(Context, XSTATE_MASK_AVX);
Si todo ha ido bien Success tendrá el valor TRUE y será necesario suspender el hilo con la API SuspendThread y obtener el contexto con la API GetThreadContext:
    if ( SuspendThread(hThread) != (DWORD) -1)
    {
        Success = GetThreadContext(hThread, Context);
    }

Si todo ha ido bien Success tendrá el valor TRUE y será necesario llamar a la API GetXStateFeaturesMask para obtener la máscara de las características válidas en el contexto especificado.

Hay que tener en cuenta que si un bit en particular no está activado quiere decir que se está en un estado inicializado y el contenido obtenido con la API LocateXStateFeature no está definido.
    DWORD64 FeatureMask;
    Success = pGetXStateFeaturesMask(Context, &FeatureMask);
Si todo ha ido bien Success tendrá el valor TRUE y ya solo tenemos que llamar a la API LocateXStateFeature para obtener los registros YMM. Para saber si estamos en 32 bits (podemos obtener del registro YMM0 al YMM7) o en 64 bits (podemos obtener del registro YMM0 al YMM15) usaremos el tercer parámetro de la API para obtener el tamaño:
    PM128A Xmm;
    PM128A Ymm;
    DWORD FeatureLength;
    Xmm = (PM128A)pLocateXStateFeature(Context, XSTATE_LEGACY_SSE, &FeatureLength);
    Ymm = (PM128A)pLocateXStateFeature(Context, XSTATE_AVX, NULL);
Y ahora con un simple
for (i = 0; i < (FeatureLength / sizeof(*Ymm)); i++)
Podemos acceder a la parte alta y baja de los primeros 128 bits de YMM y a la parte alta y baja de los últimos 128 bits de YMM que corresponden con los registros XMM:
    Ymm[Index].High 
    Ymm[Index].Low
    Xmm[Index].High 
    Xmm[Index].Low
Actualmente el ollydbg no tiene soporte para Intel AVX, así que se puede ir usando la versión básica del soporte AVX del x64dbg:



A continuación vamos a ver como obtener el CONTEXT de x87 FPU, MMX, SSE, XMM en las versiones de 32 bits y de 64 bits:

Win32: La estructura CONTEXT en Win32 tiene la siguiente pinta:
    typedef struct _CONTEXT {
        ...
        // This section is specified/returned if the
        // ContextFlags word contians the flag CONTEXT_FLOATING_POINT.
        FLOATING_SAVE_AREA FloatSave;
        ...
        // This section is specified/returned if the ContextFlags word
        // contains the flag CONTEXT_EXTENDED_REGISTERS.
        // The format and contexts are processor specific
        BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
    } CONTEXT;

    #define SIZE_OF_80387_REGISTERS      80
    typedef struct _FLOATING_SAVE_AREA {
        DWORD   ControlWord;
        DWORD   StatusWord;
        DWORD   TagWord;
        DWORD   ErrorOffset;
        DWORD   ErrorSelector;
        DWORD   DataOffset;
        DWORD   DataSelector;
        BYTE    RegisterArea[SIZE_OF_80387_REGISTERS];
        DWORD   Cr0NpxState;
    } FLOATING_SAVE_AREA;
Acceder a los 3 registros de 16 bits de la x87 FPU:
    ControlWord: Context.FloatSave.ControlWord;
    StatusWord: Context.FloatSave.StatusWord;
    TagWord: Context.FloatSave.TagWord;
Para obtener los registros ST0-ST7 (80 bytes ocupan todos los registros) se usa el campo Context.FloatSave.RegisterArea:
    BYTE RegisterArea[80];
    memcpy(RegisterArea, Context.FloatSave.RegisterArea, 80);
Obtener MMX desordenados:
    uint64_t mmx[8];
    for(i = 0; i < 8; i++)
    {
        memcpy( &(mmx[i]), & (Context.FloatSave.RegisterArea[i*10]), sizeof(mmx[i]));
    }
MxCsr: el registro MxCsr se encuentra en Context.ExtendedRegisters[24]:
    DWORD MxCsr;
    memcpy(&MxCsr, & (Context.ExtendedRegisters[24]), sizeof(MxCsr));
XMM: Para acceder a los 8 registros XMM disponibles en 32 bits se usa el campo ExtendedRegisters de la siguiente forma Context.ExtendedRegisters[(10 + indice) * 16]:
    M128A XmmRegisters[8];
    for(i = 0; i < 8; i++)
    {
        memcpy(&(XmmRegisters[i]),  & (Context.ExtendedRegisters[(10 + i) * 16]), 16);
    }
Win64: La estructura CONTEXT en Win64 y otras estructuras que nos interesan tienen la siguiente pinta:
    typedef struct DECLSPEC_ALIGN(16) _CONTEXT {
    ...
    // Floating point state.
    union {
    XMM_SAVE_AREA32 FltSave;
    struct {
        M128A Header[2];
        M128A Legacy[8];
        M128A Xmm0;
        M128A Xmm1;
        M128A Xmm2;
        M128A Xmm3;
        M128A Xmm4;
        M128A Xmm5;
        M128A Xmm6;
        M128A Xmm7;
        M128A Xmm8;
        M128A Xmm9;
        M128A Xmm10;
        M128A Xmm11;
        M128A Xmm12;
        M128A Xmm13
        M128A Xmm14;
        M128A Xmm15;
        } DUMMYSTRUCTNAME;
    } DUMMYUNIONNAME;

    // Vector registers.
    M128A VectorRegister[26];
    DWORD64 VectorControl;
    ...
    }

    typedef XSAVE_FORMAT XMM_SAVE_AREA32, *PXMM_SAVE_AREA32;

    // Format of data for (F)XSAVE/(F)XRSTOR instruction
    typedef struct DECLSPEC_ALIGN(16) _XSAVE_FORMAT {
        WORD   ControlWord;
        WORD   StatusWord;
        BYTE  TagWord;
        BYTE  Reserved1;
        WORD   ErrorOpcode;
        DWORD ErrorOffset;
        WORD   ErrorSelector;
        WORD   Reserved2;
        DWORD DataOffset;
        WORD   DataSelector;
        WORD   Reserved3;
        DWORD MxCsr;
        DWORD MxCsr_Mask;
        M128A FloatRegisters[8];
        #if defined(_WIN64)
            M128A XmmRegisters[16];
            BYTE  Reserved4[96];
        #else
            M128A XmmRegisters[8];
            BYTE  Reserved4[192];
        ...
    }
Acceder a los 3 registros de 16 bits de la x87 FPU:
    ControlWord: Context.FltSave.ControlWord;
    StatusWord: Context.FltSave.StatusWord;
    TagWord: Context.FltSave.TagWord;
Para obtener los registros ST0-ST7 (80 bytes ocupan todos los registros) se debe obtener la parte baja (10 bytes) de cada entrada de 128 bits del campo Context.FltSave.FloatRegisters:
    BYTE RegisterArea[80];
    for(i = 0; i < 8; i++)
    {
        memcpy(&(RegisterArea[i * 10]), & (Context.FltSave.FloatRegisters[i]), 10);
    }
Para obtener los MMX desordenados se debe obtener la parte baja (64 bits) de cada entrada de 128 bits (M128A FloatRegisters[8]) del campo Context.FltSave.FloatRegisters:  
    uint64_t mmx[8];
    for(i = 0; i < 8; i++)
    {
        memcpy(&(MMX[i]), & (Context.FltSave.FloatRegisters[i]), sizeof(MMX[i]));
    }
MxCsr:
DWORD MxCsr = Context.FltSave.MxCsr;
XMM: acceder a los 16 registros XMM disponibles en 64 bits es mucho más fácil, se debe usar el campo Context.FltSave.XmmRegisters.
    M128A XmmRegisters[16];
    for(i = 0; i < 16; i++)
    {
        memcpy(& (XmmRegisters[i]), & (Context.FltSave.XmmRegisters[i]), 16);
    }

Petición & Agradecimientos

En primer lugar, gracias al equipo de Security By Default y Buguroo por su apoyo y en segundo lugar me gustaría que la gente que haya trabajado y/o experimentado se animara y escribiera más sobre este tema.

David Reguera Garcia aka Dreg @fr33project - Senior Malware Analyst en Buguroo

Revolver barrel images by Jorge Martinez Taboada @jmtaboada - Senior UX Consultant en Buguroo
Leer más...

17 noviembre 2014

Bluebox-ng HowTo (I)

Más de un año después de publicar aquí la versión alpha de Bluebox-ng, por fin liberamos la primera estable esta semana en el Arsenal de la Black Hat Europa. Así que más o menos vamos a contaros lo mismo que explicábamos allí, ya que nos interesan mucho las opiniones de esta, nuestra comunidad.

Finalmente decidimos definir el proyecto como un escáner de vulnerabilidades VoIP/UC (Unified Communications).

Pero la idea es la misma, necesitábamos algo para automatizar todos los pasos manuales que seguíamos durante los test de intrusión específico en este tipo de entornos. Como sabemos, en otros como la web sí disponemos de multitud de opciones libres y de pago para este cometido. Pero no era así en nuestro caso, las escasas opciones no eran suficientes para nuestro fin (además de prohibitivas).

Antes de meternos en materia, comentar que está reescrito desde 0 en JavaScript, ya que el proyecto comenzó como un conjunto de scripts (en CoffeeScript), que "no escalaban". Ahora, a parte de el cliente de consola, se puede utilizar como una librería más de Node.js y es sencillo añadir nuevos módulos. Además ahora somos dos, estamos centrados en probarlo en entornos reales y, al mismo tiempo, empezando a añadir nuevas funcionalidades (ie: vectores para el protocolo DNS).

Para instalarla simplemente hay que tener Node (una versión actual por favor ;) y luego la forma más sencilla es utilizar el gestor de paquetes Npm como para cualquier otra librería/herramienta de este ecosistema:

npm i -g bluebox-ng

En Kali el script oficial para instalar node desde el repositorio de paquetes (y tenerlo actualizado de una forma cómoda) no funciona, así que dejo uno colgado para ahorraros trabajo, podéis usar el siguiente comando y listo:
curl -sL https://raw.githubusercontent.com/jesusprubio/bluebox-ng/master/artifacts/installScripts/kali.sh | sudo bash -

Como en todas las utilidades de este tipo disponemos de la opción de realizar un test de intrusión automático (del que hablaremos más adelante) o manual, lanzando los módulos y jugando con los distintos parámetros. Debemos aclarar que actualmente tenemos implementado un conjunto de vectores de ataque que consideramos "suficiente por ahora", pero nos queda mucho trabajo. Sabemos que la VoIP incluye a muchos más protocolos que SIP, y hay vectores muy interesantes que involucran a otros, como RTP. E incluso a distintos tipos de señalización como IAX, H323 o Skinny se siguen utilizando y también habría que contemplarlos. Aunque esto último nos preocupa menos, ya que SIP está "ganando la batalla" en estos últimos años.

En el artículo de la versión alpha hay algunos ejemplos cuya ejecución es muy similar, así que no los voy a repetir. Para ver uno actualizado, el siguiente muestra un escaneo SIP típico (lo mismo que el "svmap" del SIPVicious, para entendernos).

Podéis consultar todos los comandos podéis usar el tabulador o el comando "help". Con este mismo acompañando al nombre de un módulo nos ofrece la descripción del mismo. Entre ellos nos encontramos de distintos tipos:

  • Típicas herramientas de red: TCP ping, Whois, DNS resolve/reverse, Traceroute, Geolocation, Nmap ...
  • Vectores de ataque al protocolo SIP: Escáner, fuerza bruta de extensiones y contraseñas, llamadas sin autenticar, tests de stress, DoS, etc.
  • Fuerza bruta y explotación de la AMI (Asterisk Manager Interface) de Asterisk.
  • Seguridad: SHODAN, Exploitsearch, etc.
  • Fuerza bruta de protocolos comunes en estas infraestructuras: TFTP, SSH, MYSQL, SNMP, FTP, LDAP, etc.
  • Pijadas varias: Google Dorks y contraseñas por defecto de paneles de gestión web, un "dumb fuzzer" ...

shoot4.png

shoot5.png
Ayuda general

helpScan.png
Ayuda módulo "sipScan"

sipScan.png

sipScan2.png
Uso módulo "sipScan"

Como comentamos, la principal novedad es el modulo "auto", que hace el trabajo por nosotros. Los parámetros que recibe son los siguientes:

  • "targets": Pues eso, se le puede pasar una dirección IP o un rango en formato CIDR. Actualmente estamos añadiendo soporte para dominios SIP y DNS.
  • "srcHost": En la capa de aplicación el protocolo SIP incluye la dirección IP de origen, por lo cual debemos de indicarla de alguna forma. Por defecto se pasa el nombre de la interfaz de red y la herramienta será capaz de obtenerla de ahí. Si se decide "spoofearla" (útil en algunos casos) debemos de ser conscientes de que algunos servidores (según la configuración) van a enviar las respuestas a esta dirección en vez de a la nuestra. Si haces una auditoría fuera de tu red, a parte de redirigir los puertos, deberías utilizar "external" en este parámetro para que obtenga tu dirección IP utilizando icanhazip.com y la incluya en las peticiones.
  • "srcPort": Lo mismo pero para el puerto, en este caso por defecto usa el "real" (el mismo que a nivel de transporte).
  • "sipDomain": Si no se le especifica usará la dirección IP del objetivo, una configuración ampliamente usada. Pero existen casos en los que hace falta pasarlo, así que permitimos la opción.
  • "timeout"
  • "nmapLocation": En algún paso, que comentaremos más adelante, se utiliza el Nmap  por lo que necesitamos pasarle la ruta.
  • "profile": Típico perfil en una herramienta de este tipo, podemos elegir uno de los disponibles o utilizar el nuestro. Para una auditoría real deberíamos utilizar el "aggressive" evitando de esta forma dejarnos casos posibles sin probar.
  • "reportPath": Ruta para guardar el fichero ".html" generado con el informe.

Uso módulo "auto" (perfil "demo")

¿Qué hace todo esto? A parte de no disponer de herramientas adecuadas tampoco existe una metodología de facto, estilo OWASP, simplementes algunos apuntes incluidos entre otras más genéricas. Nuestra solución para esto fue revisar las vulnerabilidades conocidas y las secciones de seguridad de la documentación de los principales servidores libres y alguno propietario. De esa forma conseguimos especificar un conjunto de pasos para cubrir los casos más comunes, pero de momento no se le puede llamar metodología (estamos en ello ;). En el siguiente post lo explicaremos con calma y veremos cómo usar Bluebox-ng como una librería para implementar, por ejemplo, un sistema de "pentesting" continuo para nuestros servidores de voz.

Informe

Artículo cortesía de Jesús Pérez y Sergio García
Leer más...

16 noviembre 2014

Enlaces de la SECmana - 250


Leer más...