MDM Profil von iOS Gerät entfernen – ohne App, iOS/iPadOS 18+

Ich habe ein gebrauchtes iPad ersteigert – ein Gerät in gutem Zustand für wenig Geld, super schnell geliefert, Zustand wie beschrieben. Leider wurde ich beim Einrichten mit einer mir bis dahin unbekannten Meldung konfrontiert: Das Gerät wird „fernverwaltet“ und zwar offensichtlich von der Schule des Vorbesitzers. Diesen schrieb ich auch direkt an und er versprach mir sich mit dem Admin der Schule auseinanderzusetzen.
Stand „jetzt“ ist diesbezüglich noch nichts passiert und anstatt zu warten war ich doch neugierig ob man das Problem nicht selbst lösen könnte…

TL;DR

Ich habe es geschafft das Profil zu entfernen, allerdings ist das iPad damit noch nicht 100% „frei“. Nach einem Zurücksetzen ist das Profil wieder da. Immerhin kann man so aber vorerst die Beschränkungen des MDM Profils loswerden.
Und ja – es gibt Software im Netz die genau das verspricht – die kostet aber Geld und wirkt nicht sonderlich vertrauenswürdig – wer weiss was die sonst noch alles auf dem Gerät anstellt. Für meine Lösung benötigt man etwas Geduld und IT Know-How (Linux!) aber keine Fremd-Software. Es wird zudem ggf. ein Cloud Server benötigt – aber nur für kurze Zeit, die Kosten bewegen sich im Cent-Bereich.

Recherche

Erstmal musste ich mir einen Überblick verschaffen was diese Fernverwaltung überhaupt ist und wie sie funktioniert. Grob zusammengefasst wird die Fernverwaltung (oder „Betreuung“ wie Apple es auch nennt) gerne von Schulen und Unternehmen genutzt um die Geräte zentral steuern zu können. Die Betreuung wird dann mit einem sogenannten „Mobile Device Management“ (MDM) Profil kombiniert. Dieses Profil wird nach dem ersten Einrichten auf dem Gerät installiert und sorgt dafür dass dem Administrator aus der Ferne bestimmte Rechte auf dem Gerät eingeräumt werden.

Dabei ist die Registrierung des Geräts als „betreutes“ oder „fernverwaltetes“ Gerät ein Teil der bei Apple liegt (Apple School Manager) und das Ausliefern des MDM Profils kann von einem Drittanbieter erfolgen (in diesem Fall kam jamfcloud.com zum Einsatz).

Da das MDM Zeugs von Drittanbietern bereitgestellt werden kann gibt es von Apple auch eine Dokumentation des Protokolls; hier fand ich eine interessante Information: „Wenn der Server ein Gerät nicht mehr verwaltet, soll er auf alle Anfragen einfach mit deinem 401 HTTP Code antworten. In diesem Fall würde das MDM Profil automatisch entfernt“. Ich dachte mir, hier könnte ich doch ansetzen 🙂

Werkzeuge

Konfigurierbarer DNS Server

Wir müssen den HTTP Request des MDM „Check-In“ abfangen und auf einen eigenen Server umleiten. Dies geschieht über DNS – das iPad fragt die ihm bekannte Check-In URL an und landet – ohne es zu merken – auf unserem Server. Ich nutze dafür nextdns.io – diesen habe ich auch als zentralen DNS auf der FritzBox hinterlegt so dass der gesamte Traffic aus dem Haus-Netz darüber läuft. Die Einrichtung ist sehr einfach und bis zu einer gewissen Menge an Anfragen ist der Dienst kostenlos.

Server

Wir brauchen einen Webserver der die Check-In Anfrage annimmt und mit einen 401 HTTP Code beantwortet. Je nach Netzwerk-Konfiguration könnte das wohl auch ein im lokalen Netz laufender Linux Server sein (er muss nur vom iPad erreichbar sein). Ich habe mir beim Cloud Anbieter meines Vertrauens schnell einen Cloud-Server mit Ubuntu zusammengeklickt und gestartet. Der Server muss ja maximal ein paar Stunden laufen und kann danach wieder gelöscht werden.

Arbeitsschritte

Zunächst mal muss das iPad soweit eingerichtet sein dass wir den Home Screen vor uns haben. Das Gerät muss also zunächst mal bei der Fernverwaltung angemeldet werden und wird das MDM Profil installieren.
Eine Möglichkeit Dateien auf das iPad zu senden sollte ebenfalls vorhanden sein (z.B. Airdrop, oder ein Dienst wie https://www.swisstransfer.com).

Eigene CA und SSL Zertifikat erstellen

Natürlich antwortet der originale Check-In Server per HTTPS, also brauchen wir auch ein SSL Zertifikat. Es muss ein selbst signiertes werden, denn echte Zertifizierungsstellen wie Let’s Encrypt stellen uns natürlich keines für eine Domain aus die uns nicht gehört.
Ein selbstsigniertes Zertifikat hat aber den Nachteil dass das iPad diesem nicht vertrauen wird. Also benötigen wir auch eine eigene „Certificate Authority“ (CA) die wir auf dem iPad installieren, so dass dieses unserem Zertifikat dann doch vertraut.

Die einzelnen Befehle habe ich von arminreiter.com und www.brainbytez.nl hier die schnelle Abfolge:

CA erstellen:
Im ersten Block wird die CA erstellt die hinterher auch auf dem iPad installiert wird und mit der das Zertifikat signiert wird. Wichtig ist, beim erstellen des Private Key ein beliebiges Passwort anzugeben.

# define a name for the CA
CANAME=MyOrg-RootCA

# optional
mkdir $CANAME
cd $CANAME
# generate aes encrypted private key
openssl genrsa -aes256 -out $CANAME.key 4096

# create certificate, 1826 days = 5 years
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=MyOrg Root CA/C=US/ST=Denver/O=MyOrg'

Server Zertifikat erstellen:
Wir erstellen ein „Wildcard“ Zertifikat, so dass dieses für alle subdomains der Domain des MDM Verwalters gültig ist. Wichtig ist hier nur, dass ihr bei MYDOMAIN ggf. die für euch richtige Domain eintragt. Diese findet ihr in dem MDM Profil auf dem iPad unter „Einstellungen -> Allgemein -> VPN und Geräteverwaltung -> (Name des Profils) -> Enrollment“. Dort steht die URL drunter – wir brauchen nur den Domainnamen.

# define variables
MYCERT=webserver
MYDOMAIN=*.jamfcloud.com

# create the certificate signing request
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj "/CN=$MYDOMAIN/C=US/ST=Denver/O=MyOrg"

# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage=serverAuth
subjectAltName = DNS:$MYDOMAIN
EOF

# sign the certificate with the CA
openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext

# concatenate certificate and ca
cat $MYCERT.crt $CANAME.crt > $MYCERT.pem

Ihr solltet nun in dem Ordner diverse Dateien haben. Unter Anderem eine Datei „MyOrg-RootCA.crt“ und eine Datei „webserver.pem“

CA auf dem iPad installieren

Damit das iPad unserem selbstsigniertem Zertifikat vertraut, müssen wir unsere eigene CA auf dem iPad installieren. Dafür muss die CA Datei („MyOrg-RootCA.crt“) aus dem vorherigen Schritt nun auf das iPad übertragen werden. Am komfortabelsten geht das in einer Mac-Welt über AirDrop.
Nach dem Übertragen der Datei wird das Profil normalerweise direkt installiert (oder man muss die Datei nochmal über die „Dateien“ App öffnen).
Anschließend begibt man sich in die Einstellungen, wo jetzt prominent auf der linken Seite etwas von einem gerade installierten Profil steht. Dort tippt ihr drauf und tippt immer auf das im vertrauenerweckenden Rot geschriebene „installieren„.
Nun müsst ihr dem Zertifikat noch als SSL Root CA vertrauen. Dazu geht ihr in „Einstellungen -> Allgemein -> Info -> (ganz runter scrollen) -> Zertifikatsvertrauenseinstellungen“ und schaltet dort euer Root CA ein.

Server installieren

Zunächst installieren wir auf unserem Server einen Nginx Webserver (oder eben einen beliebigen Anderen). Auf Debian/Ubuntu geht das mit apt-get update && apt install nginx

Wir können nun einfach die Nginx Standardinstallation unter /etc/nginx/sites-enabled/default bearbeiten. Bei mir schaut sie so aus:

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;

        include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # just always return a 401
                return 401;
        }
}

Wie man sehen kann habe ich auch SSL auf Port 443 aktiviert. Zudem antwortet der Server einfach auf alles mit einem 401 HTTP code.

Nun müsst ihr das im vorherigen Schritt erstelle SSL Zertifikat auf den Server kopieren. Und zwar die Dateien „webserver.pem“ und „webserver.key“.

Wir müssen nun noch die Datei /etc/nginx/snippets/snakeoil.conf bearbeiten und unser SSL Zertifikat nebst Key dort einfügen. Das könnte z.B. so aussehen wenn die Dateien in /root/cert/ kopiert wurden:

ssl_certificate /root/cert/webserver.pem;
ssl_certificate_key /root/cert/webserver.key;

Mit dem Befehl nginx -t testen wir nun ob alles richtig ist, wenn dort alles OK ist laden wir die neue Webserver Konfiguration mit systemctl reload nginx

DNS umleiten

Nun leiten wir alle Anfragen auf die Check-In Domain (z.B. jamfcloud.com) auf die öffentliche IP unseres Servers um. Bei NextDNS geht das über „Einstellungen -> Umschreibungen“

Test

Wenn ihr auf dem iPad nun mal die (https!!!)-Check-In URL mit dem Webbrowser aufruft, dürfte dort eine NginX Standard Fehlerseite erscheinen und keine Zertifikats-Fehler – sondern ein vertrauenserweckendes geschlossenes Vorhängeschloss neben der URL.

Beobachten

Ihr könnt euch nun das NginX Access-Log live beobachten um zu sehen wann euer iPad die Check-In URL aufruft tail -f /var/log/nginx/access.log
In meinem Fall wurde die URL (die ja ausser von meinem Netzwerk nur über die IP zu erreichen ist) erstaunlich oft von diversen Bots aufgerufen, die auf offene Sicherheitslücken prüfen. Aber der MDM request ist ganz gut an dem „MDM“ String zu erkennen.

Warten

In meinem Fall habe ich nun ein paar Stunden gewartet – irgendwann kam der ersehnte Check-In Request. Nach einem Blick auf das iPad unter „Einstellungen -> Allgemein -> VPN und Geräteverwaltung“ war das Profil nun weg 🙂
Es scheint aber auch einen schnelleren Weg zu geben den MDM Check-In Request zu provozieren indem man kurz in den Flugmodus und wieder zurück wechselt.

Fazit

Eine recht aufwändige Methode, aber immerhin muss man sich keine ominöse Software installieren. Verkaufen könnte man das iPad so auch nicht, und die Schritte müssen nach jedem Werks-Reset wiederholt werden.
Die Lösung ist also mehr eine Notlösung. In meinem Fall hoffe ich dass der Admin der Schule das iPad bald richtig freigibt. Ansonsten ist das iPad zwar nach wie vor „Fernverwaltet“ aber der Verwalter hat keinerlei Berechtigungen mehr.