#Input_Function Vulnerability Documents
برخی عزیزان باور غلطی دارند مبنی بر اینکه زبان پایتون دارای باگ و آسیب پذیری در توابع جامع خود نیست و اگر شخصی مدعی این مسئله بشود او بیسواد است, برای پاسخ به این ادعا میبایست نگاهی به دامنه زیر از وبسایت پایتون انداخت که بیش از ۴۰ هزار باگ و برخی آسیب پذیری ها را در توابع مختلف زبان پایتون ثبت کرده است,

https://bugs.python.org

اما مستندات مربوط به آسیب پذیر تلقی شدن تابع ()input در زبان پایتون ۲ و به سبب اون حذف شدنش از پایتون ۳ و جایگزینی تابع ()raw_input بجای تابع ()input ,در کجاست؟ وبسایت معروف و معتبر geeksforgeeks که در تصویر بالایی اشاره داره به همین موضوع گواه ادعا محقق مربوطه هستش که بهش اشاره شده,وبسایت geeksforgeeks مقاله ای کامل در این خصوص زده و تشریح کرده

https://www.geeksforgeeks.org/vulnerability-input-function-python-2-x/

با صراحت تمام کلمه Vulnerability رو برای تابع ()input پایتون ۲ استفاده شده, همچنین در وبسایت های برنامه نویسان دیگر هم این گزارش آمده.

https://help.semmle.com/wiki/display/PYTHON/%27input%27+function+used

@Unk9vvN

#brk & #sbrk #Memory_Management #System_Calls #Unix
شاید تا به حال در خصوص توابع زبان سی و سی پلاس پلاس که در خصوص رزرو حافظه #Heap استفاده میشوند رو شنیده باشید, اما توابع سیستمی که Data Segment هارو مدیریت میکنند چطور؟

حافظه پویا همواره نیازمند اینه که تغییر سایز بده و اشاره گر های اون آزاد و رزور بشه, به همین منظور میبایست در یک Segment که مختص حافظه #Heap هستش آدرس دهی ها بست و گُسست پیدا کنند, از همین روی تابع ()brk و ()sbrk مامور تعیین آدرس ابتدا و انتهای حافظه Heap رو دارا هستند,

در تصویر پست یک کد سی بیس میبینید که با استفاده از یک حلقه for اقدام به رزرو حافظه #Heap پرداخته و دوباره با یک حلقه for دیگری حافظه رزوی رو آزاد کرده و دوباره اقدام به رزرو حافظه میکنه,

تنیجه در تصویر بعدی بسیار جالبه آدرس های اولین رزرو با دومین رزرو یکی بوده و بازه آدرس Data Segment هم مشخص هستش, ناگفته نمونه که تابع ()brk بصورت پیشفرض با طول آدرس 1000 تایی هر Segment رو میسازه...

https://en.wikipedia.org/wiki/Sbrk
https://man7.org/linux/man-pages/man2/brk.2.html
@Unk9vvN

#JIT_Engine Exploitation
بعد از تجربه موفق اکسپلویت کردن آسیب پذیری های موتورهای تفسیری زبان JavaScript و VBScript و PHP بر روی مرورگرها و موتور تفسیری ZendEngine مربوط به زبان PHP , آیا میتونیم در آینده شاهد اکسپلویت شدن موتوهای تفسیری #JIT_Base زبان های دیگر هم باشیم؟

آیا دنیا قراره به این سمت هم بره؟ که مثلا از کامپایلرهای Intermediate (CLR) در زبان های NET. و مثلا Dalvik Virtual Machine اندروید کشف آسیب پذیری های مربوط به حافظه بشه ؟

در پروژه کشف آسیب پذیری از توابعی مانند Unserialize در زبان PHP ما شاهد اکسپلویت شدنش بر پایه آسیب پذیری هایی مانند Use_After_Free بودیم,

همینطور اکسپلویت شدن Engine های تفسیری V8 مربوط به زبان VB , پس میشه اینطور برداشت کرد که مفسر های دیگه هم دارای آسیب پذیری های حافظه باشند,

https://github.com/80vul/phpcodz
https://halbecaf.com/2017/05/24/exploiting-a-v8-oob-write/

در آینده منتظر اکسپلویت شدن #DVM با طراحی Bytecode بیس یک اپ اندرویدی apk باشید, همینطور از خانواده NET. ...

@Unk9vvN

#Software Assurance Maturity Model
به تازگی #OWASP از یک پروژه ای با نام #SAMM رو نمایی کرده که استراتژی اندازه گیری وضعیت امنیتی نرم افزارها برای سازمان هارو مشخص میکنه,

این استراتژی بر مبنای یک نقشه راه ترسیم میشه که از مرحله ارزیابی , طراحی , توسعه و استقرار نرم افزار آغاز شده و به آموزش طراحی امن برنامه و شبیه سازی حملات سایبری خواهد رسید,

که در شبیه سازی سایبری پیکربندی هایی در خصوص برهم زدن پارامترهای موفق یک حمله تاکید خواهد نمود و نهایتا بعد از مرحله Secure Coding یک پروسه Review بصورت WhiteBox انجام داده و نهایتا انجام عملیات Penetration Testing پیاده خواهد شد,

در اصل پروژه #SAMM تاکید به پیاده سازی سیاست های استاندارد و اصولی در بحث امن سازی یک نرم افزار متمرکز میشویم...

https://github.com/OWASP/samm
https://owasp.org/www-project-samm/
@Unk9vvN

#Automated Threats WebApps ( Account Aggregation )
اگر به Handbook مجموعه OWASP نگاهی بیندازید بیست و یک مرحله در خصوص الزامات تکنیکی در بحث ساخت شکارجی آسیب پذیری که بصورت اتوماتیک کار میکنند صحبت کرده,

من یک نمونه از این تکنیک هارو در تصویر پست بر پایه یک اسکریپت بش پیاده سازی کردم, که بصورت اتوماتیک Request مربوط به Authentication صفحه Login پلتفرم آزمایشی #DVWA زده و بعد از لاگین شدن مقدار Autorize شده در SESSION رو در فایلی با نام unk9.vvn ذخیره کرده و با استفاده از awk مقدار SESSION برای ماژول متاسپلویت متغیر میشه,

البته توجه داشته باشید که صفحه لاگین DVWA مجهز به مکانیزم Double Submit Cookie (که یک نوع Mitigation در برابر درخواست های جعلی است) هستش, در نتیجه یک Request هم با Curl برای دریافت کد Nonce زده و مقدار اون رو هم برای Request مربوط به Login استفاده خواهیم کرد,

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

https://owasp.org/www-project-automated-threats-to-web-applications/
@Unk9vvN

#SMBGhost Analysis (CVE-2020-0796)
اینبار بر روی الگوریتم Compression نسخه 3.1.1 آسیب پذیری ای بروز داده که از نوع Integer Overflow هستش, این آسیب پذیری بر روی نسخه های 1903 و 1909 ویندوز 10 قابلیت اکسپلویت کردن داره و بصورت unauthenticated عمل میکنه,

آسیب پذیری در درایور srv2.sys قرار داره و اگر به تصویر 1 نگاهی کنید ما در پروتکل دو پارامتر با نام های OriginalCompressedSegmentSize و Offset/Length داریم که گزینه اول برای اعلام طول سگمنت کمپرس شده هستش و دومی اندازه داده های فشرده نشده رو نشان میده, هر دو این پارامترها 32bit بوده و تحت کنترل یک هکر میتونه قرار بگیره,

حالا اگر به تصویر 2 نگاه کنید سمت چپ کد Reverse شده تابع مربوطه رو میبینید که قسمت آسیب پذیر مشخص شده, همونطور که میدونید DataType های از نوع integer که بصورت unsigned هستند بازه مثبت 65,535 بایت داده عددی دریافت میکنند, خب آسیب پذیری اونجایست که تابع SrvNetAllocateBuffer که یک اشاره گر به قسمتی از حافظه هستش مقادیر ورودیش کنترل نشده و موجب ورود داده عددی بالای مقدار تعیین شده ی DataType بوده و موجب سر ریز عددی خواهد شد..

@Unk9vvN