EDICIóN GENERAL
220 meneos
1484 clics
GitHub rechaza una petición de retirada de un fork que contiene las claves privadas de un fabricante de drones [ENG]

GitHub rechaza una petición de retirada de un fork que contiene las claves privadas de un fabricante de drones [ENG]

Un empleado del fabricante de drones DJI se equivocó al crear un repositorio y lo hizo público en lugar de privado. Esto incluía claves AES que permitían descifrar el firmware de control de vuelo, lo que podría permitir a los pilotos de drones con conocimientos técnicos eliminar el "geofencing" del software de control de vuelo. Alguien hizo un fork antes de que DJI corrigiera el error. GitHub se niega a retira el fork alegando que la licencia de uso de GitHub especifica que al hacer un repositorio público se da una licencia irrevocable.

| etiquetas: github , fork , drones , claves
En el repo no deberían estar las claves de nada, incluso aunque sea privado.
#1 Por eso han dicho que es un error.
#7 Yo ahi veo varios errores. cc #2
#15 Tu primer comentario decía:
En el repo no deberían estar las claves de nada, incluso aunque sea privado.

Y yo te respondo que ellos ya admiten que eso es un error, que constatas algo que dice la propia noticia. No te digo que no haya más errores...
#18 Mi primer comentario? Yo no escribi el primer comentario, solo apunto que es una cadena de errores para que se acabe publicando dichas claves.
#20 Ok, creí que me respondía la misma persona. No he mirado el nick. Disculpas
#18 Lo que pone en la noticia es que el error es poner el repo público. Para mí el error es poner las claves en el repo.
#7 No, el error fue hacer el github privado como público. El problema inicial es que esas claves nunca deberían de haber estado en github, ni siquiera en modo privado.
Exacto. El primer error es meter las claves en un repositorio. El segundo, hacerlo público. El tercero, hacer un Streisand para que todo el mundo sepa que se las han robado, en lugar de resolver el problema de manera más sutil.

¿Por cierto, eso del geofencing es lo que nos protege de ataques a instalaciones seguras?
#2 si, DJI tiene un sistema que prohibe volar en determinadas zonas.
#10 Perfecto, ya tenemos las coordenadas de los lugares que los gobiernos quieren que no veamos....
#12 Esos lugares son públicos en la web de DJI, suelen ser aeropuertos, instalaciones militares y demás zonas restringidas por cada país para el vuelo. De hecho el NFZ de DJI es bastante "suave" y no incluye ni de lejos todas las zonas prohibidas.
#12 Esas coordenadas las has tenido siempre, toma: www.dji.com/flysafe/geo-map

Todo zonas que puedes ver desde todos los ángulos mientras estés en el suelo, pero por razones de seguridad, no puedes sobrevolar.

"Los gobiernos" no te ocultan nada en ese mapa.
#23 Mierda, me habéis quitado una ilusión. ;)
#27 Los conspiracionistas nunca se rinden!. Esta lista es solo la lista que los gobiernos quieren que creamos que no quieren que veamos.
#12 tambien te puedes quedar sin un dron y tal vez ademas una visita a la carcel si sobrevuelas dichas zonas con uno.
#2 Si. El que no permite despegar al vehículo en cirtos lugares gográficos, pero que de alguna manera ya se estaban saltando, aunque quizás sin necesidades de las claves o con firmwares antiguos, según me ha contado un colega que está en esto.

Ahora van a poder hacerlo con las versiones nuevas de las controladores de vuelo.
#2 El tercero, hacer un Streisand para que todo el mundo sepa que se las han robado
Hacer fork de un Github público no es robar.
#2 Era mi primer día :pagafantas:
Que majos. Ahí, facilitando la labor de los modders. Por si no fuera poco el ridículo de la filtración, dentro de poco tendrán que ver como el firmware modificado es mejor que el original xD xD xD
#3 Puede que mejoren el firmware y que también permitan volar donde no se puede y esto sea aprovechado por algún hijo de puta pueda soltar una bombita donde no quisiéramos.
Pero sí, el firmware es mejorable.
#28 Si alguien va a soltar una bombita donde no quisiéramos con un drone, o bien la bomba es muy pequeña o tienen medios de sobra para (pagar la) programación de un firmware que les vaya bien sin hacerle fork a los de DJI.
Como ya han dicho en otro comentario, gente saltándose el geofencing hay desde mucho antes de la filtración esta. Por suerto, no para bombardear nada.

Además, no hace falta la bomba, puedes joder bastante y matar a muchisima gente simplemente colando drones grandecitos en las turbinas de los aviones de pasajeros.
#28 Una bomba de 800grs? A menos que te gastes los duros en un dron comercial de 10.000 pavos, que pueden levantar como 5Kg. Y esos no son discretos cuando vuelan, no...unos bicharracos de 8 hélices y metro y pico de diámetro..
Aunque eliminen el repositorio, ya se habrán encargado de hacer copias de seguridad offline de todo el código, y sobretodo de las claves de cifrado. Por mucho que ahora intenten desviar la mirada hacía GitHub, es una cagada del empleado que creó el repositorio como público en lugar de privado, y de nadie más.
#4 Una de las bondades de git, es que con un "git clone" te abajas todo el historico del repositorio, después solo tienes que modificar el "origin" y subirlo a gitlab, bitbucket o donde quieras.
#4 bien, es una cagada, como las que hacemos todos cada día. pero una vez dicho esto e insultado al empleado, se tiene que solucionar, no?
me parece que Github tendría que haber colaborado un poco más, que si bien las claves se deben haber copiado ya, al menos se intenta minimizar un poco el alcance de la cagada
Anyway, son las claves de empaquetado de viejas versiones de firmware para el descontinuado Phantom 3...
Asusta ver los chapuceros que son en cualquier tipo de empresa. Que les pasa a estos inútiles, que meten las claves en el repositorio, o a la misma Adobe, que decide guardar las contraseñas sin Hash ni Salt, y luego le roban 38 millones de constraseñas.

nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-ado
#8 En mi caso es una tarea pendiente, no puedo quitarlas de ahí hasta que automatice el sistema de despliegues, que será el encargado de configurar los proyectos, mientras tanto seguirán en los archivos de configuración en los repositorios privados.
#8 Hola onaj, mis felicitaciones. Eres el primer caso de persona que no se equivoca. Tienes que sentirte orgulloso y hacérselo saber a familia, amigos y compañeros de trabajo, no te quedes para tí!
Alguien ha perdido su trabajo ...
#9 Ahora que ha aprendido la lección?
Una vez haciendo unos test para aprender como iba esto de s3 en Amazon... Subí el código a bitbucket con algun token privado o algo... Y curiosamente amazon me mandó un correo avisandome.
Lo subí porque iba a seguir en casa o algo... xD.
La solución es cambiar las claves privadas. Punto.
#24 Y con los drones que ya has vendido como haces?
#25 Actualizar firmware.
Perfecto. De estos tendríamos que aprender. Deberiamos extender esto a otros ámbitos.
Es un gran error y os aseguro que se comete más de lo que creéis.

Ahora, la postura de github no me parece ni medio normal. Se puede arruinar un proyecto entero con la cantidad de gente que trabaja en el solo por un estúpido error sin mala intención que no quieren enmendar.
#33 yo veo por parte de github una manera de mantener su credibilidad. Como empiece saltándose sus propias condiciones con un cliente en concreto por la razón que sea ya vamos mal y total, el daño ya estaba hecho.
#33 Hombre, si github quita el repositorio, para empezar estaría saltandose la licencia y sus propias normas. Y segundo, no conseguiría nada salvo aumentar el efecto streissand, ya que el repositorio ya ha sido clonado por mucha gente. Alguien lo volvería a subir a github o cualquier alternativa si esta lo pusiese difícil.
Al final toda la seguridad de un tema tan (supongo) importante se delega en una clave privada para acceder a un firmware que está en cada uno de los dispositivos que se han vendido. Este tipo de seguridad por ocultación no me da buena espina.
#40 Toda la criptografía se basa en ello... en una clave privada que no es accesible. Si tienes la clave privada, puedes robar el banco...
#43 Tienes razon y me he explicado fatal y no se mucho de criptografía.

Además de la clave privada, normalmente hace falta un acceso (físico o no), para proteger mis datos yo tengo mi disco duro encriptado y para que alguien lo lea necesitaría tener acceso físico, por red o como sea.. pero al fin y al cabo es mi disco que está en mi casa y cuando quiera le puedo cambiar la clave. Ahí, en caso de que se filtre, DJI tiene poco que hacer porque los dispositivos no están en su poder. Eso poner una limitación artificial a lo que los clientes han comprado, para protegerlos de ¿ellos mismos? ¿Se trata de mantener una zona aérea segura a través de una clave que si se filtra una vez ya no hay forma de pararlo?
Voy a hacer el comentario más palillero, carajillero de mi larga y dilatada vida palilleríl.

Este tipo de cosas es lo que me llevan a pensar que la criptografía asimétrica es una patraña (el simétrico algo menos)... Una patraña bajo la que se rige el mundo!
Para empezar, depende de lago tan absurdo como lo que tarda el hardware de calcular; una idea que ya de por sí me parece mala. Un cifrado no debería depender de esa variable. Un cifrado debería ser indescifrable salvo por casualidad.

En…   » ver todo el comentario
#42 El único cifrado indescifrable es el que no se puede descifrar ni con la clave. Es imposible hacer un encriptado que sea reversible y no sea susceptible a ataques de fuerza bruta, ni simétrico ni asimétrico.

Y si no existe algoritmo ni código calculable, si es un lenguaje que sea imposible de entender, entonces no existe computadora ni persona humana que lo pueda descifrar, con o sin clave. Básicamente es lo mismo que borrar tus datos en vez de encriptarlos :-P

Desde el momento que…   » ver todo el comentario
#44 Es que a lo mejor el error de base está en codificar algo descodificable en vez de usar lenguajes a medida compartidos.
Los alemanes usaban Enigma, y Alan Turing lo descifró. Los americanos usaron indios navajos, y nadie, que no fuera navajo, lo descifraba.
Hubiera descifrado Alan Turing el Navajo sin alguien que supiera Navajo? Permíteme dudarlo.
El lenguaje tiene códigos y normas, pero no siempre son las mismas y son difícilmente interpretables. Con el lenguaje puedes querer decir lo…   » ver todo el comentario
#45 Que te hace pensar que el Navajo no se puede decodificar a base de brute force de la misma manera que cualquier otra representación? De hecho estoy seguro que es mucho más fácil desencriptar Navajo que el equivalente en clave AES ya que es sencillo usar técnicas de criptoanálisis con lenguajes naturales, por lo que ni siquiera necesitas fuerza bruta.

Coge toda la información que hace falta para que alguien aprenda Navajo, sus reglas gramáticales, su completa ortografía, etc. Mira a ver…   » ver todo el comentario
#46 Tú mismo pones el ejemplo, para aprender Navajo debes conocer sus reglas. Si no conces las reglas, no puedes aprenderlo. Repito que estoy casi convencido (imposible saber esto, claro) de que Alan Turing no hubiera sido capaz de descifrar el Navajo si no hubiera tenido un indio navajo a su lado.

Basta ver el traductor de google. Cuántos años lleva funcionando? Cuánta inteligencia artificial tiene detrás? El traductor de Google, a fecha actual, es una absoluta basura. Imagina esta…   » ver todo el comentario
#47 En el ejemplo pongo las dos cosas: para aprender Navajo debes conocer sus reglas y para desencriptar un cifrado con AES debes conocer su clave. Cual de las dos cosas crees que es más fácil de adivinar? La primera es información que por cojones tiene que seguir ciertas pautas que suelen ser comunes en los lenguajes, y además debe ser suficientemente simple para que un humano lo haga mentalmente, la segunda es información completamente aleatoria que necesitas una serie de operaciones…   » ver todo el comentario
#47
El traductor de Google sólo lleva 11 años funcionando, y es capaz de traducir con un nivel relativamente suficiente como para que un lector con cabeza pueda entender lenguaje natural en una cantidad de idiomas bastante importante (te lo digo yo que en mi trabajo tengo que traducir Koreano con frecuencia para temas técnicos y es uno de los idiomas con peor soporte, Google básicamente hace mi trabajo posible sin tener que aprender Koreano). Y eso sin estar diseñado para lo que propones.…   » ver todo el comentario
Como pueden ser asi de chapuceros , que meten las claves en el repositorio, o a la misma Adobe, que decide guardar las contraseñas sin Hash ni Salt, y luego le roban millones de contraseñas. nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-ado

menéame