All you need are backticks to get root on a Cisco IMC!

This post follows on from my previous one that discusses why I even discovered this vulnerability, how it was discovered and what thought processes and techniques I used to do so.

The command injection vulnerability

This is pretty simple so here goes:

In the above demonstration, I logged in via SSH as a read only account which is only supposed to be able to view the IMC configuration but not make any changes. I guess this account would be used for monitoring. I would also make an assumption that the credentials in many organisations for a read only account would be generally available or even quite insecure as they would be deemed safe to give out.

Once you are logged in to the CLI, you have a limited set of commands that work in a similar way to Cisco IOS. ? Question mark will show any contextual commands available etc.

Anyway, you are locked into this restricted CLI. And there is very little you can do – even more so when you only have a read only account.

Simply type in:

connect debug-shell -;/bin/bash>&2

or

connect debug-shell `/bin/bash>&2`

And you immediately become root, there is no prompt or request for credentials – you are now root!

Lets break this command down:

The connect command according to Cisco is:

To connect to either the server CLI or the server shell, use the connect command.

connect { host | shell }

Usually you would use this to connect to serial over LAN but Cisco have added a hidden feature to the firmware that is for debugging by Cisco themselves, namely debug-shell.

This is very little documentation about this command and it was found by ripping the Cisco firmware apart using binwalk and a few other tools.

This command is actually quite powerful was really helpful in identifying if I was getting anywhere with my silly obsession to get root on this thing. After a bit of investigation, it became apparent that the debug shell was running as root and also that it was executing commands directly as root.

The top command actually runs /usr/bin/top directly and if you look it can be seen right there as root! This is not exactly a good design, one would also assume that the restricted shell that you get at first login is also running as root. Alarm bells should start ringing now!

This shows the process tree which further confirms my assumptions:

After trying a few a lot GTFOBins commands, I hit a wall and had to have a rethink. I would expect there are still a few holes and ways to get a shell in this way.. I just didn’t find them..

Anyway, this seemingly simple command runs ls in /var/cores and /var/cores/dumps:

cores

At first view it doesn’t look like it would be of any use at all but after having a good think and a lot of experimentation, it became the perfect tool to finding the next step towards make some progress!

I reverted back to the first restrictive shell and tried again to make some headway there instead.

I focussed on the connect debug-shell command as this was clearly spawning another child process and I knew for certain that it was as root. After a lot more experimenting, I got a strange error:

What is this? sh is executing commands and it appears that the filtering from the restrictive shell isn’t filtering very well at all! The ` backtick is being completely ignored and passed to the underlying command. Surely the implementation can’t be this bad can it?

I spend a little more time with this then look what we have here!

id has been executed as root. Hilariously bad!

Further to this I was able to redirect writes as root and with the cores command view the file!

connect debug-shell -;id>/var/core/dumps/Hello-World!

What I had managed to do so far was great but I only had access to stderr so there was no way to get an interactive shell.

A bit of lateral thinking and a small change to the redirect command above:

connect debug-shell `/bin/bash>&2`

This is quite a cool feature of BASH, the redirect simple redirects stdout to stderr. As we already have stderr we now have stdout too and hey presto, a root shell!

And if you made it this far, you may wonder what “Fox in a box” is about – It amused me to find that its the hardcoded root password in the firmware image.