Portada
mis comunidades
otras secciones
#6:
#5 Como ya sucedió con la red de cajeros ATM o en las centrales nucleares de Iran, no es necesario que estén conectados a Internet para llegar hasta ellos. Con infectar algún equipo de la red de servicio y luego buscar los Windows vulnerables es suficiente.
Generalmente reparten "pendrive" en las puertas de la oficina, los empleados los conectan en sus equipos y si estos tienen acceso a la red de servicio ya esta.
Generalmente reparten "pendrive" en las puertas de la oficina, los empleados los conectan en sus equipos y si estos tienen acceso a la red de servicio ya esta.
#13:
#12 Pues sí... Pero te lo puedo poner un poco en contexto: estos dispositivos son de la época de la guerra dura de Microsfoft contra Lilnux. OS/2 había caído (ya no había nuevas versiones) y Microsoft insistía en que Linux era una porquería porque cualquiera podía ver como estaba hecho y Windows era maravilloso porque era cerrado y super recontra seguro porque los ingenieros de Microsoft se encargaban de ello.
Pero Microsoft no se limitaba a "decirlo" públicamente. Hacía "alianzas estratégicas" con las empresas. Esas alianzas eran cosas como
Mira, que yo no soy cualquiera, son Microsoft: yo te dejo decir que eres mi "partner", te dejo más baratas las licencias de Visual Studio, te doy cursos para tus programadores. Tu a cambio haces drivers para windows para que funcione tu hardware de contador de billetes y de teclado con cifrado por hardware. A demás te comprometes a sólo hacer drivers para windows y las versiones de windows de la actual en adelante, no para versiones anteriores ni para otros sistemas operativos. Y por si fuera poco, te doy permiso para poner una pegatina que diga "designed for windows 98".
Resultado: hace muchos años me tocó desarrollar para un dispositivo de autoservicio. No era un cajero automático al uso pero tenía hardware para aceptar billetes, leer tarjetas, etc. Internamente era un PC cualquiera pero el hardware para manejar los dispositivos no seguía ningún standard. Ni siquiera se conectaba pro puerto serie o usb, tenía sus propios chips integrados en el hardware de PC y no había ningún tipo de información de su funcionamiento. Lo único que había eran unas DLL que debías linkear en tu programa y una lista de funciones con las que llamar a esas DLL.
El fabricante (NCR) NO proveía ningún soprte ni ninguna información que permitiera usar su hardware en algo que no fuera windows 95 o 98. De hecho, cuando les preguntabas te contestaban como si fuera una completa locura pensar en usar otro sistema que no fuera windows. Esos pobres frikis que se creen que son con su sistema operativo casero hecho por chavales estudiantes que no tienen vida van a poder hacer funcionar un dispositivo "serio".
Incluso barajamos la posibilidad de usar WINE para cargar las DLL que poveían, pero iban acompañadas de algo más que instalaba otra cosa, tal vez algún driver en el kernel, no se. La cosa es que no teníamos tiempo de pelear con esto y si después llegaba a fallar algo no íbamos a poder conseguir ninguna ayuda del fabricante.
En definitiva, que optamos por una solución intermedia. El software que hicimos fue básicamente un browser con acceso al hardware que necesitábamos mediante tags creados por nosotros. De esa forma toda la inteligencia de las operaciones las manejaba un servidor bajo linux, pero de cara al público no quedaba otra que usar windows. Para tratar de evitar ataques por red, pusimos un cliente IPSEC en el windows y todo el tráfico lo pasamos por ahí. Fue lo más que pudimos hacer en aquel momento.
Pero Microsoft no se limitaba a "decirlo" públicamente. Hacía "alianzas estratégicas" con las empresas. Esas alianzas eran cosas como
Mira, que yo no soy cualquiera, son Microsoft: yo te dejo decir que eres mi "partner", te dejo más baratas las licencias de Visual Studio, te doy cursos para tus programadores. Tu a cambio haces drivers para windows para que funcione tu hardware de contador de billetes y de teclado con cifrado por hardware. A demás te comprometes a sólo hacer drivers para windows y las versiones de windows de la actual en adelante, no para versiones anteriores ni para otros sistemas operativos. Y por si fuera poco, te doy permiso para poner una pegatina que diga "designed for windows 98".
Resultado: hace muchos años me tocó desarrollar para un dispositivo de autoservicio. No era un cajero automático al uso pero tenía hardware para aceptar billetes, leer tarjetas, etc. Internamente era un PC cualquiera pero el hardware para manejar los dispositivos no seguía ningún standard. Ni siquiera se conectaba pro puerto serie o usb, tenía sus propios chips integrados en el hardware de PC y no había ningún tipo de información de su funcionamiento. Lo único que había eran unas DLL que debías linkear en tu programa y una lista de funciones con las que llamar a esas DLL.
El fabricante (NCR) NO proveía ningún soprte ni ninguna información que permitiera usar su hardware en algo que no fuera windows 95 o 98. De hecho, cuando les preguntabas te contestaban como si fuera una completa locura pensar en usar otro sistema que no fuera windows. Esos pobres frikis que se creen que son con su sistema operativo casero hecho por chavales estudiantes que no tienen vida van a poder hacer funcionar un dispositivo "serio".
Incluso barajamos la posibilidad de usar WINE para cargar las DLL que poveían, pero iban acompañadas de algo más que instalaba otra cosa, tal vez algún driver en el kernel, no se. La cosa es que no teníamos tiempo de pelear con esto y si después llegaba a fallar algo no íbamos a poder conseguir ninguna ayuda del fabricante.
En definitiva, que optamos por una solución intermedia. El software que hicimos fue básicamente un browser con acceso al hardware que necesitábamos mediante tags creados por nosotros. De esa forma toda la inteligencia de las operaciones las manejaba un servidor bajo linux, pero de cara al público no quedaba otra que usar windows. Para tratar de evitar ataques por red, pusimos un cliente IPSEC en el windows y todo el tráfico lo pasamos por ahí. Fue lo más que pudimos hacer en aquel momento.
#5:
Sensacionalista. Los cajeros no están enchufados a internet, con lo que las posibles vulnerabilidades no son críticas. Y si fuera tan fácil se estaría haciendo continuamente. La forma más común de estafar con los cajeros es por medios físicos, poniendo ranuras falsas donde meter la tarjeta, cámaras ocultas que te graban metiendo el pin, o simplemente un tío se te pone detrás mirando lo que haces para posteriormente robarte la tarjeta.
Comentarios
John Connor seal of approval
#3 dinero facil!
#3 llevaré mi Atari portfolio
Y comenzaré a hackear
En los recreativos
Qué bien me lo voy a pasar
Hasta que el terminator malo
Me venga a matar
Sensacionalista. Los cajeros no están enchufados a internet, con lo que las posibles vulnerabilidades no son críticas. Y si fuera tan fácil se estaría haciendo continuamente. La forma más común de estafar con los cajeros es por medios físicos, poniendo ranuras falsas donde meter la tarjeta, cámaras ocultas que te graban metiendo el pin, o simplemente un tío se te pone detrás mirando lo que haces para posteriormente robarte la tarjeta.
#5 Como ya sucedió con la red de cajeros ATM o en las centrales nucleares de Iran, no es necesario que estén conectados a Internet para llegar hasta ellos. Con infectar algún equipo de la red de servicio y luego buscar los Windows vulnerables es suficiente.
Generalmente reparten "pendrive" en las puertas de la oficina, los empleados los conectan en sus equipos y si estos tienen acceso a la red de servicio ya esta.
#6 Lo que dices es cierto. Pero si logras infectar un equipo de la red de servicio seguro que será más rentable robar información que hackear un cajero.
#8 es mas facil darle uso a billetes que a informacion que no sabras a quien vender y si te puedes fiar de a quien quieras venderle la informacion.
#8 El problema esta en la cabeza pensante que decidió poner Windows en un cajero o en el terminal de control de una central nuclear.
En los cajeros con OS/2 nunca ha pasado nada parecido al asunto de la red ATM.
#12 Pues sí... Pero te lo puedo poner un poco en contexto: estos dispositivos son de la época de la guerra dura de Microsfoft contra Lilnux. OS/2 había caído (ya no había nuevas versiones) y Microsoft insistía en que Linux era una porquería porque cualquiera podía ver como estaba hecho y Windows era maravilloso porque era cerrado y super recontra seguro porque los ingenieros de Microsoft se encargaban de ello.
Pero Microsoft no se limitaba a "decirlo" públicamente. Hacía "alianzas estratégicas" con las empresas. Esas alianzas eran cosas como
Mira, que yo no soy cualquiera, son Microsoft: yo te dejo decir que eres mi "partner", te dejo más baratas las licencias de Visual Studio, te doy cursos para tus programadores. Tu a cambio haces drivers para windows para que funcione tu hardware de contador de billetes y de teclado con cifrado por hardware. A demás te comprometes a sólo hacer drivers para windows y las versiones de windows de la actual en adelante, no para versiones anteriores ni para otros sistemas operativos. Y por si fuera poco, te doy permiso para poner una pegatina que diga "designed for windows 98".
Resultado: hace muchos años me tocó desarrollar para un dispositivo de autoservicio. No era un cajero automático al uso pero tenía hardware para aceptar billetes, leer tarjetas, etc. Internamente era un PC cualquiera pero el hardware para manejar los dispositivos no seguía ningún standard. Ni siquiera se conectaba pro puerto serie o usb, tenía sus propios chips integrados en el hardware de PC y no había ningún tipo de información de su funcionamiento. Lo único que había eran unas DLL que debías linkear en tu programa y una lista de funciones con las que llamar a esas DLL.
El fabricante (NCR) NO proveía ningún soprte ni ninguna información que permitiera usar su hardware en algo que no fuera windows 95 o 98. De hecho, cuando les preguntabas te contestaban como si fuera una completa locura pensar en usar otro sistema que no fuera windows. Esos pobres frikis que se creen que son con su sistema operativo casero hecho por chavales estudiantes que no tienen vida van a poder hacer funcionar un dispositivo "serio".
Incluso barajamos la posibilidad de usar WINE para cargar las DLL que poveían, pero iban acompañadas de algo más que instalaba otra cosa, tal vez algún driver en el kernel, no se. La cosa es que no teníamos tiempo de pelear con esto y si después llegaba a fallar algo no íbamos a poder conseguir ninguna ayuda del fabricante.
En definitiva, que optamos por una solución intermedia. El software que hicimos fue básicamente un browser con acceso al hardware que necesitábamos mediante tags creados por nosotros. De esa forma toda la inteligencia de las operaciones las manejaba un servidor bajo linux, pero de cara al público no quedaba otra que usar windows. Para tratar de evitar ataques por red, pusimos un cliente IPSEC en el windows y todo el tráfico lo pasamos por ahí. Fue lo más que pudimos hacer en aquel momento.
#13 El problema siempre suele ser el mismo, elegir hardware "de juguete" para cosas serias.
Si usted quiere que su dispositivo tenga una larga vida útil nunca se debe utilizar un driver binario o librería binaria. Se deben tener las especificaciones de comunicación con el hardware, esto permite reescribir/actualizar la aplicación sobre otros sistemas futuros.
Un ejemplo de malas practicas son las balanzas industriales Bizerba. En las Bizerba solo suministran una aplicativo licenciado para realizar las lecturas. Cada cambio de S.O. debes comprar un licenciamiento nuevo de las DLLs y adaptar la aplicación porque los puntos de entrada y el API lo cambian.
Si en un futuro dejan de soportar un modelo en ese driver/DLLs directamente tiras la balanza industrial de miles de euros.
Con otras balanzas, como por ejemplo Ohaus Defender, la comunicación es serie o ethernet y los comandos están perfectamente documentados.
En muchos casos no se transmiten al cliente estos detalles.
#20 Si usted quiere que su dispositivo tenga una larga vida útil nunca se debe utilizar un driver binario o librería binaria.
Muy cierto. El problema es cuando los fabricantes sólo te ofrecen esa alternativa.
Un pensará ¿pero qué les cuesta liberar el código de los drivers? Si ellos venden hardware. Les da lo mismo si portas los drivers a otro sistema.
Para eso hay varias explicaciones según el caso.
1) En muchos casos el driver no lo hace la misma empresa de hardware: lo contratan con un tercero que lo desarrolla y el tercero sólo entrega binarios. Si quieren el código fuente el precio es muy distinto y no ven motivo para pagarlo. Es más, muchas veces quienes toman esas decisiones ni saben lo que es un código fuente.
2) A veces el fabricante no quiere que su hardware se utilice en otros sistemas porque tienen otros poductos mucho más caros que sí están disponibles para otras plataformas.
3) Los fabricantes siempre están felices de que un producto vendido hace años tenga que ser reemplazado. No van a colaborar GRATIS para que sigas usando algo viejo pudiendo venderte algo nuevo.
Si en un futuro dejan de soportar un modelo en ese driver/DLLs directamente tiras la balanza industrial de miles de euros
Te puedo dar otro ejemplo similar: en mi empresa hace unos años compraron un sistema de cámaras de vigilancia con grabador. Mi primera queja fue que desde linux era imposible acceder a las grabaciones. Sólo habían dos opciones: o por una aplicación para windows, o por web pero con un control activex que básicamente era la misma aplicación pero que se abría en una ventana del browser.
Lógicamente cuando dije eso me miraron como diciendo "pobre friki, que use windows como la gente normal".
Resultado: que hoy en día es imposible acceder a las grabaciones si no es por la propia pantalla del dispositivo. El software no funciona en versiones actuales de windows y el control activex sólo funcina en explorer 6. Si hiciera falta extraer una grabación del dispositivo no sería posible a no ser que te pongas con un teléfono a grabar la pantalla.
Pero bueno, estas cosas siguen sucediendo constantemente. Hace falta tener determinados conocimientos para darse cuenta de estas cosas, y la gente que toma las decisiones tiende a pensar que si paga por algo, ese algo funcionará como se promete y en realidad así es. Si la caja dice "compatible con windows 7", pues eso y sólo eso es lo que se garantiza y sólo mientras dure la garantía.
#22 El caso del NVR puede tener un pase, al fin al cabo es un producto económico y fácil de sustituir.
Lo que me resulta incomprensible es elegir juguetes para proyectos industriales caros y con muchas horas de desarrollo detrás.
En algunos casos el ejecutivo de turno, conociendo el asunto, lo que hacen es un envió del problema al futuro. Durante su "mandato" el ahorra algo de costes en el desarrollo y luego ya vendrá otro a encontrarse con el problema.
Al final resulta mucho mas caro en el tiempo.
#26 En algunos casos el ejecutivo de turno, conociendo el asunto, lo que hacen es un envió del problema al futuro. Durante su "mandato" el ahorra algo de costes en el desarrollo y luego ya vendrá otro a encontrarse con el problema.
Eso es algo constante en las empresas medianas o grandes: se premia las ganancias a corto plazo y se ignora el resultado a largo plazo. Ningún directivo de una empresa recibe una prima por planificar ganancias para dentro de 3 años. Ni siquiera para el año siguiente. Lo único que importa es este año conseguir el objetivo de aumentar las ganancias en un porcentaje determinado. Si eso se consigue, el directivo recibe un suculento premio. Si no se consigue lo despiden y contratan a otro.
Si para conseguir el objetivo de este año hace falta por ejemplo, trucar los motores para que pasen los controles de contaminación, pues perfecto, se hace. ¿Que pronto lo descubrirán le meterán a la empresa una multa y el desprestigio podría llevarla a la empresa ruina? Eso ya será problema de otro, el objetivo es llegar al fin de este año con el crecimiento que se espera.
#5 Con que estén conectados a alguno que sí lo esté basta. Basta con colarse en alguno que esté conectado a internet y a la red de los cajeros para intentar hackearlos
#6 Eso lo viste en Mr Robot cuando se cuelan en la cárcel
#17 No, son casos reales documentados.
En el caso de las centrales nucleares de Iran, consiguieron activar los motores y sumergir las barras de combustible llegando a partirlas.
https://en.wikipedia.org/wiki/Stuxnet
https://hackernoon.com/do-atms-running-windows-xp-pose-a-security-risk-you-can-bank-on-it-1b7817902d61
#23 Me refería a lo de repartir pendrives
#24 Justamente esa parece ser la técnica utilizada en Irán.
Alguien con pase de seguridad, tipo limpieza, dejo "pendrives" con etiquetas "sugerentes" cerca de la sala con los terminales SCADA.
#23 Eeeeeeh.... No. Lo de Irán no fue eso. De hecho esa frase no tiene mucho sentido: Las barras de combustible están siempre sumergidas (más nos vale a todos) y no se mueven más que para renovarlas. De hecho ni siquiera era una central nuclear. No tienen, ese es el asunto.
Lo que pasó es que engañaron al sistema de control de las centrifugadores de enriquecimiento de uranio para que pareciera que iban bien mientras en realidad variaban la velocidad hasta que se averiaban.
Del artículo de la wikipedia que enlazas:
"Furthermore, it monitors the frequency of the attached motors, and only attacks systems that spin between 807 Hz and 1,210 Hz. The industrial applications of motors with these parameters are diverse, and may include pumps or gas centrifuges."
#38 Totalmente cierto, he confundido datos de otro incidente que no estaba relacionado con el malware.
De este asunto se hablo mucho en su época.
Mi contacto con los PLCs industriales se produjo en entornos aeroportuarios y lo mas alarmante que vi:
- La redes profiBUS y similares se conectan/conmutan a una red ethernet de servicio sin ninguna protección.
- A esa red de servicio se conectan infinidad de portátiles y equipos de mantenimiento, generalmente Windows en versiones veteranas sin ningún tipo de seguridad.
- No existe control lógico sobre las direcciones de los PLCs. Un técnico se puede equivocar en el referenciado y cargar programa contra otro PLC.
- La mensajería entre PLCs y servidores de los Aplicativos eran perfectamente visibles he interceptables en toda la red de servicio. Incluso se podían inyectar mensajes haciéndose pasar por un PLC.
- Al no existir un sistema de seguridad en la conexión y trafico de dicha red, era imposible saber con certeza quien era el culpable de, por ejemplo, una modificación realizada.
- Las librerías de Siemens para interactuar con los PLCs eran un cúmulo de malas practicas en cuanto a programación y seguridad. Mi sensación es que son como son para dificultar entornos mixtos o migraciones de proveedor de PLCs.
#6 En un banco nadie deberia tener los USBs disponibles como para meter un pendrive.
Y si te cuelas en la red de un banco no te centras en los cajeros que, ademas, tiene su propia capa de seguridad en la red del banco
#30 Todos los equipos de la oficina del banco y los portátiles de los servicios técnicos que dan soporte a los cajeros tienen usb y MS Windows.
En los últimos 15 años se han dado numerosos casos de ordenar en remoto "expulsión" de dinero. Siempre ha sido con los mismo métodos, programando una hora para la "expulsión" y entrando por vulnerabilidades windows/red.
La combinación OS/2 + Frame relay contra host era muchísimo mas segura.
https://www.bbc.com/mundo/noticias-38077690
https://www.bankinfosecurity.com/atm-hackers-double-down-on-remote-malware-attacks-a-10338
https://www.kaspersky.com/blog/sas-2017-atm-malware/14509/
#41 Bueno, te hablo desde mi experiencia, que he estado unos años trabajando con cajeros. Ya te digo que el servicio tecnico no lleva portatiles con los que conectarse al cajero. Normalmente el servicio tecnico del fabricante esta ahi para los problemas de hardware y usan la consola del cajero, y todo el mantenimiento del software se hace por conexion en remoto. El windows que tiene el ordenador del cajero esta mas que capado, no te deja hacer una mierda, aunque cierto es que sí acepta que conectes un raton y un teclado por usb, pero ni siquiera es necesario enchufarse para la mayoria de problemas (con la pantalla tactil del cajero te apañas sin teclado y sin raton), con la consola del fabricante y sus herramientas de diagnostico vas que chutas.
Y si quieres hackearlo logicamente, aparte del software del propio cajero y de los drivers del fabricante, aun tienes la tercera parte de la trinidad que es el host del banco.
Yo no sabria ni por donde empezar a meterle mano. En remoto ni lo contemplo, fisicamente podrias empezar por reventar el cajero, conectarte fisicamente al ordenador despues de echar abajo el cliente, y lo mismo en ese punto ya es un hacking normal de un windows casi normal.
Desde luego que no es tan facil como lo pintan y que yo sepa en 10 años no ha habido mas robos que por fuerza bruta
PS: los equipos de las branches tampoco aceptan USBs
#44 Casos documentados hay bastantes.
https://securelist.com/atmii-a-small-but-effective-atm-robber/82707/
https://blog.trendmicro.com/trendlabs-security-intelligence/dissecting-prilex-cutlet-maker-atm-malware-families/
https://www.europapress.es/portaltic/software/noticia-kaspersky-lab-analiza-malware-atmitch-descubre-misteriosa-forma-robar-dinero-cajeros-automaticos-20170405105202.html
En los últimos años es algo que ha ocurrido en multitud de redes ATM.
#6 Por más que meto el pendrive lleno de virus por la rendija del dinero no salen billetes. Qué raro. Tendré que apretar más.
#37 Siendo USB, lo estarás metiendo al revés
#5 o el clásico hackeo low-tech de esperar a que saques y solicitarte el dinero navaja en mano.
¿15 minutos? Rato puede hacerse con una black en 15 segundos. Principiantes...
Chivatos
Voy a buscar VidÉos tutoriales.
¿dónde ? ¿dónde?
Pueden ser honeypots.
¿Por dentro están reforzados con cemento para impedir acceder a los puertos?
Mientras se pueda hackear la cámara también, no te pillan.
#11 Hay unos dispositivos que sirven para impedir que las cámaras puedan captar imágenes.
A ver si te consigo una foto de uno:
https://www.bricolemar.com/cinta-americana/8358-cinta-americana-basic-4610-negro-25mx50mm-tesa.html
#18 un chicle es más barato pero claro, dejas tu adn, a menos que lo mastique tu perro!
#21 puedes coger un chicle pegado de bajo de la mesa de la sala de estudios de la facultad de informática, con los genes de algún pringado que pueda servirte de cabeza de turco
#31 coño me has abierto todo un abanico de posibilidades!
El cajero donde saco normalmente tiene los carteles y avisos todavía en pesetas, se la sopla.
Cajeros con XP, BIOS del 2003, 256 MB de RAM, Pentium 3... en fin.
"Cajeros con Win..." y ahí dejé de leer y corrí a cambiar de banco.
He buscado comentarios antiguos míos para ver cuando comenté que vi uno con el logo de windows 98 tras reiniciarse, o al menos el boot (creo que lo llevaba msdos.sys), datan de 2009 y 2010 que lo volví a comentar, si no hay ya, es la "actualización más reciente".
Y los que no tienen XP tienen IBM OS/2. Siguiente artículo.
Todo el mundo sabe que el SO de los cajeros es obsoleto, como el de todas las "appliances" que no se sustituyen frecuentemente. Es otro artículo de una empresa de ciberseguridad para darse importancia.
NOTA: La seguridad de los cajeros es física. Para explotar esas vulnerabilidades tienes que conectarte a algo, y para eso necesitas un taladro de los grandes o una perforadora neumática. Suerte en el intento, te veremos por la tele.
Wow, todavia quedan cajeros con XP que aguantan 15 minutos, increible.
No es comprensible que con el dinero que ganan no sean capaces de actualizar los cajeros.
#14 Precisamente quienes ganan pasta de verdad son quienes no dedican recursos a algo que les retorna menos de lo que les cuesta.
La banca sabe perfectamente cuales son sus pérdidas reales por hackeos de cajeros automáticos, basta hacer un análisis de costes de lo que supondría actualizarlos y decidir si les compensa o no hacerlo.
Si no lo han hecho es por que seguramente las pérdidas por hackeos son perfectamente asumibles y menos costosas que actualizar los equipos y quedar expuestos a nuevos riesgos.
Por favor alguien me puede enviar un tutorial de como hacerlo?, sencillito, a poder ser, gracias.
#19 Envía un dolar a hombre feliz, y te mandaré un usb para que conectes en tu pc, luego tienes que loguearte en paypal...
Ah, y ya de paso, ¿podrías ayudarme a blanquear un dinero que tengo en iraq? Soy un comandante de la OTAN que