Hacking Malaysian Routers

by Keith

Greetings from Malaysia!

I'd like to write about a little hacking expedition I embarked on a couple of months back to help me improve my coding skills, as well as help me learn more about local Internet users.

Malaysia got onto the Internet scene much later than most developed countries.  Our first ISP was only founded in 1992, and even then it was pretty much exclusively dial-up.  Soon the local telecom company, Telekom Malaysia (TM), got into the ISP business and basically killed every other player because as the incumbent government-owned telecommunications company, it alone had access to the phone lines of every Malaysian household.  Until very recently, phone lines in Malaysia were owned by the federal government through Telekom Malaysia, and it was only in the late nineties that a privatization plan opened that up.

During the days of dial-up over PSTN, and even after ADSL connectivity (which still ran over PSTN lines), TM held a monopoly over all Internet subscribers in the country, simply because it owned the phone lines.  Other ISPs struggled to penetrate the market because their offerings couldn't compete with the scale and unfair advantage of TM.

Fortunately, that all changed when TM was laying down fiber-optic cables.  As part of a deal, TM secured a government subsidy to fund the fiber infrastructure, but was forced to allow other ISPs to utilize the last mile.  In theory, this would have increased competition and provided a more level playing field - which it did.  But TM was slow in opening up the last mile, and managed to get a head start of around 400,000 subscribers before any other ISP began to offer a fiber to home Internet connection.

Why am I telling you this?  Because TM doesn't really prioritize security, and I discovered a near perfect storm of security lapses that may prove costly to TM at some point.

As a "legacy" ISP in the country, TM was around when IP addresses were cheap, and IPv4 exhaustion was a prediction, not a reality.  Hence, it managed to secure for itself nearly 2.5 million IP addresses from IANA.  This abundance of IP addresses meant that TM offers all its customers a public facing Internet IP by default, something all other ISPs in Malaysia offer only on request of the subscriber.  I won't go into the details of NAT-ing here, but you can Google it if you're interested.

Secondly, as part of a fiber subscription, TM provides a modem and Wi-Fi router, which is nothing out of the ordinary except that TM sourced all their routers from just two manufacturers, and each manufacturer provided only one router model.  From a security standpoint, having an entire population on a single device isn't a good thing, because a single exploit could take them all out at once, akin to the super-viruses we hear about that could make entire crops extinct because there's so little genetic bio-diversity in industrial agriculture.

Thirdly, TM provide a TV box for free and paid channels streamed to your TV.  Problem is that the TV box requires a complex VLAN segmentation and setup on the router, meaning most routers won't support the TM fiber offering.  This forced most (or all) TM subscribers to continue using whatever router TM provided them with in the first place without the ability to swap the router for a more secure or feature rich one.

All in all, this meant that all of TM's 600,000 fiber subscribers (at the time of this writing) were connected directly to the Internet via a public IP, and most of them continued to use one of the two routers supplied by them.

So far, nothing too exceptional here, except for two last bits.  All of the routers were configured to allow access from the WAN interface (i.e., you could configure the router from the Internet), and all the routers were set up with one of five different username/password combinations by default.  The default passwords (as you may have guessed) were rarely changed, and most users were left completely vulnerable to attack on a device they never even considered would be a target.

In 2007, while the fiber offering was still very new, several hackers in Malaysia alerted TM to the "flaw" in their operating model, but TM maintained that the WAN interface was necessary for "maintenance and support," although they did promise to change all passwords to a unique password per router.  So, here we are in 2015, and I wanted to see just how honest TM were in keeping that promise.

First, I had to get the list of IP addresses that belong to TM.  A quick Google search revealed that TM was AS4788.  AS stands for Autonomous System, a sort of internal network within the Internet and used primarily for BGP routing.  BGP is the Border Gateway Protocol, which defines how IP packets are routed between AS nodes, and the great thing about it is that all this information is public, meaning you can easily determine TM's IP addresses.

Once I had the list of IP addresses, I quickly created a Python script to loop through each individual IP, and determine the HTTP-header of the end device on that IP (if there was one in the first place).  I queried only port 8080 to save time.  Since TM had only two router models, it was pretty trivial to validate the HTTP-header and see if the IP was hosting a vulnerable TM router.  A more professional approach would be to use ZMap or Shodan, but creating your own scripts to do this has its advantages in learning.

IP scanning was easy, and determining if indeed a particular router was on port 8080 of a specific IP address wasn't a tall hurdle to cross.  The much harder portion was to actually test the hypothesis that most of the routers still used the default usernames and passwords.  This meant I had to actually post data via HTTP into the page from my Python script.  This isn't usually a difficult task, but the routers themselves operated a large amount of JavaScript, and that just threw my Python scripts into a tailspin.

Try as I might, I couldn't get it working using just Python.  Eventually, I gave up trying to navigate the router's home page and found Selenium.

Selenium is a tool that allows you to "create robust, browser-based regression automation suites and tests."  In other words, Selenium allows you to control a browser like Firefox or Chrome from a Python script.  This was the holy grail, because the web browser would take care of all the JavaScript nastiness for me, and now I could go deeper into the router configuration settings and poke around to determine other things, like do people even bother to change their Wi-Fi SSID and password?

But Selenium has a performance drawback: a single Python script querying a web page takes a couple of megabytes of RAM, but an entire instance of Firefox kept open could consume a a few hundred megabytes, which severely limited my ability to scale the scanning.  Even after discovering the tool, I tried to go back to just native Python, but that JavaScript stuff just threw me off.

Eventually, I wrote a whole script in Python that would scan an IP range, determine if a router was present at the end of the IP (on port 8080), and then pass that to another script that would use Selenium to interact with a Firefox browser to visit the router's web page, try the handful of default username/passwords, and determine if any of them worked.  And they did!

Of course, while I was in, I poked around to determine things like Wi-Fi SSIDs, etc., but mostly for fun, and I made it a point not to change any setting on the router.

But there's no way I could scale all of this on my home PC or even my laptop.  So I decided to host this on the cloud, and chose to use Amazon - specifically a Windows instance on Amazon.

Initially I decided to host this in Singapore - made sense since I was visiting Malaysians' IPs.  But then I realized that the Oregon data center of Amazon had much cheaper rates than the Singapore one, so I changed my decision and hosted in Oregon instead.  In some cases this was a 20 percent reduction in cost and the expense of "slightly" more latency, but my application wasn't latency sensitive, as much as I was price-sensitive!

Then in true, cheapskate fashion, I decided to toy with Amazon Spot Instances.  This is a special deal from Amazon where they lease unutilized machines to the highest bidder - and you can get this for nearly 50 percent of the price of the "on-demand" Amazon instance.  The only downside is that Amazon reserves the right to terminate your instance at any time - but from my experience of using this, and from the blogs I read, the chances of that happening were pretty slim.

I've run nearly ten of these so far, and every time I spin up a spot-instance, it's never been auto-terminated.  Pretty decent deal - the only real downside is that a spot-instance usually takes about three to five minutes to launch due to the bid processing.  But, other than that, it's as good as an on-demand instance.

With a very powerful Amazon instance that had a large amount of RAM, I could spin up a large number of instances of Firefox to do my bidding.  Using a simple database to ensure all of the instances weren't visiting the same IP addresses, I was able to automate the whole process of visiting TM routers with ease.

Eventually, a single large Amazon instance (procured through a spot-instance method) was able to hack through 10,000 routers in less than 12 hours for under $10.  Quite a good return of investment if you're looking to create your own little bot-net army.

TM have especially dropped the ball here - they now have at least 10,000 vulnerable routers floating on their network waiting to be owned by the next Lizard Squad characters.  I could have easily configured my script to turn off the WAN interface on the router to limit people's exposure, but I thought against making changes on a host system without the owner's explicit permission.

Hopefully, if you're from Malaysia and a TM subscriber, now you know the truth.

Selamat tinggal from Malaysia.