macOS xpc_connection_get_audit_token Saldırısı

Reading time: 8 minutes

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ı Temel Bilgiler

Eğer Mach Mesajlarının ne olduğunu bilmiyorsanız bu sayfayı kontrol edin:

macOS IPC - Inter Process Communication

Şu an için hatırlamanız gereken (buradan tanım):
Mach mesajları bir mach portu üzerinden gönderilir, bu da mach çekirdeğine entegre edilmiş tek alıcı, çoklu gönderici iletişim kanalını temsil eder. Birden fazla süreç, bir mach portuna mesaj gönderebilir, ancak herhangi bir anda yalnızca bir süreç ondan okuyabilir. Dosya tanımlayıcıları ve soketler gibi, mach portları çekirdek tarafından tahsis edilir ve yönetilir ve süreçler yalnızca hangi mach portlarını kullanmak istediklerini belirtmek için kullanabilecekleri bir tam sayı görürler.

XPC Bağlantısı

Eğer bir XPC bağlantısının nasıl kurulduğunu bilmiyorsanız kontrol edin:

macOS XPC

Açıklama Özeti

Bilmeniz gereken ilginç bir nokta, XPC'nin soyutlamasının bire bir bağlantı olmasıdır, ancak bu, birden fazla göndericiye sahip olabilen bir teknoloji üzerine inşa edilmiştir, bu nedenle:

• Mach portları tek alıcı, çoklu gönderici.
• Bir XPC bağlantısının audit token'ı, en son alınan mesajdan kopyalanır.
• Bir XPC bağlantısının audit token'ını 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):

• Audit token'ları 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 port üzerindeki 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 audit token'ın 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 audit token başka normal (cevap olmayan!) mesajlar tarafından üzerine yazılamaz.

Bunu istismar edebilecek iki farklı yöntem:

1. Varyant 1:

• İstismar, hizmet A ve hizmet B'ye bağlanır.
• Hizmet B, kullanıcının yapamayacağı hizmet A'da bir ayrılmış işlevselliği çağırabilir.
• Hizmet A, bir dispatch_async içinde bir bağlantının olay işleyicisi içinde değilken xpc_connection_get_audit_token çağrısını yapar.
• Böylece, farklı bir mesaj Audit Token'ı üzerine yazabilir çünkü olay işleyicisinin dışında asenkron olarak dağıtılmaktadır.
• İstismar, hizmet B'ye hizmet A'ya gönderme hakkını verir.
• Böylece, svc B aslında hizmet A'ya mesajlar gönderecektir.
• İstismar, ayrılmış eylemi çağırmaya çalışır. Bir RC svc A, bu eylemin yetkilendirmesini kontrol ederken, svc B audit token'ı üzerine yazmıştır (istismara, ayrıcalıklı eylemi çağırma erişimi verir).

2. Varyant 2:

• Hizmet B, kullanıcının yapamayacağı hizmet A'da bir ayrılmış işlevselliği çağırabilir.
• İstismar, hizmet A ile bağlantı kurar ve istismara belirli bir cevap portunda bir mesaj gönderir.
• İstismar, hizmet B'ye o cevap portunu geçerek bir mesaj gönderir.
• Hizmet B cevap verdiğinde, hizmet A'ya mesaj gönderir, bu sırada istismar, ayrıcalıklı bir işlevselliğe ulaşmaya çalışarak hizmet A'ya farklı bir mesaj gönderir ve hizmet B'den gelen cevabın Audit token'ı tam zamanında üzerine yazmasını bekler (Race Condition).

Varyant 1: xpc_connection_get_audit_token'ı bir olay işleyicisi dışında çağırma

Senaryo:

• Bağlanabileceğimiz iki mach hizmeti A ve B (sandbox profiline ve bağlantıyı kabul etmeden önceki yetkilendirme kontrollerine dayanarak).
• A, B'nin geçebileceği belirli bir eylem için bir yetkilendirme kontrolüne sahip olmalıdır (ancak uygulamamız sahip olamaz).
• Örneğin, B bazı yetkilere sahipse veya root olarak çalışıyorsa, A'dan ayrıcalıklı bir eylem gerçekleştirmesini istemesine izin verebilir.
• Bu yetkilendirme kontrolü için, A, örneğin dispatch_async'dan xpc_connection_get_audit_token çağrısını yaparak audit token'ı asenkron olarak alır.

Bu, A'nın smd ve B'nin diagnosticd olarak 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 süreç smd ile iletişime geçerse, başka kontroller yapılmayacaktır.

Bu nedenle, hizmet B diagnosticd'dir çünkü root olarak çalışır ve bir süreci 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:

1. Standart XPC protokolünü kullanarak smd adlı hizmete bir bağlantı başlatın.
2. diagnosticd'ye ikincil bir bağlantı oluşturun. Normal prosedürün aksine, iki yeni mach portu oluşturmak ve göndermek yerine, istemci portu gönderme hakkı, smd bağlantısıyla ilişkili gönderme hakkının bir kopyasıyla değiştirilir.
3. 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 izlenimi vardır.

4. Bir sonraki adım, diagnosticd'ye seçilen bir süreci (potansiyel olarak kullanıcının kendi süreci) izlemeye başlaması talimatını vermektir. Aynı anda, smd'ye rutin 1004 mesajlarının bir seli gönderilir. Buradaki amaç, ayrıcalıklı yetkilere sahip bir aracı yüklemektir.
5. 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 sürecinin 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 audit token'ı referans almalıdır.

Varyant 2: cevap yönlendirme

Bir XPC (Çapraz Süreç İletişimi) ortamında, olay işleyicileri eşzamanlı olarak çalışmasa da, cevap mesajlarının işlenmesi benzersiz bir davranış sergiler. Özellikle, cevap bekleyen mesajlar göndermek için iki farklı yöntem vardır:

1. xpc_connection_send_message_with_reply: Burada, XPC mesajı belirlenen bir kuyrukta alınır ve işlenir.
2. 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, cevap paketlerinin bir XPC olay işleyicisinin yürütülmesiyle eşzamanlı olarak ayrıştırılma olasılığını sağlar. Özellikle, _xpc_connection_set_creds audit token'ın 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 audit token'ın 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.
• Hizmet A, yalnızca B'nin gerçekleştirebileceği belirli bir eylem için bir yetkilendirme kontrolü içermelidir (kullanıcının uygulaması bunu yapamaz).
• Hizmet A, bir cevap 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:

1. Hizmet A'nın cevap bekleyen bir mesaj göndermesini bekleyin.
2. A'ya doğrudan yanıt vermek yerine, cevap portu ele geçirilir ve hizmet B'ye bir mesaj göndermek için kullanılır.
3. 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)

Keşif Problemleri

• Örnekleri Bulma Zorlukları: xpc_connection_get_audit_token kullanım örneklerini bulmak, hem statik hem de dinamik olarak zordu.
• Metodoloji: Frida, xpc_connection_get_audit_token fonksiyonunu yakalamak için kullanıldı ve olay işleyicilerinden gelmeyen çağrıları filtreledi. Ancak, bu yöntem yalnızca yakalanan süreçle sınırlıydı ve aktif kullanım gerektiriyordu.
• Analiz Araçları: Ulaşılabilir mach hizmetlerini incelemek için IDA/Ghidra gibi araçlar kullanıldı, ancak 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.

Çözüm

• Bildirim Yapılan Sorunlar: smd içinde bulunan genel ve özel sorunları detaylandıran bir rapor Apple'a 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 audit token'ı alması nedeniyle güvenli kabul edilir. Ancak, bu, 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 audit token'ı ile uyumlu olmayan mesajları atma gibi daha kapsamlı bir çözüm uygulamamasının nedeninin belirsiz olduğu kalmaktadır. Belirli senaryolarda (örneğin, setuid kullanımı) meşru audit token 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.