SSRF vulnerability via FFmpeg HLS processing

Valeriy Shevchenko
4 min readApr 9, 2019

Once I performed pentest for one famous company. The object of testing was a platform for searching, licensing and managing music with using it on youtube. In the process of testing, I found a form for uploading my videos in the user’s personal account.
But in such a simple action for uploading video, I found two critical security issues.

The first problem was Unrestricted File Upload.
During uploading, you could change Content-Type and upload not only videos files.

POST /user/video/upload/submit/?ajax=1 HTTP/1.1

Content-Disposition: form-data; name="video"; filename="Demo.php"

Actually, the php webshell was loaded for verification reasons.

POC with my webshell

Unfortunately, the page with the loaded shell was with content type plain/text header. And operating with web shell itself was not possible. But this problem is still critical because hackers can upload dangerous files and distribute them from a trusted domain.

The second problem was everyone’s favorite ImageMagick SSRF vulnerability via HLS processing.
After when I discovered Unrestricted File Upload I tried to upload and play a specially crafted playlist.

The playlist has been loaded successfully. And after a few seconds of waiting, the code for the page where I asked to make the request was displayed as a preview.

After that, I made a request to my host to verify the presence of SSRF attacks via ImageMagick.
My theory was confirmed. I received a request to my server.

In this case, a vulnerable version of ImageMagick was displayed in the User-agent.

GET /FFMPEG.avi?.txt HTTP/1.1
User-Agent: Lavf/56.40.101
Accept: */*
Connection: close
Host: 03e***
Icy-MetaData: 1
X-Forwarded-For: 18.***.***.66

So technically I was able to perform a request to the local application server with exposing sensitive data in the video.

Due to the presence of the SSRF vulnerability through the uploaded playlist, I was able to reproduce a small DDOS attack with access to the file and subsequent redirect.

Having gathered all the facts together, I wrote a bug report to the company for which I performed pentest. But after sending the report, I noticed that all files stored in the AWS S3 bucket whose name has nothing to do with the company for which I was performing my pentest. My client also informed me that all problems should be solved in the new version in a month. But a month later it turned out that the music licensing system became independent of the service provider. In fact, the vulnerabilities disappeared from the client application but remained in service provider app. Because service provider was not informed from my client about those vulnerabilities.

By the name of S3 bucket, I managed to find a service provider. And the problem that I discovered was related to a large number of current customers. The list of customers includes quite large firms such as Warner, Sony, Universal, etc.

I quickly managed to find responsible people for the service through LinkedIn. Also through the feedback form, it was possible to make contact with the person who is able to resolve these problems. On the same day, all technical details were sent. A few days later, CEO of this service provider contacted me via email and offered a reward to my PayPal account.

Sometimes it is pleasant to receive even so insignificant bonuses as a thank you. Especially when you don't expect it.




Valeriy Shevchenko

I am a guy passionate about testing and security researching 👨‍💻 →