Muy bueno!
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.
#302
Softwares e ISOs / DriverPack Solution Professional 13 R355 x86/x64/MULTI/2013
Mayo 07, 2013, 12:42:08 PM
DriverPack Solución Profesional 13 R355 - una versión actualizada del programa de gran alcance que puede instalar automáticamente los controladores en el equipo. Esta versión cuenta con muchas nuevas características y optimizado para todas las plataformas (x86-x64), y también es compatible con el nuevo sistema operativo Windows 8.
Ventajas DriverPack Solución:
• Instalación automática del controlador: instalar todos los controladores en prácticamente cualquier ordenador por sólo unos 5 minutos
• Ahorro de tiempo: no hay necesidad de perder tiempo buscando controladores, instale los controladores en un par de clics
• Cualquier controlador para cualquier ordenador todos los drivers en un solo DVD-ROM! Simplificar la descarga de nuevos drivers desde Internet
• Posibilidad de actualizar los controladores: actualizar el controlador existente con las versiones más recientes
• Windows XP / Vista / 7/8 (x86-x64): soporta todos los sistemas operativos modernos! Como las versiones de 32 bits y 64 bits!
• Facilidad de uso: Interfaz sencilla e intuitiva
• La capacidad de diseño individual: es de código abierto
Programa se utiliza:
• Los usuarios de equipos domésticos
• Los administradores del sistema
• Asistente de Informática
• Servicio de reparación de computadoras
• otras personas que a menudo se enfrentan con la instalación / reinstalación de Windows
Ventajas de la utilización de:
• La interfaz es amigable e intuitiva
• Los controladores inteligentes de clasificación de tecnología
• Múltiples opciones de instalación (para el profesional para el usuario novato)
• plurilingüismo (no requiere conocimientos lingüísticos y el esfuerzo): Inglés, ruso, ucraniano, alemán, francés, italiano, español, turco, azerí, holandés, lituano
• Verifique la disponibilidad de nuevas versiones de software
Solución DriverPack Funciones 13 R317:
• Búsqueda eficiente y rápido para los conductores
• Instalación de los controladores en prácticamente cualquier ordenador, a sólo unos minutos
• un "downgrade" de Windows Vista a Windows XP (incluso si el fabricante no ha publicado en su web el controlador en Windows XP)
• buscar y descargar el controlador que falta de Internet, según un conjunto de parámetros del controlador
• actualizar rápidamente un conjunto existente de los controladores instalados a versiones más recientes
• Colaborar en la creación y el uso de su propio controlador de base de datos
El programa es adecuado para todos los modelos de computadoras. Eso incluye drivers para portátiles:
Asus, Acer, Sony, Samsung, HP, Lenovo, Toshiba, Fujitsu-Siemens, Dell, eMachines, MSI ...
Se permite descargar controladores libres para:
Placa base, tarjeta de sonido (audio), tarjeta de vídeo, tarjeta de red, Wi-Fi, un chipset, controlador, Bluetooth (Bluetooth), Modem, camara web, lector de tarjetas, CPU, dispositivos de entrada, monitor, impresora, escáner, USB, Otros ...
Controladores:
DP_Biometric_13044.7z
DP_Bluetooth_13044.7z
DP_CardReader_13044.7z
DP_Chipset_13045.7z
DP_LAN_13044.7z
DP_MassStorage_13045.7z
DP_Misc_13044.7z
DP_Modem_13035.7z
DP_Monitor_13045.7z
DP_Notebook_13044.7z
DP_Printer_13044.7z
DP_Sound_ADI_13035.7z
DP_Sound_CMedia_13042.7z
DP_Sound_Conexant_13045.7z
DP_Sound_Creative_13044.7z
DP_Sound_IDT_13044.7z
DP_Sound_Others_13044.7z
DP_Sound_VIA_13035.7z
DP_Sounds_HDMI_13043.7z
DP_Sounds_Realtek_13044.7z
DP_Telephone_13044.7z
DP_Touchpad_Alps_13045.7z
DP_Touchpad_Elan_13043.7z
DP_Touchpad_Others_13042.7z
DP_Touchpad_Synaptics_13045.7z
DP_TV_Aver_13043.7z
DP_TV_Beholder_13014.7z
DP_TV_DVB_13033.7z
DP_TV_Others_13045.7z
DP_Video_AMD_13045.7z
DP_Video_Hybrid_13045.7z
DP_Video_Intel_13044.7z
DP_Video_MacBook_13044.7z
DP_Video_nVIDIA_13045.7z
DP_Video_Others_13034.7z
DP_Video_Server_13045.7z
DP_WebCam_13044.7z
DP_WLAN_13044.7z
DP_xUSB_13044.7z
DP_Biometric_13044.7z
DP_Bluetooth_13044.7z
DP_CardReader_13044.7z
DP_Chipset_13045.7z
DP_LAN_13044.7z
DP_MassStorage_13045.7z
DP_Misc_13044.7z
DP_Modem_13035.7z
DP_Monitor_13045.7z
DP_Notebook_13044.7z
DP_Printer_13044.7z
DP_Sound_ADI_13035.7z
DP_Sound_CMedia_13042.7z
DP_Sound_Conexant_13045.7z
DP_Sound_Creative_13044.7z
DP_Sound_IDT_13044.7z
DP_Sound_Others_13044.7z
DP_Sound_VIA_13035.7z
DP_Sounds_HDMI_13043.7z
DP_Sounds_Realtek_13044.7z
DP_Telephone_13044.7z
DP_Touchpad_Alps_13045.7z
DP_Touchpad_Elan_13043.7z
DP_Touchpad_Others_13042.7z
DP_Touchpad_Synaptics_13045.7z
DP_TV_Aver_13043.7z
DP_TV_Beholder_13014.7z
DP_TV_DVB_13033.7z
DP_TV_Others_13045.7z
DP_Video_AMD_13045.7z
DP_Video_Hybrid_13045.7z
DP_Video_Intel_13044.7z
DP_Video_MacBook_13044.7z
DP_Video_nVIDIA_13045.7z
DP_Video_Others_13034.7z
DP_Video_Server_13045.7z
DP_WebCam_13044.7z
DP_WLAN_13044.7z
DP_xUSB_13044.7z
Requisitos del sistema:
Para todas las versiones de Windows
Título: DriverPack Solución Profesional 13 R355 (x86/x64/MULTI/2013)
Año: 2013
Plataforma: 32bit, 64bit
Idioma: Multilingüe
Medicina: No es necesario
Tamaño: 5.88GB
Extras. Información: Autor: Arthur Kuzyakov y BadPointer
Edición: Enlace funcionando: En el post siguiente de Jh0sZ
#304
Off Topic / [VIDEO] Detienen a Spamhaus en España.
Abril 30, 2013, 09:20:17 AM
Arrest of Dutch suspect Sven Kamphuis in his appartment in Granollers, Barcelona.
Suspected to initiate one of the biggest DDOS attacks in Internet history.
Looks like someone with... no life
Curious stuff : 3 27 MHz portofones Midland ALAN 42 Multi, a Midland 27
MHz transmitter/receiver, German and NATO stamps, a Commodore 64 manual,
Vodafone modem, Thomson modem, very old Lenovo notebook, old HP server
and Neal Stephenson's Quicksilver, about the shift to science in the
17th century...
The man suspected of participating in a large DDoS attack on an antispam organization that caused intermittent Internet hiccups drove around Spain in a van he used as a mobile office, Spain's Interior Ministry said Sunday.
The van was equipped with "various antennas" that were used to scan frequencies, the ministry said in a news release. On Thursday, Spanish police arrested a 35-year-old Dutch man in Barcelona suspected of conducting cyberattacks against Spamhaus, a nonprofit group that develops widely used lists of networks identified as sending spam.
Spanish police published a video of a sparse residence they raided. Images showed the room was strewn with wires and computer equipment, including routers, a Mac Mini computer, laptops, an antennae and a single cot with the book "Quicksilver" by Neal Stephenson on it. Also shown were several rubber stamps, two of which were emblazoned "NATO secret" and "NATO unclassified."
Spain Interior MinistryPolice in Barcelona arrested a man suspected of participating in a large DDoS attack on an antispam organization.
The man has been identified by an official close to the investigation as Sven Kamphuis, who has denied involvement. Dutch authorities only identified the suspect by the initials "S.K." for privacy reasons. Kamphuis has said he believes the attacks originated with members of Stophaus, a group aiming to shutdown Spamhaus for its antispam work.
The DDoS attack was estimated to peak at more than 300Gbps, making it one of the largest attacks on record, but computer security experts disagreed somewhat over its broader effect on the Internet. The attack caused problems for some European Internet exchanges nodes, or places where ISPs link to transfer traffic to one another.
The Interior Ministry, which did not name the suspect, said they seized two laptops and documents from the residence. At the time of his arrest, the man, from Alkmaar, Netherlands, claimed to be the minister of telecommunications and foreign affairs of the Republic of CyberBunker, Spanish police said.
CyberBunker.com is a hosting provider based in a former military facility in the Netherlands. It specializes in so-called "bulletproof" hosting, or one that resists law enforcement efforts to remove certain content from the Internet. It claims it has no involvement in spam and does not allow SMTP traffic, the protocol used to send email.
Kamphuis runs a network provider called CB3ROB, which provided services for CyberBunker. CB3ROB had been blacklisted by Spamhaus for activity related to spamming botnets and extortion scams.
Read more at You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
VIDEO: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Suspected to initiate one of the biggest DDOS attacks in Internet history.
Looks like someone with... no life
Curious stuff : 3 27 MHz portofones Midland ALAN 42 Multi, a Midland 27
MHz transmitter/receiver, German and NATO stamps, a Commodore 64 manual,
Vodafone modem, Thomson modem, very old Lenovo notebook, old HP server
and Neal Stephenson's Quicksilver, about the shift to science in the
17th century...
The man suspected of participating in a large DDoS attack on an antispam organization that caused intermittent Internet hiccups drove around Spain in a van he used as a mobile office, Spain's Interior Ministry said Sunday.
The van was equipped with "various antennas" that were used to scan frequencies, the ministry said in a news release. On Thursday, Spanish police arrested a 35-year-old Dutch man in Barcelona suspected of conducting cyberattacks against Spamhaus, a nonprofit group that develops widely used lists of networks identified as sending spam.
Spanish police published a video of a sparse residence they raided. Images showed the room was strewn with wires and computer equipment, including routers, a Mac Mini computer, laptops, an antennae and a single cot with the book "Quicksilver" by Neal Stephenson on it. Also shown were several rubber stamps, two of which were emblazoned "NATO secret" and "NATO unclassified."
Spain Interior MinistryPolice in Barcelona arrested a man suspected of participating in a large DDoS attack on an antispam organization.
The man has been identified by an official close to the investigation as Sven Kamphuis, who has denied involvement. Dutch authorities only identified the suspect by the initials "S.K." for privacy reasons. Kamphuis has said he believes the attacks originated with members of Stophaus, a group aiming to shutdown Spamhaus for its antispam work.
The DDoS attack was estimated to peak at more than 300Gbps, making it one of the largest attacks on record, but computer security experts disagreed somewhat over its broader effect on the Internet. The attack caused problems for some European Internet exchanges nodes, or places where ISPs link to transfer traffic to one another.
The Interior Ministry, which did not name the suspect, said they seized two laptops and documents from the residence. At the time of his arrest, the man, from Alkmaar, Netherlands, claimed to be the minister of telecommunications and foreign affairs of the Republic of CyberBunker, Spanish police said.
CyberBunker.com is a hosting provider based in a former military facility in the Netherlands. It specializes in so-called "bulletproof" hosting, or one that resists law enforcement efforts to remove certain content from the Internet. It claims it has no involvement in spam and does not allow SMTP traffic, the protocol used to send email.
Kamphuis runs a network provider called CB3ROB, which provided services for CyberBunker. CB3ROB had been blacklisted by Spamhaus for activity related to spamming botnets and extortion scams.
Read more at You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
VIDEO: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#305
Dudas y pedidos generales / Re:¿Cómo poner la tarjeta de Sony Xperia S en modo monitor?
Abril 29, 2013, 08:51:11 AM
Hombre casi todos los smartphones llevan chip Broadcom, el tema q claro ellos no van añaden el soporte de captura, porq supongo q pensarán q vale para hacer cosas malignas xD
Pero esque yo no me imaginaba hace tiempo hacer una auditoría de una red desde un teléfono... Al final la acabaremos haciendo desde el microondas...
Saludos.
Pero esque yo no me imaginaba hace tiempo hacer una auditoría de una red desde un teléfono... Al final la acabaremos haciendo desde el microondas...
Saludos.
#306
Dudas y pedidos generales / Re:¿Cómo poner la tarjeta de Sony Xperia S en modo monitor?
Abril 29, 2013, 08:35:18 AM
También una alternativa, es utilizar tu tarjeta de auditoría wifi q tengas en el pc, porq yo no sé si el chip de xperia S es capaz de inyectar paquetes.
Te pasteo el post:

Tomó nota el investigador de seguridad Mike "dragorn" Kershaw , desarrollador del patrón oro en WiFi escáneres, Kismet, recientemente ha lanzado una herramienta para Android que permite a primas 802,11 capturas de fotogramas en el modo Wi-Fi monitor.
Poner un dispositivo WiFi en modo monitor le permite capturar todo tipo de datos interesantes acerca de la red inalámbrica a la que de otro modo sería invisible. Captura de Monitor de modo son de gran utilidad para el diagnóstico de red y pruebas de penetración, y conseguir que la capacidad en los dispositivos Android deben abrir un abanico de posibilidades muy interesantes.
Captura PCAP
La nueva herramienta, llamada simplemente " Android Captura PCAP ", hace las cosas un poco diferente de lo que cabría esperar. Para empezar, no utiliza la raíz o requieren una ROM personalizada a trabajar, lo cual es bastante inusual para una avanzada herramienta como esta. Kershaw es generalmente contra de exigir el acceso root en las aplicaciones de Android, ya que él siente lo actual se maneja simplemente no es lo suficientemente seguro teniendo en cuenta la magnitud del daño a raíz de la aplicación habilitada puede hacer:
Kershaw tiene un punto sobre la forma en que actualmente se manejan acceso de root, y pese a algunos esfuerzos por cambiar lo que consideramos la norma , que sin duda tienen un riesgo cada vez que se permite el acceso root para una aplicación.
Pero cualquiera que haya trabajado con Wi-Fi bajo el estándar de GNU / Linux sabe que hacer nada con el hardware avanzado requiere acceso root. Entonces, ¿cómo Kershaw logran poner el equipo en modo monitor sin necesidad de acceso raíz o un kernel personalizado?
RTL8187 Hardware
El control de la incorporada en el hardware WiFi en Android habría ciertamente requiere acceso de root, y más que probables modificaciones a la propia ROM. Eso supone que el hardware WiFi de tu dispositivo en particular, incluso tenía soporte para modo monitor en su conductor, para empezar, que no está garantizado.
Así que para la captura PCAP, Kershaw decidió no apoyar el hardware WiFi interna en absoluto, y en su lugar sólo admiten dispositivos que utilizan la RTL8187 chipset conectado a través de USB. Al implementar el controlador RTL8187 en espacio de usuario, la aplicación no requiere de raíz, sólo se debe ejecutar en un dispositivo Android que soporta el modo USB host.
Modo USB host en Android es una especie de cajón de sastre, por desgracia. Aunque técnicamente cualquier cosa con Android Honeycomb o mejor debería apoyar host USB, las variaciones entre los fabricantes de hardware significa que su dispositivo Android en particular puede o no apoyar host USB, incluso si tiene un bastante nueva versión de Android.
En términos generales, Nexus dispositivos como el Nexus Galaxy Nexus 7 o debería funcionar, pero los dispositivos de otros fabricantes tendrán que ser probado en una base de caso por caso.
Demostración de instalación
Para realizar nuestra prueba de captura con captura PCAP, vamos a estar usando el Nexus tablet 7 y el RTL8187 basada Alfa AWUS036H adaptador WiFi.
Ambas piezas de hardware son excepcionalmente populares en sus respectivas comunidades, el Nexus 7 es uno de los más vendidos y mejor soportadas tabletas de Android jamás lanzado, y el AWUS036H ser una opción común para el trabajo avanzado WiFi en Linux.
Mientras que algunos se lamentan sin duda requisito de captura PCAP para un adaptador RTL8187 WiFi y el dispositivo USB huésped capaz Android, no se puede realmente reclamar cualquiera de estos requisitos son tan difíciles de acomodar.
También necesitaremos un USB On-The-Go (OTG) Cable adaptador, que le permite conectar un dispositivo USB estándar al puerto micro-USB que se encuentra en la mayoría de las tabletas de Android y teléfonos inteligentes (como la línea Nexus). Estos pueden tener para tan poco como $ 1 USD en sitios como You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login o eBay.

Más Info; You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
FUENTE: arg-wireless
Te pasteo el post:

Tomó nota el investigador de seguridad Mike "dragorn" Kershaw , desarrollador del patrón oro en WiFi escáneres, Kismet, recientemente ha lanzado una herramienta para Android que permite a primas 802,11 capturas de fotogramas en el modo Wi-Fi monitor.
Poner un dispositivo WiFi en modo monitor le permite capturar todo tipo de datos interesantes acerca de la red inalámbrica a la que de otro modo sería invisible. Captura de Monitor de modo son de gran utilidad para el diagnóstico de red y pruebas de penetración, y conseguir que la capacidad en los dispositivos Android deben abrir un abanico de posibilidades muy interesantes.
Captura PCAP
La nueva herramienta, llamada simplemente " Android Captura PCAP ", hace las cosas un poco diferente de lo que cabría esperar. Para empezar, no utiliza la raíz o requieren una ROM personalizada a trabajar, lo cual es bastante inusual para una avanzada herramienta como esta. Kershaw es generalmente contra de exigir el acceso root en las aplicaciones de Android, ya que él siente lo actual se maneja simplemente no es lo suficientemente seguro teniendo en cuenta la magnitud del daño a raíz de la aplicación habilitada puede hacer:
CitarDar a raíz aplicaciones android me aterra - pone 100% de confianza en que el desarrollador no ser malicioso, y que el mercado no ha presentado un proyecto clonado que es malicioso, y en los sistemas de desarrolladores para asegurarse de que nadie jamás puede empujar una actualización con las llaves que se convierte malicioso ... es una mala noticia por todas partes.
Kismet Blog
Kershaw tiene un punto sobre la forma en que actualmente se manejan acceso de root, y pese a algunos esfuerzos por cambiar lo que consideramos la norma , que sin duda tienen un riesgo cada vez que se permite el acceso root para una aplicación.
Pero cualquiera que haya trabajado con Wi-Fi bajo el estándar de GNU / Linux sabe que hacer nada con el hardware avanzado requiere acceso root. Entonces, ¿cómo Kershaw logran poner el equipo en modo monitor sin necesidad de acceso raíz o un kernel personalizado?
RTL8187 Hardware
El control de la incorporada en el hardware WiFi en Android habría ciertamente requiere acceso de root, y más que probables modificaciones a la propia ROM. Eso supone que el hardware WiFi de tu dispositivo en particular, incluso tenía soporte para modo monitor en su conductor, para empezar, que no está garantizado.
Así que para la captura PCAP, Kershaw decidió no apoyar el hardware WiFi interna en absoluto, y en su lugar sólo admiten dispositivos que utilizan la RTL8187 chipset conectado a través de USB. Al implementar el controlador RTL8187 en espacio de usuario, la aplicación no requiere de raíz, sólo se debe ejecutar en un dispositivo Android que soporta el modo USB host.
Modo USB host en Android es una especie de cajón de sastre, por desgracia. Aunque técnicamente cualquier cosa con Android Honeycomb o mejor debería apoyar host USB, las variaciones entre los fabricantes de hardware significa que su dispositivo Android en particular puede o no apoyar host USB, incluso si tiene un bastante nueva versión de Android.
En términos generales, Nexus dispositivos como el Nexus Galaxy Nexus 7 o debería funcionar, pero los dispositivos de otros fabricantes tendrán que ser probado en una base de caso por caso.
Demostración de instalación
Para realizar nuestra prueba de captura con captura PCAP, vamos a estar usando el Nexus tablet 7 y el RTL8187 basada Alfa AWUS036H adaptador WiFi.
Ambas piezas de hardware son excepcionalmente populares en sus respectivas comunidades, el Nexus 7 es uno de los más vendidos y mejor soportadas tabletas de Android jamás lanzado, y el AWUS036H ser una opción común para el trabajo avanzado WiFi en Linux.
Mientras que algunos se lamentan sin duda requisito de captura PCAP para un adaptador RTL8187 WiFi y el dispositivo USB huésped capaz Android, no se puede realmente reclamar cualquiera de estos requisitos son tan difíciles de acomodar.
También necesitaremos un USB On-The-Go (OTG) Cable adaptador, que le permite conectar un dispositivo USB estándar al puerto micro-USB que se encuentra en la mayoría de las tabletas de Android y teléfonos inteligentes (como la línea Nexus). Estos pueden tener para tan poco como $ 1 USD en sitios como You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login o eBay.

Más Info; You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
FUENTE: arg-wireless
#307
Hacking / Re:Desencriptador de Secuencias
Abril 28, 2013, 12:55:11 PM
Y esos números, no pueden ser los 6 últimos dígitos de un teléfono móvil por ejemplo??
#308
Windows / Re:Cómo recuperar particiones eliminadas o borradas con TestDisk
Abril 28, 2013, 11:06:45 AM
Esta herramienta es increíble, nunca me ha funcionado ninguna parecida de manera tan eficaz. Hay q tener esta herramienta en favoritos, podremos recuperar muchos datos de clientes, aunque esten las particiones hechas mierda.
Saludos y gracias por el aporte.
Saludos y gracias por el aporte.
#309
Diseño UX/UI / Re:Pide tu firma Underc0de!
Abril 28, 2013, 11:01:40 AM
Buenas chavales!! Cuando podáis una con mi nick plisss!!
Gracias de antemano. Saludos.
Gracias de antemano. Saludos.
#310
Hacking / Re:Metasploit - Bug Java 7u17
Abril 28, 2013, 10:59:39 AM
Lo mejor desde hace tiempo es desinstalarlo... xq tela...
#312
Dudas y pedidos generales / Re:Frenar Ataques DDOS
Abril 26, 2013, 06:57:33 AM
· Limitar de 50 a 100 el número de conexiones desde un origen determinado. Si se trata de un ataque, las conexiones excedentes se eliminarán (drop).
· Limitar de 5 a 10 el número de conexiones realizadas por segundo.
· Bloquear/Ignorar temporal o definitivamente las direcciones IP identificadas como posibles atacantes.
· Perfeccionar las técnicas de Ingress-Filtering de modo de poder "identificar como no-anomalas" las direcciones IP que solicitan un recurso. Se puede consultar la RFC 2827 que define dichas políticas.
· Para evitar ataques de tráfico saliente desde una organización (como por ejemplo desde una botnet) también se debe considerar las políticas de Egress-Filtering, solicitada en varias disposiciones y regulaciones vigentes, como PCI DSS.
Lighttpd Traffic Shaping: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
OpenBSD PF Firewall Script: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Linux Iptables Firewall: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Saludos peña!
· Limitar de 5 a 10 el número de conexiones realizadas por segundo.
· Bloquear/Ignorar temporal o definitivamente las direcciones IP identificadas como posibles atacantes.
· Perfeccionar las técnicas de Ingress-Filtering de modo de poder "identificar como no-anomalas" las direcciones IP que solicitan un recurso. Se puede consultar la RFC 2827 que define dichas políticas.
· Para evitar ataques de tráfico saliente desde una organización (como por ejemplo desde una botnet) también se debe considerar las políticas de Egress-Filtering, solicitada en varias disposiciones y regulaciones vigentes, como PCI DSS.
Lighttpd Traffic Shaping: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
OpenBSD PF Firewall Script: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Linux Iptables Firewall: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Saludos peña!
#313
Seguridad Wireless / Hackeando al vecino que me roba la WiFi (2 de 2)
Abril 22, 2013, 01:11:24 PM
Paralelamente a estos intentos, siempre mantenía mi equipo capturando tráfico WiFi en modo monitor, y analizaba las capturas, además de las que obtenía con Cain + Wireshark. En estas nuevas capturas, obtuve información interesante para el análisis.
Mi vecino/a se conectaba dos o tres veces al día, alrededor de 15 minutos cada sesión. Las páginas webs más visitadas seguían siendo de marujeo, como las comentadas en los párrafos anteriores, pero además habían accesos a las siguientes páginas:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Analizando el nombre de los sitios web, así como el contenido que había en los mismos, me quedó claro que se trataba de una mujer, que estaba estudiando para oposiciones a judicatura. Es decir, que hablamos de una aspirante a juez robando WiFi. ¡Así va este país!. Por otro lado, entre todas estas sesiones de navegación, en las que los sitios webs visitados eran los mismos especificados hasta ahora, se colaban algunas sesiones cortas en la que los sitios visitados eran:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login (Además leía la sección "El balón Rosa"
)
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Estas sesiones, en principio parecía que correspondían más a "Rober1", leyendo periódicos deportivos y echando un vistazo a las novias y mujeres de los futbolistas. En una de estas sesiones, concretamente un domingo, Rober1 consultó también la página de Yelmo Cines, pero al final parece que no se decidió a ir, porque más tarde presuntamente su pareja se volvió a conectar a ver vídeos de bebés, y leer un poco de prensa rosa, supongo que para desconectar de las arduas sesiones de estudio para la oposición.
Por la información de la que disponía hasta el momento, se trataba de una pareja de vecinos que utilizaba mi red para conectarse a Internet y ahorrarse la tarifa del ISP, no de un hax0r con muchos conocimientos. Esto último me quedó más claro, cuando en una de las capturas recogidas escuchando en modo monitor, pude ver accesos a páginas de banca electrónica, algo que alguien con conocimientos de seguridad informática jamás haría desde una WiFi ajena.

Afortunadamente para los vecinos, dieron con alguien que no tenía malas intenciones, y en esta ocasión, incluso de haberlas tenido, no podría haber hecho ningún destrozo, ya que al tratarse de tráfico SSL las credenciales no habrían sido capturadas sin romper el cifrado.
En este punto ya tenía claro el perfil de los "atacantes", así como su nivel de conocimientos, pero aún no los había identificado. Los ataques man in the middle no funcionaban siempre, así que se me ocurrieron varias alternativas. La primera de ellas, enchufarles un troyano haciendo DNS spooffing con alguna de las direcciones de los sitios webs más visitados. Pero en lugar de eso, decidí implementar un esquema "machine in the middle", colocando una máquina a modo de router, para asegurar que todo el tráfico que generaban pasaba por la misma.
Para ello, habilité una máquina virtual Backtrack, a modo de puente con dos interfaces de red. Una de ellas conectada a la red en cuestión, 192.186.1.0, y la otra en una nueva red 192.168.2.0, con la dirección IP 192.168.2.1. Además de eso, deshabilité el servidor DCHP del router al que se conectaban los vecinos, y arranqué un servidor DHCP en la máquina virtual, que repartiera direcciones en la nueva red, especificando como puerta de enlace la dirección de esta máquina en la nueva red, la 192.168.2.1. El tráfico generado era redirigido de una interfaz a otra, en aras de poder llevar el tráfico hacia y desde Internet a través del router principal.
Por otra parte, también arranqué la herramienta SSLstrip, redirigiendo el tráfico SSL al puerto 10.000, para poder así interceptar sesiones de autenticación en algún sitio web que permitiese obtener alguna información para identificar a los malhechores. En este script de shell se puede observar la configuración final.

Con este nuevo esquema, los vecinos se conectaban a mi router vía WiFi, pero era la nueva máquina puente la que hacía de router para ellos, dándoles una nueva dirección IP en el rango 192.168.2.0 y ofreciéndoles salida a Internet. Bastaba con arrancar tcpdump, dsniff, y visualizar el log de sslstrip para poder controlar todo el tráfico generado por los vecinos.
El esquema no tardó en funcionar. La siguiente vez que se conectaron, todos los paquetes pasaban por la nueva máquina puente, y tras una o dos sesiones de navegación, el log de SSLstrip reveló su dirección de correo electrónico y su cuenta de Facebook:

En este punto había completado mi análisis, y con un poco de Google Hacking a partir de su dirección de correo pude averiguar quiénes eran los vecinos, y confirmar que en efecto, se trataba de una pareja de abogados, ella estudiando para presentarse a una oposición de juez. Podría haberles hecho alguna trastada, como publicar algo en su muro, o cosas por el estilo, pero simplemente me limité a enviarles un correo informándoles de que estaba al corriente de lo que habían hecho, dándoles algunos detalles que les mostraran que efectivamente tenía conocimiento de sus sesiones de navegación, y advertirle de los peligros que corrían realizando este tipo de prácticas.
Me contestaron ofreciendo sus disculpas, comentándome que estaban avergonzados de su comportamiento y que no tenían mucha idea de lo que estaban haciendo, ya que fue "un amigo informático" el que les consiguió la conexión a Internet gratis.
Como ya todos sabemos, es impresionante toda la información que se puede obtener de una persona simplemente echando un vistazo a los sitios que visita en Internet, pero si además resulta que no sólo navega por páginas de información, sino que utiliza servicios de correo electrónico, redes sociales, o banca electrónica desde una conexión "robada", el destrozo podría ser de dimensiones considerables.
Por motivos de protección de datos se ha sustituido el nombre real del equipo vecino por "Rober1", pero el host original sigue la misma nomenclatura. Por otro lado quiero deciros que este artículo está hecho por si alguno de los lectores de este blog tiene una pareja de amigos que un día le piden que le robe la WiFi a algún vecino para conectarse gratis a Internet. Tened cuidado que, como decía Chema, la víctima del robo puede que también tenga también un amigo informático y les metas en un verdadero problema a tus amigos.
Saludos.
FUENTE: chema alonso, un informatico en el lado del mal, informatica 64
Mi vecino/a se conectaba dos o tres veces al día, alrededor de 15 minutos cada sesión. Las páginas webs más visitadas seguían siendo de marujeo, como las comentadas en los párrafos anteriores, pero además habían accesos a las siguientes páginas:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Analizando el nombre de los sitios web, así como el contenido que había en los mismos, me quedó claro que se trataba de una mujer, que estaba estudiando para oposiciones a judicatura. Es decir, que hablamos de una aspirante a juez robando WiFi. ¡Así va este país!. Por otro lado, entre todas estas sesiones de navegación, en las que los sitios webs visitados eran los mismos especificados hasta ahora, se colaban algunas sesiones cortas en la que los sitios visitados eran:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login (Además leía la sección "El balón Rosa"
)You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
Estas sesiones, en principio parecía que correspondían más a "Rober1", leyendo periódicos deportivos y echando un vistazo a las novias y mujeres de los futbolistas. En una de estas sesiones, concretamente un domingo, Rober1 consultó también la página de Yelmo Cines, pero al final parece que no se decidió a ir, porque más tarde presuntamente su pareja se volvió a conectar a ver vídeos de bebés, y leer un poco de prensa rosa, supongo que para desconectar de las arduas sesiones de estudio para la oposición.
Por la información de la que disponía hasta el momento, se trataba de una pareja de vecinos que utilizaba mi red para conectarse a Internet y ahorrarse la tarifa del ISP, no de un hax0r con muchos conocimientos. Esto último me quedó más claro, cuando en una de las capturas recogidas escuchando en modo monitor, pude ver accesos a páginas de banca electrónica, algo que alguien con conocimientos de seguridad informática jamás haría desde una WiFi ajena.

Afortunadamente para los vecinos, dieron con alguien que no tenía malas intenciones, y en esta ocasión, incluso de haberlas tenido, no podría haber hecho ningún destrozo, ya que al tratarse de tráfico SSL las credenciales no habrían sido capturadas sin romper el cifrado.
En este punto ya tenía claro el perfil de los "atacantes", así como su nivel de conocimientos, pero aún no los había identificado. Los ataques man in the middle no funcionaban siempre, así que se me ocurrieron varias alternativas. La primera de ellas, enchufarles un troyano haciendo DNS spooffing con alguna de las direcciones de los sitios webs más visitados. Pero en lugar de eso, decidí implementar un esquema "machine in the middle", colocando una máquina a modo de router, para asegurar que todo el tráfico que generaban pasaba por la misma.
Para ello, habilité una máquina virtual Backtrack, a modo de puente con dos interfaces de red. Una de ellas conectada a la red en cuestión, 192.186.1.0, y la otra en una nueva red 192.168.2.0, con la dirección IP 192.168.2.1. Además de eso, deshabilité el servidor DCHP del router al que se conectaban los vecinos, y arranqué un servidor DHCP en la máquina virtual, que repartiera direcciones en la nueva red, especificando como puerta de enlace la dirección de esta máquina en la nueva red, la 192.168.2.1. El tráfico generado era redirigido de una interfaz a otra, en aras de poder llevar el tráfico hacia y desde Internet a través del router principal.
Por otra parte, también arranqué la herramienta SSLstrip, redirigiendo el tráfico SSL al puerto 10.000, para poder así interceptar sesiones de autenticación en algún sitio web que permitiese obtener alguna información para identificar a los malhechores. En este script de shell se puede observar la configuración final.

Con este nuevo esquema, los vecinos se conectaban a mi router vía WiFi, pero era la nueva máquina puente la que hacía de router para ellos, dándoles una nueva dirección IP en el rango 192.168.2.0 y ofreciéndoles salida a Internet. Bastaba con arrancar tcpdump, dsniff, y visualizar el log de sslstrip para poder controlar todo el tráfico generado por los vecinos.
El esquema no tardó en funcionar. La siguiente vez que se conectaron, todos los paquetes pasaban por la nueva máquina puente, y tras una o dos sesiones de navegación, el log de SSLstrip reveló su dirección de correo electrónico y su cuenta de Facebook:

En este punto había completado mi análisis, y con un poco de Google Hacking a partir de su dirección de correo pude averiguar quiénes eran los vecinos, y confirmar que en efecto, se trataba de una pareja de abogados, ella estudiando para presentarse a una oposición de juez. Podría haberles hecho alguna trastada, como publicar algo en su muro, o cosas por el estilo, pero simplemente me limité a enviarles un correo informándoles de que estaba al corriente de lo que habían hecho, dándoles algunos detalles que les mostraran que efectivamente tenía conocimiento de sus sesiones de navegación, y advertirle de los peligros que corrían realizando este tipo de prácticas.
Me contestaron ofreciendo sus disculpas, comentándome que estaban avergonzados de su comportamiento y que no tenían mucha idea de lo que estaban haciendo, ya que fue "un amigo informático" el que les consiguió la conexión a Internet gratis.
Como ya todos sabemos, es impresionante toda la información que se puede obtener de una persona simplemente echando un vistazo a los sitios que visita en Internet, pero si además resulta que no sólo navega por páginas de información, sino que utiliza servicios de correo electrónico, redes sociales, o banca electrónica desde una conexión "robada", el destrozo podría ser de dimensiones considerables.
Por motivos de protección de datos se ha sustituido el nombre real del equipo vecino por "Rober1", pero el host original sigue la misma nomenclatura. Por otro lado quiero deciros que este artículo está hecho por si alguno de los lectores de este blog tiene una pareja de amigos que un día le piden que le robe la WiFi a algún vecino para conectarse gratis a Internet. Tened cuidado que, como decía Chema, la víctima del robo puede que también tenga también un amigo informático y les metas en un verdadero problema a tus amigos.
Saludos.
FUENTE: chema alonso, un informatico en el lado del mal, informatica 64
#314
Seguridad Wireless / Hackeando al vecino que me roba la WiFi (1 de 2).
Abril 22, 2013, 01:08:22 PM
Hace unos meses, realizando pruebas de diferentes tipos de ataques sobre redes WiFi, dejé habilitada una red en casa con cifrado WEP, (eso sí, sin el SSID del operador con la contraseña por defecto predecible mediante las clásicas herramientas como Liberad a WiFi). Pasó el tiempo y dejé la red tal y como estaba, consciente evidentemente de que alguien podría querer invitarse algún día a la fiesta sin haber pagado la entrada, en cuyo caso ya mandaría yo a los de seguridad.
Pues bien, hace unos días, echando un vistazo a los Logs del servicio DHCP de mi router, cuál fue mi sorpresa al ver que además de la información de mis equipos, había una fila más con el nombre de host "Rober1". En efecto, algún vecino estaba intentando utilizar mi red, y considerando que como poco había tenido que utilizar alguna herramienta para obtener la contraseña, podría tratarse de un vecino con conocimientos sobre hacking, aunque lo de poner su nombre en el hostname indicaba lo contrario (siempre y cuando no se tratara de un cebo). Por lo pronto, no conocía a ningún vecino llamado Rober o Roberto.
El primer impulso de cualquiera ante una situación así, podría ser el de cambiar el cifrado de la red a WPA2 con una clave robusta, y cortarle el grifo al vecino, pero los que nos dedicamos a esto de la seguridad, lo vemos como una excelente oportunidad para realizar una práctica con fuego real de hacking en redes de datos, al fin de todo, la red es mía y él es el intruso.
Como no disponía de mucho tiempo, pues esto me cogió justo antes de salir de casa a un compromiso ineludible, además de desconectar todos mis equipos de la red, y dejarle así todo el ancho de banda a "Rober1" para que se sintiese como en casa, mi primer paso fue poner rápidamente uno de mis equipos con Backtrack5, una antena WiFiy la suite Aircrack, a escuchar el tráfico de mi propia red en modo monitor. El objetivo era intentar obtener algún dato que me pudiese dar información acerca del vecino para conocer sus intenciones, pues podría pretender simplemente utilizarme como ISP y ahorrarse la cuota mensual con esto de la crisis y los recortes, o "auditar" mis equipos, en cuyo caso debía prepararme para la batalla.
Al llegar a casa, y descifrar el tráfico capturado con airdecrypt, me dispuse a analizarlo utilizando en primer lugar la versión gratuita de la herramienta Network Miner, que corre en sistema operativo Windows y es muy útil a la hora de obtener una visión a alto nivel de una captura de tráfico. Una vez cargada la captura, Network Miner identifica todos los hosts presentes en ella, y reconstruye a partir del tráfico tramas, archivos, imágenes, mensajes de chat, credenciales y sesiones si se han capturado, peticiones DNS, parámetros GET.. Además proporciona información interesante sobre los equipos presentes en la captura, que por otra parte podría obtenerse con cualquier otro analizador de tráfico tipo Wireshark, pero facilita bastante la tarea.

La primera lectura que podía realizar es que se trataba de un equipo con sistema operativo Windows, de nombre "Rober1", que estaba utilizando mi red para navegar por Internet. Analizando las tramas y las conexiones establecidas, los sitios webs más visitados durante la sesión de navegación, que duró cerca de 20 minutos, eran los siguientes:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
En la siguiente imagen se pueden observar algunas de las imágenes descargadas durante la sesión de navegación:

Sin querer entrar en un debate y limitándome a relatar en este artículo cuáles fueron mis suposiciones y el proceso mental seguido, mi primera impresión fue que más que tratarse de un hacker, se trataba de o bien una hacker o bien la amiga, novia, madre, hermana o esposa de "Rober1", pues eran todas páginas de lo que yo considero "marujeo", orientadas más a un público femenino.
Realizando un análisis más profundo con herramientas como CookieCadger o Wireshark, también di con información exacta del equipo que estaba utilizando para conectarse a Internet, identificando peticiones HTTP, correspondientes a la comprobación de actualizaciones disponibles para un Notebook Asus F50SL:

El siguiente paso consistiría en intentar conseguir más información mediante un ataque man in the middle, para intentar obtener alguna credencial en algún sitio web donde tuviera que identificarse, pero para eso debería de estar en casa esperando justo en el momento en que mi vecino/a fuese a utilizar mi red para navegar. Para ello, utilicé Cain + Wireshark en entorno Windows, y también arpsoof en entorno Linux. Coincidimos un par de veces a la misma hora, pero resultó que en esas ocasiones el único tráfico que generaba mi vecino, era el correspondiente a visualizar vídeos en Youtube de bebés. Esto alimentó aún más mi sospecha de que se tratara de una mujer.
Por supuesto, en aquellas ocasiones en que coincidía conectado a la vez que mi vecino/a, antes de intentar un ataque MITM, me propuse escanear su máquina con nmap, pero los puertos estaban filtrados por el Firewall de Windows.
Seguía sin poder identificar al vecino, pues a pesar de tener acceso al tráfico que generaba, no existía ningún rastro de sitios donde se autenticara con credenciales. Ni correo, ni Facebook, ni nada en un principio. Los días fueron pasando, y cada vez era más difícil coincidir en horarios para realizar un MITM. Entre el trabajo y mi reciente estrenada paternidad, complicado cuadrar con el vecino/a.
Por otra parte, este tipo de ataque, no siempre funcionaba del todo bien, hecho que podía achacar también a la distancia del equipo a mi router, pero no penséis ni por un instante que lo iba a dejar así, ¡qué me estaba hackeando la WiFi!
FUENTE: un informatico en el lado del mal, chema alonso, informatica 64
Pues bien, hace unos días, echando un vistazo a los Logs del servicio DHCP de mi router, cuál fue mi sorpresa al ver que además de la información de mis equipos, había una fila más con el nombre de host "Rober1". En efecto, algún vecino estaba intentando utilizar mi red, y considerando que como poco había tenido que utilizar alguna herramienta para obtener la contraseña, podría tratarse de un vecino con conocimientos sobre hacking, aunque lo de poner su nombre en el hostname indicaba lo contrario (siempre y cuando no se tratara de un cebo). Por lo pronto, no conocía a ningún vecino llamado Rober o Roberto.
El primer impulso de cualquiera ante una situación así, podría ser el de cambiar el cifrado de la red a WPA2 con una clave robusta, y cortarle el grifo al vecino, pero los que nos dedicamos a esto de la seguridad, lo vemos como una excelente oportunidad para realizar una práctica con fuego real de hacking en redes de datos, al fin de todo, la red es mía y él es el intruso.
Como no disponía de mucho tiempo, pues esto me cogió justo antes de salir de casa a un compromiso ineludible, además de desconectar todos mis equipos de la red, y dejarle así todo el ancho de banda a "Rober1" para que se sintiese como en casa, mi primer paso fue poner rápidamente uno de mis equipos con Backtrack5, una antena WiFiy la suite Aircrack, a escuchar el tráfico de mi propia red en modo monitor. El objetivo era intentar obtener algún dato que me pudiese dar información acerca del vecino para conocer sus intenciones, pues podría pretender simplemente utilizarme como ISP y ahorrarse la cuota mensual con esto de la crisis y los recortes, o "auditar" mis equipos, en cuyo caso debía prepararme para la batalla.
Al llegar a casa, y descifrar el tráfico capturado con airdecrypt, me dispuse a analizarlo utilizando en primer lugar la versión gratuita de la herramienta Network Miner, que corre en sistema operativo Windows y es muy útil a la hora de obtener una visión a alto nivel de una captura de tráfico. Una vez cargada la captura, Network Miner identifica todos los hosts presentes en ella, y reconstruye a partir del tráfico tramas, archivos, imágenes, mensajes de chat, credenciales y sesiones si se han capturado, peticiones DNS, parámetros GET.. Además proporciona información interesante sobre los equipos presentes en la captura, que por otra parte podría obtenerse con cualquier otro analizador de tráfico tipo Wireshark, pero facilita bastante la tarea.

La primera lectura que podía realizar es que se trataba de un equipo con sistema operativo Windows, de nombre "Rober1", que estaba utilizando mi red para navegar por Internet. Analizando las tramas y las conexiones establecidas, los sitios webs más visitados durante la sesión de navegación, que duró cerca de 20 minutos, eran los siguientes:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
En la siguiente imagen se pueden observar algunas de las imágenes descargadas durante la sesión de navegación:

Sin querer entrar en un debate y limitándome a relatar en este artículo cuáles fueron mis suposiciones y el proceso mental seguido, mi primera impresión fue que más que tratarse de un hacker, se trataba de o bien una hacker o bien la amiga, novia, madre, hermana o esposa de "Rober1", pues eran todas páginas de lo que yo considero "marujeo", orientadas más a un público femenino.
Realizando un análisis más profundo con herramientas como CookieCadger o Wireshark, también di con información exacta del equipo que estaba utilizando para conectarse a Internet, identificando peticiones HTTP, correspondientes a la comprobación de actualizaciones disponibles para un Notebook Asus F50SL:

El siguiente paso consistiría en intentar conseguir más información mediante un ataque man in the middle, para intentar obtener alguna credencial en algún sitio web donde tuviera que identificarse, pero para eso debería de estar en casa esperando justo en el momento en que mi vecino/a fuese a utilizar mi red para navegar. Para ello, utilicé Cain + Wireshark en entorno Windows, y también arpsoof en entorno Linux. Coincidimos un par de veces a la misma hora, pero resultó que en esas ocasiones el único tráfico que generaba mi vecino, era el correspondiente a visualizar vídeos en Youtube de bebés. Esto alimentó aún más mi sospecha de que se tratara de una mujer.
Por supuesto, en aquellas ocasiones en que coincidía conectado a la vez que mi vecino/a, antes de intentar un ataque MITM, me propuse escanear su máquina con nmap, pero los puertos estaban filtrados por el Firewall de Windows.
Seguía sin poder identificar al vecino, pues a pesar de tener acceso al tráfico que generaba, no existía ningún rastro de sitios donde se autenticara con credenciales. Ni correo, ni Facebook, ni nada en un principio. Los días fueron pasando, y cada vez era más difícil coincidir en horarios para realizar un MITM. Entre el trabajo y mi reciente estrenada paternidad, complicado cuadrar con el vecino/a.
Por otra parte, este tipo de ataque, no siempre funcionaba del todo bien, hecho que podía achacar también a la distancia del equipo a mi router, pero no penséis ni por un instante que lo iba a dejar así, ¡qué me estaba hackeando la WiFi!
FUENTE: un informatico en el lado del mal, chema alonso, informatica 64
#315
Hacking / SQL Injection hasta la cocina - Oracle (I)
Abril 22, 2013, 12:59:54 PM
Al contrario de lo que sucede con MS SQL Server, en Oracle no existe un comando equivalente a "xp_cmdshell" que nos permita directamente ejecutar comandos del sistema operativo, pero sí que existen algunas funciones y procedimientos de las que podemos abusar para conseguir nuestro objetivo.
Para este primer post vamos a suponer que tenemos una inyección sql con un usuario con todos los privilegios del mundo, y veremos como conseguiríamos ejecutar comandos. En el próximo post veremos como podemos elevar privilegios en el caso de que no seamos tan afortunados de encontrar unos privilegios tan mal asignados. Para las demostraciones utilizaremos una URL como la siguiente, que contiene una vulnerabilidad en su parámetro "id":
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
A pesar de no existir una función equivalente a "xp_cmdshell", Oracle permite diferentes acciones sobre clases por medio del paquete DBMS_JAVA. Una de las funciones de este paquete que nos permite llamar a clases java es RUNJAVA(), que será la que utilizaremos en este post para ejecutar código. Vale, está claro, podemos ejecutar clases java que haya en nuestro servidor objetivo peor... ¿hay alguna clase que venga preinstalada y de la que podamos abusar parar ejecutar código? La respuesta es SI: Existe una clase llamada "Wrapper" que, como vamos a ver a continuación, es exactamente lo que andábamos buscando:

Como podéis ver, esta clase java simplemente coge lo que le hayamos pasado como parámetros y directamente lo ejecuta sobre el sistema operativo, así que ya tenemos una pista del tipo de sentencia SQL que vamos a tener que realizar para conseguir ejecución remota de comandos:
Código: text
Recordad que las contrabarras tienen que ser escapadas para que lleguen al sistema operativo tal y como queremos. En este caso, estaremos creando un fichero en c:\ con el contenido "PWNED", que es una prueba bastante inútil en si mismo, pero que al menos nos muestra si estamos consiguiente ejecución de comandos o no.

Esta sentencia, además, podemos insertarla perfectamente en una Inyección SQL como haríamos con cualquier condición, de la siguiente forma:
Código: text
¡Qué fácil! ¿Verdad?
Pues no, lo cierto es que no es tan fácil ¿Recordáis que comentábamos que en este caso asumimos que el usuario de base de datos de la aplicación tiene "todos los privilegios del mundo"? Tampoco necesitamos todos los del mundo, sino que con uno solo nos basta: java.io.FilePermission. Este permiso, sin embargo, no se asigna por defecto, y yo no he visto muchos sitios donde los administradores lo hayan asignado muy a la ligera, así que podemos asumir que en una Inyección SQL real no nos vamos a encontrar con estos privilegios.
Ya, ya sé lo que estáis pensando, que vaya post inútil os he contado ¿verdad? Bueno, digamos que todo lo que os acabo de contar os vale como un segundo paso de la explotación, una vez que ya hayamos conseguido elevar a los privilegios necesarios.
FUENTE: pentester
Para este primer post vamos a suponer que tenemos una inyección sql con un usuario con todos los privilegios del mundo, y veremos como conseguiríamos ejecutar comandos. En el próximo post veremos como podemos elevar privilegios en el caso de que no seamos tan afortunados de encontrar unos privilegios tan mal asignados. Para las demostraciones utilizaremos una URL como la siguiente, que contiene una vulnerabilidad en su parámetro "id":
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
A pesar de no existir una función equivalente a "xp_cmdshell", Oracle permite diferentes acciones sobre clases por medio del paquete DBMS_JAVA. Una de las funciones de este paquete que nos permite llamar a clases java es RUNJAVA(), que será la que utilizaremos en este post para ejecutar código. Vale, está claro, podemos ejecutar clases java que haya en nuestro servidor objetivo peor... ¿hay alguna clase que venga preinstalada y de la que podamos abusar parar ejecutar código? La respuesta es SI: Existe una clase llamada "Wrapper" que, como vamos a ver a continuación, es exactamente lo que andábamos buscando:

Como podéis ver, esta clase java simplemente coge lo que le hayamos pasado como parámetros y directamente lo ejecuta sobre el sistema operativo, así que ya tenemos una pista del tipo de sentencia SQL que vamos a tener que realizar para conseguir ejecución remota de comandos:
SELECT dbms_java.runjava('oracle/aurora/util/Wrapper c:\\\\windows\\\\system32\\\\cmd.exe /c echo PWNED > c:\\\\pwned.txt') FROM DUAL);Recordad que las contrabarras tienen que ser escapadas para que lleguen al sistema operativo tal y como queremos. En este caso, estaremos creando un fichero en c:\ con el contenido "PWNED", que es una prueba bastante inútil en si mismo, pero que al menos nos muestra si estamos consiguiente ejecución de comandos o no.

Esta sentencia, además, podemos insertarla perfectamente en una Inyección SQL como haríamos con cualquier condición, de la siguiente forma:
http://www.vulnerable.com/dbaoracle.asp?id=1 and (SELECT dbms_java.runjava('oracle/aurora/util/Wrapper c:\\\\windows\\\\system32\\\\cmd.exe /c echo PWNED > c:\\\\pwned.txt') FROM DUAL) IS NOT NULL -- ¡Qué fácil! ¿Verdad?
Pues no, lo cierto es que no es tan fácil ¿Recordáis que comentábamos que en este caso asumimos que el usuario de base de datos de la aplicación tiene "todos los privilegios del mundo"? Tampoco necesitamos todos los del mundo, sino que con uno solo nos basta: java.io.FilePermission. Este permiso, sin embargo, no se asigna por defecto, y yo no he visto muchos sitios donde los administradores lo hayan asignado muy a la ligera, así que podemos asumir que en una Inyección SQL real no nos vamos a encontrar con estos privilegios.
Ya, ya sé lo que estáis pensando, que vaya post inútil os he contado ¿verdad? Bueno, digamos que todo lo que os acabo de contar os vale como un segundo paso de la explotación, una vez que ya hayamos conseguido elevar a los privilegios necesarios.
FUENTE: pentester
#316
Hacking / Técnicas para descubrir los ficheros de un sitio web 1 de 2
Abril 18, 2013, 12:36:07 PM
Técnicas para descubrir los ficheros de un sitio web 1 de 2
Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.
Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:
1.- Crawling
La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo que tradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

2.- Robots.txt
Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.
3.- Sitemap.xml
Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

4.- Buscadores
Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador.
5.- Directory Listing
Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.
6.- Ficheros .listing
Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

7.- Ficheros .DS_Store
Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.
8.- Ficheros Thumbs.db
Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.

9.- Repositorios de código fuente de los sitios web
En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria.
10.- Ficheros de error 404
Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Hasta aquí los 10 primeros sitios a mirar, en la segunda parte irá otra buena tanda de sitios y formas para encontrar las URLs que nos lleven a los nombres de los ficheros, para así poder encontrar los que sean juicy files.
Saludos.
FUENTE: chema alonso, el lado del mal
Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.
Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:
1.- Crawling
La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo que tradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

2.- Robots.txt
Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.
3.- Sitemap.xml
Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

4.- Buscadores
Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador.
5.- Directory Listing
Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.
6.- Ficheros .listing
Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

7.- Ficheros .DS_Store
Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.
8.- Ficheros Thumbs.db
Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.
9.- Repositorios de código fuente de los sitios web
En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria.
10.- Ficheros de error 404
Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Hasta aquí los 10 primeros sitios a mirar, en la segunda parte irá otra buena tanda de sitios y formas para encontrar las URLs que nos lleven a los nombres de los ficheros, para así poder encontrar los que sean juicy files.
Saludos.
FUENTE: chema alonso, el lado del mal
#317
Hacking / OpenVPN pivoting.
Abril 18, 2013, 12:26:22 PM
Como todos sabéis, pivotar o pivoting es un método que consiste básicamente en utilizar un sistema bajo nuestro control como pasarela para atacar otros sistemas y redes, evadiendo así restricciones como las reglas de un firewall intermedio. Podríamos dividir esta técnica en dos grandes tipos:
- Proxy pivoting: se canaliza el tráfico a través de un payload en el equipo mediante el cual pivotaremos. Se limita a determinados puertos TCP y UDP.
- VPN pivoting: consiste en crear un túnel cifrado contra el equipo mediante el cual pivotaremos para enrutar todo el tráfico de red, por ejemplo para ejecutar un escaneo de vulnerabilidades a otros equipos de su red o de otras redes a las que tiene acceso.
En mi caso, por versatilidad, necesito esta última técnica. Podría utilizar la versión Pro de Metasploit o Cobalt Strike que son herramientas excelentes para VPN pivoting, aunque también lo son de pago, así que según está la economía me decanto por OpenVPN.
Os planteo el siguiente escenario:

Imaginad una topología con un servidor de monitorización con Nagios en la DMZ el cual, por su naturaleza, tiene habilitado además accesos a otros segmentos de red. Tengo el usuario root y ya accedo a la consola por SSH. Además, el firewall interno me permite acceder a otros puertos del servidor.
Si realizo un escaneo desde mi portátil obtengo los siguientes resultados:
Código: text
Podría montar un túnel directamente sobre ssh, pero resultaría muy fácil meter la pata y perder la conexión con el servidor remoto, y no me gustaría tener que llamar al administrador de sistemas varias veces para que me reinicie el servidor ¬_¬ ... Así que utilizaré otro puerto abierto, por ejemplo el del telnet (por qué coño está abierto el puerto del telnet?).
Empezaré instalando OpenVPN. El servidor es Ubuntu así que esto es bastante trivial:
Código: text
OpenVPN tiene dos modos de funcionamiento, uno basado en claves estáticas pre-compartidas y otro en SSL/TLS usando certificados y claves RSA. Aunque no tan seguro, usaré el primero por simplicidad. A continuación, genero la clave privada:
Código: text
Esta clave es simétrica, por lo que la tiene que tener tanto el servidor como el cliente, con lo cual, después de generarla la copiaré a mi portátil mediante SCP (con WinSCP puesto que mi SO es Windows 7) y la protegeré como oro en paño... por que no hace falta que os diga qué pasaría si un tercero se hiciera con ella...no?
El objetivo entonces es crear un túnel VPN punto a punto que se establecerá entre los interfaces virtuales (tun0) del servidor y mi portátil con una IP privada a cada extremo: 10.8.0.1 en el endpoint del servidor y 10.8.0.2 en el endpoint del cliente. Con el modo p2p (predeterminado) se establece una topología punto-a-punto en donde la dirección IP virtual del peer remoto de la interfaz tun del cliente siempre apunta a la dirección IP virtual local de la interfaz tun del servidor.
Creo el fichero /etc/openvpn/server.conf con la siguiente configuración:
Código: text
Como véis, todas las comunicaciones entre ambos puntos irán cifradas y se realizarán sobre el puerto 23/TCP, ya que el telnet está permitido en el firewall interno el cual dejará "fluir" el tráfico del túnel como si nada...
No olvidemos que es necesario habilitar en el servidor el reenvío de paquetes:
Código: text
Ni tampoco que tengo que enmascarar mi dirección IP para habilitar el tráfico de vuelta porque las redes a las que accederé no tienen porque conocer la ruta de vuelta si uso mi IP privada real. Y bueno, me da cierto anonimato:
Código: text
Por último, sólo activaré el túnel bajo demanda por lo que elimino todos los scripts de inicio:
Código: text
Y con esto he finalizado la configuración del servidor. Podré levantar el servicio OpenVPN con el comando 'openvpn --config /etc/openvpn/server.conf &' o crearme un cutre-script como el siguiente:
Código: text
Como veis al levantar el túnel lo hará también el dispositivo virtual:
Código: text
Ahora sólo me queda configurar el cliente OpenVPN de mi portátil. Para ello creo el fichero pivoting.ovpn en C:\Program Files (x86)\OpenVPN\config con la siguiente configuración:
Código: text
Fijaros que añado un DNS a mi elección y la ruta de la red de servidores (192.168.3.0/24) para que mi cliente Windows encamine correctamente los paquetes.
Para terminar compruebo que llego al interfaz virtual del tunel y a un equipo de la VLAN de servidores:
Código: text
¡Y ya está! Ya estoy pivotando a través del servidor de monitorización mediante el túnel VPN.
Tened en cuenta que el servidor de este ejemplo lo gestiono lícitamente. Si comprometemos un servidor, obtenemos acceso como root y queremos utilizar openvpn para vpn pivoting, habrá que pensar también en utilizar algún rootkit u otras técnicas para ocultar al menos el interfaz virtual y el proceso.
Saludos.
FUENTE: hack players
- Proxy pivoting: se canaliza el tráfico a través de un payload en el equipo mediante el cual pivotaremos. Se limita a determinados puertos TCP y UDP.
- VPN pivoting: consiste en crear un túnel cifrado contra el equipo mediante el cual pivotaremos para enrutar todo el tráfico de red, por ejemplo para ejecutar un escaneo de vulnerabilidades a otros equipos de su red o de otras redes a las que tiene acceso.
En mi caso, por versatilidad, necesito esta última técnica. Podría utilizar la versión Pro de Metasploit o Cobalt Strike que son herramientas excelentes para VPN pivoting, aunque también lo son de pago, así que según está la economía me decanto por OpenVPN.
Os planteo el siguiente escenario:

Imaginad una topología con un servidor de monitorización con Nagios en la DMZ el cual, por su naturaleza, tiene habilitado además accesos a otros segmentos de red. Tengo el usuario root y ya accedo a la consola por SSH. Además, el firewall interno me permite acceder a otros puertos del servidor.
Si realizo un escaneo desde mi portátil obtengo los siguientes resultados:
Nmap scan report for 192.168.2.50
Host is up (0.00s latency).
Not shown: 991 filtered ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp closed telnet
80/tcp open http
113/tcp closed ident
161/tcp closed snmp
1060/tcp open polestar
2869/tcp open icslap
8080/tcp open http-proxy
8100/tcp open xprint-serverPodría montar un túnel directamente sobre ssh, pero resultaría muy fácil meter la pata y perder la conexión con el servidor remoto, y no me gustaría tener que llamar al administrador de sistemas varias veces para que me reinicie el servidor ¬_¬ ... Así que utilizaré otro puerto abierto, por ejemplo el del telnet (por qué coño está abierto el puerto del telnet?).
Empezaré instalando OpenVPN. El servidor es Ubuntu así que esto es bastante trivial:
sudo apt-get install openvpnOpenVPN tiene dos modos de funcionamiento, uno basado en claves estáticas pre-compartidas y otro en SSL/TLS usando certificados y claves RSA. Aunque no tan seguro, usaré el primero por simplicidad. A continuación, genero la clave privada:
openvpn --genkey --secret secret.keyEsta clave es simétrica, por lo que la tiene que tener tanto el servidor como el cliente, con lo cual, después de generarla la copiaré a mi portátil mediante SCP (con WinSCP puesto que mi SO es Windows 7) y la protegeré como oro en paño... por que no hace falta que os diga qué pasaría si un tercero se hiciera con ella...no?
El objetivo entonces es crear un túnel VPN punto a punto que se establecerá entre los interfaces virtuales (tun0) del servidor y mi portátil con una IP privada a cada extremo: 10.8.0.1 en el endpoint del servidor y 10.8.0.2 en el endpoint del cliente. Con el modo p2p (predeterminado) se establece una topología punto-a-punto en donde la dirección IP virtual del peer remoto de la interfaz tun del cliente siempre apunta a la dirección IP virtual local de la interfaz tun del servidor.
Creo el fichero /etc/openvpn/server.conf con la siguiente configuración:
mode p2p
dev tun
port 23
proto tcp-server
ifconfig 10.8.0.1 10.8.0.2
secret secret.key
;user nobody
;group nobody
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
comp-lzoComo véis, todas las comunicaciones entre ambos puntos irán cifradas y se realizarán sobre el puerto 23/TCP, ya que el telnet está permitido en el firewall interno el cual dejará "fluir" el tráfico del túnel como si nada...
No olvidemos que es necesario habilitar en el servidor el reenvío de paquetes:
echo 1 > /proc/sys/net/ipv4/ip_forwardNi tampoco que tengo que enmascarar mi dirección IP para habilitar el tráfico de vuelta porque las redes a las que accederé no tienen porque conocer la ruta de vuelta si uso mi IP privada real. Y bueno, me da cierto anonimato:
iptables -t nat -A POSTROUTING -s 10.8.0.2 -o eth0 -j MASQUERADEPor último, sólo activaré el túnel bajo demanda por lo que elimino todos los scripts de inicio:
update-rc.d -f openvpn removeY con esto he finalizado la configuración del servidor. Podré levantar el servicio OpenVPN con el comando 'openvpn --config /etc/openvpn/server.conf &' o crearme un cutre-script como el siguiente:
#! /bin/sh
case "$1" in
start)
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward
/usr/sbin/openvpn --config /etc/openvpn/server.conf &
/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.2 -o eth0 -j MASQUERADE
;;
stop)
/bin/echo 0 > /proc/sys/net/ipv4/ip_forward
/usr/bin/killall openvpn
/sbin/iptables -t nat -F
/sbin/iptables -t nat -X
;;
*)
echo "Uso: ovpn|start|stop"
exit 1
;;
esacComo veis al levantar el túnel lo hará también el dispositivo virtual:
ps -ef | grep openvpn
root 5976 1 0 12:39 ? 00:00:01 /usr/sbin/openvpn --config /etc/openvpn/server.conf
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:9523 errors:0 dropped:0 overruns:0 frame:0
TX packets:10414 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1156752 (1.1 MB) TX bytes:4833017 (4.8 MB)Ahora sólo me queda configurar el cliente OpenVPN de mi portátil. Para ello creo el fichero pivoting.ovpn en C:\Program Files (x86)\OpenVPN\config con la siguiente configuración:
mode p2p
remote 192.168.2.50
dev tun
port 23
proto tcp-client
ifconfig 10.8.0.2 10.8.0.1
secret "C:\\Program Files (x86)\\OpenVPN\\config\\secret.key"
comp-lzo
dhcp-option DNS 192.168.2.36
route-metric 15
route 192.168.3.0 255.255.255.0 10.8.0.1
verb Fijaros que añado un DNS a mi elección y la ruta de la red de servidores (192.168.3.0/24) para que mi cliente Windows encamine correctamente los paquetes.
Para terminar compruebo que llego al interfaz virtual del tunel y a un equipo de la VLAN de servidores:
C:\Users\vmotos>ping -n 1 10.8.0.1
Haciendo ping a 10.8.0.1 con 32 bytes de datos:
Respuesta desde 10.8.0.1: bytes=32 tiempo=1ms TTL=64
Estadísticas de ping para 10.8.0.1:
Paquetes: enviados = 1, recibidos = 1, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 1ms, Máximo = 1ms, Media = 1ms
C:\Users\vmotos>tracert 192.168.3.12
Traza a 10.20.16.12 sobre caminos de 30 saltos como máximo.
1 1 ms 1 ms 1 ms SERVIDOR [10.8.0.1]
2 6 ms 2 ms 2 ms 192.168.2.1
3 2 ms 2 ms 2 ms 192.168.3.12
Traza completa.¡Y ya está! Ya estoy pivotando a través del servidor de monitorización mediante el túnel VPN.
Tened en cuenta que el servidor de este ejemplo lo gestiono lícitamente. Si comprometemos un servidor, obtenemos acceso como root y queremos utilizar openvpn para vpn pivoting, habrá que pensar también en utilizar algún rootkit u otras técnicas para ocultar al menos el interfaz virtual y el proceso.
Saludos.
FUENTE: hack players
#318
Dudas y pedidos generales / Re:Sobrecalentamiento de Ubuntu
Abril 17, 2013, 08:01:14 PM
Entonces se descarta q sea un pc con requisitos bajos... Para mí es lo q dice Antrax!!
#319
Dudas y pedidos generales / Re:Sobrecalentamiento de Ubuntu
Abril 17, 2013, 11:02:54 AM
Solo se sobrecalienta cuando utilizas ubuntu?? q otro s.o tienes instalado? Déjanos características de tu pc para ser más precisos!!
Saludos
Saludos
#320
Off Topic / Re:Gif muy bueno sobre Firewall de windows xD
Abril 16, 2013, 08:33:44 PM
Es cojonudo!! XD

