Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Buscador

Entradas Mensuales

Suscripción

¿Quieres recibir las últimas novedades del blog en tu correo?

¡Suscríbete al feed!

Foro de elhacker.net - Noticias

elhacker.NET en Facebook

PostHeaderIcon [Ehn-Dev 2010] - Concurso de desarrollo de aplicaciones @ elhacker.net




Termino el periodo de entrega de aplicaciones del concurso de desarrollo de aplicaciones, para dar paso a las votaciones.
Lamentamos los que no pudieron participar porque se enteraron tarde u porque no tuvieron tiempo para trabajar en su proyecto, pero esperamos y alentamos a todos a que participen en la próxima edición del concurso!

De mi parte, y de parte de todo el staff de elhacker.net, quiero felicitar a todos los que han participado, ya que independientemente de quienes estén en los primeros puestos, todos son ganadores al participar.
Especiales felicitaciones a las personas que decidieron involucrarse en el concurso a pesar de tener poco tiempo en el mundo de la programación, y a los que no son nuevos pero han tenido complicaciones con sus horarios, y así y todo han sacado tiempo de donde no lo hay para poder estar. Doy fe que se han esforzado bastante para participar y eso vale mucho para todos nosotros.

Espero que se hayan divertido programando y que hayan aprendido algo nuevo en el camino.



Comienzan las votaciones!

Para emitir tu voto, entra aquí!


Lista de aplicaciones
:

PostHeaderIcon Envío de comandos vía VNC


Bueno, pues haciendo el PFC, me ha surgido un obstáculo a la hora de crear/inicializar las VMs, el problema es que para conectarte a una VM (más en concreto un LiveCD DVL) por ssh, hay que tener el servicio levantado, y para levantarlo hace falta conectarte...

Dándole vueltas, se me ocurrió que se podría usar el Servidor VNC que gestiona libvirt a la hora de crear VMs con virsh para simular la pulsación de teclas y así conseguir nuestro propósito, levantar el interfaz de red y el servicio ssh.

Leyendo las especificaciones del protocolo que usa VNC para acceder a las interfaces gráficas (RFB), se ve que es bastante sencillo, así que me he hecho un miniprograma en python que simula pulsaciones de teclado y las manda, y parece que funciona de lujo!

Su uso es sencillo, recibe 3 argumentos: servidor VNC, puerto, y archivo de órdenes
En el archivo de órdenes se le pueden especificar 3 tipos de orden, aquí un ejemplo:

send_string ifconfig eth0 192.168.2.50 netmask 255.255.255.0
sleep 4
send_key Return

En este caso se enviaría el ifconfig eth0..., se esperaría 4 segundos, y finalmente simularía la pulsación de Return

Os dejo el code (seguro que se puede mejorar, pero cumple su propósito):

import socket
import time
import struct
import sys

class RFBClient:
 # usar /usr/include/X11/keysymdef.h
 keycodes = {
  'BackSpace' : 0xff08,
  'Tab' :       0xff09,
  'Return' :    0xff0d,
  'Escape' :    0xff1b,
  'Insert' :    0xff63,
  'Delete' :    0xffff,
  'Home' :      0xff50,
  'End' :       0xff57,
  'PageUp' :    0xff55,
  'PageDown' :  0xff56,
  'Left' :      0xff51,
  'Up' :        0xff52,
  'Right' :     0xff53,
  'Down' :      0xff54,
  'F1' :        0xffbe,
  'F2' :        0xffbf,
  'F3' :        0xffc0,
  'F4' :        0xffc1,
  'F5' :        0xffc2,
  'F6' :        0xffc3,
  'F7' :        0xffc4,
  'F8' :        0xffc5,
  'F9' :        0xffc6,
  'F10' :       0xffc7,
  'F11' :       0xffc8,
  'F12' :       0xffc9,
  'F13' :       0xFFCA,
  'F14' :       0xFFCB,
  'F15' :       0xFFCC,
  'F16' :       0xFFCD,
  'F17' :       0xFFCE,
  'F18' :       0xFFCF,
  'F19' :       0xFFD0,
  'F20' :       0xFFD1,
  'ShiftLeft' : 0xffe1,
  'ShiftRight' : 0xffe2,
  'ControlLeft' : 0xffe3,
  'ControlRight' : 0xffe4,
  'MetaLeft' :  0xffe7,
  'MetaRight' : 0xffe8,
  'AltLeft' :   0xffe9,
  'AltRight' :  0xffea,

  'Scroll_Lock' : 0xFF14,
  'Sys_Req' :   0xFF15,
  'Num_Lock' :  0xFF7F,
  'Caps_Lock' : 0xFFE5,
  'Pause' :     0xFF13,
  'Super_L' :   0xFFEB,
  'Super_R' :   0xFFEC,
  'Hyper_L' :   0xFFED,
  'Hyper_R' :   0xFFEE,

  'KP_0' :      0xFFB0,
  'KP_1' :      0xFFB1,
  'KP_2' :      0xFFB2,
  'KP_3' :      0xFFB3,
  'KP_4' :      0xFFB4,
  'KP_5' :      0xFFB5,
  'KP_6' :      0xFFB6,
  'KP_7' :      0xFFB7,
  'KP_8' :      0xFFB8,
  'KP_9' :      0xFFB9,
  'KP_Enter' :  0xFF8D,
 }

 def __init__(self, address):
  # conectamos
  self.s = s = socket.socket()
  s.connect(address)

  # negociamos version
  version = s.recv(12)
  print version.strip()
  s.sendall(version)

  # negociamos seguridad
  security_types = ord(s.recv(1))
  for i in range(security_types):
   s.recv(1)

  s.sendall(chr(1))
  struct.unpack('!I', s.recv(4))

  # iniciamos cliente (compartido)
  s.sendall(chr(1))

 def __send_keycode(self, keycode):
  self.s.sendall(struct.pack("!BBxxI", 4, 1, keycode))
  time.sleep(0.05)
  self.s.sendall(struct.pack("!BBxxI", 4, 0, keycode))

 def send_string(self, string):
  for c in string:
   self.__send_keycode(ord(c))

 def send_key(self, key):
  self.__send_keycode(self.keycodes[key])


if(len(sys.argv) != 4):
 print "\n\t[+] Uso: " + sys.argv[0] + " servidor_VNC puerto archivo_ordenes\n"
else:
 #abrimos archivo de ordenes
 fd = open(sys.argv[3], "r")
 
 #conectamos con los datos suministrados
 client = RFBClient((sys.argv[1], int(sys.argv[2])))

 #leemos linea por linea y parseamos el tipo de orden
 fileList = fd.readlines()
 for fileLine in fileList:
  parsed=fileLine.partition(' ')
  print "\nComando: " + parsed[0] + " argumento: " + parsed[2]
  if(parsed[0]=="send_string"):
   client.send_string(parsed[2])
  elif(parsed[0]=="send_key"):
   client.send_key(parsed[2].replace('\n',''));
  elif(parsed[0]=="sleep"):
   time.sleep(int(parsed[2]))
  else:
   print "\n\t[!] Comando invalido\n"  
  
 #cerramos el descriptor
 fd.close()

PostHeaderIcon Rootkits (III)



Bueno, pues después de daros la plasta con la parte “teórica”, vamos a ver algo más práctico, para empezar analizaremos el modus-operandi de un rootkit que trabaja en espacio de usuario. Ya se
explicó someramente como trabajan estos, y para ejemplificarlo que mejor que ponernos manos a laobra a despiezar un rootkit de este tipo, en este caso “shv6”.

Para ello nos vamos a servir de una VM con un Ubuntu Server instalado, con el únic oañadido de que contará con tripwire, programa que sirve para comprobar la integridad de los archivos instalados en nuestro sistema y que nos ayudará a ver mejor los cambios que se llevan acabo en el sistema por este tipo de rootkits.



PostHeaderIcon Canal IRC de elhacker.net


El canal IRC de elhacker.net ha sido cerrado!




Debido a la baja actividad del canal y a problemas tecnicos decidimos cerrar el canal.

















































































Tras casi 8 meses de desarrollo, el día de hoy hemos decidido hacer público el canal IRC de elhacker.net, y en este post me gustaría explicar lo que hay detrás de este.

Hemos tardado tanto, debido a que hemos decidido desarrollar un bot de IRC desde zero, que al mismo tiempo, usará la misma base de datos de otros proyectos. Y debido a que los participantes de este proyecto trabajan o estudian, solo había un par de horas al mes a dedicarle al proyecto.

En primera, explicaré cuales fueron los motivos por los cuales, aun cuando los usuarios lo habian pedido tanto, no se había hecho un canal IRC oficial hasta hoy, cuales fueron nuestros retos, y las soluciones que ideamos para los problemas que encontramos.

Antes que nada, habría que explicar que en el pasado, ya hubo un canal IRC en elhacker.net, pero fue cerrado hace ya varios años, debido a que el canal parecía ser usado para hablar temas que incluso estaban baneados en el foro, y fuera de cualquier cosa, dañaba la reputación que tenia nuestra comunidad. Otro motivo, era la moderación del mismo, cuando personas que no tenían porque ser moderadores, tenían privilegios sobre el canal, y abusaban de tal poder, sin tener a quien rendir cuentas.

Fue así, como tras el fracaso que tuvo ese canal, se decidió no volver a hacer uno.. Sin embargo, tras el entusiasmo de nuestros usuarios, decidimos idear un modelo en el cual se evitaran esos problemas, al mudar su funcionamiento a algo mas transparente.

Los problemas que hemos querido solucionar han sido:

  1. Evitar abusos de poder
  2. Mejorar la eficacia de los bans
  3. Controlar mejor el contenido

Así también, hemos querido utilizar el canal IRC para cosas útiles, en las que podríamos organizar eventos, charlas y entrevistas.

Por lo que decidimos que, a pena de sacrificar tráfico en el canal, se usaría un modelo donde nuestros usuarios habituales del foro, pudieran charlar, y convivir, al mismo tiempo que crearíamos un espacio para organizar eventos simultáneos alrededor del mundo, sin afectar la integridad del canal.

Nuestras metas secundarias para el canal son:

  1. Integrarlo con nuestros servicios actuales.
  2. Habilitar su uso de forma educativa.

Dicho lo cual, pasaremos a explicar los detalles de la implementación.

Para empezar, el canal esta en una red pública, en un servidor público, lo que hace que este trabaje bajo la supervición y mantenimiento de otro grupo de personas (en nuestro caso Freenode). Hemos decidido Freenode, debido a que cuentan con una red grande de servidores, distribuidos alrededor del mundo, proveen una serie de servicios que requerimos, y están comprometidos a apoyar a grupos y comunidades sin ánimo de lucro como lo es elhacker.net.

El canal sera moderado por nuestro STAFF de forma democrática, es decir, a excepción de los coAdministradores, los colaboradores no podrán banear a un usuario, sino que necesitaran que otros dos colaboradores apoyen el ban, o ademas de el, un moderador global. El objetivo, es que una riña entre un usuario STAFF y un no STAFF no conlleve a un ban del canal.

Otro punto a destacar de los bans, es que un ban no te saca del canal, sino que simplemente te quita la voz, lo que te permite permanecer en el, pero sin la posibilidad de decir nada. Aunque puedes charlar con otros usuarios de forma privada, así como pedir que se quite un ban si el usuario considera fue injusto.

Algo que se debe tomar en cuenta, es que un ban, seria muy poco útil, si permitimos que cualquier usuario pueda simplemente registrar un usuario nuevo y entrar de nuevo al canal, por lo que hemos decidido solo permitir el acceso al canal a los usuarios que tengan cierta antiguedad y mensajes en el foro. Hemos intentado hacer esto de la forma mas justa posible, al simplemente intentar mantener solo a nuestros usuarios habituales del foro.

De esta forma, intentamos que no haya usuarios que se registran en el foro para entrar al canal IRC, sino que, entran al canal IRC por ser usuarios del foro. Una pequeña pero importante diferencia. Ya que el canal IRC es un servicio para nuestros usuarios, y no para nuestros visitantes.

Los visitantes, sin embargo, tendrán acceso libre a leer el contenido del canal de forma perpetua, ya que se guardara y publicara un log del canal. Así creando un repositorio público de todos los mensajes. De esta forma, proveemos un archivo para demostrar de forma transparente lo que se diga o haga en el canal, así como dar la oportunidad a todos de leer de lo que se trata en el mismo.

Otro punto importante en el canal, es la integración con los otros servicios. Con el objetivo de compartir una identidad entre distintos servicios, se ha creado un sistema donde debes asociar una cuenta de elhacker.net con un nickname de IRC. Esto se hace usando nuestro bot llamado "bianc4" (bianca). Bianca se encarga de loguear todo lo que se dice en el canal, asi como dar y quitar privilegios.

Detalles sobre la implementación de bianc4, que será opensource en el futuro, así como la web del archivo público del log del IRC, se explicarán en otro blogpost en otra ocasión. Si deseas entrar YA! al canal IRC, te recomendamos vayas a: http://foro.elhacker.net/irc.html

Si no cuentas con privilegios para entrar al canal, mándanos un correo a irc@elhacker.net =)

Si deseas ver el log público, visita la web de bianc4 en http://bot.elhacker.net/ este contiene un log en vivo, donde puedes ver lo que platica en el canal en tiempo real.

Para una guía completa de como entrar al canal visita http://r.i.elhacker.net/ircDoc

Para poder registrarte en el canal, necesitas registrar tu nickname en Freenode primero, hemos recibido ayuda de nuestros usuarios para crear video tutoriales!





Esperamos entren! Mucha suerte :)

Saludos!!

PostHeaderIcon Saltando un firewall de una manera no común.


Ya hace tiempo había saltado el firewall escolar, mediante la obtención de algunas contraseñas a través de ARPoison. En esta ocasión les voy a contar sobre como logre hacerlo de una manera totalmente diferente.

La red escolar es mediana, red plana, tiene varios segmentos de red local distribuidos entre los distintos edificios. Ademas de tener una Red Inalambrica en modo Infraestructura un poco mal administrada con distintos ESSID distribuidos por toda la institución.

Todo el trafico de la institución pasa a través de un Firewall hasta el momento era el único que dispositivo final que "conocía", el firewall es un servidor con Fedora instalado, tiene ssh para la administración supongo, ademas de sistema web proxy basado en squid.

Pues este semestre me di cuenta a través de gmail que la IP de salida de la escuela había cambiado (generalmente ya no me interesaba hackear nuevamente la red de la escuela), al ver el rango de la IP publica sospeche que se habían cambiado de proveedor de internet.

Al momento de hacer la consulta dns confirme mis sospechas, con esto igualmente arme la topologia completa de la escuela agregando solo un Router/Modem 2wire como salida a internet, este dispositivo esta conectado directamente al Servidor squid y firewall

Después de un scan mediante nmap a 1 puerto confirme que el dispositivo era vulnerable a DoS externamente y a CSRF internamente.

El día siguiente Jueves desde la escuela trate de buscar el módem mediante traceroute, sin embargo no apareció imagino que habrán bloqueado algo en el firewall para que no aparezca. Entonces se me ocurrió realizar ping a google de manera continua por ejemplo y después de hacer DoS al modem desde la IP externa, el ping dejo de responderme, después unos segundos recivo un Destination Unreachable :D

Wow que bien "Reply from 192.168.123.1: Destination Unreachable"

Después de comparar el TTL devuelto y ver el punto en el cual fallo el traceroute supuse que dicha IP pertenecía al modem :D.

Me conecte al modem y no me sorprendió ver lo que me mostró, era tal y cual lo esperaba.

Rápidamente comprobé si tenia password :( si lo tenia, pero nada difícil fue agregar mi propio password, después de esto veo la configuración actual de la dirección IP y la mascara de red actual, activo el wireless con un nombre de ESSID diferente, ademas de ocultarlo y agregar una clave WPA-PSK.

Configuro el Wireless de mi laptop para conectarse con la IP Manual y empiezo a buscar el momento en el que me de la conexión. Después de recorrer 3 edificios diferentes con la laptop en la mano al fin encuentro la conexión wireless.

Realizar todo esto en aproximadamente 10 minutos, me alegro el dia.

Al día siguiente viernes, llego tratando de conectar con las mismas configuraciones y nada, me dije "vaya, poco me a durado el gusto", después de reencontrar el modem y ver que puedo entrar sin problema y volver a hacer lo hice el día anterior, nuevamente dije para mi "haha cambiar la IP no detiene a nadie", ahi me tope con la sorpresa de que habían bloqueado el acceso al modem mediante http, sin embargo ese modem también tiene acceso desde la red local mediante https y este ultimo no lo bloquearon.

Anteriormente le he avisado al administrador de la red de algunas fallas en los servidores y si he recibido respuesta diciendo: "gracias por tus observaciones y recomendaciones, en un momento le doy una checadita". Y después de varias semanas nada de nada, asi que mientras no repare los anteriores no le voy a avisar nuevamente.

El ultimo día de clases antes de salir de vacaciones, me entere que regresaron el modem al proveedor (esto debido a que el modem se "había descompuesto"), verifico la conexión a internet y me doy cuenta que volvíamos  a tener salida mediante el proveedor de internet anterior, ahi ya no podía hacer mucho.

Regresando de Vacaciones 2 semanas después vuelvo a dar una revisada a la topologia de la escuela y me encuentro que otra vez salíamos mediante telmex, sin embargo al tratar de entrar a la configuración del modem, me doy cuenta que este pide contraseña mediante "basic access authentication" Al ver en el mensaje la palabra clave "EchoLife", recordé que es uno de los nuevos modems que ofrece el proveedor de servicios de Internet. Buscando en Internet después de unos segundos no me sorprendió que también fuese vulnerable a un DoS, sin embargo esta vez era diferente, antes aparte de poder realizar un DoS, también podía resetear el password, sin embargo esta vez no. Resulta que el password para el usuario es la clave WEP, con la que viene el modem por defecto.

Procedi a realizar un reset al modem, después de eso, me voy al edificio donde anteriormente se encontraba la señal wifi del modem anterior, y después de reiniciar con linux y activar el airodump me doy cuenta que si esta la red wifi, anteriormente en ese edificio no estaba esa red wifi. Después de 5 minutos de estar capturando el trafico/reinyectando ARP/Crackeando lo capturado, doy con la clave.

Me conecto via wireless y entro a la configuración, vuelvo asignarle la IP que tenia el módem antes de ser reseteado a los valores de fabrica, oculto el wireless y otra vez sonrió para mi por un buen trabajo bien ejecutado.

Al día siguiente en uno de mis tiempos libres trato de conectarme a dicha red y WTF??, todo lo que hice desapareció, trate de resetear el modem otra vez, y parece que ahora si aprendieron a configurar el firewall de manera correcta y me bloquearon el acceso al modem, (En realidad solo bloquearon las URL para resetear el modem) sin embargo todavía puedes tratar de logearte al modem, aquí intente conectarme con el usuario Administrador del modem y la clave WEP que había conseguido al día anterior, sin embargo no funciono.

Puedo intentar un force-brute, pero la verdad no vale la pena para mi perder el  tiempo en eso.
Cabe mencionar que ese modem no tiene acceso mediante https.

En fin me divertí mucho esos días.

Si tu red se encuentra en las misma situación o con una configuración parecida estas son las soluciones:

-Bloquear el trafico ICMP de el modem a la red Interna, esto se hace desde el firewall, y sirve para que no se encontrado mediante traceroute
-Configurar el modem para cerrar el puerto administrativo y evitar un DoS
-Configurar el web proxy para que no realice peticiones al modem.

- Anon

PostHeaderIcon File Carving


A menudo nos encontramos con noticias sobre fugas de información en empresas tanto de carácter público como privado, la pérdida de un USB, un disco duro "viejo" tirado en la basura como si se tratase de un cleanex, documentos con datos que no se ven pero que están ahí... la mayoría de las veces la información se encuentra a simple vista en los dispositivos, pero que sucede si dicha información ha sido borrada, o mejor aun, el dispositivo ha sido formateado?.
Incluso después del borrado/formateo/reparticionado podemos tener acceso a esta información, existen varias técnicas, tanto hardware como software, pero hoy nos vamos a centrar en una de ellas: File Carving

El File Carving es el proceso de extracción de una serie de datos que se encuentran dentro de otro conjunto mayor de datos. Las técnicas de Data Carving son usadas frecuentemente en Análisis Forense cuando nos encontramos con porciones de datos pertenecientes al Sistema de Archivos que a primera vista no están usados pero que pueden tener sorpresas.


PostHeaderIcon ¿Qubes, el OS más seguro?


Han pasado apenas unos días desde la salida de un nuevo OS basado en Linux(aun en versión Alpha), Qubes, uno más podríamos pensar... quizás si, pero quizás no.

Este OS está enfocado principalmente a la Seguridad (hasta aquí nada nuevo), y para conseguir esto, uno de los pilares básicos sobre el que se construye es Xen (Software de virtualización muy conocido en ámbitos Linux),  con el que se pretende construir "bloques" en los que los usuarios pueden organizar distintos grupos de aplicaciones. Estas VM's son gestionadas por el hypervisor de Xen (ligeramente modificado en este proyecto, apenas 2500 líneas de código se han añadido), manteniendo a las aplicaciones usadas para la oficina, por ejemplo, separadas de las aplicaciones que se usan en casa.


PostHeaderIcon Abril Negro 2010




Abril Negro 2010 da comienzo.

Como cada año, en este mes se monta un "mini-concurso" para ver quien es el que mejor se maneja en cuanto a programación de malware. Creo que no hacen falta presentaciones, ya que más o menos todos sabéis de que se trata, aqui van las bases y premios del concurso.



PostHeaderIcon Virtualización + Tarjétas inalámbricas en modo bridge


Estaba yo liado con mi PFC y más en concreto con temás de Virtualización (Xen y KVM), cuando me encontré con un "inconveniente", al trabajar con las VM's en modo bridge con una tarjeta ethernet no hay problemas, pero... que pasa si queremos hacer esto con una tarjeta inalámbrica?

Realmente podemos pasar de líos y hacerlo con la ethernet, pero si tienes un portatil y estás conectado por wifi al router de tu casa, da bastante pereza tener que moverte y "enchufarte" al router.

PostHeaderIcon Rootkits (II)


En esta segunda parte del artículo de Rootkits, vamos a hablar sobre los distintos tipos de Rootkits que existen en Linux. Básicamente, podemos separarlos en 2 tipos:

  • KernelSpace Rootkits

Estos Rootkits, se cargan como un modulo de Kernel. Lo que les permite modificar estructuras del Kernel, hookear llamadas de sistema al más bajo nivel, etc.

  • UserSpace Rootkits

Estos rootkits trabajan el el espacio del usuario. Sus privilegios son menores al de los Rootkits de Kernel. Para poder trabajar, tienen que modificar archivos y/o librerias para poder trabajar correctamente. Son más fáciles de detectar que los Rootkits de Kernel.
Las principales tareas de un Rootkits son las de Ocultar procesos, ocultar archivos, ocultar conexiones a Internet, etc. Para ello, y dependiendo del tipo de Rootkit, hacen servir distintos métodos para lograr su cometido.


PostHeaderIcon Rootkits (I)


Con este primer post, vamos a introducir una serie de artículos en los que trataremos en profundidad los rootkits, desde un repaso histórico, pasando pos los fundamentos, los distintos tipos, hasta un análisis profundo de una serie de rootkits.

Los posts corren a cargo de Hendrix y de un servidor, esperemos que sean de vuestro agrado, y sin más dilación...

Muchos usuarios habrán oído hablar de los rootkits... Tienen ya una dilatada historia, aunque en sus orígenes provienen del entorno de los Sistemas Operativos Unix y sus derivados.

Originalmente los rootkits fueron diseñados para realizar funciones en beneficio del usuario, aunque posteriormente, y de ahí su actual “popularidad”, pasaron a ser usados por los hackers para diversos propósitos.

Alrededor del 2004 empezaron a aparecer los primeros ejemplares para los Sistemas Operativos Windows, creciendo exponencialmente el número de estos. Fue en este momento cuando el término “rootkit” saltó a la palestra y empezaron a refinarse enormemente hasta llegar a los ejemplares que tenemos hoy en día.

En este artículo vamos a tratar de definir un poco más técnicamente que es un rootkit, como actúa, y porque puede ser tan potencialmente peligroso.


PostHeaderIcon Detectando hooks en procesos desde un módulo de Kernel


En el presente artículo se va a tratar la detección de API Hooking en procesos mediante un módulo de Kernel. Un breve índice sobre los puntos que voy a tratar:

  1. Diferencia entre manejo de direcciones en modo Kernel y modo Usuario
  2. Trabajando sobre el proceso en modo Kernel
  3. Leyendo memoria y código final


Diferencia entre manejo de direcciones en modo Kernel y modo Usuario:
-->
Como ya saben, no es lo mismo trabajar con memorias en un módulo de Kernel que en un proceso corriendo en modo usuario. La principal diferencia es que un módulo Kernel trabaja con direcciones físicas y los procesos con memoria virtual. Vamos a ver mas detalladamente que es cada cosa.


PostHeaderIcon ffmpeg puede grabar X de cualquier usuario


El otro día estaba platicando con Kamsky, hablando de proyectos pendientes y cosas similares. Después de un rato le digo "Una pizza si me dices que canción estoy escuchando" ya previamente le había hecho un usuario para que se conecte mediante ssh a mi equipo, y pues resulta él entró a ver algunas cosas testeó algunos archivos y demás lo que haría cualquier persona tratando de obtener privilegios que no le corresponden, bueno resulta que no logró nada en ese momento ya que el estaba ocupado en otras cosas.



PostHeaderIcon Jaulas Chroot


- Introducción

En esta entrada vamos a hablar un poco de las bondades y los defectos que tienen las "jaulas chroot" usadas en diferentes sistemas Unix y derivados, centrándonos en este caso en Linux. Antes de meternos en el fregado, vamos a ver un poco las necesidades que nos llevan a usar este u otros métodos que deberían de mostrarse eficaces en cuanto a la securización de nuestros sistemas.

Sin duda, cuando en un Servidor se instala algún Servicio, ya sea Http, Ftp, Smtp, etc., es obligatorio invertir nuestro esfuerzo en tener un sistema lo más funcional y flexible posible, pero a la vez seguro (necesidades que suelen chocar). Hay muchas medidas, como el uso de IDS, los mecanismos de securización propios que nos brinda el servicio, firewalls, etc... Y es aquí donde entran en juego las "jaulas chroot", las cuales serán definidas más tarde apropiadamente, que son una especia de caja, donde metemos un "mini-sistema" sobre el que correrá nuestro Servicio.

¿Qué nos brinda esto?, bueno pues varias cosas, en primer lugar tenemos nuestro Servicio, que es un posible foco de entrada de "personal ajeno a la organización", en una especie de bunquer aislado (luego veremos que no es tan bunquer) que no tiene acceso al resto del sistema, ya que para ese Servicio y para todo lo que haya dentro de la jaula ESE ES EL SISTEMA. Pero... y si alguien consigue acceder mediante alguna vulnerabilidad del Servicio a nuestro Server y además con privilegios de root?, bueno, en principio no debería de preocuparnos la integridad de nuestro Sistema en conjunto (más allá de ese Servicio en específico), ya que el atacante no va a ver más allá de ese "mini-sistema".

Tiene buena pinta, no?, pues a continuación vamos a entrar un poco más en detalle sobre el tema, viendo que efectivamente las "jaulas chroot" son una buena medida de Seguridad si se implementan adecuadamente, pero que no es la panacea y que los chicos malos pueden traspasar los muros de nuestro bunquer.


PostHeaderIcon Bienvenidos al blog de elhacker.net


Le damos una cordial bienvenida a todos nuestros visitantes al blog de seguridad informática elhacker.net, un lugar donde podrás encontrar todo lo que necesites para ampliar tus conocimientos, ya sea para apoyar tu trabajo, tus estudios o simplemente a modo hobby.

De antemano os damos las gracias, ya que sois vosotros los que haceis de elhacker.net una de las comunidades de habla hispana más grande relacionada con la seguridad informática.

Nuestra filosofía es la de apoyar, enseñar y educar a todo aquel que esté interesado en este apasionante mundo, así que esperamos que el blog llegue a ser un punto de encuentro para toda la gente con curiosidad y ganas de aprender.

Bienvenidos!

- El staff de elhacker.net -