jueves, 4 de julio de 2013

Descubierto un fallo de seguridad que afecta al 99% de los terminales Android.

Está claro que no hay ningún sistema 100% seguro, y por desgracia hoy nos toca sufrir a los usuarios de Android tras la revelación por parte de un grupo de investigación de seguridad informática. Y es que nuestro apreciado sistema operativo sufre un fallo de seguridad que estaría afectando al 99% de los terminales, así que no es una cuestión para tomarse a la ligera.

El grupo de investigación de Bluebox ha descubierto que es posible manipular un APK (archivo de aplicación) sin romper su firma criptográfica, que es lo que la hace que el sistema “confíe” en ella. Así que es posible convertir una aplicación legítima en un troyano sin levantar sospechas tanto desde el propio sistema, como desde Google Play.  La cosa es muy seria, ya que este fallo está presente desde Android 1.6 Donut, con lo que el número de terminales afectados puede ser muy elevado.

Según cifras de la propia Bluebox la vulnerabilidad podría afectar a 900 millones de terminales y la afectación de este fallo podría suponer desde el robo de nuestros datos hasta la creación de redes de terminales “zombies” desde las cuales operar. Según advierten esto puede resultar potencialmente peligroso con aplicaciones de los fabricantes, puesto que estas tienen privilegios bastante elevados del sistema.

El fallo, que se reportó a Google en Febrero, y por el momento no existe ningún parche que corrija este problema. Consultada la compañía californiana al respecto, han declinado hacer comentarios, pero algunos cambios en el acceso de las aplicaciones de forma que se bloquearía el acceso a las apps con este agujero denota que Google está trabajando en ello. Desde luego esperamos tener más noticias positivas en breve, ya que se trata de uno de los fallos de seguridad más graves de Android hasta la fecha.

Fuente: http://www.elandroidelibre.com/2013/07/revelado-un-fallo-de-seguridad-que-afecta-al-99-de-los-terminales-android.html

jueves, 13 de junio de 2013

Un exploit de Linux ha sido portado a Android.

El pasado abril se alerto de una vulnerabilidad en el kernel Linux que permitiría a un atacante lograr una escalada de privilegios en el sistema. El agujero de seguridad fue rápidamente parcheado, pero, todavía nos aguardaba una sorpresa: el exploit que, valga la redundancia, explota dicha vulnerabilidad, ha sido portado a Andorid.
La fuente de la noticia la encontramos en el blog de Symantec, donde además de recomendar Norton Mobile Security como solución al problema, recuerdan una evidencia, que Android se basa en Linux, por lo que portar este tipo de malware es más bien sencillo. Aunque por el rango de versiones de Linux afectadas, de la 2.6.37 a la 3.8.9, algunos dispositivos se puedan quedar fuera.
Conviene señalar que la vulnerabilidad de la que se habla en este caso solo puede ser explotada mediante acceso local a la máquina, por lo que su gravedad es relativa. En cualquier caso, Google tiene un problema con la seguridad de Android que no termina de solucionar. Y no nos referimos a que el 90% del malware móvil esté diseñado para Android, que al fin y al cabo el la plataforma dominante.
El problema tiene dos cabezas: la permisividad de Google Play para con los desarrolladores, por la que te pueden colar un troyano desde la misma tienda de aplicaciones de Android; y la política de actualizaciones del sistema, a la que se ha llegado a calificar como una práctica de negocio fraudulenta y engañosa.

domingo, 9 de junio de 2013

Convertir nuestro Terminal Android en un punto de acceso Wifi.



Las posibilidades de los teléfonos móviles de alta gama que muchos de nosotros llevamos encima a diario son innumerables y con cada actualización de Software y de Hardware las virtudes de estos aumentan ostensiblemente, es verdad que a día de hoy son muchos los usuarios que todavía no son conscientes del potencial real de lo que llevan en sus bolsillos pero también es verdad que la comunidad de Android sigue creciendo y a un ritmo vertiginoso lo cual es bueno ya que con el tiempo muchos perderán el miedo a adentrarse en las tripas de Android y por ejemplo hacerse Root ( En pocas palabras el hecho de tener acceso Root a tu terminal móvil es como si fueras el Administrador de un sistema, vamos que tienes el poder de hacer y deshacer todo cuanto te plazca, siempre con cabeza claro), pero hoy no vamos hablar del como podemos obtener acceso Root a unos de estos "pequeños" smartphones, hoy el articulo ira enfocado a como podemos hacer para que otros dispositivos informáticos ya sean portátiles, tablets, otros móviles, ect...se conecten a Internet por mediación de otro dispositivo que en este caso sera un Samsung Galaxy S2, aquí explicare todos los pasos para que este terminal haga de punto de acceso y por consiguiente ofrecer Internet a todo aquel que lo solicite y tenga el Password ;-).

Como bien dice el titular vamos a dejar nuestro terminal móvil preparado y configurado para todo aquel que necesite conectarse a Internet en un momento dado, como por ejemplo en un tren, en el metro, en un autobus, en fin, ect....bueno empecemos.


1- Hacemos link en el botón de nuestra izquierda y elegimos la opción de -Ajustes- y dentro buscamos la opción donde pone -Mas ajustes- entramos ahí y volvemos a presionar sobre -Zona Wifi y Modem USB-.


2- Una vez en la -Zona Wi-Fi- procederemos a activarla para configurar nuestro punto de acceso:

- Red SSID---> ( Nombre de la red para que los demás puedan identificarnos )
- Seguridad---> ( Yo optaría por WPA2-PSK )
- Contraseña---> ( Pondremos una que no se parezca a 1234 )

...y ya esta.

Ahora solo nos queda hacer la prueba de conexión con cualquier dispositivo que tenga Wi-Fi que hoy en día son casi todos, por cierto...

Warning: Tener cuidado a quien le damos acceso a nuestro nuevo punto de acceso creado desde nuestro Smartphone con Android (en este caso un Galaxy S2) porque hay que recordar que son vuestros Mb de la compañía-operadora X los que saldrán volando desde vuestro terminal y no es lo mismo darle acceso a un equipo que dárselo a 3, lo quiero decir es que hay que tener cuidado y cabeza porque la factura del móvil nos podría dar un buen susto al mes siguiente, en fin esto es todo. Saludos.






























viernes, 17 de mayo de 2013

Despropósito en atención al cliente y servicio de Internet Móvil nefasto de ONO.

Este post va a ser largo y pido paciencia a todo aquel que decida leerlo entero pues al terminar tendréis datos que no muchos conocen en estos momentos sobre todo con respecto a la telefonía móvil de ONO y las MALAS PRACTICAS DE MOVISTAR CON LOS SAMSUNG GALAXYS que rayan en la legalidad.



LA PORTABILIDAD DE MOVISTAR A ONO MÓVIL.


Resulta que hace unos dias decidi hacer una portabilidad de mi numero de Tlf movil de Movistar a ONO y decidi escoger la tarifa TP500 la cual si no me equivoco se promocionaba en vuestra web de la siguiente manera:











Tarifa plana TP500:

1- 500/minutos mes en llamadas a cualquier operador, fijo o movil, las 24 horas del dia, los 7 dias de la semana.

2- Establecimiento de llamada incluido.

3- 500mb/mes en datos, para navegar por internet con la mejor cobertura de la red 3G. Si    consumes toda tu tarifa de datos, sigue navegando a velocidad reducida totalmente gratis.

4- Sin compromiso de permanencia en la tarifa, puedes cambiar gratuitamente tu tarifa una vez al mes, para adaptarla a tu consumo.

5- Precio con IVA: 12.01€/Mes.

PD: Copiado textualmente de una captura de pantalla arriba expuesta.

Ahora bien, el punto Nº4 sabia que no podia ser asi y pregunte en atencion al cliente y me dejaron claro que no era tal y como se promocionaba y que conllevaba 12 meses de permanencia en el servicio y en caso de no cumplimiento la sanción seria de 90€, vale, hasta ese punto lo entiendo, todos lo hacen.

Primer Problema.

Sin embargo y una vez hecha la portabilidad de Movistar a ONO resulta que no funcionaba ni la conexión 3G y menos la H+ ni los mensajes de texto, ni los MMS...vamos casi nada de lo que contrate. Bueno me puse de nuevo en contacto con la atención al cliente de ONO y seguí todos y absolutamente todos los pasos para configurar mi smartphone (un Samsung Galaxy s2 con Jelly bean 4.1.2 instalado) y nada seguía sin Internet por 3G y sin poder mandar mensajes ni MMS y sin prácticamente nada solo llamadas Tlf enviar/recibir.

PD: Por si alguien se lo pregunta antes de portar mi numero a ONO mi Samsung Galaxy s2 estaba ya liberado y lo sigue estando puesto que al cumplir los 18 meses de permanencia con Movistar ellos mismos me proporcionaron el código de liberación de mi Samsung Galaxy S2, un código que liberación a medias puesto que la parte de datos no lo estaba...seguimos.

Vosotros mismos -ONO- (en atención al cliente) me disteis un numero de teléfono de una compañía que libera móviles llamada DoctorSIM la cual tiene un convenio de colaboración con ONO para poder liberar aquellos moviles que son de ONO o deciden portarse a ONO, vale.

Segundo Problema y de paso alucino.

Pues el chico que me atendió al otro lado -IMPORTANTE- me dijo textualmente que la compañía Movistar tenia (por decirlo de alguna manera) toda la serie Galaxy de Samsung capados para que la gente tuviera problemas a la hora de cambiarse a otra compañía y las APN de ONO (en este caso) o de otra compañía no pudieran guardarse correctamente con lo cual INTERNET=OFF, ect...

(Imaginar mi cara cuando empezó a contarme esa película propia del mejor director de Ciencia Ficción).

Captura de pantalla desde la web de DoctorSim por si alguien todavía duda.

Enlace--> http://soporte.doctorsim.com/entries/23155143-Samsung-no-almacena-el-nuevo-APN















El como arregle el problema es otra historia...lo hice yo sólito y sin ayuda de ningún servicio técnico, los tres puntos mas abajo expuestos son básicamente lo que hay que hacer para arreglar el capado de Movistar para mas info ya sabéis Google.

1-Odin 3.07
2- Instalación de Jelly Bean 4.1.2 limpia sin las porquerías que le meten los operadores.
3- Obtener acceso Root al terminal, en Google hay mucha información al respecto aunque casi todo esta en http://www.xda-developers.com/ en esa web esta absolutamente todo lo necesario.

Una vez echo todo esto mi Smartphone funcionaba mejor que cuando me lo vendieron el primer día estos de Movistar, en fin seguimos...

Tercer problema y el peor de todos.

¿En que momento se me advirtio de que al pasarme de Movistar movil a ONO-Movil (a la tarifa TP500 descrita arriba) mi conexion a Internet fija (la de mi casa) iba a bajar de 30Mb a 12Mb?, me gustaría que me pusierais la grabación donde se me advierte de esa bajada, gracias.



Y eso no es todo ¡¡LA CONEXION MOVIL DE ONO ES SIMPLEMENTE PENOSA¡¡.
no se como se atreven a llamarla banda ancha móvil ¡¡Increible¡¡.


EDITO: Al cesar lo que es del cesar, resulta que esta penosa velocidad de Internet Móvil en realidad se  debía a que el primer mes y dependiendo de la fecha en la que te des de alta con el operador (ONO en este caso) es lógico que no tengas los 500Mb enteritos a máxima velocidad, lo que quiero decir es que este problema esta arreglado ya que ONO tarifica cada día 26 de cada mes, en fin espero haberme explicado correctamente, por supuesto pienso que este dato deberían decirlo a todos sus clientes nuevos y no dejar que cada uno lo averigue por su cuenta con el consiguiente gasto telefónico ya que (por si alguno no lo sabe) la Atencion al Cliente de ONO no es gratuita, en fin saludos.








martes, 16 de abril de 2013

Hugo Teso muestra como Hackear un avion usando un dispositivo Android.


Cuando viajamos en avión, además de los tediosos controles de seguridad a la hora de embarcar, en las maniobras de despegue y aterrizaje nos hacen apagar nuestros dispositivos electrónicos "para no interferir" los sistemas del avión. Cualquier avión dispone de sistemas electrónicos (conocidos como aviónica) y sistemas de transmisión por radio, computadoras embarcadas en el aparato que controlan todo lo que pasa a bordo y en los que no solemos pensar cuando realizamos un viaje pero ¿hasta qué punto estos sistemas pueden ser vulnerables? A esta pregunta ha respondido Hugo Teso, un experto en seguridad, que durante una conferencia impartida en el día de ayer asombró a los asistentes mostrando cómo era posible atacar los sistemas de un avión valiéndose, entre otras cosas, de un dispositivo Android.

Teso, que además de trabajar en el ámbito de la seguridad tiene también formación como piloto comercial, mostró a los asistentes a la Hack In The Box Conference de Amsterdam cómo podría ser posible interferir en los sistemas de un avión con tecnología que está alcance de nuestra mano y que, por ejemplo, podemos comprar a través de Internet. Dicho de otra forma, mostró cómo podría ser posible hackear un avión y controlarlo a distancia.

Teso se centró en dos de los sistemas que hay a bordo de cualquier avión, el ADS-B (Automatic Dependent Surveillance-Broadcast), un sistema que se encarga de emitir información sobre la identificación del avión, su posición o datos sobre su altitud para que los controladores aéreos mantengan localizados los aviones en el espacio aéreo y para que las aeronaves reciban por este canal información sobre el tráfico aéreo en la zona o la información climatológica. El otro sistema en el que se centró es el ACARS (Aircraft Communications Addressing and Reporting System) que es el sistema que utilizan los pilotos para intercambiar mensajes e información con otros aviones o con el control de tierra usando enlaces vía satélite o bien por ondas de radio.

¿Y qué fue lo que hizo? Según comentó este experto durante su ponencia, ambos sistemas son bastante vulnerables y, por tanto, susceptibles de ser atacados. Concretamente, se valió de la información del ADS-B (que es una señal de broadcast) para obtener información de aviones y, por tanto, seleccionar objetivos y, por otro lado, usó el ACARS para obtener información sobre el sistema del avión para aprovechar sus vulnerabilidades y enviar "mensajes malintencionados" que pudieran afectar al comportamiento del avión.

Teso desarrolló un framework que era capaz de insertar información en los planes de vuelo de la computadora de un supuesto avión (lo ha realizado sobre una maqueta) y desarrollando una aplicación Android que se apoyaba sobre este framework podía transformar un teléfono móvil o un tableta en una especie de "clon" del famoso Flight Simulator de Microsoft puesto que se podían visualizar parámetros de la aviónica del avión e, incluso, controlarlos a distancia.

Aprovechando la información de servicios como Flightradar24, que monitoriza la posición de los vuelos comerciales, esta aplicación Android era capaz de mostrar vuelos que estaban dentro del rango de influencia de este sistema de intercepción (algo que en un escenario real dependerá fuertemente de la estación emisora de broadcast que se utilice) y, sobre el vuelo seleccionado, obtener la información del plan de vuelo, su identificador unívoco y, en el caso de ser susceptible de poder atacarse, obtener una alerta que indique que se puede interferir en los sistemas del avión.

¿Interferir en los sistemas? Aunque pueda sonar inquietante, este experto en seguridad mostró algunos de los detalles que podía hacer esta aplicación en su entorno de pruebas: cambiar el plan de vuelo, fijar condiciones de "disparo" para programar un evento cuando el avión sobrevuele una zona concreta, estrellar el avión, lanzar alarmas o aprovechar el acelerómetro del smartphone para transformarlos en los mandos y controlar el avión.

Es justo decir que todo lo que presentó es un trabajo de investigación y, por tanto, es una interesante llamada de atención a la industria aeronáutica puesto que Teso ha replicado el escenario real en una "maqueta de laboratorio" y ha trabajado sobre ésta, de hecho, todo el software que ha desarrollado funciona únicamente sobre la maqueta para que no pueda extrapolarse a un escenario real.

De todas formas, aunque todo este planteamiento sea bajo un escenario simulado, he de confesar que es bastante inquietante que los sistemas básicos de comunicación de los aviones puedan presentar vulnerabilidades que permitan ejercer, de manera remota, el control de un avión y, llevándolo al extremo, ponen sobre la mesa que muchas de las medidas de seguridad que se toman no sirven de mucho si la aviónica del avión es tan vulnerable y se sigue basando en estándares de comunicación fijados en la década de los años 70 aunque, eso sí, según comentó Teso este tipo de vulnerabilidades se producen en los casos en los que el avión vuela con el piloto automático.

Aún así, la presentación, en mi opinión, no tiene desperdicio alguno.

Fuente: http://alt1040.com/

domingo, 27 de enero de 2013

Evasión de Antivirus: ¿Por qué vulnerabilidades conocidas y antiguas siguen siendo peligrosas?.


Antes de entrar en la parte técnica y llegar a la programación, donde seguramente muchos lectores dejen de leer, quiero hacer una pequeña introducción para todos los públicos.

En este artículo voy a escribir un poco sobre lo fácil que es burlar la protección de un antivirus sin tener que recurrir a técnicas complejas y algoritmos "vanguardistas" como encoders, polimorfismos, metamorfismos y demás ingenios, que muchas veces nos llevan a la falsa creencia de que un posible intruso o creador de malware debe ser un genio de los ordenadores, y como hay pocos genios es difícil que nos toque. De hecho un gran porcentaje de incidentes de seguridad se produce aprovechando vulnerabilidades o malware antiguos, que a priori todo antivirus detectaría fácilmente de no haber sido modificados.

Eso, sumado a la falsa seguridad que nos proporciona el software como los antivirus o firewalls hace que la gran mayoría de la gente no preste la atención que debiera a la seguridad de sus sistemas (ya no vamos a entrar en el recalcado tema de cómo escoger una buena contraseña).

Se invierten millones de euros en investigación de protecciones de seguridad informática y existe todo un gran mercado en torno a ello, pero al final del día el mejor antivirus, y la mejor protección que"podría" existir para nuestros ordenadores es el propio usuario (aunque desgraciadamente, todavía siga siendo lo contrario). Muchas veces me han pedido consejo para escoger un antivirus, o me han preguntado que antivirus utilizo, y cuando yo contestaba "ninguno" se quedaban un poco sorprendidos. Si bien hoy en día si utilizo, es verdad que he estado muchísimos años sin utilizarlos.

A lo que quiero llegar es que fuera del mundillo de la seguridad informática, se sigue confiando la seguridad un 100% a programas como los antivirus, la gente se siente protegida con ellos, lo cual es contraproducente. Pequeñas cosas como mantener actualizados todos nuestros programas, ser cuidadosos con las cosas que descargamos o controlar que servicios tenemos corriendo en nuestras máquinas en cada momento quedan relegados a un segundo plano (muchísima gente ni siquiera le da importancia a no actualizar), aunque no infalible, minimizan mucho los riesgos, convirtiendo un antivirus en una capa de protección más, y no en la más importante.

Dicho esto, y después de asustar un poco a los no iniciados (esa era la intención), entremos al lío.


De todos es sabido que los antivirus basan casi el 90% de su detección en la búsqueda de signatures, partes de código reconocibles como maliciosas o sospechosas se que van actualizando en sus bases de datos de firmas según se descubren nuevos virus o exploits.

Para camuflar este tipo de firmas en malware, una de las cosas que más se están utilizando son encoders de todo tipo, que manipulan ese código detectable convirtiendolo en otro diferente que hace la misma función, pero a la larga esos encoders se vuelven inefectivos porque siguen un patrón que puede detectarse con análisis heurístico. Incluso el famoso y polimórfico shikata ga nai es inefectivo hoy en día, por muchos pases que se apliquen.


Por regla general, un antivirus realiza el análisis de los archivos tanto cuando se escriben en disco como cuando son ejecutados, pero no monitoriza toda la ejecución del mismo, porque eso requeriría de unos recursos de los que una máquina normal hoy en día no dispone (imaginad que cada vez que se ejecutase un Photoshop u otro programa intensivo computacionalmente, el AV tuviese que monitorizar en todo momento todas las operaciones que realiza).

Sin embargo existen técnicas que le pueden poner las cosas muy difíciles a un antivirus, incluso a los análisis heurísticos, y que sólo un análisis exhaustivo por parte de un humano en un entorno sandboxpodría detectar (algo impensable para la detección en tiempo real).

Algo de lo que adolecen los antivirus es que analizan los archivos independientemente, y no como un conjunto de archivos que forman una pieza de software. Y desgraciadamente deben hacerlo así para evitar multitud de falsos positivos.

Por ejemplo, en uno de los últimos exploits Java (CVE-2012-1723), compuesto por varias clases empaquetadas en un jar, detectaba la firma sólo en dos de ellas, donde se ejecutaban las funciones sospechosas, con lo que separando esas firmas en clases diferentes se podía anular la detección muy fácilmente.

Sin entrar en detalles, este exploit se basa en type confusion, asignando una clase con funciones que requieren privilegios de sistema a otra clase de distinto tipo que no los requiere, saltándose el sandbox java de ese modo. El antivirus detectaba el exploit en la clase que forzaba la confusión (llamemosle confusor), y en un par de líneas de código de otra clase, donde se creaba la instancia del confusor (probablemente para detectar variantes del exploit donde el confusor fuese diferente).

No fue necesario utilizar ningún tipo de ofuscación de clases sobre el exploit:

Para el confusor bastó con cambiar un bucle for de 100 iteraciones por 110 para que el antivirus ya no lo marcase como peligroso.

En cuanto a la clase donde se creaba la instancia de forma reflectiva, el AV lo detectaba cuando estas dos líneas aparecían juntas en el mismo archivo, pero separandolas de una manera extremadamente trivial, neutralizamos totalmente lo que el AV daba por sentado como malicioso:




Como se puede apreciar, realizando pequeñas modificaciones al código, y sobretodo separando las partes del código sospechosas en diferentes lugares es muy sencillo desaparecer de la lista de firmas del AV. De este modo y con un poco de creatividad podríamos ocultar incluso ROP chains, heap sprays...,  pilares de muchos exploits modernos.

Para continuar, y ya que hemos utilizado el exploit java para demostrar cómo evadir el antivirus durante la fase de explotación, vamos a ver como ocultar también un payload, ya que las shellcode más comunes suelen ser detectadas per se como firmas.

Hemos modificado el código del exploit de java para evitar el antivirus, pero en cuanto añadiesemos a la ecuación nuestra shellcode (por ejemplo un meterpreter https reverso), volvería a ser detectado. Dado que el exploit en java no nos limita en tamaño a la hora de weaponizarlo con un payload, y como ya nos hemos saltado el sandbox java, ¿por qué ejecutar la shellcode directamente desde el exploit, cuando podemos volcar un ejecutable a disco y lanzar la shellcode desde allí? Podría parecer una estupidez hacer una escritura a disco dando al AV una oportunidad extra de análisis, pero como veremos más adelante evitar la detección de la explotación asumiendo ese riesgo tiene sus ventajas si nos encargamos de ocultarlo bien en la fase post-exploit, donde contamos con más flexibilidad para hacerlo.


Como se puede apreciar, hemos convertido los binarios en cadenas de texto (los he truncado por legibilidad), los hemos almacenado en variables (separados en dos mitades), y los recodificamos a binario antes de escribirlos a disco, consiguiendo que el AV no los detecte al analizar el paquete Java.

Con eso ya estamos separando el payload del propio exploit (recordad, separación es la clave), pero tendremos que conseguir que el payload sea también indetectable.

Para ello vamos a utilizar varios trucos. En primer lugar, cogeremos nuestra shellcode y la partiremos en 2 mitades (una vez más). Con eso ya sería suficiente, pero para este ejemplo, además, he creado un sencillo "encoder" que hace rotaciones de bits en cada byte de la shellcode y luego los invierte, con la intención de camuflarla un poco. Así que ya tenemos dos mitades de nuestro meterpreter, previamente scrambled con el miniencoder.


Si sólo utilizaramos el encoder sobre la shellcode entera, el antivirus podría reconocerla con algo de heurística, pero de este modo aunque aplique la heurística a cada mitad, no se encontrará con la shellcode completa, con lo que no la reconocerá como firma.

Podríamos crear un sencillo ejecutable que lanzase esa shellcode, pero aquí vamos a utilizar otro truco para engañar aún más.

Crearemos un ejecutable normal (payload.exe), con una función trivial que no haría saltar jamás al antivirus, porque no realiza ninguna acción sospechosa, pero utilizaremos unas librerías dinámicas para sobreescribir esa función trivial con nuestra shellcode en tiempo de ejecución, y ya en memoria:



Debemos configurar el compilador para que no utilice el NX/XD (DEP) ni base dinámica (ASLR), de este modo la dirección de memoria que sobreescribiremos en nuestro programa no variará en cada ejecución, ni la memoria estará desorganizada por el ASLR, lo cual sería un problema para escribir secuencialmente.

Como veis, y para esta demostración, la función inofensiva() está compuesta por una serie de NOPs (o cualquier otra cosa), para hacerla más fácil de encontrar en nuestro debugger, y debe tener el tamaño suficiente para albergar nuestra shellcode una vez la sobreescribamos.

Lo ejecutamos en el debugger para localizar la dirección donde comienza dicha función:


Dado que en este caso el programa comienza a ejecutarse en 400000, nuestro offset para comenzar a sobreescribir será 53F0, que es el punto de entrada de la función.

Un análisis por parte del antivirus sobre el ejecutable no revelaría nada ya que el código de la shellcode no sobreescribe la función inofensiva() hasta que cargamos las librerías.

Como hemos partido la shellcode en 2 mitades, crearemos dos DLL (shellcode1.dat yshellcode2.dat), una con cada mitad (una vez más, separación), de este modo el AV aunque analice cada DLL en disco, no encontrará nada.



En MY_OFFSET establecemos la posición de memoria en tiempo de ejecución donde debe empezar a sobreescribir. Decodificamos nuestra media shellcode anteriormente “revuelta”, y la escribimos donde estaba la función inofensiva().

VirtualProtectEx, así como otras que permiten API hooking, es una de las funciones más vigiladas por un antivirus dado que abre las puertas a escribir en memoria en tiempo de ejecución, pero como hemos dicho antes, solo estamos escribiendo media shellcode, y es por esa razón por la que no saltará la alarma, y es a lo que me refería con que un antivirus escanea archivos independientes, y no como un conjunto.


También habréis notado que utilizo sleeps para pausar la ejecución. Es solo una sospecha personal infundada, pero aunque retrasa la ejecución del payload creo que algunos antivirus (especialmente los que quieren vendernos que casi no comen recursos al ordenador) dejan de analizar si el proceso que monitorizan es lento, especialmente si es un bucle, para ahorrar recursos y no interferir en la experiencia del usuario. Y también para tratar de que el AV no “relacione” una función con la anterior, aunque supongo que eso ya es un raciocinio humano que no se aplica a una máquina ;)


Para la segunda DLL, solo tenemos que cambiar la segunda mitad de la shellcode y el offset para continuar escribiendo en la posición donde terminó la primer mitad.

Algo que podríamos hacer para enrrevesarlo aún más (aunque para no complicarlo demasiado no lo hemos hecho aquí), sería empezar escribiendo la segunda parte de la shellcode, y luego la primera (simplemente invirtiendo el orden en el que hacemos el LoadLibrary), con lo cual nos curamos en salud ante un posible análisis secuencial de lo que estamos escribiendo en memoria.

Ya para terminar, vamos a añadir una capa más de separación, utilizando un ejecutable (spawner.exe) , el cual es el verdadero ejecutado por nuestro exploit java y que será el encargado de lanzar el payload (Nota: he hecho esto porque a día de escribir el código, el reverse https terminaba el proceso al cabo de unos minutos si no se establecía una conexión):




Este pequeño programa también es inofensivo a los ojos del AV, y lo único que hace es monitorizar si existe el proceso de nuestro payload, y si no es así, lo relanza.

Además, como hemos creado una entrada en el autorun del registro (lo cual podría resultar sospechoso para el AV), siempre es mejor que el "sospechoso" sea este nuestro spawner inofensivo, y no el que carga las librerías del payload.


Resumiendo:

  • Hemos lanzado nuestro exploit en java, ya modificado, con lo cual el antivirus no lo ha detectado. 

  • El exploit ha volcado 4 archivos al directorio temporal de Windows. El AV los analiza en el momento en que se escriben a disco. Dos de ellos son ejecutables inofensivos, con lo cual no los detecta. Los otros dos son las librerías donde está la shellcode, pero son dos archivos independientes, el AV tampoco detectará una shellcode completa. 

  • Se ejecuta nuestro lanzador inofensivo, el AV no lo detecta en la ejecución. Se ejecuta el payload lanzado, y el AV analiza qué trata de hacer (una función inofensiva), también analiza las DLL al cargarlas (pero cada una realiza la sobreeescritura por separado, tampoco las detecta). Llegado ese punto la shellcode ya está reemplazando la función inofensiva(), pero el AV ya no puede detectarlo, ya que para ello tendría que volver a analizar la ejecución completa del programa en memoria y darse cuenta que el código fue sobreescrito, algo que requeriría muchos más recursos, y que en un programa más complejo sería demasiado intensivo. 


Hemos engañado al antivirus sin rompernos la cabeza con algoritmos imposibles, simplemente separando código malicioso en diversos trozos y lugares, y ejecutandolo de una forma poco convencional (sobreescribiendo una función ya existente). Podríamos haber utilizado otros trucos sencillos, como crear un programa con un overflow deliberado y explotarlo para lanzar la shellcode (algo que el antivirus jamás se "imaginaría"), en lugar de integrarla en el propio programa como una función más.

En el hipotético caso de que esto fuese un malware real, ya conocido, y con las firmas añadidas a un antivirus, bastaría con partir en más trozos todavía el código para que el AV dejase de detectarlo, y se convertiría en el juego del gato y el ratón.


¿Soluciones? Pues es bastante complicado. Para que los antivirus pudiesen conseguir una detección robusta no basada en firmas conocidas deberían ser capaces de monitorizar todos los procesos que ocurren en una máquina en todo momento, de relacionar esos procesos entre si de forma racional, tendrían que ser capaces de descubrir automáticamente vulnerabilidades en los programas (sin saber de antemano que las tienen); en definitiva, ser una inteligencia artificial que a día de hoy solo es ciencia ficción. Y necesitarían utilizar prácticamente la totalidad de los recursos de la máquina dejando una pequeñísima parte para el resto de procesos.

Fuente: http://www.securitybydefault.com/2013/01/evasion-de-antivirus-por-que.html

viernes, 18 de enero de 2013

Vulnerabilidad crítica 0-Day en millones de routers cisco.


La empresa de seguridad informática Defense Code asegura haber detectado una vulnerabilidad de día cero en routers de Linksys, subsidiaria de Cisco.

Linksys es uno de los mayores fabricantes mundiales de equipos para redes, con 70 millones de routers vendidos.

En un comunicado, Defense Code asegura haber contactado a Cisco hace varios meses con el fin de informarles sobre la vulnerabilidad de acceso root, detectada en la instalación estándar de los routers de Linksys. Defense Code habría entregado a Cisco una descripción detallada de la vulnerabilidad, acompañando ejemplos de la forma en que sería posible explotarla.

Cisco habría respondido que la vulnerabilidad estaba solucionada mediante una actualización de la última versión de su firmware. Defense Code desmiente lo anterior, señalando que la vulnerabilidad continúa presente en la última versión oficial del firmware, versión 4.30.14, recalcando que todas las versiones anteriores también serían vulnerables.

El agujero en cuestión sería demostrado en el siguiente vídeo, en que se ha probado un router Linksys WRT54GL. Aunque Defense Code no lo prueba con ejemplos concretos, la vulnerabilidad también afectaría a otros productores de Cisco.

La empresa de seguridad informática anuncia que publicará todos los detalles técnicos de la vulnerabilidad dentro de las próximas dos semanas, exhortando a Cisco a actuar con rapidez para solucionar definitivamente el problema de seguridad.

Fuente: http://diarioti.com/detectan-vulnerabilidad-critica-en-millones-de-routers-de-cisco/60316

Vulnerabilidad crítica en Java 7u10.


Java
Oracle está pasando por momentos incómodos durante estas últimas semanas, la última actualización de Java(7 u10) contenía una grave vulnerabilidad, tanto así que los expertos en seguridad informática recomendaban desinstalar el software por completo. El 13 de enero Oracle anunció una nueva actualizaciónque se suponía solucionaría todos los problemas pero no fue así, en tan solo 24 horas encontraron una nueva vulnerabilidad y el exploit se encuentra a la venta por $5.000 USD.
El día lunes, el administrador de un foro dehackers publicó un mensaje a su comunidad asegurando que vendería el nuevo exploit a dos afortunados compradores por la modesta cantidad de $5.000 USD.
Una parte del mensaje que dió el vendedor:
Hay otra vulnerabilidad en la última versión de Java 7. No voy a entrar en detalles, excepto con los compradores seriamente interesados. ¿Qué obtendrás? los archivos sin encriptar para crear el exploit, el código fuente y una versión lista para ejecutarse.
El problema es grave, el vendedor ha prometido versiones del código fuente del exploit y toda la asesoría para ejecutarlo a los posibles dos compradores, que al parecer ya fueron encontrados, ya que el mensaje ha desaparecido del foro del cual se desconoce su nombre. Esta situación no es aislada, ya había ocurido ante en el mes de octubre del año pasado y también fue monetizado el exploit por el mismo sitio.
Oracle aún no da una declaración al respecto sobre la nueva vulnerabilidad en Java, ni se espera un nuevo parche, así que aún se recomienda desinstalar el software para no sufrir ningún tipo de ataque por parte de los hackers o bien, tener mucho cuidado en los sitios web que visitas. Lamentablemente para muchos usuarios será imposible omitir del uso de Java en sus navegadores y sólo queda esperar a que Oracle ponga manos a la obra y solucione todos los problemas que tienen con el software.

Fuente: http://alt1040.com/2013/01/vulnerabilidad-en-java