Menú

Mostrar Mensajes

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

Mostrar Mensajes Menú

Mensajes - Buster_BSA

#31
Cita de: r32 en 13 Enero 2013, 15:07 PM
Buster "nunca digas nunca", ni en informatica ni en la vida real son aplicables.
No te quito tu parte de razón, ni a Karcrack, son puntos de vista diferentes de dos programadores.

Visto desde un punto de vista lógico y racional el número de vulnerabilidades que permitan realizar una determinada acción es un número finito. En cuanto el que diseña el software corrige las vulnerabilidades ese número llega a 0 y en este momento es imposible realizar esa determinada acción.

Cuando un software llega al número 0 en vulnerabilidades por mucha imaginación que le intentes echar (y repito que la imaginación sirve para crear ideas) será imposible lograr tal acción.

Eso es lógica pura y dura y no es discutible como tampoco es discutible que el todo es mayor que cualquiera de las partes.

#32
Cita de: ameise_1987 en 13 Enero 2013, 16:51 PM
@Buster_BSA: tu comentario a mi me dio a entender que hablabas del código fuente como única manera de analizar y conseguir un bug, si no es así sorry quizás te expresaste mal o yo entendí mall.

Obviamente la ingeniería inversa suele ser la forma más empleada para buscar vulnerabilidades y exploits porque, sobre todo en software de seguridad, el código fuente no está disponible.

Lo que también es obvio es que es muchísimo más fácil encontrar defectos en el software si tienes el código fuente porque te ahorras toda la parte de la ingeniería inversa y te puedes centrar completamente en buscar los fallos de seguridad.

Cita de: ameise_1987 en 13 Enero 2013, 16:51 PM
aún así sigo pensando que la imaginación es lo que te impone las cosas, nada mas !!

Si eres capaz de darme un argumento por el cual puedas concluir de forma lógica y razonada que la imaginación del que busca un fallo de seguridad en concreto en un software es mayor o mejor o como lo quieras llamar que la de la persona o personas que diseñaron y programaron el software para evitar que ese fallo exista, entonces te daré la razón.

¿Te parece justo?
#33
Cita de: 0xDani en 13 Enero 2013, 14:24 PM@Buster_BSA, y no se podria usar algun tipo de ofuscacion extrema o conseguir lo que quieras sin hacer acciones consideradas maliciosas? O hacerte pasar por una aplicacion normal y corriente? Porque digo yo que las aplicaciones legitimas tambien podran añadir una entrada al registro o descargar un fichero de una web. En fin, esta claro que es otro nivel de analisis, parece mucho mejor que el estatico clasico, pero tampoco creo que sea imposible saltarselo.

En el análisis por comportamiento la ofuscación no vale para nada. Ya puedes usar toda la ofuscación del mundo que si al final droppeas un fichero a disco va a quedar constancia de tal acción. Y lo mismo si alteras una clave del registro o si te conectas a una página web y descargas un archivo.

Es cierto que las aplicaciones legítimas también escriben en el registro, se conectan a internet y descargan ficheros o crean ficheros en el disco duro.

En el análisis por comportamiento no solo se evalúan las acciones, también se tiene que tener en cuenta si se supone que la aplicación analizada debería realizar esas acciones o no.

Pongo un ejemplo para que se vea más claro:

Descargas un keygen y cuando lo ejecutas escribe en la clave del registro "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" y el fichero se copia a "C:\WINDOWS\System32\Scvhost.exe".

¿Qué debes pensar de que un keygen haga tal cosa? Pues que contiene un malware obviamente.

Otro ejemplo:

Descargas una versión del navegador FireFox y añade claves en el registro y crea ficheros dentro de "\Archivos de programa\FireFox".

¿Qué debes pensar de que un instalador del FireFox haga tal cosa? Pues que aparentemente es normal.

Evidentemente la herramienta de detección 100% efectiva no existe y solo con un análisis manual y exhaustivo de una aplicación se puede estar seguro de que no contiene código malicioso.

Cita de: 0xDani en 13 Enero 2013, 14:24 PMNo se trata solo de que la aplicacion tenga un bug, en parte estoy de acuerdo con Karcrack en que el limite lo pone tu imaginacion.

Pues yo no estoy de acuerdo. La imaginación te sirve para crear una idea, por ejemplo saltar desde una máquina virtual e infectar el host. Luego son la experiencia y los conocimientos los que te permiten llevar esa idea a la práctica.

Y como ya he dicho, no todas las ideas se pueden llevar a la práctica porque los que fabrican software también tienen imaginación, y ellos también tienen ideas, como la de evitar que sea posible que una aplicación desde la máquina virtual se pueda hacer con el control del host.

Pregunta para todos:

¿Por qué dais por supuesto que la imaginación del que intenta evadir la protección en un software es mayor o mejor que la imaginación del que creó el software?

Seguro que nunca os habías hecho tal pregunta, ¿verdad?
#34
Cita de: ameise_1987 en 13 Enero 2013, 03:44 AM
estás totalmente equivocado y hablando desde la ignorancia pura y dura

Vaya, entonces debo haber perdido el tiempo durante los últimos tres años mientras realizaba mi herramienta y no debería sentirme tan orgulloso de que sea una referencia en el análisis por comportamiento a nivel mundial. En fin, ¡qué se le va a hacer!

Y bien, ¿tú qué has hecho para que cuando hables no lo hagas desde la ignorancia pura y dura?

Cita de: ameise_1987 en 13 Enero 2013, 03:44 AMuna cosa es el
ANÁLISIS DE CÓDIGO ESTÁTICO Y OTRO ES EL ANÁLISIS EN TIEMPO REAL, son dos cosas totalmente diferentes,

¿Y yo he dicho que sean dos cosas iguales? ¿Dónde si se puede saber?

Cita de: ameise_1987 en 13 Enero 2013, 03:44 AMdecir que al tener el código fuente no es necesario realizar ingeniería inversa es una ignorancia del porte de un buque 2

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_inversa

"El objetivo de la ingeniería inversa es obtener información o un diseño a partir de un producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado."

Precisamente se llama inversa porque partiendo del código binario has de conseguir el código ejecutable.

¿Y eres tú el que me acusa de hablar desde la ignorancia?

;-)

#35
Cita de: 0xDani en 13 Enero 2013, 02:49 AM
@Buster_BSA, puedes explicar un poco como funciona el analisis por comportamiento? Quiza eso ayude a esclarecer la cuestion.

El análisis por comportamiento es la ejecución de un programa dentro de un entorno controlado donde las acciones del programa están siendo monitorizadas. Cualquier modificación del registro, del sistema de ficheros, apertura o conexión a puertos, etc será traceada para al finalizar el análisis revisar toda la información y generar un informe con aquellas acciones que son consideradas como maliciosas.

Por ejemplo: un malware cuando se ejecuta realiza las siguientes acciones:

* Se copia a sí mismo en otra localización del disco duro y luego se borra de la carpeta desde donde se ejecutó.

* Añade una entrada en el registro para que cuando se inicie el sistema operativo se cargue

* Se conecta a una página web, descarga un fichero y luego lo ejecuta.

Todo eso será registrado y en el informe será resaltado porque son todas acciones maliciosas.

Así funciona el análisis por comportamiento.
#36
Cita de: Karcrack en 13 Enero 2013, 02:10 AM
Tú dirás:
https://www.virtualbox.org/report/6

¿Y cuál de esos reportes se refiere a que puedas escribir en el host desde dentro de la máquina si se puede saber?

Cita de: Karcrack en 13 Enero 2013, 02:10 AMObviamente no basta con imaginar las cosas hay que tener alguna base por dónde empezar. Para software muy trabajado como el kernel de Linux (de código abierto) o Windows siguen apareciendo graves vulnerabilidades. ¿No te da que pensar?

Una cosa es un sistema operativo y otra cosa es una máquina virtual. Te vuelvo a preguntar: ¿qué vulnerabilidades han aparecido en los últimos dos años que permitieran escribir en el host desde la máquina virtual en VirtualBox o en VMWare?

Cita de: Karcrack en 13 Enero 2013, 02:10 AMSinceramente no veo que esta charla nos lleve a ningún lado y nos estamos yendo bastante del asunto principal. Si te interesa estaría encantado de seguir intercambiando opiniones contigo por privado.

Nos lleva a responder la pregunta inicial: "Hola, estoy iniciándome en el tema de indetectar malware, mi pregunta es si modeando se puede evitar que te pille la heurística y el sandbox"

Y la respuesta es no, no se puede, a no ser que detectes que estás bajo un entorno de análisis y entonces abortes la ejecuación.

Bueno, si me apuras te diría que el malware realice acciones maliciosas solo a determinadas horas del día y que el resto del tiempo simplemente no haga nada para que así si es analizado por una herramienta de análisis de comportamiento lo más probable sea que no coincida la hora y por lo tanto el análisis dé negativo.

Lo que está claro es que si el malware realiza acciones maliciosas durante un análisis eso no hay modeo que se lo salte.
#37
Cita de: Karcrack en 12 Enero 2013, 23:59 PM
Estoy completamente de acuerdo en que hay una cantidad finita pero con el paso de tiempo aumenta :P

Yo creo que el límite está en la imaginación y tú (en mi opinión) pones el límite donde los mejores lo han dejado. >:D

Aquí la imaginación no vale de nada. Los agujeros son los que son y hay que saber encontrarlos.

De hecho el VirtualBox es de código abierto, con lo cual el código fuente está disponible y no hace falta hacer ingeniería inversa. Que a pesar de contar con el código fuente no salgan nuevas vulnerabilidades, ¿es que no te dice nada?
#38
Al menos estarás de acuerdo en que el número de formas distintas de hacerlo es un número finito, ¿no?  :P
#39
Cita de: Arkangel_0x7C5 en 12 Enero 2013, 15:29 PMyo he visto a virtualbox  crasear algunas veces a causa del anfitrion, y si crasea es que hay bug, y si hay bug es posible salirse de la maquina virtual. otra cosa es que sea tan complicado que no lo hayan conseguido

Que haya bug en una parte del programa no significa que lo haya en la parte que aisla el host de los programas que corren en la máquina virtual.

Insisto: gente muy preparada han intentando saltar de la VM al host y en el pasado, hace años, lo han logrado, pero el número de vías posibles para hacer eso es limitado, no infinito, y por lo tanto en cuanto se han cerrado todas las vías posibles, ¿cuántas quedan? Pues obviamente 0.
#40
Yo te recomiendo C/C++. Si no estás hecho para la programación, el C te lo hará saber.