Encrypting any application with TCPCrypt

May 28th, 2012

For work, I have been looking into TCPCrypt. I had never heard of it before but knew exactly what it did by its name. After exploring it for a little bit, it is extremely handy, easy to deploy, and not much impact on your system. Here is how it works.

Once you install TCPCrypt, you setup iptables to forward specific traffic to TCPCrypt and if the other host is using TCPCrypt as well, then it will exchange encryption keys and start encrypting the payload of all the traffic on that session.

Hosts identify another TCPCrypt host by adding or looking for a 2 byte TCP option that TCPCrypt has enabled in the SYN. The TCP Option it sets is

0x45 0x02

The 0×45 indicates it is a TCPCrypt host and the 0×02 is the length of the TCPCrypt options in total (in this case 2 bytes). When the server sees the TCPCrypt option in the SYN, it will respond back with a standard SYN ACK except for some additional TCP options just like the original SYN. It will send back something like this

0x45 0x07 0x41 0x05 0x02 0x04 0x04

The second byte in the SYN ACK is, as always, length of the option, 0×41 shows that it is displaying what encryption algorithms it supports and the rest after that are codes for those algorithms.

At this point, the TCP session deviates from the standard 3 way handshake and turns into a 4 way handshake by exchanging INIT1 (0x45 0x03 0x06) and INIT2 (0x45 0x03 0x07) messages that contain keys and couple further bits needed. Once this is done, we should be good to start encrypting.

Now, to actually route traffic through TCPCrypt, you need to set up some iptables rules. The following rules send any traffic across port 23 (Telnet) to TCPCrypt.

iptables -I INPUT -p tcp --sport 23 -j NFQUEUE --queue-num 666
iptables -I INPUT -p tcp --dport 23 -j NFQUEUE --queue-num 666
iptables -I OUTPUT -p tcp --sport 23 -j NFQUEUE --queue-num 666
iptables -I OUTPUT -p tcp --dport 23 -j NFQUEUE --queue-num 666

And just like that…once TCPCrypt is running, all Telnet traffic will be encrypted with hardly any effort nor any knowledge of the actual telnet daemon itself. This works with any application and you just need to swap out port numbers in the iptables rules and you are good to go.

Link to the PCAP of TCPCrypt
Link to the IETF Standards Draft

A quick look at AnonymOS v0.1

March 15th, 2012

A couple of days ago someone (claiming to be) from Anonymous released a prepackaged Ubuntu distro with a whole bunch of tools pre installed. I decided to fire it up in a VM and check what it does on the wire. I would not trust this OS one bit as it is probably backdoored.

The first thing it does (naturally) is send out a DHCP request and once it gets an offer, it immediately tries to join the MDNS IGMP group ( and then performs a whole slew of MDNS queries. Once it is done, with MDNS it will then send out SOA queries to get some information about to domain it lives on. Some more tedious NTP lookups and then we get to some interesting stuff.

At this point, it started scanning the network for Canon printers that ran BJNP (a USB over IP protocol for printing). I do not currently have a printer that uses this but would love to set one up to see exactly why it scans for printers. I am not seeing any current exploits in either exploit-db or Metasploit so your guess as to why it scans for these printers is as good as mine. It did cross my mind that they could throw a 0-day but looking at Anon’s track record this is highly unlikely.

Now, the most interesting thing part of this is that it does a geoip lookup using geoip.ubuntu.com. What it does with this info is again beyond me. As far as I could tell, it was not using this information as I could not see any of the information anywhere in the filesystem. Also keep in mind it does this before you have the option to launch tor. You are not so Anonymous when using this OS.

So far, it looks like a legit OS but I am concerned with why it is scanning for those printers and what it may do with the geoip information but I have not uncovered why it does this yet. I will dig in a little further later.

Black Hat OSPF Vulerabilities

August 31st, 2011

This year at Black Hat, some researchers presented some new ways to inject routes into an OSPF network. I will not go into much technical detail on how they were able to do so but at the very beginning of the talk they made it clear that these methods assumed that the attacker already had the md5 authentication key. After the talk was over, I talked to multiple people about it and was completely surprised at how all of them were brushing it off or playing it down. From just the arguments against the talk, I can conclude that

  • If administrators are not using an authentication key then there are other serious problems
  • A simple authentication password is sufficient enough to stop attackers
  • We haven’t seen it used in the wild so we don’t need to worry

I think that is total and utter bullshit and here is why.

If administrators are not using an authentication key then there are other serious problems:
I am not going to disagree with that at all. It is super easy to turn on the authentication key and there should be no excuse for any semi-competent network administrator to not have done so but we can not assume that, because not everyone has. I can say specifically from my experience in the Network Technical Support realm, 9.8 times out of 10, when walking someone through setting up OSPF on their device, they specifically tell me to not set up an authentication key and enable OSPF on all interfaces. This could be because they want to see it working with the path of least resistance all the way to they don’t think authentication was necessary. Also, every time I went to troubleshoot an OSPF network, I not once saw it enabled. Please keep in mind that I have worked with some very LARGE companies with big teams dedicated to administrating their network and securing it.

A simple authentication password is sufficient enough to stop attackers:
I spoke with one friend who specifically stated “I got up and left once they said they assumed you already had the key.” With all the preaching about how it is so easy to abuse passwords and how we need a better system because passwords suck, I would have expected to hear a different response because thats all the authentication key is, a password. We have been cracking passwords for a long long time now and there has even been a very successful contest at Defcon the past few years aimed at cracking as many passwords as you can in 3 days. You will be amazed to see how many passwords they crack every year. In essence, it isn’t hard to crack a password these days. If you throw a team of Nvidia GPU’s at the problem, it can be solved in no time. Also, don’t forget about the speed of using rainbow tables. Oh, and there are also web based services revolving around cracking passwords. If there were not already a plethora of options for cracking passwords, here is a shot of me brute forcing an OSPF authentication key with loki

And since I am doing this just to prove a point and don’t want to wait for the brute force to complete, here is a shot of me successfully getting the authentication key via a wordlist

We haven’t seen it used in the wild so we don’t need to worry:
Out of any of the responses I have heard, this is the most absurd. I don’t feel I should have to say this to anyone involved in the Security Community but here it goes anyway.

Just because you haven’t seen it does not mean it is not currently or will never be exploited.

If I have to explain this then please give up reading anything else I have to say for the rest of time.



I think this is a very viable attack method that everyone else has been discrediting and playing down when they shouldn’t be.

lulzsec, a catalyst for change?

June 15th, 2011

Big headlining breaches are all over the news these days and the star of the show recently has been the group lulzsec. Lulzsec is extremely popular on Twitter right now due to their extremely cavalier approach to securing the Internet. As their name implies, they are in it just for the lulz and because it is just for the lulz, they put no restrictions on themselves. They gain access to companies, post stolen information, and openly mock said company for not being secure enough to stop them. Some agree with what they are doing and some disagree but the big question I have see is “Is lulzsec a necessary evil that will get companies to actually pay attention to the security of their own systems?”

I have heard security guys, for years, preach that companies are only skating by with the bear minimum when it comes to the security of their IT infrastructure. Its the mentality that you set the bar just slightly higher than your competitor so that attackers peruse the other guy first. From a business standpoint, I can see where it makes sense. You (theoretically) come out ahead with much less resources spent on the issue but it does not take the persistent threat into account and lulzsec is proving that. Notice how I left “advanced” out of that last statement? Persistence can triumph with a lack of advanced. As it appears right now, lulzsec is not advanced at all as they are utilizing basic SQL injection tactics to obliterate these companies. But are they a necessary evil?

I would have to say yes. Currently, there is no system that leaves companies accountable for less than reasonable security practices. I would like to point out the TJX breach as a prime example. After a breach of almost 50 million credit card numbers (by a WEP network), it seems they are going strong. I believe that they are still going strong because they play the roll of the innocent victim and people identify with that and continue shopping there. If lulzsec were to have been responsible for the TJX breach, there would have been no incentive to stay quiet for personal gain, and TJX couldn’t have played the victim card because lulzec would be publicly bashing them for having less than standard security practices. You can’t play victim when the main reasons you were breaches was because you aren’t doing it right to begin with.

I am personally cheering lulzsec on. Yes, what they are doing is illegal. Yes, they are hurting innocent bystanders in the process. And yes, they are causing catastrophe but until we come up with a better system for making companies accountable….we might as well have some lulz as we watch them be humiliated.

Huge Compromises

April 27th, 2011

The media has definitely been busy the past few months. There have been some very high priority compromises and news generating events recently. Some of the big headlines have been Epsilon breached and customer emails stolen, RSA SecurID compromised, Another attack against Iran?, FBI takes offensive against Coreflood Botnet, and Sony Playstation Network compromised and ALL personal data stolen. The term APT (advanced persistent threat) has also been thrown around in a lot of the compromises and it makes me wonder if these are isolated insentients or if they may be related in some way. Can we also expect to keep getting some of these high profile compromises or will they die down?

I love a good conspiracy so I would like to hear that they are all related and this Blog post by Krypt3ia strengthens my belief even more that China is up to no good and possibly ramping up for an all out attack in the Cyber Domain. Only time will tell but until then, I will keep theorizing about my conspiracies.

); ?http://www.statcounter.com/free_hit_counter.html