Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - r32

#661
Hola Roboto creo en esto te has colado:
Cita de: Roboto en 13 Noviembre 2014, 08:52 AM

No entiendo muy bien a estos foreros moralistas, que te mandan trabajar y luego son ellos mismos unos vagos....

* Ahí te has colado  >:(, te han dado su opinión, nada más...

Fijate en la info del siguiente link, puedes usar varias distros, Crunchbank de las más livianas, con Kali algo más pesado pero tienes version slim tambien:

https://www.google.es/search?q=linux+con+persistencia+usb&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:es-ES:official&client=firefox-a&channel=sb&gfe_rd=cr&ei=vnVkVMHxBo6B8QfFooGgBg

Saludos.
#662
Hacking Wireless / Re: AYUDA CON XIAOPAN
5 Noviembre 2014, 02:03 AM
A ver si esto te puede ayudar:

http://xiaopan.co/forums/wiki/index/

http://xiaopan.co/forums/wiki/how-to-install-latest-compat-wireless-drivers/

Lo he probado pero no tengo esa tarjeta.

Saludos.
#663
Con el título Introducción a Bitcoin, se ha publicado la tercera y última lección del curso de Sistemas de Pago Electrónico en el MOOC Crypt4you, siendo sus autores los profesores de la Universitat de les Illes Balears María Magdalena Payeras, Andreu Pere Isern y Macià Mut, miembros del grupo de Seguridad y Comercio Electrónico http://secom.uib.es/ SeCOM.

El objetivo de esta lección es el de ofrecer una introducción a los conceptos básicos de Bitcoin, así como a algunos puntos importantes que afectan a su funcionamiento. Como en todo medio de pago, la seguridad y la privacidad son dos requisitos indispensables, por lo que se analizarán los mecanismos que propone Bitcoin para mantener la seguridad, la privacidad y otros requisitos de todo medio de pago. No obstante, Bitcoin también plantea una serie de inconvenientes o excepticismos que por supuesto conviene analizar.

Temario lección 3:

    Apartado 3.1. Introducción a Bitcoin
    Apartado 3.2. Conceptos criptográficos básicos
    Apartado 3.3. Conceptos del protocolo Bitcoin
    Apartado 3.4. Estadísticas de la red
    Apartado 3.5. Críticas y excepticismo
    Apartado 3.6. Monedas digitales alternativas
    Apartado 3.7. Conclusiones
    Apartado 3.8. Ejercicios
    Apartado 3.9. Referencias bibliográficas


http://www.criptored.upm.es/crypt4you/temas/sistemaspago/leccion3/leccion03.html

Saludos.
#664


Las organizaciones nacionales y europeas han mostrado su preocupación por la seguridad en los entornos ICS. En el pasado, se diseñaban y ponían en marcha tales dispositivos para trabajar solamente en redes aisladas. Sin embargo, estas redes aisladas se están conectando cada vez más a Internet. Este cambio supone grandes ventajas, pero también aumenta el número de amenazas, incluyendo el ciberterrorismo.

También, hay cada vez más interés en las evaluaciones de seguridad de este tipo de arquitecturas. Por ejemplo, a nivel europeo, ENISA está discutiendo la importancia de temas como «la creación de un banco de pruebas común, o bien un marco de certificación de seguridad del ICS». Poder conseguir este objetivo puede llevar mucho tiempo. Pero, ¿qué podemos hacer mientras tanto?

INCIBE, como centro de ciberseguridad a nivel nacional, está al tanto de la importancia de trabajar en este reto, por lo que plantea el Proyecto SCADA LAB (Laboratorio SCADA y Banco de Pruebas como Servicio para la Protección de Infraestructuras Críticas). La propuesta acumula el esfuerzo de nueve miembros de distintos países de la Unión Europea: Hungría, Italia, Reino Unido y España.

Este proyecto está incluido dentro del programa «Prevención, preparación y gestión de las consecuencias del terrorismo», un programa específico financiado por la Comisión Europea. Su principal objetivo es analizar las actuales medidas de seguridad aplicadas en entornos ICS a través de:

   1- El desarrollo de un laboratorio y banco de pruebas específico, enfocado en el sector energético.
   2- La reutilización de los recursos existentes, conocimiento y equipamiento, de una manera eficiente.

Otro precedente importante que hay que tener en cuenta es el informe de ENISA «Protección de sistemas de control industrial. Recomendaciones para Europa y Estados Miembros», que describe la situación actual de la seguridad de los ICS y propone siete recomendaciones para mejorarla. En particular, en su recomendación número 5 destaca la falta de iniciativas específicas en estos entornos y la necesidad de realizar evaluaciones independientes de productos de seguridad de estos sistemas. Entre otros, ENISA fomenta el establecimiento de bancos de pruebas. Estos deben ser entornos realistas que permitan llevar a cabo evaluaciones que hagan validaciones y verificaciones independientes.

En resumen, el principal propósito del proyecto SCADA LAB es la creación de un entorno de pruebas que permita la evaluación en remoto del nivel de seguridad de un ICS, o cualquier parte del mismo. Para llevar a cabo este objetivo, la arquitectura del proyecto está dividida en dos áreas principales: el laboratorio y el banco de pruebas.



- Áreas principales en SCADA LAB -

El Área del Laboratorio incluye tanto el hardware como el sotware necesarios para llevar a cabo una evaluación de seguridad del banco de pruebas.

El Área del Banco de Pruebas es el objetivo a evaluar. Idealmente, su implementación es lo más parecida posible a un ICS en producción.

Dentro del ámbito del proyecto, el Área del Banco de Pruebas se encuentra en la sede de Telvent Energy, en Sevilla, y el Área de Laboratorio está ubicado en las instalaciones de INCIBE, León.
Metodología de pruebas

Leer completo en :

https://www.incibe.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/SCADALAB_seguridad_ICS

#665


Vulnerabilidad en Drupal deja a millones de sitios web en peligro

Responsables del gestor de contenidos, Drupal, han advertido a sus usuarios que sus sitios web están en peligro si no actualizaron en su momento a la última versión publicada el 15 de octubre.

Ataques automáticos que comprometen webs realizadas con Drupal 7 que no fueron actualizadas a la versión 7.32 comenzaron a las pocas horas de publicarse el parche. Si no se actualizó la web antes del 15 de octubre a las 23h UTC, es decir a las 7 horas de la publicación del parche, se debe proceder como si todas las webs estuvieran comprometidas, explican desde el CMS.

Drupal es un paquete de software de código abierto que proporciona un sistema de gestión de contenido (CMS) para sitios web. Es el tercero del mercado por popularidad detrás de WordPress y Joomla y se creen que esta vulnerabilidad crítica de inyección de código SQL ha dejado comprometidos 12 millones de sitios web.

Curiosamente la última actualización Drupal 7.32 corregía este tipo de vulnerabilidades. El problema reside en que de nada sirve actualizar ya estos sitios comprometidos, algo que ha ocurrido mediante "ataques automatizados" a las 7 horas de publicarse el parche, explican.

No es sencillo parchear tan rápidamente las máquinas, dicen desde la firma Sophos. Muchos usuarios no recibieron el aviso a tiempo simplemente porque estuvieran durmiendo por la diferencia horaria. La solución sería que Drupal implemente un sistema de actualización automática para la instalación de los parches de seguridad, algo que ya tienen otros gstores como WordPress.

Parche: https://www.drupal.org/SA-CORE-2014-005

+ info: https://www.drupal.org/PSA-2014-003

Fuente: http://muyseguridad.net/2014/11/04/vulerabilidad-en-drupal
#666




En el ámbito de seguridad de la información los controles nos permiten mitigar riesgos, razón por la cual se han desarrollado marcos de trabajo (frameworks) que ofrecen diferentes tipos de medidas de seguridad.

En esta ocasión vamos a revisar los Controles de Seguridad Críticos (CSC) para la ciberdefensa, una propuesta inicialmente coordinada por SANS Institute que luego fue transferida al Consejo de Ciberseguridad para su administración y mantenimiento.

¿Qué son los controles de seguridad críticos y qué los diferencia?

Se trata de un conjunto de controles que definen acciones específicas para la ciberdefensa, desarrollado y mantenido por diferentes partes interesadas, como empresas, agencias gubernamentales, instituciones académicas y expertos en el tema.

Se denominan críticos porque son el resultado del conocimiento combinado que se tiene actualmente sobre los ataques y las medidas de seguridad utilizadas para mitigarlos. Estos controles han sido priorizados con base en la reducción de riesgos y la protección que ofrecen contra las amenazas más comunes. Además se trata de un consenso sobre el conjunto de las medidas que resultan efectivas para detectar, prevenir, responder o mitigar los ciberataques.

Aunque no busca reemplazar a los marcos de trabajo y estándares, estos controles surgen como una opción para ofrecer nuevas alternativas de seguridad, ya que los requisitos de las normas y otros marcos desarrollados en ocasiones se enfocan en el cumplimiento y elementos de gestión, destinando recursos a actividades que no están directamente relacionadas con la protección contra las amenazas.

Características de los controles de seguridad críticos

Los controles tienen como característica principal su enfoque hacia la priorización de las funciones de seguridad, que han mostrado efectividad para la mitigación de riesgos, lo que indica qué debería realizarse primero, dentro de una lista relativamente pequeña de acciones.

Además se trata de un subconjunto del catálogo definido por National Institute of Standards and Technology (NIST) SP 800-53, por lo que los elementos recomendados han sido probados con anterioridad. La versión 5.1 de este documento incluye 20 controles de seguridad críticos.

Para llevar un control se presenta una descripción de su importancia en cuanto a la forma de identificar o bloquear la presencia de ataque, así como la forma en la que un atacante podría aprovechar la ausencia de este control. Para identificarlos se emplean las letras CSC (Critical Security Control) y el número correspondiente a la prioridad del mismo.

Además, incluye una lista de las acciones específicas que las organizaciones deben llevar a cabo para implementar, automatizar y medir la efectividad del control. El CSC también considera procedimientos y herramientas que permiten su implementación y automatización, así como métricas y pruebas que permiten evaluar el estado de la implementación y su efectividad. Por último, se cuenta con un diagrama entidad-relación de los componentes utilizados durante la implementación.

Categorías de CSC

Dentro de la lista de controles de seguridad críticos podemos encontrar cuatro categorías que permiten tener una mejor descripción de los mismos, con base en las características que se muestran a continuación:

    Triunfos rápidos: Son los tipos de controles que proporcionan una reducción significativa de los riesgos sin la necesidad de llevar a cabo importantes cambios en aspectos financieros, de procedimientos, en arquitecturas o técnicos. También pueden proporcionar dicha reducción de manera sustancial o inmediata sobre los ataques más comunes en las organizaciones.
     Medidas de visibilidad y de atribución: Estos controles buscan mejorar los procesos, arquitectura y capacidades técnicas de las organizaciones para monitorear sus redes y sistemas informáticos, para detectar intentos de ataques, localizar los puntos de acceso, identificar equipos comprometidos, actividades de infiltración de atacantes u obtener información sobre los orígenes de un ataque.
     Configuración de seguridad de la información mejorada e higiene: Tienen como objetivo reducir el número y la magnitud de las vulnerabilidades de seguridad, así como mejorar el funcionamiento de los sistemas informáticos en la red, a través de un enfoque hacia las prácticas de seguridad deficientes que podrían dar ventaja a un atacante.
     Subcontroles avanzados: Utilizan nuevas tecnologías o procedimientos que proporcionan mayor seguridad, pero representan mayor dificultad para su implementación, mayor costo o requieren más recursos, como personal altamente calificado.

Una opción más de seguridad a considerar

Entonces, los controles de seguridad críticos pueden ser utilizados como una opción más de medidas para la protección, con las características propias de esta lista como la priorización de las acciones a realizar y su completa orientación hacia la detección, prevención, respuesta o mitigación de amenazas a la seguridad.

En este sentido, pueden contribuir en la complementación de otros estándares o mejores prácticas de seguridad, ya que ofrecen medidas actualizadas sobre las amenazas más comunes y otras características, como elementos para la medición de la efectividad, procedimiento y herramientas.

Créditos imagen: © /Flickr

Autor Miguel Ángel Mendoza, ESET
#667




Con el lanzamiento de Android 5.0 Lollipop a la vuelta de la esquina son muchos los usuarios que esperan ansiosos las nuevas funcionalidades del sistema operativo de Google. Muchos usuarios se sentirán especialmente atraídos por la nueva interfaz Material Design pero nosotros vamos a centrarnos en 5 aspectos de la seguridad que han sido mejorados en esta nueva versión de Android.

Cifrado por defecto

Esta es quizás la característica que pasará más desapercibida para los usuarios pero que otorgará mayor privacidad a los datos que almacenemos en nuestro dispositivo. Si bien es cierto que Android venía ofreciendo a sus usuarios la posibilidad de cifrar el contenido de sus dispositivos, esta opción requería ser activada por el usuario.

En Lollipop, el cifrado vendrá activado por defecto, manteniendo seguras nuestras fotos, vídeos o documentos privados de miradas indiscretas, necesitándose una clave para poder acceder a los mismos de forma segura. No hace falta decir que esta clave de cifrado deberá ser lo suficientemente robusta como para que no pueda ser fácilmente adivinada o rota por mecanismo de fuerza bruta.

Viendo que Apple también ha adoptado medidas similares, esta característica parece una reacción de ambas empresas ante los casos de espionaje gubernamental destapados tras las revelaciones que aún al día de hoy siguen produciéndose por los documentos filtrados por Edward Snowden.

De todas formas, de nada sirve cifrar esta información en nuestro dispositivo si después la subimos a sistemas de almacenamiento en la nube. Es importante que, si queremos tener una copia de seguridad de esta información, esta también se encuentre cifrada.

Bloqueo de la pantalla

Una de las medidas de seguridad básicas que prácticamente todos los usuarios realizan es bloquear su pantalla con un código PIN o un patrón de desbloqueo. A estos sencillos métodos se han añadido recientemente la posibilidad de utilizar valores biométricos como el reconocimiento facial o de nuestras huellas dactilares.

Google quiere ir un paso más allá y hacer este proceso de bloqueo / desbloqueo de forma más sencilla y propone utilizar Smart Lock, una funcionalidad de Android Lollipop que permite desbloquear nuestro dispositivo mediante la vinculación vía Bluetooth o NFC a otro dispositivo, como por ejemplo un smartwatch (reloj inteligente). Además, el sistema de reconocimiento facial se ha mejorado, haciendo que su utilización sea más rápida y efectiva.

Además de estas nuevas características, podremos configurar qué tipo de notificaciones se pueden mostrar en la pantalla de bloqueo, pudiendo acceder a información interesante de forma rápida y manteniendo nuestro dispositivo bloqueado.

Compartir WiFi de forma segura

Buena parte de la seguridad de una red WiFi depende de la robustez de su contraseña. Estas contraseñas suelen darse alegremente demasiadas veces, especialmente en sitios públicos como bares o bibliotecas, algo que compromete seriamente la seguridad de la red y que puede provocar que tengamos visitantes inesperados.

Para evitar tener que ir cambiando continuamente de contraseña, Google propone un nuevo sistema a base de utilizar etiquetas inteligentes con tecnología NFC. De esta forma, podremos almacenar la contraseña de nuestra red WiFi en una de estas tarjetas y dársela a los usuarios que quieran hacer uso de la misma, sin comprometer en ningún momento la clave usada para proteger la red.

Restauración de fábrica con contraseña

La popularización de los smartphones también ha provocado que los delincuentes se fijen en ellos como un botín apetecible y cada día se roban miles de ellos para desconsuelo de los usuarios. Existen herramientas como Android Device Manager o nuestra solución de seguridad ESET Mobile Security que permiten bloquear remotamente el dispositivo borrado, borrar su contenido o incluso localizarlo en Google Maps.

No obstante, si se realiza una restauración del dispositivo al estado en el que sale de fábrica, estas aplicaciones también desaparecen y perdemos la oportunidad de intentar recuperar nuestro Smartphone.

Para evitar esta situación, en Android Lollipop se requiere una contraseña para restaurar el teléfono a los valores de fábrica. De esta forma, si un ladrón intenta "limpiar" el teléfono para venderlo de segunda mano no podrá hacerlo sin esta contraseña, dándole más tiempo al legítimo propietario para tratar de recuperar su dispositivo.

SELinux, más seguro todavía

Desde la aparición de Android, el sistema operativo siempre ha confiado en una sandbox para ejecutar las aplicaciones en un entorno aislado de forma controlada. No obstante, si analizamos la situación actual del malware en dispositivos móviles observaremos como los delincuentes han conseguido saltarse esta protección y propagan sus amenazas sin muchos problemas.

Google quiere poner fin a esta situación y en Lollipop activa por defecto el modo "enforced" para las aplicaciones en todos los dispositivos. De esta forma se evita que los delincuentes se aprovechen sin demasiadas complicaciones de las vulnerabilidades que vayan apareciendo en el sistema. Sin duda un movimiento inteligente por parte de Google que no solo nos beneficia a los usuarios de a pie si no que apunta también a los entornos corporativos.

Conclusión

Todas estas características ayudarán sin duda a hacer de Android un sistema más seguro pero no hemos olvidar que los usuarios somos la mayoría de las veces la principal línea de defensa y hemos de estar informados acerca de las amenazas que puedan afectar a nuestros dispositivos. Si además contamos con una solución de seguridad como ESET Mobile Security (que cuenta con una versión gratuita) que nos ayude a establecer capas de defensa adicionales, podremos disfrutar de todas las bondades del nuevo Android Lollipop de una forma segura.

Créditos imagen: © Jackie/Flickr

Autor Josep Albors, ESET
#668


El pasado viernes, en la última jornada de la Ekoparty, los investigadores representantes de Core Security Technologies, Martin Balao y Martin Fernandez, nos deleitaron con su demostración de explotación de aplicaciones Android para lograr la ejecución de comandos en dispositivos remotos. Esto se lograba mediante la posibilidad de inyectar procesos para hacer uso de aplicaciones con vulnerabilidades conocidas, y así conseguir acceso a los permisos vigentes en el equipo víctima. A lo largo de su presentación explicaron cómo explotar, escalar y post-explotar este tipo de debilidades presentes en uno de los sistemas operativos móviles más utilizados mundialmente, de manera absolutamente imperceptible para el usuario del terminal.

¿En qué consiste la explotación?

La idea principal de su desarrollo radica en la inyección de procesos para obtener los permisos otorgados a una aplicación vulnerable, y así lograr ganar acceso a la Dalvik VM. Esto se logra mediante la explotación de la clase WebView, la cual presenta componentes HTML y javascript –usualmente utilizados para mostrar publicidades al usuario. Éstos vuelven posible la exposición de instancias de clases de Java con la utilización del método addJavascriptInterface() que exporta un objeto JSInterface, deviniendo en la invocación de métodos estáticos como getClass() o forName(), y la eventual obtención del contexto de ejecución conjuntamente a la explotación de cualquier clase cargada en la VM, pudiendo ejecutarse con esta vulnerabilidad diferentes comandos en el sistema operativo remoto.

Entre las dificultades que este enfoque presenta encontramos la fuerte presencia de sandboxing en Android, con aplicaciones corriendo en espacio de usuario, sin privilegios de administrador –y consecuentemente, sin acceso al sistema de archivos o la posibilidad de instalar otras aplicaciones, y el hecho de que binder –el driver del kernel en el sistema operativo Android– utiliza tanto identificadores de usuario como de procesos en su operatoria.

Dado que la presencia de sandboxes restringe la comunicación entre aplicaciones, el objetivo de la explotación se torna entonces en utilizar permisos de aplicaciones vulneradas para interactuar con otros procesos, no desde un proceso separado, sino con la escritura e invocación de archivos en el filesystem desde el mismo proceso mediante inyección. Esto implica la capacidad de alocar un espacio de memoria, escribir un shellcode en el mismo, crear un hilo que lo ejecute, y lograr realizar esto sin corromper la memoria virtual del proceso y el estado de los diferentes hilos.

Y ahora, ¿cómo resulta esto posible?

Ya que, al acoplar un depurador a un proceso, generamos otro proceso padre del mismo bajo nuestro control, somos capaces entonces de interceptar los mensajes enviados al hilo original, otorgándonos el poder de escribir espacio de memoria –incluso de sólo lectura–, leer el contexto de ejecución del hilo, secuestrarlo, detenerlo, o ejecutarlo en un lugar de memoria diferente. Con base en este principio, podemos acoplar un depurador a un hilo de la Dalvik VM, alocar memoria, escribir un shellcode, crear un hilo de ejecución, y utilizar las variables mapeadas entre direcciones físicas y virtuales, dejando finalmente el proceso en su estado original.

Algunos linkers dinámicos presentan la función dlopen, la cual carga una dirección en la memoria del proceso. Para ubicar esta función y acoplarse a ella, es posible buscar la entrada correspondiente en la Global Offset Table (GOT), la cual nos redireccionará a la posición final absoluta de los símbolos de la llamada a la función, pero sólo una vez que el linker dinámico la resuelva.

Entonces, debemos mirar cada entrada en la Procedure Linkage Table (PLT), las cuales constan de un pequeño código ejecutable. En vez de llamar a la función directamente, el código llama una entrada en la PTL, la cual luego se encarga de invocar la función genuina. Esta estructura es conocida como "trampolín". La identificación de este arreglo se basará en el estudio de patrones aritméticos de los registros, donde cada secuencia de instrucciones corresponde a una función diferente. Una vez determinado el trampolín correspondiente a dlopen, es posible colocar en éste el hilo secuestrado a ejecutar.

La clase ActivityThread del framework contiene un método estático que inicializa la creación del hilo principal de la aplicación vulnerable. Ésta presenta un atributo sMainThreadHandler que devuelve una instancia de Handler, la cual permite mediante el método post() encolar objetos Runnable a ser ejecutados. Un atacante puede generar una llamada nativa para invocar este método, y así obtener una referencia a un objeto Context. Este último actúa como interface para acceder a la información general sobre el contexto de ejecución de la aplicación, como ser recursos y clases específicos de la misma, o llamadas desde binder al Activity Manager Service para realizar operaciones como lanzar actividades, publicar y recibir intentos, y concretar acciones de alto nivel –como la lectura o envío de SMSs.

Resumiendo lo aprendido...

Luego de la inyección, un atacante podría interactuar con binder utilizando Java a modo de post-explotación. De esta forma, se consigue acceso a los objetos en Java, sus métodos, y los métodos estáticos de las clases a las que pertenecen. Una manera de lograr esto es instanciar un objeto de APK ClassLoader, y utilizarlo para cargar código malicioso.

El resultado final de la explotación es la posibilidad de reemplazar los javascripts, incluir payloads binarios, escribir éstos en el sistema de archivos, y concluir con un Java Agent ejecutando en el equipo víctima con el mismo identificador de proceso que la aplicación vulnerable, lo que permite la posterior escalación de privilegios y la inyección remota de comandos –como la generación de llamadas o el envío de SMSs, el listado del sistema de archivos o de los procesos actualmente siendo ejecutados en el sistema operativo.

Como bien resaltaron los oradores, el comprender este tipo de vulnerabilidades nos recuerda la importancia de evitar aplicaciones depurables en entornos de producción, siendo las entidades corporativas potenciales blancos para estos ataques. Además, los archivos .apk construidos en modo standalone –es decir, paquetes de aplicación que no requieren de otros paquetes o archivos para funcionar– se constituyen como un sistema inherentemente débil, que de ser combinado con un proceso de explotación como el explicado a lo largo de esta charla, pueden generar poderosos vectores de ataque.

Créditos imagen: ©Windell Oskay/Flickr
#669
Cita de: andronicoset en  2 Noviembre 2014, 12:03 PM
A por cierto tambien me robaron una antena de exterior si la conectan en mi barrio aparte de verla en alguna ventana hay un modo de rastrearla??

Casi peor que lo del portatil, no creo tengas formas de rastrearlo, no se a ver si alguien sabe algo más del tema. Tambien puede depender un poco, si no cambiaron el nombre de la red puedes rastrearla pero te va a tocar hacer la pregunta que formulas:

Wardriving:
http://es.wikipedia.org/wiki/Wardriving

Saludos
#670
Quizás me perdí algún comentario pero en la captura paracen los segundos:



Citar:

09.10.2014
09:25:56

Si no lo que dice Dimitrix inventatelos, aunque creo lo requieren para la verificacion de conexion que tiene registrado el ISP, creo eh...

Saludos.