The Issues with Security by Abstinence

Today I want to talk about a prevailing concept in security that I’m hereby referring to as security by abstinence. I know this is a somewhat comical and religious title but we’re going with it and I hope by the end of this you’ll see that its appropriate.

What is Security by Abstinence

Security by abstinence is the concept that if I simply don’t tell you how to do something then you won’t do it. To go with something more specific; if I don’t tell you how to access your server remotely then you won’t do it. This mentality is fundamentally flawed. In cybersecurity we often say that a determined adversary will always find a way. That phrase is also true for end users; when determined an end user will find a way to achieve what they want, and that way may not be safe.

I am a frequent user of Pi-Hole for my network wide adblocking and security based DNS blackholing, but I have frequent disagreements with the developers on the security behind pi-hole. On the r/pi-hole subreddit new users will frequently ask how they can access their Pi-Hole from the internet. The moderators, who are also the developers, will frequently refuse to answer these questions; opting instead to simply tell people to use a VPN instead.

I’ve gotten into a number of arguments with the developers about this, and other topics like the admin dashboard not being SSL secured. The developers have maintained the Pi-Hole has no need of being properly secured because it shouldn’t be exposed to the internet in the first place. However, as I stated earlier, a determined user will find a way. I know this is true because I have Google Analytics and Shodan to prove it.

My most visited page is my article on how to access Pi-Hole from the internet securely, and the most common search terms that bring people in are:

  • access pihole remotely
  • nginx proxy manager pihole
  • pihole nginx proxy manager
  • how to access pihole remotely
  • pi.hole/admin
  • pihole reverse proxy
  • pihole remote access
  • pihole nginx
  • pihole external access
  • pi hole nginx
  • pihole with nginx
  • use pihole remotely
  • And many more

My write up for how to access pi-hole admin interface from the internet averages 25K clicks every 3 months, outpacing my other posts by a factor of 3 to 1.

When you check Shodan for the Pi-Hole admin interface you’ll see any number of results. When I ran this search on September 12th 2021 I got a total of 406 Pi-Hole’s with the admin interface open to the public over insecure ports.

Someo of these results tried to hide the port they were on so that bots wouldn’t spam port 80 but security through obscurity rarely works.

Why is Security by Abstinence a problem

There are two main reasons why Security by Abstinence is a problem. The first reason is simple and I’ve said it already. When an end-user wants to do something they will; even if its the worst way to do it. While I may not be a fan of opening port 80 (or any other HTTP port) to the internet there is technically nothing wrong with it. The problem here comes from users with some knowledge making bad decisions because they can’t get information on how to make good decisions.

When people research how to reach Pi-Hole remotely they will probably come across tutorials on port forwarding. If they aren’t sure about the risks of port forwarding they might forward something they shouldn’t. I realize this is quintessential slippery slope fallacy, but it’s hard to argue against when you see how many people have port forwarded port 53 (DNS) to Pi-Hole.

Over four and a half thousand have opened up a DNS recursive resolver to the internet because they likely didn’t know the danger of things like a DNS Amplification Attack. Users are still going to do what they want anyways, whether or not we tell them how bad of an idea it is.

Furthermore the Pi-Hole Dashboard can give away a lot of information.

This information can be used to tell which Pi-Holes are in active use, which will cause issues in the next section.

The Second Problem: Security by design

Perhaps my greatest complaint about the Pi-Hole project is the developers stance on security by design. The Developers have taken a stance that Pi-Hole is never supposed to be exposed to the internet in any form. Because of this they have adopted some interesting stances on things like failed logins, and HTTPS support. As I noted in an update to my Pi-Hole, lighthttpd is not configured to log failed login attempts. This in turn means that there is no way to set up a fail2ban instance to ban people or bots spamming the login page.

I’ve asked the Pi-Hole devs about this in the past and the answer I got was that Pi-Hole didn’t need this (a basic security feature) because it shouldn’t be on the internet anyways. Security by Abstinence is not security.

A Scenario to Bring it all Together

Let’s imagine for a minute that a user has set up Pi-Hole on their network and they want the ability to check their stats remotely. Maybe they, like me, have less than tech savvy family members who are in school and sometimes need access to blocked websites. While this user is at work they don’t have the ability to VPN in back to their house so they need a way to access the dashboard and unblock domains, or temporarily pause Pi-Hole, when their family calls.

This user goes to the Reddit forums or Pi-Hole forums to ask for a way to access their Pi-Hole remotely. The Developers tell them it’s not made for that and refuse to help (Security by Abstinence). The user now turns to Google and search for “pihole remote access” (which we know is a legitimate search people do based on my logs).

The user learns about port forwarding and DMZing. In a worse case scenario the user places the Pi-Hole in the DMZ. A passing botnet sees the open recursive resolver and uses it in a DNS amplification attack, potentially causing the users ISP to cancel their service and at worst causing them hundreds of dollars in transfer fees with a VPS. But let’s take a step back and say that the user didn’t DMZ their Pi-Hole instead they just port forwarded HTTP.

Shodan scanned their IP and noticed that port 80 was open and pointed towards a Pi-Hole web interface. A nefarious action using Shodan results goes to this admin interface and notices that the Pi-Hole is out of date. (This is another two choices the developers make intentionally. Pi-Hole does not automatically update and the dashboard shows version without login. Again this is done because their belief that Pi-Hole is internal only.)

The nefarious actor sees that the user’s Pi-Hole is running version with a critical vulnerability that provides Root access to the physical device when exploited (Pi-Hole version 5 actually does have a buffer overflow leading to remote code execution.) The nefarious actor reads Pi-Hole documentation, maybe sets up a test Pi-Hole since it’s free, and notices that lighthttpd isn’t logging failed attempts.

Thie nefarious actor uses a free tool like Hydra to attempt to brute force the login password (since it’s password only without a username). Eventually the actor manages to guess the password and not they have access to the users admin interface.

With access to the interface and knowledge that the Pi-Hole is out of date and vulnerable they execute the remote code execution, gaining root level access on the device. With root level access on the device there’s a lot of different things they could do. They could laterally move throughout the network by proxying Metasploit, they could attempt to sniff traffic on a network, or they could

The nefarious actor then modified the /etc/hosts file and sets a common domain like Reddit.com to point to their server. On their server they have a small bit of JavaScript that tells the browser to automatically download and execute some malware. Now every time the user tries to visit Reddit they instead get forced to the nefarious actors drive by download site. Not only are they not able go to Reddit (because the /etc/hosts file is pointing to a different IP) but they are also potentially getting compromised further.

Conclusion

The scenario above may sound a bit dramatic but it’s entirely possible. In the course of looking up this open Pi-Holes for this post most of the ones I saw were running old versions vulnerable to the remote code execution I mentioned. I was encouraged to see a large portion were behind an Nginx reverse proxy which required an SNI to access (I had to know the actual URL to browse).

The scenario above is made possible because of the Developer’s belief that their software does not need to be properly secured because it “should not” be exposed to the internet. Because of that belief the Developers have decided to leave out basic security features like logging failed log in attempts. Rather then implement a proper security posture the Developers choose to use Security by Abstinence and hope that the end user doesn’t make a bad decision without knowing how to make a good decision. Which of course doesn’t work because a determined end users will do what they want.

Author’s Note:

I know I’ve been heavily critical of the Pi-Hole Developer team but I want to say that this is not exclusive to Pi-Hole and despite all these issues I still highly recommend Pi-Hole (especially for parents looking to keep their kids safe online). The Developer team has done amazing work bringing such a fantastic tool to everyone for free. However, fanatics work in one area does not preclude you from criticism in another.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

WordPress Appliance - Powered by TurnKey Linux