Basically the Nexus underlying operating system, made by MonteVista, which was formally called Hard Hat Linux (a hardened version of Red Hat Linux). I can tell you that there are numerous ways to attack these boxes. Some that I have found:

PATH not properly set in shell scripts

Input not properly sanity checked in scripts

IFS together with PATH exploitable

gdbserver running has root, can allow you to kill any process, including securityd

The binaries for the most part are stripped. So there is no symbol information, I plan to eventually re-construct the symbol table using some tools. This combined with gdb would give you the ability to call any function you want as root.

Many processes run as root (via /etc/sudoers), its very sloppy

I have found at least 5 ways to get shell access.

gdb could (Theoritically) be used to overflow the stack on a number of functions to run arbitrary shellcode. I haven’t done this because its tedious but should work. The security problem is that you can use gdb to remotely connect in the first place.

At least one serious problem is the ability to crash a nexus remotely via CDP, I don’t believe this is fixed yet.

Productive evening. I was able to get shell access on a 5k, 7k, 1000v, and MDS, that is from the CLI I was able to get to an actual bash shell. Oddly using different exploits on MDS vs. 5k/7k/1000v. As far as I know these are not known to Cisco. Its not really a serious issue since you have to have access to the box anyways. I only tried as admin, but its likely to work from any user level.

I did not post every method that I was able to obtain root with, nor did I post the straight forward malicious methods such as constructing a special CDP packet that will take NX-OS down every time (at least it used to). If you have any interesting things you have found in NX-OS please let me know!

gdb

The gdb is visable via the which command. you can do “sh processes” and see all processes, then use “gdp <process id>” to run gdb as a server.

Then from your workstation you can connect to gdb process using “gdb target remote x.x.x.x:yyyyy" where x.x.x.x is the ip address of the mds and yyyyyy is the port the gdb says its listening on (starts at 10001). Then you can use gdb to do things like stack smashing and other hacks. These are advanced topics beyond what I am willing to write here, but trival for those that know security and gdb.

I have found many security holes in the shell programs, and can pass things from CLI that crash the system. Yes most of these work in older versions of SanOS as well as NX-OS.

You can see in my previous article, that I used the “bash” command. In later NX-OS versions this was not possible. After rooting the box, I spent a lot of time learning about all of the shell scripts and binaries on the filesystem, and I continued to hack at them.

What became my “goto” command was “this“. I think “this” was an undocumented command. But once you hack into the filesystem you could see it was a command that was available.

The most common hack I would do was to do like so:

this ;bash vi

and then just use :shell from within vi……..this gives you a shell, you can look around and do whatever you like.

When doing shells from within NX-OS, you may not end up with an interactive shell, so you must redirect to your tty to see the output like so:

Some of you may know me as a sage hacker from the mid 80’s to the early 90’s. Although, if you met me after 1994, most of you probably don’t know that about me at all. It was a previous life. Sufficient time has passed since I have informed Cisco about numerous security vulnerabilities in older versions of NX-OS that I can now make this post. I have no idea if these are even still relevant in newer versions. I hack stuff, and I move on. I was quite involved in NX-OS years ago as it was based on SanOS, which was an OS that I became intimately familiar with while getting my CCIE Storage. Now of days I focus on advanced Software Engineering and doing anything on a beach! You may wish to read my articles:

In the old days, I would make Frankenpix boxes. These would be basically identical to a PIX520 or LocalDirector 430/416. They were Cisco PIX/LocalDirector clones, using the following hardware, and they worked great:

It will ask you if you wish to ignore this, but regardless the integration will fail, and it won’t be able to validate your credentials, and so you will have no Cloud Foundry integration.

I really like the Cloud Foundry integration in Eclipse so I set off on a way to figure out how to make it work. Originally I tried an older version of the plug-in, version 1.7.3, which appeared to work. I was using this with PCF 1.4.0.0 which has just been released. I removed an application however, and when it did, I believe it removed my apps_manager application which exists in the system org. I know this sounds weird, because 1) the plug-in should not be removing the apps_manager service under any circumstances, 2) even if it wanted to, my credentials I used in Spring Tool Suite did not have the authority to remove an app from the system org. I did not spend a lot of time looking into this, I just noticed that I removed an application, and all the sudden my developer console was gone. (Developer Console is now known as Apps Manager).

To get the integration to work you need to add the self-signed certificate from your PCF to your Java keystore. Its important to understand which version of Java your running, you may have several versions of Java installed. Typically the version that is being used is defined by $JAVA_HOME, but you’ll want to verify with STS/Eclipse which version its using or maybe add the certificate to all your versions.

I use a Mac, and typically the original Java installed by Apple is in /System/Library/Java/JavaVirtualMachines. For example my system has like so:

Of course, if you have access to the Ops Manager, you can just go into the Elastic Runtime tile and look at the IPs and Ports and grab the certificate from there, that is where you created it in the first place. There are two certificates listed, the first one is the public one, which is the one you want, and the second is the private. Whether you use openssl or just cut and paste it, the result should be the same.

After this is done, simply restart your Eclipse or Spring Tool Suite application, and it should now allow you to add a Cloud Foundry instance with no issue. If you have already added an instance, simply delete it and re-add it. Fill out your credentials, and all should validate properly.

About this blog

This blog is mostly about my pursuits in Data Science. Previous blog entries also dealt with storage, compute, virtualization and professional services. Currently the focus is on Data Science, including Big Data, Hadoop, Business Intelligence, Data Warehouse, Data Integration and Visualization. From time to time I will blog about other things of interest.
The opinions expressed in this blog are entirely my own and should not be taken as the opinion of my employer.