Por un error en la programación, la empresa española PayPro ha perdido los más de 400.000 euros recuadados en su ICO, oferta pública de "acciones" vía blockchain.
#9#7 Como aclaración, en el caso de PayPro, el error se debe a la conversión de la dirección desde JS durante el deployment, por lo que sabemos con certeza que nadie tiene esa clave privada.
#5 Si la pierdes no se lo queda nadie, queda bloqueado en la cadena de bloques.
Si es muy pero que muy pero que muy escandaloso quizá consigas convencer a la comunidad para que se aplique una solución a medida para ese caso, como ocurrió con el proyecto The Dao y que provocó la creación de la cadena de bloques competidora ETC (Ethereum Classic).
En el caso de este meneo explican que la dirección de destino usada no es la que ellos querían que se usase y que desconocen de dónde ha salido, por lo que existe la posibilidad que haya sido un ataque interno o externo en el cual se intercambiase la dirección de destino en algún momento del proceso. En ese caso el atacante puede estar en posesión de la clave privada y puede ser capaz de mover esos fondos, no tiene por que hacerlo ahora podría esperar años a que nadie se acordase de lo ocurrido para no levantar sospechas.
Otra historia es que se hubieran equivocado en un carácter, o añadido caracteres detrás o borrado, en ese caso sería obvio que sería un error tipográfico y entonces sí la clave privada se podría dar por inexistente e imposible de conseguir. Y es que generar dos direcciones similares que varíen en unos pocos caracteres es tan difícil como encontrar una clave privada partiendo de la pública.
#7 Como aclaración, en el caso de PayPro, el error se debe a la conversión de la dirección desde JS durante el deployment, por lo que sabemos con certeza que nadie tiene esa clave privada.
#9 Ciertamente son demasiado parecidas para no concluir que la clave privada no existe, al leer la primera vez el contenido no supe ver la similitud (seguramente por como aparecían descuadradas visualmente y por el cambio de mayúsculas y minúsculas).
Mis disculpas por la confusión que haya podido generar esa parte errónea de mi comentario anterior.
Bien claro le dijeron al encargado: "va a venir el informático a instalar el programa del blockchain. Cuando termine, lo ejecutas". No hacen caso y pasa lo que pasa.
Aquí la paradoja de fondo es que esta empresa quiere ser un "banco descentralizado" pero no es capaz de gestionar ni si propio dinero. ¿Quién puede confiar en una empresa así? ¿Alguien en su sano juicio metería su dinero en algo donde es tan fácil perderlo?
#14 Tiene pinta de startup castuzil pero mejor que hayan fallado ahora a cuando fueran grandes. Lo siento por ellos. Creo que pocas ICOs hispanas consiguieron esas cifras
#9: Que hagan una canción como esta dedicada a las conversiones erróneas a hexadecimal en JavaScript: www.youtube.com/watch?v=i_cVJgIz_Cs Jorge Rubira Santos - No te olvides de poner el Where en el Delete From.
#5 Supongo que te refieres al dinero físico. Entiendo que lo habrían usado para comprar moneda Ethereum, y por culpa de ese error, todas las monedas compradas quedaron almacenadas en esa cuenta errónea en lugar de la suya, con lo que han perdido el dinero físico y el virtual.
se ha encontrado un error de programación. Esto ha provocado que la cantidad mencionada anteriormente se haya depositado en otra dirección. Esta corresponde con un monedero en el nadie cuenta con acceso.
Jejeje, esto me suena a que uno de los programadores ha puesto su dirección personal para que le transfieran los fondos. Como esas direcciones no están vinculadas a ninguna persona física es el fraude perfecto.
#20 Buena suerte convirtiendo esos LTC a Fiat. La cuenta es privada pero los movimientos no lo son. Y si ese dinero se mueve es muy fácil saber dónde acaba.
Las dos direcciones son demasiado similares como para que la segunda pueda existir, crear dos direcciones tan similares es computacionalmente inviable, requeriría de una cantidad de tiempo y energía astronómica (literalmente) para poder acercarte a tener un mínimo de posibilidades de conseguir ese objetivo.
#12 Pues mira que he currado en proyectos bancarios y he visto unos mierdones del 15... fallos que permiten saltarse los OTP (reportados y mail guardado para que no me toquen los huevos el dia de mañana, edito para decir que ignoraron este tipo de fallo critico), cifrados con AES donde la key la puede volcar un niño de 10 años y mil fallos mas ...
Por no hablar de cosas desarrolladas y tiradas a la basura directamente por absorciones (que ya se conocian antes de comenzar el proyecto)...
En fin que poner la banca como ejemplo de hacer las cosas bien...
Y por ultimo, a todos aquellos que hashean sin salt ... que ostia teneis
#33 Es más parecido a que no les hayan dicho donde está la casa y que pueda estar en cualquier rincón del universo, incluso más allá del universo observable.
#23 Si. Teniendo en cuenta que las direcciones de ethereum son de 20 bytes, y asumimos que se generan siguiendo una distribución uniforme, las probabilidades de que te crees justo esa cuenta en concreto son de 1/2^160.
#35 he hecho de pentester de algunos de los 4 bancos gordos del país, y todos caían con cosas que eran para matarlos. Antes de eso, pensaba que iban a ser más duros de roer, pero qué va, sólo es cuestión de tiempo colarte en cualquiera de ellos. En auditoría externa, llegas hasta la cocina en menos de 2 meses, en una interna en menos de 5 días.
Lo único que tienen es pasta (y firewalls y NIDS). Visto lo visto, está claro que no hace falta ser muy brillante para ser empleado o proveedor de ellos.
Admin/admin en las SAN, por si te apetece formatear todos los HDDs, scripts de backup con el login/pass del administrador general de la red colgados de servidores de archivos sin autenticación , banca online que permite enumerar clientes y filtra sesiones activas con extractos de clientes logados, tomcats en dmz ejecutados cómo root, trabsferidores de puntos de fidelización que también permiten transferir euros sin validar que la cuenta origen es tuya o colas guardando los datos completos (incluidos los numeritos del reverso) de todos los pagos con tarjeta, a casi 30000 tarjetas/día o que todos los PCs de las oficinas tenían metido en el ODBC el sysdba del registro de morosos, y ya pa acabar de flipar, bancos con decenas de miles de empleados a los cuales puedes lanzar ping desde cualquier máquina hackeada en la (supuesta) DMZ, por no hablar de los típicos ibm/ibm, Indra/indra123 o hp/hp1234.
Son la peste. Fuera yo el CTO/CISO/CIO y pillaba una katana para reducir el gasto en personal y proveedores en un 80% manteniendo el servicio intacto.
#6 En realidad es casi imposible que haya una clave privada detras de esa clave publica. Los primeros caracteres de la direccion publica son los mismos. Las probabilidades de que haya alguien detras de esa direccion son infimas.
De hecho, las posibilidades de que haya una clave privada detras de cualquier secuencia con el formato de una direccion ETH son bajisimas. Hay un maximo de unas 1461501637330902918203684832716283019655932542976 posibles combinaciones (2^160). Ahora mismo hay un total de 100 millones de differentes direcciones ETH, aproximadamente 1 entre 14615016373309029182036848327162830196559.
Eso quiere decir que si toda la potencia del mayor cupercomputador del mundo, que es la red de bitcoin entera con sus 25000000 de terahashes por segundo, se dedicara a intentar encontrar esa colision, le llevaria aproximadamente 18.537.565.161.477 años.
O lo que es lo mismo, unas 1300 veces la edad del universo.
Asi que concluyo que es razonable pensar que no hay nadie detras de esa direccion.
#35 me llama siempre la atención los aires de superioridad y de saberlo todo mejor que nadie que se gastan ciertos informáticos. Estás emulando a Linus Torvalds?
A ver si me entero.
En un momento dado en vez de enviar los fondos a la direccion A, se envió a la dirección B.
Y nadie sabe en qué momento se cambió A por B.
Ni puede haber garantía en el sistema de que todas las transacciones se hagan a la direccion A.
Porque si alguien o algo tiene acceso y modifica el código y cambia A por B adiós muy buenas. Ya sea un malware a nivel de cliente (ya que el problema fué en Javascript) o del servidor.
A ver si hace falta un blockchain que garantice el blockchain.
La verdad me parece más fiable el sistema bancario que el blockchain ya que el primero está a salvo de la apropiación indebida, en cambio el segundo no.
#51 La dirección siempre fue la B, que es la que estaba en blockchain. El problema es que se dijo que se enviara el dinero a una cuenta diferente. Vamos, que no se cambio la dirección A por la B, si no que hubo una dirección A y una B a la vez.
#52 Claro. Pero el programa en algun momento cambió la dirección buena por la mala. Esa es la vulnerabilidad. No cualquier direccion blockchain debería ser válida. Debería haber un checksum o algo parecido de forma que cambiando un solo caracter no sirviera la dirección.
Hasta el NIF con su puta letra de comprobación es más seguro que una dirección blockchain...
#54 No es asi, una vez el codigo solidity esta en ethereum es inmutable, asi que la empresa deberia dejar de contar historias. El tema de las direcciones blockchain es que son en si mismas Checksums de claves privadas de 32 bits.
Por ejemplo con Bitcoin tu tienes una clave privada y tu direccion es el SHA256() de tu clave privada.
Lo que paso es que los muy idiotas pusieron la direccion publica que no se correspondia con su clave por una cagada de primero de programacion, que es la base numerica. La mayor de las vulnerabilidades es la incompetencia.
Con respecto a la auditoria que mencionan, solo tenian que mirar que el contrato funcionara. Y el contrato funciona. A fin de cuentas, en ethereum el codigo es ley (Casi siempre)
Es algo que considero un error en ETH, no deberia dejarte enviar fondos a una dirección que no existe. Por otro lado menudo fail lo de estos tios, siempre siempre hay que probar que el sistema funciona con una cantidad pequeña antes de meter miles de euros!!
#14 A esto es a lo que me refiero cuando me desgañito por sitios como este a decir que las criptomonedas están en la fase del tam-tam.
Demasiado tejido económico y organizacional se está pasando a blockchain para lo pronto que es. La cosa tiene que madurar mucho todavía.
#51La verdad me parece más fiable el sistema bancario que el blockchain ya que el primero está a salvo de la apropiación indebida, en cambio el segundo no.
¿Que el sistema bancario está a salvo de la apropiación indebida?
#56 Lo de las direcciones preexistentes lo implementó Ripple y para evitar un ataque de spam obligaron a que la creación de cada monedero costase 20 XRP. Debido a la fluctuación de cotización eso ha llegado a suponer tener que gastar el equivalente a más de $100 para abrir un monedero nuevo.
Obviamente esto tiene soluciones como que la cifra sea dinámica, pero no es menos cierto que cada "solución" tiene sus propios problemas.
También dificulta la creación de monederos desconectados de Internet, que es la forma más segura de crearlos.
Lo de que las direcciones ethereum no lleven de serie un checksum que impida errores tipográficos o de programación sí es algo que es difícil de justificar, más cuando ya existía Bitcoin que lo incorpora (creo que los nodos y mineros rechazan transacciones cuyas direcciones no cumplan checksum).
Las empresas de informática deberían hacerse seguros de responsabilidad civil antes de aventurarse a lanzar líneas de código a lo loco y sin los test adecuados sobre sistemas que mueven tanto dinero.
¿Por qué a un arquitecto se lo exigen y a un desarrollador ingeniero no? Es muy infrecuente tener uno de estos, y si es el caso de la empresa externa que la cagó esto probablemente les va a arruinar la vida a algunos.
#66 Para empezar, conocer bien algunas tecnologías y protocolos.
No pasa nada que no sepas de todo, trabajarás en un equipo interdisciplinar y no todos son fuertes en lo mismo.
Mírate sectools.org, al menos deberías saber utilizar 1/3 de las herramientas (sin hacer falta ser Dios, ya aprenderás).
En mi caso, sabía un poco de varias cosas (programación web, SQL, PHP, JS, Perl) y bastante de otras (Linux, Webservers, Shellscripting...). Los webservers son lo más común en intrusión externa, o sea que eso seguro que te lo valorarán.
Recomendaría saber programar en algún lenguaje popular (php, java, C#...) y algo potente para hacerte tus scriptillos (p.e. python o al menos Perl).
Saber filtrar datos guay en un terminal Linux (grep, sed, cut, tr, awk, tail, head...) va super bien cuándo vuelcas toneladas de datos.
Para currar de ello, iría bien tener experiencia previa currando de desarrollador y/o sysadmin. Yo tenía más de 4 años currando de informático, pero he conocido gente increíble fichada recién salida de la carrera.
Los más potentes que he conocido, todos programan. He encontrado pentesters que no saben demasiado de ello y... bueno, hacen curro pero no suelen ser los que consiguen las mayores gestas.
Y para acabar, te sacas la certificación de Ethical Hacker y algunas de sistemas operativos (LPIc 1&2&303, RHCE, MCSA+MCSP...) y de AWS, y si no te pillan de pentester, al menos podrás tener un curro guapo y bien pagado
No he visto ningún comentario que lo aclare así que lo pongo por aquí :
El error fue por parte de PayPro al desplegar, ocurrió lo siguiente :
En lugar de escribir esto: web3.toHex("0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77")
Escribieron esto, sin comillas: web3.toHex(0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77)
Lo que no queda claro si en las instrucciones de despliegue estaba especificado que era con comillas.
Es decir, en vez de a:
etherscan.io/address/0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77
han mandado los fondos a:
etherscan.io/address/0x132623d797fe61de05de0ab5ec5e7a8380000000
(Que es la dirección de arriba al convertirse mal a hexadecimal desde JS en vez de tratarlo como string)
Si es muy pero que muy pero que muy escandaloso quizá consigas convencer a la comunidad para que se aplique una solución a medida para ese caso, como ocurrió con el proyecto The Dao y que provocó la creación de la cadena de bloques competidora ETC (Ethereum Classic).
En el caso de este meneo explican que la dirección de destino usada no es la que ellos querían que se usase y que desconocen de dónde ha salido, por lo que existe la posibilidad que haya sido un ataque interno o externo en el cual se intercambiase la dirección de destino en algún momento del proceso. En ese caso el atacante puede estar en posesión de la clave privada y puede ser capaz de mover esos fondos, no tiene por que hacerlo ahora podría esperar años a que nadie se acordase de lo ocurrido para no levantar sospechas.
Otra historia es que se hubieran equivocado en un carácter, o añadido caracteres detrás o borrado, en ese caso sería obvio que sería un error tipográfico y entonces sí la clave privada se podría dar por inexistente e imposible de conseguir. Y es que generar dos direcciones similares que varíen en unos pocos caracteres es tan difícil como encontrar una clave privada partiendo de la pública.
Es decir, en vez de a:
etherscan.io/address/0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77
han mandado los fondos a:
etherscan.io/address/0x132623d797fe61de05de0ab5ec5e7a8380000000
(Que es la dirección de arriba al convertirse mal a hexadecimal desde JS en vez de tratarlo como string)
Mis disculpas por la confusión que haya podido generar esa parte errónea de mi comentario anterior.
Así ha salido la cosa.
www.youtube.com/watch?v=i_cVJgIz_Cs Jorge Rubira Santos - No te olvides de poner el Where en el Delete From.
Ya, el típico...
EDITO: ETC, no LTC.
Las dos direcciones son demasiado similares como para que la segunda pueda existir, crear dos direcciones tan similares es computacionalmente inviable, requeriría de una cantidad de tiempo y energía astronómica (literalmente) para poder acercarte a tener un mínimo de posibilidades de conseguir ese objetivo.
Por no hablar de cosas desarrolladas y tiradas a la basura directamente por absorciones (que ya se conocian antes de comenzar el proyecto)...
En fin que poner la banca como ejemplo de hacer las cosas bien...
Y por ultimo, a todos aquellos que hashean sin salt ... que ostia teneis
Lo único que tienen es pasta (y firewalls y NIDS). Visto lo visto, está claro que no hace falta ser muy brillante para ser empleado o proveedor de ellos.
Admin/admin en las SAN, por si te apetece formatear todos los HDDs, scripts de backup con el login/pass del administrador general de la red colgados de servidores de archivos sin autenticación , banca online que permite enumerar clientes y filtra sesiones activas con extractos de clientes logados, tomcats en dmz ejecutados cómo root, trabsferidores de puntos de fidelización que también permiten transferir euros sin validar que la cuenta origen es tuya o colas guardando los datos completos (incluidos los numeritos del reverso) de todos los pagos con tarjeta, a casi 30000 tarjetas/día o que todos los PCs de las oficinas tenían metido en el ODBC el sysdba del registro de morosos, y ya pa acabar de flipar, bancos con decenas de miles de empleados a los cuales puedes lanzar ping desde cualquier máquina hackeada en la (supuesta) DMZ, por no hablar de los típicos ibm/ibm, Indra/indra123 o hp/hp1234.
Son la peste. Fuera yo el CTO/CISO/CIO y pillaba una katana para reducir el gasto en personal y proveedores en un 80% manteniendo el servicio intacto.
De hecho, las posibilidades de que haya una clave privada detras de cualquier secuencia con el formato de una direccion ETH son bajisimas. Hay un maximo de unas 1461501637330902918203684832716283019655932542976 posibles combinaciones (2^160). Ahora mismo hay un total de 100 millones de differentes direcciones ETH, aproximadamente 1 entre 14615016373309029182036848327162830196559.
Eso quiere decir que si toda la potencia del mayor cupercomputador del mundo, que es la red de bitcoin entera con sus 25000000 de terahashes por segundo, se dedicara a intentar encontrar esa colision, le llevaria aproximadamente 18.537.565.161.477 años.
O lo que es lo mismo, unas 1300 veces la edad del universo.
Asi que concluyo que es razonable pensar que no hay nadie detras de esa direccion.
Bueno, sí, malgastar recursos finitos para nda
Hace 13 años reporté un error en una aseguradora que, tras migrar dios sabe cuántas veces los routers, sigue ahí.
Los muy retrasados han migrado las configuraciones erróneas
En un momento dado en vez de enviar los fondos a la direccion A, se envió a la dirección B.
Y nadie sabe en qué momento se cambió A por B.
Ni puede haber garantía en el sistema de que todas las transacciones se hagan a la direccion A.
Porque si alguien o algo tiene acceso y modifica el código y cambia A por B adiós muy buenas. Ya sea un malware a nivel de cliente (ya que el problema fué en Javascript) o del servidor.
A ver si hace falta un blockchain que garantice el blockchain.
La verdad me parece más fiable el sistema bancario que el blockchain ya que el primero está a salvo de la apropiación indebida, en cambio el segundo no.
Hasta el NIF con su puta letra de comprobación es más seguro que una dirección blockchain...
Por ejemplo con Bitcoin tu tienes una clave privada y tu direccion es el SHA256() de tu clave privada.
Lo que paso es que los muy idiotas pusieron la direccion publica que no se correspondia con su clave por una cagada de primero de programacion, que es la base numerica. La mayor de las vulnerabilidades es la incompetencia.
Con respecto a la auditoria que mencionan, solo tenian que mirar que el contrato funcionara. Y el contrato funciona. A fin de cuentas, en ethereum el codigo es ley (Casi siempre)
Demasiado tejido económico y organizacional se está pasando a blockchain para lo pronto que es. La cosa tiene que madurar mucho todavía.
¿Que el sistema bancario está a salvo de la apropiación indebida?
Obviamente esto tiene soluciones como que la cifra sea dinámica, pero no es menos cierto que cada "solución" tiene sus propios problemas.
También dificulta la creación de monederos desconectados de Internet, que es la forma más segura de crearlos.
Lo de que las direcciones ethereum no lleven de serie un checksum que impida errores tipográficos o de programación sí es algo que es difícil de justificar, más cuando ya existía Bitcoin que lo incorpora (creo que los nodos y mineros rechazan transacciones cuyas direcciones no cumplan checksum).
youtu.be/8XWff_itZms
¿Por qué a un arquitecto se lo exigen y a un desarrollador ingeniero no? Es muy infrecuente tener uno de estos, y si es el caso de la empresa externa que la cagó esto probablemente les va a arruinar la vida a algunos.
No pasa nada que no sepas de todo, trabajarás en un equipo interdisciplinar y no todos son fuertes en lo mismo.
Mírate sectools.org, al menos deberías saber utilizar 1/3 de las herramientas (sin hacer falta ser Dios, ya aprenderás).
En mi caso, sabía un poco de varias cosas (programación web, SQL, PHP, JS, Perl) y bastante de otras (Linux, Webservers, Shellscripting...). Los webservers son lo más común en intrusión externa, o sea que eso seguro que te lo valorarán.
Recomendaría saber programar en algún lenguaje popular (php, java, C#...) y algo potente para hacerte tus scriptillos (p.e. python o al menos Perl).
Saber filtrar datos guay en un terminal Linux (grep, sed, cut, tr, awk, tail, head...) va super bien cuándo vuelcas toneladas de datos.
Para currar de ello, iría bien tener experiencia previa currando de desarrollador y/o sysadmin. Yo tenía más de 4 años currando de informático, pero he conocido gente increíble fichada recién salida de la carrera.
Los más potentes que he conocido, todos programan. He encontrado pentesters que no saben demasiado de ello y... bueno, hacen curro pero no suelen ser los que consiguen las mayores gestas.
Y para acabar, te sacas la certificación de Ethical Hacker y algunas de sistemas operativos (LPIc 1&2&303, RHCE, MCSA+MCSP...) y de AWS, y si no te pillan de pentester, al menos podrás tener un curro guapo y bien pagado
El error fue por parte de PayPro al desplegar, ocurrió lo siguiente :
En lugar de escribir esto: web3.toHex("0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77")
Escribieron esto, sin comillas: web3.toHex(0x132623d797FE61f8E1D1aE2aA17Fc997a4f9bf77)
Lo que no queda claro si en las instrucciones de despliegue estaba especificado que era con comillas.
fuente : www.businessinsider.es/pierden-medio-millon-criptomonedas-culpan-infor
PD: sep, la plataforma estaba realizada en javascript...