The Security of Porn

The Security of Porn

This post is meant to educate readers about the recent Internet of Things (IOT) Distributed Denial of Service (DDoS) attacks and the lessons learned from them. These are from my own perspective. While I make every effort to be thorough and hit every aspect, there are times that I inadvertently omit things or skip them due to scope, time, length or applicability. Email any questions you have about this or any other topic to blog@advancedpersistentsecurity.net

The opinions expressed in this post do not necessarily reflect those of Joe’s employers: past, present, or future. While I am a security professional, I am not your security professional. The data included in this post is sound by current industry parameters, your mileage may vary.

Introduction

By now, you have probably heard about one, maybe two massive Distributed Denial of Service (DDoS) attacks in recent weeks. The first was Brian Krebs being subjected to a 620 Gbps DDoS. The second, and more noticeable attack against DNS provider, Dyn, which took down parts of Twitter, Amazon, and other Dyn clients infrastructure on the East Coast.

Read the statement from Dyn here.

Upon closer research and critical thinking, I found that from the outside, Porn Hub (I am not linking to them) seem to be doing information security better than some ‘security’ companies. The purpose of this blog is to analyze what they are doing and how it fares in the technology industry as a whole.

My ANALYSIS

General Observations

This should be a lesson to all organizations. PornHub, a non-security, non-tech (aside from encoding and video production) business is showing up industry professionals. To elaborate, they have a well documented and responsive bug bounty program on HackerOne. PornHub will pay between $50 (non-core ‘Other Cross Site Scripting’) and $15,000 (core Remote Shell/Command Execution) for various vulnerabilities discovered and reported responsibly in accordance with HackerOne’s policies.

Observations Specific to the DDoS

In looking at the root cause of the outages of Twitter and Amazon in areas in and around the United States East Coast, single points of failure seem to be the driving force behind the outages. I saw some mention of this on Twitter and I finally stopped procrastinating and did a little research today. Keep in mind that the DDoS was almost two weeks ago. Here are the outputs of the “dig -t NS _____” command, where the blank is one of the following websites:

NSA.gov

This is the output of running dig on NSA.gov
This is the output of running dig on NSA.gov

This indicates that NSA (National Security Agency) uses 6 distinct DNS servers, they seem to all belong to Akamai. Akamai is a well known and respected Content Distribution Network (CDN). This provides some layer of protection from Denial of Service (DoS) attacks. Since NSA is a controversial government entity, they are likely subjected to DoS and other attack attempts often. It is worth noting that the actual NSA.gov site is not tied directly to classified systems, so attacking it is more political and symbolic in nature than productive in leaking classifed and sensitive information. 

Fundamentally, this is somewhat sound in terms of redundancy. They do have the variety of servers for DNS, but again, all with Akamai. While this is discouraged, this site is not critical for NSA operations. If this were for another entity, especially one in e-commerce or social media, this could be disastrous.

NSA.gov Geolocation based on IP
NSA.gov Geolocation based on IP

Note: The pin in Atlanta is erroneous. That is where I was querying from and the UI would not remove that pin.

This shows the Geolocation of NSA.gov’s external DNS servers by IP Address. This is only where the IPs resolve and do not take into account design methodologies like clustering and load balancing. Several hosts resolved to Switzerland. There were a couple that resolved to France and one that resolved to Kansas. This is ironic since NSA is a US government entity and typical policy and guidance under FISMA prohibits the US Government from using computing assets outside the US. Sometimes exception is made to FVEY (Five Eyes; US, UK, Canada, Australia, and New Zealand) countries.

The spread of these geolocations are excellent for disaster recovery and business continuity. The probability of an event occurring in ALL these areas simultaneously in a manner that would disrupt the internet as a whole is minimal or near 0. (Full Disclosure: I am NOT a statistician, so do not hold me to that number) If one server is down via a DoS or DDoS, the others can pick up. While Akamai did experience issues during the Brian Krebs DDoS, I recall hearing that this prompted them to examine their infrastructure and policies and make changes as necessary.

Facebook.com

This is the output of running dig on Facebook.com
This is the output of running dig on Facebook.com

This is unique. Facebook hosts all of their external servers (likely in a cluster configuration) themselves vice outsourcing. I initially searched only for IPv4 addresses. Notice the IPv6 address includes the string “face:booc” for Facebook. From this perspective, this is not entirely sound, assuming they’re not using clusters. Let’s take a closer look at their geolocation.

Facebook.com Geolocation based on IP
Facebook.com Geolocation based on IP

Note: The pin in Atlanta is erroneous. That is where I was querying from and the UI would not remove that pin.

I was appalled that they only had servers in California. Granted Los Angeles is a sizeable distance from the Bay Area (Facebook Headquarters), they are still close enough to experience some of the same issues such as (an improbable) hurricane, earth quake, civil unrest, or terrorist attack. When I added the IPv6 scan, seeing Manitoba was a relief and a reaffirmation.

I recall learning in my CISSP-ISSMP bootcamp that Manitoba was  the disaster recovery capital of the world. The weather is consistent and “boring.” It is also far from California, New York, Texas, etc. As we progress through this, you will see more servers in Manitoba.

Twitter.com

This is the output of running dig on Twitter.com
This is the output of running dig on Twitter.com

Twitter was one website that went down for some users during the Dyn DDoS. While I did perform this analysis AFTER the Dyn DDoS, it shows that they now have a variety of providers in their DNS record. This should be able to help alleviate the traffic burdens should this happen again. Let’s examine their geolocation based on IP addresses.

Tiwtter.com Geolocation based on IP
Tiwtter.com Geolocation based on IP

Note: The pin in Atlanta is erroneous. That is where I was querying from and the UI would not remove that pin.

Twitter also subscribes to Manitoba, as we can tell. I performed this analysis AFTER the Dyn DDoS. This shows us that Twitter is now using Seattle, New Hampshire, and Manitoba. This is a good spread depending on how they have the redundancy set up. During the DDoS, west coast users were not subjected to any down time. This is because of the Seattle server. There are multiple New Hampshire servers as of now. I cannot speak to before the attack.

Pornhub.com

This is the output of running dig on Pornhub.com
This is the output of running dig on Pornhub.com

PornHub is proving to be one of the more security minded entities on the internet today. While they are not precisely in the technology industry, it is certainly a core support tenet in their business strategy. This is in terms of availability, encoding, user accounts, and upload/ingest operations. PornHub seems to “get it” in terms of security. They have a diverse set of IPs/Servers, and providers. This is in addition to their bug bounty program that I previously mentioned.

Pornhub.com Geolocation based on IP
Pornhub.com Geolocation based on IP

Note: The pin in Atlanta is erroneous. That is where I was querying from and the UI would not remove that pin.

Like Twitter and Facebook, Pornhub uses Manitoba in addition to a couple more. While this spread itself is not ideal, there are enough redundant servers to (in theory), provide the necessary redundancy. Consequently, I have no specific traffic statistics on any of these sites, I can provide my analysis of the potential motives behind performing DDOS attacks on any of these sites:

  1. Facebook could be attacked to disrupt social interaction and “for the lulz.”
  2. Twitter could be targeted very much the same as Facebook.
  3. NSA could be targeted “for the lulz,” but most likely for political or hacktivist reasons. This is especially the case since (presumably; in theory) no classified information resides on that domain.
  4. Pornhub could suffer the same fate as Facebook and Twitter for similar reasons or as a by-product of a morality based campaign against porn.

Business Continuity and Disaster Recovery Observations

Some of the companies that I mentioned were resilient in their nature and activated their Business Continuity and Disaster Recovery plans to keep the business online and profitable. Therefore, this is a prime example of why BCP/DRP/Contingency Planning (CP)/Continuity of Operations (COOP) is so important. In conclusion, I have a lot of thoughts about this topic, but I am reserving them for a separate blog post about the Supply Chain Security perspective of this situation as it relates to BCP/DRP/CP/COOP and resiliency.


OTHER APS POSTS

Beware: Walking Dead Phishing Schemes and Malware
NSA Secrets Stolen; Edward Snowden 2.0?
Kim Kardashian: An OSINT Cautionary Tale
Implications of Powershell Going Open Source
Yahoo Data Breach: What We Know Now
Most of What You Need to Know: Wi-Fi
Cybersecurity & the US 2016 Presidential Election
Most of What You Need to Know: Passwords
Twitter Hacked?
Change Your Email Password Now!
Qatar Bank Breached After Bangladesh
Bangladesh Bank Loses 80 Million USD

Thanks for stopping by and checking out our podcast. We would appreciate if you could subscribe (assuming you like what you hear; we think you will).  To learn more about us, check out our “About Us” page.

Enter your email address:


Delivered by FeedBurner

Subscribe to our mailing list

* indicates required



About Joe Gray

Joe Gray is a native of East Tennessee. He joined the U.S. Navy directly out of High School and served for 7 years as a Submarine Navigation Electronics Technician. Since leaving the Navy, Joe has lived and worked in St. Louis, MO, Richmond, VA, and Atlanta, GA. His primary experience is in the Information Assurance (IA) and Cyber Security compliance field. He has worked as a Systems Engineer, Information Systems Auditor, Senior UNIX Administrator, Information Systems Security Officer, and Director of IT Security.

Joe is in pursuit of his PhD in Information Technology (with focus in Information Assurance and Security). His undergraduate and graduate degrees are also in Information Technology (with focus in Information Assurance and Security) from Capella University, where he graduated Summa Cum Laude for both degrees and completed a Graduate Certificate in Business Intelligence. He also is a part-time (Adjunct) Faculty at Georgia Gwinnett College.

Joe holds the (ISC)² CISSP-ISSMP, GIAC GSNA, CompTIA Security+, CompTIA Network+, and CompTIA A+ certifications. In his spare time, Joe enjoys reading news relevant to information security, blogging, bass fishing, and flying his drone in addition to tinkering with and testing scripts in R and Python.