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!
Cagada nivel maestro.
Para evitar problemas yo he borrado todos los usuarios del AD.
que es un AD?
Que es un AD?
#3 #4 Active Directory.
#3 ¿Active Directory?
#3 #4 https://en.wikipedia.org/wiki/Active_directory
En realidad es una reimplementación del clásico LDAP de *nix.
#0 Me parece peligroso que esto llegue a portada.
#8 pero es un gran paso para el pingüino
Suena divertido... si no fuera porque yo sí que administro varios AD
#8 Es una patata caliente
#8 Más peligroso es que sólo se enteren unos pocos
#7 #6 #5 Muchas gracias. Me lo miro
#10 Te vas a tener que mirar los permisos de todos los luser todos los días
#14 Lo peor es que, del que menos te lo esperas, puede llegar a hacerlo. No parece muy complicado.
#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.
#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
#8 https://es.wikipedia.org/wiki/Seguridad_por_oscuridad
#2 Mejor borra todo el árbol, así no te arriesgas.
#9 ¿El pingüino tiene una active directory decente?
#21 si tiene el original.
¿tiene windows seguridad?
#7 Con algunas cosillas más.
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.
#1 es lo malo de no saber idiomas
#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.
#2 Borra todos los ficheros de árbol de directorios. Así te arriesgas aún menos
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
#2 Desinstala "potato.exe" y arreglado.
#24 Menos mal que en la banca y la administración, esto no se da.
#2 mejor borra Windows
#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=
#28 perdón, te vote negativo por error.
#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/
#24 goto #28
#8 Me imagino a los users sacando las consolas...
#28 De esto si
#23 Si, Active Directory es LDAP+Kerberos+SMB todo integrado.
#4 Un conversor Analógico/Digital
Una traducción de todo esto 📤 estaría muy bien, si puede ser Gracias.
#8 Me parece peligroso que no se sepa esto.
#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.
#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...
Mientras yo, que no soy capaz de conectar dos ordenadores por red sin poner Todos en compartida
#43 utilizo Windows pero soy una putita del karma
#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.
#45 ¡Ah! El karma... tan aditctivo y necesario...:p
#2 Mejor tira el servidor por la ventana, desde un quinto piso como mínimo a poder ser.
#46 Gracias por la aclaración
https://es.wikipedia.org/wiki/Acci%C3%B3n_Democr%C3%A1tica La que está liando Venezuela...
#47: El karma para un meneante es como el bambú para un oso panda.
#39 Antes de Dcristo.
Hijnorantes...
eso se hace con el ratón?
#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.
tantos millones de pago a los ingenieros de microsoft para esto
Vulnerabilidades 0-day de 15 años...
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.
#54 Porque para una corporación un poco grande es necesario. Si Windows es intocable en empresas grandes es por el Directorio Activo.
¿Alguien lo puede traducir al castellano?
#48 Nunca verás un Windows ir más deprisa
#56 vamos, como que linux no ha tenido vulnerabilidades 0-day de 15 (ni de 20 ni de mas años)
Pero de que habláis?
#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.
#53 No,necesitas gafas de realidad virtual y haber hecho el curso de Visual Basic de CSI.
#61 0-day de 15 años = vulnerabilidad conocida desde hace 15 años y no resuelta.
No sé a qué viene lo de Linux, pero si nos ilustras con alguna...
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.
#48 y di "El servidor se ha caido"
#38 como el cocido, todo en uno: sopa + carne + verdura
#27 Las cosas se hacen bien o no se hacen... bidon de gasolina y mechero.
#52 Antes del Desayuno. Ya veo que tú te levantas tarde. Viene a ser lo que para ti no existe
#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.
#65 negativo compensado perdón.
Shellshock, Heartbleed dieron guerra ehh
#49 Entiende por "inmediata" un par de semanas y que no haya pasado ya "el día del parche" https://en.wikipedia.org/wiki/Patch_Tuesday (en inglés) que entonces ya te esperas al mes siguiente.
Aunque bueno, si la cosa es muy grave lo solucionarán "Pronto".
#45 Dejémoslo en "putita".
#4 También eran las siglas en inglés de una enfermedad, pero no me acuerdo cual.
Peroooo, esto traducido al castellano, ¿cómo se dice?
¿Qué es? ¿Un fallo de seguridad? ¿Un fallo que puede ser aprovechado por mí?
#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.
#73 Desde windows 10 ya no hay solo "Patch Tuesday" a parte no seria la primera vez que para bugs gordos sacan fixes fuera de "Patch Tuesday".
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.
#77 Aham, es una forma de conseguir permisos que no deberías tener en un sistema administrado, si no he entendido mal.
Gracias.
#65 #72 No recuerdo ahora el nombre de una vulnerabilidad que encontraron y notificaron los de SUSE y se paso años y años y años sin arreglar.
#80 Exacto.
#71 ¿Tiene algo que ver la notificación de cambios en el sistema en este jaleo?
¿Y no se resolvió precisamente con esto los problemas de entrar en modo "root" y demás zarandajas?
#83 Sinceramente.. No me lo he leído.
#76 Es un fallo de seguridad, y puede ser aprovechado por ti.
No este, sino cualquier noticia de seguridad. Por poder, puedes hacer lo inimaginable. Sé un poco más concreto.
#85 ¿Más concreto que decir que no entiendo una mierda del asunto del que trata el tuit?
The techniques that this exploit uses to gain privilege escalation aren’t new, but the way they are combined is. Microsoft is aware of all of these issues and has been for some time (circa 2000). These are unfortunately hard to fix without breaking backward compatibility and have been leveraged by attackers for over 15 years.
The exploit consists of 3 main parts, all of which are somewhat configurable through command-line switches. Each part corresponds to an already well known attack that has been in use for years:
¿Seguro que esto es noticiable y no es un remix de algún juanker?
Yo no he entendido nada de nada...
#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).
#38 Como lo que hizo Novell con el NDS
Mañana lo pruebo en el curro
#75 ¿Déficit de atención?
#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.
#8 Debes ser de Microsoft tú, no? digo por lo de "seguridad por oscuridad"
El año de windows en tu orto
#26 Hmmmm.... algo así como el famoso "rm -rf / mifichero" ?
#91 Pasaomañana estás en el paro
#24 NTLM sigue activo en todas las versiones de Windows, y no creo que se vaya a desactivar
Windows utiliza dos protocolos de autenticacion generalmente dentro de lo que se conoce como Autenticación Integrada de Windows, NTLM y Kerberos. Kerberos es superior, pero requiere la existencia de una tercera parte en la comunicacion que tanto cliente como servidor confien. Siempre que no se cumple esto (muy a menudo, al final kerberos suele funcionar en redes locales donde haya un AD y se haya configurado correctamente), se hace fallback a NTLM
#76 http://www.hackplayers.com/2016/01/escalado-de-privilegios-en-windows-hot-potato.html
#51 Así están, que luego no les interesa follar...