Mensajes

Excelente! Ahí terminé de entenderte al 100%! No es que me lo hayas explicado mal, sino que tal vez fue breve para que terminara de entender tu idea, pero con éstas últimas aclaraciones se me fue el ruido por completo. Es decir, entre nodo y nodo se puede pasar por muchos routers que pertenecen a uno o más de un sistema autónomo, y en todos esos routers se ve la IP de cada pareja, tal como me dices! Por su puesto! Tiene todo el sentido del mundo.

Gracias nuevamente, por meterte en lo técnico tal como a mi me gusta, y corregirme en lo que me estaba equivocando para tener una idea más clara de las cosas.

Saludos.

Muchas gracias animanegra por ayudarme a terminar de entender algunas cosas!!! Respecto a lo de las consultas DNS, justo mientras me escribías la respuesta, me acordé de que en algún momento use polipo para justamente forzar a que las consultas se hagan a través de tor. Hace unos minutos actualice lo que puse, sobre el final (en la P.D.), pero tu sin leer esa modificación ya me aclaraste la duda! jajaja, gracias de vuelta!

En cuanto a TOR, si sabía que usa proxys encadenados, pero lo que no sabía es que el ISP puede saber todos los nodos de TOR por los que pasa nuestro tráfico! Recuerdo que una vez quise capturar el tráfico de TOR que sale directamente desde mi PC, pero no pude. Aquí había preguntado algo desde mi cuenta anterior hace poco más de un año:

https://foro.elhacker.net/redes/capturar_trafico_que_llega_a_traves_de_tor-t473130.0.html

Saludos y muchas gracias nuevamente!

Hola, quiero hacer una síntesis de lo que entiendo sobre VPN, y qué pueden ver o no ver nuestros ISP, y quiero que me corrijan por favor si me estoy equivocando en algo de lo que digo.

El tráfico pasa si o si por nuestro ISP antes de llegar al proxy, al servidor VPN o al primer nodo de la red TOR. La diferencia es que al usar VPN o TOR estamos cifrando el tráfico, y el cifrado siempre se hace punto a punto desde el cliente (o sea desde nuesta pc, movil o dispositivo) hasta el servidor VPN, o hasta llegar al último nodo de TOR (en realidad en tor se aplica cifrado por cada nodo al que se pasa, pero luego del último nodo es donde se descifra por completo el tráfico, siempre refiriendonos al cifrado que se usa dentro de TOR, y no incluyendo HTTPS, o el cifrado que hayamos usado en la capa de aplicación).

A nuestro ISP solo le llegaría la IP del primer nodo de TOR, o la del servidor VPN, y todo el tráfico y los servidores finales a los que queremos acceder no los sabría nuestro ISP ya que va cifrado, pero una vez descifrados, lo estamos dejando en manos del último nodo de TOR o de nuestro servidor VPN, y del cifrado que se use en la capa de aplicación (HTTPS por ejemplo). Tanto el servidor VPN como el último nodo de TOR podría ver el contenido en claro dependiendo por ejemplo en el caso de la web, si la que visitamos está en HTTP o HTTPS (es decir, dependiendo si se usa o no cifrado en la capa de aplicación).

A nuestro ISP, a través de las consultas DNS que hacemos (en caso de resolver con el DNS que da nuestro ISP) solo le llegan los nombres de dominio vinculados al primer nodo de TOR o al servidor VPN. Y el último nodo de TOR o el servidor VPN si sabría en sus consultas DNS, los nombres de dominio de los servidores finales a los que queremos conectarnos.

En el caso de los proxys, no estudié muy bien pero creo que el tráfico no se cifra, y nuestro ISP puede saber tanto las IP del proxy al que nos queremos conectar, como los DNS de los servidores finales a los que queremos acceder. Recién hice una prueba, y capturando tráfico desde mi PC, utilizando un proxy, puedo ver paquetes del protocolo IRC que van y vienen hacia/desde el proxy, y en ellos solo puedo ver en claro el nombre de dominio del servidor final, pero no el contenido de la consulta DNS, ni ningún otra parte del tráfico, solo puedo ver en claro el nombre de dominio. Y esos mismos paqutes, tal cuál como salen de mi PC sería como los ve nuestro ISP (exceptuando obviamente datos de la capa de enlace, que se van modificando salto a salto).

En el caso del correo electrónico, por más que no usemos TOR ni VPN, al enviar correos a través de hotmail, yahoo o gmail por ejemplo, a nuestro ISP solo le llega el DNS correspondiente al mensajero, y todo el resto del contenido estaría cifrado a través de HTTPS y no podría ser visto por nuestro ISP. Ahora, si no nos encargamos de cifrar el contenido del correo a través de OpenPGP por ejemplo, hotmail (o el mensajero emisor), y los routers intermedios hasta llegar al mensajero receptor o destino, si podrían ver en claro nuestros mensajes, ya que el correo, luego de llegar al servidor web de hotmail o el mensajero emisor, se descifraría el HTTPS, y lo enviaría al destino a través del protocolo SMTP, esta vez en claro. Por eso la importancia de cifrar el contenido del email con OpenPGP por dar un ejemplo. Pero cabería destacar que nuestro ISP no puede saber el contenido de nuestros emails, a no ser que la página del mensajero que utilicemos, no utilice HTTPS.

Nuevamente, espero que me corrijan si estoy equivocándome en algún punto, ya que quiero estar seguro de haber entendido las cosas bien. Y si quieren agregar algo más, también están más que bienvenidos. Entender sobre privacidad me parece un tema muy importante.

Saludos!

P.D.: Una parte en la que pienso estar equivocado es sobre si las consultas DNS hacia el servidor final se hacen dentro o fuera de la VPN o de TOR, ya que ahora acabo de recordar haber utilizado polipo junto a TOR para obligar a realizar las consultas DNS dentro de TOR, según había visto en algún sitio, porque sino por defecto, las consultas DNS hacia el destino se realizan desde mi PC y no desde el último nodo de TOR.

jaja, las peliculas exageran mucho. De todas formas tener conectados 2 monitores puede llegar a resultar cómodo, por ejemplo, para tener wireshark capturando paquetes en uno mientas utilizas otras herramientas con el otro monitor. Muchas veces también se puede llegar a utilizar varias máquinas virtuales para hacer pruebas en diferentes entornos, pero obviamente la realidad está muy lejos de como te la pintan películas como esas.

Saludos!

Excelente MAFUS! Lo voy a tener en cuenta como una solución! Gracias nuevamente. Saludos

El problema es bastante complejo. Estaba investigando el código fuente de un rootkit, me parece que había tenido una duda sobre una linea complicada, y vos me ayudaste a desmenuzarla hace un tiempo, asi que gracias otra vez, jaja. Bueno, finalmente logré comprender como trabajaba y me dediqué a tomar funcionalidad de otros rootkits y adaptarlos al primero que estaba analizando, y el mayor trabajo que estuve haciendo fue el de hacer que el rootkit fuera compatible con cualquier versión de kernel desde la 2.6 hasta la 4.17, y pensé que lo había logrado pero luego me encontré con cosas inesperadas.

Para lograr la compatibilidad con todas las versiones de kernel, me fijé a través de la página
elixir.bootlin.com como iban cambiando las estructuras que mi rootkit usaba, eso junto con los errores que devuelve el compilador, me ayudaron a realizar ésta tarea. Parte de mi código es asi, por ejemplo:

Código (c) [Seleccionar] Expandir

struct proc_dir_entry {
unsigned int low_ino;
umode_t mode;
nlink_t nlink;
kuid_t uid;
kgid_t gid;
loff_t size;
const struct inode_operations *proc_iops;
const struct file_operations *proc_fops;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 10, 0) && \
    LINUX_VERSION_CODE < KERNEL_VERSION(3, 19, 0)
struct proc_dir_entry *next, *parent, *subdir;
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0) && \
    LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0)
struct proc_dir_entry *parent;
struct rb_root subdir;
    struct rb_node subdir_node;
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(4, 14, 0)
struct proc_dir_entry *parent;
struct rb_root_cached subdir;
    struct rb_node subdir_node;
#endif
void *data;
atomic_t count; /* use count */
atomic_t in_use; /* number of callers into module in progress; */
/* negative -> it's going away RSN */
struct completion *pde_unload_completion;
struct list_head pde_openers; /* who did ->open, but not ->release */
spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
u8 namelen;
char name[];
};

Como ves, algunos campos de la estructura fueron cambiando en las distintas versiones de kernel. Ésta estructura estaba definida desde el principio en el rootkit que analicé, ya que "no está publicada en las cabeceras públicas de los nuevos kernels". Además de esa estructura, las variables que utilizo, que hacen referencia a campos de distintas estructuras tambien tienen esos macros dependientes de versiones de kernels. Luego de analizar detalladamente versión por versión, logré utilizar los macros adecuados para que el rootkit compilara sin errores en todos los linux que probé, todos con distitnas versiones de kernels. Aquí dejo la lista:


Kali Linux (Rolling)   4.17.9   x86_64
Kali Linux (Rolling)   4.16.18   x86_64
Linux Mint 19 (Tara)   4.15.0-20-generic   i686
Kali Linux (Rolling)   4.14.0-kali3-amd64   x86_64
Ubuntu 16.04.4 LTS   4.13.0-36-generic   x86_64
Fedora 26                   4.11.8-300.fc26   x86_64
Ubuntu 17.04           4.10.0-19-generic   x86_64
Debian 9                   4.9.0-7-686   i686
Kali Linux (Rolling)   4.4.142   x86_64
Kali Linux (Rolling)   3.16.57   x86_64
Linux Mint 17           3.13.0-37-generic   x86_64
Wifislax                   3.12.36   i686
Fedora 19                   3.9.5-301.fc19   x86_64
Ubuntu 12.10           3.5.0-17-generic   i686
Lihuen 5.10               3.2.0-4-amd64   x86_64
Ubuntu 10.04.4 LTS   2.6.32-38-generic-pae   i686

El problema fue cuando lo probé sobre openSUSE.  openSUSE Leap 15.0 con el kernel 4.12.14, utiliza la estructura proc_dir_entry que se empezó a utilizar en los kernels 4.14. Es como que openSUSE en su release, modificó esa estructura, pero manteniendo el número de la versión de kernel anterior, entonces, dentro de mi código, pasa por los macros que no debería pasar y no termina funcionando, ya que las estructuras no coinciden. Si yo utilizo un ubuntu con el kernel 4.12.14 (exactamente la misma version), el rootkit funciona, pero no sobre openSUSE. Entonces si quiero que funcione universalmente, en los macros debería agregar algo como ésto:

Código (c) [Seleccionar] Expandir

struct proc_dir_entry {
unsigned int low_ino;
umode_t mode;
nlink_t nlink;
kuid_t uid;
kgid_t gid;
loff_t size;
const struct inode_operations *proc_iops;
const struct file_operations *proc_fops;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 10, 0) && \
    LINUX_VERSION_CODE < KERNEL_VERSION(3, 19, 0)
struct proc_dir_entry *next, *parent, *subdir;
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0) && \
    LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 0) && NO_ES_OPENSUSE
struct proc_dir_entry *parent;
struct rb_root subdir;
    struct rb_node subdir_node;
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(4, 14, 0) || ES_OPENSUSE
struct proc_dir_entry *parent;
struct rb_root_cached subdir;
    struct rb_node subdir_node;
#endif
void *data;
atomic_t count; /* use count */
atomic_t in_use; /* number of callers into module in progress; */
/* negative -> it's going away RSN */
struct completion *pde_unload_completion;
struct list_head pde_openers; /* who did ->open, but not ->release */
spinlock_t pde_unload_lock; /* proc_fops checks and pde_users bumps */
u8 namelen;
char name[];
};

Para identificar si el SO es openSUSE, pensé en una forma, pero utilizando código que se ejecuta luego de la etapa de preprocesamientos, ya que no encontré macros que pregunten por una distribución en específico.

La solución por el momento sería crear dos rootkits distintos, uno especialmente echo para funcionar con openSUSE, y el otro para funcionar con todas las demas distros, pero yo no quería llegar a ésto, ya que mi idea era la de tener un solo rootkit universal que funcionara sobre cualquier linux.

Es bastante complicado el problema, si no fui claro en alguna parte, por favor escribime.

Gracias nuevamente MAFUS, que vos siempre estás aca para ayudar.

Saludos!

Hola NEBIRE!  Gracias por tu tiempo! El problema que tengo es un poco complejo, pero voy a ver de que forma elimino la dependencia cíclica

Buenas que tal!!! No se si sea claro, pero voy a tratar de ser lo más genérico posible. Necesito obtener el resultado de una función para tomar una decisión antes de la etapa de preprocesamiento. Dependiendo de ese valor, tengo que tomar una decisión para definir un código u ótro código, pero el valor solo se como obtenerlo empleando una función, que se ejecuta luego del preprocesamiento... Quería saber como resolver ésta clase de problema.

Podrías hacer un bash script más o menos asi:

Código (bash) [Seleccionar] Expandir

#!/bin/bash
inicio_ns=`date +%s%N`
inicio=`date +%s`
sleep 5 # el comando
fin_ns=`date +%s%N`
fin=`date +%s`
let total_ns=$fin_ns-$inicio_ns
let total=$fin-$inicio
echo "ha tardado: -$total_ns- nanosegudos, -$total- segundos"

En vez de poner sleep 5, ponele los comandos q vas a usar, en tu caso el mfoc y el mfcuk para crackear tarjetas.

Saludos!

Me parece que la letra se elige al azar