During one of my recent YouTube visits I noticed DEF CON had uploaded new talks which meant it was time to check them out. The following talk about DNS Rebinding caught my attention.

Initially this post was made to release way sooner, however I decided to turn the topic into a presentation for a school project. The project went way more in depth on different attack methods which I won’t be explaining here. If you’re interested I suggest you go to this Github wiki which explains the different attack methods.

DNS Rebinding: How it works

Snippet from the video above

DNS Rebinding allows an attacker to bypass the same-origin policy. This policy prevents a malicious website attacker.com from making requests to hosts other than itself such as other websites but also locally hosted websites and services.

Since same-origin policy is based on host names, we can host our own DNS server with a short TTL and change the IP address of the subdomain randomname.attacker.com to the one of another website or point the domain to a local IP address using a DNS reply.

This now means that Javascript code hosted attacker.com is now able to bypass the same-origin policy and make requests towards another site or in my case a locally hosted service.

PoC – Exploiting solar panel inverters

After watching the complete DEFCON video and browsing the singularity framework code on Github and reading through their wiki, I decided I wanted to try performing a DNS rebinding attack myself.

Looking for an appropriate target within my home network, I quickly decided to use my “Omnik” solar panel inverter’s web interface as a target.

Checking if my target is vulnerable

Service accepts arbitrary host headers.

Authorization required?

First, a little backstory:

We were one of the 12.000 people interested in a group purchase of solar panels in 2017 in East-Flanders alone.

I found a guide online on how to setup the Omnik solar inverters, which doesn’t suggest changing the default credentials (admin/admin). Obviously, the technicians who installed the inverter didn’t either.

Even worse: the open WiFi access point for the initial configuration wasn’t disabled after installation. Which means anyone can walk by your house, connect to the access point, sign in with admin/admin and read your main WiFi SSID + password as well as upload new firmware for your solar panel inverter.

Because of this, I think it’s safe to assume that there’s a lot of installations out there with the default credentials still in place.

Target page

The page we’ll be targeting in our PoC looks like this. The WiFi SSID and password are returned on the page which makes it easy for us to fetch the page and extract the SSID and password.

Setting up a domain + server

I started off by buying a cheap domain at Gandi.net and a $5/month server at Linode.com. Obviously you’ll have to change the DNS records for your domain. Mine are as follows:

As for the server itself, it’s as simple as cloning the singularity git repo and following the installation instructions provided at their wiki.

Writing the exploit

Initially I planned on releasing the exploit code on my Github but by now I lost the code and it wasn’t very reliable anyway (mostly due to my poor JS skills). I can however leave a screenshot of the exploit code to give you a general idea.

IGEN-Wifi module for Singularity

Exploit time!

Visiting my website, selecting the payload and pressing the attack button allows me to test my exploit. I only show the SSID in the screenshot but the WiFi password can be obtained in the same way since it’s also returned in plain-text by the webserver.

My successful attack timings ranged from 14 seconds to 1 minute 20 seconds, depending on the attack method used.

As you can see, all it takes is to stay on the website for about a minute to obtain the SSID and password. The exploit can be automated by either guessing the local IP range of a visitor and scanning for running websites in that range using Javascript or by using a local IP leaked by WebRTC and scanning the /24 range of that IP.