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
jueves, 29 de marzo de 2012
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__
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+
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
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
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
Suscribirse a:
Entradas (Atom)