#3:
Lo mejor de todo es que te muestra el proceso que ha seguido como si fuera un manual guía-burros. Mola
#7:
#2 Lo que explica el fulano es poesía sánscrita para mí.
#14:
balla balla, guardaban archivos en texto plano cuyo nombre era el DNI de los afiliados/usuarios (?), y que contenían todo tipo de información personal de los mismos.
Un 10 a los genios en seguridad que pergeñaron semejante diseño.
#15:
Joder lo de sacar cualquier fichero con el nombre del fichero como parámetro haciendo ../../.,/../, vaya manera de empezar. La típica mierda que ves en los logs y te preguntas para qué lo prueba nadie, con lo borrico que hay que ser para que eso sea vulnerable
PD: Fast-forward de boquiabierto en boquiabierto hasta la clave de root sin cifrar en la base de datos, dios santo...
balla balla, guardaban archivos en texto plano cuyo nombre era el DNI de los afiliados/usuarios (?), y que contenían todo tipo de información personal de los mismos.
Un 10 a los genios en seguridad que pergeñaron semejante diseño.
#14archivos en texto plano cuyo nombre era el DNI de los afiliados/usuarios (?), y que contenían todo tipo de información personal de los mismos.
Si lo he entendido bien, el archivo del que habla cuando comenta lo del texto plano lo ha creado él mismo haciendo un dump de la BBDD. Los archivos con nombre DNI de los afiliados parecen ser imágenes (pero él ha usado ese cargador para subir el suyo manipulado) así que seguramente son DNIs escaneados o similares, cosa que coincide con lo que se ve en las capturas del formulario. Lo que está en texto plano es la contraseña de root en la BBDD. Al hacer un dump de la misma a un fichero es cuando lee su contenido.
No sé, me da que uno de los dos no lo ha entendido bien, porque lo que leo en tu comentario no es para nada lo que he entendido leyendo el artículo...
"Investigando el código del formulario de afiliación he visto que en algún lugar hay un cargador de archivos que almacena las subidas en /usr/paginas/v5.file/cms/ con el DNI del usuario como nombre del archivo."
Esto lo dice mucho antes de hablar de la base de datos.
Lo que no dice el meneo es qué ficheros subían los usuarios. Dice que se pueden subir ficheros como PDF, Word, imágenes... Podría ser cualquier cosa: datos personales o no tan personales... Por ejemplo, si el DNI del usuario era 1234F y se subía una imagen del DNI escaneado pues el fichero guardado en el servidor sería D1234F.jpg o bien algún número detrás, en plan D1234F2.jpg si era el segundo fichero de ese usuario.
Aunque se pueden guardar ficheros en una base de datos, creo que es bastante "normal" / habitual guardarlos en un directorio. Obviamente lo de guardarlos en Base de Datos tiene la ventaja de no poder hacer este tipo de ataque: no está en el filesystem y por tanto no se podría ejecutar algo que subas. Otra ventaja es que si tienes un administrador del Linux no podría ver esos ficheros si no tiene la clave de la base de datos... Pero puede haber alguna desventaja si el programa de la web se hizo de forma descuidada permitiendo consultar la Base de Datos, que pueden ser imágenes muy personales y comprometidas.
Ahora bien, lo de usar el DNI como clave diferenciadora de los ficheros creo que es una mala práctica.
Lo suyo es que las claves primarias no tengan significado (usuario 1, 2, 3) y ese número asignado no sabe el usuario cuál es, no sabe si es el 1337 o el usuario número 5006... Por tanto, el atacante no sabría el nombre del fichero para poder ejecutarlo.
Aunque también es cierto que si la clave primaria es arbitraria y sin significado tampoco debería ir en nombres de fichero... creo que sería mejor usar un hash del DNI o algo así.
El saber el nombre del fichero y la ruta (carpeta) donde se guarda le facilitó escribir el comando que ejecuta ese fichero que ha escrito y subido él.
En cuanto al dump de la Base de Datos, sí es lo que le permitió sacar datos más delicados, como la contraseña de root.
Joder lo de sacar cualquier fichero con el nombre del fichero como parámetro haciendo ../../.,/../, vaya manera de empezar. La típica mierda que ves en los logs y te preguntas para qué lo prueba nadie, con lo borrico que hay que ser para que eso sea vulnerable
PD: Fast-forward de boquiabierto en boquiabierto hasta la clave de root sin cifrar en la base de datos, dios santo...
Nos reímos con las mariscadas pero lo cierto es que son unos indeseables. Tragan del dinero público y de hacerles la pelota a los poderosos. ¿Cómo se puede llamar a esto un sindicato? Es un cáncer más que padecemos Señores.
#24
En este caso puede ser que lo hicieran asi por que no querían pagar mas y punto. Si pagas una mierda, tendrás una mierda.
Al final será amigo o familiar de alguien. Ya veras tu como el que pringa es el menos culpable suponiendo que alguien pringue por esto
#29 Por poder, pueden ser muchas cosas. Pero cagadas como las que menciona el artículo no son fruto de estar mal pagado. Y espérate que el "informático" sea informático...
#17 Hombre... deberían!!!
De todas formas das por sentado que tenían contratado a un informático. Pero más bien parece que tenían a algún cuñado. Y no hablemos del desarrollador... si es que el programador y el administrador son dos personas diferentes.
Yo creo que la web de comisiones obreras (y la de la UGT) entrarían en crisis por el solo hecho de que alguien tratara de afiliarse. Un proceso tan infrecuente es lógico que esté poco testado, y de normal ya te de error.
Comentarios
Lo mejor de todo es que te muestra el proceso que ha seguido como si fuera un manual guía-burros. Mola
#3 ha puesto hasta las contraseñas de algunas bases de datos de ccoo en los pantallazos... imagino eso es para que se aseguren que las cambien
#3 Nunca se deja de aprender. Me ha resultado muy didáctico y te enseña cosas que puedes proteger si estás en situación parecida.
balla balla, guardaban archivos en texto plano cuyo nombre era el DNI de los afiliados/usuarios (?), y que contenían todo tipo de información personal de los mismos.
Un 10 a los genios en seguridad que pergeñaron semejante diseño.
#14 archivos en texto plano cuyo nombre era el DNI de los afiliados/usuarios (?), y que contenían todo tipo de información personal de los mismos.
Si lo he entendido bien, el archivo del que habla cuando comenta lo del texto plano lo ha creado él mismo haciendo un dump de la BBDD. Los archivos con nombre DNI de los afiliados parecen ser imágenes (pero él ha usado ese cargador para subir el suyo manipulado) así que seguramente son DNIs escaneados o similares, cosa que coincide con lo que se ve en las capturas del formulario. Lo que está en texto plano es la contraseña de root en la BBDD. Al hacer un dump de la misma a un fichero es cuando lee su contenido.
No sé, me da que uno de los dos no lo ha entendido bien, porque lo que leo en tu comentario no es para nada lo que he entendido leyendo el artículo...
#27 Tendrás razón. Lo he leído en diagonal para meterle caña a los desarrolladores de esa página...
#28 Yo lo he entendido igual que tú la verdad.
#27
El texto del meneo dice:
"Investigando el código del formulario de afiliación he visto que en algún lugar hay un cargador de archivos que almacena las subidas en /usr/paginas/v5.file/cms/ con el DNI del usuario como nombre del archivo."
Esto lo dice mucho antes de hablar de la base de datos.
Lo que no dice el meneo es qué ficheros subían los usuarios. Dice que se pueden subir ficheros como PDF, Word, imágenes... Podría ser cualquier cosa: datos personales o no tan personales... Por ejemplo, si el DNI del usuario era 1234F y se subía una imagen del DNI escaneado pues el fichero guardado en el servidor sería D1234F.jpg o bien algún número detrás, en plan D1234F2.jpg si era el segundo fichero de ese usuario.
Aunque se pueden guardar ficheros en una base de datos, creo que es bastante "normal" / habitual guardarlos en un directorio. Obviamente lo de guardarlos en Base de Datos tiene la ventaja de no poder hacer este tipo de ataque: no está en el filesystem y por tanto no se podría ejecutar algo que subas. Otra ventaja es que si tienes un administrador del Linux no podría ver esos ficheros si no tiene la clave de la base de datos... Pero puede haber alguna desventaja si el programa de la web se hizo de forma descuidada permitiendo consultar la Base de Datos, que pueden ser imágenes muy personales y comprometidas.
Ahora bien, lo de usar el DNI como clave diferenciadora de los ficheros creo que es una mala práctica.
Lo suyo es que las claves primarias no tengan significado (usuario 1, 2, 3) y ese número asignado no sabe el usuario cuál es, no sabe si es el 1337 o el usuario número 5006... Por tanto, el atacante no sabría el nombre del fichero para poder ejecutarlo.
Aunque también es cierto que si la clave primaria es arbitraria y sin significado tampoco debería ir en nombres de fichero... creo que sería mejor usar un hash del DNI o algo así.
El saber el nombre del fichero y la ruta (carpeta) donde se guarda le facilitó escribir el comando que ejecuta ese fichero que ha escrito y subido él.
En cuanto al dump de la Base de Datos, sí es lo que le permitió sacar datos más delicados, como la contraseña de root.
Cc: #14
Joder lo de sacar cualquier fichero con el nombre del fichero como parámetro haciendo ../../.,/../, vaya manera de empezar. La típica mierda que ves en los logs y te preguntas para qué lo prueba nadie, con lo borrico que hay que ser para que eso sea vulnerable
PD: Fast-forward de boquiabierto en boquiabierto hasta la clave de root sin cifrar en la base de datos, dios santo...
Al principio, ofrecían este pantallazo.
#1 Ahora eres el principal sospechoso.
#2 Lo que explica el fulano es poesía sánscrita para mí.
#7 es como leer un libro de hechizos
#2 Y viendo ese logo...
- Alvise has joined the chat.
CC/ #1
#10 farlopa y ardillas… no me jodas, es Alvise seguro, son aus gustos
#1 Podían haber puesto una gamba.
#1 A ver si la CGT se corta un poco...
#0 arregla esos hashtags porque te lo pueden tumbar
#20 Están los sociópatas seniles despiertos?
#20 No tengo ni idea de como hacerlo, pero gracias por el aviso.
Nos reímos con las mariscadas pero lo cierto es que son unos indeseables. Tragan del dinero público y de hacerles la pelota a los poderosos. ¿Cómo se puede llamar a esto un sindicato? Es un cáncer más que padecemos Señores.
#22 La CGT recibe el mismo dinero publico, son ellos unos indeseables vendidos?
Tampoco se nota mucho la diferencia,con la mierda que era...
#32 Un sindicado con becarios, eso tiene que ser gracioso.
#33 Los tienen, los tienen.
Quién hackea a un marisquero, 100 años de mariscadas
Es un autohackeo, cualquier cosa que les dé excusas para no trabajar.
Pero al final ha conseguido la flag o no?
Alguien ha hackeado a alguien, alguien es un hackeador...
CCOO siempre le da la razón al empresario. Lameculos
Los sindicatos a sueldo del hijoputa.
Edit, parezco idiota
#4 es el mismo enlace del meneo...
#5 Yaya, pensaba que el meneo iba a la web de CCOO. Cosas de no leer los meneos.
#6 Las web de los cocorotos ofrecen ahora este panorama:
Ahora es cuando despiden al informático
#17 Hombre, en este caso...
#24
En este caso puede ser que lo hicieran asi por que no querían pagar mas y punto. Si pagas una mierda, tendrás una mierda.
Al final será amigo o familiar de alguien. Ya veras tu como el que pringa es el menos culpable suponiendo que alguien pringue por esto
#29 Por poder, pueden ser muchas cosas. Pero cagadas como las que menciona el artículo no son fruto de estar mal pagado. Y espérate que el "informático" sea informático...
#17 Al becario, que es el culpable siempre
#17 Pues curiosamente la página de tic funciona https://www.ccoo-servicios.es/tic/
#17 Hombre... deberían!!!
De todas formas das por sentado que tenían contratado a un informático. Pero más bien parece que tenían a algún cuñado. Y no hablemos del desarrollador... si es que el programador y el administrador son dos personas diferentes.
Yo creo que la web de comisiones obreras (y la de la UGT) entrarían en crisis por el solo hecho de que alguien tratara de afiliarse. Un proceso tan infrecuente es lógico que esté poco testado, y de normal ya te de error.
Seguramente todavía no se hayan ni enterado