Molte volte, nell’ambito del nostro lavoro, ci troviamo a discutere della gravità di vulnerabilità, procedure o minacce in generale; redigendo classifiche che a volte lasciano stupiti i nostri interlocutori perché mettiamo molta attenzione a quello che succede dentro le reti e alle possbilità operative lasciate agli utenti interni. Questo mese vogliamo portare la vostra attenzione sul problema del “privilege escalation”: come sfruttare una vulnerabilità di poco conto per riuscire poi a diventare utente amministratore di un sistema.Innanzitutto è bene ricordare come le vulnerabilità comunente trattate (anche in questa rubrica) sono intese come dei problemi di sicurezza che si possono sfruttare da remoto e non presuppongono l’accesso fisico alla macchina. Queste vulnerabilità sono in realtà una netta minoranza del totale anche se occupano quasi in monopolio la ribalta delle cronache. Il problema è che se si riesce a bucare un servizio, ad esempio il web, e si riesce quindi ad operare sulla macchina oggetto dell’attacco con i privilegi-utente con i quali girava il servizio web, sfruttando una vulnerabilità locale, si potrà scalare i privilegi fino a diventare superuser di quel sistema e magari si potrà ora operare fraudolentemente anche sui sistemi interni della rete target.E’ chiaro che anche la più macroscopica vulnerabilità locale è assolutamente inutile per portare un attacco informatico in assenza di una invocabile da remoto, tuttavia è vero che complessivamente la gravità media dei problemi si eleva di molto considerando non più i problemi singolarmente ma a coppie remoto+locale. Una tecnica molto diffusa, fino al kernel linux 2.4.10, era quella di sfruttare proprio un problema del kernel, da un’utenza normale o nobody avuta tramite ad esempio unproblema di Apache si poteva a quel punto prendere completo controllo del sistema informatico attaccato. Altro esempio, in tempi più recenti, si poteva utilizzare una vulnerabilità del ptrace (fino a 2.4.21) per diventare root. http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0134.html
E’ molto difficile limitare efficacemente le possibilità di privilege escalation operando sui privilegi degli utenti, come consiglio diciamo ancora di eliminare tutte le vulnerabilità, ricordando come mai come in questo caso vale la considerazione che la validità di sistema di difesa corrisponde alla forza dell’anello più debole del sistema stesso.Dopo molto tempo, circa 2 anni, il caso ha voluto che nello stesso mese fossero pubblicati due problemi su Sendmail, uno dei software più diffusi sulla rete (50%-75% dei mail server installati) http://www.cert.org/advisories/CA-2003-07.html
http://www.cert.org/advisories/CA-2003-12.html
In questo caso segnaliamo questi problemi anche per la capacità di colpire server non connessi alla rete pubblica e perché operano su porte che solitamente non sono protette dai firewall – come anche per WebDav che colpisce IIS sulla porta 80 ed è il primo che può colpire Windows 2000 nonostante l’installazione del Service Pack 3 (http://www.cert.org/advisories/CA-2003-09.html).Una curiosità, il primo Internet Worm della storia colpiva le sue vittime proprio per colpa di un baco di sendmail, scommettiamo che purtroppo queste due vulnerabilità non saranno le ultime?