Buenas! Hace un año o más había probado el linset, y yo recuerdo que mi android una vez que se quedaba sin conexión con la red verdadera, se conectaba automáticamente con la red abierta falsa clonada. Actualmente volví a probar el ataque y mi teléfono una vez que se queda sin conexión con la red auténtica no se conecta al AP falso clonado, y no solo ésto, sino que tampoco se puede conectar al AP falso manualmente, nunca se llega a asociar ni recibir la IP... Me gustaría saber si a ustedes les pasa lo mismo, y si tiene que ver con alguna nueva característica de los Android, del NetworkManager, o de lo que sea. El Android con el que lo estoy probando está en la versión 4.4.4.

Saludos!

Buenas! Quería saber si es buena práctica utilizar paths absolutos de la siguiente forma al incluir distintos archivos, por ejemplo:

require_once($_SERVER['DOCUMENT_ROOT']."/model/ClasePaciente.php");
require_once($_SERVER['DOCUMENT_ROOT']."/model/RepositorioPaciente.php");

Porque tuve muchos problemas al utilizar paths relativos, ya que dependiendo de donde este parado, el archivo se carga o no, entonces vi ésta como posible solución... Tambien intente utilizando:

$root = $_SERVER['DOCUMENT_ROOT'];
require_once($root."/model/ClasePaciente.php");
require_once($root."/model/RepositorioPaciente.php");

para que quede más legible y con menos caracteres, pero tendría que definir esa variable por cada php distinto al que accedo a través de la accion de los formularios html, y me resulta incómodo. Probé definiendo constantes y me encuentro en la misma situación, asi que me parece una solución razonable. Que piensan?

Por otro lado, no es posible que el atacante pueda editar el valor de $_SERVER['DOCUMENT_ROOT'] y lograr vulnerar la aplicación a través de un path traversal por ejemplo?

Saludos y muchas gracias!

Buenas! Probe utilizando la máquina del tiempo y viendo la primera noticia de esa fecha, no sirvió, asi que terminé probando todas las noticias existentes, ingrasanto tanto título, como cuerpo y titulo/cuerpo de todas las formas posibles y no pude superar el reto con ninguna... Será que el snapshot que tiene la maquina del tiempo haya borrado alguna información y el reto ya no se pueda resolver? Alguno que lo haya resuelto y recuerde como lo resolvió, me gustaría que se fijara si todavía puede ser resolvible... :p Gracias!

Buenas, resulta que hace un tiempo había probado ésta herramienta y solo pude hackear Windows 7 x86 sobre Firefox con los pluggins desactualizados (por ejemplo flash). Pero cuando probé instalar la misma versión vulnerable de flash en un windows 7 x64 el exploit no funcionó. También probé Windows 7 x86 con Chrome, misma versión del pluggin, y no hubo caso tampoco... En linux tampoco pude explotar versiones vulnerables de plugins. Entoneces hoy en día que ya java (NPAPI) no es màs utilizado por los navegadores, solo quedaría flash. Y si para explotarlo ademas de que sea una versión vieja, necesitar que la víctima use Firefox y esté en un Windows 7 x86 se hace muy dificil de llevar a cabo. Quería saber si modificando o toqueteando en algún lado los exploits que lanza el browser_autopwn y browser_autopwn2 podría llegar a adaptarlos para SO de x64 y navegadores Chrome o si ya existen pùblicos exploits que afecten a  dichos sistemas y yo esté ignorando.

Muchas gracias y saludos!

Bueno, excelente, muchas gracias BloodSharp! alguna vez creo haber leido exactamente esa definición y en éste caso se acemeja a lo que les marque como "explicacion 2". Pero ahora casualmente estaba leyendo la guía de pruebas de OWASP y miren:



Lo que resalté en amarillo hace referencia al mismo concepto que yo marqué como "explicación 2" y que vos BloodSharp me acabas de citar de la mismisima página de OWASP haciendo referencia al concepto de blind sqli... En éste caso, a ese concepto no lo toman como blind SQL injection, sino como una de las tres clases en las que se dividen los ataques de sqli.

Y en lo que remarqué en rojo se hace referencia a mi "explicación 1", lo cuál en ésta guía de pruebas OWASP lo considera blind SQL injection...

No entiendo como OWASP se contradice, o mezcla las cosas. Tal vez sea un error de traducción.

Buenas! Hay lugares en los que te explican blind SQL injection de una forma y otros en los que te la explican de otra.

Explicación 1:
Blind SQL injection se da cuando el servidor no muestra mensajes de error al hacer una consulta SQL malformada, sin darle información al atacante sobre como podría formar una consulta válida.

Explicación 2:
Blind SQL injection se da cuando los datos consultados en la inyección no son mostrados en la misma web, por lo tanto para comprobar su existencia hacen faltas de pruebas basadas en tiempo, etc, para confirmar según el comportamiento del servidor si un dato existe o no.

Según el tiempo que llevo usando sqlmap, y artículos y cosas que vengo leyendo, para mi lo que más tiene sentido que sea una blind SQL injection es la de la explicación 2. O sea si el servidor simplemetne no muestra información de error no complicaría tanto las cosas. Solo hay que probar varias inyecciones hasta que se muestre los datos que esperamos ver. En el otro caso hay que hacer pruebas muy distintas basadas en tiempo...

Bueno, me gustaría que me ayudaran a despejar ésta duda.

Saludos!

Muchas gracias AlbertoBSD!!! Entonces según lo que me decís aca:


el antivirus no solo se fija en disco, sino que también en la memoria y en el tráfico de red. Yo había leído un artículo que decía que el antivirus no analizaba la memoria, tal vez era un artículo muy viejo y los antivirus viejos no la analizaban y ahora si.

En cuanto a lo primero de los exploits del tipo local, tenes razón! No lo estaba teniendo en cuenta... Si por ejemplo se utilizan las ultimas vulnerabilidades de word o adobe reader pero con un payload ofuscado en un archivo .doc o .pdf, pensás que sería posible evadir el antivirus o igualmente sería detectado de algún otro modo?

Muchas gracias nuevamente!

Saludos!

Buenas, estaba leyendo éste artículo del Chema Alonso:

http://www.elladodelmal.com/2017/09/owasp-zsc-zeroday-cyber-research.html

que muestra una nueva herramienta para crear shellcodes ofuscados para insertarlos en los exploits. Mi duda es por qué un payload necesitaría ser ofuscado? Supuestamente el antivirus no es que solo analizaba el disco? Es decir, que es capaz de detectar archivos maliciosos? Pero en el caso de los exploits, consiguen tomar el control de la pc sin necesidad de ningún archivo, ya que utilizan al proceso vulnerable para ejecutar codigo, yendo directamente a memoria sin tocar el disco. Cómo es que un antivirus podría llegar a detectar una shellcode de un exploit si la misma no está ofuscada?

Gracias y saludos!

Buenas! Puede llegar a generar un problema de privacidad ya que la direccion ipv6 esta formada en base a nuestra direccion fisica. Aca te dejo esto:


https://www.wilderssecurity.com/threads/should-i-disable-ipv6.358189/

Buenas, resulta que mi amplificador Edifier 2.1 empezó a hacer pitidos insoportables muy cortitos cada ciertos segundos mientras estaba conectado a la PC. Luego de hacer varias pruebas notamos que el pitido sonaba en en ampli, sin estar conectado a la PC. Si al ampli le desconectas la salida de audio se escucha el pitido muuy muy bajito desde adentro del ampli. Si conectas los parlantes a la salida ahi suena muy fuerte. Alguna idea? Nunca me paso algo asi.

Saludos!