Capturing DVB-S2 signals on Windows with EBSpro

Since re-purposing my old DirecTV satellite installation into a free-to-air Ku satellite system, one of the first things I purchased was a PCIe card/DVB-S2 tuner (specifically the TBS 6902) which accepts a coax input from the LNB attached to my 39" satellite dish. Before attempting to capture signals, however, you have to make sure your dish is correctly aligned. For that, I splurged and purchased a digital satellite finder so I could ensure a proper lock on the satellite. If you don't have a strong lock, you're not going to be happy with the end-result of your capture. 

On Windows there are a few software options for ingesting DVB-S2 transmissions. Personally, I use EBSpro 18.0.0.4 which is now freeware. (Note: as far as I can tell, the official site hosting this software no longer exists, so not only is it no longer maintained, you can only find it from unofficial sources, and for that reason, I will not be sharing a download link). If you have a tuner card (and its drivers) installed, EBSpro should detect it automatically. 

My TBS 6902 shown in EBSpro

From there, you have a few options. You can opt for a blindscan which will scan through a custom range of frequencies and symbol rates, though I've found my particular card does not work well with EBSpro for blindscanning. Or, if you know the frequency, symbol rate, and polarity to which you want to tune, you can navigate to "Tools>Signal Analyzer>DT Mode" to enter the data manually. In this case, because my dish is pointed at the Galaxy 19 satellite at 97°W, I'll choose the mux at 12185 H 22500.

Signal Analyzer

After clicking "Lock Transponder", if your dish is correctly aligned, you should see a list of channels under "TSA (OK)".

List of PIDs

Now you have a few options for capturing. You can opt to capture the mux (and all its PIDs) in its entirety (which would be quite a bit of data), or you can capture an individual channel. If you opt for capturing the entire mux, you'll be left with a .ts file with several programs. In VLC, you can choose between the programs by right clicking in the video view, then navigating to "Playback>Program". If you're just capturing a single channel, simply right click on the channel you wish to capture, then select "TS Grabber" and click "Record". This will create a transport stream media file for playback and, provided the channel does not have encryption flags enabled, will be compatible with the vast majority of media players/media servers (such as Plex).

This is where you can select which elements of the TS you'd like to capture. Some channels have many redundant audio tracks that you may not wish to capture, so this is where you'd de-select them

.

C-Band Satellite Dishes (AKA the "Big, Ugly Dish")

 

C-Band satellite dish

Ever been driving in the countryside and spot one of those big, ugly satellite dishes in someone's yard and wonder what the hell they're using it for? (It's not to communicate with aliens). Chances are, it's not being used anymore, BUT not only did they serve a purpose years ago, they still have a valid use case today.

In North America (and the rest of the world), C-Band satellite signals (and its little sibling Ku-band) are primarily used for backhaul feeds, which, in short, is a way for broadcasters to transmit content not yet meant for viewing from consumers. For example, on Super Bowl Sunday, the production crew on-site will uplink this "backhaul" feed to one of the North American satellites, only for it to bounce back to the broadcaster where they finish production (adding commercials, finalizing the audio mix, applying compression, etc.). Nowadays, these feeds are usually encrypted (more on that later), so the average Joe won't be able to watch the content, but this wasn't always the case.

In the 80s and 90s, broadcasters were using this technology without applying encryption, also know as free-to-air television (FTA). As such, if you had the means (and the know-how) to set up one of these big ugly dishes, you could get access to virtually any television channel and backhaul feed. You could find news anchors, reporters, or sports commentators talking on a hot mic, being none the wiser that these transmissions were in the clear. 

Eventually, broadcasters and TV providers caught on and started applying encryption (AKA signal scrambling) as a form of DRM, much to the dismay of satellite enthusiasts, such as Captain Midnight, who hijacked HBO's Galaxy 1 satellite signal after the company enabled encryption on their channels. This trend would continue and slowly but surely, C-Band dishes have fallen out of favor with the majority of Americans. 

Captain Midnight's friendly message to HBO subscribers (with a warning to Showtime)

Today, the vast majority of satellite backhaul feeds apply what's known as BISS encryption. Is cracking this encryption possible? Well, I won't ever endorse doing this, because de-scrambling satellite signals is illegal in the US (and elsewhere), but, if each key is 16 digit hex, and you're using a CUDA-accelerated GPU, well... I'll let you do the math. But aside from the legal concerns, finding and installing a C-Band dish is not an easy feat. These dishes usually range from 6 to 12 feet in diameter and require precise positioning to get a reliable signal, to say nothing of the issue of 5G interference. There's also the trouble of finding/purchasing one. In the US, few, if any of these dishes are available for purchase and your best bet would be third party marketplaces like Craigslist or Facebook Marketplace (lots of people just want to get rid of them).

If committing felonies isn't your thing, there is still a non-insignificant amount of content that is free-to-air over both C and Ku-band. Rick Caylor's Satellite Wildfeed and Backhaul Forum is still used today by satellite enthusiasts who scour the North American satellites for television signals and share them for all, welcoming newcomers to this fun and engaging hobby.

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.