- En Alemania, un desarrollador que investigaba logs de software durante su trabajo encontró datos de acceso a la DB del proveedor y lo informó, pero el tribunal consideró que fue hackeo
- El software en cuestión establecía una conexión MySQL con el servidor de base de datos del proveedor, que contenía no solo los datos del cliente del desarrollador, sino también los datos de todos los clientes del proveedor
- Las credenciales estaban hardcodeadas en texto plano dentro de la aplicación y estaban tan expuestas que ni siquiera hacía falta descompilar
- El tribunal consideró que el solo hecho de que existiera una contraseña implicaba que había un mecanismo de protección, y determinó que el acto de eludirlo constituía hackeo
- Este tipo de fallo puede desalentar la investigación de seguridad legítima y hacer que empresas con seguridad deficiente eviten responsabilidades, poniendo a los usuarios en mayor riesgo
Del hallazgo a la denuncia
- Este caso genera preocupación de que la ley alemana pueda convertir la investigación de seguridad en una actividad riesgosa
- Un desarrollador recibió la tarea de investigar un software que generaba demasiados mensajes de log
- Durante la investigación, confirmó que ese software establecía una conexión MySQL con el servidor de base de datos del proveedor
- La base de datos contenía no solo los datos de su cliente, sino también los datos de todos los clientes del proveedor
- Tras confirmarlo, el desarrollador informó de inmediato al proveedor, que corrigió la vulnerabilidad, pero presentó una denuncia penal contra el desarrollador
El mecanismo de protección según el tribunal
- La cuestión central era si las credenciales de la base de datos hardcodeadas en la aplicación constituían una protección suficiente para justificar una acusación de hackeo
- Esas credenciales estaban expuestas en texto plano y ni siquiera era necesario descompilar
- El tribunal determinó que, al haber una contraseña, existía un mecanismo de protección, y que el acto de eludirlo era hackeo
El riesgo que queda para la investigación de seguridad
- La razón por la que hay reacciones que esperan que el fallo sea revocado en una instancia superior es que, por más deficiente que sea una protección, su sola existencia puede convertir la investigación de seguridad en hackeo delictivo bajo la ley alemana
- Si se desalienta la investigación legítima, las empresas pueden mantener una seguridad inadecuada y aun así evitar responsabilidades, y en última instancia los usuarios quedan en riesgo
Fuente original
- Artículo relacionado en alemán: Gericht sieht Nutzung von Klartext-Passwörtern als Hacken an
1 comentarios
Opiniones en Hacker News
El título del artículo es algo confuso y parece casi clickbait. Si lo entendí bien, su delito fue usar credenciales de base de datos expuestas para iniciar sesión en un servidor de base de datos de un tercero.
Es decir, no lo procesaron simplemente por “exponer” credenciales, como sugiere el título, sino más bien porque efectivamente las usó para mirar adentro.
Es parecido a asumir que, cuando te dan una tarjeta de acceso a un edificio, las puertas que se abren son salas a las que puedes entrar. Si el equipo de seguridad me encuentra en una sala a la que no debería entrar, no queda claro si la culpa es mía o de quien me dio una tarjeta con permisos equivocados.
Si después de abrir la puerta y mirar adentro me doy cuenta de inmediato de que “aquí no debería estar” y lo reporto al equipo de seguridad, también cabe preguntarse si debería ser castigado.
Pero el punto clave es si podía saber eso antes de iniciar sesión. Si las credenciales están dentro de la app, ¿debería asumir que la seguridad de la empresa es tan deficiente que permiten acceder a todos los datos de clientes? Él tenía derecho a usar la app, y como la app usa esas credenciales, no es un salto tan grande pensar que él también podía usarlas.
En cualquier caso, el resultado de este fallo será claramente malo para la seguridad informática. En el futuro, quienes descubran vulnerabilidades como esta podrían no reportarlas por miedo a represalias legales.
Desde la perspectiva de un desarrollador, es natural ver una contraseña como algo destinado a impedir el acceso de quienes no son usuarios, no de usuarios legítimos. Para empezar, las credenciales ni siquiera estaban ocultas ni ofuscadas.
Cuando quedó claro que los usuarios no debían acceder, lo reportó al proveedor. ¿Me estoy perdiendo algo? De un lado hay un desarrollador haciendo su trabajo, y del otro una empresa avergonzada que toma represalias y asusta a potenciales reportadores de bugs. Parece bastante claro qué está pasando.
Al parecer, el nombre de la base de datos también daba esa impresión. En cuanto se dio cuenta de que contenía los datos de todos los clientes, cortó la conexión.
Lo importante es qué hizo con esos datos después de acceder a ellos. Si no hizo nada, no debería ser un delito; el delito debería configurarse cuando esos datos se usan realmente con fines maliciosos.
Esto es un problema bastante grande en Alemania. Por los artículos citados StGB 202 y siguientes, la investigación de seguridad en el sector privado se volvió prácticamente imposible o, como mínimo, muy poco atractiva.
Se produjo un vacío de casi 20 años, con muy pocos ingenieros jóvenes interesados o formados en esta área. Las grandes empresas con más dinero absorbieron el talento que pudieron encontrar, y los mejores se fueron al extranjero. Por eso, las pymes, que constituyen la mayoría de las empresas alemanas, son hackeadas cada día más. Nadie hace auditorías. Hoy en día, todo lo que está conectado a una red es un riesgo de seguridad.
Creo que esperar que una instancia superior lo revierta es muy ingenuo. El acusado podría terminar perdiendo años yendo del AG al LG, al OLG y al BGH. Estimo que también se le irán unos 100.000 euros en costos. ¿Y para qué, exactamente? Una empresa no protegió bien sus propios datos y, cuando alguien se lo informó, le dio las “gracias” llevándolo a juicio.
Mi consejo es este: si no hay un programa de bug bounty claro, si no es tu propia empresa, o si esa empresa no te lo encargó explícitamente por escrito y te paga por ello, no conviertas ese problema en tu problema. Reprime tu complejo de buen samaritano, borra todos los archivos y no se lo digas a nadie. Especialmente en el trabajo, no lo menciones bajo ninguna circunstancia. Cuando empiece una demanda, la persona a la que interroguen dirá: “Ah, Mike de DevOps lo descubrió en un volcado hexadecimal”, y te vas a arrepentir.
Algunos de los veteranos de la seguridad informática en Alemania están tan enojados por este tema que se niegan a ayudar incluso cuando una agencia gubernamental sufre un incidente. Es una actitud de que aprendan a través del dolor.
Este caso lleva años en curso.
El verano pasado, el tribunal desestimó el caso de la fiscalía. En este sistema, la fiscalía presenta el caso ante el tribunal, y el tribunal lo revisa rápidamente y puede desestimarlo antes de fijar fecha de juicio si es claramente débil, algo bastante inusual. La fiscalía logró revertirlo en un tribunal superior, así que el juicio se celebró en el mismo tribunal inferior, pero con un juez distinto al que había desestimado inicialmente el caso.
“Según la decisión del Tribunal de Distrito de Jülich del 10 de mayo de 2023, se desestimó el procedimiento penal contra el investigador de seguridad. El tribunal considera que no se configura un delito penal porque los datos a los que accedió el investigador de seguridad no estaban suficientemente protegidos. ‘Solo los datos especialmente protegidos contra el acceso no autorizado entran dentro del ámbito de protección de este delito. Esto presupone que se hayan tomado medidas objetivamente adecuadas para impedir el acceso a los datos’, señaló la decisión del tribunal. ‘El tribunal no comparte la postura de la fiscalía de que la protección mediante contraseña por sí sola sea suficiente. Por ejemplo, cuando la contraseña es demasiado simple o se usa de forma estandarizada en una aplicación específica, una contraseña no siempre ofrece una protección efectiva de los datos. En esos casos, facilitar el acceso a los datos no constituye delito.’”
“heise online pudo confirmar, tras su propia investigación del software de Modern Solution, que efectivamente contenía una contraseña predeterminada integrada. Esto significa que cualquiera que analizara el software disponible para descarga libre en el sitio web de la empresa podía acceder a los datos en los servidores de Modern Solution.”
No, lo declararon culpable por usar esas credenciales para conectarse a la base de datos. No conozco la ley alemana, pero al menos en el Reino Unido sería una violación clara de la Computer Misuse Act, así que el desenlace era obvio
Te guste o no, si estás en posición de hacer este tipo de investigación, deberías conocer al menos lo básico de la ley
Suena a que el desarrollador no estaba haciendo investigación de seguridad, sino investigando un bug. Conectarse a la base de datos, darse cuenta de qué era y desconectarse de inmediato para reportarlo responsablemente no debería terminar en un castigo
Como dijo alguien más, con este enfoque se incentiva a la gente a vender ese conocimiento a personas que sí lo van a “usar indebidamente” de verdad
No veo cuál es la diferencia. Tal vez sea una violación de los términos de servicio, pero de ahí a llamarlo “hacking” hay un trecho enorme
Que haya una contraseña no significa que intentaran mantener a la gente afuera. Ellos distribuyeron la contraseña junto con el producto
Es como si al entrar a un edificio te dieran una tarjeta de acceso y dijeran “por favor no vaya a donde no debe”, pero resulta que era una llave maestra. ¿Cómo se supone que uno iba a saber de antemano que esa tarjeta abriría lugares a los que no debía entrar?
Yo también tengo credenciales de servicios de Google, pero solo me dan acceso a lo mío
Ejecutó el conector de otro servicio de donde parecían venir esos datos y observó en el firewall que se abría una conexión en texto plano a un servidor MySQL remoto. Al revisarlo, vio que las credenciales usadas eran las mismas para todos los tenants de la DB MySQL. Así que lo expuesto no eran solo los datos del cliente, sino los datos de todos los tenants
Después, según tengo entendido, creó hashes de los datos de usuarios y los exportó para reportarlo a las autoridades y permitir que los usuarios verificaran si estaban incluidos en el sistema que debía considerarse comprometido. Esa DB exponía datos de unos 700 mil usuarios finales. También informó del problema a la empresa que operaba la DB
El proveedor de ese conector lanzó un nuevo cliente que usaba TLS, y él también lo evadió para demostrar que el problema seguía vigente
También lo acusaron de haber obtenido la contraseña descompilando el software cliente, pero si mal no recuerdo él sostuvo que simplemente abrió un archivo en el Bloc de notas
Cuando se dio cuenta de que podía acceder a más datos de los previstos, se desconectó
Yo hice exactamente lo mismo en una situación parecida. Había un proveedor de software de escritorio con un problema, vi que las credenciales de la base de datos estaban guardadas en texto plano en un archivo de configuración y me conecté. En mi caso, esa base de datos era single-tenant y exclusiva de nuestra empresa, así que pude hacer lo que necesitaba
¿No debería considerarse claramente la intención al aplicar la ley en casos así? No parece que este desarrollador tuviera intención de acceder a un sistema restringido
Creo que esas leyes deberían reescribirse. La intención importa, y no parece que este “hacker” quisiera causar daño
La empresa quedó avergonzada porque se expuso una falla de seguridad, y quiere castigar a quien la hizo pública
Solo por este caso, como desarrollador no querría trabajar en Alemania, y mucho menos en seguridad
Quieren que los “campesinos” conozcan su lugar y no miren por las ventanas de la nobleza. A menos que los abogados logren de algún modo iluminarlo con la luz de la opinión pública, el Estado casi siempre se pone del lado de quien tiene más dinero. Por eso este tipo de cosas hay que hacerlas de forma anónima
Una vez tuve una startup de alimentos en Países Bajos
Trabajábamos con PostNL, un proveedor importante de envíos postales y antigua organización gubernamental. Cada semana subíamos nuestros pedidos a su sistema y podíamos ver nuestro historial
Pero un día, de pronto, pudimos acceder al historial de todos los demás clientes y exportar datos de usuarios. Muchos de ellos eran competidores directos, y sus listas de correo nos habrían sido bastante valiosas
Mi socio exportó a Excel todos los datos de Marley Spoon, un competidor que había levantado más inversión, y algunos otros datos. Cuando me lo contó, le dije que lo borrara de inmediato. Podía ser divertido, pero no debíamos generar responsabilidad legal. Aun así, si lo hubiéramos usado, quizás podríamos haber crecido entre 10% y 30% en pocas semanas
Aunque tenían la obligación bajo la ley de la UE, nunca lo reportaron
Al final, si recibes las llaves del castillo, quizá sea mejor no usarlas. O quizá sí
Podríamos haber usado eso en la negociación de precios, y tal vez debimos hacerlo. En los meses siguientes casi nos duplicaron los precios y no tuvieron piedad. Sin mencionar que procesaban mal entre el 3% y el 8% de los pedidos y aun así no reembolsaban
Pero en cambio nos mudamos a otros servicios de entrega, y cada uno tenía sus propias fallas
Una captura de pantalla con evidencia de que se están filtrando datos personales sin duda ayudaría, y no creo que PostNL haya arreglado ese sistema espantoso
Según la ley neerlandesa, si tu colega sabía que no debía acceder y aun así descargó datos más allá de lo necesario para confirmar la filtración, cometió un delito
Si hubieras “usado” esta información en una negociación, eso sería extorsión, y en especial con una empresa tan grande y sin un competidor real, es algo que definitivamente no querrías hacer. Ellos lo denunciarían a la policía y tú estarías acabado
Suena parecido a un caso que ocurrió donde vivo
https://www.techdirt.com/2022/02/25/turns-out-it-was-actuall...
Ese “hackeo” fue decodificar números de seguro social en Base64
Imaginen la cantidad de cosas que programadores flojos pegan en decodificadores Base64 en línea. Cuánto habrá dentro de esos payloads
Operar un sitio como base64decode.org sería un excelente honeypot
Si realmente hubieran cifrado los datos, habría estado bien, pero la codificación Base64 no es cifrado. Base64 se puede decodificar muy fácilmente: https://developer.mozilla.org/en-US/docs/Glossary/Base64#the...
Muchos “hackeos” son como cuando algún idiota deja la puerta de entrada totalmente abierta
Si dejas la puerta de entrada totalmente abierta y te roban, el público no te tendría mucha lástima, pero cuando las empresas ahorran dinero y no hacen nada para actualizar, mantener y hacer cumplir las mejores prácticas básicas de seguridad, la gente le grita al hacker
Si dejaste la puerta de entrada totalmente abierta y yo entro a robar, cometí un delito. “La puerta estaba abierta” no es una excusa
Yo merecería críticas, pero la persona que me robó también debería recibir el castigo adecuado
Incluso si dicen que “solo estaban tratando de comprobar que todo estuviera seguro”
¿No es esto lo opuesto a una ley del buen samaritano? Algo así como: si ves algo, no digas nada y no hagas nada
Si encontrar estos problemas es ilegal, me pregunto si sería legal detenerse después de notar que podría haber un problema y ponerse corto con acciones de la empresa
El problema que enfrentarías si intentaras hacerlo de verdad es que a los inversionistas casi no les importan los problemas de seguridad. Así que, aunque publiques una vulnerabilidad, es probable que la acción no baje. Además, esta empresa ni siquiera parece cotizar en bolsa. No sé alemán, así que no debería afirmarlo con certeza, pero probablemente sea esta: https://www.modernsolution.net/
Algo como: “Hola, por casualidad descubrí que hay una contraseña en el offset X de esta app. En esta captura del volcado hexadecimal se ve la contraseña. Al lado también están el nombre de usuario y el host, y hay indicios claros de que es una conexión SQL, pero no puedo verificar cuál es esa contraseña. No se conecten a esta IP con este nombre de usuario y contraseña. ¡Gracias!”
Además, en el caso de empresas de EE. UU., muchas veces una gran filtración de datos o intrusión no tiene un impacto negativo en las finanzas de la empresa
El artículo 202a del código penal dice esto
https://www.gesetze-im-internet.de/stgb/__202a.html
Aproximadamente: “obtener, para uno mismo o para otra persona, acceso a datos especialmente protegidos contra accesos no autorizados”
aparentemente, una contraseña hardcodeada metida en el cliente también entra en esto
Pero esta es la realidad, y tal vez la arreglen por ahí de 2050