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

امنیت JWT بخش دوم: حملات شناخته شده JWT

JSON Web Token (JWT) یک راهکار امن و فشرده به منظور انتقال اطلاعات در قالب JSON Object تعریف می‌نماید. قبل از شروع  معرفی حملات شناخته شده در JWT باید این نکته را در نظر داشت که این حملات عموما وابسته به نوع پیاده سازی JWT بوده و ارتباطی به ساختار اصلی آن ندارند. در این متن، به معرفی دو نمونه از رایجترین حملات JWTها پرداخته خواهد شد.

۱ حملات شناخته شده JWT

قبل از شروع  معرفی حملات شناخته شده در JWT باید این نکته را در نظر داشت که این حملات عموما وابسته به نوع پیاده سازی JWT بوده و ارتباطی به ساختار اصلی آن ندارند. برای درک بهتر این حملات  باید یک دید کلی راجع به JWS (json web signatures) یا همان امضاهای دیجیتال استفاده شده در این مکانیزم داشته باشیم.

هدف اصلی JWS کسب اطمینان از صحت اطلاعات ارسالی در یک فرمت Serializable و قابل درک برای سیستم‌های رایانه‌ای می‌باشد. منظور از صحت اطلاعات‌، عدم تغییر داده‌های ارسالی بعد از امضاء دیجیتال می‌باشد.

همانطور که در بخش اول (مقدمه‌ای بر JWT) ذکر گردید، یک توکن JWT دارای دو بخش اصلی Header و Payload می‌باشد که با استفاده از الگوریتم Base64 کدگذاری شده و با کاراکتر (.) به هم الحاق می‌شوند.

  • بخش Header حاوی اطلاعاتی مربوط به خود JWT از قبیل نوع امضاء و الگوریتم می‌باشد.
  • بخش Payload شامل تمامی اطلاعات مربوط به توکن از قبیل sub، iat و یا هر Claim دیگر می‌باشد.

به عنوان نمونه؛

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.XbPfbIHMI6arZ3Y922BhjWgQzWXcXNrz0ogtVhfEd2

۱-۱  حمله “alg: none”

همانطور که پیش اشاره کردیم ، JWT ها دارای دو شی JSON با اطلاعات مهم، به نام‌های Header و Payload می‌باشند. در JWTهای امضا شده، هر دو بخش header و payload می‌گردد. اما در JWTهای رمز شده، تنها بخش Payload رمز شده و بخش Header بایستی به صورت متن واضح باقی بماند.

در توکن‌های امضا شده، علیرغم اینکه بخش امضا از دستکاری بخش‌های Header و Payload محافظت به عمل می‌آورد، اما امکان بازنویسی این بخش‌ها بدون نیاز به امضا و همچنین اعمال تغییرات در محتوای آن وجود دارد.

برای مثال به نمونه JWT زیر قبل از Serialize شدن توجه کنید:

header: {
  alg: “HS256”,
  typ: “JWT”
},
payload: {
  sub: “joe”
  role: “user”
}

فرض کنید پس از افزودن بخش امضا (با استفاده یک کلید Secret) و کدگذاری Base64 بخش‌های مختلف، رشته JWT به صورت زیر خواهد بود.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJqb2UiLCJyb2xlIjoidXNlciJ9.vqf3WzGLAxHW-X7UP-co3bU_lSUdVjF2MKtLtSU1kzU

حال، از آنجایی که این یک توکن امضا شده است، می‌توانیم آن را خوانده و همچنین یک توکن مشابه با آن (با تغییرات مورد نظر در دادهای آن) ایجاد نماییم. شایان ذکر است تا زمانی که کلید امضا (Secret) را نداشته باشیم، نمی‌توانیم آن را امضا نماییم. سوال اینست که مهاجمین علیرغم نداشتن کلید Secret، چگونه می‌توانند توکن را دستکاری نمایند.

پاسخ ساده است. مهاجمان می‌توانند از توکن بدون امضا استفاده کنند!

مثال :

header: {
  alg: “none”,
  typ: “JWT”
},
payload: {
  sub: “joe”
  role: “admin”
}

که مقدار Serialize شده آن به صورت زیر خواهد بود.

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJqb2UiLCJyb2xlIjoiYWRtaW4ifQ.

در مثال فوق، بخش Signature یا امضاء توکن به صورت کامل حذف شده است و  مقدار “alg”  به “none”  و همچنین مقدار “role” از “user” به “admin”  تغییر داده شده است. حال در صورت آسیب پذیر بودنJWT، فرد مهاجم قادر است به عنوان یک مدیر (با دسترسی بیشتر) به سامانه وارد شود. در ادامه توضیح خواهیم داد که دلیل امکان پذیر بودن این حمله چه چیزی می‌تواند باشد.

بدین منظور بایستی نگاهی به چگونگی کارکرد برخی از کتابخانه های فرضی JWT بیندازیم. فرض کنید یک تابع رمزگشایی همانند ذیل را داریم.

function jwtDecode(token, secretOrPublicKey) {
  // (...)
}

بدین صورت که این تابع، یک توکن رمزگذاری شده به همراه کلید Secret را دریافت نموده و پس از تایید توکن، محتوای رمزگشایی شده آن را باز می‌گرداند. همچنین در زمانی که توکن تایید نشود، یک خطا نمایش می‌دهد. حال در صورتی که این تابع برای انتخاب الگوریتم مناسب برای تایید توکن، از پارامتر “alg” در بخش Header استفاده نماید، باعث به وجود آمدن آسیب‌پذیری ذکر شده می‌گردد. زمانی که فرد مهاجم مقدار پارامتر را با “None” جایگزین می‌کند، در واقع بدین معنی است که هیچ الگوریتمی برای صحت‌سنجی توکن وجود ندارد. در نتیجه تابع از مرحله تایید گذشته و فرد مهاجم به راحتی به عنوان “admin” وارد سامانه می‌شود.

همانطور که مشاهده می کنید ، این یک نمونه کلاسیک از حملات JWT  است که به ابهام خاصی از API یک کتابخانه خاص متکی است، و نه یک آسیب‌پذیری در خود JWT.  با این حال، این یک حمله واقعی است که در چندین اجرای مختلف در گذشته امکان پذیر بود. از اینرو، امروزه بسیاری از کتابخانه ها، مقدار “none” را برای پارامتر “alg” نامعتبر قلمداد می‌نمایند.

مهمترین روش جلوگیری از اینگونه حملات این است که همیشه قبل از صحت‌سنجی توکن، الگوریتم مشخص شده در Header اعتبارسنجی گردد. روش دیگر ارسال نوع الگوریتم مورد استفاده به عنوان یک پارامتر به تابع jwtDecode می‌باشد.

۱-۲ کلید های HMAC ضعیف

الگوریتم‌های “HMAC” به منظور تولید و اعتبارسنجی امضاها، به یک کلید مشترک متکی می‌باشند. کلیدهای مشترک مشابه کلمات عبور می‌باشند. این کلیدها بایستی دارای طول نسبتا زیادی بوده تا در مقابل حملات Brute force مقاوم باشند. از سوی دیگر، تعداد کاراکترهای خیلی زیاد کلید Secret می‌تواند سرعت پردازش‌های انجام شده را تحت تاثیر قرار دهد. از اینرو بایستی طول کلید به وصرت معقول و منطقی انتخاب شود. در واقع، طول کلید از نظر تعداد بیت حداقل بایستی هم اندازه تعداد بیت‌های خروجی تابع درهم‌سازی باشد (برای مثال ۲۵۶ بیت در الگوریتم “HS256”). به عبارت دیگر، بسیاری از کلمه‌های عبور که می‌توانند در هرجایی استفاده شوند، برای کلیدهای مشترک در JWTهای امضا شده توسط HMAC مناسب نیستند.

گزینه خوب دیگر، استفاده از الگوریتم “RS256” یا الگوریتم‌های Public-Key دیگر است که بسیار مقاوم و انعطاف پذیر می‌باشند. شایان ذکر است که این فقط یک حمله فرضی نیست. به عبارت دیگر، در صورتیکه طول کلید Secret کوتاه باشد، حملات “Brute Force” برای “HS256” به اندازه کافی ساده می‌باشد.

تدوین: امیر حسین بابایی

امنیت JWT بخش اول: مقدمه ای بر JWT

JSON Web Token (JWT) یک راهکار امن و فشرده به منظور انتقال اطلاعات در قالب JSON Object تعریف می‌نماید. به دلیل استفاده از امضای دیجیتال در این روش، صحت  اطلاعات مذکور قابل تایید می‌باشد.

۱ JWT چیست؟

JSON Web Token (JWT) یک استاندارد باز (RFC 7519) می‌باشد که یک راهکار امن و فشرده به منظور انتقال اطلاعات در قالب JSON Object تعریف می‌نماید. به دلیل استفاده از امضای دیجیتال در این روش، صحت[۱] اطلاعات مذکور قابل تایید می‌باشد. JWT می‌تواند توسط یک کلید (الگوریتم HMAC) یا جفت کلید عمومی/خصوصی (الگوریتم‌های RSA یا ECDSA) امضا شود. همچنین به منظور تضمین محرمانگی اطلاعات انتقالی مابین طرفین ، امکان رمزنگاری JWT وجود دارد.

۲ موارد استفاده JWT

نمونه‌هایی از سناریوهای استفاده JWT به شرح ذیل می‌باشد.

مجازشماری[۲]: عمده استفاده از JWT در امر مجازشماری می‌باشد. بدین صورت که پس از ورود کاربر به سامانه، اعتبارسنجی مقدار JWT موجود در هر درخواست کاربر، مجاز بودن آن کاربری جهت دسترسی به سرویس‌ها و منابع سامانه را مشخص خواهد کرد. با توجه به سربار کم و سهولت استفاده، امروزه JWT به صورت گسترده در مکانیزم‌های Single Sign On مورد استفاده قرار می‌گیرد.

تبادل اطلاعات: JSON Web Tokenها یکی از امن‌ترین روش‌ها به منظور تبادل اطلاعات بین طرفین می‌باشد. با توجه به اینکه اطلاعات مذکور در JWT، دارای امضای دیجیتال می‌باشند، می‌توان از هویت فرد ارسال کننده اطمینان حاصل نمود. همچنین می‌توان اطمینان یافت که اطلاعات دریافتی در بین راه دستکاری نشده است.

۳ ساختار JWT

JWT دارای ۳ بخش اصلی می‌باشد که توسط کاراکتر ( . ) از یکدیگر جدا می‌شوند. هر یک از این بخش‌ها بصورت Base64 کدگذاری می‌شوند.

•  Header

•  Payload

•   Signature

برای مثال : xxxx.zzzz.yyyy  

Header: از دو قسمت اصلی alg و typ تشکیل می‌شود، که بخش alg الگوریتم استفاده شده برای امضا (به عنوان مثال HMAC SHA256 یا RSA) را تعیین نموده و بخش typ نوع token را مشخص می‎کند که همواره مقدار آن برابر JWT می‌باشد. برای مثال :

{
    "alg": "HS256",
    "typ": "JWT"
 } 

Payload: دومین بخش توکن شامل Claimها یا در واقع تمامی داده‌ها و اطلاعات ارسالی می‌باشد. معمولا در بخش Claim اطلاعات کاربری که باید تصدیق هویت شود قرار می‌گیرد.

{
	"sub": "1234567890",
	"name": "John Doe",
	"admin": true
}

Signature: برای ایجاد بخش Singnature بایستی تمامی بخش‌های توکن به صورت base64 کدگذاری شوند. سپس با مشخص بودن الگوریتم امضا و کلید، می‌توان امضای دیجیتال را محاسبه نمود. برای مثال جهت ایجاد یک امضا با الگوریتم HMACSHA256 می‌توان به صورت زیر اقدام نمود.

HMACSHA256(
	base64UrlEncode(header) + "." +
	base64UrlEncode(payload),
	secret)

نهایتا پس از الحاق بخش‌های فوق، خروجی به صورت زیر خواهد بود.

۴ JWT چگونه کار می‌کند؟

پس از انجام فرآیند احراز هویت، زمانی که کاربر قصد دسترسی به یک سرویس یا منبع محافظت شده را دارد، مقدار JWT در درخواست HTTP (معمولا در یک سرآیند با نام Authorization) ارسال می‌شود.

حال پس از دریافت این سرآیند توسط سرور، مقدار مذکور بایستی اعتبارسنجی شده و در صورتیکه توکن مورد تایید باشد، کاربر می‌تواند به بخش مورد نظر دسترسی یابد.

از نکات مثبت استفاده از JWT می‌توان به موارد ذیل اشاره نمود.

  • در مواقعی که JWT حاوی داده‌های اطلاعاتی مورد نیاز باشد، می‌تواند منجر به کاهش تعداد پرس‌وجوها از پایگاه‌داده گردد.
  • در صورتیکه JWT به جای Cookie از طریق سرآیند Authorization ارسال شود، دیگر آسیب‌پذیری CORS (Cross Origin Resource Sharing) مطرح نمی‌باشد.

نحوه دریافت اجازه دسترسی با استفاده از JWT در تصویر ذیل نشان داده شده است.

مرحله اول: کاربر درخواستی را به سرور Authorization به منظور دسترسی به منابع ارسال می‌نماید.

مرحله دوم: زمانی که درخواست کاربر تایید و اجازه دسترسی صادر شد، سرور Authorization توکن دسترسی را به کاربر ارسال می‌کند.

مرحله سوم: کاربر از این توکن برای دسترسی به منابع محافظت شده استفاده می‌نماید.

بایستی توجه گردد که در این توکن‌ها می‌تواند اطلاعات مهمی از قبیل کد ملی، نام کاربری، شماره موبایل و غیره ارسال شود که در صورت عدم رمزنگاری، این اطلاعات برای کاربران قابل مشاهده می‌باشد. علیرغم اینکه کاربران قادر به تغییر این اطلاعات نیستند، با این وجود بایستی از درج اطلاعات محرمانه در JWT پرهیز شود.

تدوین: امیر حسین بابایی


[۱] Interity

[۲] Authorization

امنیت ActuatorهایSpring Boot

Spring Boot Framework شامل تعدادی از ویژگی ها به نام Actuator است که به منظور پایش و مدیریت برنامه‌های کاربردی تحت وب در محیط عملیاتی مورد استفاده قرار می‌‎گیرد که در صورت عدم پیکربندی امن می‌توانند یک در مخفی به روی سرور باز نمایند.

هنگامی که برنامه Spring Boot در حال اجرا است، به طور خودکار Endpointهای مختلفی از جمله/health ، /trace ، /shutdown ، /env  و غیره را در مسیریابی خود ثبت می کند. این Endpointها اطلاعات حساسی را در خصوص برنامه کاربردی افشا می‌نمایند. به عنوان مثال:

  • heapdump/  – می‌توان به اطلاعات حافظه وب سرور دسترسی داشت و همچنین آن را دانلود نمود.
  • trace/  – آخرین پیغام‌های HTTP مربوط به برنامه وب را نشان می‌دهد که می‌تواند شامل شناسه‌های نشست باشد.
  • logfile/  – محتویات فایل های مربوط به لاگ را نمایش می‌دهد.
  • env/  – دسترسی به محیط پیکربندی برنامه وب را فراهم می‌کند.
  • shutdown/  – برنامه وب را از دسترس خارج می‌نماید.
  •  -restart/ برنامه وب را restart می‌کند.

در Spring Boot (نسخه ۱ تا ۱٫۴)، تمامی Endpointها بدون احراز هویت در دسترس می‌باشند که می‌تواند باعث ایجاد مشکلات قابل توجهی در امنیت برنامه کاربردی تحت وب می‌شود.  از نسخه ۱٫۵ به بعد، به صورت پیش فرض کلیه Endpointها (به غیر از health/  و info/) محافظت شده و در دسترس نمی‌باشند. اما این پیکربندی اغلب توسط توسعه دهندگان غیرفعال می‌شود.

نمونه‌هایی از موارد سوءاستفاده از آسیب‌پذیری‌ها

اجرای کدهای مخرب راه دور(RCE) با استفاده از jolokia/: در صورتیکه کتابخانه jolokia در برنامه کاربردی مورد استفاده قرار گرفته باشد، توسط Spring Boot به طور خودکار در jolokia/ در دسترس قرار می‌گیرد. حال در صورت عدم پیکربندی مناسب امنیتی، مهاجم قادر به اجرای کدهای مخرب از راه دور خواهد گردید.

تغییرات در پیکربندی برنامه وب با استفاده از env/: در صورتیکه مهاجم امکان ارسال درخواست POST بر روی env/ را داشته باشد، می‌تواند تغییراتی را در پیکربندی موجود Spring Boot Framework به وجود آورد. همچنین با استفاده از این آسیب پذیری مهاجم قادر به اجرای دستورات از قبیل insert، update و delete بر روی پایگاه داده می‌باشد. به عنوان نمونه، در شکل ذیل مهاجم موفق به حذف جدول users از پایگاه داده شده است.

دسترسی به اطلاعات حافظه ی وب سرور: Endpoint دیگری که می‌تواند منجر به نشت اطلاعات حساس گردد، heapdump/ می‌باشد که در صورت دسترسی مهاجم به این Endpoint، به تمامی اطلاعات موجود در حافظه دسترسی خواهد داشت.

دسترسی مهاجم به برنامه‌های کاربردی آسیب‌پذیر

بررسی‌ها نشان می‌دهد که در زمان نگارش این متن بیش از ۱۰۰ برنامه کاربردی تحت وب مبتنی بر Spring Boot در Shodan (مربوط به کشور ایران)، ثبت شده است که مهاجم با بررسی این موارد می‌تواند به اطلاعات حساس برنامه کاربردی دسترسی داشته و تحت شرایطی موفق به اجرای کد راه دور بر روی سرور شود.

راهکارهای رفع آسیب‌پذیری

به منظور پیکربندی امن Spring Boot توصیه می‌شود تمامی EndPointهای حساس غیرفعال گردند. همان طور که در بخش‌های قبلی ذکر شد در نسخه‌های جدید Spring Boot (نسخه ۱٫۵ به بعد)، تمامی Endpointها به جز health/ و info/ حساس تلقی شده و به طور پیش فرض این موارد غیرفعال می‌باشند.

در صورت نیاز به فعال‌سازی تمامی یا برخی از Endpointهای موجود، بایستی احراز هویت (با استفاده از کلمه عبور) بر روی این موارد فعال گردد.

بدین منظور، باید موارد ذیل به Spring Security اضافه شوند.

شایان ذکر است که پیکربندی خودکار Spring Boot به طور خودکار تمام اجزای مربوط به امنیت را مقدار دهی می‌نماید. از اینرو، تنها بایستی یک حساب کاربری تعریف گردد که به صورت ذیل قابل انجام است.

در نتیجه پیکربندی صحیح، بایستی Endpointها بدون احراز هویت در دسترس نبوده و خطای ۴۰۱ Unauthorized در پاسخ دریافت شود.

گردآوری: امین اسفندیاری

منابع:

https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

https://www.amitph.com/how-to-secure-spring-boot-actuator-endpoints/

https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html

شناسایی حساب کاربری Backdoor مخفی در برخی تجهیزات فایروال و AP Controllerهای زایکسل

اخیرا آسیب­ پذیری با شناسه CVE-2020-29583 (با امتیاز CVSS-7.8) بر روی تجهیزات Firewall و AP Controllerهای زایکسل منتشر گردیده که نشان می­دهد میان­افزار نسخه ۴٫۶۰ برخی از این تجهیزات، حاوی یک حساب کاربری غیر مستند (zyfwp) و به صورت هاردکد شده با رمز عبور غیرقابل تغییر می­باشد. رمز عبور این حساب کاربری را می­توان به صورت متن­واضح در میان افزار شناسایی نمود. از این حساب کاربری می­توان برای ورود به ssh server یا واسط وبی با سطح دسترسی Admin و به مخاطره انداختن تجهیزات شبکه استفاده نمود. این آسیب­پذیری، طیف وسیعی از تجهیزات زایکسل از قبیل USG(Unifi Security Gateway)، USG Flex، ATP و محصولات VPN Firewall را تحت تاثیر قرار می­دهد. زایکسل، وصله امنیتی برای رفع این آسیب­پذیری حیاتی بر روی تجهیزات Firewall را در دسامبر ۲۰۲۰ تحت عنوان ZLD V4.60 Patch1 منتشر نموده است. همچنین اعلام نموده که وصله امنیتی مربوط به AP Controllerها در آوریل ۲۰۲۱ منتشر خواهد شد. براساس توصیه­نامه منتشر شده توسط زایکسل، حساب کاربری غیرمستند (zyfwp) دارای رمز عبور غیرقابل تغییر “PrOw!aN_fXp” می­باشد. از آنجایی که کاربر zyfwp از سطح دسترسی Admin برخوردار است لذا این آسیب ­پذیری، یک آسیب­پذیری حیاتی می­باشد که با استفاده از آن مهاجم قادر است به طور جدی محرمانگی، یکپارچگی و دردسترس بودن تجهیزات را به مخاطره بیاندازد. به عنوان مثال، مهاجم با سوء­استفاده از این آسیب­ پذیری قادر است تنظیمات فایروال را تغییر دهد تا ترافیک خاصی را مجاز یا مسدود کند. همچنین می­تواند ترافیک را شنود نماید یا حساب های VPN برای دسترسی به شبکه موجود در پشت دستگاه ایجاد کند. ترکیب این آسیب­پذیری با آسیب‌پذیری دیگری مانند Zerologon، می تواند برای مشاغل کوچک و متوسط مخرب باشد. اکیدا توصیه می­گردد که به منظور کاهش میزان مخاطره مرتبط با این آسیب­پذیری، مدیران (Administrators) و کاربران نسبت به نصب به ­روزرسانی­ های ضروری میان افزار اقدام نمایند.