Egor Homakov, desarrollador y hacker ruso, saltó a la "fama" en 2012 al hacerse admin en GitHub explotando una vulnerabilidad en Ruby on Rails (el framework utilizado por GitHub) que, pese a reportarla con anterioridad, no había sido solucionada. Ahora, Egor anda por San Francisco y nos trae otra bonita historia acerca de cómo encontró una manera de generar una cantidad ilimitada de dinero en tarjetas regalo de Starbucks. ¡Café gratis para siempre!... o hasta que te pillen... :-S
starbucks.com tiene cuentas de usuario, donde se pueden agregar tarjetas de regalo, comprobar saldos e incluso transferir dinero entre estas tarjetas de regalo. Hay un interesante tipo de vulnerabilidades llamada "condición de carrera", que es un error muy común en los sitios web con saldos, vales u otros recursos limitados (sobre todo dinero).
Egor compró tres tarjetas de 5$ cada una. Para transferir dinero de la Tarjeta1 a la Tarjeta2 se realizan dos simples peticiones POST: la primera /step1?amount=1&from=wallet1&to=wallet2 guarda los valores en la sesión y la segunda petición POST/step2?confirm es la que realmente transfiere el dinero y limpia la sesión.
Esto hace que la explotación sea más difícil porque la sesión se destruye inmediatamente después de la petición de confirmación y, si volvemos transferir dinero otra vez, fallará. Pero esta "protección" todavía es fácil de pasar por alto: sólo tenemos que utilizar la misma cuenta en dos navegadores diferentes (con diferentes cookies de sesión).
El pseudo código para la explotación sería:
# prepara los detalles de la tranferencia de dinero en ambas sesiones
curl starbucks/step1 -H «Cookie: session=session1» --data «amount=1&from=wallet1&to=wallet2»
curl starbucks/step1 -H «Cookie: session=session2» --data «amount=1&from=wallet1&to=wallet2»
# envía $1 simultanemamente desde wallet1 a wallet2 usando ambas sesiones
curl starbucks/step2?confirm -H «Cookie: session=session1» & curl starbucks/step2?confirm -H «Cookie: session=session2» &
Después de 5 intentos fallidos, Egor estaba a punto de darse por vencido. Muchos desarrolladores utilizan protecciones insuficientes como limitar el número de peticiones por IP/cuenta/acción, haciendo una pausa aleatoria o mediante transacciones de base de datos de una manera incorrecta. La única manera correcta *y pesimista* de hacerlo es mediante bloqueo (cláusula FOR UPDATE).
Pero sí, la sexta petición creó dos transferencias de 5 dolares desde wallet1 a wallet2, por lo que en vez de tener 10$ en la segunda tarjeta tenía 15$... y para demostrar que no se trata de un error o de algún problema de caché, agarró la tarjeta de 15$ (cuyo saldo había aumentado ++) más la tarjeta de 5$ que tenía adicional (y que no entiendo muy bien para que la quería en esta PoC), se acerco al Starbucks más cercano y...
¡Pero no corrais a comprar tarjetas regalo de Starbucks! Que esto tiene finalfeliz: responsible disclosure.
Egor mandó un correo a InformationSecurityServices_at_starbucks.com el 23 de marzo y, después de buscar y buscar alguien responsable y al que realmente le importara, después de que encima le llamaran de todo menos "bonito", el bug fue solucionado 10 días después.
Y como él bien dice: en vez de notificar la vulnerabilidad, podía haber comprado un montón de tarjetas de regalo falsas en todo el mundo, haber aumentado el saldo de cada una de ellas y haberlas vendido al 50% a cambio de Bitcoins. Y así hasta conseguir 2 millones de dólares (si realmente Starbucks no rastrea los saldos de sus tarjetas). Pero claro, es mejor avisar y que te pongan la cara colorada, es lo que tiene ser de los buenos... pero al menos, y aunque no sea mucho, algunos asentimos, admiramos y respetamos... go, go, go!
Fuente: Hacking Starbucks for unlimited coffee
starbucks.com tiene cuentas de usuario, donde se pueden agregar tarjetas de regalo, comprobar saldos e incluso transferir dinero entre estas tarjetas de regalo. Hay un interesante tipo de vulnerabilidades llamada "condición de carrera", que es un error muy común en los sitios web con saldos, vales u otros recursos limitados (sobre todo dinero).
Egor compró tres tarjetas de 5$ cada una. Para transferir dinero de la Tarjeta1 a la Tarjeta2 se realizan dos simples peticiones POST: la primera /step1?amount=1&from=wallet1&to=wallet2 guarda los valores en la sesión y la segunda petición POST/step2?confirm es la que realmente transfiere el dinero y limpia la sesión.
Esto hace que la explotación sea más difícil porque la sesión se destruye inmediatamente después de la petición de confirmación y, si volvemos transferir dinero otra vez, fallará. Pero esta "protección" todavía es fácil de pasar por alto: sólo tenemos que utilizar la misma cuenta en dos navegadores diferentes (con diferentes cookies de sesión).
El pseudo código para la explotación sería:
# prepara los detalles de la tranferencia de dinero en ambas sesiones
curl starbucks/step1 -H «Cookie: session=session1» --data «amount=1&from=wallet1&to=wallet2»
curl starbucks/step1 -H «Cookie: session=session2» --data «amount=1&from=wallet1&to=wallet2»
# envía $1 simultanemamente desde wallet1 a wallet2 usando ambas sesiones
curl starbucks/step2?confirm -H «Cookie: session=session1» & curl starbucks/step2?confirm -H «Cookie: session=session2» &
Después de 5 intentos fallidos, Egor estaba a punto de darse por vencido. Muchos desarrolladores utilizan protecciones insuficientes como limitar el número de peticiones por IP/cuenta/acción, haciendo una pausa aleatoria o mediante transacciones de base de datos de una manera incorrecta. La única manera correcta *y pesimista* de hacerlo es mediante bloqueo (cláusula FOR UPDATE).
Pero sí, la sexta petición creó dos transferencias de 5 dolares desde wallet1 a wallet2, por lo que en vez de tener 10$ en la segunda tarjeta tenía 15$... y para demostrar que no se trata de un error o de algún problema de caché, agarró la tarjeta de 15$ (cuyo saldo había aumentado ++) más la tarjeta de 5$ que tenía adicional (y que no entiendo muy bien para que la quería en esta PoC), se acerco al Starbucks más cercano y...
¡Pero no corrais a comprar tarjetas regalo de Starbucks! Que esto tiene final
Egor mandó un correo a InformationSecurityServices_at_starbucks.com el 23 de marzo y, después de buscar y buscar alguien responsable y al que realmente le importara, después de que encima le llamaran de todo menos "bonito", el bug fue solucionado 10 días después.
Y como él bien dice: en vez de notificar la vulnerabilidad, podía haber comprado un montón de tarjetas de regalo falsas en todo el mundo, haber aumentado el saldo de cada una de ellas y haberlas vendido al 50% a cambio de Bitcoins. Y así hasta conseguir 2 millones de dólares (si realmente Starbucks no rastrea los saldos de sus tarjetas). Pero claro, es mejor avisar y que te pongan la cara colorada, es lo que tiene ser de los buenos... pero al menos, y aunque no sea mucho, algunos asentimos, admiramos y respetamos... go, go, go!
Fuente: Hacking Starbucks for unlimited coffee
No good deed goes unpunished!
ResponderEliminarsabio, los haxor demuestran una vez mas que somos gente de honor
ResponderEliminarhay que tener lo que hay que tener para no beneficiarte y encima pelearse para que solucionen un fallo que encima les afecta a ellos
ResponderEliminarEthical Hacker!
ResponderEliminarYa me había saboreado mi café ja
ResponderEliminarqueremos cafe gratis!!
ResponderEliminar