Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Microsoft : des connexions aux services trop bavardes et des serveurs Exchange pris pour cible

Sale journée
Internet 4 min
Microsoft : des connexions aux services trop bavardes et des serveurs Exchange pris pour cible
Crédits : stevanovicigor/iStock/Thinkstock

Microsoft fait face à plusieurs critiques dirigées contre la connexion à certains de ses services. Les requêtes font transiter un identifiant unique en clair, permettant de récupérer certaines informations. Parallèlement, l’un des produits de l’éditeur, Exchange, se retrouve impliqué dans une vaste attaque dirigée contre une grosse entreprise.

Mauvaise journée pour l’éditeur de Redmond après la révélation coup sur coup de deux problèmes de sécurité, dont un particulièrement sérieux, mais dont il ne semble pas directement responsable. Le premier concerne la méthode utilisée par Microsoft pour la connexion à plusieurs de ses services, notamment OneDrive et Outlook.com. Lors de la phase « DNS lookup » (conversion d’une adresse IP en nom de domaine), une requête HTTPS est envoyée aux serveurs pour obtenir une autorisation. Malheureusement, cette requête affiche un identifiant unique en clair.

Quand le HTTPS ne fait pas tout

Cette série de caractères, découverte par un blogueur basé à Beijing (Pékin), est un entier 64 bits nommé CID, que Microsoft utilise visiblement souvent avec ses API pour l’identification des utilisateurs.  Cet identifiant apparaissant en clair, il peut être récupéré puis utilisé par une personne malintentionnée pour récolter certaines informations : le nom du compte, sa date de création et la photo servant d’avatar.

Il ne s’agit évidemment pas d’informations très sensibles, mais elles ne devraient dans tous les cas pas être accessibles du tout. Dans certains cas, il est par ailleurs possible d’obtenir certaines informations de paramètres pour quelques services, notamment Calendrier. Si la prévision météo est active, on peut ainsi retrouver l’emplacement choisi par défaut ainsi que l’unité de mesure. La ville par défaut étant souvent celle où réside l’utilisateur (ou la plus proche grande ville), c’est un indice supplémentaire sur sa vie.

Ars Technica, qui s’est fait le relai de l’information, a pu effectuer ses propres tests et a confirmé la situation. Nos confrères ont contacté Microsoft et la société s’est dite au courant du problème. Elle prépare d'ailleurs une communication sur le sujet. Le blogueur, dans son billet, indiquait à la fin que le problème était relativement simple à corriger pour l'éditeur.

Une attaque persistante contre le module OWA d'Exchange

Dans le même temps, un produit de Microsoft est impliqué dans une APT (Advanced Persistent Threat), qui s'appuie sur un malware pour voler des informations. Cette découverte est relayée dans un rapport de la société de sécurité Cybereason, qui raconte comment une entreprise, dont le nom n’a pas été communiqué, l’a contactée pour lui signaler une activité suspecte sur son réseau. Cybereason est donc intervenue pour vérifier l’état du parc, comptant tout de même 19 000 terminaux divers.

Les pirates ont réussi à installer une version compromise de la bibliothèque « OWAAUTH.dll », chargée normalement sur un serveur Exchange de l’entreprise dans le module lié à Outlook Web Access. Cette DLL n’était pas signée et contenait en fait plusieurs portes dérobées lui permettant de recevoir des instructions. Or, comme le signale Cybereason, OWA est à l’interface entre le réseau interne de l’entreprise et Internet. L’entreprise visée avait de plus autorisé son module à recevoir une administration distante, ouvrant un large canal vers sa structure interne en cas de problème.

Conséquence, le malware est resté en place pendant une période de plusieurs mois. Il a pu dérober tous les identifiants complets qui ont circulé, via les jetons d’authentification. OWA étant basé en effet sur la sécurité du domaine et donc ses identifiants, récupérer les identifiants du premier ouvre les portes du second. Il est donc probable que les pirates aient pu obtenir de nombreuses informations. Par ailleurs, le rapport de Cybereason se concentre sur une seule grande entreprise, mais il n’est indiqué nulle part si la contamination a été repérée ailleurs. Le fait qu’il s’agisse d’une APT peut signifier que seule la première était visée, mais les erreurs de configuration de logiciels et matériels sont probablement trop courantes pour ne pas en avoir profité sur d’autres cibles.

Cybereason souligne qu’en dépit d’un souci de configuration, le composant OWA d’Exchange est particulièrement sensible : « Presque par définition, OWA exige des entreprises un lot assez lâche de restrictions ». Ses réglages sont donc à effectuer soigneusement sous peine d’ouvrir de grandes portes vers le réseau de l’entreprise. Selon le rapport, Microsoft ne semble pas directement fautif dans le cas présent, mais ce type de découverte peut entrainer des modifications dans la configuration par défaut ou dans les recommandations qui sont faites aux entreprises. D'autant qu'on ne sait en fait pas comment les pirates ont en premier lieu réussi à installer leur malware.

28 commentaires
Avatar de 2show7 INpactien
Avatar de 2show72show7- 06/10/15 à 13:08:51

Les joies futures du tout connecté :craint:

Avatar de Inny Abonné
Avatar de InnyInny- 06/10/15 à 13:15:18

Le système n'aurait-il pas dû rejeter la dll non signée en théorie ?

Avatar de anonyme_751eb151a3e6ce065481d43bf0d18298 INpactien

D'où l'intérêt de bien compartimenter un SI avec des sous-domaines pour réduire la portée de ce type d'attaque.

En tout cas, ça doit chauffer dans les DSI, dont chez moi, où le composant est utilisé.

Avatar de anonyme_69736061fe834a059975aa425bebeb6d INpactien

Cette DLL n’était pas signée et contenait en fait plusieurs portes dérobées

;)

Avatar de RaoulC INpactien
Avatar de RaoulCRaoulC- 06/10/15 à 13:21:20

Inny a écrit :

Le système n'aurait-il pas dû rejeter la dll non signée en théorie ?

Une vérification de signature d'un fichier ca se patche. Si les pirates ont étés capable de remplacer une dll, alors remplacer le composant qui ferait la vérification devait être possible aussi, sans doutes.
 
 

ActionFighter a écrit :

D'où l'intérêt de bien compartimenter un SI avec des sous-domaines pour réduire la portée de ce type d'attaque.

En tout cas, ça doit chauffer dans les DSI, dont chez moi, où le composant est utilisé.

Dans quelle administration? C'est juste pour savoir bien entendu :D

Édité par RaoulC le 06/10/2015 à 13:22
Avatar de mrjay42 INpactien
Avatar de mrjay42mrjay42- 06/10/15 à 13:27:00

J'ai scrollé huit fois sur toute la page pour trouver le bouton signaler une erreur...pas trouvé. Voici donc:
 "Exchange, se retrouve impliqué dans vaste attaque dirigée contre une grosse entrepris"
 Il manque le mot "une" :)

Avatar de Dedrak Abonné
Avatar de DedrakDedrak- 06/10/15 à 13:37:43

Fallait pas scroller trop loin ;) , le bouton signaler c'est le /!\ dans la barre en haut de la page dès qu'on la fait défiler un peu.

Avatar de inborn INpactien
Avatar de inborninborn- 06/10/15 à 13:37:52

Quand tu scroll un peu, un bandeau avec le bouton apparait. ;)
 
 EDIT: Grilled...

Édité par inborn le 06/10/2015 à 13:39
Avatar de timhor INpactien
Avatar de timhortimhor- 06/10/15 à 13:47:52

ca change rien, la dll compromise permet quand meme de recuperer les credentials des gens comprimis.
 
un sous domaine c'est bien mais ca fait pas tout non plus

Avatar de anonyme_751eb151a3e6ce065481d43bf0d18298 INpactien

timhor a écrit :

ca change rien, la dll compromise permet quand meme de recuperer les credentials des gens comprimis.
 
un sous domaine c'est bien mais ca fait pas tout non plus

De ce que je comprend, la dll permet de récupérer les credentials sur un domaine particulier, donc si OWA est situé sur un sous-domaine bien distinct, seul les credientials de ce domaine sont récupérables.

Il n'est plus possible de commenter cette actualité.
Page 1 / 3