¿Cómo puedo mitigar los ataques que se basan en datos envenenados como desarrollador?

1

Hace unos años, hubo un ataque de alto perfil en un editor de Wired, donde los hackers agregaron una tarjeta de crédito a la cuenta amazon del objetivo, luego usaron esa tarjeta de crédito autoaditida para obtener acceso a la cuenta del objetivo. Así que efectivamente envenenaron la base de datos de Amazon para su ataque, y luego la ingeniería social se abrió paso a través.

¿Cómo puede un desarrollador mitigar este vector de ataque específico, a saber, el atacante que usa los datos que ellos mismos agregaron para obtener acceso?

Tenía la idea de que, para el ejemplo anterior, permitiría que se agregue la tarjeta de crédito, pero el usuario no podría usarla para fines de pago o recuperación hasta que haga clic en un enlace de su correo para confirmar. que quería agregarlo, como que ya requerimos verificación por correo electrónico para crear una cuenta. De esa manera, un atacante también tendría que comprometer una segunda cuenta. Y, por supuesto, el representante de atención al cliente no podría hacerlo por sí mismo.

    
pregunta Nzall 30.07.2014 - 13:56
fuente

3 respuestas

3

El ataque que describe ocurre porque la cuenta de usuario es un contenedor de tarjetas de crédito, y Amazon equipara el "conocimiento de un objeto contenido" con el "conocimiento del contenedor". No es sorprendente, porque todos asumen que una tarjeta de crédito debe mantenerse en secreto, por lo tanto, el conocimiento de la tarjeta de crédito era una prueba de que el atacante tenía conocimiento de un secreto.

Para evitar esto, puede verificar a un usuario en función de su conocimiento de la información proporcionada en el momento del registro. Eso significa que cuando un agente abre la pantalla para ayudar a alguien que "no puede recordar su contraseña", debe tener acceso solo a esos datos limitados, no a todos los datos de la cuenta. De lo contrario, podría realizar un ataque similar observando a alguien que realiza una compra, luego llamando a Amazon y diciendo "Por supuesto que soy yo, compré un widget ayer por $ 100 en widgets.com, debería verlo en mi historial de cuenta".

Otra opción sería requerir la validación de todos los datos contenidos. Si la persona que llama dice "mi tarjeta # es 123, es mi cuenta", el agente debería poder preguntar "¿cuántas otras tarjetas hay en la cuenta? Por favor, dígame todos los números de cuenta".

Por supuesto, un mejor enfoque podría ser requerir la validación del usuario antes de permitirle agregar elementos al contenedor. ¿Por qué debería poder agregar una tarjeta de crédito a una cuenta a menos que pueda probar que es su cuenta? ¿Qué beneficio empresarial sirve?

    
respondido por el John Deters 30.07.2014 - 14:41
fuente
0

En realidad, no hay mucho que pueda hacer con respecto a los ataques de ingeniería social, aparte de capacitar mejor a sus empleados que interactúan directamente con los clientes (representantes de atención al cliente) en este caso. Si aprenden cómo hacer más preguntas en caso de sospecha, o actualicen todo el programa de capacitación de seguridad para ellos. De nuevo, como desarrollador no hay mucho que puedas hacer.

    
respondido por el Morpheus 30.07.2014 - 14:32
fuente
0

Esto puede parecer trivial, pero la conciencia es probablemente la respuesta correcta. Muchos bancos tienen pautas estrictas sobre qué información se le puede pedir a un cliente y el mejor enfoque es avisar a los clientes de estas pautas con advertencias durante su navegación o dentro del contrato.

Mi sugerencia sería incluir un cuadro que diga "nunca le pediremos que nos diga su contraseña" o "nunca le pediremos que haga clic en un enlace" o "nunca lo contactaremos por correo electrónico para preguntarle iniciar sesión". También sugeriría que un canal a través de los clientes pueda reportar comportamientos inusuales (phishing, estafa, anomalías, etc.).

    
respondido por el Francesco Manzoni 01.08.2014 - 11:06
fuente

Lea otras preguntas en las etiquetas