3. ¿Quiénes somos?
• Juan Antonio Calles
(@jantonioCalles)
• Jefe de Proyectos de
Seguridad en everis
• www.flu-project.com
• elblogdecalles.blogspot.com
4. ¿Quiénes somos?
• Pablo González (@fluproject)
• Responsable de Seguridad
en Informática 64
• www.flu-project.com
• www.seguridadapple.com
• www.windowstecnico.com
7. Entrevista a Carles Pons, director de tecnología
de Akamon Entertainment (mundijuegos.com)
• 9 millones de usuarios registrados
• Presencia en más de 7 países
• Funcionando en varios idiomas.
http://www.securityartwork.es/2013/02/20/entrevista-a-carles-pons-director-de-
tecnologia-de-akamon-entertainment/
8. ¿Qué tipos de ataques son los más generalizados?
Tenemos bastante variedad, aunque nada distintos de los que
suelen ocurrir otras plataformas online: perfiles falsos para
suplantar a usuarios, robo de cuentas, intentos de phishing,
intentos de recargar fichas de forma fraudulenta, ataques de fuerza
bruta…
Con tantos usuarios ¿cómo detectáis y actuáis ante posibles
“tramposos” cuando no se está recibiendo un ataque puramente
tecnológico?
Tenemos un equipo de gestión de usuarios y soporte al cliente que
rápidamente detecta los intentos de hacer trampas, y en ese caso
siempre procedemos con el bloqueo de los tramposos
9. Prácticamente todo el negocio de Akamon depende de vuestros
juegos los cuales están hechos en Flash. Recuerdo que hace pocos
años casi todos estos juegos podían “trampearse” con relativa
facilidad a base de modificar variables con Cheat Engine,
descompiladores de Flash, manipulando las peticiones, etc. ¿Cuál
es el panorama actual de la tecnología Flash con respecto a la
seguridad de las aplicaciones?
Hoy en día este tipo de problemas ya no existen. Basta con mover
toda la lógica de los juegos a la parte del servidor por lo que
cualquier petición o valor que se manipule en el cliente, a la hora de
validarse en el servidor se detectará y corregirá. Desde el reparto de
cartas, el número de tiradas, los valores que sacan los dados, el
número de casillas a moverse,… todo se calcula en el servidor por lo
que está a salvo de este tipo de ataques.
17. Web
• Mismas medidas de seguridad que en un portal web, compras
online, etc.
• Validación de parámetros en servidor en vez de en cliente
• Bastionado de servidores
o Eliminación de servicios innecesarios
o Cuentas sin privilegios de administración
o Bloqueo de USBs, prohibidas las grabadoras
o Etc.
• Separación de actividades por servidores
o Servidor de aplicaciones
o Servidor de bbdd
o Etc.
18. Web
• Protección Anti-DoS y ante ataques de fuerza bruta
• Arquitectura dimensionada a las necesidades
• Actualizaciones periódicas de la infraestructura
• Antivirus
• Filtros de inyecciones web:
o XSS
o Xpath Injection
o Blind Injection
o CSRF
o Path traversal
o SQL Injection
o Etc.
22. Ganar siempre al Apalabrados
• Suplantación de la cookie
del contrincante, si
estamos en la misma red
• Hacer jugadas malas
• Pedir rendirse
• Pedir pasar turno :P
23. Ganar siempre al Mezcladitos
• Si interceptamos las
peticiones con un proxy
podemos modificar la
petición, para hacer uso
de las letras que más nos
convengan.
• Ocurre porque no hay una
validación adecuada en el
lado del servidor
25. Escritorio
• Protección frente a vulnerabilidades de código:
o No hay XSS, CSRF, Path traversal, etc.
o Pero sí hay inyecciones (SQL Injections, Xpath, etc.)
o Buffer overflow (Ej. Exploits Xbox, Wii, etc.)
• Cifrado de datos
o Contraseñas
o Variables importantes del juego
• Ofuscación de código
o Dificultando la vida a los reversers
• Cuidado con la Ram… ¡leches!
o Demo HxD
36. ¿Soluciones?
• Ofuscar el código:
o Por ejemplo, con Eazfuscator o NetReactor (.Net)
• Intentar separar el contenido de una cadena en partes y cifrarlas
por separado:
o Ej. Malo:
password = 123456;
o Ej. Bueno:
p1 = 123;
P2 = 456;
p1=cifrar(p1);
p2=cifrar(p2);
password=p1+p2;
40. Recomendaciones de desarrollo
seguro
• Uso de OWASP Top 10 y OWASP Testing Guide
• Tu app con interacción web:
– Filtrado de parámetros
• Evitar SQL Injection
• Evitar XSS
• Evitar LFI/RFI
– Gestión de cookies
• HTTPs (Only)
– Almacenamiento/envío de valores de manera segura
• Cifrados, conexión segura, certificados, etc.
41. Recomendaciones de desarrollo
seguro
• Lógica en el cliente (error)
– El servidor debe validar cada interacción!!!!
• En el cliente
– Almacenamiento de claves seguro (cifrado)
– Envío de claves y cookies seguro (HTTPs)
– Utilizar mecanismos seguros para borrar valores en la
RAM (problema en Android)
– Evitar claves inseguras en registro (Windows)
– Cookies no permanentes
