Portada
mis comunidades
otras secciones
![GitHub rechaza una petición de retirada de un fork que contiene las claves privadas de un fabricante de drones [ENG]](https://cdn.mnmstatic.net/cache/2c/25/media_thumb_2x-link-2893232.jpeg?1516948086)
#2:
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?
¿Por cierto, eso del geofencing es lo que nos protege de ataques a instalaciones seguras?
#1:
En el repo no deberían estar las claves de nada, incluso aunque sea privado.
#23:
#12 Esas coordenadas las has tenido siempre, toma: https://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.
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.
#4:
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.
#3:
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 
Comentarios
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: https://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
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
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
#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..
Alguien ha perdido su trabajo ...
#9 Ahora que ha aprendido la lección?
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.
https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/
#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í!
#25 Actualizar firmware.
La solución es cambiar las claves privadas. Punto.
#24 Y con los drones que ya has vendido como haces?
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 segundo lugar, un cifrado debería depender de un código no calculable. Es un idioma calculable? Puede una máquina entender un idioma si no se lo enseñamos? Puede una máquina calcular un idioma? El cifrado no debería ser un algoritmo, debería ser un idioma. De hecho debería ser un idioma aleatorio. Algo así como el Navajo que usaban los yankis en la segunda guerra pero a lo bestia.
Por último, si ya es malo lo anterior, peor idea todavía parece el cifrado de clave pública - clave privada! El colmo ya! Un cifrado no debe depender de algo tan absurdo como perder las claves!!
Ala, ahora, si alguien me ha leído, ya me puede apedrear...
#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
Desde el momento que exista una forma "legal" de desencriptarlo se vuelve vulnerable y por fuerza bruta, con suficiente tiempo, siempre lo vas a poder desencriptar. Es imposible encriptar algo de forma definitiva, simplemente puedes hacer que sea muy dificil de hacer, o cueste varias vidas de duración.
#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 contrario del significado literal y esos mensajes son imposibles de comprender para las máquinas.
Quizá, sólo quizá, palilleramente se me ocurre que las técnicas criptográficas habituales (por ejemplo RSA y la descomposición en factores de pares de primos enormes) no son demasiado buena idea.
#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 cuantos KB de datos ocupa esa información y crea una clave AES con el mismo número de bits que esa información ocupa.
Luego compara las frases en navajo de palabras repetidas y criptoanalizables con el galimatías aleatorio que obtienes como resultado de encriptar con esa clave AES, algoritmo que por cierto no se ha conseguido nunca romper por cryptoanálisis. Cual crees que es más fácil de desencriptar?
Y eso sin tener en cuenta que traducir al Navajo sería mucho más lento, pesado, y más propenso a errores con cosas que no son fácilmente traducibles o que quedan "lost in translation".
#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 conversación traduciéndola a un idioma "raro", el tagalo, por ejemplo. Si cada uno de nosotros tradujera sus mensajes al tagalo, y de nuevo al español, con el traductor de google no nos entenderíamos en absoluto. Y estamos hablando de dos lenguajes que google conoce.
Evidentemente el lenguaje natural es muchísimo mejor para comunicarnos entre humanos que las codificaciones informáticas. Lo más lógico es que los cifrados se hicieran con lenguajes cifrados conocidos a ambos extremos de la comunicación. En vez de computar pares de números primos, tendríamos que computar lenguajes naturales aleatorios compartidos. Esto no serviría para ssl o similar, claro. Pero serviría para cifrar comunicaciones que quieras que sean secretas. De hecho, no me fío un pelo de ssl, menos aún desde las pifias de Intel o el heartbleed hace unos años.
Imagina esta conversación entre dos camellos a los que pincha el teléfono la policía:
- "Vienen unos nenes a comprar piruletas".
Sin contexto, una máquina muy difílmente descifraría que van a comprar drogas. Los policías lo entienden porque comprenden el contexto, un contexto "cultural", aleatorio. Imposible de adivinar por fuerza bruta salvo que participes de él.
Un mensaje "encriptado de verdad" debería partir de premisas lingüísticas similares, a partir de elementos aleatorios y contextuales, crear un nuevo idioma con el que comunicarse. Por fuerza bruta nunca podría la máquina hacer nada... Además, aplicar un AES256 a dicho lenguaje le añadiría la capa extra :-).
PD: AES es simétrico, ya dije que tengo menos mania a los cifrados simétricos que a los asimétricos...
#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 complejas para encriptar/desencriptar que no se pueden hacer de cabeza.
No estoy tan seguro como tú de que Alan Turing no hubiera sido capaz de desencriptar navajo por criptoanálisis. De lo que sí estoy seguro es de que no hubiera sido capaz de desencriptar AES por criptoanálisis, porque nadie, ni siquiera hoy con herramientas más modernas, ha sido capaz de hacerlo.
Yo creo que si interceptas suficientes mensajes de la policía diciendo "Vienen unos nenes a comprar piruletas" y los ves siempre despues mandar patrullas antidroga no hace falta ser Turing para imaginarse lo que esa frase significa, aunque estuviera escrito en Innuit. En cambio con AES, cambias un punto o una coma y el mensaje al completo cambia radicalmente como si fuese un galimatías totalmente distinto. Vamos, ni siquiera puedes saber si el mismo mensaje está encriptado con la misma clave o lo mismo sigue un sistema bajo el que se cambia la clave según la hora y la fecha.
#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.
Sabes cuantos años necesitas para desencriptar 256 bits AES por fuerza bruta? Es un "pelín" más de 11 ..y un "pelín" más de poder de procesamiento del que tiene Google.... [échale un vistazo a este post en reddit](https://www.reddit.com/r/theydidthemath/comments/1x50xl/time_and_energy_required_to_bruteforce_a_aes256/).
Y eso presuponiendo que la clave es constante y no se encripta cada palabra con una clave distinta.
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...
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. https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/
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?