دانلود رایگان مقاله هک کورکورانه

چکیده

          نشان می‌دهیم که نوشتن از راه دور برای سرریز بافر بدون داشتن یک کپی از هدف باینری یا کد منبع، در برابر خدماتی که پس از شکست مجدد راه‌اندازی می‌شوند ممکن است. این مسئله امکان هک خدمات اختصاصی باینری، یا سرورهای منبع باز گردآوری شده به‌صورت دستی و نصب از منبع را فراهم می‌کند. تکنیک سنتی معمولا در یک فایل باینری خاص و توزیع‌شده، به‌صورت یکسان عمل می‌کند که در آن هکر، محل ابزار مفید برای برنامه‌نویسی بازگشت‌گرا (ROP) را می‌داند. ROP کورکورانه  (BROP)که در این مقاله ارائه شده است به جای حمله از راه دور، ابزارهای ROP کافی برای انجام یک سیستم فراخوانی Write و انتقال آسیب‌پذیر باینری بر روی شبکه را می‌یابد و پس از بهره‌برداری، می‌تواند با استفاده از تکنیک شناخته شده‌ای تکمیل شود. بنابراین با نفوذ در اطلاعات یک بیت براساس اینکه آیا یک فرایند شکست خورده است یا نه، عملیات را شروع می‌کند. BROP نیاز به آسیب‌پذیری پشته و یک سرویس دارد که پس از شکست شروع به اجرا کند. در این مقاله Braille پیاده‌سازی شده است، بهره‌برداری کاملا خودکار، که کمتر از 4000 درخواست (20 دقیقه) در برابر آسیب‌پذیری در nginx، yaSSL + MySQL و سرور اختصاصی را متحمل است. حمله در لینوکس 64 بیتی با فضای آدرس‌دهی تصادفی (ASLR)، بدون محفاظت از اجرای صفحه (NX) و پشته صورت می‌گیرد. 

1. مقدمه 

           مهاجمان در سوء‌استفاده بر روی هدف،  با درجه‌ای از اطلاعات مختلف بسیار موفق عمل کرده‌اند. نرم‌افزار متن باز دردسترس است زیرا مهاجمان می‌توانند کد را برای یافتن آسیب‌پذیری پویش کنند. نرم‌افزار منبع بسته هک ممکن است برای ایجاد انگیزه در مهاجمان از طریق استفاده از تست fuzz و مهندسی معکوس به کار گرفته شود. تلاش برای درک محدودیت‌های مهاجم، این سؤال را مطرح می‌کند که: آیا مهاجمان ممکن است تلاش خود برای رسیدن به هدف و سوء استفاده از خدمات اختصاصی را نه تنها برای منبع بلکه برای کد باینری گسترش دهند؟ در نگاه اول، ممکن است چنین به نظر برسد که دست نیافتنی است زیرا سوء استفاده به داشتن یک کپی از هدف دودویی برای استفاده در برنامه‌نویسی بازگشت‌گرا (ROP) نیاز دارد [1]. ROP لازم است، زیرا در سیستم‌های مدرن، حفاظت غیراجرایی (NX) از حافظه تا حد زیادی مانع از تزریق کد حملات می‌شود. برای پاسخ به این سوال، با ساده‌ترین آسیب‌پذیری ممکن شروع می‌کنیم: پشته سرریز می‌شود. متاسفانه این مسئله هنوز هم در نرم‌افزارهای محبوب (به‌عنوان مثال، در nginx CVE-2013- 2028 [2]) قابل اعمال است. بنابراین تنها می‌توان چنین حدس زد که باگ‌ها از نرم‌افزار اختصاصی دور بماند، که در آن منبع (و دودویی) تحت بررسی عمومی و دقیق متخصصان امنیت نیست. بااین‌حال، این امکان برای یک مهاجم فراهم است که از تست fuzz برای یافتن باگ‌ها از طریق رابط‌های سرویس شناخته شده یا طراحی معکوس استفاده کند. در روش دیگر، مهاجمان می‌توانند آسیب‌پذیری‌های شناخته شده در کتابخانه‌های محبوب را (به‌عنوان مثال، SSL یا تجزیه‌کننده PNG) مورد هدف قرار دهند که ممکن است در خدمات اختصاصی مورد استفاده قرار گیرند. مهم‌ترین چالش این مسئله، توسعه‌ی یک روش برای بهره‌برداری از این آسیب‌پذیری‌ها است زمانی‌که اطلاعات در مورد هدف دودویی محدود است. 

          یکی از مزیت‌هایی که اغلب حملات دارند این است که بسیاری از سرورها فرآیندهای خود را پس از یک شکست در جهت موفقیت دوباره مجددا راه‌اندازی می‌کنند. نمونه‌های قابل توجه عبارتند از، آپاچی، وب سرور nginx، سامبا و OpenSSH. اسکریپت Wrapper مانند mysqld_safe.sh یا daemon ها مانند systemd، این قابلیت را دارند. متعادل‌کننده‌های بار به‌طور فزاینده‌ای شایع هستند و اغلب اتصالات را به تعداد زیادی از میزبان‌هابا پیکربندی‌های یکسان برای اجرای فایل‌های باینری برنامه توزیع می‌کنند. بدین ترتیب، موقعیت‌های بسیاری وجود دارد که در آن یک مهاجم به‌طور بالقوه برای ایجاد بهره‌برداری (تا تشخیص) بی‌نهایت تلاش می‌کند. 

          در این مقاله یک حمله جدید ارائه می‌کنیم، برنامه‌نویسی بازگشت‌گرا کور (BROP)، که از مزیت‌های این موارد، سوء استفاده کورکورانه از خدمات اختصاصی باینری و منابع ناشناخته است. در حمله BROP، نرم‌افزار سرور با یک آسیب‌پذیری پشته فرض می‌شود و فرآیندی که پس از خرابی دوباره راه‌اندازی می‌شود. حمله در لینوکس 64 بیتی با ASLR (فضای آدرس‌دهی تصادفی)، حافظه nonexecutable (NX) و پشته فعالیت می‌کند. با این حال تعداد زیادی از سرورها را پوشش می‌دهد که نمی‌توانیم در حال حاضر در سیستم ویندوز مورد هدف قرار دهیم چون باید حمله به ویندوز ABI منطبق شود. این حمله توسط دو تکنیک جدید فعال می‌شود: 

1) خواندن از پشته تعمیم‌یافته: این تعمیم شناخته شده برای پشته مورد استفاده قرار می‌گیرد و موجب ذخیره آدرس بازگشت به‌منظور ASLR پیش‌فرض در سیستم 64 بیتی می‌گردد، حتی زمانی که مکان اجرای مستقل (PIE) استفاده می‌شود. 

2) ROP کور: این روش ابزار ROP را از راه دور در مکان قرار می‌دهد. 

         هر دو روش، ایده‌ی استفاده از آسیب‌پذیری پشته را برای نشت اطلاعات براساس اینکه آیا یک سرور با شکست مواجه می‌شود یا نه، به اشتراک می‌گذارند. روش خواندن از پشته، بایت‌های پشته را بایت به بایت با حدس دوباره نویسی می‌کند، تا زمانی که عملیات درست یافت شود و سرور دچار شکست نشود و عملیات خواندن (با نوشتن) پشته به طور موثر انجام گیرد. حمله کورکورانه ROP ابزارهای کافی برای انجام سیستم پاسخ write را پس از انتقال باینری سرور از حافظه به سوکت مهاجم می‌یابد. در این ح، ASLR و NX شکست خورده‌اند و بهره‌برداری می‌تواند با استفاده از تکنیک‌های شناخته شده انجام گیرد. 

         حمله BROP سوء استفاده قوی برای اهداف عمومی را نوسط سه سناریو جدید انجام می‌دهد: 

1) خدمات بسته باینری و اختصاصی هک. ممکن است متوجه یک تصادف در هنگام استفاده از یک سرویس از راه دور و یا کشف از طریق آزمایش fuzz از راه دور شویم. 

2) هک یک آسیب‌پذیری در یک کتابخانه منبع باز تصور می‌شود که در یک سرویس اختصاصی باینری استفاده شود. برای مثال کتابخانه محبوب SSL ممکن است آسیب‌پذیری پشته داشته باشد و ممکن است حدس بزنیم که توسط یک سرویس اختصاصی استفاده می‌شود.

 3) هک یک سرور منبع باز برای منابع باینری ناشناخته است. این امر به صورت نصب دستی و راه‌اندازی یا توزیع‌هایی مانند Gentoo انجام می‌شود.

          هر سه سناریو را مورد ارزیابی قرار دادیم. در حالت ایده‌آل، برای سناریوی اول تکنیک‌های ما در برابر خدمات تولید که هیچ اطلاعاتی در مورد نرم‌افزار نگه نمی‌دارد مورد تست قرار گرفت، اما به دلایل قانونی محدودیت‌هایی وجود دارد. برای شبیه‌سازی یک سناریو، روش خودمان را در برابر یک سرویس اختصاصی مورد آزمون قرار دادیم که هیچ اطلاعاتی در مورد منبع آن، باینری یا عملکرد نداشتیم. برای سناریوی دوم، یک آسیب‌پذیری واقعی در کتابخانه yaSSL را هدف قرار دادیم [3]. این کتابخانه در گذشته توسط MySQL استفاده شده بود و ما آن را به‌عنوان برنامه میزبان در نظر می‌گیریم. برای سناریوی سوم، یک (2013) آسیب‌پذیری اخیر در nginx [2] را مورد هدف قرار دادیم و به‌صورت عمومی بهره بردیم که به یک فایل باینری خاص بستگی نداشت. این امر به‌ویژه در هر توزیع و نسخه آسیب‌پذیر وب سرور nginx بدون نیاز به حمله برای بهره‌برداری از هر توزیع و نسخه ترکیبی (همان‌گونه که امروزه انجام می‌شود) مفید است و به کار می‌رود. 

         در این مقاله یک ابزار امنیتی جدید، Braille، پیاده‌سازی کردیم که باعث می‌شود حملات BROP کاملا خودکار عمل کنند. Braille می‌تواند بر روی عملکرد سرور آسیب‌پذیر در حدود 4000 درخواست، یک فرایند که در کمتر از 20 دقیقه کامل می‌شود و در برخی شرایط، فقط در چند دقیقه بهترین کارآیی را داشته باشد. یک مهاجم تنها نیاز به ارائه یک تابع دارد که یک درخواست با حداقل طول برای شکست سرور ایجاد کند و یک رشته توسط Braille اضافه کند. همچنین کارکرد این روش به عملکرد یک بیت براساس اینکه آیا سرور شکست می‌خورد یا نه، بستگی دارد. 

کارهای انجام شده عبارتند از: 

1) یک روش برای شکست ASLR بر روی سرورها (خواندن عمومی از پشته).

2) روش برای یافتن از راه دور ابزارهای ROP(BROP) به‌طوری‌که نرم‌افزار، زمانی که باینری ناشناخته است مورد حمله قرار گیرد. 

3) Braille: ابزاری برای بهره‌برداری خودکار از ورودی داده شده در مورد اینکه چگونه یک پشته در سرور سرریز می‌شود. 

4) اولین بهره‌برداری عمومی (بنابه دانش ما) برای آسیب‌پذیری اخیر وب سرور nginx، در حالت عمومی، 64 بیتی و شکست ASLR (کامل / PIE) ، canaries و NX است. 

5) پیشنهادات برای دفاع در برابر حملات BROP. به‌طورخلاصه، ASLR باید به تمام بخش‌های اجرایی (PIE) اعمال شود و پس از هر شکست (در تقابل با سرورهای fork) مجددا به حالت تصادفی برگردد. حفاظت باینری در برابر مهاجم یا تغییر هدفمند ممکن است یک اقدام متقابل امنیتی موثر نباشد. 

Abstract

           We show that it is possible to write remote stack buffer overflow exploits without possessing a copy of the target binary or source code, against services that restart after a crash. This makes it possible to hack proprietary closed-binary services, or open-source servers manually compiled and installed from source where the binary remains unknown to the attacker. Traditional techniques are usually paired against a particular binary and distribution where the hacker knows the location of useful gadgets for Return Oriented Programming (ROP). Our Blind ROP (BROP) attack instead remotely finds enough ROP gadgets to perform a write system call and transfers the vulnerable binary over the network, after which an exploit can be completed using known techniques. This is accomplished by leaking a single bit of information based on whether a process crashed or not when given a particular input string. BROP requires a stack vulnerability and a service that restarts after a crash. We implemented Braille, a fully automated exploit that yielded a shell in under 4,000 requests (20 minutes) against a contemporary nginx vulnerability, yaSSL + MySQL, and a toy proprietary server written by a colleague. The attack works against modern 64-bit Linux with address space layout randomization (ASLR), no-execute page protection (NX) and stack canaries.

I. INTRODUCTION

          Attackers have been highly successful in building exploits with varying degrees of information on the target. Open-source software is most within reach since attackers can audit the code to find vulnerabilities. Hacking closed-source software is also possible for more motivated attackers through the use of fuzz testing and reverse engineering. In an effort to understand an attacker’s limits, we pose the following question: is it possible for attackers to extend their reach and create exploits for proprietary services when neither the source nor binary code is available? At first sight this goal may seem unattainable because today’s exploits rely on having a copy of the target binary for use in Return Oriented Programming (ROP) [1]. ROP is necessary because, on modern systems, non-executable (NX) memory protection has largely prevented code injection attacks.

          To answer this question we start with the simplest possible vulnerability: stack buffer overflows. Unfortunately these are still present today in popular software (e.g., nginx CVE-2013- 2028 [2]). One can only speculate that bugs such as these go unnoticed in proprietary software, where the source (and binary) has not been under the heavy scrutiny of the public and security specialists. However, it is certainly possible for an attacker to use fuzz testing to find potential bugs through known or reverse engineered service interfaces. Alternatively, attackers can target known vulnerabilities in popular opensource libraries (e.g., SSL or a PNG parser) that may be used by proprietary services. The challenge is developing a methodology for exploiting these vulnerabilities when information about the target binary is limited.

          One advantage attackers often have is that many servers restart their worker processes after a crash for robustness. Notable examples include Apache, nginx, Samba and OpenSSH. Wrapper scripts like mysqld_safe.sh or daemons like systemd provide this functionality even if it is not baked into the application. Load balancers are also increasingly common and often distribute connections to large numbers of identically configured hosts executing identical program binaries. Thus, there are many situations where an attacker has potentially infinite tries (until detected) to build an exploit.

          We present a new attack, Blind Return Oriented Programming (BROP), that takes advantage of these situations to build exploits for proprietary services for which both the binary and source are unknown. The BROP attack assumes a server application with a stack vulnerability and one that is restarted after a crash. The attack works against modern 64-bit Linux with ASLR (Address Space Layout Randomization), nonexecutable (NX) memory, and stack canaries enabled. While this covers a large number of servers, we can not currently target Windows systems because we have yet to adapt the attack to the Windows ABI. The attack is enabled by two new techniques:

1) Generalized stack reading: this generalizes a known technique, used to leak canaries, to also leak saved return addresses in order to defeat ASLR on 64-bit even when Position Independent Executables (PIE) are used.

2) Blind ROP: this technique remotely locates ROP gadgets.

         Both techniques share the idea of using a single stack vulnerability to leak information based on whether a server process crashes or not. The stack reading technique overwrites the stack byte-by-byte with possible guess values, until the correct one is found and the server does not crash, effectively reading (by overwriting) the stack. The Blind ROP attack remotely finds enough gadgets to perform the write system call, after which the server’s binary can be transferred from memory to the attacker’s socket. At this point, canaries, ASLR and NX have been defeated and the exploit can proceed using known techniques.

         The BROP attack enables robust, general-purpose exploits for three new scenarios:

1) Hacking proprietary closed-binary services. One may notice a crash when using a remote service or discover one through remote fuzz testing.

2) Hacking a vulnerability in an open-source library thought to be used in a proprietary closed-binary service. A popular SSL library for example may have a stack vulnerability and one may speculate that it is being used by a proprietary service.

3) Hacking an open-source server for which the binary is unknown. This applies to manually compiled installations or source-based distributions such as Gentoo.

         We evaluate all three scenarios. Ideally, for the first scenario we would test our techniques against production services for which we hold no information about the software, but we are constrained for obvious legal reasons. To simulate such a scenario, we tested against a toy proprietary service a colleague of ours wrote for which we had no information about source, binary, or functionality. For the second scenario, we target a real vulnerability in the yaSSL library [3]. This library was used by MySQL in past and we use that as the host application. For the third scenario, we target a recent (2013) vulnerability in nginx [2] and write a generic exploit that does not depend on a particular binary. This is particularly useful as the exploit will work on any distribution and vulnerable nginx version without requiring an attacker to write a specific exploit for each distribution and version combination (as is done today).

          We implemented a new security tool, Braille, that makes BROP attacks highly automated. Braille can yield a shell on a vulnerable server in approximately 4,000 requests, a process that completes in under 20 minutes and, in some situations, in just a few minutes. An attacker need only provide a function that constructs a request of a minimum length to crash the server and append a string provided by Braille. The function must also return a single bit based on whether the server crashes or not.

Our contributions are:

1) A technique to defeat ASLR on servers (generalized stack reading).

2) A technique to remotely find ROP gadgets (BROP) so that software can be attacked when the binary is unknown.

3) Braille: a tool that automatically constructs an exploit given input on how to trigger a stack overflow on a server.

4) The first (to our knowledge) public exploit for nginx’s recent vulnerability, that is generic, 64-bit, and defeats (full/PIE) ASLR, canaries and NX.

5) Suggestions for defending against BROP attacks. In summary, ASLR must be applied to all executable segments (PIE) and re-randomization must occur after each crash (at odds with fork-only servers). Holding the binary from the attacker or purposefully altering it may not be an effective security countermeasure.

چکیده

1. مقدمه

2. تاریخچه مختصری از سرریزهای بافر

3. آموزش ROP 

4. سرریزهای بافر 

5. محیط BROP 

6. طرح کلی حمله 

7. خواندن از پشته: تصادفی‌سازی مجدد ASLR 

8. حمله BROP 

A. قطعاتی از پازل 

B. پیدا کردن ابزار و توقف ابزار 

C. شناسایی ابزارها

D. پیدا کردن جدول روش لینک کردن 

E. کنترل RDX از طریق strcmp 

F. پیدا کردن نوشتن 

 G. مرحله پایانی حمله 

H. خلاصه حمله 

I. اصول اولیه حمله 

J. دیگر جزئیات سطح پایین 

9. پیاده‌سازی 

10. ارزیابی

.A  عملکرد 

B. ثبات 

C. کمک سورس کد 

11. محدودیت ها 

12. بحث

A. BROP در سیستم عامل‌های مختلف 

B. BROP فراتر از سرریز پشته 

C. سمت سرویس گیرنده در مقابل سمت سرور 

D. واریانس در فایل‌های باینری 

E. تست fuzz از راه دور 

13. پیشگیری BROP 

A. تصادفی‌سازی

B. خواب در شکست 

C. حفاظت  ROP

D. تکنیک‌های کامپایلر 

14.  کارهای مرتبط 

15. نتیجه‌گیری 

منابع

Abstract

1. INTRODUCTION

2. BRIEF HISTORY OF BUFFER OVERFLOWS

3. ROP TUTORIAL

4. BUFFER OVERFLOWS TODAY

5. BROP ENVIRONMENT

6. ATTACK OUTLINE

7. STACK READING: ASLR DE-RANDOMIZATION

8. BROP ATTACK

A. The pieces of the puzzle

B. Finding gadgets and the stop gadget

C. Identifying gadgets

D. Finding the Procedure Linking Table

E. Controlling rdx via strcmp

F. Finding write

G. Concluding the attack

H. Attack summary

I. First principles attack

J. Other low-level details

9. IMPLEMENTATION

10. EVALUATION

A. Performance

B. Stability

C. Source-code aid

11. LIMITATIONS

12. DISCUSSION

A. BROP in different OSes

B. BROP beyond stack overflows

C. Client-side vs. server-side

D. Variance in binaries

E. Remote fuzz testing

13. BROP PREVENTION

A. Rerandomization

B. Sleep on crash

C. ROP protections

D. Compiler Techniques

14. RELATED WORK

15. CONCLUSION

REFERENCES