“INABIAF”, un acronimo forse sconosciuto ai più. Forse è più conosciuta la sua versione estesa: “it's not a bug, it's a feature” (“non è un bug, è una funzionalità”). Quante volte ci è capitato sentire gli sviluppatori affermare questo a fronte a nostre lamentele su un problema del loro software? 

Abbiamo sempre ritenuto questa affermazione dominio di programmatori distratti e superficiali (per non dire altro), specie quando il difetto riguardava problemi di sicurezza. 

Ed invece ci troviamo a commentare l’utilizzo di questa espressione da parte di un grande vendor: Microsoft. 

Un gruppo di ricercatori di sicurezza avrebbe individuato un problema di sicurezza in Office Online Server e lo ha prontamente segnalato a Microsoft: ma di conseguenza si sono sentiti rispondere con la suddetta locuzione. 

Office Online Server è un prodotto server Microsoft per supportare l’utilizzo via browser di note applicazioni di Redmond quali Word, PowerPoint, Excel e OneNote attraverso il protocollo WOPI (Web app Open Platform Interface). Questo supporto consente ad utenti SharePoint Server, Exchange Server o semplici cartelle condivise e siti Web di poter comodamente aprire documenti Office direttamente da browser durante la navigazione, senza dover necessitare di una propria istanza di tali software e naturalmente della relativa licenza. 

Tornando al problema segnalato, si tratterebbe di una possibilità di ottenere la falsificazione delle richieste lato server (Server-Side Resource Forgery: SSRF), e la possibilità di eseguire codice da remoto (Remote Code Execution: RCE) sull’host server in cui esegue Office Online Server. Dopo la segnalazione al Microsoft Security Response Center, i ricercatori si sono visti rispondere che il comportamento presunto vulnerabile non sia in effetti un bug, ma una funzionalità di Office Online Server, e dunque Microsoft non avrebbe dovuto o, meglio, non avrebbe avuto alcuna intenzione di porre rimedio a questo. 

Office Online Server è un servizio ASP.NET che fornisce una pagina aspx per accedere remotamente ai documenti: secondo lo studio, proprio questa pagina consente un attacco SSRF. Attraverso richieste GET non autenticate è possibile rilevare i server di back-end al servizio nella rete locale. In più i ricercatori hanno dimostrato come sia possibile eseguire un attacco RCE attraverso privilegi amministrativi dell’host su cui esegue Office Online Server. Questo attacco prevede uno sfruttamento del protocollo SMB quando questo venga utilizzato per recuperare un documento sull’endpoint (dell’attaccante), mediante un attacco SMB Relay attack con il quale è possibile ottenere un certificato client Active Directory dal servizio ACDS (Active Directory Certificate Service) e da questo ricavare un Ticket-Granting Ticket (TGT), un token di sessione di accesso per l'host di Office Online Server. Il tutto attraverso un comunissimo software open source, “ntlmrelayx” della suite Impacket (di cui abbiamo già parlato). 

I ricercatori hanno anche parlato di un possibile percorso di attacco alternativo che consente di ottenere l'accesso remoto al server: lo farebbe inoltrando la connessione dell'endpoint al servizio LDAP ed eseguendo un attacco all’oggetto shadowAccount. Ma questa è tutta un’altra storia. 

Resta il fatto che Microsoft in tutto questo si è limitata a suggerire solamente alcune “mitigazioni” di infrastruttura, quali quello di agire su porte e account nell’ecosistema degli host con Office Online Server esposti su Internet, così come il bloccare la possibilità di utilizzare la Universal Naming Convention (UNC) per raggiungere le risorse Office, la funzionalità che è stata utilizzata per dimostrare l’attacco al server. 

A chi credere?

Tweet