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

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.

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

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

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.

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.

I spent the last few minutes working on setting up Kippo. Kippo is a medium interactive ssh honeypot. Basically what Kippo does is start up a ssh daemon and then monitor ssh brute force attempts and then if the attacker is successful in gaining access, it logs all of the commands that are run on it, and captures all the tools that are downloaded to it. It was fairly simple to set up on a Ubuntu 10.10 machine so here we go:

First we want to go ahead and take care of a simple dependency

metacortex@ubuntu:~/SecTools/kippo$ sudo aptitude install python-twisted-conch python-twisted-web

Once we have conch installed, go ahead and download kippo and extract it

metacortex@ubuntu:~/SecTools/kippo$ wget http://kippo.googlecode.com/files/kippo-0.5.tar.gz
metacortex@ubuntu:~/SecTools/kippo$ tar -zxvf kippo-0.5.tar.gz
metacortex@ubuntu:~/SecTools/kippo$ cd kippo-0.5

You will now see the following files

metacortex@ubuntu:~/SecTools/kippo/kippo-0.5$ ls
data dl doc fs.pickle honeyfs kippo kippo.cfg kippo.tac log start.sh txtcmds utils

From here we want to go ahead and edit the config file (kippo.cfg). There are a few special lines you may want to change.

ssh_port = 2222

Please note that you can not run Kippo as root so you are going to want to choose a port number to listen on that does not require root privileges. I would like to have Kippo open on 22 so what I have done is forward port 22 to port 2222 on my firewall.

hostname = sales

This is the hostname that you will see once you successfully log in.

password = 123456

This will be the password for root and will allow access.

Once we get the config all ready we want to go ahead and start kippo. Remember we are not using root

metacortex@ubuntu:~/SecTools/kippo/kippo-0.5$ ./start.sh
Starting kippo in background…/home/dan/SecTools/kippo/kippo-0.5/kippo/commands/ping.py:6: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import time, re, random, md5
Generating RSA keypair…
done.

You will see the deprecation warning but you can safefully ignore that. Now that we see it generated the SSH keys, we can go ahead and log into it.

metacortex@ubuntu:~/SecTools/kippo/kippo-0.5$ ssh root@127.0.0.1 -p 2222
The authenticity of host ‘[127.0.0.1]:2222 ([127.0.0.1]:2222)’ can’t be established.
RSA key fingerprint is eb:de:07:eb:8f:e0:e4:c4:1e:1d:d3:eb:02:20:53:f1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘[127.0.0.1]:2222′ (RSA) to the list of known hosts.
Password:
sales:~# ls
sales:~# pwd
/root
sales:~# id
uid=0(root) gid=0(root) groups=0(root)
sales:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
richard:x:1000:1000:richard,,,:/home/richard:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin

Here you can see that we were able to sucessfully log in using the password 123456. Now if we want to go ahead and look at the logs located in the log directory

metacortex@ubuntu:~/SecTools/kippo/kippo-0.5$ cd log/
metacortex@ubuntu:~/SecTools/kippo/kippo-0.5$ cat kippo.log
2011-01-31 13:41:34-0800 [-] Log opened.
2011-01-31 13:41:34-0800 [-] twistd 10.1.0 (/usr/bin/python 2.6.6) starting up.
2011-01-31 13:41:34-0800 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2011-01-31 13:41:34-0800 [-] kippo.core.honeypot.HoneyPotSSHFactory starting on 2222
2011-01-31 13:41:34-0800 [-] Starting factory
2011-01-31 13:44:43-0800 [kippo.core.honeypot.HoneyPotSSHFactory] New connection: 127.0.0.1:44261 (127.0.0.1:2222) [session: 0]
2011-01-31 13:44:43-0800 [HoneyPotTransport,0,127.0.0.1] Remote SSH version: SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
2011-01-31 13:44:43-0800 [HoneyPotTransport,0,127.0.0.1] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa
2011-01-31 13:44:43-0800 [HoneyPotTransport,0,127.0.0.1] outgoing: aes128-ctr hmac-md5 none
2011-01-31 13:44:43-0800 [HoneyPotTransport,0,127.0.0.1] incoming: aes128-ctr hmac-md5 none
2011-01-31 13:44:43-0800 [HoneyPotTransport,0,127.0.0.1] connection lost
2011-01-31 13:45:10-0800 [kippo.core.honeypot.HoneyPotSSHFactory] New connection: 127.0.0.1:44262 (127.0.0.1:2222) [session: 1]
2011-01-31 13:45:10-0800 [HoneyPotTransport,1,127.0.0.1] Remote SSH version: SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
2011-01-31 13:45:10-0800 [HoneyPotTransport,1,127.0.0.1] kex alg, key alg: diffie-hellman-group1-sha1 ssh-rsa
2011-01-31 13:45:10-0800 [HoneyPotTransport,1,127.0.0.1] outgoing: aes128-ctr hmac-md5 none
2011-01-31 13:45:10-0800 [HoneyPotTransport,1,127.0.0.1] incoming: aes128-ctr hmac-md5 none
2011-01-31 13:45:12-0800 [HoneyPotTransport,1,127.0.0.1] NEW KEYS
2011-01-31 13:45:12-0800 [HoneyPotTransport,1,127.0.0.1] starting service ssh-userauth
2011-01-31 13:45:12-0800 [SSHService ssh-userauth on HoneyPotTransport,1,127.0.0.1] root trying auth none
2011-01-31 13:45:12-0800 [SSHService ssh-userauth on HoneyPotTransport,1,127.0.0.1] root trying auth keyboard-interactive
2011-01-31 13:45:15-0800 [SSHService ssh-userauth on HoneyPotTransport,1,127.0.0.1] login attempt [root/123456] succeeded
2011-01-31 13:45:15-0800 [SSHService ssh-userauth on HoneyPotTransport,1,127.0.0.1] root authenticated with keyboard-interactive
2011-01-31 13:45:15-0800 [SSHService ssh-userauth on HoneyPotTransport,1,127.0.0.1] starting service ssh-connection
2011-01-31 13:45:15-0800 [SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] got channel session request
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] channel open
2011-01-31 13:45:15-0800 [SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] got global no-more-sessions@openssh.com request
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] pty request: xterm (24, 138, 0, 0)
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Terminal size: 24 138
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] unhandled request for env
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] getting shell
2011-01-31 13:45:15-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Opening TTY log: log/tty/20110131-134515-8373.log
2011-01-31 13:45:20-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] CMD: ls
2011-01-31 13:45:20-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Command found: ls
2011-01-31 13:45:21-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] CMD: pwd
2011-01-31 13:45:21-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Command found: pwd
2011-01-31 13:45:22-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] CMD: id
2011-01-31 13:45:22-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Command found: id
2011-01-31 13:45:33-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] CMD: cat /etc/passwd
2011-01-31 13:45:33-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Command found: cat /etc/passwd
2011-01-31 13:45:33-0800 [SSHChannel session (0) on SSHService ssh-connection on HoneyPotTransport,1,127.0.0.1] Updating realfile to honeyfs//etc/passwd

Now you have all you need for your honeypot. Go ahead and put it out on the internet and see what you get.

It seems more and more recently, Security companies are getting owned. The three notable ones in the past month or so have been Goatse Security, Ligatt, and HBGary. If you were not aware of who Goatse Security are, then you may remember the breach quite a while ago that exposed the email addresses of iPad owners. That breach was guys from Goatse Security. HBGary is an incident response company and Ligatt Security is a company that has gained more visibility in the Security World than it should.

I will look at the Goatse Security compromise first. A screenshot of the site after getting owned can be seen here. There is not a whole lot behind this other than it was done for the “lolz” and a “look what I did” kind of thing. HBGary and Ligatt are much more interesting.

The entire subject of Ligatt so much material to write about that it constitutes more time than I want to give Ligatt Security and Gregory D Evans. For all of the background on Ligatt/Mr. Evans please see Attrition.org. Now what happened recently was that the website Ligatt Leaks has gone live in an attempt to expose all of the things wrong with Mr. Evans. Some of the fallout from Ligatt Leaks is that someone had gotten into Ligatt’s mail server for several days, pulled down all of the mail and released all of it in a torrent.

HBGary is the most interesting out of the three I have noted. I had never heard of HBGary until one of their higher ups went public stating that he had found all of the personal information of the people that run Anonymous and would be selling it to the FBI. Not only did Anonymous rebuke the information stating that it was not correct but that HBGary was going to turn over innocent people to the FBI. This also angered Anonymous and so they took a page from the Ligatt book, got into HBGary’s mail server and released all of the emails stored there detailing their attack on Anonymous and how HBGary was planning to start targeting WikiLeaks donors.

Being a security shop and getting hacked is a pretty big blow to not only your ego but your reputation as well but it occurs all too often. Some further examples include Dan Kaminsky gets hacked, Kaspersky gets hacked, and Kevin Mitnick’s website hacked.

In my eyes, it comes down to the fact that you don’t write all of the software that you use (personally or for business). If you do not write all of the code yourself then you can not be 100% certain that there are no holes nor can you fully trust it (and even if you do write it 100% yourself, you are human and make mistakes). Being in the Security Industry also requires a sense of humility as there will always be someone who will be able to find a hole. The key is to not piss these people off and if they do find a hole, work with them to try and get it fixed. Do not paint a bullseye on your back and ask for you. Many people have done this and many have failed (see LifeLock CEO and StrongWebmail contest).

Having been keeping tabs on this industry for several years, I can tell you that there are plenty of people that I would not dream of pissing off because I know how good they are at attacking technologies and that I would not stand a chance against them. It just boils down to the fact that you need to assume everything is vulnerable and someone will get in.