دوره پدافند سایبری
خواهشمند است از لینک زیر فایل های مربوطه را دانلود نمایید.
رمز فایل توسط سازمان، اطلاع رسانی می گردد.
در خصوص آزمون دوره، فراگیران محترم می توانند از طریق لینک زیر اقدام نمایند.
مدیریت ریسک امنیت اطلاعات
مدیریت ریسک اگر به‌درستی در سازمان صورت پذیرد، میتواند با کنترل وقایع آینده، از خطرات احتمالی پیش‌گیری نماید و موجب صرفه‌جویی در هزینه و محافظت از آینده و اعتبار سازمان گردد.
به بیانی دیگر، مدیریت ریسک آنچه را قابل رخ دادن است و پیامدهای ممکن را تحلیل می‌کند و سپس راجع به آن چه باید انجام شود و زمان آن، تصمیم‌گیری می‌کند تا ریسک‌ها به میزان قابل پذیرشی کاهش یابند.
مدیریت ریسک امنیت اطلاعات همواره بخشی جدانشدنی از تمامی اقدامات مدیریت امنیت اطلاعات میباشد و همچنین در پیاده‌سازی و بهره‌‌برداری مداوم سیستم مدیریت امنیت اطلاعات (ISMS) به‌کار می‌رود.
این فرآیند می‌بایست به صورت مستمری باشد به طوریکه زمینه درونی و بیرونی سازمان را در نظر گرفته و بر این اساس، ریسک‌ها را ارزیابی نماید و با استفاده از برنامه اجرای توصیهها و تصمیمات ریسک‌های بالاتر از توان تحمل سازمان را برطرف نماید.
جهت انجام فرآیند مدیریت ریسک استانداردهای متفاوتی وجود دارد که در اینجا برخی از آنها ذکر شده است:
۱ مدیریت ریسک امنیت اطلاعات
مدیریت ریسک‌های امنیت اطلاعات، به منظور شناسایی، تحلیل یا آنالیز و سنجش ریسک انجام میگردد، پس از انجام این مراحل در یک دسته کلان‌تر با عنوان ارزیابی ریسک، به چگونگی و استراتژی برخورد با ریسک‌های شناسایی شده پرداخته شده و پاسخ به خطرات احتمالی امنیت اطلاعات سازمان صورت می‌پذیرد.
خروجی حاصل از مرحله ارزیابی ریسک شامل سناریوهای ریسکی هستند که در محدوده‌های متفاوتی نظیر قابل‌قبول و یا غیرقابل قبول برای سازمان دسته‌بندی می‌شوند. برای ریسک‌های غیر قابل‌قبول ۴ رویکرد اصلی که در ادامه به تشریح آنها می‌پردازیم، در پیش‌روی سازمان وجود دارد.
در این مرحله سازمان می بایست استراتژی و برنامه خود برای برخورد و مقابله با ریسک‌های پذیرش نشده را تعیین نماید. مهمترین خروجی این بخش طرح مقابله با ریسک (RTP) میباشد که در آن سازمان ضمن اولویت‌بندی ریسک‌ها، هر یک از اقدامات مدنظر خود را به منظور مقابله با آنها تشریح می‌نماید.
مدیریت ریسک امنیت اطلاعات به موارد زیر کمک می‌کند:
- شناسایی و ارزیابی ریسک
- درک احتمال ریسک و عواقب آن برای کسب و کار
- ایجاد دستور اولویت‌دهی برای کاهش ریسک
- مشارکت ذی‌نفعان در تصمیمات مدیریت ریسک
- اثربخشی نظارت بر کاهش ریسک
- آگاهی کارکنان از خطرات و اقدامات انجام شده برای کاهش آنها.
مدیریت ریسک‌ها امنیت اطلاعات، باید شامل موارد زیر باشد:
- شناسایی ریسک‌ها
- ارزیابی ریسک‌ها، بر حسب پیامدهای‌شان برای کسب و کار و احتمال وقوع آنها
- گفتمان و درک در مورد احتمال و پیامدهای ریسک‌ها
- تعیین اولویت‌ها برای کاهش ریسک
- تعیین اولویت‌ها برای اقدامات کاهش وقوع ریسک
- دخیل کردن ذی‌نفعان در اخذ تصمیمات مدیریت ریسک‌ها و آگاهی رساندن به آنها از وضعیت مدیریت ریسک‌ها
- اثربخشی پایش مقابله با ریسک
- پایش و بررسی منظم ریسک‌ها و فرآیند مدیریت ریسک
- جمع‌آوری اطلاعات به‌منظور بهبود رویکرد ریسک
- آموزش به مدیران و کارکنان در رابطه با ریسک‌ها و اقدامات کاهش ریسک
توجه: فرآیند مدیریت ریسک امنیت اطلاعات را میتوان به کل سازمان و یا به بخش‌هایی از سازمان تعمیم داد.
۲ بررسی ISO 27005
این استاندارد از زیرمجموعه استانداردهای خانواده ISO 27000 محسوب میگردد که به بررسی و تشریح فرآیند‌ها‌ی مدیریت امنیت اطللاعات می‌پردازد. در واقع چارچوب استاندارد ISO/IEC 27005 مبتنی بر شناسایی داراییها، آسیبپذیریها و تهدیدات جهت ارزیابی و محاسبه ریسک میباشد که رفع آنها از طریق مجموعه‌ا‌ی از کنترل‌‌ها‌ی مقابله‌ا‌ی برنامه‌ریزی میگردد.
فراهم‌سازی دستورالعمل‌ها‌یی برای مدیریت ریسک امنیت اطلاعات هدف اصلی ISO 27005 میباشد. این استاندارد کلیه مفاهیم بیان‌شده در استاندارد ISO 27001 را پشتیبانی می‌نماید و جهت پیاده‌سازی امنیت اطلاعات براساس رویکرد مدیریت ریسک طراحی شده است.
توصیهها و راهنمایی‌‌‌ها‌ی ارائه شده در ISO / IEC 27005 برای همه سازمانها، صرف نظر از اندازه و نوع آن قابل اجرا هستند، همچنین مشاوره و راهنمایی در مورد مدیریت ریسک در ISO27005 قابل اجرا است. شناخت مفاهیم، مدل‌‌ها، فرآیند‌‌ها و اصطلاحات شرح داده شده در ISO / IEC 27001 و ISO / IEC 27002 برای درک کامل ISO / IEC 27005: 2018 مهم است.
۲-۱ فرآیند مدیریت ریسک ISO 27005
همانطور که در تصویر زیر مشاهده می‌شود، فرآیند مدیریت ریسک شامل زیرفرآیندهای زیر است:
اگرچه ISO 27005 هیچ روش خاصی برای مدیریت ریسک مشخص نمی‌کند، اما بر فرآیند پیوسته مدیریت ریسک اطلاعات مبتنی بر اجزاء کلیدی زیر دلالت دارد:
- زمینه‌سازی
- شناسایی ریسک
- تحلیل ریسک
- ارزشیابی ریسک
- واکنش به ریسک
- پذیرش ریسک
- ارتباط و مشاوره
- نظارت و بازبینی ریسک
- زمینه‌سازی: چارچوب مدیریت ریسک معیارهایی را برای نحوه شناسایی ریسک‌ها، مسئولیت مالکیت ریسک، تأثیر ریسک‌ها بر محرمانه بودن، صحت و در دسترس بودن اطلاعات و نحوه محاسبه تأثیر و احتمال ریسک تعیین می‌کند.
در این مرحله زمینه داخلی و خارجی مدیریت ریسک امنیت اطلاعات پایه‌گذاری می‌شود که شامل تنظیم معیارهای بنیادی برای مدیریت ریسک امنیت اطلاعات است. موارد زیر در این مرحله مد نظر قرار می‌گیرد:
- تعیین رویكرد و روش مدیریت ریسک
- تعیین معیارهای ارزیابی ریسک
- تعیین معیارهای پیامد
- تعیین معیارهای پذیرش ریسک
- تعریف محدوده و قلمرو مدیریت ریسک امنیت اطلاعات
- سازماندهی
- شناسایی ریسک: فرآیند شناسایی ریسک مبتنی بر دارایی را که شامل پنج مرحله کلیدی زیر است، در این مرحله انجام میگردد:
- گردآوری دارایی‌های اطلاعاتی
- شناسایی تهدیدها و آسیب پذیری‌های قابل اعمال برای هر دارایی
- تعیین ارزش تاثیر و احتمال بر اساس معیارهای ریسک
- ارزیابی هر ریسک در برابر سطوح از پیش تعیین شده مقبولیت
- اولویت‌بندی و ترتیب خطرات احتمالی
- تحلیل ریسک
تحلیل ریسک با توجه به سطح جزئیات مورد نظر، میزان حیاتی بودن داراییها، گستره تحلیل ریسک آسیب‌پذیری‌های شناخته شده و نیز رخدادهای دربرگیرنده سازمان انجام می‌شود. روش تحلیل ریسک میتواند كمی و یا كیفی و یا تلفیقی از هر دو باشد. این مرحله شامل گام‌های زیر است:
- ارزیابی پیامدها
- ارزشیابی احتمال رخداد
- تعیین سطح ریسک
- ارزشیابی ریسک
در این زیر فرآیند بر اساس معیارهای استخراج شده در زیر فرآیند تحلیل ریسک، سطح پذیرش ریسک و ریسک‌های قابل پذیرش استخراج می‌شوند. به عبارت دیگر فعالیت‌های انجام شده در این مرحله عبارتند از:
- تعیین معیار پذیرش ریسک
- مقایسه ریسک‌های تحلیل شده با معیار پذیرش، اولویت‌بندی ریسک‌ها و تعیین ریسک‌های قابل پذیرش
- برخورد با ریسک: چهار راه برای برخورد با ریسک وجود دارد، فرآیند برخورد با ریسک در انتخاب اقدامات امنیتی به منظور،كاهش، حفظ، اجتناب و انتقال انجام می‌شود:
- تغییر (اصلاح) ریسک
- انتقال (اشتراك) ریسک
- اجتناب از ریسک
- حفظ ریسک
- پذیرش ریسک
در این مرحله تصمیم‌گیری در خصوص پذیرش ریسک امنیت اطلاعات صورت می‌گیرد. باید توجه داشت كه تصمیمات مرتبط با پذیرش ریسک و نیز مسئولیت تصمیم‌گیری باید به طور رسمی ثبت گردد.
- ارتباط و مشاوره در رابطه با ریسک: ارتباط موثر برای افراد مهم است. فرآیند مدیریت ریسک امنیت اطلاعات این اطمینان را میدهد که تصمیماتی که گرفته می‌شود بر اساس چرایی اقدامات خاصی که مورد نیاز است، میباشد. به اشتراک گذاشتن و تبادل اطلاعات در مورد ریسک همچنین توافق بین تصمیم‌گیرندگان و سایر ذی‌نفعان در مورد نحوه مدیریت ریسک را تسهیل می‌کند.
فعالیت‌های ارتباطی با ریسک باید به طور مداوم انجام شود و سازمانها باید برنامه‌های ارتباطی با ریسک را برای عملیات عادی و همچنین شرایط اضطراری تدوین کنند.
- نظارت و بازبینی ریسک: تهدیدات ثابت نیستند و می‌توانند ناگهان تغییر کنند. به تبع آن ریسک‌ها نیز تغییر نموده و یا ایجاد می‌گردند، بنابراین می‌بایست ریسک‌ها به طور مداوم تحت نظارت قرار گیرند تا تغییرات در کم‌ترین زمان ممکن شناسایی شده و ریسک‌های به وجود آمده بررسی و ارزیابی گردند.
۳ دلایل انتخاب ISO27005
بر خلاف سایر استانداردهای مدیریت ریسک که رویکرد همه جانبه را اتخاذ می‌کنند، ISO 27005 دارای ماهیت انعطاف‌پذیری است و به سازمانها اجازه میدهد تا رویکرد خود را برای ارزیابی ریسک بر اساس اهداف تجاری خاص خود انتخاب کنند.
ISO 27005 از یک ساختار ساده و تکرارپذیر پیروی می‌کند و هریک از بندهای اصلی در چهار بخش زیر سازماندهی شده است:
- ورودی: اطلاعات لازم برای انجام یک عمل
- اقدام: خود فعالیت
- راهنمای پیاده‌سازی: هرگونه جزئیات اضافی
- خروجی: اطلاعاتی که باید توسط فعالیت ایجاد شود
این رویکرد به افراد کمک می‌کند تا اطمینان حاصل شود که سازمانها قبل از شروع هرگونه فعالیت مدیریت ریسک، اطلاعات لازم را در اختیار دارند.
ISO 27005 همچنین مطابق با استاندارد ISO 27001 میباشد، این استاندارد مشخص می‌کند که هرگونه کنترل که در زمینه ISMS (سیستم مدیریت امنیت اطلاعات) اجرا می‌شود می‌بایست مبتنی بر ریسک باشد. پیاده‌سازی فرآیند مدیریت ریسک امنیت اطلاعات مطابق با استاندارد ISO 27005 میتواند این الزام را برآورده سازد.
تدوین: خانم مهندس سعیدی
امنیت JWT بخش سوم – ادامه حملات شناخته شده JWT
در بخش دوم دو نمونه از حملات شناخته شده JWT معرفی گردید. در این بخش سایر حملات مطرح در خصوص JWT بحث خواهد شد.
فرضیات نادرست در صحت‌سنجی رمزگذاری/امضای پشته‌ای
عملیات امضا از دستکاری غیرمجاز محافظت می‌کنند. به عبارت دیگر، علیرغم اینکه، داده‌ها همچنان قابل خواندن می‌باشند، با این وجود قابل تغییر نبوده و هرگونه تغییر در داده‌ها منجر به نامعتبر بودن امضا خواهد شد. در مقابل، عملیات رمزگذاری، داده‌ها را برای موجوریت‌هایی که کلید خصوصی را دارا نمی‌باشند، قابل خواندن نیست. برای بسیاری از برنامه‌ها، امضا به تنهایی کافی میباشد. با این حال، برای داده‌های حساس، ممکن است رمزگذاری مورد نیاز باشد. JWTها از هر دو عملیات فوق پشتیبانی می‌نماید.
بسیاری به اشتباه تصور می‌نمایند که رمزگذاری در مقابل دستکاری و تغییر داده نیز محافظت می‌کند. منطق این فرض به این صورت میباشد که “اگر داده‌ها قابل خواندن نباشند، چگونه یک مهاجم میتواند آنها را به نفع خود تغییر دهد؟”. متأسفانه، این تصور غلط، مهاجمان و همچنین دانش آنها از الگوریتم‌های درگیر در این فرآیند را دست کم می‌گیرد.
برخی از الگوریتم‌های رمزگذاری/رمزگشایی صرف نظر از اعتبار داده‌های ورودی به آنها، خروجی را تولید می‌کنند. به عبارت دیگر، حتی اگر داده‌های رمزگذاری شده تغییر یابند، باز هم الگوریتم رمزگشایی یک رشته‌ای را به عنوان خروجی ایجاد خواهد نمود. تغییر کورکورانه داده‌ها معمولاً خروجی غیر قابل مصرف تولید می‌کند. اما برای یک فرد مهاجم، این امر ممکن است برای دسترسی به سیستم کافی باشد. به عنوان مثال، JWT زیر را در نظر بگیرید:
{
"sub": "joe",
"admin": false
}همانطور که مشاهده می‌شود، “admin” یک مقدار boolean است. اگر مهاجمان بتوانند به گونه‌ای تغییر در داده‌های رمزگشایی شده ایجاد کنند که منجر به تغییر آن مقدار boolean شود، ممکن است منجر به انجام موفقیت آمیز حمله ارتقای دسترسی گردد. به طور دقیقتر، مهاجمی که دارای زمان کافی می‌باشند، می‌توانند به دفعات داده‌های رمزگذاری شده را دستکاری نمایند تا به نتیجه مطلوب برسند.
به همین دلیل، الگوریتم‌های JSON فقط الگوریتم‌های رمزگذاری را که شامل تأیید صحت داده نیز می‌باشند، تعریف می‌کنند. به عبارت دیگر، تا زمانی که الگوریتم رمزگذاری یکی از الگوریتم‌های تایید شده توسط JWA باشد، نیازی به قرار دادن یک JWT رمز شده بر روی JWT امضا شده (بصورت پشته‌ای) نمی‌باشد. اما در صورتیکه از یک الگوریتم غیر استاندارد برای رمزگذاری استفاده شود، باید اطمینان حاصل گردد که صحت داده‌ها توسط آن الگوریتم فراهم می‌شود، در غیر اینصورت باید به منظور تضمین صحت داده، از JWT امضا شده به عنوان درونی‌ترین JWT (پشته‌ای) استفاده شود. JWTهای تو در تو[۱] همچنین ممکن است در زمان ارسال توکن‌ها به یک سیستم طرف ثالث[۲] نیز مورد استفاده قرار گیرد.
اشتباه رایج در این سناریوها مربوط به اعتبارسنجی JWT است. به منظور حصول اطمینان از حفظ صحت داده‌ها و رمزگشایی صحیح داده‌ها، بایستی به ازای تمام لایه‌های JWT، کلیه اعتبارسنجی‌های مربوط به الگوریتم‌های مربوطه انجام شود. به عبارت دیگر، حتی اگر خارجی‌ترین JWT، با موفقیت رمزگشایی و اعتبارسنجی گردد، همچنان لازم است که JWTهای درونی نیز اعتبارسنجی (یا رمزگشایی) شوند. عدم انجام این کار، به ویژه در مورد JWT رمزگذاری شده خارجی که حاوی یک JWT داخلی امضا شده است، میتواند منجر به استفاده از داده‌های اعتبارسنجی نشده شود که میتواند منجر به بروز آسیب‌پذیری‌های متعددی گردد.
۱-۳ حمله جایگزینی[۳]
حملات جایگزینی یک کلاس از حملات است که در آن یک مهاجم موفق می‌شود حداقل دو توکن مختلف را دریافت نموده و سپس یک یا هر دو این توکن‌ها را برای اهدافی غیر از آنچه برای آنها در نظر گرفته شده، استفاده کند. حمله جایگزینی به دو نوع مختلف میباشد: ۱) گیرنده[۴] یکسان و ۲) گیرنده متفاوت.
۱-۳-۱ گیرنده متفاوت
حملات گیرنده‌های مختلف بدین صورت میباشد که توکن در نظر گرفته شده برای یک گیرنده به گیرنده دیگری ارسال میگردد. فرض کنید یک سرور Authorization وجود دارد که برای سرویس طرف ثالث، توکن صادر می‌کند. توکن مذکور، یک Jwt امضاء شده به شکل زیر است.
{
"sub": "joe",
"role": "admin"
}این توکن میتواند در APIها برای انجام عملیاتی که نیاز به احراز هویت دارند مورد استفاده قرار گیرد. در این توکن، کاربر joe دارای سطح دسترسی admin میباشد. با این وجود، این توکن دارای مشکل میباشد. به عبارت دقیقتر، صادر کننده و گیرنده توکن مشخص نیست. در صورتیکه این توکن توسط گیرنده دیگری (غیر از گیرنده اصلی) دریافت شده و تنها به اعتبارسنجی امضا اکتفا نماید، چه اتفاقی خواهد افتاد؟ فرض کنید کاربر joe در پایگاه داده آن سرویس هم به عنوان نام کاربری مجاز وجود داشته باشد. در این شرایط، مهاجم میتواند همین توکن را به آن گیرنده (سرویس) دیگر ارسال نموده و دسترسی admin را بدست آورد!
همانطور که در تصویر فوق مشاهده می‌شود، یک توکن توسط سرور Authorization به منظور احراز هویت و مجازشماری در سرور Org.1، ایجاد و به کاربر ارسال شده است. اما به دلیل اینکه گیرنده یا فرستنده در این توکن تعیین نشده است، فرد مهاجم از آن برای سوء استفاده از سرور org.2 استفاده می‌نماید.
برای جلوگیری از این حملات، اعتبارسنجی توکن باید به کلیدها یا Claimهای منحصر به فرد و به ازای هر سرویس متکی باشد. به عنوان مثال، این توکن میتواند شامل یک Claim با عنوان aud باشد که مخاطب مورد نظر را مشخص می‌کند. به این ترتیب، حتی اگر امضا معتبر باشد، توکن مذکور را نمی‌توان در سایر سرویس‌ها مورد استفاده قرار داد.
۱-۳-۲ گیرنده یکسان
این حمله مشابه حمله قبلی است با این تفاوت که در این مورد، گیرنده یکسان میباشد. آنچه در این حالت تغییر می‌کند این است که مهاجم توکن را به جای سرویس مورد نظر (در همان شرکت یا ارائه دهنده خدمات) به سرویس دیگری می‌فرستد. توکن زیر را در نظر بگیرید.
{
"sub": "joe",
"perms": "write",
"aud": "cool-company/user-database",
"iss": "cool-company"
}
این توکن نسبت به توکن قبلی بسیار امن‌تر به نظر می‌رسداین توکن حاوی Claimهای صادرکننده (iss)، مخاطبان (aud) و مجوز (perms) میباشد. APIی که این توکن برای آن صادر شده است، همه این موارد را به همراه امضای توکن بررسی می‌نماید. به این ترتیب، حتی اگر مهاجمان موفق شوند توکنی را که با همان کلید امضا شده به دست آورند، نمی‌توانند از آن برای کار با سرویسی که برای آن در نظر گرفته نشده است، استفاده کنند.
فرض کنید شرکت cool-company سرویس‌های عمومی دیگری نیز دارد. یکی از این سرویس‌ها، سرویس cool-company/item-database میباشد که اخیرا به گونه‌ای تنظیم شده است که امضای توکن و Claimها بررسی نماید. با این حال، تیم مسئول به‌روزرسانی اشتباهی مرتکب شده و aud را به درستی اعتبارسنجی نمی‌نمایند. به عبارت دیگر، به جای بررسی کامل و دقیق مقدار aud، تنها به وجود عبارت cool-company اکتفا شده است. در این شرایط، توکنی که برای سرویس دیگر شرکت (cool-company/user-database) ایجاد و منتشر شده است، میتواند در اعتبارسنجی سرویس cool-company/item-database نیز با موفقیت مورد استفاده قرار گیرد. به عبارت دیگر، مهاجمان می‌توانند از توکن در نظر گرفته شده برای سرویس user-database به منظور احراز هویت و مجازشماری برای سرویس item-database نیز استفاده کنند.
[۱] Nested
[۲] ۳rd Party
[۳] Substitution
[۴] Repicient
تدوین: امیر حسین بابایی
امنیت 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ها در آوریل ۲۰۲۱ منتشر خواهد شد. |
نکات امنیتی دورکاری ویژه مدیران/راهبران
- امن‌سازی زیرساخت شبکه و سرویس‌های سازمان بر اساس بهین تجربیات امنیتی معتبر
- پیکربندی امن تجهیزات امنیتی از قبیل فایروال و WAF
- پیاده‌سازی مکانیزم احراز هویت دو عاملی برای سامانه‌ها و سیستم‌های حساس
- به‌روزرسانی آنتی ویروس‌ها
- نصب سریع وصله‌های امنیتی و به‌روزرسانی‌ها
- محدودسازی استفاده از نرم‌افزارهای ارتباط راهدور از قبیل AnyDesk و TeamViewer
- پیاده‌سازی امن راهکارهای VPN به منظور برقراری ارتباط راهدور کارکنان با سیستمها و شبکههای سازمانی
- عدم استفاده از پروتکل‌های ناامن و دارای آسیبپذیری
- عدم باز نمودن پورت‌های مدیریتی و دسترسی راه دور از قبیل RDP، VNC و SSH به طور مستقیم بر روی اینترنت
- تنظیم Timeout محدود و کوتاه برای تمامی نشست‌های راه دور کاربران
- پایش کلیه اتصالات و دسترسیهای راه دور
- تخصیص حساب‌های کاربری منحصربفرد برای هر فرد
- اختصاص مجوزهای کاربران بر اساس اصل حداقل دسترسی مورد نیاز
- ارائه روش‌های ارتباطی مناسب از قبیل ایمیل یا شماره تلفن به کارکنان جهت گزارش رخدادها و حملات سایبری
١٩ گام امنیتی برای شکست COVID-19
- انتخاب یک مکان مستقل و غیر عمومی برای انجام دورکاری
- استفاده از رایانه اختصاصی برای انجام وظایف
- استفاده از کلمات عبور قوی و پیچیده
- اجتناب از به اشتراکگذاری رمز عبور با سایرین
- استفاده از احراز هویت دو عاملی
- استفاده از VPN برای اتصال به شبکه سازمان
- استفاده از آنتی‌ویروس معتبر و به‌روز
- نصب سریع وصله‌های امنیتی و به‌روزرسانی‌ها
- عدم استفاده از شبکه بی‌سیم ناامن
- پشتیبان‌گیری از داده‌ها و اطلاعات مهم در تجهیز ذخیره‌ساز خارجی
- استفاده از فضای ابری مورد تایید سازمان برای ذخیره اطلاعات
- عدم استفاده از نرم‌افزارهای ارتباط راهدور از قبیل AnyDesk و TeamViewer
- عدم بکارگیری ابزارهای ارتباطی از قبیل Whatsapp، Telegram، Linkedin برای تبادل اطلاعات
- عدم کلیک بر روی ایمیل‌ها، لینک‌ها و باز نمودن فایل‌های مشکوک
- رمزنگاری اطلاعات ذخیره شده و در حال انتقال
- عدم استفاده از حساب کاربری با سطح دسترسی بالا برای انجام کارهای عادی
- قفل نمودن سیستم در زمان ترک آن
- گزارش رخدادهای سایبری و موارد مشکوک به سازمان
- اطمینان از مسدود بودن میکروفون و وبکم‌ها در زمان عدم استفاده
راهنمای امنیتی؛ نکات امنیتی دورکاری کارکنان در سازمانها
راهنمای امنیتی؛ نکات امنیتی دورکاری کارکنان در سازمانها قبل از مطالعه بدانید: در این راهنما به درست/نادرست بودن دورکاری اشاره ای نگردیده، زیرا که سیاست‌ها و نیازهای سازمانها متفاوت است. پس با فرض اینکه به این نتیجه رسیده‌اید که دورکاری در شرکت یا سازمان شما انجام گردد، می‌توانید از این راهنما در خصوص افزایش امنیت […]