The Things Network hacking event write-up

The Things Network hacking event write-up

DearBytesBlogThe Things Network hacking event write-up

dinsdag 21 november 2017

HackTalk! It was already the second edition and this time it was all about The Things Network. For those not familiar with this platform, it is a community based network that allows LoraWan devices to connect using a low frequency grid. It really sounds promising when we can put sensors in boats, lampposts or bycicle tires that are cheap and low powered. Depending on the type of sensor, the battery can have a life span of a couple of years and using LoraWAN the signal can travel for a couple of miles. But how secure is The Things Network?

HackTalk (organized by Chris van ‘t Hof) teamed up with The Things Network and organized a hacking challenge to test the security of the community based platform. Together with 32 hackers we tried to find vulnerabilities within the Lora Protocol, the gateways and the cloud based infrastructure. Who would become a true “lord of the things”. With everything in scope (except the social engineering of the organization) there was a lot of ground to cover. Together with a couple of colleagues from the DearBytes Offensive Security department, we teamed up and took the challenge and had a good time. 🙂

Within the first minutes we disconnected the first gateway and connected our prepared switch with a SPAN port. While Eavesdropping on the line we quickly discovered the internal IP-addresses of the locally installed gateways. We started to attack the devices on all levels, both hardware and software based. While one was testing the gateway interface, the other was looking at the Cloud based website. It didn’t take long before we had our first finding allowing us to gain access to quite a few accounts from other users. Let us explain but before we go into any of the details we would like to congratulate The Things Network Community with the speed of fixing this issue (within one hour!). They were able to patch the issue and do a deployment of their new system in production before we had the chance to see if we could abuse this vulnerability even further. That is a nice example of Continuous Integration. So, without further hesitation, here is one of our price winning findings (as the other cannot be disclosed yet 😉).

First, let’s login to the Things Network Website:

If you are a website developer you would probably know how sessions work. You first login to a website using your credentials and if they are correct, the server will provide you with a randomized string which you can use as a session token. As long as the session is valid, you won’t have to enter your credentials. But if anyone manages to obtain your session token, he or she will be able to take over your session and impersonate the user. This is why we always want to use strongly randomized session tokens to prevent attackers from guessing a correct token.

So here is an example of the session token provided by the website after successfully logged in.

The session token indeed looks random… but there is a catch. Some of you might have noticed the “=” in the end. This little “random” string is in fact a Base64 encoded identifier. What would we get when we decode it?


We discovered that the session identifier is based on the users ID. This means that if you know someone’s ID, you can simply base64 encode it, and impersonate this user. It’s nearly impossible to correctly “guess” the correct identifier for a certain user but still we were able to do something which made this issue became “THE MOST FEARSUM HACK” of the evening. By combining this vulnerability with two simple feature that are provided on the Things website we were able to increase the impact rapidly. We’ll try to explain them one by one and let you decide how they work together.

For starters, there is the Things API. This API allows software developers to create their own apps and services, using the information publicly available in the Things Network. One of the features within the API is the “gateways”-extension which you can use to query a gateway by its EUI-number and list its public information. This is an example of such gateway:

See what we have there? It is the identifier of the user owning this gateway. Don’t get too excited because querying all gateways (by brute forcing the EUI) one by one to extract identifiers will take quite a while and it isn’t stealthy. We will need to find a list of all gateways and the API doesn’t support a feature that says “list them all”. Luckily one of us found a hidden gem stored in the root of the main website (the Things Map functionality):

To compromise all accounts that have a public gateway you can write a little script that extracts the EUI numbers from this file and query the REST API one by one. From there, you extract its owner, extract the ID for the user, modify your cookie and access to the account is obtained:And what is even nicer is that we can persistently gain control over your account simply by changing your e-mail address and reset the password. A confirmation e-mail of this modification is send to the new e-mail address (which should be the old one as well).

For a short while we were able to access all accounts that have a public gateway registered by faking our session cookie. We didn’t get too much out of it because The Things Network Community was able to patch the issue before we were able to query the gateways, also the impact of our bug was already proven and there was no need to. They really have their Continuous Integration and Automated Deployments nicely taken care off. They also promised to implement a recovery feature, sending the notification e-mail to both the current as the new e-mail address and allowing the old e-mail address to undo the action. Our deep respect for quickly fixing the reported vulnerabilities.

Final Words

There is only so much you can do in 5 hours of bug hunting. Still, together with 32 others we were able to help The Things Community and made new friends in the progress. The Things Network is open to improve the security of the network, this is the reason why they teamed up with Hacktalk to organize this event. This is an awesome initiative from The Things Network and Hacktalk. More information on the fix from The Things Network:

We fixed a security issue in the Account Server that allowed altering session cookies. This issue has been reported to the core team following the rules of responsible disclosure during an ethical hacking session in which The Things Network core team participated. The fix was deployed 30 minutes after reporting confidentially. Also, we reset all sessions of all users on all devices to require people to login and ensure safety of their session.

The Things Network also added a responsible disclosure page to their website, which allows security researchers to report security vulnerabilities in a correct way. We would like to thank HackTalk and the Things Community for their effort in organising the event and hope they will continue the good work!