Introduction
In this post, I will detail my experience discovering and reporting a content disclosure vulnerability in Microsoft Sharepoint Stream (VULN-145248).
The vulnerability allowed unauthorized access to video content by bypassing download restriction permissions. I’ll share the technical details, impact, and Microsoft’s response while adhering to responsible disclosure practices.
Discovery & Research Process
In other words, the company’s internal video is actually Public!
I was preparing some material for an internal GenAI training session when I stumbled upon the vulnerability. I was watching a previously recorded video call that was shared with me by one of my teammates on our internal Sharepoint Stream.
During my research, I wondered if Sharepoint’s video download permissions (Which I didn’t have) could be bypassed, allowing unauthorized offline access to the content.
Curious, I started inspecting the video player’s network requests and found that the video content was being streamed from a URL pointing to a unencrypted video manifest file that was accessible without any authentication. I was able to stream the video by directly accessing the URL on Safari, in an incognito session, and on a different device. In other words, the company’s internal video is actually Public!
Consequently, I was able to download the video content by using a simple combination of curl and ffmpeg. I was able to reproduce the issue multiple times, and I was able to download the video content without any restrictions.
I went to Pedro Tarrinho, our resident Security Lord and Saviour Head of Application Security in Celfocus, to discuss the issue and get his opinion. He suggested I report it to Microsoft’s MSRC.
(Not very) Technical Details
Sharepoint’s video manifests are very similar to that of Karl Marx’s: open and accessible to all.
Video Manifest File
Most websites try to offer a “smart” streaming service to serve videos in multiple resolutions and bitrates. This is done by providing a manifest file that contains the video’s metadata and the URLs to the video chunks. The video player then requests these chunks and stitches them together to play the video.
An example of such file(s) is the m3u8 format, which is a playlist file used by various video players to play video content. The file contains a list of video chunks, their duration, and the URL to the video content:
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=4400000,RESOLUTION=3840x2160, CODECS="avc1.42e030,mp4a.40.2"
/processing_video/2160/manifest.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-KEY:METHOD=AES-128,URI="aes.key",IV=0x07B1D7401B75CA2937353EC4550FEE5D
#EXTINF:4.000000,
0000.ts
#EXTINF:4.000000,
0001.ts
#EXTINF:4.000000,
0002.ts
#EXTINF:4.000000,
0003.ts
#EXTINF:4.000000,
0004.ts
#EXTINF:0.120000,
0005.ts
#EXT-X-ENDLIST
Manifest Security (or lack thereof)
While secure manifest files require authentication and encryption, Sharepoint’s video manifests are very similar to that of Karl Marx’s: open and accessible to all.
Some manifest files can include encryption keys and require authentication tokens, Google even has a patent on the topic (of course they do). This ensures that only authorized users can access the video content. And let’s not forget the most polarising technique: DRM.
MSRC Report & Response
it’s dangerous to ignore the fact an insider without access to download permissions could exploit this vulnerability.
Following Pedro’s advice, I reported the vulnerability to Microsoft’s MSRC. I provided a detailed report of the vulnerability, including the steps to reproduce it, the impact, and the potential risks. I also included a video demonstration of the vulnerability in action.
However, Microsoft’s response was somewhat expected. They acknowledged the report but stated that the issue was “low severity” and that they see it as a bug. They also mentioned that the issue was not eligible for a bounty reward.
“We have shared your report with the team responsible for maintaining the product or service and they will consider a potential future fix, taking the appropriate action as needed to help keep customers protected.”
– Microsoft MSRC
What I disagree with was another statement they made: “this requires a malicious insider.” While this is true in a sense, it’s dangerous to ignore the fact an insider without access to download permissions could exploit this vulnerability.
Conclusion
The issue was reported to Microsoft’s MSRC, who acknowledged the report but deemed it “low severity” and ineligible for a bounty reward. The vulnerability remains unpatched, and the potential risks of exploitation are still present.
I hope this post sheds light on the importance of responsible disclosure practices and the need for companies to take security vulnerabilities seriously, regardless of their perceived severity.