تكتشف Check Point Research وجود ثغرات في SQLite والتي تسمح باختراق جهاز iPhone

تكتشف Check Point Research وجود ثغرات في SQLite والتي تسمح باختراق جهاز iPhone.

• SQLite هو نظام إدارة قواعد البيانات الذي يتم فيه حفظ جهات اتصال iPhone
• الأنظمة الأخرى التي تستخدم SQLite هي Windows 10 و MacOS و Chrome و Safari و Firefox و Android

اكتشف Check Point® Software Technologies Ltd. (NASDAQ: CHKP) ، المزود العالمي الرائد للأمن السيبراني ، نقاط ضعف تؤثر على SQLite ، وهو نظام إدارة قواعد البيانات الأكثر استخدامًا على مستوى العالم. من خلال هذه الثغرات الأمنية ، يمكن للسيطرة الإلكترونية التحكم في iPhone ، حيث يتم تخزين جهات اتصال هذه الأجهزة في هذا النوع من قواعد البيانات.

"على الرغم من الاعتقاد السائد بأن أجهزة iPhone كانت أكثر أمانًا ، فإن نقاط الضعف هذه تظهر أنه يمكن اختراقها أيضًا. من المهم أن يأخذ المستخدم في الاعتبار أمان أجهزة الكمبيوتر والهواتف المحمولة ، حيث يمكن للمستخدم التحكم وسرقة جميع المعلومات المخزنة "، كما يقول Eusebio Nieva ، المدير الفني لـ Check Point for Spain and Portugal.

سكليتي إنه نظام لإدارة قواعد البيانات متاح على جميع أنظمة التشغيل وأجهزة الكمبيوتر والهواتف المحمولة. على سبيل المثال Windows 10 ، و MacOS ، و iOS ، و Chrome ، و Safari ، و Firefox ، و Android ، من أشهر مستخدمي SQLite. لكونه أحد البرامج الأكثر استخدامًا في العالم ، فإن العديد من البرامج تتضمنه لأغراض مختلفة. على سبيل المثال ، بالإضافة إلى حالة iPhone ، تقوم أجهزة Mac أيضًا بحفظ بعض كلمات المرور على هذا النظام. من خلال نقاط الضعف هذه ، سيكون من الممكن التحكم في أي نظام يستعلم عن قاعدة بيانات يتحكم فيها SQLite.

نظرًا لحقيقة أن SQLite شائعة جدًا ، توجد إمكانيات لا حصر لها لاستغلال هذه الثغرات الأمنية. قامت Check Point بإنشاء عرض توضيحي لإثباته على نظام التشغيل iOS الخاص بجهاز iPhone ، والذي تم تقديمه في حدث Def Con 2019. الاستفادة من نقاط الضعف هذه ، سيكون من الممكن التهرب من آلية التشغيل الآمن Apple والحصول على أذونات المسؤول على أحدث iPhone. كانت Check Point رائدة في إظهار مشكلة عدم حصانة SQLite التي لا تعتمد على المستعرض.

"حتى الآن ، لم يعد التشاور مع قاعدة بيانات خطيرًا ، لكن بحثنا أظهر أنه يمكن أن يكون كذلك. لأن سكليتي تحظى بشعبية كبيرة ، أصبحت هذه الثغرات فرصة كبيرة للاستغلال. خطأ خطير في SQLite هو خطأ خطير في بعض التقنيات الأكثر استخدامًا في العالم ، مثل iPhone أو Dropbox أو Adobe أو Skype"، ويختتم نيفا.

تتضمن Check Point في أنظمة الحماية من الاختراق (IPS) حلول الأمان التي تضمن عدم تأثر المستخدم بهذا النوع من انتهاكات البرامج.

لمزيد من المعلومات حول هذه الثغرات الأمنية ، يرجى زيارة: https://research.checkpoint.com/select-code_execution-from-using-sqlite/

نترك لك الإدخال المترجم.

الحصول على تنفيذ التعليمات البرمجية باستخدام قاعدة بيانات SQLite ضارة البحث عن طريق: عمر نور

SQLite هي واحدة من أكثر البرامج نفذاً في العالم. ومع ذلك ، من منظور الأمان ، تم فحصه فقط من خلال عدسة WebSQL واستغلال المستعرض. ونحن نعتقد أن هذا هو مجرد غيض من فيض.

في التحقيق الذي أجريناه على المدى الطويل ، نقوم بتجربة استغلال مشكلات تلف الذاكرة في SQLite دون الاعتماد على أي بيئة أخرى غير لغة SQL. باستخدام تقنيات الاستجواب المختلطة للاستعلام وبرامج البرمجة الموجهة للاستعلام ، نوضح أنه من الممكن استغلال مشكلات تلف الذاكرة بشكل موثوق في مشغل SQLite. نعرض هذه التقنيات في اثنين من السيناريوهات في العالم الحقيقي: إنشاء كلمة مرور لسرقة خادم الواجهة الخلفية وتحقيق استمرارية نظام iOS بامتيازات أكبر.

نأمل أنه من خلال إطلاق البحث والمنهجية ، سيتم إلهام مجتمع أبحاث الأمان لمواصلة فحص SQLite في السيناريوهات التي لا حصر لها حيث تتوفر. بالنظر إلى حقيقة أن SQLite مدمجة عمليا في جميع أنظمة التشغيل الرئيسية ، وأجهزة الكمبيوتر المكتبية أو الأجهزة المحمولة ، فإن المناظر الطبيعية والفرص لا حصر لها. بالإضافة إلى ذلك ، العديد من الأوليات المقدمة هنا ليست حصرية لـ SQLite ويمكن نقلها إلى محركات SQL أخرى. مرحبًا بكم في العالم الجديد الشجاع المتمثل في استخدام لغة الاستعلامات المنظمة المألوفة للاستغلال البدائي.

حافز

بدأ هذا التحقيق متى omriher وكنت أبحث في شفرة المصدر المسربة لبعض لصوص كلمة المرور سيئة السمعة. بينما هناك العديد من سرقات كلمة المرور ( Azorult ، لوكي بوت و المهر، على سبيل المثال لا الحصر) ، طريقة عملها هي نفسها تقريبا:

يصبح الكمبيوتر مصابًا والبرامج الضارة تلتقط بيانات الاعتماد عند استخدام أو جمع بيانات الاعتماد المخزنة التي يحتفظ بها العديد من العملاء.
ليس من غير المألوف أن يستخدم برنامج العميل قواعد بيانات SQLite لهذه الأغراض.
بعد قيام البرامج الضارة بتجميع ملفات SQLite هذه ، يتم إرسالها إلى خادم C2 الخاص بها حيث يتم تحليلها باستخدام PHP وتخزينها في قاعدة بيانات جماعية تحتوي على جميع بيانات الاعتماد المسروقة.

عند قراءة شفرة المصدر المصفاة لصوص كلمة المرور هذه ، نبدأ في التكهن على سطح الهجوم الموصوف أعلاه.
هل يمكننا الاستفادة من التحميل والتشاور من قاعدة بيانات غير موثوقة لصالحنا؟
هذه القدرات يمكن أن يكون لها آثار أكبر بكثير في سيناريوهات لا حصر لها ، منذ ذلك الحين سكليتي هي واحدة من أكثر البرامج التي يتم تنفيذها على نطاق واسع .

قاعدة رمز معقدة بشكل مدهش ، متوفرة على أي جهاز يمكن تخيله تقريبًا. كل ذلك هو الدافع الذي نحتاجه ، وهكذا بدأت رحلتنا.

مقدمة لسكليتي

هناك العديد من الاحتمالات التي تستخدمها حاليا SQLite ، حتى لو كنت لا تعرف ذلك.
لاستشهاد مؤلفيه:

SQLite هي مكتبة لغة C تنفذ محرك قاعدة بيانات SQL صغير وسريع ومستقل وموثوق به وعالي المزايا. سكليتي هو محرك قاعدة البيانات الأكثر استخداما في العالم. تم دمج SQLite في جميع الهواتف المحمولة ومعظم أجهزة الكمبيوتر ويتم تضمينها في عدد لا يحصى من التطبيقات التي يستخدمها الناس كل يوم.

على عكس معظم قواعد بيانات SQL الأخرى ، لا يحتوي SQLite على عملية خادم منفصلة. SQLite يقرأ ويكتب مباشرة إلى ملفات القرص العادية. يتم تضمين قاعدة بيانات SQL كاملة مع العديد من الجداول والفهارس والمشغلات وطرق العرض داخل ملف قرص واحد.

سطح الهجوم

الجزء التالي هو مثال عام إلى حد ما على الواجهة الخلفية لسرقة كلمة المرور.

نظرًا لأننا نتحكم في قاعدة البيانات ومحتواها ، يمكن تقسيم سطح الهجوم المتاح لنا إلى قسمين: التحميل والتحليل الأولي لقاعدة البيانات الخاصة بنا ، واستعلام SELECT الذي تم إجراؤه ضدها.

الحمل الأولي الذي أدلى به sqlite3_open هو في الواقع منطقة محدودة للغاية ؛ إنها في الأساس كمية كبيرة من رمز التثبيت والتكوين لفتح قاعدة البيانات. سطحنا هو أساسا تحليل رأس الذي تم اختباره في المعركة ضد AFL.

تصبح الأمور أكثر إثارة للاهتمام عندما نبدأ بالتشاور مع قاعدة البيانات.
باستخدام كلمات مؤلفي سكليتي:

"عبارة SELECT هي الأمر الأكثر تعقيدًا في لغة SQL."

على الرغم من أننا لا نملك السيطرة على الاستعلام نفسه (نظرًا لأنه مدون في هدفنا) ، فإن دراسة عملية SELECT بعناية ستكون مفيدة في بحثنا عن الاستغلال.

نظرًا لأن SQLite3 عبارة عن جهاز افتراضي ، يجب أولاً تجميع كل عبارة SQL في برنامج تعليمات برمجية بايت باستخدام أحد الإجراءات sqlite3_prepare * .
من بين عمليات أخرى ، تعمل وظيفة الإعداد على تجاوز وتوسيع جميع استعلامات SELECT الفرعية. جزء من هذه العملية هو التحقق من أن جميع الكائنات ذات الصلة (مثل الجداول أو طرق العرض) موجودة بالفعل ووضعها في المخطط الرئيسي.

sqlite_master و DDL

كل قاعدة بيانات SQLite لديه sqlite_masterجدول يحدد مخطط قاعدة البيانات وكافة عناصره (مثل الجداول ، المشاهدات ، الفهارس ، وما إلى ذلك).
يعرف جدول sqlite_master بأنه:

الجزء الذي يهمنا بشكل خاص هو العمود sql.
هذا الحقل هو DDL (لغة تعريف البيانات) المستخدمة لوصف الكائن.
بمعنى ما ، تشبه أوامر DDL ملفات رأس C. يتم استخدام أوامر DDL لتحديد بنية وأسماء وأنواع حاويات البيانات داخل قاعدة البيانات ، تمامًا مثل ملف الرأس. وهي تحدد بشكل عام تعريفات الأنواع والبنى والفئات وغيرها من هياكل البيانات.

تظهر عبارات DDL هذه بالفعل في نص عادي إذا فحصنا ملف قاعدة البيانات:

أثناء تحضير الاستعلام ، يحاول sqlite3LocateTable () العثور على البنية في الذاكرة التي تصف الجدول الذي نرغب في استشارته.

يقوم sqlite3LocateTable () بقراءة المخطط المتوفر في sqlite_master ، وإذا كانت هذه هي المرة الأولى ، فسيكون له أيضًا رد اتصال لكل نتيجة تتحقق من أن إعلان DDL صالح ويخلق بنيات البيانات الداخلية الضرورية التي تصف الكائن في السؤال.

بقع DDL

نتساءل عما إذا كنا قد علمنا بعملية التحضير هذه ، هل يمكننا ببساطة استبدال نص عادي DDL داخل الملف؟ إذا استطعنا ضخ SQL الخاصة بنا في الملف ، فربما يمكننا التأثير في سلوكه.

وفقًا لمقتطف الشفرة أعلاه ، يبدو أن تعليمات DDL يجب أن تبدأ بـ "إنشاء".
مع وضع هذا القيد في الاعتبار ، كنا بحاجة لتقييم سطحنا.
التحقق من وثائق SQLite كشف أن هذه هي الكائنات المحتملة التي يمكننا إنشاؤها:

أعطانا الأمر CREATE VIEW فكرة مثيرة للاهتمام. بعبارة بسيطة للغاية ، تعد VIEWs عبارة عن عبارات SELECT المعبأة مسبقًا فقط. إذا استبدلنا الجدول المتوقع بالبرنامج المستهدف بـ VISTA متوافق ، فسيتم الكشف عن فرص مثيرة للاهتمام.

خطف أي استفسار

تخيل السيناريو التالي:
تحتوي قاعدة البيانات الأصلية على TABLE فريد يسمى دمية يتم تعريفه كـ:

يستهدف البرنامج المستهدف ما يلي:

في الواقع ، يمكننا اختطاف هذا الاستعلام إذا أنشأنا دمية كطريقة عرض:

يسمح لنا هذا "الاعتراض" بعرض اختطاف الاستعلام ، مما يعني أننا نقوم بإنشاء استعلام جديد تمامًا نحن نسيطر تماما.

تعمل هذه الفروق الدقيقة على توسيع سطح الهجوم بشكل كبير ، بدءًا من التحليل البسيط للرأس والاستعلام الذي لا يمكن التحكم فيه الذي تم إجراؤه بواسطة برنامج التحميل ، إلى الحد الذي يمكننا من خلاله التفاعل الآن مع أجزاء واسعة من مترجم SQLite عن طريق تصحيح الـ DDL وإنشاء وجهات نظرنا الخاصة . مع الاستفسارات الفرعية.

الآن وبعد أن أصبح بإمكاننا التفاعل مع مترجم SQLite ، كان سؤالك التالي هو ما هي بدائل الاستغلال التي يتم دمجها في SQLite؟ هل تسمح لأي أمر من نظام القراءة أو الكتابة إلى نظام الملفات؟

نظرًا لأننا لسنا أول من لاحظ الإمكانات الهائلة لـ SQLite من منظور الاستغلال ، فمن المنطقي مراجعة العمل السابق المنجز في هذا المجال. نبدأ من الأساسيات.

حقن SQL

بصفتنا باحثين ، من الصعب علينا أن نتهجى لغة الاستعلامات البنيوية بدون "i" ، لذلك يبدو أن هناك مكانًا مناسبًا للبدء. بعد كل شيء ، نريد أن نتعرف على الأولويات الداخلية التي يقدمها SQLite. هل هناك أي قيادة النظام؟ هل يمكننا تحميل مكتبات تعسفية؟

يبدو أبسط خدعة هي إرفاق ملف قاعدة بيانات جديد والكتابة إليه باستخدام شيء مثل:

نحن نعلق قاعدة بيانات جديدة ، وإنشاء جدول واحد وإدراج سطر واحد من النص. تنشئ قاعدة البيانات الجديدة ملفًا جديدًا (نظرًا لأن قواعد البيانات عبارة عن ملفات في SQLite) مع وجود صفحة الويب الخاصة بنا.
تقوم الطبيعة المتسامحة لمترجم PHP بتحليل قاعدة البيانات الخاصة بنا حتى تصل إلى علامة PHP المفتوحة وهي "<؟".
من المؤكد أن كتابة صفحة الويب عبارة عن انتصار في سيناريو سرقة كلمة المرور الخاصة بنا ، وكما تتذكر ، لا يمكن لـ DDL البدء بـ "ATTACH"

خيار آخر ذو صلة هو الوظيفة load_extension . بينما يجب أن تسمح لنا هذه الوظيفة بتحميل كائن مشترك تعسفي ، يتم تعطيله بشكل افتراضي.

تلف الذاكرة في سكليتي

مثل أي برنامج آخر مكتوب بلغة C ، تعد مشكلات أمان الذاكرة أمرًا يجب مراعاته عند تقييم أمان SQLite.
في بلده العظيم بلوق وظيفة وصف Michał Zalewski كيف انضم إلى SQLite مع AFL لتحقيق بعض النتائج المثيرة للإعجاب: 22 خطأ في 30 دقيقة فقط من التشويش.

ومن المثير للاهتمام أن SQLite قد بدأت في استخدام AFL كجزء لا يتجزأ من مجموعة الاختبارات الرائعة.

عوملت فساد الذاكرة هذه بالشدة المتوقعة (يستحق ريتشارد هوب وفريقه الكثير من الاحترام). ومع ذلك ، من وجهة نظر المهاجم ، فإن هذه الأخطاء قد تكون طريقًا صعبًا للاستغلال بدون إطار عمل لائق للاستفادة منها.
تمثل عمليات التخفيف الحديثة عقبة رئيسية أمام استغلال مشكلات تلف الذاكرة ويحتاج المهاجمون إلى إيجاد بيئة أكثر مرونة.

سوف يجد مجتمع أبحاث الأمن قريباً الهدف المثالي!

مزود الويب

Web SQL Database هي عبارة عن واجهة برمجة تطبيقات لصفحة ويب لتخزين البيانات في قواعد البيانات التي يمكن الرجوع إليها باستخدام متغير SQL من خلال JavaScript. توقفت مجموعة عمل تطبيقات الويب W3C عن العمل على المواصفات في نوفمبر 2010 ، بسبب عدم وجود تطبيقات مستقلة بخلاف SQLite.

حاليًا ، لا تزال واجهة برمجة التطبيقات متوافقة مع Google Chrome و Opera و Safari.
انهم جميعا استخدام SQLite كواجهة خلفية API هذا.

لفت الإدخال غير الموثوق به في SQLite ، الذي يمكن الوصول إليه من أي موقع على شبكة الإنترنت ضمن بعض المتصفحات الأكثر شعبية ، انتباه مجتمع الأمن ، ونتيجة لذلك ، بدأ عدد الثغرات الأمنية في الازدياد.
فجأة ، يمكن استغلال الأخطاء في SQLite بواسطة مترجم JavaScript لتحقيق استغلال موثوق للمستعرض.

تم نشر العديد من التقارير البحثية المثيرة للإعجاب:

• ثمار منخفضة مثل CVE-2015-7036
  • Dereference من المؤشر لا موثوقة fts3_tokenizer ()
• المزيد من المهارات المعقدة المقدمة في Blackhat 17 من قبل فريق شيتين
  • اكتب الارتباك على fts3OptimizeFunc ()
• الاخطاء الاخيرة لماجلان استغلالها من قبل الخروج
  • عدد صحيح تجاوز في fts3SegReaderNext ()

يكشف نمط واضح في بحث WebSQL السابق أن وحدة نمطية للجدول الافتراضي تسمى "FTS" يمكن أن تكون هدفًا مثيرًا للاهتمام لبحثنا.

FTS

البحث عن النص الكامل (FTS) عبارة عن وحدة نمطية للجدول الافتراضي تتيح البحث عن النص في مجموعة من المستندات.
من منظور عبارة SQL ، يشبه كائن الجدول الظاهري أي جدول أو طريقة عرض أخرى. ولكن وراء الكواليس ، تستدعي الاستعلامات في جدول افتراضي طرق رد الاتصال في جداول الظل بدلاً من القراءة والكتابة المعتادة إلى ملف قاعدة البيانات.

تستخدم بعض تطبيقات الجداول الافتراضية ، مثل FTS ، جداول قاعدة بيانات حقيقية (غير افتراضية) لتخزين المحتوى.

على سبيل المثال ، عند إدراج سلسلة في الجدول الظاهري FTS3 ، يجب إنشاء بعض البيانات التعريفية للسماح بالبحث النصي الفعال. يتم تخزين بيانات التعريف هذه في جداول حقيقية تسمى "٪ _segdir" و "٪ _segments" ، بينما يتم تخزين المحتوى نفسه في ""٪ _content "حيث"٪ "هو اسم الجدول الظاهري الأصلي.
تسمى هذه الجداول المساعدة الفعلية التي تحتوي على بيانات للجدول الظاهري "جداول الظل"

نظرًا لطبيعتها الموثوقة ، توفر الواجهات التي تمرر البيانات بين جداول الظل أرضًا خصبة للأخطاء. CVE-2019-8457 ، – ثغرة جديدة في قراءة OOB وجدت في وحدة الجدول الافتراضي RTREE ، تثبت ذلك بشكل جيد.

من المتوقع أن تبدأ الجداول الافتراضية RTREE ، المستخدمة في الفهرسة الجغرافية ، بعمود كامل. لذلك ، تتوقع واجهات RTREE الأخرى أن يكون العمود الأول من RTREE عددًا صحيحًا. ومع ذلك ، إذا أنشأنا جدولًا يكون العمود الأول فيه عبارة عن سلسلة ، كما هو موضح في الشكل التالي ، فقم بتمريره إلى الواجهة rtreenode () ، تحدث قراءة OOB.

والآن بعد أن أصبح بإمكاننا استخدام اختطاف الاستعلام للسيطرة على استعلام ومعرفة مكان العثور على الثغرات ، حان الوقت للمضي قدماً لاستغلال التطوير.

SQLite Internals لاستغلال التنمية

توضح المنشورات السابقة حول استغلال سكليتي بوضوح أن بيئة الغلاف كانت ضرورية دائمًا ، سواء كان مترجم PHP الذي شوهد في هذا المدهش بلوق وظيفة حول إساءة استخدام رموز SQLite أو أحدث عمل في Web SQL من راحة مترجم JavaScript.

نظرًا لأن SQLite موجود في كل مكان تقريبًا ، فقد بدا غير مقنع لإمكانية استغلاله وبدأنا استكشاف استخدام مكونات SQLite الداخلية لأغراض الاستغلال.
أصبح مجتمع البحث جيدًا في استخدام جافا سكريبت لتطوير الاستغلال. هل يمكننا تحقيق بدايات مماثلة مع SQL؟

بالنظر إلى أن SQL هو تورينج كاملة (( 1 ) ، ( 2 )) ، بدأنا في إنشاء قائمة رغبات بدائية لتطوير مآثر على أساس تجربة pwning لدينا.
استغلال الحديثة المكتوبة حصرا في SQL لديها القدرات التالية:

• فقدان الذاكرة
• تعبئة وتفريغ أعداد صحيحة إلى مؤشرات 64 بت.
• مؤشر حسابي
• وضع الأشياء الخاطئة المعقدة في الذاكرة.
• رذاذ كومة

واحدًا تلو الآخر ، سنتناول هذه الأولويات وننفذها باستخدام لغة SQL.

من أجل تحقيق RCE في PHP7 ، سوف نستخدم يوم واحد حتى الآن دون تحديد of CVE-2015-7036.

انتظر ذلك؟ كيف يتم إصلاح هذا الخطأ لمدة 4 سنوات؟ إنها حقًا قصة مثيرة للاهتمام ومثال رائع على حجتنا.
تم اعتبار هذه الميزة ضعيفة في سياق البرنامج الذي يسمح لـ SQL التعسفي من مصدر غير موثوق به (Web SQL) ، لذلك تم تخفيفه وفقًا لذلك.
ومع ذلك ، فإن استخدام SQLite متعدد الاستخدامات بحيث لا يزال بإمكاننا تفعيله في العديد من السيناريوهات.

خطة لعبة الاستغلال

CVE-2015-7036 هو خطأ مناسب جدًا للعمل به.
ببساطة ، وظيفة fts3_tokenizer () إرجاع Vulnerable عنوان الرمز المميز عند استدعاء وسيطة واحدة (مثل "simple" أو "porter" أو أي رمز مميز آخر مسجل).

عند الاتصال باستخدام وسيطين ، يتخطى fts3_tokenizer عنوان الرمز المميز في الوسيطة الأولى مع العنوان الذي يوفره blob في الوسيطة الثانية.
بعد أن يتم تجاوز رمز مميز معين ، فإن أي مثيل جديد لجدول fts الذي يستخدم هذا الرمز المميز يسمح لنا باختطاف تدفق البرنامج.

خطتنا لعبة الاستغلال:

• تسرب عنوان Tokenizer
• حساب العنوان الأساسي
• مزيف رمزية وهمية من شأنها أن تنفذ التعليمات البرمجية الخبيثة لدينا
• قم بإلغاء أحد الرموز الرمزية باستخدام الرمز المميز لدينا
• مثال على جدول fts3 لتفعيل الشيفرات الخبيثة

الآن دعنا نعود إلى تطوير استغلالنا.

البرمجة الموجهة نحو الاستعلام ©

نحن فخورون بتقديم نهجنا الفريد لتطوير الاستغلال باستخدام لغة الاستعلام المنظمة المألوفة. نحن نشارك QOP مع المجتمع على أمل تشجيع الباحثين على البحث عن إمكانيات غير محدودة لاستغلال محركات قاعدة البيانات.
ويرافق كل من الأوليات التالية مثالا على قذيفة sqlite3.

بينما يمنحك هذا تلميحًا لما تريد تحقيقه ، ضع في اعتبارك أن هدفنا النهائي هو زرع كل تلك العناصر الأولية في جدول sqlite_master واختطاف الاستعلامات التي يصدرها البرنامج الوجهة الذي يقوم بتحميل وتحميل ملف SQLite db الضار

تسرب الذاكرة – ثنائي

من المؤكد أن التخفيفات مثل ASLR رفعت عائق استغلال الفساد في الذاكرة. من الطرق الشائعة لهزيمته معرفة شيء عن تصميم الذاكرة التي تحيط بنا.
هذا هو المعروف باسم تسرب الذاكرة.
تعتبر فقدان الذاكرة فئة فرعية من الثغرات الأمنية ، ولكل منها تكوين مختلف قليلاً.

في حالتنا ، فإن التسرب هو عودة BLOB بواسطة SQLite.
تعتبر BLOBs هدفًا جيدًا للهروب ، حيث تحتوي في بعض الأحيان على مؤشرات ذاكرة.

يتم استدعاء fts3_tokenizer () الضعيفة باستخدام وسيطة واحدة وإرجاع عنوان ذاكرة الرمز المميز المطلوب. عرافة () ماذا يجعل الإنسان قابلاً للقراءة.
من الواضح أننا نحصل على بعض عناوين الذاكرة ، لكن يتم عكسها نظرًا لانخفاض درجة الصلاحية.
بالتأكيد يمكننا قلبها باستخدام بعض عمليات سلسلة SQLite المدمجة.

¡Substr () يبدو أنه مناسب تمامًا! يمكننا أن نقرأ BLOB endian ، لكن هذا يثير سؤالًا آخر: كيف يمكننا تخزين الأشياء؟

سلسلة QOP

وبطبيعة الحال ، يتطلب تخزين البيانات في SQL عبارة INSERT. نظرًا لتعزيز التحقق من sqlite_master ، لا يمكننا استخدام INSERT نظرًا لأن جميع الإعلانات يجب أن تبدأ بـ "CREATE". نهجنا في هذا التحدي هو ببساطة تخزين استفساراتنا تحت VISTA ذات مغزى وتسلسلها.
المثال التالي يجعله أوضح قليلاً:

قد لا يبدو هذا فرقًا كبيرًا ، ولكن كلما أصبحت سلسلتنا أكثر تعقيدًا ، فإن القدرة على استخدام متغيرات وهمية ستجعل حياتنا بالتأكيد أكثر سهولة.

تفريغ مؤشرات 64 بت

إذا واجهت أي وقت مضى تحديات pwning ، فإن مفهوم مؤشرات التعبئة والتفريغ لا ينبغي أن يكون غريبًا.
يجب أن يسهل هذا البدائي تحويل قيمنا السداسية عشرية (مثل التسرب الذي حققناه للتو) إلى أعداد صحيحة. القيام بذلك يسمح لنا بإجراء العديد من العمليات الحسابية على هذه المؤشرات في الخطوات التالية.

يقوم هذا الاستعلام بتكرار char سلسلة ست عشرية بواسطة char في الاتجاه المعاكس باستخدام substr ().

يتم تنفيذ ترجمة لهذه الشخصية باستخدام هذا خدعة بارعة مع تعديل طفيف لل instr () الذي يقوم على 1.
كل ما نحتاجه الآن هو الإزاحة الصحيحة على يمين علامة *.

المؤشر الحسابي

حساب المؤشر هو مهمة سهلة إلى حد ما مع الأعداد الصحيحة في متناول اليد. على سبيل المثال ، يكون استخراج قاعدة الصورة من المؤشر الخاص بنا من الرمز المميز المصفّى سهلاً كما يلي:

التعبئة والتغليف مؤشر 64 بت.

بعد قراءة المؤشرات التي تمت تصفيتها ومعالجتها بناءً على إرادتنا ، من المنطقي تجميعها مرة أخرى في شكلها الداخلي الصغير حتى نتمكن من كتابتها في مكان ما.
سكليتي char () يجب استخدامه هنا ، حيث تشير وثائقه إلى أنه "سيعود سلسلة مكونة من أحرف تحتوي على قيم نقطة رمز Unicode لعدد صحيح."
لقد تبين أنها تعمل بشكل جيد ، ولكن فقط في نطاق محدود من الأعداد الصحيحة

تم ترجمة أعداد صحيحة أكبر إلى نقاط رمز 2 بايت الخاصة بهم.
بعد ضرب رؤوسنا ضد وثائق سكليتي ، كان لدينا فجأة عيد الغطاس الغريب: استغلالنا هو في الواقع قاعدة بيانات.
يمكننا أن نعد مسبقًا جدولًا يعين أعدادًا صحيحة لقيمها المتوقعة.

الآن لدينا استفسار التعبئة مؤشر على النحو التالي:

وضع الأشياء الخاطئة المعقدة في الذاكرة

من المؤكد أن كتابة مؤشر واحد مفيد ، لكن لا يزال غير كافٍ. تتطلب العديد من سيناريوهات استغلال مشكلة أمان الذاكرة المهاجمين صياغة كائن أو بنية في الذاكرة أو حتى كتابة سلسلة ROP.

في الأساس ، سوف نقوم بتوصيل العديد من لبنات البناء المذكورة أعلاه.
على سبيل المثال ، دعنا نصوغ الرمز المميز الخاص بنا ، كما هو موضح هنا .
يجب أن يتوافق الرمز المميز لدينا مع الواجهة المتوقعة بواسطة SQLite المحددة هنا:

باستخدام الطرق الموضحة أعلاه واستعلام JOIN البسيط ، يمكننا تزوير الكائن المطلوب بسهولة تامة.

عند التحقق من النتيجة باستخدام مصحح أخطاء منخفض المستوى ، نرى أنه في الحقيقة تم إنشاء كائن مزيف رمزي.

رذاذ كومة

الآن وقد أنشأنا كائنًا مزيفًا ، فمن المفيد أحيانًا رش الكومة به.
من الناحية المثالية ، يجب أن يكون هذا شكل متكرر من هذا الأخير.

لسوء الحظ ، لا يقوم SQLite بتطبيق الدالة REPEAT () مثل MySQL.
ومع ذلك، هذا أعطانا موضوع حل أنيق.

وظيفة zeroblob (N) إرجاع BLOB يتكون من N بايت أثناء استخدام يستبدل () لاستبدال تلك الأصفار مع كائن وهمية لدينا.

يوضح البحث عن تلك 0x41 أننا نحقق أيضًا تناسقًا مثاليًا. مراقبة التكرار كل 0x20 بايت.

تسرب الذاكرة: كومة

بالنظر إلى خطة لعبتنا للاستغلال ، يبدو أننا نسير في الاتجاه الصحيح.
نحن نعلم بالفعل أين توجد الصورة الثنائية ، يمكننا أن نستنتج أين توجد الوظائف الضرورية ورش الكومة باستخدام الرمز المميز لدينا.

الآن هو الوقت المناسب لإلغاء رمز مميز مع أحد الأشياء التي تم رشها. ومع ذلك ، نظرًا لأن اتجاه الكومة عشوائيًا أيضًا ، فإننا لا نعرف من أين تم تخصيص رذاذنا.
يتطلب تسرب في الكومة أن لدينا مشكلة عدم حصانة أخرى.

مرة أخرى ، سوف نشير إلى واجهة الجدول الظاهري.
نظرًا لأن الجداول الافتراضية تستخدم جداول الظل الأساسية ، فمن الشائع جدًا أن تمر المؤشرات العادية بين واجهات SQL المختلفة.

ملاحظة: تم تخفيف هذا النوع الدقيق من المشكلة سكليتي 3.20 . لحسن الحظ ، يتم تصنيف PHP7 مع إصدار سابق. في حالة وجود نسخة محدثة ، يمكن أيضًا استخدام CVE-2019-8457 هنا.

لتصفية عنوان الكومة ، نحتاج إلى إنشاء جدول fts3 مقدمًا وإساءة استخدام واجهة MATCH الخاصة به.

كما رأينا في أول فقدان للذاكرة ، يكون المؤشر صغيرًا ، لذا يجب عكسه. لحسن الحظ ، نحن نعرف بالفعل كيفية القيام بذلك مع SUBSTR ().
الآن وقد أصبحنا نعرف موقع التخزين الديناميكي الخاص بنا ويمكنه الرش بشكل صحيح ، يمكننا أخيرًا أن نتخطى الرمز المميز باستخدام الرمز المميز لدينا!

وضع كل ذلك معا

مع وجود كل بدائل الاستغلال المطلوبة في متناول اليد ، فقد حان الوقت للعودة إلى حيث بدأنا: استغلال لص كلمة المرور C2.

كما هو موضح أعلاه ، نحن بحاجة إلى تكوين "فخ" VIEW لبدء استغلال لدينا. لذلك ، يجب علينا دراسة هدفنا وإعداد VISTA الصحيح.

كما هو موضح في المقتطف أعلاه ، يتوقع هدفنا أن تحتوي قاعدة البيانات الخاصة بنا على جدول يسمى Notes مع عمود يسمى BodyRich بداخله. لاختطاف هذا الاستعلام ، نقوم بإنشاء VIEW التالية

بعد استشارة Notes ، يتم تنفيذ 3 سلاسل QOP. دعنا نحلل أول واحد.

heap_spray

يجب أن تملأ سلسلة QOP الأولى لدينا الكومة بالكثير من الرموز الرمزية الخبيثة.

p64_simple_create و p64_simple_destroy و p64_system هي كل السلاسل التي تحققت من خلال قدراتنا على التسرب والتعبئة.

على سبيل المثال ، يتم إنشاء p64_simple_create على النحو التالي:

عندما تصبح هذه السلاسل معقدة للغاية وسريعة للغاية ومتكررة للغاية ، فإننا ننشئها QOP.py .
يبسط QOP.py الأشياء قليلاً عن طريق إنشاء هذه الاستعلامات بأسلوب pwntools.
يصبح إنشاء العبارات أعلاه سهلاً:

مظاهرة

لتناول الطعام ؛

الآن وقد وضعنا إطارًا لاستغلال أي موقف لا يمكن فيه للمحقق التأكد من أن قاعدة البيانات ليست ضارة ، فلنبحث عن حالة استخدام أخرى مثيرة للاهتمام لاستغلال SQLite.

IOS المثابرة

من الصعب تحقيق الثبات في نظام التشغيل iOS ، حيث يجب توقيع جميع الملفات القابلة للتنفيذ كجزء من Secure Boot of Apple. لحسن الحظ بالنسبة لنا ، لم يتم توقيع قواعد بيانات SQLite.

باستخدام قدراتنا الجديدة ، سنستبدل إحدى قواعد البيانات الشائعة الاستخدام بإصدار ضار. بعد إعادة تشغيل الجهاز واستشارة قاعدة البيانات الضارة الخاصة بنا ، نحصل على تنفيذ التعليمات البرمجية.

لإظهار هذا المفهوم ، استبدلنا قاعدة بيانات جهات الاتصال «AddressBook.sqlitedb». كما تم في استغلال PHP7 الخاص بنا ، أنشأنا بيانين إضافيين لـ DDL. يتجاوز أحد عبارات DDL الرمز المميز "البسيط" الافتراضي ، ويقوم بيان DDL الآخر بإطلاق التعطل عند محاولة إنشاء مثيل لعلامة رمزية باطلة. الآن ، كل ما يتعين علينا القيام به هو إعادة كتابة كل جدول في قاعدة البيانات الأصلية كطريقة مختطفة لأي استفسارات مقدمة وإعادة توجيهها إلى DDL الضارة الخاصة بنا.

استبدل جهات اتصال db بجهات اتصال db الضارة الخاصة بنا وأعد تشغيل النتائج في كتلة iOS التالية:

كما هو متوقع ، تم حظر عملية الاتصال في 0x414141414141414149 حيث توقعنا العثور على مُنشئ xCreate لرمز مزيف لدينا.

بالإضافة إلى ذلك ، يتم مشاركة جهات اتصال db بين العديد من العمليات. جهات الاتصال ، و Facetime ، و Springboard ، و WhatsApp ، و Telegram ، و XPCProxy هي مجرد بعض العمليات التي تستشيرها. بعض هذه العمليات أكثر امتيازًا من غيرها. بمجرد أن نثبت أنه يمكننا تنفيذ التعليمات البرمجية في سياق عملية التشاور ، تسمح لنا هذه التقنية أيضًا بتوسيع ورفع مستوى امتيازاتنا.

لقد تم الكشف عن أبحاثنا ومنهجيتنا بطريقة مسؤولة Apple وتم تكليفهم بـ CVE التالية:

• CVE-2019-8600
• CVE-2019-8598
• CVE-2019-8602
• CVE-2019-8577

العمل في المستقبل

بالنظر إلى حقيقة أن SQLite مدمجة عملياً في أي منصة تقريبًا ، فإننا نعتقد أننا بالكاد خدشنا طرف الجبل الجليدي عندما يتعلق الأمر بإمكانية استغلاله. نأمل أن يأخذ مجتمع الأمن هذا البحث المبتكر والأدوات التي تم إطلاقها ودفعها إلى الأمام. فيما يلي بعض الخيارات التي نعتقد أنها قد تكون مثيرة للاهتمام

• خلق مآثر أكثر تنوعا. يمكن القيام بذلك عن طريق بناء مآثر ديناميكية عن طريق اختيار أدوات QOP ذات الصلة من الجداول الجاهزة باستخدام وظائف مثل sqlite_version () أو sqlite_compileoption_used () .
• تحقيق بدائل استغلال أقوى مثل R / W. التعسفي
• Busque otros escenarios en los que el interrogador no pueda verificar la confiabilidad de la base de datos.

Conclusión

Establecimos que simplemente consultar una base de datos puede no ser tan seguro como espera. Usando nuestras técnicas innovadoras de Secuestro de consultas y Programación orientada a consultas, demostramos que los problemas de corrupción de memoria en SQLite ahora pueden ser explotados de manera confiable. A medida que nuestras jerarquías de permisos se vuelven más segmentadas que nunca, está claro que debemos repensar los límites de la entrada SQL confiable / no confiable. Para demostrar estos conceptos, logramos la ejecución remota de código en un backend de robo de contraseñas que ejecuta PHP7 y obtuvimos persistencia con mayores privilegios en iOS. Creemos que estos son solo un par de casos de uso en el panorama interminable de SQLite.

El producto Check Point IPS protege contra esta amenaza: «SQLite fts3_tokenizer Ejecución remota de código de puntero no confiable (CVE-2019-8602)».