Ronny Lam


Abusing Software Defined Networks

In my last post I mentioned that I was going to do less if Software Defined Networking. But @RaymondKuiper got my interest in jut one tweet.

With clear-text wire protocol implementations, little support for switch TLS, no authentication for nodes, poorly conceived rate-limiting features in the controllers, controller APIs that don’t require authentication, and back-door netconf access, the leading platforms Floodlight and OpenDaylight, are ripe for attack.

This was indeed bound to happen. Encryption is part of the standard, but not mandatory. And when it is not mandatory people are not going to use it, especially in lab-environments. This is partly understandable from an Open Source controller perspective. Developing software without encryption is always easier than with. But I do not understand it from the hardware vendors. We have fought and won the ssh-battle a while agon and now we are going back to plain-text protocols?

I good word for OpenDayLight. Thankfully they implemented TLS in their software. It is however turned of by default. Is this a problem? Since we don’t see a lot of production networks yet, it is not. But now is the time to call for awareness. Gregory Pickett did a great job. I can recommend his whitepaper and presentation.

Blog Maintenance

It is amazing that ths blog has been broken for the last couple of months. First of all I have not posted anything for a while. But I have also moved my blog of of Heroku and onto a dedicated webserver. However, all the redirect url’s for the feed where working on Heroku and I forgot to migrate them to ther webserver. Thank god, I have not posted anything, which is a lousy excuse.

I have repaired all the links and I have also, again, thought of revitalizing my blogging scheme. But in order to do that I have to change my content. It’s not that I care about SDN anymore. On the contrary, but I thought it was more of the same to blog about it and in the end I did not blog about it anymore. So that’s why you will see a change in content from now on. You will see more general tech, like I did before, but you will also see more Scouting.

The thing is that, after an 8 year break, I picked up Scouting again. Relocation and starting a family stopped me from serving my old group which I served for almost 25 years and now I started at a new group and am also picking up some national activities. More about those details in future posts.

I Am Using Whatsapp More Then Ever

First of all: you are right! There have not been any posts for almost 4 months on this blog. So this followup is directly connected to the previous one.

Did I say that I was going to quit Whatsapp? Well, the opposite happened. I joined an organization where we are using the medium very intensive. Within this organization the group conversation is being used the most, in multiple groups. And the best thing is that it just works. We get things done very fast. In between decisions are made very fast. And sometimes the conversation is supported by an image. This is the IRC for youngsters.

Telegram, on the other hand, I have not been using a lot. Did I see a lot of activity when Whatsapp joined Facebook, it looks like completely dead. At least to me, I don’t see people join anymore and I don’t get messages through the app anymore.

Talking about Facebook. The organization I just joined does a lot on Facebook. There might just come a time where I can not ignore it anymore. But until that time I’ll still try, very hard.

Bye Bye WhatsApp

This week the great news came out that Facebook acquired WhatsApp for a whopping 19 billion dollars. Word is that the founders were always heads down, very focused on the product, and didn’t even have a sign on the building. They even turned down a bid from Google for 10 billion dollars, but in the end everybody is for sale.

I was never a big fan of WhatsApp, primarily because of the security issues that were involved. They solved most of them, but besides ssl-transportlayer encryption they didn’t secure anything. The problem was though they everybody was on WhatsApp. If you want to reach somebody it was either by SMS/text or WhatsApp, if you wanted a conversation it had to be WhatsApp. But now that the founders sold their soul to Facebook everything is changing.

I myself am not on Facebook, for a very simple reason: I hate the way Mark Zuckerberg is running the show. There are some huge privacy concerns related to Facebook and the way some things get forced on you is just not my cup of tea. I am the first to admit that Google is not clean either. The fact that Facebook is buying WhatsApp is enough reason for me to leave the network and look for an alternative. And it seems that, with me, a lot more people are doing the same thing. Although I find some of them hypocrites, because they are on facebook already.

One such alternative is Telegram. It may not be the best, but again, it is important that all your friends are there. Encryption seems a bit better, since the app is using SHA1 by default, using client-server-client encryption for normal messages and end-to-end client-client encryption for secure messages. But the SHA1 encryption is a bit outdated. I have looked at other apps, but for now stick with Telegram because all the people are there.

Funny thing about getting on early, and have a large addressbook is that I see people joining the network every hour or so. The app is using a telephone number to identify your contacts and in my case it seems that a substantial percentage of people do not have their phone-number anymore that I have in my addressbook. I can check this by the profile picture that people are uploading.

One last thing. I do not think that since a lot of people are joining Telegram that they are leaving WhatsApp. In most cases it is just going to be another network. So while I was hoping that the price of 35 dollars per user that Facebook originally paid effectively would double or even triple, I don’t think it will happen. In the end Facebook/WhatsApp will still have the same amount of users, and other networks also gained on this success. This means that messaging is hot and will stay hot for a while.

Are You IPv6 Ready?

Yay, today I took some time to make most of my domains fully IPv6 enabled. For testing purposes I am using the excellent site IP6.NL which was launched during IPv6 launch-day on 6-6-2012.

IPv6 Ready

Today it all starts with choosing the right domain-registrar. It is amazing that there are still registrars out there that are not running there nameservers on IPv6. Of course you could run your own nameservers, which seems considering some previous posts a good point. But in the end it is a good thing that your registrar is running them on IPv6.

The next important thing is that your DNS allows you to configure AAAA-records, to translate a name into an IPv6-address. And again, there are still registrars that do not have that possibility. My advice would be to move away from them, as soon as possible.

Next thing is to configure your mail-servers to use IPv6. In my case it is very easy, because I run all my domains on Google Apps. And Google is very far ahead of the rest when it comes to IPv6. Of course your DNS MX-records should also point to the IPv6 addresses of your mailservers.

Last point is that both your www-subdomain and apex, i.e. naked, domain should be configured with AAAA-records. And to reflect that, of course your webserver should also be using those IPv6 addresses.

When all this is done and working you get 5 stars from IP6.NL and you will, like me, be added to the Hall of Fame. And while you are on it, don’t forget to dual-stack every other service that is not tested in this basic test.

IPv4 Exhaustion Timeline for 2014 created a great infographic with information provided by Network Utility Force, from which you can view the whole infographic.

IPv4 Exhaustion

It looks like ARIN, the US IP-registry, will be running out of IPv4 address-space by the end of the year. With only 3% of traffic being IPv6, with the US on the lower side, there will be an enormous challenge to speed up migrations/implementations of IPv6.

I am afraid more effort and money will be invested in large Carrier Grade NAT (CGN) solutions than in actual implementations of IPv6. Besides ISP’s being late, also here in the Netherlands, there are some large application and infrastructure service providers which are also behind. Amongst them are providers like Skype and Amazon Web Services, no small kids. If companies like this are going to support native IPv6, instead of some loadbalancing trick, traffic will rise very quickly.

I understand implementation cost can be high which I thinks is only partly true for Skype and AWS, but ISP’s seem to have a hard time getting CPE equipment that supports IPv6 in a stable manner. Implementations within backbone- and core-networks are growing, but the access-layer seems still to be a headache.

How Sensitive Is a Registrar to Social Engineering

In my previous post I wrote about how an attacker was hijacking a domain to get to his victim, having a single character Twitter handle. I also questioned in that post how my own registrar, MijnDomein would handle social engineering techniques. But what I experienced yesterday with the hoster/registrar of my employer is beyond imagination.

I was working with a colleague to enable ssl on all our web-services. Most web-services we are hosting ourselves from Amazon EC2, but there was still one web-service running on a Direct-Admin server at the hoster/registrar. First, the connection to the dashboard is not encrypted, so everything you are doing is world readable. The dashboards gives access to the database, mail options, filesystem, web-service and DNS-zones. We were trying to add an ssl-certificate to the dashboard when it started to complain that you need an individual IP-address for that. So, apparently the IP-address is shared and Direct-Admin is using vhosts or something to differentiate.

That’s when we went to the hoster/registrar’s website and started a chat from there. This chat is encrypted, but not authenticated. You just type your email and question and off goes the chat. We mentioned that we were trying to install an ssl-certificate in our domain. The person on the other side replied that we could use the shared certificate. No, we want to install our own. He replied that we would need to buy an IP-address that would cost 20 euros. 20 euros is a lot of money for an IP-address so we asked when our contract would end. In my opinion this is personal information and we are still not authenticated. He replied with the date which was still 11 month ahead. So we asked him to install the IP-address. The generated an order which would cost 20 euros, unauthenticated.

I bet if we asked him to reset our password or something like that he would still do it. This does not feel good. With this registrar I am sure it is very easy to gain access to an account and hijack domains as mentioned in the previous post. It is people like this that are very dangerous for chain-hacking. It was very easy to get some information that I can use in a further attack. And with this person I am sure I could gain access to the system in the same single chat.

Moral of this story is that you should very thoroughly check your registrar and not only your registrar, but almost every service that you use. Because, as mentioned before, this chain-hacking could lead to serious problems. Out of courtesy I did not mention the names of the hoster/registrar and the Customer Service person, yet.

How I Lost My Twitter Username

Somehow I was stunned by this story of Naoki Hiroshima losing his Twitter Username “@N”. As we know from the past some people find it a game to target short Twitter handles, just for fun. The same happened to Mat Honan a couple of months ago.

The big problem here is chain-hacking. The attacker is using a weakness in one or more other systems to get the right information or change things in order to get to the target. In the case of Mat Honan it was a combination of process vulnerabilities in both Amazon and Apple. In the case of Naoki Hiroshima it is a combination of process vulnerabilities in PayPal and GoDaddy. The trick here was that the attacker would gain and take over access to Naoki’s GoDaddy account and could change the MX-records to reroute Naoki’s email-delivery. When using custom-domains to authenticate account information on certain websites this is indeed a vulnerability and is as strong as the security of the registrar of your domain.

Naoki’s suggestion is a good one. Do not use your custom domain to register with websites, but use a gmail account. One of the commenters also suggests that if you use Google Apps you can use the domain to register. Key here is that it is almost impossible for an attacker to forge the Google DNS.

When asking my own registrar MijnDomein for a response the reply was that this was nearly impossible here because transferring a domain requires a token. The responser obviously did not read the article. My question is what their policies are when someone calls them, crying, that he or she cannot access their account anymore. And comes up with some vague details that everyone can find on the web.

The problem is that chain-hacking is hard to fight. There is always some individual in a company that is vulnerable to die-hard social engineering.

It Is Time for SDN 2.0

Like me and a couple of other people Tom Hollingsworth is fed up with the definition of SDN and especially the abuse of it. We are almost at a point where even the term “cloud” is better defined than “SDN”.

SDN has been reduced to a buzzword that gets attached to anything a vendor is trying to sell.

But to Tom’s credits he is also proposing something new, because the bear is loose. Something new is happening; we are at the era of the long awaited innovation of networking. And SDN wasn’t such a bad name if only the industry wouldn’t abuse it so much. Let’s just call it SDN 2.0, or Superior Defined Networking:

  1. Automated
  2. Programmable
  3. Open

I totally agree on the first two, but the last could be better defined. Open Source is not the only thing. How about open standards and open API?

I like it and we need it, but for a future proof definition it is not too well Superior Defined, yet.

EMA Vendor to Watch: NetYCE

Sometimes hard work pays off. At NetYCE we are providing a solution called “Design Driven Networking” to both large enterprise customers and service providers, delivering end to end configuration and service management. Now Enterprise Management Associates has recognized that we can

deliver unique customer value by solving problems that had previously gone unaddressed or provide value in innovative ways. The designation rewards vendors that dare to go off the beaten path and have defined their own market niches.

NetYCE Vendor to Watch

In this Vendor to Watch report EMA explains our unique proposition which fills the current gap between configuration management and policy enforcement.

“EMA believes that network teams embracing the NetYCE approach could have real hope for eliminating the vast majority of risks that manual network configuration practices present to operational integrity, while also putting them in position to successfully make the transition to the programmable networks of the future.” The best part of all is that they can start with today’s infrastructure and make a smooth transition via a hybrid approach to possibly full-SDN.

I would like to thank the EMA for this reward; the full report can be downloaded here.