Mensajes

Hola!!

Gracias por contestar. He probado contra 3 equipos distintos (los 3 Windows con su antivirus instalado) y no actuliza sus tablas arp. Incluso, en 2 de ellos borré las entradas de la tabla arp y aún así se actuliza con la MAC que inyecto yo.

Salu2

Podria ser que el equipo victima tenga antivirus o firewall?

Hola!!!

Sí, estoy usando Nemesis con  el Wireshark. Y sí, tambien veo las tramas ARP indicando la mac falsa:

Código [Seleccionar] Expandir


192.168.1.1 is at 00:f1:f2:f3:f4:f5″


Por otro lado, ya comprobé que las entradas en la tabla arp era dinámicas.... Me parece raro que no funciona ya que con ettercap tambien he tenido problemas y no actualiza... La verdad que llevo una semana leyendo sobre esto y aún no he visto a nadie que le pase como a mi.

Gracias por contestar y saludos

Hola!
Estaba probando Nemesis en la LAN de mi casa y veo que no me funciona. En teoria es algo sencillo porque tienes que lanzar un comando pero al hacer "arp -a" en las victimas, sus tablas no se actualizan a la mac que yo pongo:

Código [Seleccionar] Expandir

nemesis arp -v -r -d eth0 -H 00:11:22:33:44:55 -S 192.168.1.2 -D 192.168.1.21

Al hacer arp -a en el equipo 192.168.1.21, tiene el valor bueno. ¿Tengo quen habilitar alguna cosas más para que se cambie dicho valor?
Tambien he usado ettercap con el mismo equipo, y tampoco he conseguido hacer fluir el trafico desde la victima pasando por mi tarjeta de red hasta el router

Gracias!

Hola!

Muchas veces para hacer funcionar un exploit hay que "pegarse" con él. Revisa todo lo que ha comentado Ivan en este hilo para entender lo que debe hacer... A priori tu kernel es vulnerable pero puede haber varios factores que puedan hacer que no lo sea...

Por otro lado, Ivan, compile de nuevo el kernel 2.6.37 para habilitar el dispositivo /proc/kmem. He intentado usar el código que me paseste, pero me da error de IO:

Código [Seleccionar] Expandir


./a.out 0xbffff65e
/dev/kmem opened.
Error at line 81, file vuelca_memoria.c (5) [Input/output error]


He intentado investigar por la red, y no he visto nada claro sobre el problema...
Ultimamente estoy super liado con el trabajo, si puedo te contesto tan rapido como pueda.

Salu2

Hola!

Yo hace tiempo usaba en Windows el SSS (Shadow Security Scanner). Mira a ver si te sirve....

Salu2

Hola!

Yo tampoco tengo el dispositivo /dev/kmem.... la verdad que ver la memoria real no me sirve de mucho.....
Tengo una duda existencial (que desde luego no iria en este foro), cuando con el "gdb" ves todas las direcciones que salen, tanto la de las instrucciones como las de la pila, esas direcciones son virtuales ¿verdad? y siendo esto cierto, desde 0x00000000 hasta 0xFFFFFFFF ¿sería todo el espacio de direcciones virtuales del proceso?
Volviendo al tema, voy a seguir a ver si encuentro otra manera de hacer dump de la memoria virtual.

Salu2

Otra cosa, como no he visto en ningún lado que la version del kernel 2.6.37 no sea vulnerable, voy a intentar a ver si consigo hacer andar el exploit...

Si queres sacar exactamente el offset correcto no se me ocurre otra que dumpear la memoria virtual del kernel.

¿Cómo podría hacer esto que dices para revisar la memoria y localizar la varible "char name" en tiempo de ejecución?

Gracias!

La idea es buscar cuantos bytes tenes hasta el campo char name[32] y eso se le mandas como offset.

Mmmm entonces si no he entendido mal, esto es lo que se supone que hace:

1. Se le pasa a la función socket el protocolo -70
2. Esto hace que proto_tab[protocol] apunte a direcciones más baja:

Código [Seleccionar] Expandir


0xf8??????     proto {
                               .....
                               .....
                 
                                char name[32];  <-- proto_tab[-70] apuntaria aquí
                              }

0xf8??????     proto_tab{

                                   }


3. La varible "name" tiene valor PHONET, que transformado a Hex y cogiendo 4 bytes (PHON) es 0x4e4f4850

4. En esta dirección en memoria es donde tenemos nuestras estructuras falsas creadas

5. Al hacer la llamada ioctl hacemos que se ejecute el "getroot" de nuestra estructura

¿El exploit funciona como digo?

Hola!!!

Lo acabo de probar con otra version del kernel, la 2.6.35 y sí que me ha funcionado..... En la 2.6.37 me imagino que estará parcheado. De todos modos, no sé cómo narices funciona este exploit aún, y es algo que me fastidia...

Salu2

Hola Ivanchuck!

He probado el código que me has pasado y tambien me ha devuelto 0x90...
No he comentado que mi version del kernel es la 2.6.37.
Te dejo mi estructura proto a ver si tiene algo de pecualiar

Código [Seleccionar] Expandir

struct proto {
void (*close)(struct sock *sk,
long timeout);
int (*connect)(struct sock *sk,
        struct sockaddr *uaddr,
int addr_len);
int (*disconnect)(struct sock *sk, int flags);

struct sock * (*accept) (struct sock *sk, int flags, int *err);

int (*ioctl)(struct sock *sk, int cmd,
unsigned long arg);
int (*init)(struct sock *sk);
void (*destroy)(struct sock *sk);
void (*shutdown)(struct sock *sk, int how);
int (*setsockopt)(struct sock *sk, int level,
int optname, char __user *optval,
unsigned int optlen);
int (*getsockopt)(struct sock *sk, int level,
int optname, char __user *optval,
int __user *option); 
#ifdef CONFIG_COMPAT
int (*compat_setsockopt)(struct sock *sk,
int level,
int optname, char __user *optval,
unsigned int optlen);
int (*compat_getsockopt)(struct sock *sk,
int level,
int optname, char __user *optval,
int __user *option);
#endif
int (*sendmsg)(struct kiocb *iocb, struct sock *sk,
   struct msghdr *msg, size_t len);
int (*recvmsg)(struct kiocb *iocb, struct sock *sk,
   struct msghdr *msg,
size_t len, int noblock, int flags,
int *addr_len);
int (*sendpage)(struct sock *sk, struct page *page,
int offset, size_t size, int flags);
int (*bind)(struct sock *sk,
struct sockaddr *uaddr, int addr_len);

int (*backlog_rcv) (struct sock *sk,
struct sk_buff *skb);

/* Keeping track of sk's, looking them up, and port selection methods. */
void (*hash)(struct sock *sk);
void (*unhash)(struct sock *sk);
void (*rehash)(struct sock *sk);
int (*get_port)(struct sock *sk, unsigned short snum);
void (*clear_sk)(struct sock *sk, int size);

/* Keeping track of sockets in use */
#ifdef CONFIG_PROC_FS
unsigned int inuse_idx;
#endif

/* Memory pressure */
void (*enter_memory_pressure)(struct sock *sk);
atomic_long_t *memory_allocated; /* Current allocated memory. */
struct percpu_counter *sockets_allocated; /* Current number of sockets. */
/*
* Pressure flag: try to collapse.
* Technical note: it is used by multiple contexts non atomically.
* All the __sk_mem_schedule() is of this nature: accounting
* is strict, actions are advisory and have some latency.
*/
int *memory_pressure;
long *sysctl_mem;
int *sysctl_wmem;
int *sysctl_rmem;
int max_header;
bool no_autobind;

struct kmem_cache *slab;
unsigned int obj_size;
int slab_flags;

struct percpu_counter *orphan_count;

struct request_sock_ops *rsk_prot;
struct timewait_sock_ops *twsk_prot;

union {
struct inet_hashinfo *hashinfo;
struct udp_table *udp_table;
struct raw_hashinfo *raw_hash;
} h;

struct module *owner;

char name[32];

struct list_head node;
#ifdef SOCK_REFCNT_DEBUG
atomic_t socks;
#endif
};

Aún así, no entiendo cómo el exploit apunta a esta estructura. ¿A qué parte de ella apunta,a toda o sólo a una parte?