miércoles, 27 de marzo de 2013

Arreglando Sandboxie, que está kaputt.

En algún momento creo que ya os he hablado de Sandboxie (por ejemplo, aquí). Y, recientemente, también os he hablado de verifier y de cómo resolví un problema que tenía con el equipo. Bueno, pues en este proceso, y sin darme cuenta, sandboxie dejó de funcionar. Y, para resumir, todo este proceso tuvo algo que ver en que su panel de control, SbieCtrl.exe, sólo me pusiera mensajes parecidos a:

- SBIE1114 No es posible encontrar el servicio de sistema Zw, motivo 36
- SBIE1108 No se pudo analizar el procedimiento NTDLL.ZwCreateToken
- SBIE1103 El controlador de Sandboxie (SbieDrv) version 3.76 no ha conseguido iniciarse
- SBIE9153 No es posible iniciar el controlador (SbieDrv)
- SBIE1102 El controlador de Sandboxie (SbieDrv) se está descargando

Te encuentras con estas cosas (que  me salen después de haber estado trasteando un buen rato), y dices: ¿Qué hago? Pues empiezas a investigar. Si lo primero que has visto, antes de obtener estos mensajes, es que   puede tenga que ver con el servicio en sí mismo, SbieSvc, se intenta lanzar de diversas maneras, desde utilizando el comando sc, hasta yendo a la consola de administración de servicios de Windows.

Claro. Estos mensajes que estoy mostrando me han ido saliendo después de, incluso, haber reinstalado todo el programa con una desinstalación de por medio, porque una actualización no sirvió de nada.

Y, si se mira el autoruns de sysinternals, se puede ver que sí se deberían de estar cargando en el inicio.

Por lo que, si volvemos a la parte en la que iniciamos el servicio, que se encuentra parado, desde la consola de servicios, podremos ver cómo se empieza a arrancar, y a los pocos segundos, se para. Ahí se lanzan las alertas. ¿Y si miro en el visor de eventos de Windows a ver qué me sale? Si miramos en los registros de sistema, podremos ver que están exactamente las mismas líneas que nos muestra el panel de control. Al iniciar una de las primeras búsquedas, nos encontraremos que el registro
SBIE1114 Cannot find Zw system service, reason 36
nos indica que la razón 36 se produce cuando en un sistema 64 bits se está utilizando el driver verifier manager con SbieDrv.

Como ya dije en su momento, qué casualidad que no usé sandboxie después de haberlo activado. Por lo tanto, voy a lanzar esta herramienta y eliminaré la configuración actual (acordaros de elevar privilegios y de reiniciar).

Una vez reiniciado, ya tendremos otra vez sandboxie funcionando. Evidentemente, si has reinstalado entero, tendrás que volver a configurar las cosas de nuevo.

lunes, 25 de marzo de 2013

Mi propio black screen of death

Este es un error que lleva mucho, mucho, mucho tiempo pasándome. He intentado hacer de todo y de momento no he conseguido saber qué es lo que sucede. Cuando creo que ya lo he arreglado, vuelve a pasarme. Lo peor de todo es que es aleatorio. Estas haciendo cualquier cosa (o te vas, y dejas el ordenador encendido) y el equipo se le pone la pantalla negra (que no apagada, y no es el salva pantallas) y no responde nada: ni el sonido (si estabas escuchando algo), ni el teclado ni el ratón... nada. Niente.

¿Cosas que he probado? Probé a cambiar los drivers de la tarjeta gráfica (que pueden ir por ahí los tiros): Una ATI de la que hay que  instalar los drivers de Windows Vista.

Probé a lanzar un

sfc /scannow

con privilegios de administrador para examinar y reparar los ficheros del sistema que pudieran producir este error. Y vuelve a suceder. Lo peor de todo es que los logs que suelta esta herramienta no se pueden seguir. Horas y horas de logs. Imposible de leer por la gran cantidad de información que sueltan. Pero tampoco lo acaba de solucionar. Muchos días después de haber lanzado este comando, me lo sigue haciendo.

Tengo varias ideas en mente.

Una: buscar alguna herramienta que sea capaz de poner en orden estos logs. Así, podría intentar quitar toda la paja y ver lo que realmente es importante. Al buscar algún sitio que diga cómo se pueden leer, me he encontrado uno que, aunque también lo cuenta, dice que para más detalles vayamos al KB de Microsoft. En general, vienen a decir lo siguiente. Después de lanzar la herramienta:

sfc /scannow
sfc /scannow
podremos encontrarnos los resultados en el fichero %windir%\CBS\CBS.log. Pero, como no es exclusivo de esta herramienta, hay que localizar sus resultados buscando el flag [SR] dentro del log. Para no tener que estar buscando, una forma sería hacer una búsqueda de éste utilizando la consola y forzar la salida a otro fichero en vez de a pantalla. El ejemplo que ponen (y que utilizaré cuando termine la ejecución) sería:

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

y a mirar lo resultados. Pero, no tengo mucha esperanza de que pueda encontrar el problema. Si así fuera, ya habría dejado de hacerlo. Vamos a ver: el resultado que he obtenido es más o menos similar a la anterior vez que lo lancé. Dice que hay "archivos dañados".  Y que "los reparó correctamente". Pero sigo igual:

sfc /scannow - finalizado
sfc /scannow - finalizado
Por lo tanto, una vez he creado el fichero sfcdetails.txt, y siguiendo el consejo de Microsoft, me he puesto a buscar la cadena Repairing corrupted file para ver qué encontraba. En efecto, han aparecido algunas cosas: una reparación de diskmgt.chm (un fichero de ayuda). Sale 4 veces, en 2 bloques de 2. Esto no puede ser lo que hace que se caiga el sistema. Además, el log es mucho, mucho más pequeño (sólo como reseña).

¿Qué otras cosas he hecho? He pasado un memtest. De esos que tienen los liveCDs. Tampoco me ha dicho que se hubiese producido algún error. Lo que sí que he visto que es que en vez de mostrar los 4096MB, mostraba unos 3962 (o por ahí). Vamos, la diferencia era más o menos de 128 MB. Cuando me puse a buscarlo hace una semana (cuando pasé ese memtest) me dio la sensación de haber encontrado que si la memoria gráfica está compartida con la RAM, podía suceder. Pero, a decir la verdad, no me ha quedado del todo claro si eso es cierto. O, al menos, que en ese caso eso sea posible. Si no fuera cierto, ya tendríamos la posible razón por la que me estuviese pasando.

Otra opción que se me ha ocurrido: algún driver no está del todo bien. O algún programa que se está ejecutando todo el rato. Sí recuerdo que me llegó a suceder al principio de los tiempos, cuando tenía el Norton instalado. Fue quitarlo y dejó de suceder. Esa sería otra vía de búsqueda. Lo primero que intentaría hacer el buscar algún software de workbench para ver si va logueando cada parámetro y se rompe en el punto que me está fallando.

Para esta opción de los drivers, lo primero que he encontrado ha sido el driver verifier manager, y después el driverquery. Pues he hecho las pruebas en sentido inverso. Primero he probado el driverquery, y después he configurado el driver verifier manager en mi equipo, con sus dos posts correspondientes. Con respecto a la primera herramienta mencionada en este párrafo, comentan los BSODs. A mi de momento no me salen, pero por si las moscas, voy a ver si consigo obtener información sobre qué está pasando para que me suceda este error.

Un buen tiempo después de haber escrito los párrafos anteriores (justo cuando escribí mis posts que referencio ahí), he descubierto que Sandboxie ha dejado de funcionar, y a su vez, no me ha vuelto a suceder el "apagón" a pantalla negra. Por lo tanto, puedo deducir que Sandboxie es el responsable de que la pantalla de mi Windows se quede de repente en negro, como si de un BSOD se tratase, pero en negro y sin letras.

Por lo tanto, y para resumir, las posibles soluciones a un comportamiento de este tipo son:
- Lanzar el sfc /scannow y mirar sus logs.
- Lanzar driverquery y revisar los drivers disponibles con sus estados.
- Tener activado una temporada el driver verifier manager.

viernes, 15 de marzo de 2013

Batería externa para móviles

Hace una semana que terminó la Rooted2013, tal y como pudisteis ver cuando os conté el primer, segundo y tercer (y último) día.

Como ya tuve problemas el año pasado y en las NoConNames a la hora de gestionar la batería, me dispuse a buscar algún trasto que me permitiera cargar el móvil allí, in situ, sin conectarlo en algún lugar donde me pudieran tangar el terminal (tal y como les sucedió el año pasado a algunos incautos que conectaron su móvil a unos cables sin saber [ni sospechar] que estaban conectados a un portátil).

Por lo tanto, mi primera idea fue intentar buscar algún aparato como una dinamo, tal y como se podían ver con los Nokias 3310:

Cargador de emergencia/manivela para Nokia 33XX
Cargador de emergencia/manivela para Nokia 33XX -  Foto original
Pero, buscando en un sitio de electrónica no lo tenían para el móvil que yo gasto. De hecho, creo que ya es complicado encontrarlo en tiendas físicas.

Por lo tanto, me decanté por ir al Media Mark. Allí, tampoco tenían, pero mientras que lo buscaba me encontré con uno como este:

Cargador externo usb Energizer
Cargador externo usb Energizer - Foto original
Por lo que fui a preguntar a la chica que de esa sección: 40 tantos pavos. Por la cara que puse cuando me lo dijo... Me dijo "Espera". Cogió otro y por el precio, y para el uso que necesitaba, me cogí ese "otro". 25 euritos.

¿Qué me llevé? Este pequeño trasto:

Sony CycleEnergy
Sony CycleEnergy
Prometen un promedio de 500 cargas posibles para el trasto en sí (por lo tanto, es susceptible de que se termine agotando) y dar 2 veces soporte por cada una de ellas. Es decir, que podrás cargar el móvil 2 veces por cada vez que cargues este cacharro. Como de costumbre, son promedios.

¿Qué tal me ha ido con esto? Dado que lo compré el miércoles, el jueves no salió del todo bien. Ayudó un poco, pero muy por los pelos. La primera carga no debió de ir muy fina o, como era de estreno, tenía que ajustarse un poco. También como lo cargué por el portátil... El segundo y tercer día, lo cargué por el enchufe, y, la verdad, bastante mejor. No me puedo quejar. 

No puedo dar más reseñas al respecto porque como sólo lo he usado para este fin... Ahora, vamos a plantear una pregunta. ¿No sería posible crear un aparatito de estos que, mientras que carga el terminal, copie los datos que hay en él? Mucho mejor si es el de otra persona. 

domingo, 10 de marzo de 2013

RootedCon 2013: Tercer (y últmo) día

Ya está. La RootedCon 2013 ha finalizado. Nos lo hemos pasado muy bien. Hemos descubierto cosas bastante nuevas. También le hemos dado una vuelta a otras ya conocidas... Pero: ¿Cuáles fueron?¿Qué nos enseñaron?¿Qué sucedió?

Además de encontrarnos con los mismos compañeros de las otras jornadas, algunos más, este es el resumen de lo que pudimos ver:

- José Picó y David Perez, de @taddong, nos mostraron cómo pudieron localizar un móvil a través de su señal GSM. Es decir: sin ninguna aplicación instalada en el mismo para encontrarlo. Funcionaría igual con un Iphone que con un magnífico Nokia 3310. Porque, esas son las dos formas de localizar un trasto de estos: por su señal móvil, o por software. Nos explicaron los distintos tortazos que se fueron dando a la hora de realizar su estudio. Uno tras otro, muy poco a poco, iban consiguiendo su objetivo. Una frase: "un trasto en encima del coche... Por muy lento que vayas... no te adelanta ni Dios".

- Después tuvimos a Joxean Koret: Herramientas de análisis de código. Lo suyo es que analicen tanto el código fuente como el binario. Aún así, cometen errores. Y tienen que tener cierta interactividad, parametrización para un programa en concreto. Las distintas técnicas en las que hay que analizar el código, como por ejemplo, utilizando árboles. Un ejemplo que nos puso es que para un programa pequeño, en el que sólo había una función, el análisis tardó casi tres horas. ¿Cuánto tardará en analizar un programa como el Adobe o el Office? Después nos mostró su herramienta.

Un descansito y... Román se disfrazó de pato!! "Ahora entiendo cómo se siente Juanito cuando tuvo que ponerse en pijama".

- Jaime Sánchez, @segofensiva, nos habló sobre (a ver si lo cuento bien) el kernel de linux. Nombramos iptables. Esta herramienta utiliza un target que es el NFQUEUE. Añadiendo ciertas entradas de este tipo al iptables y algo de programación, podremos conseguir crear un sniffer o, incluso, forzar a que un

nmap -O

devuelva un dato totalmente distinto al real. Por ejemplo, eso haría que un equipo con Windows Vista devuelva que es una impresora HP. También se pusieron ejemplos de port knocking o manipulación de DNSs.

- La RootedForge: cada participante tenía 5 minutos para explicar su proyecto. Ciertamente había pocos participantes para la cantidad de gente que decíamos que teníamos proyectos en mente. Shame for me! Los

Después, a comer!! Fuimos 15 personas a un VIPs. Evidentemente, entre unas cosas y otras, apenas dio tiempo a comer un plato, rápidamente. Pagar uno a uno, junto a la caja, y mientras que unos ya habíamos pagado (y nos íbamos pitando hacia el evento), los otros continuaban pagando. Mover a 15 personas es muy complicado.

- Ahora, Raúl Siles nos contaba cómo cada terminal móvil almacenaba y configuraba las redes móviles. Cada uno de los sistemas operativos más utilizados: Windows Phone, Android, iOS, BlackBerry, lo hace una forma distinta. Mientras que un SS.OO te deja configurar a mano algunos datos, pero otros datos no, otro SS.OO te permite configurar todos pero no los valida. Por poner un ejemplo. Lo mismo a la hora de eliminarlas. Creo recordar que era en iOS donde forzaba a estar conectado a la red que deseas eliminar. En caso contrario, ni te lo ofrece. ("Es la mejor forma de que te paguen un viaje de vuelta al hotel de 5 estrellas donde te conectaste para poderla eliminar"). Se habló de la herramienta iStupid. Si no me acuerdo mal, era la que creaba una red falsa para que el móvil se conectase a esta y así poderla eliminar. Aún hay más: war standing: escanear el aire, coger los probes que se van emitiendo para ver la lista de redes que buscan los dispositivos, y después impersonar una. Para realizar esta búsqueda: probesmon.py. También pudimos ver cómo se podía conseguir forzar la conexión de equipos corporativos suplantando servidores Radius y CAs. Es más: se llegó a decir que si esa empresa usaba una CA privada, era mejor que si usaba una pública (y conocida).

- Albert López nos habló sobre Linux heap exploting. No voy a negarlo: esta es una de las más me costó entender. (Si es que se nota las que más entendí y las que menos...)  Su ponencia trataba sobre un "estudio" que se hizo sobre el 2005, que se quedó ahí. Después 2008 o 2009 y ahora él lo amplía. Tuvimos términos como heap, arena, listas doblemente enlazadas (¡qué tiempos en los que estudiábamos los punteros!), la función RELBO, unlink... Nos hizo unas cuantas pruebas de concepto. Al final, pudimos ver cómo implementando su ataque, se podía conseguir una shell.

Se hizo un descanso en el que pudimos ver a a Wardog (@mundowdg) y a Chema Alonso firmar libros.

- El tiempo de la ponencia de Chema se utilizó en parte para que Wardog respondiese a preguntas sobre el libro que escribió y el otro tiempo para que Chema diera su ponencia. Basándose en lo que ya vimos tanto en el Asegur@IT Camp4 y en la NoConName 2012, añadió un punto más consiguiendo que las visitas a una página web con https se hiciesen en claro sin que el usuario se diera cuenta. Entre otras herramientas, utilizó la Evil Foca.

Y ahí finalizó la Rooted 2013.

Espero que el año que viene pueda volver a asistir, que además, si todo va bien, prometerá mucho más, dado que, entre otras cosas, se va a buscar un sitio mucho más grande. Y vosotros, los que habéis estado: ¿qué os ha parecido este año?

viernes, 8 de marzo de 2013

RootedCon 2013: Segundo día

Hoy el dia lo he comenzado demasiado pronto. Por intentar llegar bien, he llegado bien, bien pronto. Pero la espera ha merecido la pena.

Además de haber visto a @l0ngin0s, @dot_ike, @_Angelucho_, @Madrikeka, @Javiover y los demás, hemos tenido:

- Los hermanos Tarasco nos han presentado OWISAM. Una herramienta de auditoría de redes Wifi. su proyecto, que se puede visitar en owisam.org, es una herramienta de auditoría de redes wifi, desarrollada en C# y cuyo sistema operativo principal es Windows (más o menos la razón "porque estoy acostumbrado a las ventanas y a este sistema operativo"). Las siglas, Open Wireless Security Assessment Methodology. Mmmmh... Es que contarlo bien me va a ser complicado: Su trabajo viene después de que les solicitasen hacer un test de intrusión en caja negra. Se llevaron la sorpresa de que de todas las redes inalámbricas encontradas, 1500, la tercera parte eran desconocidas por la empresa contratante. En su estudio se encontraron que aunque un AP no enviase el ESSID, los había que enviándole un paquete determinado, devolvía información importante: como dicho nombre de red. Algunos de los routers inalámbricos afectados serían los de Linksys, los que llevan OpenWRT.... También se han hablado de dispositivos físicos para capturar información como pueden ser los keyloggers por hardware (keygrabbers), o, incluso, un aparato que lo han llamado APTWs. Es posible que me haya quedado con esta parte que es más técnica, cuando, posiblemente lo importante, sea la parte teórica: Las metodologías, controles... Aquí, yo lo estaba viendo como si se usasen métricas. Y eso me ha recordado a las métricas que se usan en.... ¿la ISO 27001?. De todas formas, en un tweet me han dicho que podíamos hablar. Posiblemente alguna cosa no la haya transmitido del todo bien en los muchos tweets que he enviado a lo largo del día. Bueno. Han dicho que quieren que la gente les ayude a mejorarla, ya sea dando ideas, nuevos módulos, traducción de la documentación... Mientras se montaba el siguiente equipo han enseñado en 15 segundos el resultado del scan de redes wifi del edificio.

- Jesús Olmos, aka @sha0coder, nos ha presentado una extensión para Chrome que permite realizar auditorías web: ataques de fuerza bruta para usuarios/contraseña, fuzzing, etc. Nos ha explicado cómo la ha integrado y las razones de tomar una decisión u otra para montarla de una manera o de otra.

En el descanso de la mañana, una vez más, zumos, palmeritas y, ¡cómo no!, las sabrosas... ¡conchas códan!.

- Los ataques de denegación de servicio distribuidos, DDOS, han sido analizados por David Barroso, @lostinsecurity. Hemos podido ver que los ataques se envían a las pymes, aquellas empresas que el hecho de estar fuera de Internet unos días puede ser su ruina. Aún así, también se atacan entre ellos, con el fin de tumbar a la competencia. Algunos datos interesantes pueden ser que la vida media de los paneles de control que manipulan estas bots tienen una vida media de unos 23 días; se han visto afectadas unas 3.500 direcciones. Aunque la mayoría iban contra el puerto 80, no quiere decir que tampoco el 22 (SSH) o el 3306 /MySql) entre otras tampoco lo sufrieran. Se ha hablado del bicho Pandora, sobre cómo funciona... El vídeo de un anuncio de un servicio para tumbar webs con el que nos hemos partido la caja. Un tipo de servicio que ayuda a mitigar este tipo de ataques son los CloudFares. Se ha recordado que la ley "obliga a resistir la extorsión". Y por supuesto, nunca pagar (si pagas una vez, te vuelven a atacar).

- Una vez más, Sebastián Guerrero, @0xroot, nos trae más peligros contra nuestros preciados Androids. Los peligros de tener LKM activado en el sistema operativo puede llegar a hacer que se ejecuten cosas no deseadas. Se han enseñado 4 demos, unas de una forma más rápida que otra (porque el inicio era el mismo y sólo cambiaba el final). Total: que puede conseguir debuguear una app, meter malware, bypasear un antivirus ("menos AVAST,  ninguna comprueba el LKM"). Y si se usa todo esto con algún juego hecho a tal efecto, aplicando el tapjacking, que ya lo explicó el año pasado... Lo tenemos todo... ¿perdido?

Ahora, nos vamos a comer. De hecho, nos hemos encontrado con el miso restau del año pasado. Es la típica casa de comidas con el menú a elegir entre varios primeros, varios segundos, postre... Yo he pasado de ese menú y tanto Longinos como Oscar como alguno que otro más nos hemos pedido unas hamburguesas... ¡Qué buenas! Hala. Ya comidos, otra vez al edificio de la Mutua para empezar la siguiente charla.

- @pepeluxx, Jose Luis Verdeguer, nos ha presentado su charla sobre FreePBX. Lo puedo resumir porque ya contó algo muy similar en la NoConName del año pasado: centralitas PBX con acceso desde Internet. Vulnerabilidades que tienen a la hora de controlar quién está accediendo, qué introducen en los cuadros de texto... Total, que al final se puede llegar a conseguir acceso a la centralita entera y manipularla para hacer llamadas "gratis" (a cosa de la empresa comprometida). Teniendo en cuenta que según qué instalación se queda un usuario "root" sin contraseña en la base de datos. Los ficheros que se instalan en el Apache son del usuario "asterisk", el mismo que está accediendo (por lo que puede abrir los ficheros de configuración de la aplicación web). También podrá llegar a acceder a los ficheros que se encuentran bajo /etc/ por la misma razón... Hay muchos servicios de este tipo accesibles por Internet cuando indican explicitamente que no se haga...

- Después hemos conocido a Roberto Rabatta, con su exposición sobre eCrime: es gestor de fraudes en NovaGalicia.  ¿Qué fraudes? Por ejemplo: phishing. Se ha puesto de ejemplo que si la usabilidad es buena, la seguridad baja y viceversa. Sobretodo a tener en cuenta que "si no hay un empleado atendiendo, cuesta más" (más o menos se ha dicho esto). ¿Qué objetivos se miran: el negocio o la seguridad? Nos ha mostrado ejemplos de denuncias reales (tapando los datos confidenciales), pero se ven ejemplos en que aunque el usuario a tenido la culpa, éste estaba pidiendo al banco que le pagase lo que se sustrajeron. Nos ha explicado que para eso tiran de un seguro contratado para esos efectos. También tienen que mirar lo que les permite hacer la ley, o el negocio... Hay cinco términos a tener en cuenta: prevenir, detectar, detener, corregir y evaluar.

Tras la charla, hemos hecho un descanso (con algo para merendar).

- Ya, la última parte, ha sido la mesa redonda: una vez más, se ha hablado del futuro. En esta ocasión, se ha hecho mucho incapie en lo que es un emprendedor y si se puede o no emprender bien en España, si dejan emprender... Como de costumbre, ha habido opiniones para todo.

Y esto ha sido lo que hemos podido ver en la Rooted2013 en el día de hoy. Mañana más... Además, será la última jornada.

RootedCon 2013: Primer día

Hoy ha comenzado el primer día de la RootedCon 2013. Ya es el cuarto año que se celebra. Un año más, se ha realizado en la sede de la Mutua Madrileña, en el Paseo de la Castellana (junto al metro Rubén Darío).
Como el resto de años (aunque esta es mi segunda vez), nos hemos encontrado con problemas con los enchufes. No había. Por lo que se ha tenido que ser muy austero con la batería del móvil.

Importante. Antes de indicar lo que han presentado, nombrar a Longinos (@l0ngin0), Oscar (@dot_ike), Javi y Angelucho (de la Guardia Civil, Grupo de Delitos Telemáticos), Jorge y Umberto (del Asegur@It Camp 4) y a los demás compañeros.

Ahora, ya sí. Resumiendo el evento, esta ha sido la agenda de hoy:

- Keynote: Es la presentación del evento. Más que presentación, es la inauguración del mismo. Se presenta cómo se han escogido las ponencias, quienes forman parte del equipo de la Rooted, agradecimientos a los sponsors, patrocinadores, voluntarios... Poco más se puede contar al respecto.

- David Fuentes hace una ponencia sobre lo que ha llamado "señales débiles". Se pueden definir como "el reflejo" de lo sucedido, por ejemplo, en una incidencia. También se ha mencionado la archiconocida frase de "el eslabón más débil es el usuario". O, frase twiteada por Borja Berástegui, parafraseando a David, "hace falta invertir en materia gris, personas que manejen la (sic del tweet) herramientas". Una prueba de concepto se ha montado (con efecto demo incluido), usando poison ivy y crimepack.

- La siguiente ponencia, por parte de Vicente Díaz aka @trompi, nos ha hablado de fraude en twitter. Ha hecho una investigación sobre los bots que están pululando por esa red social. Razones por las que ponen enlaces (campañas publicitarias, recolección de datos personales, etc) en los que al final , lo que se desprende, es que el los envía es porque suscribe ese "enlace" a un pay-per-click. Total, por cada dato personal obtenido, consigue pelas. Para ello, el atacante, puede recurrir a dichos bots, cuentas falsas con una vida media de 45 minutos, robo de credenciales... Su investigación la ha hecho con un programa hecho en ¿python?¿perl? "No asustarse de la IA", "En internet nadie sabe que eres un perro". Estas han sido frases que he conseguido twittear durante la ponencia.

- Desayuno con, como no, conchas codan y zumito.

- Ponencia de Míkel Gastesi, aka @mgastesi, y Jose Miguel Esparza, @EternalTodo, nos han hablado de SepolkaSopelka y EurograberEurograbber. También han hablado un poco de otros bichos también conocidos: Stuxnet, Flame... Sobretodo la ponencia iba de los dos primeros. Los otros eran meramente comentados. La idea era echar un poco por tierra el cómo se hizo el informe sobre los supuestos 36 millones de euros que se habían robado con Eurograbber  Así, muy resumido, un informe de 17 páginas, con muchos pantallazos, datos repetidos, y que los autores no pueden justificar una posible alternativa. Por ejemplo, dudas sobre por qué se dice que se robaban entre 250€ y 250.000€ y hay lugares de los pantallazos donde se pueden ver 3€ y pico. O cuentas en las que teniendo números rojos, se les ingresaba 5000€. Update: Para ser más puntillosos con lo que he tachado: en el informe se veían cantidades de entre 250 y 250.000€, en el que suponía que eran transferencias, aunque realmente pueden ser cantidades en las cuentas. Incluso, aparecía una cantidad de ~25.000€ en negativo. Por lo tanto, si esas cantidades eran transferencias, esa cantidad negativa sería una transferencia a la víctima. En general, y muy resumido, pudimos ver cómo el informe estudiado no tenía ningún fundamento. Agradecer a Jose Miguel que me haya aclarado estos puntos que, visto lo visto, no los pillé (o he explicado) del todo bien.

- Hemos continuado con Antonio Ramos (no es Alejandro Ramos, que irá más tarde). Nos ha explicado conceptos de contabilidad, aplicados a la seguridad, de una forma muy comprensible por nosotros, y muy divertida. Por ejemplo, "un contable es un log". O, también, un auditor informático al director "necesitamos X€ en seguridad". El director, "no te preocupes, asumo el riesgo". Hasta que el riesgo toca su propio bolsillo. Otra frase: "El dinero negro es un 0day. Nadie sabe que está ahí". Después de las preguntas, nos vamos a comer.

- Una vez comidos, los compañeros de Flu-project Juan Antonio Calles (@jantonioCalles) y Pablo Gonzales (@fluproject) han presentado Flu-AD. Es una nueva versión de su bichito Flu que está montado bajo mínimos (50KB), y que después éste se va bajando los módulos que se vayan necesitando según las fuerzas del orden y seguridad del estado le indiquen al panel de control. También, tal y como han conseguido manejar la descarga de las DLLs, y su posterior montaje, se ha conseguido que ningún antivirus lo detecte (hasta el momento). De las personas a las que le han agradecido la ayuda está Germán Sánchez. Me dejo a otra persona más que no la tengo apuntada. Sorry. :(

- Después de Flu, viene Alejandro Ramos, a presentarnos SQLite: El almacenamiento de datos de dispositivos móviles. Cómo se podrían recuperar los datos borrados por el mero hecho de estar fragmentados. Y cómo evitar esa fragmentación: VACUUM es un comando que se ha de ejecutar después del borrado de un registro de esta "base de datos" light. Nos ha presentado la herramienta que han montado para recuperar los mensajes, fotos, etc de estos dispositivos.

- Después de recuperar datos borrados de los smartphones, viene David Meléndez Cano, @taiksontexas. Nos ha presentado sus dos robots home made. Ha utilizado varios routers que tenía por ahí en su casa. Alguna web cam, alguna pieza de 20€ cada una... y eso que un dron que nos ha enseñado tiene mínimo dos.  Muy chulos esos cacharros. Eso sí, los 4 años que ha dedicado en ambos.... Un trabajo de chinos.

- Por último, la RootedPanel 1. Es decir: la primera mesa redonda (como dice el chiste: que es rectangular) de la temporada. ¿Se trabaja mejor "en casa" o hay que emigrar a otros países?. ¿En esos países se hacen las entrevistas igual que aquí en España?¿Exigen las mismas cosas?

Y aquí ha terminado la primera jornada de la Rooted 2013. El viernes (como esto está escrito entre medas de los dos días...), tendremos más. Seguro que sale igual de bien que la anterior.

miércoles, 6 de marzo de 2013

Drivers problemáticos: driver verifier manager

Haciendo una búsqueda para comprobar los drivers, me he encontrado con una herramienta del sistema que se llama driver verifier manager. Todo esto que estoy haciendo es para (intentar) solucionar un problema que me lleva trayendo de cabeza durante mucho tiempo y del que más adelante tendréis un post al respecto. De hecho, iba a pasar un poco por encima para explicarla y al final, voy a escribir este artículo explicitamente para contarla.

Para lanzar esta herramienta hay que ejecutar (por ejemplo, desde inicio-->buscar--> verfier verifierverfier.exe verifier.exe:

Driver verifier manager, Administrador del comprobador de controlador
Driver verifier manager, Administrador del comprobador de controlador
Como habréis podido comprobar, es la primera vez que la voy a utilizar, con todo lo que ello conlleva. Mi idea es la siguiente: crearé una configuración estándar:

Creando una configuración estandar
Creando una configuración estandar
Hay alguna que otra cosa que me interesa comprobar. Puedo tener mis sospechas de por dónde pueden ir los tiros. Por lo que, aún pudiendo tener controladores no firmados, voy a obviar esa opción. También podría seleccionar la opción de "controladores para versiones anteriores de Windows". Pero, sólo me sale uno. Por lo que también lo voy a obviar. Aunque me he sentido tentado, no voy a poner todos los controladores. Por lo tanto, seleccionaré de una lista los que me interesen:

Seleccionando drivers
Seleccionando drivers
Aquí también estará el único que se encontraba como "para versiones anteriores de Windows".

Una vez terminada la configuración, habrá que reiniciar el equipo para que los cambios sean efectivos (yo, de momento, me esperaré a otro momento para reiniciar). Una vez configurado, habrá que esperar que se produzca el error y cruzar los dedos que sea alguno de los drivers que he seleccionado. 

Pase lo que pase, hay que acordarse de desactivar esta configuración en el momento en el que se de por perdido o cuando se obtenga la información deseada. 

lunes, 4 de marzo de 2013

Buscando drivers con DriverQuery

Realizando una investigación para publicar aquí, me he encontrado con un comando que se llama driverquery. Este comando, según he podido averiguar, hace un listado de los drivers que hay en el sistema que se le pase como parámetro (o sin el, será el mismo equipo donde se esté lanzando). Los parámetros son sencillos. Así lo ejecutaríamos:

driverquery [/s Computer] [/u Domain\User /p Password] [/fo {TABLE|LIST|CSV}] [/nh] [/v] [/si]
Por poner un ejemplo, podríamos lanzar

driverquery /fo CSV /v

Al ejecutar ese línea, obtendríamos esto:

driverquery /fo CSV /v
driverquery /fo CSV /v
Tal y como se puede ver, no hay quien se entere de nada. ¿Y si en vez de CSV lo hicíesemos con salida en formato table?

driverquery /fo table /v

Por lo que la salida sería esta:

driverquery /fo table /v
driverquery /fo table /v
Y obteniendo la salida en formato lista:

driverquery /fo list /v

tenemos:

driverquery /fo list /v
driverquery /fo list /v
El mayor problema que podemos tener a la hora de sacar estos datos es que el buffer del cmd se puede acabar antes de terminar de mostrar toda la información, por lo que perderíamos las primeras líneas. Así, si tomamos de partida la primera prueba que hemos hecho, podríamos redirigir la salida a un fichero y después abrirlo con otro programa. Por ejemplo:

driverquery /fo CSV /v > driverquery.csv

Y lo abrimos con algún programa de edición de hojas de cálculo:

Abriendo fichero CSV: driverquery.csv
Abriendo fichero CSV: driverquery.csv
La verdad, está muy bien tener en cuenta este comando. Sobretodo si se necesita información sobre los drivers que hay en el sistema. La verdad, a simple vista parece mucho mejor este comando que no ejecutar

sc query type= driver

en el que obtendremos un resultado en bloques similar a tercer ejemplo de arriba:

sc query type= driver
sc query type= driver
Si lo ejecutas, ojo al espacio (es importante). 

Así, a ojos vista, parece que es mucho más manejable la información utilizando driverquery y enviándola a un fichero externo. 

Espero que si en algún momento os hace falta buscar los drivers instalados, os sea de mucha utilidad.