DRM in the modern streaming era (and why HDCP negates it)

Virtually all popular streaming services implement a level of Digital Rights Management (DRM) to protect their content. Whether it's as pervasive as Widevine, or as simple as adding AES-128 to HLS playlists, DRM is seen throughout the industry (including the OTA TV space). However, there's an inherent problem with all DRM solutions in the streaming space: content must be decoded client-side. This has led to a cat and mouse game between content providers and pirates - a game that will never end.

Google's Widevine DRM platform is about as pesky as they come, however this doesn't stop pirates from re-distributing this content on popular torrent sites. But how? The simplest method is via a bypass of High-Bandwidth Digital Copy Protection (HDCP) - another link in the full DRM chain. HDCP is intended to prevent users from copying content played over common display connections (HDMI, DVI, DP, etc.), however HDCP has seen a number of issues throughout the years.

Nearly all of HDCP's iterations have faced significant security problems, limiting its effectiveness. In its current state of 2.3 (which is also backward compatible with 2.2), recording content from an HDMI signal is as simple as purchasing a ~$20 HDMI splitter that strips HDCP, then connecting the output to a capture card for recording. While this isn't as efficient as downloading the content directly, modern compression algorithms (e.g. HEVC), have made this process much less expensive as it relates to file size, while also providing a high-quality end result, including 4K content.

So what does HDCP have to do with Widevine or encrypted HLS playlists? The main point is that your DRM implementation is only as strong as its weakest link. At some point, some level of trust is offloaded - whether it's HDCP or the physical device used to stream the content. Due to the simple nature of how videos must be played, decrypted, and decoded client-side, the "game" will likely never be won by content providers.

CISSP Journey + Tips

At the time of this blog post, a search for "CISSP" on ZipRecruiter yields 693 results for remote positions. It almost needs no introduction - if you've worked in the information security space for any amount of time, you've probably heard of the cert. Recent professional circumstances have made pursuing the CISSP a worthwhile endeavor for me, so I thought I'd share some things that helped me obtain it with about 3 weeks of preparation. (Disclaimer: this may not be one-size fits all advice).

Some quick background: I've worked in infosec for nearly 7 years, the majority of which has been in penetration testing, both as a consultant and as an internal security researcher. I have about a year of experience working as a SOC analyst for a fairly large MSSP. In addition, I have an OSCP which I obtained in 2016 and a (now expired) GXPN that I earned in 2020. My actual work experience, beyond a shadow of a doubt, is where I picked up the vast majority of my knowledge relevant to the exam. If I was starting from scratch, it would have been a much more time consuming study process.

I am not an expert in all 8 domains - and I would venture to say that the majority of CISSP-holders are similar in that regard. But total expertise is not a pre-requisite to pass. I've found the "mile-wide, inch-deep" allegations to be absolutely true. That said, the CISSP isn't a non-technical exam and its technical aspects cannot be ignored. As such, when looking for good, compact technical study material, I happened across Pete Zerger's exam cram on YouTube. This is an amazing resource - and for the material that was mostly new to me, I watched it on repeat until I was nearly finishing his sentences. He'll also opine on whether or not something is likely to come up on the exam and I recommend giving extra attention those parts. There's also the official ISC2 study guide, which I did not personally use, but I've read good things. If I was preparing for longer than 3 weeks, I probably would have used it.

For practice exams, there are two that I can wholeheartedly recommend. The first of which is LearnZapp. You can quiz yourself on each domain separately (which is both good and bad, considering the questions on the CISSP are multi-domain), allowing you to allocate your study areas more effectively. If you get a question wrong, try to understand why, and if you can't, do some research on your own. The questions themselves are far more technical than what you see on the exam, so it's not necessarily going to put you in the exam mindset, which is where Quantum Exams comes into the equation. QE's practice questions are brutally hard, but exceptionally useful. On my final practice exam, I scored a 53/100 and was content (this score is within the standard deviation for folks who've passed). What makes this practice exam useful is that it forces you to slow down, read, and interpret the questions - and it doesn't shy away from the multi-domain aspect of the real thing. I can't say for sure, but I doubt I'd've passed the CISSP on my first attempt if I didn't use QE.

The exam itself is essentially what I expected (mostly thanks to QE). Be prepared for questions that may seem subjective, like "what is the BEST option" or "what is the MOST cost effective solution". The important thing to remember is that it's a multiple choice exam, so don't be afraid to employ relevant strategies. For me, elimination was the key. It was usually easy to eliminate two wrong answers (though picking from the remaining two often felt like a coin flip). I'll be honest, though - I wasn't feeling good about my chances midway through. With 80 minutes left, I clicked submit on question 100 and when the exam ended, I thought I failed, but was pleasantly surprised when I was handed the piece of paper that said "congratulations".

A few final notes: don't rely solely on practice exams to provide the necessary foundation to pass, don't really worry about "thinking like a manager" (just answer the question), don't just practice the areas you're already strong at, and get good sleep the night before the exam. 

Trying Out Security Scenario Generator (SecGen)

The top post on reddit.com/r/netsec this week is a pretty nifty idea: a Vulnerable VM generator. Since vulnerable VMs are my thing, I decided to check it out. Installation is pretty straightforward on Ubuntu, and generating a VM is as simple as "ruby secgen.rb run".

After everything is up and running, an nmap script scan shows a vulnerable IRC server for which a metasploit module exists to exploit.

I go to msfconsole and set everything apropriately and, quickly, I have a low privilege shell (I later upgraded to a full meterpreter shell).

After running "find / -perm -2000 -o -perm -4000" I see nmap is setuid (took me longer than I'd like to admit to find this).

A metasploit module exists to exploit this as well, so root is easy pickings.

So cool that a unique vulnerable VM was conjured in front of me from some Ruby code. Big thanks to Cliffe from GitHub for providing the community with a great resource for learning!

[VulnHub] hackfest2016: Sedna

An nmap scan shows a very similar port list as the first hackfest VM I did. However, this time port 8080 is open.

I find a Tomcat 7 installation...

...however I couldn't login as the manager, so I gave up on this and moved on to enumerating port 80. Uniscan found a few interesting directories.

I couldn't do much with these on their own however. That is until nikto brought up a great point.

I checked license.txt and found a useful piece of information.

I see a "BuilderEngine" installation. I went to the /builderengine/ directory and confirmed it was present. There is an exploit that exists that allowed me to upload an arbitrary file and place it in the /files/ directory on the web server. First I went to the directory used in the exploit to confirm it exists.

Then I copied the exploit code, pasted it in a file called "uploader.html" on my attacking machine and swapped out the link to match the one above.

Then I opened the file in Firefox and uploaded a php reverse shell.

Then I navigated to the /files/ directory on the server and clicked on my shell.php file and get a beautiful reverse shell.

Then I dirty COW my way to root. The exploit kills my shell, however I can just ssh to the "firefart" user it created.

According to the VM details on VulnHub there are two post exploitation flags. I'm fairly certain one of them is the Tomcat7 password found at /etc/tomcat7/tomcat-users.xml.

These credentials allowed me to login to the tomcat manager interface.

The other flag I'm pretty sure is the password for the "crackmeforpoints" user...

...but I'm going to go ahead and let someone else crack that due to my hardware limitations. Overall I really enjoyed this VM; I don't get to use exploit-db enough for web apps in VulnHub VMs so this was a pleasant surprise!

[VulnHub] hackfest2016: Quaoar

An nmap script scan of port 80 shows robots.txt is present. While there were other ports open, the details of the VM strongly suggested a web application is the correct rabbit hole so I decided to investigate that first.

I navigate to it in my browser and find a wordpress installation present.

I immediately go to the admin login and get through with "admin/admin" credentials. The description did say this was a very easy VM after all.

After logging in I navigated to "plugins > editor" and selected the "Mail Masta" plugin (since it was already active) and added a php reverse shell to one of the files. Simply clicking "update" gave me a shell.

I immediately noticed a "wpadmin" user in the /etc/passwd/ file and found the password to be "wpadmin" so I decided to ssh to that user for a more stable shell and I found the first flag.

Going through a file in the "/upload/" directory of the web root, I found a "config.php" file containing root credentials for the MySQL server.

Going along with the "very easy" theme, I tried logging into root with these credentials and was successful!

According to the VM description on VulnHub there is a post exploitation flag on the VM, however I have not been able to find it. I went through the MySQL database and searched through the file system for anything resembling a flag and had no luck. Other than that, this was a very easy VM that was still somewhat satisfying in a weird way. I will be sure to make time for the other two, more difficult hackfest VMs.

[VulnHub] pluck: 1

An nmap scan shows SSH, HTTP, and MySQL open.

Using uniscan, I find a promising LFI link.

Visiting the link I see some juicy information.

Obviously this is a great start, however, I navigated to "/admin.php" and found a very promising SQL error after trying basic injection techniques.

I wasted more time than I'd like to admit trying to leverage this. Trying everything I can think of in sqlmap, I couldn't seem to find any way to exploit this (the reason becomes clear later on).

Moving on with the /etc/passwd file, I see an interesting script associated with the "backup-user" account that might lead to something.

I view the script using the same link I used for /etc/passwd. 

It looks like this script creates a tar backup of the /home and web root directories and puts it in reach of a tftp server. I connect to the tftp server and download the tar file and extract it. 

Looking in paul's directory, I see SSH public key files. 

Logging in with id_key4 I get a "pdmenu" shell.

From here, I select "Edit file" and create a php reverse shell file and place it in paul's home directory.

Then I once again use the LFI and execute the new php file and get a reverse shell.

At this point, my number one concern was figuring out why my SQL injection efforts were futile. Viewing the "admin.php" source code, I can see I was duped. 

Moving on, I dirty COW my way to root and find the flag.

This was an enjoyable VM that gave me flashbacks to working in the OSCP labs which is always something I'm looking for!

[VulnHub] Tr0ll: 2 Privilege Escalation Walkthrough

If you've made it to the low privilege shell in Tr0ll: 2 by exploiting the Bash Shellshock vulnerability, you've probably quickly found the "nothing_to_see_here" directory and the three doors that go along with it.

Each "door" contains a binary owned by root with the SUID bit set. These files will randomly switch directories every few minutes. The one that should be exploited is the largest sized binary (8401). When executed it asks for a user input, which strongly suggests I will be buffer overflowing my way to root. I first open gdb and send a string of 1000 "A's" through the debugger to see if the program crashes. Simply entering 'r "AAAA..."' into the gdb console will do this.

So after entering in the A's you'll see the program did indeed crash. Typing in "i r" (short for "info registers"), the registers and their contents will be displayed. The main register we're looking at here is the EIP register which contains the value "0x41414141" (41414141 is "AAAA" converted from ASCII to hex). EIP is code for "instruction pointer". This register controls the execution flow of a program. By modifying EIP, you can essentially redirect execution flow to an address of your choosing.

Also, after examining the ESP register located at address 0xbffff8c0 (this may be different in your environment) by typing "x 0xbffff8c0" (short for "examine 0xbffff8c0") into the gdb console, I see the string overwrote ESP as well. This is the ideal spot to send EIP.

However, first I'll need to find the exact point in which the string overwrites EIP. To do this, I use a program built in to Kali Linux (pattern_create.rb). This program basically creates a predictable string so we can see exactly where EIP is overwritten. I ask for a string length of 1000 characters once again.

Now that I have the string, I send it through the program which once again crashes.

Now I can copy the contents of EIP and plop it in another program (pattern_offset.rb) and find the exact spot in which EIP is overwritten.

Now that I know EIP is 268 bytes in, I modify my input a little. I use python to print 268 "A's" followed by 4 "B's" which should overwrite EIP.

Perfect! I see EBP still contains the "A's" and EIP now contains the "B's" (42 in hex) like I'd planned. I check to see if ASLR is enabled. I do this by checking the "/proc/sys/kernel/randomize_va_space" file. If the value within the file is 2, it means ASLR is enabled, if it's 0 then it's been disabled. I find out it is disabled, which means ESP should contain a predictable address once our buffer length is set.

Before I check the address at ESP, I add 16 no operation or "NOP" ("\x90") instructions to the buffer. The NOPs will make sure the shellcode will smoothly make it to ESP. After I add the 16 NOPs, my pre-shellcode buffer length is set, so I can take note of the ESP register and I can overwrite EIP.

So from there, I see ESP is at the address 0xbffffb80 (again, note this may be different for you). I replace the "B's" in my buffer with the address in little endian format. My buffer now has 268 "A's" followed by the address of ESP in little endian format ("\x80\xfb\xff\xbf") followed by 16 NOP instructions ("\x90"). Now a shellcode of my choosing can be added to the buffer and will be executed within the SUID binary as the root user. I choose a simple 23 byte "/bin/sh" shellcode.

Now that my final buffer is set, I run the program with my small python script appended and I get a beautiful root shell.

Boom. It's that easy. Of course, if you ignore everything you just read, you could just use Dirty COW and pop a root shell that way.