Test de penetración, ¿tiene usted permiso?

Estimados amigos del blog,

El otro día estaba en uno de esos eventos pequeños que se organizan en ciudades humildes, sin mucho bombo y caja, pero que reúnen a lo mejorcito de la zona de manera indiscreta XD. Hablando con el señor R.Pinuaga, para mi, uno de los mejores profesionales de este campo nuestro que es el hacking, salieron a relucir algunas experiencias con el tema de los permisos.

En este post voy a intentar aproximaros a varios escenarios ante los que podríamos encontrarnos a la hora de pedir permiso para realizar una auditoría de seguridad o test de intrusión contra una empresa, ya que hacerla sin el consentimiento previo del cliente, propietario etc. es ilegal:

1. Permiso normal del cliente

El caso más habitual es el de contar con un permiso explícito por parte del cliente, incluido en un contrato de no revelación de secreto o NDA, en el que se detalla, en mayor o menor medida, las características de la auditoría y el ámbito de actuación de la misma. En este contrato se deben establecer las direcciones IP, dominios, servicios, incluso horarios en los que podemos realizar nuestras auditorías.

El INCIBE pone a nuestra disposición de un modelo de NDA, pero no contempla los detalles del trabajo.

2. Auditoría BlackBoX

¿Qué pasa con las auditorías Blackbox? Las auditorías Blackbox son aquellas que se realizan sin información previa por parte de la empresa. El auditor debe reconocer los activos de la empresa por sí mismo. Entendemos, pues, que cualquier auditoría del tipo BlackBox puede ser ilegal, ya que en ese proceso de descubrimiento podemos «atacar» a otra empresa, entendiendo como ataque un simple escaneo de red o un bannergrabbing… Ahí queda eso estimados abogados…

3. Reseller o contratista

Cuando alguien que no es el propietario del servicio te pide un trabajo, la mayoría de las veces suelen ser particulares que necesitan servicios de auditoría ILEGALES. Estos cantan a la vista. Por ejemplo: recuperar una clave de no-sé-qué servicio que he perdido, retirar información pública de mi empresa en un website ajeno, «este tío me debe pasta y quiero tumbarle el website»…. Todas estas preguntas, que muchos recibimos en el correo, huelen a ilegal. Hay muchas historietas a contar sobre esto, pero ahora mismo no es el caso.

Vamos a suponer que es una empresa «seria» que subcontrata el servicio de auditoría. ¿Cómo sabes tú, como auditor, que la empresa final ha dado el consentimiento al contratista para realizar la auditoría? Que la empresa contratista parezca seria no es una respuesta válida, ni siquiera que aporten algún documento «firmado» por el CEO de la empresa cliente final. La práctica común es que si el cliente final autoriza el acceso a su sistema, deje en su sistema alguna prueba. Por ejemplo, en algún directorio de la web, un sencillo TXT en el que indique que autoriza el trabajo a tal persona. De esta manera, tendremos más certeza a la hora de confiar en la gestión. Quizá un abogado pondría pegas a este tipo de autorizaciones, pero creo que podría ser válida.

4. Infraestructuras en la nube

Cuando un cliente nos solicita un trabajo, pero sus servidores están alojados en un servicio en la nube, lo que viene siendo un hosting, ¡vaya! Pero… ya sabes que si vas a auditar a una empresa con recursos externos, debes contar con el consentimiento de esta empresa también.

Imagina un servidor en Azure o Amazon y tú con tu botnet de 2.000 equipos tirando un ddos a un cliente. ¿Cómo se toma Azure/Amazon esto?.

Para ambas plataformas existen unos documentos, unos formularios, que has de rellenar y entregar para que ellos sean conscientes de que estás haciendo una auditoría de seguridad y no pongan sus armas defensivas contra ti, o más bien, sus abogados. Os dejo el documento para Amazon y para Azure.

Es cierto que muchas veces, cuando se nos presenta un caso así, se dificulta mucho obtener el acceso, por cuestiones de trámites, de tiempo o de ignorancia. Hay hostings que no tienen este tipo de procedimientos definidos, por lo que pedir un permiso puede ser perder un cliente. En estos casos, el sentido común me hace pensar que en los objetivos alojados en servidores externos, deberíamos prescindir un poco de los ataques directos contra infraestructura, como por ejemplo los ataques DDOS o DOS basados en tamaño, y olvidarnos de secuestrar el BGP, DNS… Ataques de este tipo pueden afectar a todo el hosting y ocasionarnos problemas.

5. Permisos entre departamentos

Este concepto es nuevo para mi, el amigo Ramón comentaba un caso en el que se tenía el permiso de un departamento, por ejemplo, el de auditoría interna, pero no el de IT, o al revés, no sé, pero se presentaba el problema de que dentro de un cliente había quejas ya que no reconocía la valía de ese permiso, incluso habiendo salido de un departamento/cargo con poder… En este caso, manos a la cabeza y a llamar a un buen abogado porque si entre departamentos hay problemas, lo más seguro es que las «leches» al final caigan del lado de los externos.

Creo que en este pequeño recopilatorio he contemplado todos los casos, bueno seguro que no… La casuística y la ley de Murphy siempre están ahí.

¿Nos cuentas tus experiencias u opiniones al respecto?

¡Gracias por leernos!