خب، ویشینگ در امنیت سایبری چیست و چرا توسعهدهندگان باید به آن اهمیت بدهند؟ ویشینگ، مخفف فیشینگ صوتی، یک تکنیک مهندسی اجتماعی است که در آن مهاجمان از تماسهای تلفنی یا پیامهای صوتی برای فریب اهداف جهت افشای اعتبارنامهها، تنظیم مجدد توکنها یا دور زدن کنترلهای امنیتی استفاده میکنند. در حالی که حملات ویشینگ زمانی کارمندان عمومی را هدف قرار میداد، مهاجمان به سمت توسعهدهندگان، مهندسان DevOps و مدیران سیستم تغییر جهت دادهاند، زیرا این نقشها دسترسی مستقیم به کد دارند، pipelineها، و زیرساخت ابری.
مثال: الفمهاجمی با شما تماس میگیرد و وانمود میکند که از تیم فناوری اطلاعات داخلی شماست: «به دلیل یک حادثه امنیتی، اعتبارنامههای گیتهاب شما را تغییر میدهیم؛ باید اعتبارنامههای شما را تأیید کنم.» کد وزارت امور خارجه"
یک حرکت اشتباه، و کد منبع شما یا pipeline اعتبارنامهها افشا میشوند. در محیطهای توسعهدهندگان، یک حمله ویشینگ موفق میتواند:
- منجر به CI/CD بازنشانی توکن و استقرارهای غیرمجاز
- افشای کلیدهای API یا اعتبارنامههای SSH که به صورت محلی ذخیره شدهاند
- به خطر انداختن رجیستریهای ابری و کانتینری مورد استفاده توسط سیستم ساخت
به همین دلیل است که فهمیدن ویشینگ اختیاری نیست؛ بلکه بخشی از ایمنسازی تحویل شماست. pipeline.
حملات ویشینگ در دنیای واقعی که توسعهدهندگان و CI/CD محیط ها
بیایید بررسی کنیم که حملات ویشینگ واقعی چگونه بر محیطهای فنی تأثیر گذاشتهاند.
سناریوهای ناامن زیر فقط برای اهداف آموزشی هستند؛ بدون مجوز، در محیط عملیاتی یا آزمایش داخلی تکرار نکنید.
- نقض امنیتی توییتر در سال ۲۰۲۰: مهاجمان با کارمندان تماس گرفتند و خود را به عنوان مدیر داخلی فناوری اطلاعات جا زدند. آنها کارکنان را متقاعد کردند که کدهای MFA را به اشتراک بگذارند و به این ترتیب به پشت صحنه دسترسی پیدا کردند که امکان تصاحب حسابها را فراهم میکرد.
- حادثه گیتهاب (۲۰۲۲): توسعهدهندگان با تماسهایی که ادعا میشد از طرف پشتیبانی امنیتی هستند، هدف قرار گرفتند و به آنها راهنمایی شد تا اعتبارنامههای خود را «تنظیم مجدد» کنند که منجر به دسترسی غیرمجاز به مخزن شد.
- سناریوهای مدیریتی AWS: مهاجمان از مهندسی اجتماعی مبتنی بر تلفن برای تنظیم مجدد رمز عبور و دسترسی به حسابهای توسعهدهندگان مرتبط با نقشهای IAM در محیط عملیاتی استفاده کردند.
برای توسعهدهندگان، اینها خطرات انتزاعی نیستند. در یک آزمایش شبیهسازیشدهی تیم قرمز داخلی، یک مهندس یک مورد جعلی را «تأیید» کرد. pipeline مشکلی تلفنی که منجر به لغو مجوز شد CI/CD توکن دوباره به یک ایمیل تحت کنترل مهاجم ارسال میشود. این جوهره یک حمله ویشینگ است: استفاده از فوریت، اعتماد و زمینه فنی برای فریب دادن متخصصانی که فکر میکنند بیش از حد فنی هستند که بتوان آنها را فریب داد.
زنجیره حمله: از یک فراخوانی تا دسترسی کامل به مخزن
در اینجا نحوهی وقوع یک حملهی ویشینگ گام به گام، به طور خاص در ...، آورده شده است. DevOps یا محیط توسعه
- تماس اولیه: tمهاجم با جعل هویت پشتیبانی فناوری اطلاعات، یک فروشنده یا حتی یک ارائهدهنده خدمات ابری، تماس میگیرد.
اسکریپت نمونه:
«سلام، ما موارد مشکوکی را شناسایی کردهایم.» login فعالیت در حساب GitHub شما. آیا میتوانم کد MFA شما را تأیید کنم تا بتوانیم فوراً آن را ایمن کنیم؟"
- برداشت اعتبارنامه: مهاجم قربانی را فریب میدهد تا اطلاعات احراز هویت، کدهای OTP یا مجوزهای برنامه OAuth را فاش کند.
- تشدید امتیاز: به محض ورود، مهاجم اعتبارنامهها را بازنشانی میکند یا اطلاعات را بازیابی میکند. CI/CD رازها
- Pipeline سازش: آنها یک ساختار مخرب را اعمال میکنند، اسکریپت استقرار را دستکاری میکنند یا کد منبع را استخراج میکنند.
⚠️ مثال ناامن، فقط برای اهداف آموزشی. در محیط عملیاتی استفاده نشود.
نسخه امن:
⚠️ هشدار: از چاپ یا ثبت متغیرهای حساس (توکنها، اعتبارنامهها یا رمزها) در گزارشهای ساخت خودداری کنید. گزارشها اغلب برای چندین کاربر و سیستم قابل دسترسی هستند که میتواند منجر به افشای ناخواسته اعتبارنامهها شود.
چرا آگاهیرسانی سنتی در مورد امنیت کافی نیست؟
توسعهدهندگان اغلب فرض میکنند که «آموزش آگاهیبخشی» از آنها محافظت میکند. اما وقتی مراحل اعتبارسنجی فنی انجام نشود، دانستن اینکه ویشینگ چیست، کافی نیست. مهاجمان از نقاط ضعف رویهای سوءاستفاده میکنند، نه فقط از جهل:
- فرآیندهای پشتیبانی که دسترسی را بر اساس درخواستهای تلفنی بازنشانی میکنند
- عدم تأیید هویت پشتیبان
- اتکای بیش از حد به MFA بدون اعتبارسنجی زمینهای
چک لیست کوچک: جلوگیری از ویشینگ توسعهدهندگان
- هرگز کدها یا توکنهای MFA را از طریق تماسهای صوتی به اشتراک نگذارید
- هویت تماسگیرنده را از طریق دایرکتوری داخلی یا تأیید چت تأیید کنید
- اجرای رویههای تماس مجدد (تماس مجدد از طریق یک شماره داخلی تأیید شده)
- حسابرسی بخش پشتیبانی و تنظیم مجدد گردشهای کاری برای اعتبارسنجی هویت
- برای تنظیم مجدد رمز عبور یا توکن از کانالهای امن (SSO، ارائهدهنده هویت) استفاده کنید.
روش تأیید بازنشانی امن
- هرگز MFA یا توکنها را از طریق تماس صوتی به اشتراک نگذارید
- قطع کنید و با استفاده از یک شماره داخلی تأیید شده دوباره تماس بگیرید
- درخواست را از طریق میز کمک رسمی یا پورتال SSO تأیید کنید
- فقط پس از تأیید هویت درخواستکننده، ادامه دهید
ایجاد راهکارهای دفاعی در برابر ویشینگ در گردشهای کاری DevOps
برای دفاع در برابر حملات ویشینگ در CI/CD و محیطهای توسعهدهندگان، آگاهی باید با اجرای فنی همراه شود. اقدامات عملی عبارتند از:
- احراز هویت چند عاملی (MFA) با تأیید خارج از باند: هرگز برای وظایف مدیریتی به MFA مبتنی بر تلفن تکیه نکنید.
- سیاستهای دسترسی درجا (JIT): محدود کردن پنجرههای دسترسی برای اقدامات با امتیاز بالا.
- اعتبارسنجی خودکار: هنگام بازنشانی اعتبارنامهها یا تغییر غیرمنتظره مجوزها، هشدارهایی را فعال میکند.
- نظارت رفتاری: تشخیص الگوهای صوتی یا دسترسی غیرعادی مرتبط با تعاملات پشتیبانی.
مثلا:
این نوع اتوماسیون قبل از اعمال اقدام انسانی، مشروعیت آن را تأیید میکند.
اعتبارسنجی مداوم و اجرای سیاستها برای اقدامات آغاز شده توسط انسان
حتی بهترین توسعهدهنده آموزشدیده هم میتواند تحت فشار اشتباه کند. اعتبارسنجی مداوم تضمین میکند که یک تماس ویشینگ نمیتواند از کنترلهای امنیتی خودکار عبور کند.
با استفاده از کنترل دسترسی مبتنی بر ویژگی (ABAC) یا سیاستهای آگاه از متن، pipelineمیتواند به طور خودکار موارد زیر را تأیید کند:
- منبع درخواست (IP داخلی، دستگاه شناخته شده یا جلسه).
- زمان انجام عمل (در طول ساعات کاری یا به دلیل ناهنجاری پس از ساعات کاری).
- ویژگیهای هویتی (تطبیق نقشهای کاربر و رفتار قبلی).
این یعنی درخواست بازنشانی رمز عبور که پس از ساعات کاری و از طریق شماره جدید ارسال شود، حتی اگر کاربر دستکاری شده باشد، به طور خودکار تأیید نخواهد شد. این کنترلهای فنی، اجرای حملات ویشینگ را دشوارتر و شناسایی آنها را سریعتر میکند.
آگاهی + اتوماسیون = حفاظت واقعی
توسعهدهندگان اکنون در مرکز حملات هویتمحور قرار دارند. درک اینکه چه چیزی در امنیت سایبری ویشینگ نامیده میشود، فقط یک موضوع آگاهیبخشی نیست؛ بلکه یک نگرانی DevSecOps است که با کد مرتبط است. pipelineها، و زیرساخت ها.
ترکیب آگاهی با اتوماسیون:
- اعتبارسنجی هر درخواست دسترسی
- برای بازنشانی اعتبارنامهها، تأیید خارج از باند را اعمال کنید
- نظارت مداوم بر موارد غیرعادی pipeline اقدامات
بستر های نرم افزاری مانند شیگنی به تیمهای توسعه و امنیت کمک کنید تا فعالیتهای مرتبط با ویشینگ را شناسایی کنند، اعتبارسنجی دسترسی زمینهای را اجرا کنند، و محافظت از CI/CD pipelines از تهدیدات مبتنی بر مهندسی اجتماعی. یک حمله ویشینگ به بدافزار نیاز ندارد؛ فقط به یک صدای قابل اعتماد نیاز دارد. مطمئن شوید که سیستمهای شما کورکورانه اعتماد نمیکنند.
