Hace 3 años | Por eugefu a vozpopuli.com
Publicado hace 3 años por eugefu a vozpopuli.com

La Generalitat de Cataluña ha sufrido una vulnerabilidad informática en al menos tres de sus páginas webs. Al menos 5.000 registros con direcciones de correos electrónicos y contraseñas han estado al descubierto por un fallo de seguridad de tipo SQL Injection, vulnerabilidad que explicaremos más adelante. El servicio de TI de la Generalitat mantiene abierta una investigación para detectar si ha habido robo de datos.

Comentarios

Katsumi

Els hackers ens roben

M

#1 Los idiotas hasta saben escribir.

Katsumi

#83 Ya veo

O

#78 No soy clon de nadie fachi español. La tienes metida muy adentro con Cataluña, solo hace falta ver tus mensajes. Cuando una noticia deja en ridículo a la CAM o Madrid, te escondes en una cueva o votas negativo la noticia. Tu solo sales de la cueva para hablar de Cataluña lol kiss

O

#81 No haces más que decir disparates. Ahora tengo ascendencia extremeña o lo que sea
Y por supuesto seguro que estoy involucrado con la ANC lol

Sigue probando.

Que tengas un buen día, y no tengas pesadillas por la noche con puchi

O

#63 ¿Pero qué clase de trauma tienes con Cataluña? Algún catalán te robó la novia?

Toma, aquí tienes una de tu querida comunidad, de hace menos de un mes: https://www.elconfidencial.com/tecnologia/2020-10-31/comunidad-madrid-brecha-datos-colegios-alumnos-profesores_2809919/

elGude

#5 No sería tan raro. Yo me he encontrado desarrollos donde la contraseña estaba sin cifrar. En pleno 2020.

l

#9 si se entera la agencia de protección de datos de eso te cae un puro que terminan de pagarlo tus nietos

Arcueid

#14 Hace un tiempo denuncié un caso de spam masivo a la AEPD donde se exponían además todos los correos electrónicos.
A lo mejor les pusieron un puro, oye, pero no me informaron del resultado. No sé yo...

thrasher

#23 hace tiempo en la aepd había un buscador de resoluciones, pero como indica #28 hay casos en que no afecta a aapp

Arcueid

#46 Sí, es una opción. O puede que no considerasen relevante. Era una sociedad privada que se lucraba con esos envíos de información, así que me sorprende. Pero puede ser que sea lo que decís.

La denuncia era principalmente por no hacer uso del BCC, pero también por spam no solicitado (nunca me registré en dicho sitio).

p

#14 No en la administración. No se multa a sí misma, o sea que...
Al menos es lo que me contaron en un curso sobre esto en la agencia catalana de protección de datos.

elGude

#14 A mí no, al que lo desarrollo, que a mí me toco arreglarlo.

D

#9 Diselo a Adobe, que le robaron todas las cuentas y ni siquiera tenian una sal

Ramsay_Bolton

#43 que sosos

squanchy

#43 Recuerdo cuando cifré las contraseñas de nuestros clientes y añadí sal. Mi jefe flipó con la técnica, y al rato me vino a decir que le añadiese pimienta. Había estado investigando por google.

johel

#5 si te descuidas y la contrata era indra precarios s.l , podrian estar perfectamente en una excel

M

#5 MD5 es demasiado complicado, un base64 mejor.

D

#84 rot13 hombre.

snowdenknows

#2 pregunta en twitter q las guarda/ban en plano

D

#41 +1 Si fuera SQL Injection las habr'ian reventado hace anhos.

cosmonauta

#45 Exacto. Y les habrían robado toda la base de datos, que probablemente ya estaría publicada en algún sitio

ACEC

#65 Yo he llegado a contar 6 hasta niveles de subcontratación para que al final, el "ingeniero" fuera un chavalito que no sabría ni reinstalar su propio PC

manc0ntr0

#74 Eso lo he visto yo con un ingeniero de Telefónica, nada de subcontratado.
Si te daba mucha lata le pedías que te crease una extensión y lo tenías entretenido para todo el día

D

#65 Eso es el día a día de todo.

KimDeal

#65 itnow que yo sepa no tiene nada con la Generalitat. Y te has dejado a everis, dxc, ticxcat y algunas otras.
Por otra parte, la Gene tiene su empresa con sus ingenieros (el todopoderoso CTTI) pero el problema es que el caos de aplicaciones, lenguajes, frameworks, gestores de bbdd, etc, con permanentes cambios y urgencias, es tan descomunal que aún es raro que no pasen más cosas.

Por lo demás, estoy de acuerdo contigo. Hace falta poner orden urgentemente ahí. Yo estuve trabajando unos años y salí quemadísimo de echar horas extras para corregir desastres funcionales y técnicos de todo tipo.

Duk

#99 tienes razon, me colé, me referia a everis y me confundí, como bien dices, me deje bastantes en el tintero y de las que no sé.

manc0ntr0

#65 Amén.
Aquí un antiguo subcontratado por T-Systems que estuvo currando para la Gene.
Si te digo por ejemplo que si se caía el CPD principal tenía que ir un técnico a Sabadell a levantar a mano el de respaldo seguro que no te parece raro

D

#2 no te llegas ni a imaginar la de empresas que guardan sus contraseñas en texto plano

D

#2 Cambia algo pero tampoco tanto.

Si tienes acceso a la base de datos, que las contraseñas esten encriptadas pueden evitar que alguien las use masivamente para probarlas en otros servicios, pero no que hagan un ataque a una en particular para obtener la real.

Dravot

La República digital.

A

Que una página gubernamental sea sensible a un ataque sql injection a estas alturas del siglo, ya tiene tela. Y si guardaban las contraseñas en texto plano, ya es de premio.

jacktorrance

Qué pinta la foto de Torra?

D

Marca Cataluña España.

S

Inyección SQL en una plataforma que debería estar muy bien protegida... es una de las vulnerabilidades más clásicas comúnmente (aunque no siempre) causada por malas practicas.

Joder__soy_yo

#3 Una inyección de SQL es de principiantes. No hay excusa

bobbelaki

La Generalitat sufre un fallo de ciberseguridad y deja al descubierto miles de correos y contraseñas

Titular aséptico para maquillar lo que realmente se ha hecho.

e

#4 Ein?

ACEC

#30 No son solo son preocupantes las contraseñas, Ensenyament tiene datos personales de todos los niños de Cataluña

frg

Ninguna de las webs reportadas figura como un sistema crítico y, por lo tanto, no contenían datos críticos o sensibles

No se, pero viendo las páginas afectadas me resulta muy raro que no hayan accedido a datos sensibles. Habrá que ver cuando se podían llevar, pero tiene pinta de que han podido hacer un volcado completo de las BBDD afectadas, y seguro que había datos "bonitos" en las mismas.

D

#6 Aunque no sean críticas mucha gente usa siempre la misma contraseña, así que una vez consigues una es cuestión de ir a otra web que sí tenga "información sensible" y probar con esas mismas credenciales.

O

¿Pero quién demonios almacena hoy en día una contraseña en base de datos?

rojo_separatista

#8, eing?

m

#11 Se refiere a que es raro que se almacenen las passwords (como tales directamente) en una bbdd. Es práctica malísima.

rojo_separatista

#18, vale, ya lo entendí, presupongo que hoy no hace esto ni un estudiante de primero de ingeniería informática.

m

#33 Desde luego no debería. Burradas hemos visto todos en todos los sitios.

Arcueid

#33 Uy. Pues no sé cómo andarán ahora los estudiantes de primero de ingeniería de informática, pero yo he visto burradas así en sistemas de producción, en el departamento de informática, hace menos de una década.
Vamos, lo que dice #36. Otra cosa es que sea una salvajada (y hay muchas).

KimDeal

#36 #33 #18 supongo que os referís a guardar la password tal cual, sin hash no? Porque si no es hasheada bbdd o en archivos ocultos encriptados, no conozco más métodos.

marcoschus

#18 pregunta de buena fé
si no se guarda en la BdD.... (Encriptada evidentemente)
donde se guarda?

marcoschus

#73 ah ok, entiendo hash como validación de contraseña
pero algo se debe guardar
entendí que no se guardaba nada (ni el hash)
si es así, entendido
positivo para tí

m

#62 se guarda un md5 o sha de la pass en la bbdd. Pero si te pillan ese hash no sacan la pass.

D

#98 Si que la sacan.

No tan fácil si esta bien hecho y no es un encriptado bidireccional, pero teniendo la hash y la sal, que seguramente también estará en la misma base de datos, y asumiendo que conocen el algoritmo que transforma la clave (que conocerán porque usarán uno conocido) se puede montar un ataque que la obtenga con unos cuantos miles de intentos. Como la hash ya la tienen se ahorran todo el tiempo de establecer conexiones, así que muy fuertes han de ser las contraseñas para decir que no las van a descifrar.

luckyz

#11 lo lógico es almacenar el hash, no la contraseña en si.

rojo_separatista

#25, sí, pero el hash se guarda en una base de datos, no?

luckyz

#31 Claro, pero ese hash solo te sirve para validar si una contraseña es correcta, pero no contiene la contraseña en si. Podrías hacerlo público y no serviría para mucho

rojo_separatista

#38, obviamente. Pero desde que leí la noticia que he dado por sentado que lo que lo que había quedado expuesto eran los hash, no las contraseñas a pelo.

Arcueid

#31 Como indica #38, la idea de usar hashes es la de aplicar conceptos matemáticos que permiten exponer datos en su versión transformada sin que se pueda recuperar la original (entre otros conceptos).

Creo recordar que cuando eso no se implementa correctamente (que haya una relación biyectiva entre dato original y hash) se puede usar para intentar adivinar. Aparte de que haya funciones más o menos "adecuadas" para transformar el dato en hash.

analphabet

#57 Para ser más preciso el concepto de usar hashes no es para impedir que se pueda recuperar la original, sino para provocar que ese proceso de recuperación no sea inmediato en el tiempo, sino que requiera de una capacidad de computo que en el momento en que ese hash no se considera débil sea de cientos sino miles de años.

Arcueid

#92 Cuando dije "exponer datos en su versión transformada sin que se pueda recuperar la original" debería añadir "únicamente a partir de la versión transformada".

Es decir, en el sentido de obtener una "f" tal que f(hash(dato)) = dato. Recuerdo haber estudiado explícitamente que los hashes eran "one-way methods".

Lo cual es ligeramente diferente a decir que no se puede obtener el dato original mediante prueba y error, de modo que hash(prueba) = hash(dato), por lo cual prueba = dato (asumiendo que no hay colisiones y todo eso). En ese caso, sí; claramente las funciones para hacer el "mapping"/hash se adaptan a los tiempos de computación más o menos disponibles en cada época.

En todo caso pregunto: ¿acaso hay manera de revertir el proceso de hash, sólo usando hash(dato) y "deshasheando"?

O

#8 Doy el punto de vista de alguien conocedor que para la gestión de los sistemas de información de las administraciones públicas no lo suelen hacer funcionarios sino un entramado de empresas cárnicas y UTEs que no dudan en contratar o bien becarios o bien gente hasta los cojones de cobrar una miseria.

#11 ¡Tash-Koh-Tah!

L

#8 Das tu punto de vista desde un prisma crítico o conocedor de principios de sistemas. Ahora tienes que ponerte en el punto de vista de un funcionario que se la suda al ser indefinido y va a pasar el rato en el trabajo, y no a trabajar.

m

#13 Pero es que eso no lo hace el funcionario sino quien diseña el programa.

L

#19 Lo he entendido mal entonces tinfoil

luckyz

#13 el que programa no es el funcionario, es la empresa adjudicataria

L

#26 Lo he entendido mal entonces tinfoil

thrasher

#13 me pongo en tu punto de vista y veo la vida muy gris

L

#52 Es que es gris, salvo pequeños destellos de luz.

l

#8 pues hombre, o están en un sistema LDAP o los tienen externalizado via algo como OAuth (que por detrás usará una base de datos o un LDAP), o están en una base de datos.

Salvo que tengas necesidades de SSO, no tiene nada de malo tenerlas en una base de datos, otra cosa es con que hash lo tengas guardado. Un SHA-384 con random salt es muuuuuy jodido de romper

D

#22 a lo que #8 se refiere, es a que NO se debe almacenar nunca una contraseña en texto plano, sino un hash de la contraseña.

El tema funciona a grandes rasgos así: cuando el usuario introduce la contraseña en la pantalla de log in (por ejemplo), se compara el hash almacenado con el hash de la contraseña del usuario. El algoritmo de hashing (debería) ser unidireccional, por lo que un atacante que se hiciese con esos hashes no sería capaz de suplantar a los usuarios afectados.

Eso te vale lo mismo en una base de datos, en LDAP o ficheros de texto. Como en una auditoría te cacen con contraseñas en texto plano, te puede caer un multón de impresión.

editado:
no te había leído bien el segundo párrafo, veo que ya sabías todo eso

l

#47 eehhhhhhmmmm, sí, se de que va eso y se como funciona un algoritmo de hash, pero gracias.

O

#47 Ahí le has dado. Hoy en día no se almacenan contraseñas sino sus resúmenes criptográficos. Esa es la razón por la que en las páginas webs ya no tienen un botón de "recordar contraseña" sino de "generar nueva contraseña". Así, si acceden a la base de datos como mucho pueden robarte el hash y dependiendo del utilizado, no van a poder hacer mucho.

#42 Veo que no entiendes del tema.

keiko_san

#60 wall

D

#47@zetapazzz, a qué viene el negativo?

llorencs

#22 Una cosa no me queda clara, SSO no usa OAuth?

l

#77 un SSO (single sign on) puede usar cualquier protocolo para ello. El de Windows usa el AD y Kerberos.

Se pueden usar cosas como CAS, Kerberos, SAML, OAuth,OpenID...

keiko_san

#8 Mucho mejor en una libreta al lado del servidor

D

#8 Pues todo el mundo.

Hasheada y con una sal. Pero todo el mundo la almacena en la base de datos.

O

#50 No. Cuando le metes el hash de una contraseña no almacenas la contraseña porque los algoritmos hash no son bidireccionales, es decir, no puedes calcular una contraseña a partir de su hash.

keiko_san

#61 ñiñiñiñiñiñi
Ponte lo quisquilloso que quieras pero es exactamente como dice #50

Idomeneo

#50 Hasheada y con una sal

Y si eres Bruce Schneier, con sal y pimienta:

https://www.schneierfacts.com/facts/671

l

#50 es que lo almacenas en la base de datos, pero hasheado. Ambas cosas no son excluyentes

fareway

La contraseña más usada es: "aquelqueantelavozespañaNOgriteunviva-NIeshombreNIesespañol".

rojo_separatista

También sería interesante saber de dónde ha venido el ataque.

Baal

#12 del CNI of course

m

#12 Si es una página web, a los 30 minutos ya lo saben porque el log del servidor marca la ip de origen de cada petición.

rojo_separatista

#24, pero seguramente hayan utilizado un proxy.

m

#35 Se suelen utilizar PCs zombies. Pero si, si han sido un poco hábiles se camuflan bien. El log les podrá dar pautas. Como el rastro acabe en China o Rusia, les va a dar igual porque no van a mover un dedo alli.

D

#12 Anda que si viniese de "juankers" chinos o rusos se te iba a caer el mundo encima...

D

#12 Espanya ens hackea...

Yonny

#12

Yo no llamaría ataque a un sql inyection ... un ataque es otra cosa.

t

#12 Dice la leyenda que si lees la noticia tus dudas quedarán resueltas.

M

Sqli en 2020... eso tiene que llevar ahí siglos, y raro es que no lo hayan explotado... es lo más sencillo del mundo y lo que prueban todos los script kiddies

D

La contraseña más frecuente fué: puchi1234

RazorCrest

A cualquier intervención de las cloacas del estado se le llama fallo de seguridad.

Yonny

#40

Hasta mi sobrino de 12 años sabe hacer un sql inyection... espero que las cloacas sean algo más sofisticadas que eso

D

Los dinerales que pagamos por la infraestructura tecnológica en Europa, para que al final lo acabe haciendo todo el becario recién salido de la universidad.

D

La Nasa Catalana lol lol lol.

f

Una buena oportunidad para venderles el servicio de escaneo de seguridad.

F

Hay que ser cutre para que te hagan un ataque por SQL Injection

1 2