.

Compartelo:
0

Intercambio de archivos en línea supone grandes riesgos

Jesus Bourne 6 de julio de 2012

De acuerdo con Symantec, las PYMES se encuentran más en riesgo que nunca debido al aumento del intercambio de archivos en línea como una práctica común en los negocios.

Un nuevo estudio revela que los trabajadores de PYMES adoptan cada vez más servicios no administrados o para uso personal de soluciones de intercambio de archivos sin el permiso de TI, una amplia tendencia de los consumidores de TI en el que la adopción de servicios en línea para el uso de dispositivos móviles personales desvanece las líneas entre trabajar y jugar.

Estos nuevos comportamientos, como los que impulsa el uso de la tecnología en el intercambio de archivos, están haciendo vulnerable la seguridad de las organizaciones a la pérdida potencial de datos.

“El 71 porciento de las pequeñas empresas que sufrieron ataques cibernéticos nunca se recuperaron, fue fatal”, dijo Rowan Trollope, presidente del grupo PYMES y .cloud de Symantec.  “A medida que el tiempo avanza, se adoptan tecnologías de la nube, como el uso compartido de archivos, las PYMES necesitan el uso de mejores prácticas seguras, especialmente cuando se utiliza una solución que puede no haber sido construida para empresas.

Mientras empleados adopten cada vez más servicios de nube de nivel casero en el trabajo, el riesgo para las PYMES aumenta”.  

Las partes interesadas en cuanto a PYMES reconocen que el intercambio de archivos ayuda a impulsar la productividad entre los empleados. 74 por ciento de los encuestados mencionaron que adoptaron el intercambio de archivos en línea para reforzar su propia productividad.

Además, el 61 por ciento de los encuestados informaron a los empleados tienden a ser demasiado influyentes a la hora de adoptar soluciones de intercambio de archivos internos, a la par con el uso de dispositivos móviles (63 por ciento), PC / laptops / uso de tabletas (64 porciento) y el uso de medios sociales (53 por ciento).

Muchos de los encuestados reconocieron los riesgos potenciales que las malas prácticas de intercambio de archivos pueden traer a sus organizaciones.

Entre los encuestados, los riesgos citados como posibles problemas incluyen el intercambio de información confidencial usando soluciones aprobadas (44 por ciento), malware (44 por ciento), pérdida de información confidencial o personal (43 por ciento), violación a la información confidencial (41 por ciento), daño a la reputación (37 por ciento), y la violación de normas de regulación (34 por ciento).

Por otra parte, la falta de cumplimiento de las políticas también aumenta los riesgos para muchos de los encuestados en más de una quinta parte, 22 por ciento de los encuestados no han implementado políticas que restringan cómo los empleados pueden acceder y compartir archivos.

El comportamiento de los empleados en el intercambio de archivos indican un mayor potencial de riesgo para la seguridad.

Cuando se les preguntó lo que los empleados pueden hacer cuando tienen que compartir un archivo de gran tamaño, los encuestados indicaron que piden ayuda a profesionales de TI (51 por ciento), utilizar una solución sugerida por un cliente, contratista o colega (42 por ciento), utilizar algún sistema de TI (33 por ciento), o buscar en línea y descargar una solución gratuita (27 por ciento).

Por otra parte, el 41 por ciento indicó que el daño a la reputación de la marca era una preocupación cuando se trata de intercambio de archivos.

Muchos de los archivos que se comparten interna y externamente están aumentando significativamente en tamaño. Uno de cada siete (14 por ciento) de los encuestados informó que el tamaño en general de los archivos compartidos en la actualidad por su organización es de más de 1 GB, mientras que hace tres años, sólo el 6 por ciento reportó que el tamaño promedio de los archivos era de 1 GB.

Los encuestados indicaron que el número de empleados que trabajan de forma remota y/o desde casa ha aumentado gradualmente en los últimos tres años, y se prevé un aumento.

Los resultados de la encuensta predicen que dentro de un año un 37 por ciento de las organizaciones de PYMES podrían tener empleados trabajando de forma remota (hasta un 22 por ciento de hace tres años y 32 por ciento en la actualidad), y el 32 por ciento va a tener empleados que trabajen desde casa (hasta un 20 por ciento de hace tres años, y 28 por ciento en la actualidad).



Fuente: Help Net Security 

0

Se identifica a EUA e Israel como autores de Flame

Jesus Bourne 4 de julio de 2012

Estados Unidos e Israel han sido identificados como creadores del sofisticado malware Flame, que fue encontrado en la mayoría de los casos atacando sistemas computacionales Iraníes, según los reportes.

El Washington Post afirmó que fuentes con conocimiento de dicha obra dijeron que la Agencia Nacional de Seguridad (NSA), la CIA y la milicia israelí estuvieron involucrados en la creación del malware que fue descubierto por primara vez en mayo. 

El Post también informó que un oficial de alto rango de la inteligencia de EUA reveló que los esfuerzos en contra de los sistemas informáticos de Irán aún siguen en marcha.

"Se trata de preparar el campo de batalla para otro tipo de acción encubierta. La ciber recolección en contra del programa de Irán tiene mucho más alcance de lo que podemos ver" se citó al oficial mientras hablaba.

Como era de esperarse la CIA, la NSA y la Ofinica de la DNI (Director of National Intellingence), así como la embajada de Israel en Whashington, negaron los comentarios sobre las denuncias que publicó el diario Washington Post.

Sin embargo, existen revelaciones de reportes anteriores, en las que el presidente Obama había apoyado la creación y lanzamiento de Stuxnet en contra de Irán, en un intento de paralizar sus planes de desarrollo nuclear.

Los informes recientes mostraron que tanto Flame como Stuxnet tienen componentes de código similares, lo que hace suponer que hay cierta relación entre los dos proyectos, una vez más se sustenta la credibilidad de las fuentes.


Fuentes: v3-uk 
0

Detenidos todos los integrantes de la red Carberp

Jesus Bourne

El siguiente artículo es una traducción y adaptación de la publicación All Carberp botnet organizers arrested realizada echa por un investigador de nombre Aleksandr Matrosov.

Hemos estado vigilando la actividad del grupo de cibercriminales Carberp durante tres años. Este seguimiento empezó en 2009 con las primeras muestras del malware Carberp propagándose activamente. A principios de 2010, la segunda oleada de actividad de Carberp sobrepasó la de otras familias de malware (Win32/Spy.Shiz, Win32/Hodprot) en Rusia.

Resumimos la primera fase de nuestra investigación en la presentación “Cybercrime in Russia: Trends and issues” en el evento CARO 2011. Este año hemos resumido los resultados de las investigaciones realizadas a posteriori en la presentación “Carberp Evolution and BlackHole: Investigation Beyond the Event Horizon” en el evento CARO 2012.

Durante este periodo tres grupos diferentes de cibercriminales trabajaron con Carberp. El primer grupo empezó en 2009 y el organizador de este grupo tuvo una relación directa con el desarrollador principal de Carberp.

Este grupo comenzó usando software legítimo de control remoto para poder robar dinero manualmente cuando una máquina se encontraba conectada (Sheldor-Shocked). En 2010 las fuentes de Carberp se vendieron al segundo grupo y trabajaron en paralelo.


A principios del verano de 2011, la mayor botnet Carberp de todos los tiempos fue iniciada por los organizadores de la botnet Hodprot (Hodprot: Hot to Bot). A finales de octubre de 2011 vimos las primeras detecciones de variantes del descargador de Carberp que incluía un bootkit (Evolution of Win32/Carberp: going deeper). Esta botnet tenía el nombre en clave “Origami” y su panel de administración lucía así:




Este grupo usó plugins específicos para atacar los sistemas bancarios más importantes de Rusia y realizó experimentos con phishing en redes sociales populares (Facebook Fakebook: New Trends in Carberp Activity).

A finales de 2011 empezó una campaña de infecciones masivas de sitios legítimos con redirecciones al kit de exploits BlackHole (Carberp + BlackHole = growing fraud incidents, Blackhole, CVE-2012-0507 and Carberp). En abril de 2012 se abandonó BlackHole por la versión más reciente del Nuclear Pack usando una inteligente técnica de redirección (Exploit Kit plays with smart redirection).

Durante todo el periodo el primer grupo usó Win32/Sheldor para robar dinero manualmente y en 2011 Sheldor evolucionó a Win32/RDPdoor (basado en el software legítimo ThinSoft BeTwin). 

La última versión de Win32/RDPdoor tiene una funcionalidad que detecta una smartcard y permite la explotación remota de estas de forma transparente para  instalar la aplicación FabulaTech USB para permitir el acceso por Escritorio Remoto (Smartcard vulnerabilities in modern banking malware). El panel de administración de la última versión de Win32/RDPdoor es así:



Ahora, los organizadores de los tres grupos ya han sido arrestados en Rusia. Las noticias del primer arresto fueron publicadas en marzo de 2012 (Members of the largest criminal group engaged in online banking fraud are detained). Uno de los organizadores del segundo grupo fue arrestado a principios de junio de 2012 (Group-IB aided Russian law enforcement agents in arresting yet another cybercriminal group).

A finales de junio, el organizador de la botnet “Origami/Hodprot” también fue arrestado (One of the largest banking botnets has been disabled).

Las estadísticas de las detecciones de Win32/RDPdoor son las siguientes:

Datos de la nube Live Grid

Las estadísticas de las detecciones de Carberp son las siguientes:

Datos de la nube Live Grid

Datos de la nube Live Grid

Todos los organizadores de la botnet Carberp han sido arrestados, pero nuestras estadísticas no están reflejando un descenso importante en las detecciones. La región de Rusia lidera las detecciones de Carberp y tras los arrestos mostró un ligero descenso.

En el gráfico por tiempo podemos ver una bajada en las infecciones tras cada arresto, como por ejemplo en la información del mes de junio. Pero a finales de junio, un organizador de la botnet Carberp más grande, “Origami/Hodprot” (con millones de bots activos al mismo tiempo) fue arrestado. 

Es un caso único, entre todos los delincuentes que organizaron botnets realmente grandes y obtuvieron grandes beneficios (millones de dólares), el que fuera arrestado.

Agradecimientos especiales a mis compañeros del Grupo-IB, Dmitry Volkov and Ilya Sachkov, quienes se encargaron de la mayor parte de la investigación en el caso Carberp.

Fuentes: Ontinet.com - Josep Albors













0

Falla crítica en Internet Explorer, código de ataque publicado

Jesus Bourne 2 de julio de 2012

Microsoft confirmó que la falla está siendo usada en “ataques limitados”, sin embargo la compañía no ha actualizado (aún) su boletín MS12-037 para dejar claro que el código público del exploit está ampliamente disponible.

La semana pasada, cuando Microsoft lanzó la actualización crítica de Internet Explorer, la empresa emitió una advertencia de que el código funcional podría ser liberado dentro de 30 días.

Menos de una semana después, un exploit de una de la falla "crítica" del navegador se ha instalado en la herramienta de ataque de distribución gratuita Metasploit, las muestras han sido liberadas a Contagio, un blog que da seguimiento en directo los ataques de malware.

La adición del exploit en Metasploit significa que los ciber-delincuentes tienen ahora acceso a copiar el código de ataque para su uso en el kit de explotación y otros ataques de malware de comunicación.

La vulnerabilidad (CVE-2012-1875) es un defecto de ejecución remota de código en la forma en que Internet Explorer obtiene acceso a un objeto que ha sido borrado.

La vulnerabilidad puede dañar la memoria de tal manera que un atacante podría ejecutar código arbitrario en el contexto del usuario actual.

Microsoft ha confirmado que este error está siendo utilizado en "ataques limitados", pero la compañía no ha actualizado (todavía) su boletín MS12-037 para aclarar que el código público del exploit está ahora ampliamente disponible.

Según McAfee, los ataques comenzaron cerca del primero de junio 2012:

El exploit funciona en las principales plataformas de Windows, incluyendo Windows Vista y Windows 7. Aprovecha la programación orientada al retorno (ROP), la tecnología de la explotación de derivación con ejecución de datos (DEP) y las protecciones aleatorias del espacio de direcciones de diseño (ASLR), y el gancho de salto de las técnicas de evasión para evadir las detecciones basadas en host IPS. 

Se requiere del sistema de la víctima para ejecutar una vieja máquina virtual de Java que viene con una versión non-ASLR de msvcr71.dll. Si Java no está instalado o no existe una versión non-ASLR de msvcr71.dll en el sistema, el exploit no tendrá oportunidad, a pesar de que hará que Internet Explorer deje de funcionar.

En Windows XP, la vulnerabilidad puede ser explotada de forma fiable sin ningún componente de terceros. Encontramos que el exploit trató de descargar y ejecutar un binario desde un servidor remoto.

El servidor fue hospedado por Yahoo y fue retirado el mismo día que Microsoft informó acerca de este hecho.

Los investigadores de AlienVault Labs reportan el descubrimiento de "varios servidores de hosting de versiones similares del exploit." También dijo que el exploit es compatible con una amplia gama de idiomas y versiones de Windows (desde Windows XP hasta Windows 7) y parece ser muy confiable.

Es importante señalar que esta vulnerabilidad es completamente diferente de la vulnerabilidad de IE sin parchar ligada a la de "los atacantes de algún Estado" que participan en los ataques actuales contra GMail y usuarios de Windows.

La siguiente video muestra el exploit en acción de Metasploit:




Fuentes: ZDnet
0

Vulnerabilidades de seguridad, métrica y amenazas de SAP

Un reporte global dedicado a SAP security muestra varios servicios críticos expuestos en un 5%-25% (dependiendo del servicio) de las compañías que implementan SAP.


Uno de los objetivos de la investigación era desmentir el mito de que los sistemas SAP están asegurados contra  hackers y sólo están disponibles desde la red interna. 

Aunque todas las recomendaciones de SAP y de empresas consultoras dicen que incluso el acceso interno a los servicios administrativos innecesarios debe ser restringido, se encontró que muchas compañías configuran mal su entorno y exponen servicios críticos a Internet. 

La razón, en algunos casos, es la falta de conocimiento y en o tras ocasiones las empresas quieren tener un control remoto fácil, lo que las hace inseguras.

Por ejemplo, routers SAP 2012 fueron encontrados en Alemania, los cuales fueron creados principalmente para rutear el acceso a los sistemas internos de SAP. Los routers de SAP pueden tener errores de configuración de seguridad en sí mismos, pero el verdadero problema es que el 8% de estas empresas también los exponen directamente a Internet, por ejemplo, el servicio SAP Dispatcher, eludiendo al Router de SAP.

Este servicio puede ser fácilmente explotado por una sesión con las credenciales por defecto o por la explotación de algunas de las vulnerabilidades que fueron parchadas por SAP en mayo de 2012. 

Además, el 9% de la muestra estudiada (que incluía mil empresas que utilizan SAP en todo el mundo) exponen la consola de administración de SAP, que es vulnerable a la recolección no autorizada de los parámetros del sistema de forma remota desde Internet. La mayoría de ellos se encuentran en China (55%) y en India (20%). 

Los principales hallazgos son:

• La mayoría de los problemas (69%) tienen una alta prioridad, lo que significa que aproximadamente 2/3 de las vulnerabilidades publicadas deben ser corregidas rápidamente.

• Un total de 2,677 servidores únicos con diferentes aplicaciones web de SAP fueron encontrados en Internet usando Shodan Search.

• 59% de ellos son vulnerables a la divulgación de información.

• Los sistemas operativos más populares para SAP son Windows NT (28%) y AIX (25%).

• Se encontró que el 40% de los sistemas de NetWeaver ABAP en Internet tienen el servicio habilitado WebRFC que permite llamar a funciones críticas relacionadas con el negocio y la administración. La función es asegurada por nombres de usuario y contraseñas, pero hay demasiadas credenciales predeterminadas que funcionan en la mayoría de los casos.

• Se encontró que el 61% de los sistemas J2EE en Internet tienen el servicio de CTC habilitado. Este es vulnerable a Verb Tampering, que permite eludir la autenticación y aún se encuentra sin actualizar en la mayoría de las empresas.

Fuentes: NetSecurity

.

Compartelo:
 
Copyright 2010 SI3H-C5IRT