A while ago, we had an internal discussion around people working from home and the technologies/products that could be implemented and/or bought to protect home users. This was due to the implementation of the nationwide lockdown which resulted in companies being forced to change their approach entirely to having employees work from home.
Since I had a Pi-hole installed already, I decided to take a look at this beautiful piece of ad blocking software in more detail, specifically reviewing the code and logic of the application. Because it’s Opensource and available freely, this was easily accomplished by downloading and installing the latest Pi-hole (v5.0 at the time).
It’s worth mentioning that a lot of vulnerabilities had already been found in this software, some overlapped with findings that I had found particularly during April and May, which were rightfully allocated to the first people that reported the issues. With that being said, the Pi-hole is a popular target for researchers and adds a lot of value to people’s home and small office environments, so the more findings and fixes the better. I also wanted to focus on the latest version because of this.
Initially, I had found a few critical security vulnerabilities but many had been found and fixed already and others eventually required local shell access in some form, some functionality had been changed over time, which solved those particular RCE issues too. So, I therefore looked at a few other vectors and decided to focus on one specific attack vector, which looked promising.
Backup Functions:
Settings.php has lots of functionality, one of which allows users to back up and restore (export and import) configurations of the Pi-hole with a limited set of files (teleporter tab).
This was interesting for me because when you export files, they are compressed in tar.gz format and saved. Upon decompression and by systematically reviewing each file that was saved, I found that there were several files which were useful and easy wins for RCE, in particular if no whitelisting and sanitising was taking place. However, those particular ones are not restored if you modify them, re-compress and upload to restore the backup.
In this instance though, the affected files I found are dnsmasq.d configuration files and the adlist.json file. The dnsmasq.d/04-pi-hole-static-dhcp.conf file allows static DHCP leases, which link to MAC, IP and host.
I modified the configuration file for dnsmasq.d initially, in which I added my own code for the host parameter. Once I did this, I recompressed the file accordingly and imported the file back in via teleporter:
Upon browsing to the static DHCP leases section of the Pi-hole web interface, I could see my code was executing correctly i.e. I had found a Code Injection vulnerability.
The same then applied to adlists.json and other parameters in other files, as all the files were not being properly checked upon upload, they also just overwrote whatever was previously there and therefore your code executed accordingly:
Browse to host/admin/groups-adlists.php and you should get the ‘Adam popup’:
There are more examples, however it’s more of the same as what has been discussed above. I would also like to mention, that the Pi-hole is an amazing piece of software, built by people who really care for the community, please support them and donate. All the responses (especially from Adam) were really quick and things were patched exceptionally quickly.
You can browse all the fixes, comments and progress of patching by going here:
