LATEST ARTICLES

enero 5th 2018

Microprocesadores vulnerables: ¿qué son Meltdown y Spectre?

Número de lecturas: 968
{lang: 'es-419'}

La innovación en microprocesadores está en la base del progreso tecnológico: una industria que demanda velocidades de ejecución cada vez mayores, y que ha generado un progreso enorme a lo largo de las últimas décadas. Por eso, las nuevas vulnerabilidades descubiertas en los microprocesadores de todos nuestros dispositivos modernos y comunicadas de manera general ayer, Meltdown y Spectre, tienen un nivel de criticidad tan sumamente elevado, aunque en la práctica poco podamos hacer con respecto a ellas.

¿Qué deberíamos saber al respecto? Fueron descubiertas por investigadores en seguridad: la primera, Meltdown, se debe al trabajo independiente de tres equipos en la Universidad Técnica de Graz, en Cyberus Technology y en Google Project Zero; la segunda, Spectre, también en Google Project Zero y por el investigador Paul Kocher. El descubrimiento, como ocurre en muchas ocasiones en cuestiones relacionadas con la seguridad, se remonta a hace algunos meses, durante los cuales han podido presuntamente ocurrir cosas como que algunos de los implicados se preparasen para ofrecer seguridad a sus usuarios, y otros se dedicasen a vender rápidamente acciones de sus propias compañías.

¿En qué consisten? Todos los microprocesadores modernos utilizan una serie de capacidades de ejecución especulativa para los accesos de memoria: el microprocesador no solo lleva a cabo lo que le pedimos, sino que dedica una parte de sus recursos a especular que una condición determinada, por ejemplo, será verdadera, y a llevar a cabo los accesos a memoria correspondientes a que así fuese, y así optimizar su tiempo de ejecución. Si finalmente esa especulación no resulta cierta, las instrucciones ejecutadas especulativamente son descartadas. Sin embargo, aunque esa especulación y ese descarte no tienen ningún efecto en la ejecución de los programas (además de acelerarla, que no es poco), sí producen cambios en los componentes del microprocesador, tales como, por ejemplo, cargar determinados datos en la cache. La presencia de esos datos en la memoria cache o en otros componentes del microprocesador es detectable porque su acceso es más rápido que si no estuvieran ahí, y eso podría permitir el acceso a información sensible. Básicamente, hablamos de vulnerabilidades que, en el caso de Meltdown, rompen la frontera entre las aplicaciones del usuario y el sistema operativo, permitiendo así que un programa malicioso pueda acceder a la memoria y, por tanto, a datos de otros programas o del propio sistema operativo. En Spectre, más difícil de explotar que Meltdown pero también más difícil de parchear o solucionar, hablamos de la ruptura del aislamiento entre distintas aplicaciones, lo que permite que una aplicación maliciosa pueda engañar a otras aplicaciones sin errores para obtener datos de las mismas.

Todos los microprocesadores modernos utilizan ejecución especulativa, y de hecho, es una funcionalidad que está en la base de sus prestaciones y que los microprocesadores de Intel llevan a cabo de una manera particularmente agresiva. Los parches que se han puesto en marcha hasta el momento son una primera solución, ponen bajo control o eliminan las funciones especulativas, y provocan al hacerlo pérdidas de prestaciones de hasta un 30%. Renunciar a la ejecución especulativa no parece el camino a seguir, y la solución final podría demorarse bastante tiempo, durante el cual, indudablemente, surgirán actores capaces de explotar las vulnerabilidades en sistemas que no hayan sido parcheados.  Algo tan evidente como que debes aplicar los correspondientes parches de seguridad no es en realidad tan sencillo: aunque en muchos casos esos parches se aplican de manera automática, no todos los usuarios tienen la cultura adecuada como para aplicarlos regularmente. Pero además, la solución debe considerarse como algo temporal: a lo que nos dirigimos es a un replanteamiento fundamental sobre el uso de la ejecución especulativa en microprocesadores, un proyecto de nueva arquitectura que solucione estos problemas de la manera adecuada que llevará mucho tiempo.

¿Es normal que pasen estas cosas? Sí, desgraciadamente, es lo que tiene que la industria avance a la velocidad que avanza. ¿Quiere decir que todo es vulnerable? ¿Estás en riesgo? Si simplemente usas un dispositivo, lo normal será que no, porque las vulnerabilidades no son suficientes – o no en su estado actual – para, por ejemplo, comprometer tu máquina a través de su navegador. Apple, por ejemplo, ha confirmado que todos sus dispositivos, tanto ordenadores como smartphones, están afectados, aunque no se conoce todavía ningún esquema de ataque, y dado que dichos ataques precisan de una aplicación o programa instalado en el dispositivo, recomiendan instalar únicamente software procedente de fuentes fiables. El riesgo fundamental es para los proveedores de servicios de computación en la nube, que por lo general ya habrán aplicado los correspondientes parches a costa de un descenso en su rendimiento, con todo lo que ello conlleva en términos de coste. Básicamente, un problema para el que no vas a poder hacer nada más – ni nada menos – que seguir una serie de instrucciones cuando estas vayan llegando, que debería servirte para extremar la precaución y las rutinas de seguridad – nunca es malo que lo hagas – y que se mueve a unos niveles que están muy por encima del usuario común.

Fuente:

enriquedans.com

diciembre 22nd 2017

Conoce Symfony … Así va a funcionar el nuevo drupal

Número de lecturas: 1220
{lang: 'es-419'}

Hace un mes participe en el Drupal Camp 2017, pude dictar una charla la cual la comparto espero les sea un aporte.

diciembre 19th 2017

Libro sobre Auditoria Informática y Seguridad para no profesionales del sector

Número de lecturas: 1034
{lang: 'es-419'}

Interesante libro de Seguridad Informática donde se le da otro enfoque y aclara varios conceptos.

Aca el indice del mismo:

Contenido

Capítulo 1 ………………………………………………………………………………………………… 4
¿Por qué y Para qué debo certificar mi empresa? …………………………………….. 4
Capítulo 2 ………………………………………………………………………………………………… 8
Por dónde empezar y como ……………………………………………………………………. 8
Capítulo 3 ………………………………………………………………………………………………. 19
Identificando activos y su clasificación. ISO 55001 …………………………………. 19
Capítulo 4 ………………………………………………………………………………………………. 32
La Gestión del Riesgo y la Continuidad del Negocio. ISO 22301 …………….. 32
Características del análisis de impacto ……………………………………………………………………. 41
Consideraciones durante el desarrollo del BIA …………………………………………………………. 42
Ventajas de la realización de un análisis de impacto …………………………………………………. 42
Capitulo 5 Auditorias: ………………………………………………………………………………. 52
No es tan fiero el Lobo como lo pintan. ………………………………………………….. 52
Vulnerabilidades y Ataques Informáticos ……………………………………………………………. 56
Auditoria de Redes Lógicas ……………………………………………………………………………………. 59
Auditoria Red Física ………………………………………………………………………………………………. 61
Auditorias de Sistemas Operativos Servidor / Cliente. ………………………………………………. 69
Capítulo 6 ………………………………………………………………………………………………. 72
Las Bases de Datos y su Auditoria: Motor SGDBR y Desarrollo. …………….. 72
Donde descansa la mayoría de la información de nuestra empresa. …………………………… 72
Auditoria de Base de Datos y Desarrollo ………………………………………………………………….. 72
Capítulo 7 ………………………………………………………………………………………………. 94
Las conclusiones y la traducción a un término universal: el Coste. …………… 94
Capítulo 8 …………………………………………………………………………………………….. 104
La Nomenclatura y Estructura de las Normas ……………………………………….. 104
Normas ISO – ISO / IEC – ISO – UNE. ……………………………………………………………………… 104
Capítulo 9 …………………………………………………………………………………………….. 106
Políticas Organización y Seguridad de la Información. ………………………….. 106
Dominio 5 & 6…………………………………………………………………………………………………….. 106
Capítulo 10 …………………………………………………………………………………………… 107
Recursos Humanos. …………………………………………………………………………… 107
Dominio 7 ………………………………………………………………………………………………………….. 107
Capítulo 11 …………………………………………………………………………………………… 108
Manual de Auditoria para no Auditores
Gestión de Activos. ISO 55001 ……………………………………………………………. 108
Dominio 8 ………………………………………………………………………………………………………….. 108
Capítulo12 ……………………………………………………………………………………………. 109
Control de Accesos Físicos y Lógicos ………………………………………………….. 109
Dominio 9 ………………………………………………………………………………………………………….. 109
Capítulo 13 y 14 ……………………………………………………………………………………. 110
Cifrado y Seguridad Física y Ambiental. ………………………………………………. 110
Dominios 10 -11 – ISO 14001 ………………………………………………………………………………… 110
Capítulo 15 …………………………………………………………………………………………… 112
Seguridad Operativa. ISO 20000 …………………………………………………………. 112
Dominio 12 ………………………………………………………………………………………………………… 112
Capítulo 16 …………………………………………………………………………………………… 118
Seguridad en las Telecomunicaciones. ISO 27010 …………………………………… 118
Dominio 13 ………………………………………………………………………………………………………… 118
Capítulo 17 …………………………………………………………………………………………… 122
Adquisición, Desarrollo y Mantenimiento de los Sistemas de Información. …. 122
Dominio 14 ………………………………………………………………………………………………………… 122
Capítulo 18 …………………………………………………………………………………………… 127
Relaciones con suministradores. ISO 20000 ……………………………………….. 127
Dominio 15 ………………………………………………………………………………………………………… 127
Capítulo 19 …………………………………………………………………………………………… 129
Gestión de Incidentes de Seguridad. ISO 20000 ………………………………….. 129
Dominio 16 ………………………………………………………………………………………………………… 129
Capítulo 20 …………………………………………………………………………………………… 131
Continuidad del Negocio ISO 22301 / 22320. …………………………………………… 131
Dominio 17 ………………………………………………………………………………………………………… 131
Capítulo 20 …………………………………………………………………………………………… 138
Cumplimiento Legal. ISO 19600 ………………………………………………………….. 138
Dominio 18 ………………………………………………………………………………………………………… 138
Capítulo 21 …………………………………………………………………………………………… 142
ISO 27007 …………………………………………………………………………………………. 142
¿Cómo se auditan los controles por parte del Auditor?……………………………… 142
Capítulo 22 …………………………………………………………………………………………… 173
La Ingeniería Social, la zona muerta del Derecho actual. ………………………….. 173
Capítulo 23. ………………………………………………………………………………………….. 196
Manual de Auditoria para no Auditores
Las metodologías OWASP / OSSTMM soporte para la verificación de la
normativa. …………………………………………………………………………………………….. 196
Capítulo 24 …………………………………………………………………………………………… 217
OSSTM versión 3 : 2010 ………………………………………………………………………… 217
Mapa de la Seguridad según OSSMT ……………………………………………………… 220
Capítulo 25. ………………………………………………………………………………………….. 403
Manos a la obra, la parte práctica. ……………………………………………………….. 403
Capítulo 26. ………………………………………………………………………………………….. 419
Como realizar una investigación técnica de calidad. ……………………………… 419

Lo pueden descargar AQUI

 

 

diciembre 19th 2017

VichUploaderBundle – no se puede reemplazar ni actualizar el archivo cargado

Número de lecturas: 838
{lang: 'es-419'}

Generalmente cuando utilizo symfony para cargar imagenes lo hacia con las opciones del framework y en otros proyectos que utilizo VichUploaderBundle solo cargaba el archivo y lo solucionaba, sin embargo en este proyecto en especifico tengo la necesidad de editar el archivo que ya subi, lo cual no se hace con la configuración “normal” del Bundle.

Pero con unos pequeños en el archivo config.yml cambios todo funciona perfectamente.

La clave esta en agregar estas líneas:

//config.yml
delete_on_remove: true
delete_on_update: true

Un ejemplo completo sería asi:

vich_uploader:
    db_driver: orm
 
    mappings:
        user_images:
            delete_on_remove: true
            delete_on_update: true
            inject_on_load: true
            uri_prefix:         '%app.path.user_images%'
            upload_destination: '%kernel.root_dir%/../web/uploads/images/users'

Si se necesita más lugares donde cargar archivos se agregan mappings con la misma lógica

Fuente:

http://mossco.co.uk/
https://symfony.com/doc/current/controller/upload_file.html
https://stackoverflow.com/questions/22484000/update-form-vich-uploader-cannot-delete-or-edit-file