En Chile, la explotación de vulnerabilidades se ha convertido en uno de los principales problemas de seguridad cibernética del país. De acuerdo con el informe de la Cámara Chilena de Seguridad Cibernética (CCHSC), el número de ataques cibernéticos realizados en el país aumentó un 57% entre 2019 y 2020. Esta cifra nos impulsa a investigar los casos más sonados de explotación de vulnerabilidades en Chile.
Los ciberataques han estado presentes desde los inicios de la informática y la tecnología. A medida que estas se han desarrollado y aumentado su uso, también lo han hecho los ciberataques de forma cada vez más sofisticada y con un impacto cada vez mayor en la seguridad de la información.
LimeSurvey es una aplicación de código abierto escrita en PHP, creada específicamente para realizar encuestas online. Es realmente útil para aquellos usuarios que carecen de conocimientos de programación, ayudándoles a generar un entorno para la recogida de respuestas sobre sus encuestas.
Hace un tiempo atrás, encontramos y reportamos una vulnerabilidad de descarga arbitraria de archivos en Limesurvey, la cual está registrada como CVE-2019-9960. Esta vulnerabilidad permite a un Administrador descargar archivos internos del servidor, a través de un Directory Traversal. La vulnerabilidad afecta a las versiones <= 3.15.9+190214.
Hasta la fecha, LimeSurvey cuenta con un total de 2.192 estrellas en GitHub.
Cuando un usuario exporta la estructura de una encuesta al formato *.lss, se genera un modal con el botón “Descargar archivo”.
El mismo, al ser ejecutado, genera una petición GET a la siguiente URL:
/index.php/admin/export/sa/downloadZip/sZip/pb46rb245xhdv8aqtpebzpbpaw5pb8LimeSurvey utiliza el formato Pretty URL, mediante el cual se realizan llamadas a diferentes acciones en los distintos controladores que componen la aplicación. La URL anterior se estructura de la siguiente manera.
Por un lado, admin/export hace referencia al controlador:
./application/controllers/admin/export.php.sa
En los últimos años, Chile se ha visto afectado por ciberataques cada vez más frecuentes que han afectado a empresas de todos los tamaños. Según el último informe de la Oficina de Seguridad Cibernética del país, en 2020 se registraron más de 5.500 incidentes de ciberseguridad, lo que representa un aumento de un 46% desde el año anterior.
En los últimos años, el número de ciberataques en Latinoamérica ha aumentado. Todos hemos oído hablar de la fuga de información del Ejército Nacional de Colombia, en donde según algunas versiones, fue provocada por agentes de inteligencia de un país cercano, comprometiendo información sensible de operaciones y orientaciones tácticas.
Muchas veces es difícil buscar exploits vinculados a ciertos CVE (Vulnerabilidades y exposiciones comunes). Son casi imposibles de encontrar y, normalmente, no tienen un PoC (Prueba de concepto) sobre la vulnerabilidad.
Existe una vulnerabilidad de inyección de comandos en elFinder, que afecta a la mayoría de las versiones hasta la 2.1.47. La vulnerabilidad se identifica como CVE-2019-9194. Fue reportada por Thomas Chauchefoin y afecta al componente PHP Connector.
En este artículo, nos encargaremos de entenderla. Te mostraremos cómo realizar el proceso para encontrar esta vulnerabilidad 1-day y explotarla, para la creación de un exploit funcional.
El proyecto tiene nada menos que 3.180 estrellas en Github en el momento que se escribió este post, eso puede hacerlo bastante popular.
Y como puedes ver, a través de un simple Google Dork puedes listar un gran número de sitios que tienen una instalación de elFinder, la mayoría de las versiones encontradas son vulnerables.
Al entrar en el Github de elFinder, en el readme, se puede ver en mayúsculas un mensaje que advertía al usuario del peligro de utilizar versiones anteriores o iguales a la 2.1.47. Como se puede ver en las publicaciones, la vulnerabilidad fue parcheada rápidamente en su nueva versión 2.1.48 (Buen trabajo de los desarrolladores).
Luego, se fue directamente a los commits del repositorio para ver cuáles habían sido los cambios, y así tener una idea de dónde estaba la vulnerabilidad.
En el commit, se ve claramente que se hicieron varias modificaciones al código dentro del script PHP elFinderVolumeDriver.class.php, pero sólo uno de los cambios llamó fuertemente la atención.
En la imagen anterior, se puede ver que dentro de la función imgRotate() la variable $path fue modificada por $quotedPath, que se puede ver un poco más arriba de lo que es correctamente saneado mediante el uso de la función escapeshellarg(). Así que nos dirigimos directamente al script FinderVolumeDriver.class.php, para mirar más de cerca el código.
La función imgRotate() se encarga de rotar una imagen JPEG dada por el usuario, para ello utiliza 2 binarios que están instalados en el sistema.
Ambos son clientes de consola cuya función es transformar imágenes JPEG. Puedes ver dentro de la función imgRotate() la existencia de dos IF.
El primer IF verifica si el binario exiftran está instalado en el sistema, en caso contrario, llamará al binario jpegtran (si está instalado). La vulnerabilidad requiere la existencia del primer binario (exiftran) ya que la variable $path no está correctamente saneada y es necesario entrar en dicha condicional para explotar correctamente la Inyección de Comandos.
Una vez que se supo en dónde y cómo se producía la vulnerabilidad, llega el momento de explotarla. Para ello, se subió una imagen JPEG con el siguiente nombre.
1
test.jpeg;touch $(echo -n 2e2e2f66696c65732f70776e6564|xxd -p -r);echo rce.jpegEl payload anterior es responsable de crear un archivo llamado pwned, en el directorio files. Se realizó una codificación de la cadena “../files/pwned” en hexadecimal, ya que había problemas con la / (barra) en el nombre del archivo, donde todo lo que seguía a un carácter de barra era cortado.
Una vez cargada la imagen, se empezó a girarla para que se produjera la inyección de comandos.
En el momento de realizar la rotación, el comando malicioso se inyectó en la variable $path de la siguiente manera.
1
exiftran -i -9 test.jpeg;touch $(echo -n 2e2e2f66696c65732f70776e6564|xxd -p -r);echo rce.jpeg
AWS (Amazon Web Services) es un servicio que ofrece un método sencillo para obtener acceso a servidores, almacenamiento, bases de datos y una amplia gama de servicios de aplicaciones a través de Internet.
Cada vez es más utilizado por pequeñas, medianas y grandes empresas para alojar aplicaciones, guardar imágenes, documentos o crear sus propias redes de una manera bastante sencilla, otorgando un gran nivel de escalabilidad para el usuario. La seguridad en las redes de AWS es crucial a la hora de desarrollar aplicaciones, ya que existen varias vulnerabilidades que podrían exponer información sensible que son esenciales para que un atacante pueda comprometer una red empresarial en la nube.
Este post no explicará en profundidad el uso de la herramienta AWS-CLI, no pretende servir de guía para la gestión de los diferentes servicios que componen AWS, sino que se encargará de detallar ciertos puntos de interés. La información adjunta (imágenes, comandos), corresponde a un caso real, que por motivos de privacidad será censurado para salvaguardar la identidad del cliente.
Existen diferentes formas por las que un atacante podría acceder a la infraestructura en la nube, pero todas ellas requieren obtener las credenciales del usuario IAM, que secompone de dos partes: la primera parte es la access_key que es un identificador del usuario y la segunda parte es la secret_access_key que corresponde a la contraseña necesaria para autenticarse en AWS.
Un atacante podría obtener las claves de sesión a través de la explotación de vulnerabilidades como SSRF (Server-Side Request Forgery), SQL Injection, Full Source Disclosure, RFI, etc. A continuación, explicaremos cómo fue posible obtener ambas claves a través de una de las vulnerabilidades mencionadas anteriormente.
Una de las muchas maneras de identificar si una aplicación está siendo alojada en AWS es hacer una resolución DNS inversa a la IP del servidor.
La dirección IP apunta al dominio de amazon AWS ec2-52-*-*-*.compute-1.amazonaws.com.
Durante las pruebas, se comprobó la existencia de una vulnerabilidad de Blind SQL Injection en una de las funcionalidades de la aplicación y a través de ella, se obtuvo las claves de usuario IAM correspondientes al área de producción. Las claves estaban almacenadas en texto plano dentro de una tabla de la base de datos.
Normalmente en un Penetration Test, un auditor se conformaría con solo incluir las claves obtenidas dentro del informe, es información que puede ser demasiado valiosa para el cliente y que puede tener un efecto devastador si se explota la vulnerabilidad. Sin embargo, quisimos ir más allá y tomar control de una de las instancias EC2 donde corría la aplicación utilizando las credenciales filtradas.
Para ello, se realizaron los siguientes pasos para conseguir acceder por SSH al servidor de producción objetivo. En la siguiente imagen se puede ver un resumen de la metodología utilizada para ello.
AWS-CLI es un cliente para consola escrito en python que permite al usuario interactuar con los diferentes servicios que ofrece AWS. Entre ellos, la posibilidad de operar sobre las instancias EC2, con AWS-CLI es posible crear imágenes AMI de una instancia concreta, arrancar y parar instancias, crear reglas de firewall, grupos de seguridad, entre otras cosas.
Así que lo primero para interactuar cómodamente con AWS es instalar la herramienta.
Una vez completada la instalación, se configuran las credenciales que se obtuvieron previamente a través de la vulnerabilidad SQL Injection.
Después de añadir las claves del usuario, se ejecutó el siguiente comando, para verificar que las credenciales eran válidas y no se trataba de datos que habían caducado hacía tiempo.
Esto dio una lista de los servidores S3 que componían la empresa. En este punto, se ha tomado el control sobre toda la Red EC2 de la Empresa, y para probar los privilegios, se decidió utilizar estos accesos para acceder a la instancia EC2 de producción donde se ejecutaba el sistema principal.
Después de verificar que las credenciales obtenidas funcionaban correctamente, hay que enumerar los privilegios del usuario IAM. Para ello, se utilizó la herramienta nimbostratus.
Nimbostratus es una herramienta de fingerprinting y explotación en redes AWS que entre sus funcionalidades permite crear usuarios IAM, comprobar privilegios, extraer información de la instancia de metadatos, etc.
Lo primero, fue verificar cuáles eran los privilegios del usuario que estaba utilizando.
Como se ve en la imagen de salida, el usuario tenía permiso para ejecutar algunas acciones limitadas en el servicio EC2.
Después de esta acción, se procedió a crear un nuevo usuario con todos los privilegios, esto fue posible debido a que el usuario IAM “produccion”, tenía los permisos de iam:CreateUser.
En este punto, se había logrado crear un usuario con TODOS LOS PRIVILEGIOS en la red de AWS. Ahora, se podría autenticar y cómodamente empezar a manipular al servicio de EC2.
El siguiente paso fue identificar en qué instancia corría la aplicación, para ello tenía que listar todas las instancias que había en EC2.
Mediante el comando anterior, se pudo listar todas las instancias pertenecientes al cliente. Para identificar en qué instancia se ejecutaba la aplicación, sólo tenía que consultar el valor de la clave PublicIpAddress e identificar la que contenía la IP pública del objetivo, así de sencillo.
Una vez identificada la instancia, se obtuvo su InstanceId correspondiente. El siguiente comando devuelve la instancia de destino, haciendo un filtro sobre el InstanceId.
Salida JSON del comando:
{
"Reservations": [
{
"Groups": [],
"Instances": [
{
"VirtualizationType": "hvm",
"SecurityGroups": [
{
"GroupId": "sg-dee387a6",
"GroupName": "Client"
},
{
"GroupId": "sg-d05570a8",
"GroupName": "Frontend Web Servers SG"
},
{
"GroupId": "sg-4c4a6f34",
"GroupName": "RabbitMQ Management Access SG"
},
{
"GroupId": "sg-a3e7aadb",
"GroupName": "RDS PROD Access Group"
},
{
"GroupId": "sg-58cbee20",
"GroupName": "PROD Redis PHPSession Access SG"
}
],
"Tags": [
{
"Value": "Application - PROD",
"Key": "Name"
},
{
"Value": "operacion",
"Key": "Grupo"
}
],
"Monitoring": {
"State": "disabled"
},
"BlockDeviceMappings": [
{
"Ebs": {
"DeleteOnTermination": true,
"AttachTime": "2017-09-28T20:09:44.000Z",
"VolumeId": "vol-03efb6d8259e693ae",
"Status": "attached"
},
"DeviceName": "/dev/sda1"
}
],
"PrivateIpAddress": "10.0.0.57",
"ClientToken": "UDjHC1506629382681",
"Hypervisor": "xen",
"VpcId": "vpc-7d797f19",
"PublicIpAddress": "34.*.*.*",
"SubnetId": "subnet-cf3f8de5",
"PrivateDnsName": "ip-10-0-0-57.ec2.internal",
"ImageId": "ami-11790707",
"KeyName": "Frontend-PROD",
"StateReason": {
"Code": "",
"Message": ""
},
"AmiLaunchIndex": 0,
"SourceDestCheck": true,
"Architecture": "x86_64",
"PublicDnsName": "ec2-34-*-*-*.compute-1.amazonaws.com",
"ProductCodes": [],
"InstanceType": "t2.micro",
"Placement": {
"Tenancy": "default",
"GroupName": "",
"AvailabilityZone": "us-east-1b"
},
"RootDeviceType": "ebs",
"NetworkInterfaces": [
{
"Description": "Primary network interface",
"SourceDestCheck": true,
"Attachment": {
"AttachTime": "2017-09-28T20:09:43.000Z",
"AttachmentId": "eni-attach-3d0239c9",
"DeviceIndex": 0,
"Status": "attached",
"DeleteOnTermination": true
},
"OwnerId": "147200857443",
"Status": "in-use",
"Association": {
"PublicDnsName": "ec2-34-*-*-*.compute-1.amazonaws.com",
"PublicIp": "34.*.*.*",
"IpOwnerId": "147200857443"
},
"NetworkInterfaceId": "eni-2cc990a7",
"PrivateIpAddress": "10.0.0.57",
"MacAddress": "12:84:db:f6:96:cc",
"Groups": [
{
"GroupId": "sg-dee387a6",
"GroupName": "Client"
},
{
"GroupId": "sg-d05570a8",
"GroupName": "Frontend Web Servers SG"
},
{
"GroupId": "sg-4c4a6f34",
"GroupName": "RabbitMQ Management Access SG"
},
{
"GroupId": "sg-a3e7aadb",
"GroupName": "RDS PROD Access Group"
},
{
"GroupId": "sg-58cbee20",
"GroupName": "PROD Redis PHPSession Access SG"
}
],
"PrivateIpAddresses": [
{
"Association": {
"PublicDnsName": "ec2-34-*-*-*.compute-1.amazonaws.com",
"PublicIp": "34.*.*.*",
"IpOwnerId": "147200857443"
},
"PrivateDnsName": "ip-10-0-0-57.ec2.internal",
"Primary": true,
"PrivateIpAddress": "10.0.0.57"
}
],
"VpcId": "vpc-7d797f19",
"Ipv6Addresses": [],
"SubnetId": "subnet-cf3f8de5",
"PrivateDnsName": "ip-10-0-0-57.ec2.internal"
}
],
"EbsOptimized": false,
"IamInstanceProfile": {
"Arn": "arn:aws:iam::147200857443:instance-profile/NGINX-PHPFPM-Role",
"Id": "AIPAIHNPLRX25Y7UN5WWW"
},
"RootDeviceName": "/dev/sda1",
"LaunchTime": "2017-09-28T20:09:43.000Z",
"InstanceId": "i-0b9c16863d2b0edef",
"State": {
"Code": 16,
"Name": "running"
},
"StateTransitionReason": ""
}
],
"ReservationId": "r-0d422c908382bac0b",
"OwnerId": "147200857443"
}
]
}
El open banking llegó para revolucionar la industria financiera. Así como en su momento lo hizo la banca en línea y las aplicaciones móviles. Este protocolo permitió a las plataformas centrarse aún más en el cliente para ofrecerle productos personalizados y facilitarle los movimientos y transacciones financieras que quiera realizar.
Proteger tu plataforma legaltech es algo que tienes que hacer sí o sí, si quieres asegurar el éxito del negocio.
La ciberseguridad en México es un tema que debería ser relevante para todas las empresas que operen en el país o tengan planes de expansión en él.
Hackmetrix 2018. All rights reserved.
