While running an internal vulnerability scan I noticed that one of the devices was showing vulnerable to VxWorks Memory Dump.
This is exploitable by using the Metasploit wdbrpc_memory_dump module, so I fired it up and loaded the module to see if I could pull the memory from this device.
I run the exploit against the system and it began dumping the memory, and it got to about 31% before stopping, so I had to restart it from the OFFSET value it stopped at. This happened 3 more times before it finished. The output file was about 256MB in size, so I was not sure if it had good information from the system or just crap.
Being that it was a hex dump of the memory, I ran strings against the file to get a list of information and look for possible information to use. I put the output into another file to search through with “grep”.
#strings vxworks_memory.dmp > strings.memory.dmp
I was able to determine that it was a network switch from viewing the IP address on port 80 (looked back at Nessus to see what ports where open and what it thought the device was), so I decided to search for words like “password”, “enable”, and “encryption”.
At first nothing showed up that was any good or valuable to use, so I decided to search for partial words, like “assw”, “able” and “crypt” to see if the words had been split across lines in the memory dump.
#cat strings.memory.dmp | grep -i assw
#cat strings.memory.dmp | grep -i crypt
I discovered that the enable hash was in the dump, so I guessed that the password could also be stored in there as well.
Taking the new file from the strings output (strings.memory.dmp), I ran it through “sort” with the unique flag and output that into another file to use as my password list starting point.
#cat strings.memory.dmp | sort –u > passlist.list
With new list of possible passwords, and hoping that one copy of it was completely intact and not split across a line. I ran it through PW-Inspector to narrow it down to a more manageable number and realistic passwords and an actual realistic length.
#pw-inspector –I passlist.list –o passlist.uniq.list –lunps –m 8 –M 16
Now that I had narrowed the password list down to a more manageable solution, I ran John against the hash with the shorter list.
In no time at all I had the password for the hash, the switch was not Cisco and was only using an MD5 hash, which made it rather simple to crack.
Now that I had the password, I needed to search for a user name. So I started searching for common names in the file, and admin came back multiple times with the word user next to it, so with a little searching on Google, I discovered that admin was the default user on this switch.
From there I tried to SSH to the switch, but was denied due to the use of private keys and not passwords for SSH, so I tried telnet to connect to the switch and was able to login.
From there I had access to see all of the other VLANS, and IP address space that I did not have access to before. Now time to see where else the password is used.