Security Art Work

Hoy nos hemos levantado con una noticia a la altura del reciente Heartbleed: una vulnerabilidad en el intérprete de comandos Bash permite la posibilidad de ejecutar código remoto en la máquina. Esta vulnerabilidad ha sido catalogada como CVE-2014-6271 con una puntuación de CVSS de 10.

Están afectadas todas las versiones hasta 4.3 incluida. La vulnerabilidad se produce cuando el intérprete no procesa adecuadamente las variables de entorno. Mediante la declaración de funciones puede incluir al final código que será ejecutado independientemente del nombre de la variable; esto es especialmente crítico en servidores web que tengan instalados módulos CGI. Una forma rápida de comprobar si somos vulnerables o no es ejecutando el siguiente código:

env x='() { :;}; echo vulnerable'  bash -c "echo prueba en bash"

En ambos casos aparecerá lo último por pantalla ‘prueba en bash’. Si se muestra por pantalla la cadena de texto ‘vulnerable’, nuestra versión de bash estará afectada ya que ha seguido ejecutando el código añadido a la cola de la función; por el contrario, si vemos el siguiente mensaje de error, quizá no seamos tan vulnerables:

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x’

La última frase no se ha dicho de forma arbitraria: pese a que ya ha sido publicado un primer parche, una investigación en profundidad del mismo ha demostrado que aún tiene posibles vectores de ataque, por lo que habrá que esperar a una nueva actualización para poder decir que ya está completamente solucionado.

Más información:

• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
• https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271 (módulo Metasploit)
• http://www.volexity.com/blog/?p=19

Al hilo del reciente post “Seis más una medidas para la seguridad sin concienciación”, sería fácil concluir que la seguridad corporativa sin concienciación, no es una opción.

Frecuentemente, las políticas de seguridad de las empresas, si existen, son una entelequia: Casi todos los empleados saben que existen y sólo unos cuantos saben alguna de ellas y de estos, sólo unos pocos se preocupan por aplicarlas convenientemente.

Sin embargo, la importancia de las políticas es clave para proteger los activos de la compañía, más si cabe cuando en los últimos años la información de la empresa fluye alegremente a través de dispositivos móviles, tanto los que siguen el modelo COPE (CompanyOwnedPersonallyEnabled), como el modelo BYOD (BringYourOwnDevice) en los que se entremezcla el uso profesional con el uso personal.

Si pudiéramos pedir un sistema para promover convenientemente las políticas de seguridad de la empresa, puestos a pedir, tendríamos la siguiente lista de deseos:

• Que habilite la concienciación de las políticas de seguridad de la empresa pero sin la necesidad de leernos un documento infumable. Ya por pedir, que nos permita aprender sobre la marcha, con recomendaciones sobre la mejor forma de proceder en cada situación.
• Que sea multi-dispositivo, es decir, que nos permita utilizarla tanto en smartphones y tablets, así como en nuestro portátil.
• Que en determinados casos, permita realizar un análisis de riesgos de cada situación, incorporando el concepto de oportunidad para equilibrar la acción más adecuada desde el punto de vista de la organización.
• Que no nos moleste continuamente y que tenga como objetivo principal el usuario. Lo ideal sería que apenas nos diéramos cuenta de que existe este sistema y tan sólo nos dé recomendaciones en situaciones en las que haya un alto riesgo para un activo concreto.

Dicho esto, como usuarios del sistema, aún nos faltaría algo muy importante:

• ¿Qué hay de nuestra privacidad?
• ¿Qué tipo de interacciones monitorizaría este sistema?
• ¿Está nuestra información personal a salvo?

El deseo final sería por tanto que solamente recopile la información necesaria para garantizar el cumplimiento de políticas y no almacene información personal.

Pongamos un ejemplo para dejarlo más claro: Si la política de seguridad indica que no instalemos una aplicación de lista negra, el sistema debe monitorizar sólo si esta aplicación está instalada en el dispositivo y descartar la información relativa al resto de aplicaciones instaladas.

En cuanto a la información que le debe llegar al Responsable de Seguridad, esta deberá ser convenientemente cifrada, ya que lo importante no es quién estuvo cerca de incumplir una política, sino que la acción que pone en peligro la información de la empresa no se lleve a cabo, sea quien sea el que lo intentó.

El objetivo, por tanto, no es un sistema que controle a los usuarios para darles una reprimenda, sino que el sistema automatice ese control por medio de recomendaciones. Dichas recomendaciones se traducen en la evolución de la cultura de la empresa, en la que poco a poco se introduce el conocimiento de las políticas de seguridad, de una forma progresiva y automática. En mi opinión, mucho más llevadero que tener que leerse un documento formal, con la ventaja de que con el documento no siempre es fácil relacionar nuestras tareas diarias con cada una de las políticas.

Todos estos deseos, y algunos más que van surgiendo por el camino, son los que pretendemos cumplir en el proyecto MUSES, cuyo lema es “Corporatesecuritywiththeuser at heart”, coordinado por S2 Grupo y en el que colabora con socios de varios países europeos (Suecia, Alemania, Austria, Suiza, Bélgica, Italia y España).

La posibilidad de compartir el proyecto hacia la creación de una comunidad open source es una de nuestras principales metas. Por lo tanto, cualquier desarrollador es bienvenido en participar en esta experiencia open source, a través de la participación en nuestro proyecto GitHub.

A partir de este post, os iremos informando de las novedades del proyecto, pero no olvidéis seguir el proyecto en twitter (@MUSESproject) y facebook (MUSES Project).

El éxito es un trayecto, no un destino. Os mantendremos informados durante el camino.

Jugando un poco con Google Apps Script, que es un entorno de scripting de gran alcance proporcionado por Google, se pueden hacer solicitudes autenticadas contra los datos de un usuario en Google.

Al autorizar una aplicación de Google, los usuarios están permitiendo a una tercera parte el acceso a sus datos, por lo que los ataques de ingeniería social resultan demasiado fáciles, debido a que se encuentran alojados en un dominio de Google, incluso los usuarios experimentados que buscan dominios sospechosos pueden ser engañados.

Después de la autorización de la aplicación, un usuario malintencionado puede, subir el correo electrónico del usuario a un medio externo, borrar datos, o acceder a la información personal a través del API de Google.

Cómo funciona
Aquí está un simple Google Apps Script que hice. Que se encuentra alojado en Google.

Una persona malintencionada podría hacer un script usando “https://script.google.com” para que realice cualquier acción en contra de los datos de Google de un usuario. A continuación, compartí el enlace con la apariencia de una herramienta útil. Desde la URL script.google.com, parece legítimo e incluso los usuarios experimentados es probable que se dejen engañar.

Nombré mi aplicación “Actualización de seguridad de Gmail”, pero podría llamarse de cualquier otra manera.

La capacidad del atacante para asignar el nombre de la aplicación es muy peligrosa. Para este post usamos como nombre “Actualización de seguridad de Gmail”. Cabe destacar que Google de ninguna manera deja claro que esta aplicación fue creada por una tercera parte, durante el proceso de autorización de la aplicación.

El usuario aprueba la aplicación, ya que parece completamente legítima:

Una vez aprobada la aplicación, en este caso solo envía los 10 primeros correos de la bandeja de entrada a la papelera, pero podría haber borrado todos los emails, leer todo el correo electrónico, reenviar correos, o acceder a la información personal a través del API de Google y enviarla a una tercera parte.

La comunicación efectiva de Seguridad a veces resulta difícil, pero considero fundamental comunicar al usuario los riesgos implicados al autorizar alguna aplicación, Google podría agregar una advertencia importante en el cuadro de autorización de la aplicación.

Dicho esto, veo complicado que un usuario común o quizás algún usuario más experimentado, entienda que se puede ejecutar código malicioso estando dentro del dominio de Google. Irónicamente después de autorizarla Google envía un correo electrónico explicando que una aplicación de una tercera parte ha sido autorizada, pero a estas alturas es, muy tarde la aplicación ya ha tenido acceso a los datos del usuario, y se ha eliminado, robado o manipulado.

Detalles adicionales
La aplicación creada para este post “Actualización de seguridad de Gmail”, simplemente contiene este código:

URL de la aplicación Actualización de seguridad de Gmail(CUIDADO)

API de Google Scripting

Aplicaciones autorizadas en tu cuenta de Google

Hace unos días, a propósito de la llamada de unos técnicos falsos de Microsoft, nuestro compañero Raúl advertía sobre la necesidad de concienciar a los usuarios, tanto personales como profesionales (cada uno tiene una cosa que perder) en los aspectos más de seguridad. Como este es, en general, un blog del ámbito profesional, me permitirá que abandone a los usuarios domésticos a su suerte o a la de su primo informático, y nosotros nos quedemos en el entorno corporativo, que es el que nos atañe.

La cuestión es que la entrada de Raúl me trajo a la memoria una serie de medidas que, allá por el 2007, propusimos en este blog como contrapartida a la concienciación. Es más, como le indicaba en aquel caso, puedo garantizar que con la aplicación gradual de todas ellas podemos reducir prácticamente en un 100% cualquier tipo de fuga de información o problema de seguridad, sin invertir un euro en concienciación. Eso sí, le advierto que el camino no es sencillo.

La primera medida es, como no podría ser de otra manera, inhibir cualquier medio de extracción de información mediante dispositivos o soportes de almacenamiento. Será necesario por tanto inhabilitar los puertos USB, además de desinstalar cualquier grabadora de CD o DVD. Por experiencia le diré que tendrá que lidiar con las quejas de algunos usuarios reticentes a cambiar sus hábitos, pero a la larga el beneficio compensa la molestia. Son, cómo decirlo, esas pequeñas molestias que te hacen el día diferente; pequeños contratiempos sin mayor importancia. Se acabaron al fin los virus que nos llegan por ese USB que vaya a saber usted dónde ha estado antes.

La segunda medida lógica en este proceso es cortar el correo electrónico. Así, de raíz. Porque todo el mundo sabe que no hay mayor peligro que el e-mail. Potencialmente, cualquier empleado malintencionado o un equipo controlado remotamente podría estar utilizando este sistema para mandar información confidencial a cuentas privadas, a potencias asiáticas, a la competencia o incluso a su primo el informático. Además, de esta forma acaba usted de un plumazo con las herencias africanas, las validaciones de seguridad bancaria de bancos en los que no tiene cuenta y las fotografías subidas de tono de la celebrity de moda en formato ejecutable. Así que corte el grifo. No email, no risks.

Ya nos hemos ahorrado muchos problemas, pero no podemos cejar en nuestro proceso de bastionado corporativo. La tercera medida es eliminar el acceso a Internet. No sólo evitaremos el acceso a webmails gratuitos, que son un potencial peligro, sino que evitaremos que un empleado malintencionado o un potencial atacante utilice alguna alternativa como el ftp, ssh o servicios cloud para extraer información. Esta medida también carece de complejidad: Deny ALL from ALL. O puede simplemente arrancar el cable o apagar el router de salida. Es así de simple. Se acabaron los ataques de denegación de servicio, los escaneos de red y cualquier cosa que se le ocurra. Internet ya no sabe que usted existe, ergo no le puede atacar. En este caso las quejas serán algo más enérgicas, especialmente cuando el personal de Administración no pueda conectar a la banca electrónica para realizar las transferencias de las nóminas. Sin embargo, dígales que para eso están los cibercafés. Nuestro objetivo es, ante todo, proteger la información corporativa, no las nóminas del personal.

Seguimos. Si piensa usted que cerrando los USB, el acceso a Internet y el e-mail está a salvo de la fuga de información, está muy equivocado. La cuarta medida es la eliminación de cualquier fax, teléfono, tablet, cámara y dispositivo de cualquier tipo que permita registrar, grabar, transmitir, anotar, fotografiar, enviar o extraer información interna, de cualquier manera. Sí, será necesario que confisque los teléfonos móviles de los empleados y cualquier visitante: clientes, auditores, políticos o hijos de los empleados, si se da el caso. Somos conscientes de que eso puede generar algún ligero malestar entre el personal, pero nada que la promesa de una organización más segura no pueda compensar. Al fin, ya no hemos de preocuparnos de que la información salga por vía telemática, telefónica, electrónica o cualquier otro medio. Estamos llegando (casi) al final.

La quinta medida es eliminar las impresoras y cualquier tipo de material en el que y con el que se pueda escribir, copiar, dibujar, etc.: lápices, bolígrafos, folios, libretas, etc. Nunca podemos estar seguros de que alguien no va a copiar a mano, sin ninguna mala intención, un diseño del último transatlántico que su empresa está fabricando o el listado de nombres y apellidos de los dos mil empleados, y va a acabar perdiendo la hoja con esa información en el metro. Todos sabemos que hay gente muy rara por el mundo, y como suele decirse, mejor prevenir que curar. Por supuesto, deberá cortar el correo postal. De salida, porque no tiene sentido, y de entrada, porque seguro que ha oído lo del Anthrax, ¿verdad? Pues eso.

La sexta (y penúltima) medida viene prácticamente derivada de las dos anteriores. Le hemos aconsejado que prohíba los dispositivos de grabación como los smartphones, y se deshaga de los lápices. Pero, ¿cómo estar seguro de que esa medida se cumple? Piense que un competidor disfrazado de hijo de empleado podría entrar con un móvil en el bolsillo. Pues para evitarlo, es necesario que en el acceso a nuestra organización pongamos dos guardias de seguridad para llevar a cabo cacheos exhaustivos del personal (a la entrada y a la salida, por si quedan dudas). Si además instala los sistemas de seguridad que se utilizan en los aeropuertos estadounidenses, mejor que mejor. Así, hemos llegado casi al final de nuestro recetario de seguridad.

La séptima (y última) medida está relacionada, como no podría ser de otra manera, con las personas que se mueven por su organización. De nuevo, empleados, visitantes, clientes, etc. Si no estaba al tanto, debe saber que cualquiera de ellos está capacitado para memorizar información en su propia cabeza (sí, está demostrado), que luego podría difundir. Por razones que no vienen al caso, no podemos aconsejarle que impida la salida de las personas de su empresa una vez han entrado, ni que tome acciones más “expeditivas”, así que dado que esa no es una opción, debe impedir bajo cualquier concepto que cualquier persona tenga cualquier tipo de acceso a la información. Ya sabe: cualquier persona a cualquier tipo de información. Es decir, no deje que nadie, nunca, de ningún modo, acceda a su organización.

Con estas sencillas y útiles medidas comprobará que, sin invertir lo más mínimo en concienciación, su empresa está totalmente a salvo de cualquier problema de seguridad de la información y por extensión, de cualquier otro tipo.

Hace unos días recibí en una de las cuentas de correo un fichero “.apk”, una extensión que como los lectores sabrán, corresponde a las aplicaciones Android. Como no acaba de ser normal —al menos en mi caso— eso de recibir una aplicación de Android por correo electrónico, lo que hice fue desconfiar y me puse a trastear un poco.

Lo primero una pequeña búsqueda en www.virustotal.com de MD5 nos revela que efectivamente se trata de un virus:

https://www.virustotal.com/es/file/bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d/analysis/

Lo siguiente es mirar el fichero Manifest para ver qué permisos solicita la aplicación. Para ello utilizaremos la aplicación apktool, un programa java que es muy sencillo de instalar:

apktool d foo.apk

Este comando creará una carpeta con varios ficheros, entre los cuales estará “>AndroidManifest.xml. Podemos observar que prácticamente pide todos los permisos.

Las aplicaciones Android son en realidad aplicaciones java, pero hay que modificarlas un poco, así que el siguiente paso es decompilarla. Para esto tenemos que convertirla a un fichero .jar, mediante el programa dex2jar

dex2jar.bat foo.apk

Ahora simplemente tenemos que utilizar la herramienta java decompiler para ver el código de programa.

Como podemos ver, parece que el virus hace casi de todo. Una de las cosas que siempre busco a la hora de hacer un análisis de este tipo es localizar hacia qué dominios contacta, y en este caso aparecen dos:

Si queremos ir más lejos y hacer un análisis dinámico podemos usar la sandbox online Anubis.

Hace unos días recibí una llamada de socorro de un familiar, de estas que te hacen temblar porque esperas que te diga que tiene un montón de virus en el ordenador, en el móvil o en el aire acondicionado. Sin embargo, resultó que se trataba de un caso típico de estafa o “phishing telefónico”, ataques que no deja de sorprenderme que sigan siendo efectivos.

En este caso, el ataque se inicia con la llamada por parte de un falso técnico de Microsoft. Ya había leído con anterioridad acerca de cómo actúan y qué hacen, pero me llamó la atención el grado de dispersión de este tipo de actividad, hasta el punto de llegar a personas cercanas. En 2012 ya había informes y reportes de especialistas de nuestro gremio que habían tenido la oportunidad de analizarlo, como el que se cita en este enlace de Viruslist. En éste, podemos repasar en detalle cada uno de los pasos que ejecutan los delincuentes.

1.- En primer lugar, el atacante realiza una llamada directa a la víctima, donde se identifica como un técnico de soporte de Microsoft. Que evidentemente, no lo es.

2.- A petición del atacante, la víctima accede a realizar una serie de comprobaciones falsas que le convencen de que su equipo está en peligro.

3.- Tras esto, el falso técnico convence a la víctima de que instale en su equipo una aplicación que le servirá para acceder de forma remota a su equipo y de esta manera solucionar su falso problema.

4.- Una vez instalado el malware, el atacante ya es capaz de acceder de forma remota e instalar cualquier tipo de malware, o incluso pedir dinero por los “trabajos” que han realizado.

5.- Por último, la víctima accede a pagar una cantidad de dinero (250$) mediante PayPal, VISA, u otros medios de pago.

En el caso de mi familiar, gracias a las advertencias que les suelo hacer (aunque muchas veces se olvidan), tuvo el nivel suficiente de desconfianza para sospechar, no caer en la trampa y colgar el teléfono. Me comentó que la llamada era de una persona que comenzó hablándole en inglés, y que al no entenderlo muy bien, apenas fue capaz de decir en castellano que tenían indicios de que estaba infectado su ordenador y por tanto corría un grave peligro.

He de reconocer que me sorprende que una persona confíe en un extraño que le llama por teléfono hasta el punto de de dejarle “meter mano” a su ordenador, y además, que pague una cantidad de dinero por los trabajos realizados. Pero esas cosas, por desgracia, siguen sucediendo.

Pero imaginemos que la persona que recibe la llamada, en lugar de estar en su casa, está sentado delante del PC de su empresa. La tecnología no ha llegado al punto de detectar este tipo de ataques, así que no hay firewall o IDS que detecte estas llamadas. En ese caso, si la persona no está lo suficientemente concienciada en materia de seguridad, es probable que facilite la instalación de troyanos y puertas traseras en los sistemas corporativos.

Sirva este breve post para alertar a los lectores de este tipo de ataques y que nunca es tarde para alertar a tus amigos y familiares, aunque parezca uno un poco paranoico. En mi caso, creo que esperaré el momento de recibir esta llamada para pasar a la acción.

Se han identificado recientemente multitud de aplicaciones Android vulnerables a ataques del tipo Man-In-The-Middle (MITM) bajo SSL, permitiendo a un atacante obtener la información transmitida entre el dispositivo móvil y el servidor.

En Fireeye han analizado 1.000 aplicaciones disponibles en Google Play y de ellas el 68% fueron identificadas como vulnerables. En el análisis se detectaron las siguientes tres casuísticas, que provocan un error en el manejo de las sesiones SSL/TLS conllevando a que un atacante puede realizar un ataque MITM.

• El gestor de confianza no verifica la cadena de certificados del servidor remoto, al no comprobarse si los certificados se encuentran firmados por una Autoridad de Certificación (CA).
• Se permite reemplazar el servidor remoto, dado que no se verifica el nombre del servidor, verificándose únicamente si el servidor dispone de un certificado, independientemenete de si es autofirmado o generado por una CA.
• Se ignoran errores en la negociación de las sesiones SSL al emplear Webkit.

Al revisar las estadísticas de Fireeye podemos observar:

• El 73% de las 664 aplicaciones no revisan los certificados de los servidores.
• El 8% de las 50 aplicaciones no verifica el nombre de los servidores.
• Y un 77% de aplicaciones de las 285 analizadas ignora los errores SSL generados al emplear Webkit.

Ahora bien, ¿qué impacto o consecuencias pueden suponer estas vulnerabilidades en nuestro dispositivo móvil?

Tras los análisis llevados a cabo, dependiendo de la aplicación que tengamos instalada podemos sufrir las siguientes consecuencias:

• Extracción de fotos almacenadas.
• Extracción de las credenciales de acceso de la aplicación.
• Extracción de credenciales de acceso de redes sociales (Facebook, Twitter…)
• Asimismo, hay aplicaciones que pueden llegar a permitir a un ataque inyectar imágenes o aplicaciones maliciosas, así como Denegación de Servicio (DoS).

Pero no únicamente se han detectado aplicaciones vulnerables a MITM, también existen librerías que permitirían obtener información sensible, como puede ser la ubicación o el código IMEI.

Estas detecciones nos hacen plantearnos las siguientes preguntas, ¿cuál es nuestro nivel de seguridad hoy en día en nuestros dispositivos móviles? ¿Podemos confiar ciegamente en las aplicaciones de Google Play?

Este descubrimiento pone en peligro la seguridad de nuestros dispositivos móviles, en especial los dispositivos de Android, y por consiguiente la confidencialidad de la información que manejamos en ellos (correo electrónico personal y/o profesional, credenciales a redes sociales, datos bancarios etc.).

Los desarrolladores ya están informados de las vulnerabilidades y esperamos que se apliquen las medidas correctivas cuanto antes. Aún así, como usuarios, nosotros también debemos aplicar medidas preventivas, especialmente en las redes wifi, dado que es en ellas donde podríamos sufrir este tipo de incidentes de seguridad. Hay que recordar que nunca sabemos quién puede estar detrás analizando el tráfico que enviamos en este tipo de redes.

Por otro lado, estas detecciones recientes ponen en entredicho la seguridad de las aplicaciones de Google Play, y por consiguiente el sistema Android. Este tipo de incidentes puede incluso llegar a hacer que nos decantemos por uno u otro dispositivo. Esto está siendo aprovechado hoy por hoy por Apple en su sistemas iOS, queriendo dar la sensación de mayor seguridad, al ser aplicaciones que han pasado un control más exhaustivo por miembros de Apple.

Tal y como recientemente anunció John Matherly (@achillean), fundador de Shodan, se han incorporado mejoras significativas en dicho buscador como, entre otras funcionalidades, una mejor integración con Shodan Exploits / Maps, resultados más rápidos, posibilidad de exportar en CSV o JSON o la posibilidad de representar gráficamente una instantánea de los resultados obtenidos tras hacer una determinada búsqueda, a modo de informes para tener una visión general de dichos resultados, de forma que, podamos tener una serie de gráficas desglosadas según ubicación, sistema operativo, producto, nombre del host, etc.

Los informes pretenden, por un lado, mostrar una imagen visual de los resultados, mucho más atractivos y accesibles si son presentados a modo de gráficas o mapas, de forma que con solo mirar el informe te hagas una idea de cuáles son los resultados obtenidos y puedas identificar tendencias. Por otro lado, puesto que los informes son instantáneas de los resultados de la búsqueda tal y como la ve Shodan en ese momento, es posible programar por ejemplo reportes periódicos cada X meses para detectar cambios en las redes que auditamos como nuevos elementos incorporados. Aunque esto también sería posible hacerlo añadiendo por ejemplo a nuestra petición las etiquetas “after” y/o “before” y, de los resultados obtenidos, obtener un informe. Un ejemplo de petición para obtener resultados, por ejemplo, recogidos en los últimos 8 meses de las WebCams indexadas por Shodan sería:

Se pueden consultar todas las opciones para personalizar las búsquedas echando un vistazo a la documentación de la API y en la ayuda de los filtros de Shodan.

Para generar un informe, solo hay que pinchar en “Create Report” tras realizar la petición de búsqueda, darle un título identificativo y esperar a que te llegue vía email el enlace que te lleva al informe que has generado.

Una ejemplo de informe sería el siguiente. Queremos ver de forma genérica estadísticas de Raspberry Pi online indexadas por Shodan. Como es algo muy genérico en la consulta simplemente buscaré por Raspbian:

Tras la obtención de resultados solicitamos el informe a través de “Create Report” y en unos pocos minutos nos llegará a nuestro correo el enlace al informe solicitado que, en este caso podéis ver completo en este enlace, y a continuación algunas capturas:

Otro ejemplo de informe podría ser con la siguiente consulta, servidores Apache detectados en el último mes en España:

El informe de salida tendría este aspecto:

(Me pregunto que pasará en Orihuela …)

Parece muy interesante esta nueva funcionalidad de Shodan, ¿se os ocurren más utilidades para obtener los informes?

Durante el transcurso del análisis forense de una máquina que sospechamos que está contaminada con malware, hemos encontrado el siguiente fichero: cosa.pyc.

¿Alguno de nuestros lectores nos podría echar una mano para saber qué hace? ;-)

Los delitos informáticos están de moda (y lo que les queda). Fraudes, robo de datos personales y bancarios, amenazas, pornografía infantil, blanqueo de capitales… la lista es larga, y solo limitada por la imaginación, la naturaleza humana y la legislación vigente.

Entre el aumento de los delitos, la mejora de la legislación (que hasta hace relativamente pocos años no equiparaba delitos informáticos con sus equivalentes físicos) y el excelente trabajo de las FCSE, cada día llegan a los juzgados más casos relacionados con las TIC.

Y dado que los jueces no son omniscientes, en ocasiones es necesario que recurran a terceras personas. Según la RAE, un perito se define como “persona que, poseyendo determinados conocimientos científicos, artísticos, técnicos o prácticos, informa, bajo juramento, al juzgador sobre puntos litigiosos en cuanto se relacionan con su especial saber o experiencia”.

[Read more…]