macOS xpc_connection_get_audit_token Attack
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
Daha fazla bilgi için orijinal gönderiyi kontrol edin: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Bu bir özet:
Mach Mesajlarının ne olduğunu bilmiyorsanız bu sayfayı kontrol etmeye başlayın:
macOS IPC - Inter Process CommunicationŞu anda hatırlamanız gereken (buradan tanım): Mach mesajları, mach çekirdeğine entegre edilmiş tek alıcı, çoklu gönderici iletişim kanalı olan bir mach portu üzerinden gönderilir. Birden fazla işlem, bir mach portuna mesaj gönderebilir, ancak herhangi bir noktada yalnızca bir işlem ondan okuyabilir. Dosya tanımlayıcıları ve soketler gibi, mach portları çekirdek tarafından tahsis edilir ve yönetilir ve işlemler yalnızca hangi mach portlarını kullanmak istediklerini belirtmek için kullanabilecekleri bir tamsayı görürler.
XPC bağlantısının nasıl kurulduğunu bilmiyorsanız kontrol edin:
macOS XPCBilmeniz gereken ilginç bir şey, XPC'nin soyutlamasının bire bir bağlantı olmasıdır, ancak bu, birden fazla göndericiye sahip olabilen bir teknoloji üzerine kuruludur, bu nedenle:
Mach portları tek alıcı, çoklu gönderici.
Bir XPC bağlantısının denetim belirteci, en son alınan mesajdan kopyalanan denetim belirtecidir.
Bir XPC bağlantısının denetim belirtecini elde etmek, birçok güvenlik kontrolü için kritik öneme sahiptir.
Önceki durum umut verici görünse de, bunun sorun yaratmayacağı bazı senaryolar vardır (buradan):
Denetim belirteçleri genellikle bir bağlantıyı kabul edip etmeyeceğine karar vermek için bir yetkilendirme kontrolü için kullanılır. Bu, hizmet portuna bir mesaj gönderilerek gerçekleştiğinden, henüz bir bağlantı kurulmamıştır. Bu porttaki daha fazla mesaj, yalnızca ek bağlantı talepleri olarak işlenecektir. Bu nedenle, bir bağlantıyı kabul etmeden önceki kontroller savunmasız değildir (bu, -listener:shouldAcceptNewConnection: içinde denetim belirtecinin güvenli olduğu anlamına gelir). Bu nedenle, belirli eylemleri doğrulayan XPC bağlantılarını arıyoruz.
XPC olay işleyicileri senkronize bir şekilde işlenir. Bu, bir mesaj için olay işleyicisinin, bir sonraki mesaj için çağrılmadan önce tamamlanması gerektiği anlamına gelir, hatta eşzamanlı dağıtım kuyruklarında bile. Bu nedenle, bir XPC olay işleyicisinde denetim belirteci diğer normal (yanıt vermeyen!) mesajlar tarafından üzerine yazılamaz.
İki farklı yöntem bu şekilde istismar edilebilir:
Varyant 1:
Saldırı A hizmetine ve B hizmetine bağlanır
B hizmeti, kullanıcının yapamayacağı ayrıcalıklı bir işlevselliği A hizmetinde çağırabilir
A hizmeti, bir dispatch_async içinde bağlantı işleyicisinde _değil**_ken xpc_connection_get_audit_token çağrısını yapar.
Böylece, farklı bir mesaj Denetim Belirtecini üzerine yazabilir çünkü olay işleyicisi dışında asenkron olarak dağıtılmaktadır.
Saldırı, B hizmetine A hizmetine gönderme hakkını verir.
Böylece B hizmeti aslında A hizmetine mesajlar gönderiyor.
Saldırı, ayrıcalıklı eylemi çağırmaya çalışır. Bir RC'de A hizmeti, bu eylemin yetkilendirmesini kontrol ederken, B hizmeti Denetim belirtecini üzerine yazar (saldırıya, ayrıcalıklı eylemi çağırma erişimi verir).
Varyant 2:
B hizmeti, kullanıcının yapamayacağı ayrıcalıklı bir işlevselliği A hizmetinde çağırabilir
Saldırı, A hizmetiyle bağlantı kurar ve bir yanıt bekleyen bir mesaj gönderir.
Saldırı, B hizmetine o yanıt portunu geçerek bir mesaj gönderir.
B hizmeti yanıt verdiğinde, A hizmetine mesaj gönderir, bu sırada saldırı ayrıcalıklı bir işlevselliğe ulaşmaya çalışarak A hizmetine farklı bir mesaj gönderir ve B'den gelen yanıtın Denetim belirtecini mükemmel bir anda üzerine yazmasını bekler (Race Condition).
Senaryo:
Bağlanabileceğimiz iki mach hizmeti A ve B (sandbox profiline ve bağlantıyı kabul etmeden önceki yetkilendirme kontrollerine dayanarak).
A belirli bir eylem için bir yetkilendirme kontrolüne sahip olmalıdır ki B bunu geçebilir (ancak uygulamamız geçemez).
Örneğin, B bazı haklara sahip veya root olarak çalışıyorsa, A'dan ayrıcalıklı bir eylemi gerçekleştirmesini istemesine izin verebilir.
Bu yetkilendirme kontrolü için, A denetim belirtecini asenkron olarak alır, örneğin dispatch_async'dan xpc_connection_get_audit_token çağrısı yaparak.
Bu durumda bir saldırgan, A'dan bir eylem gerçekleştirmesini istemek için B'nin A'ya mesajlar göndermesini sağlarken Race Condition tetikleyebilir. RC başarılı olduğunda, B'nin denetim belirteci bellekte kopyalanacak ve saldırımızın isteği A tarafından işlenirken yalnızca B'nin talep edebileceği ayrıcalıklı eyleme erişim sağlayacaktır.
Bu, A olarak smd ve B olarak diagnosticd ile gerçekleşti. SMJobBless fonksiyonu, yeni bir ayrıcalıklı yardımcı araç yüklemek için kullanılabilir (root olarak). Eğer root olarak çalışan bir işlem smd ile iletişime geçerse, başka kontroller yapılmayacaktır.
Bu nedenle, B hizmeti diagnosticd'dir çünkü root olarak çalışır ve bir işlemi izlemek için kullanılabilir, bu nedenle izleme başladıktan sonra, saniyede birden fazla mesaj gönderir.
Saldırıyı gerçekleştirmek için:
Standart XPC protokolünü kullanarak smd adlı hizmete bir bağlantı başlatın.
diagnosticd'ye ikincil bir bağlantı oluşturun. Normal prosedürün aksine, iki yeni mach portu oluşturmak ve göndermek yerine, istemci port gönderme hakkı, smd bağlantısıyla ilişkili gönderme hakkının bir kopyasıyla değiştirilir.
Sonuç olarak, XPC mesajları diagnosticd'ye dağıtılabilir, ancak diagnosticd'en gelen yanıtlar smd'ye yönlendirilir. smd için, hem kullanıcıdan hem de diagnosticd'den gelen mesajların aynı bağlantıdan geldiği görünmektedir.
Bir sonraki adım, diagnosticd'ye seçilen bir işlemi izlemeye başlaması için talimat vermektir (potansiyel olarak kullanıcının kendi işlemi). Aynı anda, smd'ye rutin 1004 mesajlarının bir seli gönderilir. Buradaki amaç, ayrıcalıklı yetkilere sahip bir aracı yüklemektir.
Bu eylem, handle_bless fonksiyonu içinde bir yarış koşulunu tetikler. Zamanlama kritik öneme sahiptir: xpc_connection_get_pid fonksiyonu, kullanıcının işleminin PID'sini döndürmelidir (çünkü ayrıcalıklı araç kullanıcının uygulama paketinde bulunur). Ancak, xpc_connection_get_audit_token fonksiyonu, özellikle connection_is_authorized alt rutininde, diagnosticd'ye ait denetim belirtecini referans almalıdır.
XPC (Çapraz İşlem İletişimi) ortamında, olay işleyicileri eşzamanlı olarak çalışmasa da, yanıt mesajlarının işlenmesi benzersiz bir davranış sergiler. Özellikle, yanıt bekleyen mesajlar göndermenin iki farklı yöntemi vardır:
xpc_connection_send_message_with_reply: Burada, XPC mesajı belirlenen bir kuyrukta alınır ve işlenir.
xpc_connection_send_message_with_reply_sync: Tersine, bu yöntemde XPC mesajı mevcut dağıtım kuyruğunda alınır ve işlenir.
Bu ayrım, yanıt paketlerinin bir XPC olay işleyicisinin yürütülmesiyle eşzamanlı olarak ayrıştırılma olasılığını sağladığı için kritik öneme sahiptir. Özellikle, _xpc_connection_set_creds denetim belirtecinin kısmi olarak üzerine yazılmasını önlemek için kilitleme uygulasa da, bu korumayı tüm bağlantı nesnesine genişletmez. Sonuç olarak, bu, bir paketin ayrıştırılması ile olay işleyicisinin yürütülmesi arasındaki aralıkta denetim belirtecinin değiştirilmesine olanak tanıyan bir zayıflık yaratır.
Bu zayıflığı istismar etmek için aşağıdaki kurulum gereklidir:
A ve B olarak adlandırılan iki mach hizmeti, her ikisi de bir bağlantı kurabilir.
A hizmetinin yalnızca B'nin gerçekleştirebileceği belirli bir eylem için bir yetkilendirme kontrolü içermesi gerekir (kullanıcının uygulaması bunu yapamaz).
A hizmeti, bir yanıt bekleyen bir mesaj göndermelidir.
Kullanıcı, B'ye yanıt vereceği bir mesaj gönderebilir.
İstismar süreci aşağıdaki adımları içerir:
A hizmetinin yanıt bekleyen bir mesaj göndermesini bekleyin.
A'ya doğrudan yanıt vermek yerine, yanıt portu ele geçirilir ve B hizmetine bir mesaj göndermek için kullanılır.
Ardından, yasaklı eylemi içeren bir mesaj gönderilir ve bunun B'den gelen yanıtla eşzamanlı olarak işleneceği beklenir.
Aşağıda, tanımlanan saldırı senaryosunun görsel bir temsili bulunmaktadır:
 (1) (1) (1) (1) (1) (1).png)
Örneklerin Bulunmasındaki Zorluklar: xpc_connection_get_audit_token kullanım örneklerini bulmak, hem statik hem de dinamik olarak zordu.
Metodoloji: xpc_connection_get_audit_token fonksiyonunu yakalamak için Frida kullanıldı, olay işleyicilerinden gelmeyen çağrıları filtreledi. Ancak, bu yöntem yalnızca yakalanan işlem için geçerliydi ve aktif kullanım gerektiriyordu.
Analiz Araçları: Ulaşılabilir mach hizmetlerini incelemek için IDA/Ghidra gibi araçlar kullanıldı, ancak bu süreç zaman alıcıydı ve dyld paylaşılan önbelleği ile ilgili çağrılarla karmaşık hale geldi.
Betik Sınırlamaları: dispatch_async bloklarından xpc_connection_get_audit_token çağrılarını analiz etmek için betik yazma girişimleri, blokların ayrıştırılması ve dyld paylaşılan önbelleği ile etkileşimdeki karmaşıklıklar nedeniyle engellendi.
Rapor Edilen Sorunlar: Apple'a smd içindeki genel ve özel sorunları detaylandıran bir rapor gönderildi.
Apple'ın Yanıtı: Apple, smd içindeki sorunu xpc_connection_get_audit_token'ı xpc_dictionary_get_audit_token ile değiştirerek ele aldı.
Çözümün Doğası: xpc_dictionary_get_audit_token fonksiyonu, alınan XPC mesajına bağlı mach mesajından doğrudan denetim belirtecini alması nedeniyle güvenli kabul edilir. Ancak, xpc_connection_get_audit_token gibi kamu API'sinin bir parçası değildir.
Daha Kapsamlı Bir Çözümün Yokluğu: Apple'ın, bağlantının kaydedilen denetim belirteciyle uyumlu olmayan mesajları atma gibi daha kapsamlı bir çözüm uygulamamasının nedeninin ne olduğu belirsizdir. Belirli senaryolarda (örneğin, setuid kullanımı) meşru denetim belirteci değişikliklerinin olabileceği bir faktör olabilir.
Mevcut Durum: Sorun, iOS 17 ve macOS 14'te devam etmekte olup, bunu tanımlamaya ve anlamaya çalışanlar için bir zorluk teşkil etmektedir.
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
