Para DarkByte

[marcoszorrilla]

Gracias DarByte, la nota que dejaste sobre un tema de posible inyección de HTML, ha sido reportado al Foro de Moderadores para su solución, se ha movido del de Noticas, a fin de no dar publicidad a quién no se la merece.

Un Saludo.

[DarkByte]

Ningun problema marcos

Espero que me comenteis la evolución de esto, ya que me interesa el tema de la seguridad como ya sabéis.

Un abrazo

[marcoszorrilla]

Pues asi se hará, espero que quede resuelto esta misma noche en cuanto se conecte Emilio.

Un Saludo.

[[marceloalegre]]

Ya que salio el tema de inyeccion html, y que el post va para el amigo DarkByte quiero recordarle que todavia hay gente esperando el "Proof of Concept" de inyección dll, o por lo menos que alguien amplie mas del tema.

http://www.clubdelphi.com/foros/showthread.php?t=15348

Saludos!

[DarkByte]

No se si sigo teniendo los sources, pero me parece que son demasiado peligrosos como para dejarlos en un foro y en una sección pública.

[roman]

¡Hombre! No creo que seas el único poseedor de la caja de Pandora Quien quiera hacer daño, te aseguro que encontrará vasta información en otras partes. Además, en el hilo que se menciona, no se te pedía que publicaras no sé que sources, sólo que aclarases el concepto de inyección dll.

// Saludos

[[marceloalegre]]

Ya entiendo por que DarkByte lo decia...

Aca paso una pequeña explicación del tema que saque de una pagina (esta como para tontos):

La inyección de código (o de dll) consiste, básicamente, en pedir parte del espacio de memoria y ejecución de otro proceso para ejecutar código propio. Para haceros una idea... Veamos un ejemplo.
Supongamos una reunión de cocineros, cada uno con su fogón, sus ollas y sus ingredientes. Estamos todos en un concurso y los jueces andan paseando para observar que no se hagan trampas. En un momento dado aprovechas
para, usando una olla de otro cocinero y uno de sus fogones (un fogón excelente que le ha tocado a él, en suerte, y tú no tienes), introducir los ingredientes de tu salsa. De esta forma parecerá que la salsa la está
haciendo él, ¿no? Si pasa el juez, te verá a lo tuyo y creerá que dicha salsa pertenece a tu compañero. Desde luego, si revisa lo singredientes declarados de cada uno y el objetivo del plato podría darse cuenta de que esa salsa no se corresponde con lo que se supone que ese cocinero debe estar haciendo, pero... Los jueces no "suelen" fijarse tanto. Así que te has aprovechado de otro para ocultar que estás haciendo una salsa, ganas tiempo y ahorras olla y fogón. Encima, aprovechamos un fogón de calidad "especial" que nosotros no tenemos y que dará a nuestra salsa el punto de cocción perfecto.

Ahora extrapolemos a lo que nos ocupa. Se trata de aprovecharnos de "ciertas ventajas" de que disfrutan algunos programas en el S.O. para hacer algo sin que se sepa que somos nosotros y sin las restricciones que
nosotros podamos tener.

1.- ¿Que ventajas prácticas tiene la inyección de código?
Visto lo visto ya podeis imaginar algunas. Al margen de las más legítimas, y en lo que respecta al tema de la seguridad, las consecuencias inmediatas de la inyección de código son:

a) la posibilidad de ejecutar código "de forma invisible" en el S.O. Una vez inyectado el código en el proceso "anfitrión" podemos cerrar la ejecución de nuestro programa principal (inyector) y dejar que se siga ejecutando el código inyectado en el espacio de programa del proceso "anfitrión". Un listado de las tareas en ejecución NO revelará nuestro código.

b) La posibilidad de engañar a algunos cortafuegos que trabajan a nivel de permisos a ejecutables concretos.

Si un cortafuegos permite, por ejemplo, que el iexplore o el emule salgan a Internet, podríamos inyectar un reverse shell en uno de estos dos programas y el cortafuegos, en principio, lo dejaría pasar sin "cantar".
OJO. Algunos cortafuegos, sobre todo en su versión comercial, ya detectan este tipo de prácticas.

c) Otra posibilidad es la del ejemplo que voy a poner (por ser sencillo y fácil de asimilar por todos). Dado que estamos ejecutando código en otro proceso, podemos borrar nuestro ejecutable actual. Útil, por ejemplo, para borrar rastros. Bastará con que inyecte el código necesario en el proceso que me de la gana y finalice la ejecución de mi programa... El código inyectado se ocupará de borrar el ejecutable que he usado para inyectarlo.


2.- ¿Es tan sencillo "colarse" en otro programa?
Umm... Si y no. Usando las funciones del API, y contando con que nuestro programa lo ejecute un usuario con suficientes privilegios, inyectar código es relativamente sencillo. Sin embargo, debemos tener en cuenta que, una vez estamos en ese otro programa, todas las referencias (punteros) a funciones y datos válidas en nuestro programa dejarán de serlo en el programa anfitrión.

Eso podría complicarnos algo las cosas... De hecho mucho. Si no fuese por la tendencia conservadora de Windows de cargar en la misma dirección de memoria en todos los procesos varias de las dll básicas del API. Eso nos
permitirá saber que, al menos ciertas funciones, se encontrarán casi con toda seguridad en una posición concreta del espacio de memoria de dicho programa que, además, coincidirá con la posición que ocupa esa misma función en NUESTRO propio espacio de memoria.

Por ejemplo, librerías como kernel32 o user32 se cargan en prácticamente todos los procesos que ejecuta windows. Ntdll es otro ejemplo (aunque muchas de sus funciones están mapeadas desde kernel32). Podemos pues,
por lo tanto, usar todas las funciones de esas dll sabiendo que posición ocupan en nuestro proceso y confiando en que usarán esa misma referencia en el espacio de ejecución del programa objetivo o anfitrión.

De la misma forma, tambien debemos contar con que los datos (variables, estructuras, etc) válidos en nuestro programa no lo serán en el programa objetivo. Si definimos, por ejemplo, una variable "x" en nuestro programa,
cada vez que usemos el nombre de dicha variable para realizar una operación (x = x + 2, por ejemplo) estaremos referenciando con el nombre "X" a una posición CONCRETA de memoria dentro del espacio reservado por nuestro
programa. Sin embargo, esa posición concreta, dentro del programa objetivo, puede estar ocupada por CUALQUIER otra cosa que dicho programa necesite (otras variables, una función o parte de código, etc). Incluso es posible que ni siquiera exista esa posición concreta.

Por lo tanto deberemos buscar la forma de reservar memoria en dicho programa para alojar nuestra variable "X" y conocer la posición de memoria que referenciará dentro de ese programa, con el fin de poder usarla en el
código que inyectaremos.

Por último, en caso de ser necesario usar funciones de dlls del API que NO pertenezcan a las dll básicas, no podremos asumir que el programa anfitrión cuenta con ellas, ni que están en las mismas posiciones de memoria que en el nuestro. Así que deberemos cargarlas dentro del código que inyectaremos (afortunadamente esto es posible dado que el API cuanta con la función LoadLibraryA dentro de kernel32.dll)...
----------------------

Honestamente no tenia, ni tengo interes de hacer daño, ya tengo el codigo fuente en delphi y esto es correcto, funciona perfectamente, realmente no se que filosofia tiene el foro ante estos aspectos. Como dice roman el que quiere hacer daño puede hacerlo tranquilamente hay mil lugares por donde buscar....
Asi que si quieren los moderadores y deciden que es correcto yo lo posteo en el foro...
DarkByte no lo tomes a mal!! te respeto muchisimo, aportas muchas cosas buenas al foro!, pero en el tema de liberar info de este tipo, seguramente tenemos formas distintas de pensar!!

Saludos a todos!

[dec]

Hola,

Muy interesante kanvictor. Gracias.

[DarkByte]

Existe una técnica más, y es inyectar el código directamente. Es más avanzada que la inyección dll y no tienes ni que llevar la librería ni preocuparte por el firewall.

kanvictor, no me lo tomo a mal, pero Delphi es un lenguaje que se ha relacionado muchísimo con la población "lammeril" que hace un troyano con tres teclas. Y es cierto: hay una cantidad enorme de puertas traseras programadas en Delphi, ya que tiene una lista de funciones increibles que, en otros lenguajes como C, serían más complicadas de realizar. ¿O cómo si no se explica que haya coders de backdoors que no sepan nada sobre winsock?

Entiendo que quien quiera hacer mal lo hará, pero no porque el niño pueda acabar metiendo los dedos en un enchufe debemos de dejar los enchufes sin tapar.

Con esto quiero decir: Si la documentación está en otro idioma, los código fuente se encuentran más o menos escondidos y no se explica para tontos, estamos obligando al lector pasar una prueba: vivir para esto (ya que cualquiera que esté metido en esto entiende el vocabulario relacionado con el underground), saber entender un código fuente y utilizar neuronas para aprender el funcionamiento, de otra forma se promueve el "Trucomania Copy & Paste Hacker Style".

Después de esto, aún sin poderte asegurar del todo, puedes aceptar que la información cae en mano de personas capacitadas. Creo que casi todas las personas que han estado años en el tema de la seguridad acaban por volverse éticos por sí mismos. ¿O acaso yo el primer año no hice porquerías con mis conocimientos? Por supuesto, incluso marcoszorrilla es testigo de que tuve mis dudas éticas: cuando uno tiene los conocimientos y el poder, cuesta trabajo resistirse a ellos. Pero luego vienen los motivos... ¿Para qué voy a perder el tiempo haciendolo si puedo aprovecharlo estudiando la seguridad de OpenBSD para evitar buffers overflows, retocando los offsets de algun rootkit o mejorando mi nivel de C/C++?

Espero que se haya comprendido mis intenciones y motivos.

[vtdeleon]

Saludos

Aunque no tengo el conocimiento suficiente para hacer la "inyeccion dll", verdaderamente no me interesa, para nada. Yo estoy de acuerdo en que no se publique, si alguien lo desea pues google esta a la par.

Con la explicacion que se ha dado, por parte de DarkByte y kanvictor , es suficiente para saber el da~o que podria provocar eso.

[jmariano]

Empezado por vtdeleon

Aunque no tengo el conocimiento suficiente para hacer la "inyeccion dll", verdaderamente no me interesa, para nada...

No estoy tan de acuerdo contigo, creo que todo "conocimiento" es bueno porque nunca sabes cuando tendrás que aplicarlo. Lo que sí es verdad, es que cada uno es responsable de lo que haga después con él...

Saludos!

[vtdeleon]

Saludos

Con lo poco que se al respecto, no me viene (a la mente) un ejemplo positivo en que se pueda usar este codigo.