Portada
mis comunidades
otras secciones
#1:
es un fallo muy grave. Actualicen lo antes posible.
sudo apt-get upgrade
Oh wait!
sudo apt-get upgrade
Oh wait!
#112:
Voy a intentar explicar un poco en que consiste este fallo, en parte traduciendo al español y en parte usando los conocimientos que tengo del tema. Creo que es mucho más facil si abordamos esto en la dirección contraria a como lo explica el artículo (desde el final al principio)
En windows existe una tecnología llamada SMB, que entre otras cosas se utiliza para las carpetas compartidas. Una de las opciones que te da NTLM es poder crear una shell (hay un programa de windows internals llamado psexec que hace esto). Para conseguir esta shell necesitamos poder suministrar unas credenciales, y para eso usaremos un sistema llamado NTLM. NTLM es un protocolo de desafío/respuesta, es decir, que cuando queremos autenticar, el servidor (en este caso el servicio SMB local de la máquina) nos va a hacer una pregunta y tenemos que darle una respuesta que solo es posible calcular conociendo la contraseña. Por lo tanto, podemos abrir una shell con permisos si:
- Obtenemos la contraseña del administrador local o de la cuenta de sistema (una cuenta con aun más privilegios que administrador que usa windows)
- Podemos convencer a alguien que conoce la contraseña que nos de la respuesta al desafío
La primera opción no es factible, pero la segunda si que lo es. De hecho hay algunas limitaciones de seguridad para que no puedas hacer esto en ciertos escenarios, pero el que cubren en este ataque sigue abierto
Como convencemos a alguien para que nos de esa respuesta? Lo más sencillo es coger una petición lícita por parte del sistema que normalmente no pide autenticación y hacerle creer que si la esta pidiendo. Si le damos el mismo desafío que SMB nos esta pidiendo, la respuesta que obtenemos debería ser válida para SMB. El sistema hace automáticamente una serie de peticiones, pero las que son más fáciles de alterar son aquellas de tipo HTTP. Esto es porque las peticiones HTTP no es raro que circulen a través de un proxy, un intermediario que recibe las peticiones y da las respuestas (muy común en entornos empresariales donde de esta forma se puede controlar el tráfico HTTP que hacen los clientes). Ahora bien, hay un problema, para cambiar el proxy que utilizan las operaciones del sistema, tienes que ser administrador, pero si de alguna forma conseguimos cambiarlo, podemos hacer que una operación de sistema vaya a nuestro proxy en lugar del proxy real (o sin proxy), y engañarla para que nos de la respuesta al desafío NTLM. Así que ese es el objetivo a partir de ahora. Operaciones de sistema hay muchas, pero en el ejemplo usan cosas como Windows Update o la actualización de Windows Defender (hay alguna más relacionadas con la cryptoApi de Windows que gestiona los certificados, pero la idea es la misma)
Las aplicaciones de windows tienen dos librerías básicas para realizar peticiones HTTP, conocidas como WinHTTP y Wininet. La configuración de WinHTTP (que incluye el proxy) es única para toda la máquina, mientras que la configuración de la Wininet depende de cada usuario. Por lo tanto, una petición hecha por un servicio del sistema tiene dos opciones:
- Utilizar WinHTTP y el perfil general (prácticamente todas las llamadas de sistema en un windows moderno)
- Utilizar Wininet y el perfil de la cuenta de sistema (NT Authority/SYSTEM) (alguna habrá, pero es raro, y probablemente si le pides autenticación, lo negará)
Aquí es donde el equipo que lo ha hecho sabe que funciona, pero parece que no tiene 100% claro por qué, creo que puedo arrojar algo de luz. Cambiar la configuración de proxy de WinHTTP requiere permisos de administrador, así que nada, no es una opción. Una de las cosas curiosas es que los windows modernos tienen un servicio corriendo que copia la configuración de proxy de la Wininet a Winhttp, por lo que al final, si logramos cambiar la configuración de proxy de wininet, cuando ese servicio lo detecte, acabará cambiando la de Winhttp también. Creo que es por la frecuencia con la que se les debe estar haciendo esta copia de configuración por la que a veces les funciona y otras no
Como podemos cambiar el proxy? Hay una opción en Windows que es configurar el proxy automáticamente, muy util en entornos empresariales, porque sin ella tendríamos que configurar el proxy a mano (bueno, a mano no, hay alternativas, pero esta automática esta ahi). Esto significa que cada cierto tiempo que se hace una petición a la Wininet, esta va a intentar localizar un fichero llamado http://wpad/wpad.dat que incluye la configuración del proxy. Básicamente, intenta ver si hay una máquina llamada wpad de la que el ordenador tenga constancia y si esta ahi, le pide los datos del proxy. Hemos avanzado un paso más, si conseguimos convencer a la máquina que existe alguien llamado wpad en la red y que nosotros controlamos (puede ser la misma máquina en la que estamos), podemos decirle que configuración de proxy utilizar.
Como conseguimos esto? Windows va a tratar de localizar wpad de tres formas distintas. Intenta una y si falla, pasa a la siguiente de la lista:
- Que en un fichero especifico de la maquina (el fichero hosts), aparezca el nombre de wpad y una dirección IP. Esto es muy raro, porque lo tendría que haber puesto un administrador. Si este es el caso, no vamos a poder atacar la máquina
- Que un servidor de DNS nos dé la dirección ip de la máquina wpad
- Que preguntando a lo loco a nuestro "vecindario", alguien sepa de esa máquina y nos responda (NBNS)
Alterar el fichero hosts esta fuera de nuestro control, requiere permisos.
Conseguir que el servidor DNS nos responda con el valor que queremos, también, ya que es una máquina distinta de la red
Que alguien de nuestro vecindario (y una vez más, podemos ser nosotros mismos) nos responda diciendo que la máquina existe, es una posibilidad
Por lo tanto, ahora tenemos tres objetivos:
a) Hacer que la búsqueda en el fichero hosts falle
b) Hacer que la petición DNS a wpad falle
c) Hacer que la petición al vecindario NBNS de el valor para wpad que nosotros queremos
Para conseguir a), nuestra única esperanza es que la entrada no este ahi, pero como decíamos, esa entrada no va a estar ahi el 99%
b) Hacer que la petición DNS falle
Aquí pueden pasar dos cosas. Si el servidor DNS local no tiene una entrada para wpad, ya hemos logrado nuestro objetivo. Pero si el servidor tiene una entrada wpad, tenemos que asegurar que la pregunta falle sin tocar el servidor DNS. Para saber como hacer esto, hay que entender un poco como funciona la comunicación. El mejor ejemplo, es que cuando haces una petición de DNS, estas enviando una carta y esperando una respuesta, pero la dirección que pones en el remitente tiene que ser forzosamente un apartado de correos de tu oficina de correos local (que amablemente ofrece el servicio gratis). Lo interesante, es que el número de apartados de correos disponibles en la oficina es limitado. Si "alguien" (como puede ser nuestro programa atacante), ha alquilado todos los apartados de correos disponibles, la Wininet no puede alquilar uno que poner como remitente, cuando esto pasa, se considera que esta opcion falla y pasa a la alternativa, NBNS), así que b) es fácil de conseguir (es la opción que el articulo dicedisableexhaust false. Quizá hubiera sido más claro si la sintaxis fuera enableexhaust true)
Por lo tanto, solo queda c), si logramos que una petición NBNS preguntando por wpad responda lo que nosotros queramos, podemos hacer que el proxy se configure con los valores que queramos, con eso, alterar la petición de una operación del sistema y así conseguir que nos de la respuesta al desafío NTLM que nos lanza SMB.
Bien, para entender como funciona NBNS, digamos que estamos haciendo es gritar a todos los vecinos del barrio "Si alguien conoce a wpad, por favor, que me ponga su dirección en un sobre y la meta en mi buzón". Si el wpad real existe, cuando esto pasa, un puñado de vecinos vendrán y pondrán sobres en el buzón dando su dirección verdadera. La clave aquí es que nuestro programa atacante también puede poner mensajes en ese buzón, por lo que se pone a escribir mensajes a lo loco dicendo que wpad tiene la dirección IP que nos interesa, y no la que ponen los vecinos. Con un poco de suerte, aunque los vecinos estén escribiendo la dirección real de wpad en el buzón, nuestro programa esta poniendo tantos mensajes ahi que los tapa y no son visibles, por lo que cuando Wininet abre el buzón y coge uno, no llega a ver las respuestas reales, solo las falsas que hemos escrito. Hay un pequeño detalle aquí, y es que ese sobre con la dirección de wpad tiene que tener escrito un numero entre 1 y ~65k, pero no importa, porque nuestro programa escribe tantos mensajes tan rápidos que puede escribir uno para cada uno de los 65k números, por lo que objetivo conseguido.
Continuacion en #113
En windows existe una tecnología llamada SMB, que entre otras cosas se utiliza para las carpetas compartidas. Una de las opciones que te da NTLM es poder crear una shell (hay un programa de windows internals llamado psexec que hace esto). Para conseguir esta shell necesitamos poder suministrar unas credenciales, y para eso usaremos un sistema llamado NTLM. NTLM es un protocolo de desafío/respuesta, es decir, que cuando queremos autenticar, el servidor (en este caso el servicio SMB local de la máquina) nos va a hacer una pregunta y tenemos que darle una respuesta que solo es posible calcular conociendo la contraseña. Por lo tanto, podemos abrir una shell con permisos si:
- Obtenemos la contraseña del administrador local o de la cuenta de sistema (una cuenta con aun más privilegios que administrador que usa windows)
- Podemos convencer a alguien que conoce la contraseña que nos de la respuesta al desafío
La primera opción no es factible, pero la segunda si que lo es. De hecho hay algunas limitaciones de seguridad para que no puedas hacer esto en ciertos escenarios, pero el que cubren en este ataque sigue abierto
Como convencemos a alguien para que nos de esa respuesta? Lo más sencillo es coger una petición lícita por parte del sistema que normalmente no pide autenticación y hacerle creer que si la esta pidiendo. Si le damos el mismo desafío que SMB nos esta pidiendo, la respuesta que obtenemos debería ser válida para SMB. El sistema hace automáticamente una serie de peticiones, pero las que son más fáciles de alterar son aquellas de tipo HTTP. Esto es porque las peticiones HTTP no es raro que circulen a través de un proxy, un intermediario que recibe las peticiones y da las respuestas (muy común en entornos empresariales donde de esta forma se puede controlar el tráfico HTTP que hacen los clientes). Ahora bien, hay un problema, para cambiar el proxy que utilizan las operaciones del sistema, tienes que ser administrador, pero si de alguna forma conseguimos cambiarlo, podemos hacer que una operación de sistema vaya a nuestro proxy en lugar del proxy real (o sin proxy), y engañarla para que nos de la respuesta al desafío NTLM. Así que ese es el objetivo a partir de ahora. Operaciones de sistema hay muchas, pero en el ejemplo usan cosas como Windows Update o la actualización de Windows Defender (hay alguna más relacionadas con la cryptoApi de Windows que gestiona los certificados, pero la idea es la misma)
Las aplicaciones de windows tienen dos librerías básicas para realizar peticiones HTTP, conocidas como WinHTTP y Wininet. La configuración de WinHTTP (que incluye el proxy) es única para toda la máquina, mientras que la configuración de la Wininet depende de cada usuario. Por lo tanto, una petición hecha por un servicio del sistema tiene dos opciones:
- Utilizar WinHTTP y el perfil general (prácticamente todas las llamadas de sistema en un windows moderno)
- Utilizar Wininet y el perfil de la cuenta de sistema (NT Authority/SYSTEM) (alguna habrá, pero es raro, y probablemente si le pides autenticación, lo negará)
Aquí es donde el equipo que lo ha hecho sabe que funciona, pero parece que no tiene 100% claro por qué, creo que puedo arrojar algo de luz. Cambiar la configuración de proxy de WinHTTP requiere permisos de administrador, así que nada, no es una opción. Una de las cosas curiosas es que los windows modernos tienen un servicio corriendo que copia la configuración de proxy de la Wininet a Winhttp, por lo que al final, si logramos cambiar la configuración de proxy de wininet, cuando ese servicio lo detecte, acabará cambiando la de Winhttp también. Creo que es por la frecuencia con la que se les debe estar haciendo esta copia de configuración por la que a veces les funciona y otras no
Como podemos cambiar el proxy? Hay una opción en Windows que es configurar el proxy automáticamente, muy util en entornos empresariales, porque sin ella tendríamos que configurar el proxy a mano (bueno, a mano no, hay alternativas, pero esta automática esta ahi). Esto significa que cada cierto tiempo que se hace una petición a la Wininet, esta va a intentar localizar un fichero llamado http://wpad/wpad.dat que incluye la configuración del proxy. Básicamente, intenta ver si hay una máquina llamada wpad de la que el ordenador tenga constancia y si esta ahi, le pide los datos del proxy. Hemos avanzado un paso más, si conseguimos convencer a la máquina que existe alguien llamado wpad en la red y que nosotros controlamos (puede ser la misma máquina en la que estamos), podemos decirle que configuración de proxy utilizar.
Como conseguimos esto? Windows va a tratar de localizar wpad de tres formas distintas. Intenta una y si falla, pasa a la siguiente de la lista:
- Que en un fichero especifico de la maquina (el fichero hosts), aparezca el nombre de wpad y una dirección IP. Esto es muy raro, porque lo tendría que haber puesto un administrador. Si este es el caso, no vamos a poder atacar la máquina
- Que un servidor de DNS nos dé la dirección ip de la máquina wpad
- Que preguntando a lo loco a nuestro "vecindario", alguien sepa de esa máquina y nos responda (NBNS)
Alterar el fichero hosts esta fuera de nuestro control, requiere permisos.
Conseguir que el servidor DNS nos responda con el valor que queremos, también, ya que es una máquina distinta de la red
Que alguien de nuestro vecindario (y una vez más, podemos ser nosotros mismos) nos responda diciendo que la máquina existe, es una posibilidad
Por lo tanto, ahora tenemos tres objetivos:
a) Hacer que la búsqueda en el fichero hosts falle
b) Hacer que la petición DNS a wpad falle
c) Hacer que la petición al vecindario NBNS de el valor para wpad que nosotros queremos
Para conseguir a), nuestra única esperanza es que la entrada no este ahi, pero como decíamos, esa entrada no va a estar ahi el 99%
b) Hacer que la petición DNS falle
Aquí pueden pasar dos cosas. Si el servidor DNS local no tiene una entrada para wpad, ya hemos logrado nuestro objetivo. Pero si el servidor tiene una entrada wpad, tenemos que asegurar que la pregunta falle sin tocar el servidor DNS. Para saber como hacer esto, hay que entender un poco como funciona la comunicación. El mejor ejemplo, es que cuando haces una petición de DNS, estas enviando una carta y esperando una respuesta, pero la dirección que pones en el remitente tiene que ser forzosamente un apartado de correos de tu oficina de correos local (que amablemente ofrece el servicio gratis). Lo interesante, es que el número de apartados de correos disponibles en la oficina es limitado. Si "alguien" (como puede ser nuestro programa atacante), ha alquilado todos los apartados de correos disponibles, la Wininet no puede alquilar uno que poner como remitente, cuando esto pasa, se considera que esta opcion falla y pasa a la alternativa, NBNS), así que b) es fácil de conseguir (es la opción que el articulo dice
Por lo tanto, solo queda c), si logramos que una petición NBNS preguntando por wpad responda lo que nosotros queramos, podemos hacer que el proxy se configure con los valores que queramos, con eso, alterar la petición de una operación del sistema y así conseguir que nos de la respuesta al desafío NTLM que nos lanza SMB.
Bien, para entender como funciona NBNS, digamos que estamos haciendo es gritar a todos los vecinos del barrio "Si alguien conoce a wpad, por favor, que me ponga su dirección en un sobre y la meta en mi buzón". Si el wpad real existe, cuando esto pasa, un puñado de vecinos vendrán y pondrán sobres en el buzón dando su dirección verdadera. La clave aquí es que nuestro programa atacante también puede poner mensajes en ese buzón, por lo que se pone a escribir mensajes a lo loco dicendo que wpad tiene la dirección IP que nos interesa, y no la que ponen los vecinos. Con un poco de suerte, aunque los vecinos estén escribiendo la dirección real de wpad en el buzón, nuestro programa esta poniendo tantos mensajes ahi que los tapa y no son visibles, por lo que cuando Wininet abre el buzón y coge uno, no llega a ver las respuestas reales, solo las falsas que hemos escrito. Hay un pequeño detalle aquí, y es que ese sobre con la dirección de wpad tiene que tener escrito un numero entre 1 y ~65k, pero no importa, porque nuestro programa escribe tantos mensajes tan rápidos que puede escribir uno para cada uno de los 65k números, por lo que objetivo conseguido.
Continuacion en #113
#28:
Por lo que pone ("Privilege Escalation on Windows 7,8,10, Server 2008, Server 2012") los usuarios de Windows XP y los de Vista están a salvo
#114:
Viene de #112
Al final:
Desde el punto de vista del software legitimo que corre en el ordenador
Windows tiene que hacer una comprobación a windows update
Antes de hacer la comprobación, comprueba el proxy
Como no hay un proxy configurado, decide autodetectar uno
Para ello, intenta localizar una máquina llamada wpad:
- En el fichero hosts local no existe, prueba el siguiente método
- No hemos podido preguntar al servidor DNS porque todos los puertos de origen para establecer la comunicación están agotados (que causalidad :))
- Hemos hecho una pregunta al vecindario para ver si alguien conocía a wpad. Ha habido un numero absurdo de respuetas, muchas de ellas con un codigo de mensaje incorrecto, pero hemos cogido uno de los sobres que incluía el codigo correcto y nos han dicho que wpad existe y es 127.0.0.1
El sistema ha llamado al servidor wpad y le ha dicho que todas las peticiones HTTP tienen que pasar por un proxy especifico llamado 127:0.0.1:8080
Hemos lanzado una peticion a 127.0.0.1:8888 solicitándole que en nuestro nombre haga una peticion a update.microsoft.com
Segun el proxy, update.microsoft.com dice que tengo que autenticarme, y que para ello tengo que presentar la respuesta al desafio FHGLMNVN2043H
He cogido mi contraseña y he calculado la respuesta ASHGFLKGHGSLG
La peticion a windows update ha fallado igualmente
Desde el punto de vista del programa atacante:
- He reservado todos los puertos UDP para bloquear las peticiones DNS
- He inundado la maquina de mensajes NBNS diciendo que wpad resuelve a 127.0.0.1
- He escuchado peticiones para el fichero wpad y he respondido diciendo que el proxy es 127.0.0.1:8888
- He escuchado solicitudes de proxy y he esperado una dirigida a windows update:
- He puesto en pausa dicha peticion
- He hecho una llamada SMB solicitando abrir una shell y SMB me ha respondido que me autentique con el desafio FHGLMNVN2043H
- He respondido la peticion de windows update diciendo que tiene que autenticarse y le he mandado dicho desafio
- He cogido la respuesta que me ha dado (ASHGFLKGHGSLG) y se la he mandado a SMB, que la he aceptado
- SMB me ha abierto una shell como System
Preguntas que me hago:
Es factible lo que dicen?
Si, tengo que ver como estan haciendo el 401 que responden con el proxy, ya que en teoría eso debería de ir por HTTP limitando lo que el proxy puede hacer, pero pueden estar dando un 401 a la operacion de CONNECT o un 407 y decir que es el proxy el que pide credenciales. Aun así, tendré que probarlo y confirmar que funciona
Hay workaround?
Si, si hay una entrada para wpad en el fichero hosts, el ataque falla (a menos que apunte a localhost)
Es factible por parte de microsoft reparar esto?
Si, totalmente.
Les basta con evitar que wpad pueda resolverse por NBNS, por ejemplo. O nunca aceptar autenticar contra Windows Update y similares
Podéis coger este tocho (y el previo) y hacer con el lo que os de la gana. Reproducir todo o parte, corregir fallos tecnicos u ortograficos, lo típico
Al final:
Desde el punto de vista del software legitimo que corre en el ordenador
Windows tiene que hacer una comprobación a windows update
Antes de hacer la comprobación, comprueba el proxy
Como no hay un proxy configurado, decide autodetectar uno
Para ello, intenta localizar una máquina llamada wpad:
- En el fichero hosts local no existe, prueba el siguiente método
- No hemos podido preguntar al servidor DNS porque todos los puertos de origen para establecer la comunicación están agotados (que causalidad :))
- Hemos hecho una pregunta al vecindario para ver si alguien conocía a wpad. Ha habido un numero absurdo de respuetas, muchas de ellas con un codigo de mensaje incorrecto, pero hemos cogido uno de los sobres que incluía el codigo correcto y nos han dicho que wpad existe y es 127.0.0.1
El sistema ha llamado al servidor wpad y le ha dicho que todas las peticiones HTTP tienen que pasar por un proxy especifico llamado 127:0.0.1:8080
Hemos lanzado una peticion a 127.0.0.1:8888 solicitándole que en nuestro nombre haga una peticion a update.microsoft.com
Segun el proxy, update.microsoft.com dice que tengo que autenticarme, y que para ello tengo que presentar la respuesta al desafio FHGLMNVN2043H
He cogido mi contraseña y he calculado la respuesta ASHGFLKGHGSLG
La peticion a windows update ha fallado igualmente
Desde el punto de vista del programa atacante:
- He reservado todos los puertos UDP para bloquear las peticiones DNS
- He inundado la maquina de mensajes NBNS diciendo que wpad resuelve a 127.0.0.1
- He escuchado peticiones para el fichero wpad y he respondido diciendo que el proxy es 127.0.0.1:8888
- He escuchado solicitudes de proxy y he esperado una dirigida a windows update:
- He puesto en pausa dicha peticion
- He hecho una llamada SMB solicitando abrir una shell y SMB me ha respondido que me autentique con el desafio FHGLMNVN2043H
- He respondido la peticion de windows update diciendo que tiene que autenticarse y le he mandado dicho desafio
- He cogido la respuesta que me ha dado (ASHGFLKGHGSLG) y se la he mandado a SMB, que la he aceptado
- SMB me ha abierto una shell como System
Preguntas que me hago:
Es factible lo que dicen?
Si, tengo que ver como estan haciendo el 401 que responden con el proxy, ya que en teoría eso debería de ir por HTTP limitando lo que el proxy puede hacer, pero pueden estar dando un 401 a la operacion de CONNECT o un 407 y decir que es el proxy el que pide credenciales. Aun así, tendré que probarlo y confirmar que funciona
Hay workaround?
Si, si hay una entrada para wpad en el fichero hosts, el ataque falla (a menos que apunte a localhost)
Es factible por parte de microsoft reparar esto?
Si, totalmente.
Les basta con evitar que wpad pueda resolverse por NBNS, por ejemplo. O nunca aceptar autenticar contra Windows Update y similares
Podéis coger este tocho (y el previo) y hacer con el lo que os de la gana. Reproducir todo o parte, corregir fallos tecnicos u ortograficos, lo típico
#46:
#40 En las redes profesionales existen máquinas que controlan los accesos de los usuarios con cuentas de red... esto es porque hay carpetas de datos comunes, impresoras, etc... que se usan en función de grupos de seguridad... El Windows que llevan es específico para servidores.
Un tipo de recursos humanos no debe ver las carpetas de contabilidad y viceversa... pero un director puede que sí tenga que poder entrar a todo. Por eso se hace así. Se dan permisos y privilegios a los usuarios.
No es como con un PC en casa que no hay "dominios" ( agrupaciones para hacer la administración de los usuarios y datos ) sino que entras con tu usuario y listo.
Lo que se supone que hace esto es que un usuario se otorga privilegios él mismo saltándose las medidas de seguridad... de forma que un empleado podría llegar a ver o borrar datos en otras máquinas de la red.
Normalmente cuando aparecen fallos así, Microsoft saca una solución inmediata para resolverlo, pero se dice aquí que aun no se ha hecho.
Yo creo que es un poco bulo... pero bueno. Ya veremos en que queda.
Un tipo de recursos humanos no debe ver las carpetas de contabilidad y viceversa... pero un director puede que sí tenga que poder entrar a todo. Por eso se hace así. Se dan permisos y privilegios a los usuarios.
No es como con un PC en casa que no hay "dominios" ( agrupaciones para hacer la administración de los usuarios y datos ) sino que entras con tu usuario y listo.
Lo que se supone que hace esto es que un usuario se otorga privilegios él mismo saltándose las medidas de seguridad... de forma que un empleado podría llegar a ver o borrar datos en otras máquinas de la red.
Normalmente cuando aparecen fallos así, Microsoft saca una solución inmediata para resolverlo, pero se dice aquí que aun no se ha hecho.
Yo creo que es un poco bulo... pero bueno. Ya veremos en que queda.
#2:
Cagada nivel maestro.
Para evitar problemas yo he borrado todos los usuarios del AD.
Para evitar problemas yo he borrado todos los usuarios del AD.
#34:
#24 Me da que no. Por lo que leo en el articulo esta vulnerabilidad se explota en 7, 8,10 server 2008 y 2012.
Aquí un enlace al blog donde lo explican y donde se ven los vídeos que para hacer el ataque.
http://foxglovesecurity.com/2016/01/16/hot-potato/
Aquí un enlace al blog donde lo explican y donde se ven los vídeos que para hacer el ataque.
http://foxglovesecurity.com/2016/01/16/hot-potato/
#105:
#43 el problema es que actualizar en Windows es jugársela a que se estropee cualquier otra cosa. Sin ir más lejos, esta mañana en mi trabajo se ha actualizado el servidor de SharePoint Foundation y como el SQL Server del que tira el SharePoint no se ha actualizado con la misma actualización... Pues ha dejado de funcionar, con dos cojones 😂 😂
#7:
#3 #4 https://en.wikipedia.org/wiki/Active_directory
En realidad es una reimplementación del clásico LDAP de *nix.
En realidad es una reimplementación del clásico LDAP de *nix.
#66:
El día que vea uno de mis lusers escalando privilegios me voy a emocionar y todo, lo mas que saben es hacer doble click en todos los enlaces de internet.
#79:
Para explotar cualquiera de los tres ejemplos se requiere poder ejecutar codigo arbitrario en la maquina. Si tienes acceso a una maquina y puedes ejecutar codigo descargado es que algo no está bien configurado y ya da lo mismo si usas un sistema retorcido como estos o el comando "at"(programador de tareas) de toda la vida para escalar privilegios.
Comentarios
es un fallo muy grave. Actualicen lo antes posible.
sudo apt-get upgrade
Oh wait!
#43 utilizo Windows pero soy una putita del karma
#8 Más peligroso es que sólo se enteren unos pocos
Por lo que pone ("Privilege Escalation on Windows 7,8,10, Server 2008, Server 2012") los usuarios de Windows XP y los de Vista están a salvo
#48 y di "El servidor se ha caido"
Cagada nivel maestro.
Para evitar problemas yo he borrado todos los usuarios del AD.
Voy a intentar explicar un poco en que consiste este fallo, en parte traduciendo al español y en parte usando los conocimientos que tengo del tema. Creo que es mucho más facil si abordamos esto en la dirección contraria a como lo explica el artículo (desde el final al principio)
En windows existe una tecnología llamada SMB, que entre otras cosas se utiliza para las carpetas compartidas. Una de las opciones que te da NTLM es poder crear una shell (hay un programa de windows internals llamado psexec que hace esto). Para conseguir esta shell necesitamos poder suministrar unas credenciales, y para eso usaremos un sistema llamado NTLM. NTLM es un protocolo de desafío/respuesta, es decir, que cuando queremos autenticar, el servidor (en este caso el servicio SMB local de la máquina) nos va a hacer una pregunta y tenemos que darle una respuesta que solo es posible calcular conociendo la contraseña. Por lo tanto, podemos abrir una shell con permisos si:
- Obtenemos la contraseña del administrador local o de la cuenta de sistema (una cuenta con aun más privilegios que administrador que usa windows)
- Podemos convencer a alguien que conoce la contraseña que nos de la respuesta al desafío
La primera opción no es factible, pero la segunda si que lo es. De hecho hay algunas limitaciones de seguridad para que no puedas hacer esto en ciertos escenarios, pero el que cubren en este ataque sigue abierto
Como convencemos a alguien para que nos de esa respuesta? Lo más sencillo es coger una petición lícita por parte del sistema que normalmente no pide autenticación y hacerle creer que si la esta pidiendo. Si le damos el mismo desafío que SMB nos esta pidiendo, la respuesta que obtenemos debería ser válida para SMB. El sistema hace automáticamente una serie de peticiones, pero las que son más fáciles de alterar son aquellas de tipo HTTP. Esto es porque las peticiones HTTP no es raro que circulen a través de un proxy, un intermediario que recibe las peticiones y da las respuestas (muy común en entornos empresariales donde de esta forma se puede controlar el tráfico HTTP que hacen los clientes). Ahora bien, hay un problema, para cambiar el proxy que utilizan las operaciones del sistema, tienes que ser administrador, pero si de alguna forma conseguimos cambiarlo, podemos hacer que una operación de sistema vaya a nuestro proxy en lugar del proxy real (o sin proxy), y engañarla para que nos de la respuesta al desafío NTLM. Así que ese es el objetivo a partir de ahora. Operaciones de sistema hay muchas, pero en el ejemplo usan cosas como Windows Update o la actualización de Windows Defender (hay alguna más relacionadas con la cryptoApi de Windows que gestiona los certificados, pero la idea es la misma)
Las aplicaciones de windows tienen dos librerías básicas para realizar peticiones HTTP, conocidas como WinHTTP y Wininet. La configuración de WinHTTP (que incluye el proxy) es única para toda la máquina, mientras que la configuración de la Wininet depende de cada usuario. Por lo tanto, una petición hecha por un servicio del sistema tiene dos opciones:
- Utilizar WinHTTP y el perfil general (prácticamente todas las llamadas de sistema en un windows moderno)
- Utilizar Wininet y el perfil de la cuenta de sistema (NT Authority/SYSTEM) (alguna habrá, pero es raro, y probablemente si le pides autenticación, lo negará)
Aquí es donde el equipo que lo ha hecho sabe que funciona, pero parece que no tiene 100% claro por qué, creo que puedo arrojar algo de luz. Cambiar la configuración de proxy de WinHTTP requiere permisos de administrador, así que nada, no es una opción. Una de las cosas curiosas es que los windows modernos tienen un servicio corriendo que copia la configuración de proxy de la Wininet a Winhttp, por lo que al final, si logramos cambiar la configuración de proxy de wininet, cuando ese servicio lo detecte, acabará cambiando la de Winhttp también. Creo que es por la frecuencia con la que se les debe estar haciendo esta copia de configuración por la que a veces les funciona y otras no
Como podemos cambiar el proxy? Hay una opción en Windows que es configurar el proxy automáticamente, muy util en entornos empresariales, porque sin ella tendríamos que configurar el proxy a mano (bueno, a mano no, hay alternativas, pero esta automática esta ahi). Esto significa que cada cierto tiempo que se hace una petición a la Wininet, esta va a intentar localizar un fichero llamado http://wpad/wpad.dat que incluye la configuración del proxy. Básicamente, intenta ver si hay una máquina llamada wpad de la que el ordenador tenga constancia y si esta ahi, le pide los datos del proxy. Hemos avanzado un paso más, si conseguimos convencer a la máquina que existe alguien llamado wpad en la red y que nosotros controlamos (puede ser la misma máquina en la que estamos), podemos decirle que configuración de proxy utilizar.
Como conseguimos esto? Windows va a tratar de localizar wpad de tres formas distintas. Intenta una y si falla, pasa a la siguiente de la lista:
- Que en un fichero especifico de la maquina (el fichero hosts), aparezca el nombre de wpad y una dirección IP. Esto es muy raro, porque lo tendría que haber puesto un administrador. Si este es el caso, no vamos a poder atacar la máquina
- Que un servidor de DNS nos dé la dirección ip de la máquina wpad
- Que preguntando a lo loco a nuestro "vecindario", alguien sepa de esa máquina y nos responda (NBNS)
Alterar el fichero hosts esta fuera de nuestro control, requiere permisos.
Conseguir que el servidor DNS nos responda con el valor que queremos, también, ya que es una máquina distinta de la red
Que alguien de nuestro vecindario (y una vez más, podemos ser nosotros mismos) nos responda diciendo que la máquina existe, es una posibilidad
Por lo tanto, ahora tenemos tres objetivos:
a) Hacer que la búsqueda en el fichero hosts falle
b) Hacer que la petición DNS a wpad falle
c) Hacer que la petición al vecindario NBNS de el valor para wpad que nosotros queremos
Para conseguir a), nuestra única esperanza es que la entrada no este ahi, pero como decíamos, esa entrada no va a estar ahi el 99%
b) Hacer que la petición DNS falle
Aquí pueden pasar dos cosas. Si el servidor DNS local no tiene una entrada para wpad, ya hemos logrado nuestro objetivo. Pero si el servidor tiene una entrada wpad, tenemos que asegurar que la pregunta falle sin tocar el servidor DNS. Para saber como hacer esto, hay que entender un poco como funciona la comunicación. El mejor ejemplo, es que cuando haces una petición de DNS, estas enviando una carta y esperando una respuesta, pero la dirección que pones en el remitente tiene que ser forzosamente un apartado de correos de tu oficina de correos local (que amablemente ofrece el servicio gratis). Lo interesante, es que el número de apartados de correos disponibles en la oficina es limitado. Si "alguien" (como puede ser nuestro programa atacante), ha alquilado todos los apartados de correos disponibles, la Wininet no puede alquilar uno que poner como remitente, cuando esto pasa, se considera que esta opcion falla y pasa a la alternativa, NBNS), así que b) es fácil de conseguir (es la opción que el articulo dice
disableexhaust false. Quizá hubiera sido más claro si la sintaxis fueraenableexhaust true)Por lo tanto, solo queda c), si logramos que una petición NBNS preguntando por wpad responda lo que nosotros queramos, podemos hacer que el proxy se configure con los valores que queramos, con eso, alterar la petición de una operación del sistema y así conseguir que nos de la respuesta al desafío NTLM que nos lanza SMB.
Bien, para entender como funciona NBNS, digamos que estamos haciendo es gritar a todos los vecinos del barrio "Si alguien conoce a wpad, por favor, que me ponga su dirección en un sobre y la meta en mi buzón". Si el wpad real existe, cuando esto pasa, un puñado de vecinos vendrán y pondrán sobres en el buzón dando su dirección verdadera. La clave aquí es que nuestro programa atacante también puede poner mensajes en ese buzón, por lo que se pone a escribir mensajes a lo loco dicendo que wpad tiene la dirección IP que nos interesa, y no la que ponen los vecinos. Con un poco de suerte, aunque los vecinos estén escribiendo la dirección real de wpad en el buzón, nuestro programa esta poniendo tantos mensajes ahi que los tapa y no son visibles, por lo que cuando Wininet abre el buzón y coge uno, no llega a ver las respuestas reales, solo las falsas que hemos escrito. Hay un pequeño detalle aquí, y es que ese sobre con la dirección de wpad tiene que tener escrito un numero entre 1 y ~65k, pero no importa, porque nuestro programa escribe tantos mensajes tan rápidos que puede escribir uno para cada uno de los 65k números, por lo que objetivo conseguido.
Continuacion en #113
#8 https://es.wikipedia.org/wiki/Seguridad_por_oscuridad
Suena divertido... si no fuera porque yo sí que administro varios AD
#3 #4 https://en.wikipedia.org/wiki/Active_directory
En realidad es una reimplementación del clásico LDAP de *nix.
#1 Eso será sí existe el parche, claro. Porque si no está es igual de inutil hacer esto en sistemas Windows que en Linux. Sí está disponible enl parche es más fácil e igual de rápido en Windows. No desaprovechais una para hacer proselitismo...
#24 Me da que no. Por lo que leo en el articulo esta vulnerabilidad se explota en 7, 8,10 server 2008 y 2012.
Aquí un enlace al blog donde lo explican y donde se ven los vídeos que para hacer el ataque.
http://foxglovesecurity.com/2016/01/16/hot-potato/
#40 En las redes profesionales existen máquinas que controlan los accesos de los usuarios con cuentas de red... esto es porque hay carpetas de datos comunes, impresoras, etc... que se usan en función de grupos de seguridad... El Windows que llevan es específico para servidores.
Un tipo de recursos humanos no debe ver las carpetas de contabilidad y viceversa... pero un director puede que sí tenga que poder entrar a todo. Por eso se hace así. Se dan permisos y privilegios a los usuarios.
No es como con un PC en casa que no hay "dominios" ( agrupaciones para hacer la administración de los usuarios y datos ) sino que entras con tu usuario y listo.
Lo que se supone que hace esto es que un usuario se otorga privilegios él mismo saltándose las medidas de seguridad... de forma que un empleado podría llegar a ver o borrar datos en otras máquinas de la red.
Normalmente cuando aparecen fallos así, Microsoft saca una solución inmediata para resolverlo, pero se dice aquí que aun no se ha hecho.
Yo creo que es un poco bulo... pero bueno. Ya veremos en que queda.
#4 Un conversor Analógico/Digital
#21 si tiene el original.
¿tiene windows seguridad?
#24 Menos mal que en la banca y la administración, esto no se da.
#3 #4 Active Directory.
Viene de #112
Al final:
Desde el punto de vista del software legitimo que corre en el ordenador
Windows tiene que hacer una comprobación a windows update
Antes de hacer la comprobación, comprueba el proxy
Como no hay un proxy configurado, decide autodetectar uno
Para ello, intenta localizar una máquina llamada wpad:
- En el fichero hosts local no existe, prueba el siguiente método
- No hemos podido preguntar al servidor DNS porque todos los puertos de origen para establecer la comunicación están agotados (que causalidad :))
- Hemos hecho una pregunta al vecindario para ver si alguien conocía a wpad. Ha habido un numero absurdo de respuetas, muchas de ellas con un codigo de mensaje incorrecto, pero hemos cogido uno de los sobres que incluía el codigo correcto y nos han dicho que wpad existe y es 127.0.0.1
El sistema ha llamado al servidor wpad y le ha dicho que todas las peticiones HTTP tienen que pasar por un proxy especifico llamado 127:0.0.1:8080
Hemos lanzado una peticion a 127.0.0.1:8888 solicitándole que en nuestro nombre haga una peticion a update.microsoft.com
Segun el proxy, update.microsoft.com dice que tengo que autenticarme, y que para ello tengo que presentar la respuesta al desafio FHGLMNVN2043H
He cogido mi contraseña y he calculado la respuesta ASHGFLKGHGSLG
La peticion a windows update ha fallado igualmente
Desde el punto de vista del programa atacante:
- He reservado todos los puertos UDP para bloquear las peticiones DNS
- He inundado la maquina de mensajes NBNS diciendo que wpad resuelve a 127.0.0.1
- He escuchado peticiones para el fichero wpad y he respondido diciendo que el proxy es 127.0.0.1:8888
- He escuchado solicitudes de proxy y he esperado una dirigida a windows update:
- He puesto en pausa dicha peticion
- He hecho una llamada SMB solicitando abrir una shell y SMB me ha respondido que me autentique con el desafio FHGLMNVN2043H
- He respondido la peticion de windows update diciendo que tiene que autenticarse y le he mandado dicho desafio
- He cogido la respuesta que me ha dado (ASHGFLKGHGSLG) y se la he mandado a SMB, que la he aceptado
- SMB me ha abierto una shell como System
Preguntas que me hago:
Es factible lo que dicen?
Si, tengo que ver como estan haciendo el 401 que responden con el proxy, ya que en teoría eso debería de ir por HTTP limitando lo que el proxy puede hacer, pero pueden estar dando un 401 a la operacion de CONNECT o un 407 y decir que es el proxy el que pide credenciales. Aun así, tendré que probarlo y confirmar que funciona
Hay workaround?
Si, si hay una entrada para wpad en el fichero hosts, el ataque falla (a menos que apunte a localhost)
Es factible por parte de microsoft reparar esto?
Si, totalmente.
Les basta con evitar que wpad pueda resolverse por NBNS, por ejemplo. O nunca aceptar autenticar contra Windows Update y similares
Podéis coger este tocho (y el previo) y hacer con el lo que os de la gana. Reproducir todo o parte, corregir fallos tecnicos u ortograficos, lo típico
#2 Desinstala "potato.exe" y arreglado.
#2 mejor borra Windows
#2 Borra todos los ficheros de árbol de directorios. Así te arriesgas aún menos
#2 Mejor tira el servidor por la ventana, desde un quinto piso como mínimo a poder ser.
El día que vea uno de mis lusers escalando privilegios me voy a emocionar y todo, lo mas que saben es hacer doble click en todos los enlaces de internet.
#10 Te vas a tener que mirar los permisos de todos los luser todos los días
que es un AD?
Que es un AD?
#8 Es una patata caliente
#39 Antes de Dcristo.
Hijnorantes...
#2 Mejor borra todo el árbol, así no te arriesgas.
Por lo que he leído, en un paso se ataca el protocp ntlm, que es un protocolo de seguridad de windows anticuado, obsoleto y deshabilitado por defecto en las versiones modernas de windows y samba.
Entiendo que para que el ataque sea posible es necesario tener un windows 2000 server o la seguridad de la red "relajada" admitiendo protocolos antiguos inseguros por compatibilidad con equipos con SO viejos.
Vamos, que no me quita el sueño.
#15 Cualquiera con pulgares oponibles (y alguno sin ellos) puede saltarse la seguridad de windows
#16 No, pero ahora cualquier subnormal puede bajarse la solución...compilarla y hacer un interfaz con un botón para que todo cristo se la pase.
#27 Las cosas se hacen bien o no se hacen... bidon de gasolina y mechero.
#3 ¿Active Directory?
#8 pero es un gran paso para el pingüino
#8 Me parece peligroso que no se sepa esto.
#52 Antes del Desayuno. Ya veo que tú te levantas tarde. Viene a ser lo que para ti no existe
#48 Nunca verás un Windows ir más deprisa
#43 el problema es que actualizar en Windows es jugársela a que se estropee cualquier otra cosa. Sin ir más lejos, esta mañana en mi trabajo se ha actualizado el servidor de SharePoint Foundation y como el SQL Server del que tira el SharePoint no se ha actualizado con la misma actualización... Pues ha dejado de funcionar, con dos cojones 😂 😂
#0 Me parece peligroso que esto llegue a portada.
Una traducción de todo esto 📤 estaría muy bien, si puede ser Gracias.
#58 Sí, supongo. AD y X.509 no es más que burocracia informatizada desde IETF
Pero eso se podría simplificar más en un futuro con ACL's y permisos/protocolos más simples. Es una barbaridad la complejidad de los NT, que entiendo que son herencia espiritural de OpenVMS, pero hoy en día no es necesario tal nivel.
Mira los de Apple. Conviertiron un sistema raruno y algo anticuado en un UNIX-like con partes de Next. Y no es tan malo.
No sé como MS no coje un BSD y le mete .Net encima como API, con Win32 como retrocompatiblidad.
Si total, hoy en día puedes virtualizar departamentos enteros y olvidarte de capas de permisos.
#9 2016 va a ser el año de Linux
https://www.meneame.net/search?q="va a ser el año de linux"&w=comments&h=&o=&u=
#54 Porque para una corporación un poco grande es necesario. Si Windows es intocable en empresas grandes es por el Directorio Activo.
Para explotar cualquiera de los tres ejemplos se requiere poder ejecutar codigo arbitrario en la maquina. Si tienes acceso a una maquina y puedes ejecutar codigo descargado es que algo no está bien configurado y ya da lo mismo si usas un sistema retorcido como estos o el comando "at"(programador de tareas) de toda la vida para escalar privilegios.
#10 si intentan ir a por otras maquinas de la red desconecta cualquier maquina que haga un DNS flood, si es por una local si, estas jodio
. Ya saldrá un parche
#1 es lo malo de no saber idiomas
#47: El karma para un meneante es como el bambú para un oso panda.
#51 Así están, que luego no les interesa follar...
No seamos hipócritas. Todos los que usamos Windows somos administradores del sistema. Desde el más experimentado usuario hasta el cuñado que no sabe ni conectar el cable del micro y de los altavoces siguiendo el código de colores.
#38 como el cocido, todo en uno: sopa + carne + verdura
#26 Hmmmm.... algo así como el famoso "rm -rf / mifichero" ?
#79 Y ese es el motivo por el que los usuarios en un dominio no deben ser administradores locales de su máquina, a menos que sea total y absolutamente imprescindible (Aplicación de cuando Franco era corneta). Por suerte hoy día funciona el 99% de lo necesario sin esos privilegios.
#14 Lo peor es que, del que menos te lo esperas, puede llegar a hacerlo. No parece muy complicado.
#16 He visto lusers que sólo saben escribir con dos dedos índice cargarse cosas y luego tener que ir corriendo a por el backup... hay un fallo de seguridad en Windows, pero está en la forma en que fue pensado.
#8 Me imagino a los users sacando las consolas...
#23 Si, Active Directory es LDAP+Kerberos+SMB todo integrado.
Mientras yo, que no soy capaz de conectar dos ordenadores por red sin poner Todos en compartida
#59 Quiere decir que (especialmente) los administradores de sistemas de tu empresa tienen un problema de seguridad.
Cualquier usuario normal puede convertirse en superusuario.
Por ejemplo si un usuario entrase con su usuario en el servidor windows y entonces se convirtiese en usuario "System" que es superusuario, y con eso, la puedes liar buena.
Básicamente, depende de como esté montado, podrías hacerte con el control de todos los equipos con windows en algunas empresas.
#37 "el día del parche", suena a versión matrix del día de la marmota.
#45 Dejémoslo en "putita".
#8 si un sólo admin de windows se entera del problema y corre a curarse en salud ya merece la pena que se sepa.
#53 No,necesitas gafas de realidad virtual y haber hecho el curso de Visual Basic de CSI.
#7 #6 #5 Muchas gracias. Me lo miro
#76 al menos que trabajes en una compañia medianamente grande no, no vas a estar bajo AD, y si estas bajo AD y el administrador es competente y despues de conocer esta noticia revisa permisos y lo has explotado, espero que no te gustase tu trabajo.
#83 Sinceramente.. No me lo he leído.
#97 Diré que yo sólo abrí un GIF o un PDF
#28 De esto si
#45 ¡Ah! El karma... tan aditctivo y necesario...:p
Vulnerabilidades 0-day de 15 años...
El año de windows en tu orto
#28 perdón, te vote negativo por error.
#76 http://www.hackplayers.com/2016/01/escalado-de-privilegios-en-windows-hot-potato.html
#112 Creo que puede ser solventado con algunos pequeños cambios..
Por lo pronto estoy viendo que NBNS es NetBIOS, y eso es algo que se puede cambiar desde políticas de grupo o desde el mismo servidor de DNS. Es algo que hoy en día debería venir de fábrica, yo por lo pronto lo tengo desactivado. Si el spoofing de wpad se lo quieren hacer a otro a través de NBNS yo creo que lo mejor en una red empresarial (aparte de desactivar NetBIOS) es bloquear los puertos NetBIOS a nivel de switch Capa 3 y de firewall.
Así que el primer paso para el hack es solventable a priori (no lo he probado aún, ojo).
También habrá maneras de identificar el exhaustion, e identificarlo como ataque.
Lo siguiente sería detectar que un usuario está ejecutando un servicio de red. Creo que igualmente debe haber opciones de analizar periódicamente los puertos en uso para identificar si alguno se ejecuta en nivel de usuario. Igualmente se puede verificar que el proxy no sea local (nada de localhost, o 127.0.0.X o nada que resuelva a localhost).
Los ataques parece ser que esperan a que algún servicio elevado haga uso del wpad para capturar las credenciales. Puede ser 30 minutos o 1 día, o quién sabe cuánto.
Yo creo que para protegerse lo mejor sería:
-Desactivar todo NETBIOS en toda la red.
-Bloquear NetBIOS en todos los switches y firewall.
-Todos los usuarios (incluidos TI) sin privilegios de admin local.
-Evitar que los usuarios puedan ejectuar código dentro de carpetas de usuario o donde ellos puedan escribir (que además protege contra CryptoLocker), con AppLocker o SRP.
-Tener algún servicio corriendo que detecte cambios en el proxy. Esto también es útil para bloquear UltraSurf.
-Evitar utilizar credenciales de administrador de dominio en máquinas de usuario.
-Buscar algún programa que detecte el uso de puertos por parte de aplicaciones de usuario. Excepto alguna cosa rara y muy particular creo que ningún usuario debería tener puertos de escucha (algo como http://www.codeproject.com/Articles/4298/Getting-active-TCP-UDP-connections-on-a-box ) .
#86 Eh, que casi somos dos.
Pero vamos, leyendo entre líneas y saltándose cincuenta tecnicismos satánicos de esos que murmuran los magos de nivel 90 y se tienen que estudiar todos los días para poder seguir ejecutando sus hechizos...
... me da que esto, lo que viene a decir, es que da igual que estés como usuario o como admin en tu equipo (o sea que por mucho que digan aquí que no pasa nada si no trabajas en una empresa... como que no).
#20 ¿Y reimplementar todas las GPO? Puta locura , no sñe como Windows no manda LDAP y cualquier X.509 al cuerno y lo simplifican un pelín más, como el LDAP de los de Fedora, que no es parco pero no llega al nivel gargantuesco de los NT.
#80 Exacto.
#26 Te refieres al fallo de seguridad que está entre el monitor y la silla?
#32 escribí Línux
#129 tranquilízate hombre, sal un ratito a la calle a que te dé el aire
#66 No son los monos tontos los que te joden el percal... sino que basta con un único mono listo... y siempre hay listos... Siempre.
Lo malo ya no es que el listo lo haga y le funcione... sino que acabe enseñando a los demás... ahí radica el desastre.
#29 yo no digo na...
https://github.com/foxglovesec/Potato/tree/master/source/Potato/Potato
#149 para nada. Puedes votarme tantas veces negativo como estimes oportuno
#46 Gracias por la aclaración
#95 Me he logueado sólo para votarte positivo
#130 y encima la nes://pre.sso se te jode de buenas a primeras. Y las croquetas quemadas a mí quién me las paga!?
#91 Sabes que si te pillan haciendo algo así no solo es despido inmediato, además puede ser denuncia por lo penal.
Se de sobra que es 100% coña, pero muchas veces la gente piensa que algo que se hace con el ordenador de la empresa no puede ser grave, como copiar datos del servidor con diseños a un pendrive y llevártelos (espionaje industrial, también penal).
#107 ¿El eclipse cuya única dependencia es el java runtime? Si ni siquiera se instala...
#0 ¿Costaba mucho enlazar la fuente original, en lugar de un mísero "tweet" que no contiene ni aporta nada más que un enlace?
#147 ¿Me ves intranquilo? Sólo te he explicado el motivo de mi voto. ¿Quizá eres de esos críos que se ponen chulitos con quien les vota negativo un meneo, pobrete?
#4 También eran las siglas en inglés de una enfermedad, pero no me acuerdo cual.
#112 #114
Vale, lo he estado pensando, y aunque aun no estoy en casa para probarlo, el ataque tiene un fallo
Para poder montar un server que responda al wpad, necesitas escuchar por el puerto 80, pero el firewall de windows te va a bloquear escuchar en ese puerto si no das permiso como admin. No termino de ver como se saltan ese punto, empiezo a sospechar que van de farol
#117 Cuanto más lo pienso, más convencido estoy que el ataque directamente no va a funcionar (especialmente lo de poder escuchar en el 80 sin privilegios para dar la respuesta WPAD)
Hay alguien que lo haya probado y confirme que funciona?
#114 Como se dice por aquí.. Achooooooo!!! menuda expliación 👏 👏 👏 👏
#116 Y yo perdiendo el tiempo, que cabrones
#124 Aunque a estas alturas ya asumo que el ataque es falso, tienes razón que el forzar un wpad en el hosts daría problemas en portatiles que tienen que conectar dentro y fuera de la oficina. A veces no pienso en estas cosas, se nota que nunca me ha tocado trabajar de sysadmin
Aun así, si esto hubiera sido real, un equipo de admins decente se te junta y a las dos horas te tienen seis parches distintos al problema
#91 Pasaomañana estás en el paro
#c-119" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2547576/order/119">#119 Ahora que lo dices creo que es cierto, que te pide permisos de admin para autorizar un puerto de escucha. No me hagas mucho caso porque en mi máquina como tengo C# probablemente lo autoricé la primera vez que desarrollé algo.
Lo de la entrada wpad en el archivo hosts en muchos casos no es viable. Nuestro proxy es no transparente en la oficina, pero fuera no debe ser, por lo que necesitamos una detección automática.
Por cierto, muy buena aportación y muy bien explicado.
No sé si irán de farol, pero esa frase de "Si llevas un AD, reza" se me hace pretenciosa y descalifica todo el mensaje.
Qué cojones rezar, un Sysadmin o un CIO medio cualificado deberían poder presentar un par de opciones viables en poco tiempo (horas o como mucho días).
Si no, la que tiene que rezar es la empresa por tener personal no cualificado para un puesto de responsabilidad (y más hoy en día, con tantos ataques y malware que hay). Me parece más peligroso el Hashcat (y los pass the hash) que éstos.
Un admin local se puede robar las credenciales de un admin de dominio, eso sí es más peligroso.
El ataque en sí me parece muy rebuscado, puede funcionar pero son tantas variables que es fácil que una falle, con defender una de las etapas se evita el ataque.
Y como tú dices puede ser solventado por Microsoft de bastantes maneras.
#119 El exploit funciona perfectamente, al menos en Windows 7. Yo lo he probado y va como la seda. Si no funciona simplemente reinicia para eliminar la configuración WPAD cacheada y prueba de nuevo.
El firewall de Windows no es un problema, la alerta aparece y el firewall bloqueará las conexiones entrantes por la pila de red pero aun así la aplicación estará escuchando en el puerto 80 y el paquete se envía al adaptador "loopback" (127.0.0.1), que se salta la pila de red y por tanto el firewall de Windows.
No creo que sea buena idea bloquear las conexiones TCP al adaptador loopback, ya que este método es usado en algunas implementaciones de IPC (comunicación entre procesos) en las que una aplicación hace de servidor y otra de cliente para intercambiarse datos localmente y si bloqueas esto te dejarán de funcionar algunos programas.
Este exploit está muy elaborado (la explicación de Razhan es estupenda) y creo que no va a ser tan fácil para Microsoft ofrecer una solución a este agujero.
#9 ¿El pingüino tiene una active directory decente?