.----------------.---------------------------------------------.------------------. | Nice Name Crew | | 04.August.2008 | .----------------.---------------------------------------------.------------------. The end of your Internet - malware for home routers Welcome to the second technial paper released under the banner of the NiceNameCrew. My name is naxxatoe and we are going to take a look at the security of SOHO. (Small home Small Office) routers. Everybody has a soho device nearby, but nobody really pays much attention to it and why should they? These mystical devices have always been protected by security through obscurity. Most of the research in this area was limited to wireless security. Security researchers seemed to enjoy the idea of obtaining free internet by defeating wireless encryption algorythms. But, we are going to go one step further. The answer is in the box, not the band. This paper will be split into two sections. The first one will give you a brief overview about network setups and the basics of router hacking. After that, we will take a look at the main topic. Malware for soho routers. Before you continue reading, i would like to tell you, that this is not the standard boring as hell technical type of paper you would expect. _THE NETWORK _ Soho networks are simple. Typically there is a router, which is attached to a modem and one or many client computers. In some cases the router may have a integrated modem. There are two possible ways the network may be set up. For this paper, our main focus will be on networking setups using NAT. .____________________. _ _ ..... | .________________. | ( ` )_ / \ | | | | ( ) `) *------------>*Router*-------->* | Computer | | (_ (_ . _) _) \...../ | | | | | *----------------* | Internet .--------------------. _NAT (Network Adress Translation)_ Most soho routers you will run into, will be set up to use network address translation. The router will obtain an ip adress from the ISP (internet service providers) dhcp server and the computer will get an ip address within a private network range (RFC 1918). This way the computer can only communicate with the outside world via the router. The main benefit of this setup is that the router acts as a man in the middle. This design has a lot of benefits and a few drawbacks. The most important one, is the router acts like a natural firewall, shielding the private network (192.168.0.0/16) from the outside world. .__._________________. _ _ ..... | .________________. | ( ` )_ / \ | | | | ( ) `) *------------>*Router*-------->* | Computer | | (_ (_ . _) _) \...../ | | | | | *----------------* | Internet 172.16.0.2 .--------------------. 192.168.1.1 192.168.1.2 _Bridge_ Another option would be a bridged setup. In this case, the router is not a main part of the infrastructure. It will only relay traffic from the isp to the computer without further investigation. In this scenario, the computer recieves the ip adress handed out by the isp. .__._________________. _ _ ..... | .________________. | ( ` )_ / \ | | | | ( ) `) *------------>*Router*-------->* | Computer | | (_ (_ . _) _) \...../ | | | | | *----------------* | Internet (transparent) .--------------------. 172.16.0.2 _POSITION IN THE NETWORK_ In this paper, we will take a look at attacks against routers from two different angles. The first one, will be from the users perspective, the second one from the attackers point of view. Whilst the user sits comfortably inside the network, our attacker wants to perform attacks from the outside. It helps to look at attacks that can be performed within the local network, because we can then understand, how attacks from the outside work. _BASIC ROUTER HACKING_ In the last few years, vendors have taken steps to help the user configure and use the router in an easy and simple way. They have come up with good looking web interfaces, so the user will be without problems. For most routers they can be accesst over http (RFC 2616). More advanced models will also provide the user with the option to configure them over telnet or ssh (RFC 854 & RFC 4251). The soho router market is expanding fast and as the vendors are compeating against each other, they have to cut down on development and production costs, so they can lower their prices. This trend leads to, two very interesting facts - A lot of home routers run linux - the software used is really buggy Now, lets see what we are dealing with. We will focus on three services, we are going to attack. - Webinterfaces - Telnet/Ssh - Other services The easiest way to attack, is the most violent one. Brute force! Password guessing is really violent because it can produce high ammounts of traffic. Nonetheless, it is still very effective. Cheap routers, usually dont even deal with this kind of threat. Over 50% of all routers that where tested, most had no countermeasures, preventing password guessing Every 15 failed login tries, the router could "blacklist" the computer from guessing passwords for 5 minutes. Now for the practial part. In a real scenario, there are a lot of different points where one can try to guess passwords. Some models have only a simple html page with static content that allows the user to login by sending the password. When taking a look at the form, it is easy to discover that the only thing needed to build a program for password guessing is to send the password via HTTP_POST. Other routers use 'http auth basic' or more complicated forms. But it still doesn't provide any security if password guessing is not prevented. If attacking the web interface is not an option, one can still try to guess the password via the ssh or telnet deamon running on some routers. Of course, there are good alternatives to bruteforce. Most web interfaces are really buggy and they have different types of flaws. Attack vectors, reach from checking the cookies in the browser used to take a look at the webpage and changing the cookie set from LOGGED_IN = FALSE to LOGGED_IN = TRUE to information disclosure bugs. For this paper we are going to focus on 4 different routers as we need them for the practical examples later on. But, i have to worn you! There are bugs in every soho router. The ones we use as examples are only to demonstrate different kinds of bugs that may be found in other models. The first one is the speedport 500v given out by T-Com germany. It holds an Authentifcation byepass bug that allows a potential attacker to log into the router and alter the configuration. Once the attacker has gained access to the router via the 'LogInKey' Cookie Parameter Authentication Bypass Vulnerability he may proceed to enable the built in telnet server via another issue that can be exploited in this model. Another option for an attacker, would be to upload a new firmware image and replace the existing one or just simply retrieve any interesting info from the device (usernames, passwords for the authentification with the isp). For this model, there is also a few other bugs that may come in handy later on. Like the b_banner.stm file that can be accessed via the webserver. It holds the password of the router in plain text. The second one is the wrt54gl from linksys. It is a widely deployed product but suffers from a lack of bruteforce prevention. After the password has been guessed, an attacker, may upload a new firmware. This could be a modified openwrt that smells and looks like the original firmware but has some bad features. For early versions of the fonera it was even worse. The lack of bruteforce protection in combination with an input validation in the interface that allowed evil code to be executed. (via http://foneroinsidenetworkipadress/cgi-bin/webif/connection.sh ) Here is a list of things you may find in Webinterface: - Login/Authentification byepass - Information disclosures - Cross site scripting bugs - missing bruteforce prevention - ... _ADVANCED ATTACKS_ All the attacks we have covered so far have one big problem. Most of them can only be performed from inside the network. But before anybody gets exited about how much security this provides, we should take a closer look. Depending on the router model, the user may choose to enable access to the web interface from the outside. In some cases, this is even enabled by default. If the router only allows the Webinterface, ssh/telnet daemon only to be accessed from inside the network, things get complicated. Therefore, we know two different types of attacks that may be performed by any attacker from outside the network. _PUSH_ Push attacks are easy to explain. The router grants full or partial access to its configuration interface to anybody that knows its ip adress (even the public one). After identifying the target, an attacker may exploit any issues and gain full control over the router. _PULL_ Pull attacks are much more complex. The routers configuration interfaces can only be accessed from within the local network. This means that we need to get creative. So how does a pull attack work? - Usually the attacker will try to get the user to carry out the exploit. This can be accomplished in a couple of ways. The best way so far, is to embed javascript/activex/java in a website When the user visits a url there is an abuse dns rebinding to violate the same origin policy of the language. An effective way to carry out attacks on routers would be to build a framework in php that will automatically check the browser id and the system the browser runs on. Depending on this informtion it will then automatically select the right attack to perform and send the evil code to the user. In the last year before this paper was published there have been a lot of attacks against security bugs in browsers that allowed the attack to execute code. This leaves us with the next option. Not only can a attacker potentially abuse any scripting language integrated into the browser to perform attacks against the router, he could also exploit a known issue in a browser and then launch a attack from the computer of the victim. _IDENTIFICATION OF TARGETS_ Depending on the type of attack. The attacker may choose to perform target identification. Mass scanning is possibly the best option for push attacks. For pull attacks however, there is no real target identification because this type of attacks would be best to perform on a big scale. Let us assume that we have a framework for browser exploitation ( similar to mpack,..). We would go and buy ads from ad service companies or do dns cache poisoning attacks to ensure a huge number of humans visit a website that contains our evilcode. _MALWARE FOR ROUTERS_ Why is malware on routers even a interesting topic? - The answer is simple, desktop computers are getting more secure every day. Over time, programers have learned from their mistakes There are better resources available for beginners. Firewall and Av systems have become more secure. Malware authors always face the problem that the code should run as long as possible on as many systems as possible. Botnets are a good example for this. In a huge botnet there is always fluctution going on. Computers getting cleaned, some get re-installed some get thrown away. The bot herder has to compensate this by spreading (infecting fresh systems). But since the security on desktop systems is getting tighter, something has to change. - The target. Getting Malware (or to be more specific bots) to run on routers is very attractive for bot herders. There is less fluctuation going on, there is bad security and its relativly simple. Plus there are close to no limits to what can be achieved. We will now take a look at a few scenarios that can be done with a compromised router. The attacker choose to abuse the maschine for one of the following purposes: - Proxy hosting (So the router can be abused to mask ip adresses and relay network traffic) - DDos (A lot of routers have a good uplink to the internet 6mbit x 200k maschines = fun ) - Fraud (the router may be abused to send mails (for spam/phishing) or host scam pages) - Sniffing (the attacker can monitor the victims traffic and filter out logins to mail accounts,..) - Mitm Attacks (the router may act as a man in the middle for encrypted connections) - Klick fraud (the router may visit pay per click websites) - Traffic Redirection - .... _SEMI AUTOMATIC_ In the whild there have been very few examples of bots attacking routers, but mostly to change some of the router configuration. However there are examples of semi automatic bots attacking routers. The best example for this is the 'D-link r00t3r by gesubambi'. It is a simple shell script that will try to find dlink routers vulnerable to a password information disclosure bug. In what can be considered as the usual way of for semi automatic malware, a botherder would have a version of this running on a hacked linux server. Once the script spits out some Weak routers, the botherder would log into the router and set up a irc bot (like kaiten (a old unix bot)) that connects to a command and control server. From there on, possibilities are unlimited. _SELF SPREADING_ After a while this grew up to be a very hot topic in the "bot herding scene". Rumors spread about fully automatic versions of bots. After a while a bot called hydra made it to the public. It is a irc drone that will automatically spread on dlink routers. All the bot herder has to do is give it instructions on the ip ranges to be scanned. Three is also built in functions to perform denial of service attacks. Luckeyly however there have not been any signs of malware abusing ad networks or dnscachepoisoning,.. to spread via code embedded in websites so far. _DETECTION OF COMPROMISED SYSTEMS_ Detecting if a router has been compromised is a difficult task as we all know. The real problem is that the router does not sit within your network, it is on the edge. This means that we cant simply put a sniffer in front of it and take a look if it is doing anything (ie connecting to a command and control server,...)! The best way to do this is the one that really cuts deep into the users flesh. Simply put at traffic analysis systems at the isp that analyse all network traffic from the user and based on this information detection can be accomplished. This method has only one drawback - there is no privacy. Another way of finding infected systems is to set up low interaction and high interaction honeypots within different ip ranges. Using the high interaction ones to detect 0 day attacks by comparing the systems state to what it was by default every few hours. After deeper analysis low interaction honeypots could be built. This kind of honeypots only emulates vulernbilities and can be used effectivly to find infected systems trying to spread (so they can be taken down). _COPYRIGHT AND OTHER THINGS_ All of the content in tis paper is under Creative Commons Liscense. If you want to use it, you can do it, but the author has to be named and you are only allowed to use it for noncommercial use only. In case you want to use it comercially, plese send a note to me. As you may have noticed i (naxxatoe) did not include any of my poc codes in this paper. At the current time there is close to nothing of what i implemented whilst researching this paper in the public and i am afraid that by releasing more than just the basic info i could cause big trouble.. Legal note: Naxxatoe or NNC are not to be held responsible for any damage, loss, and so on anybody could cause with the knowlege provided in this paper. You are responsible for your own actions. Security Researchers are just curious ppl, we are no criminals! __________________ / ABOUT THE AUTHOR \ *------------.--------------------------------------------------------------------* | Contact: | | .------------. | | Author: naxxatoe (Sebastian Maier) | | Email: naxx@nicenamecrew.com | | Web: http://nicenamecrew.com/ | | Web: http://naxx.nicenamecrew.com/ | *---------------------------------------------------------------------------------* ______________ / GREETS/SHOUTS \ *------------.--------------------------------------------------------------------* | Thanks to: | | .------------. | | All NNC members (Vicious, thule, canthandle, albert for the help and support) | | stefan heineke 'nosleep' - (thx for all the advice and help) | | whoami at rootmybox org - (thx for grammar corrections,...) | | kewagi - (for reviewing this paper and feedback) | | | .------------.--------------------------------------------------------------------. | Greets to: | | .------------. | | id, stel, stranger, cyber, gnu, sniper109, ... @ unkn0wn eu | | Michael Kafka, Rene Peiffer (luchs.at) - (the deepsec.net team) | | Jonny long (author recommends hackersforcharity.org) | | All of the Metalab Members + Joe from joebox.org | | | *---------------------------------------------------------------------------------*