Shadow code, una amenaza a tener muy en cuenta

De un tiempo a esta parte, el concepto de Shadow Code ha empezado a emerger como un factor de riesgo. Y aunque sea la primera vez que escuchas este término, es más que probable que lo hayas relacionado, acertadamente, con Shadow IT, es más, podemos englobar Shadow Code dentro de Shadow IT, pero con una diferencia, y es que si de la categoría madre sí que podemos extraer alguna enseñanza, en este caso en concreto poco o nada podemos sacar en positivo. Y la mayoría de las ocasiones será nada en absoluto, si bien sí es cierto que nos puede estar alertando sobre un problema.

Cuando hablamos de Shadow Code, nos referimos a código que no ha sido probado, valorado y aprobado por sus responsables, pero que pese a ello ha llegado de algún modo a nuestra infraestructura. Y aunque así planteado pueda sonar a algo tremendamente inusual, fruto de ciberataques e incursiones ilegítimas en nuestra red, en realidad es algo de lo más común, al punto de que lo poco habitual es encontrar entornos en los que no haya presencia alguna de Shadow Code o que, como mínimo, se den las circunstancias propicias para que esto ocurra.

Y es que, antes de seguir, es importante hacer una aclaración, Shadow Code no es sinónimo de malware. En bastantes ocasiones, en realidad, el código invisible, cumple de manera adecuada con las funciones para las que ha sido implementado y, además, gracias al mismo (al código en sí, claro, no al modo en el que éste se ha incorporado a la red), posiblemente se haya podido acelerar sustancialmente el despliegue de software en la organización.

¿Y cuál es el origen del Shadow Code? Pues ya imaginarás que, en esta ocasión, no estamos hablando de la Dark Web, sino de orígenes tan comunes como GitHub y otros repositorios públicos y proveedores de código. Así, en la mayoría de los casos no es un problema del propio código, sino de si encaja, o no, en nuestras políticas de seguridad y compliance. El problema es que se usa sin aprobaciones y, lo que es más importante, sin la confirmación de que es seguro, cumple y puede operar de manera compatible con otras aplicaciones, sin presentar riesgos.

¿Y a qué riesgos nos podemos enfrentar por culpa del Shadow Code?

Pues podemos poner el foco principalmente en tres: la posible presencia de vulnerabilidades en dicho código, la posible presencia de código malintencionado oculto en la descarga supuestamente legítima, y la incompatibilidad, teniendo en cuenta que aquí no solo hablamos de incompatibilidad técnica, sino también de que el código empleado sea incompatible con nuestros parámetros de seguridad.

• Vulnerabilidades: El uso de código no examinado y no aprobado aumenta el riesgo de que existan vulnerabilidades que un actor de amenazas pueda aprovechar.
• Intención maliciosa: a veces, los actores de amenazas crean código malicioso de manera intencional y lo colocan en depósitos y bibliotecas con la esperanza de que se utilice. Los infiltrados no autorizados también pueden introducir código malicioso en secuencias de comandos propias.
• Incompatibilidad: a veces, una empresa puede desear introducir una nueva característica en un sitio web, como un bot de chat. Entonces, en lugar de escribir la funcionalidad desde cero, el desarrollador (generalmente bajo presión para hacer el trabajo rápidamente) toma el código existente para construir la funcionalidad. Si el desarrollador no examina el código para asegurarse de que sea la última versión y sea compatible con otras aplicaciones conectadas, pueden surgir problemas. 

A este respecto, al hablar de Shadow Code, Security Boulevard recuerda el sonado caso de Ticketmaster, que implementó un chatbot con código de terceros en su página de pagos online, con tan mala suerte que dicha herramienta tenía vulnerabilidades, que fueron explotadas por ciberatacantes que llevaron a cabo una exfiltración de datos. El incidente le costó a Ticketmaster una crisis de reputación, una mancha en su expediente y tener que pagar, en Reino Unido, una multa de 1,25 millones de libras.

La clave, claro, no pasa por renunciar al código desarrollador por terceros, del mismo modo que no cocemos nuestros propios ladrillos de barro para construir nuestras casas. La política que debemos emplear para enfrentarnos al Shadow Code, al igual que en el caso de Shadow IT, acabar con la zona ciega, auditar todo el software que se emplea, independientemente de su origen y, si es necesario, emplear las herramientas que ya existen en el mercado para chequear su seguridad.

Fuente: Muy Seguridad

Suscríbete a nuestro Boletín