تیم امنیت سایبری حامیان ولایت

اللهم إیّاک نعبد و إیّاک نستعین

تیم امنیت سایبری حامیان ولایت

اللهم إیّاک نعبد و إیّاک نستعین

تیم  امنیت سایبری حامیان ولایت

تیم امنیت سایبری حامیان ولایت در سال 1392 فعالیت خود را در زمینه های هک و امنیت آغاز کرد و به زودی به کمک کاربران فعال و مدیران لایق یکی از بزرگ ترین انجمن های هک و امنیت ایران خواهد شد . تیم امنیت سایبری ولایت فقط جهت اشنایی و بالا بردن سطح اطلاعات هم وطنان عزیزمان در زمینه ی هک و امنیت و طبق قوانین جمهوری اسلامی ایران فعالیت میکند. گروه ما از همین جا اعلام می دارد که هدف ما ارتقای امنیت سایت های ایرانی است وبه هیچ عنوان به سایت های ایرانی حمله نخواهیم کرد و هرگونه حمله ای بنام تیم ما، مورد تایید گروه ما نیست.

پیوندهای روزانه

۳۱ مطلب با کلمه‌ی کلیدی «نفوذ» ثبت شده است

ابزاری می‌باشد‌ که اگر کاربر شما عضو گروه administrator کامپیوترتان باشد احتمالا از آن استفاده کرده‌اید دلیل آن این است که به صورت پیش‌فرض برای کاربران معمولی غیرفعال می‌باشد به این معنی که کاربر معمولی به صورت پیش‌فرض با آن مواجه نمی‌شود. تنظیمات UAC به شما اجازه می‌دهد تنظیمات دلخواه خود را متناسب با شرکتان و سازمانتان انجام دهید.

 User Account Control

Uacیک ویژگی امنیتی می‌باشد، وقتی که یک عملیات و یا یک اقدام نیاز به سطح دسترسی بیشتری به سیستم شما را دارد به شما اطلاع می‌دهد. شما در سیستم عامل ‌های گذشته مانند سیستم عامل window Xp اگر با کاربری که عضو گروه admin بود log on می‌کردید به صورت اتوماتیک به بالاترین سطح مدیریتی(سطح امنیتی) در تمامی زمان‌ها دسترسی داشتید .

  • مدیرکل

یک حفره فوق‏ العاده خطرناک اینترنتی طی سه روز گذشته تمام اینترنت را مشغول خود کرده است. Heartbleed یا خونریزی قلبی بسیاری از سایت‏ها و سرویس‏های مشهور را آلوده کرده و گفته می‏شود میلیون‏ها اکانت در سراسر جهان را در معرض دزدیده شدن قرار داده است.

Heartbleed به گفته متخصصان امنیتی مهم‌ترین حفره و ضعف امنیتی اینترنتی از زمان پیدایش آن است و بسیاری از سایت‏های مشهور مثل Yahoo را آلوده کرد، اما به دلیل آنکه بسیاری از شرکت‏ها اطلاعات و ضعف‏های امنیتی خود را فاش نمی‏کنند مشخص نیست که دقیقا چه سایت‏هایی آلوده شده‏ اند.
  • مدیرکل
انتخاب یک کلمه عبور خوب و قوی چقدر مشکل است؟ بیشتر مردم اعتقاد دارند که انتخاب یک کلمه عبور خوب ساده است. اما در حقیقت اغلب مردم معمولا کلمات عبور ضعیفی انتخاب می کنند. در سال 1990 تلاش برای نفوذ به یک پایگاه داده بزرگ از کلمات عبور منجر به کشف بیش از 300 کلمه عبور در همان 15 دقیقه اول شد! یک پنجم از کلمات عبور در هفته اول و تقریبا یک چهارم از آنها تا پایان عملیات پیدا شدند. بیش از نصف کلمات عبوری که مورد نفوذ قرار گرفته بودند از شش کاراکتر یا کمتر تشکیل شده بودند و برخی از حسابهای کاربری اصلا کلمه عبور نداشتند! انتخاب یک کلمه عبور مناسب در حقیقت مصالحه ای بین انتخاب چیزی است که به سختی حدس زده می شود و چیزی که به راحتی به خاطر سپرده می شود. برای مثال ممکن است @G7x.m^l یک کلمه عبور خوب باشد، در حالیکه هیچکس نمی تواند آن را به راحتی به خاطر بسپارد. برعکس، به خاطر سپردن نام شما برای شما کار بسیار بسیار ساده ای است و در مقابل حدس زدن آن نیز برای هکرها کار ساده ای خواهد بود.

برخی قوانین ساده و اولیه

برخی راهکارهای ساده برای انتخاب کلمه عبور مناسب عبارتند از:
  • یک کلمه عبور حداقل باید از 8 کاراکتر تشکیل شده باشد.
  • سعی کنید برخی علائم نگارشی یا ارقام را در کلمه عبور خود وارد کنید.
  • بهتر است کلمه عبور شما از ترکیبی از حروف بزرگ و کوچک الفبا تشکیل شده باشد.
  • یک عبارت یا ترکیبی از کلمات را انتخاب کنید تا به خاطر سپردن کلمه عبور کار ساده تری گردد.
  • کلمه ای که در یک دیکشنری از جمله دیکشنریهای زبانهای دیگر وجود داشته باشد را انتخاب نکنید.
  • حروفی را که روی صفحه کلید پشت سر هم قرار دارند مانند qwertyui انتخاب نکنید.
  • هیچ کاراکتری را بیش از یکبار بصورت پشت سر هم تکرار نکنید.
  • فقط از علائم نگارشی یا ارقام یا حروف الفبا استفاده نکنید. بلکه ترکیبی از آنها را بکار ببرید.
  • کلماتی که به سادگی قابل حدس زدن هستند انتخاب نکنید، مانند:
    • شماره تلفنها
    • شماره اتومبیل
    • اسامی دوستان یا خویشاوندان
    • نام یا جزئیات کار خود
    • تاریخ
  • هرگز نام کاربری خود را بعنوان کلمه عبور استفاده نکنید.
  • از کلمات عبور متفاوت برای حسابهای کاربری مختلف استفاده کنید.
  • کلمات عبور خود را هر از گاهی تغییر داده و از کلمات عبور قدیمی خود دوباره استفاده نکنید.
  • یک رقم یا علامت نگارشی را درست به ابتدا یا انتهای یک کلمه اضافه نکنید.
  • از معکوس کلمات معنی دار استفاده نکنید.
  • حروف را با ارقامی که از نظر ظاهری به آنها شبیه هستند جایگزین نکنید. برای مثال جایگزین کردن تمامی حروف I در کلمه عبور با رقم 1 کار درستی نیست.
  • مدیرکل
امروزه مرورگرهایی مانند Internet Explorer 7 و Mozilla Firefox تقریباً بر روی همه رایانه ها نصب می شوند و از آنجایی که اغلب اوقات مورد استفاده کاربران قرار می گیرند، ایمن سازی آنها یکی از ضروریات محسوب می شود. متأسفانه مرورگرهایی که به صورت پیش فرض همراه با سیستم عامل نصب می شوند، در اکثر موارد دارای تنظیمات ایمنی نیستند و عدم ایمن سازی مرورگر، خیلی سریع منجر به بروز مشکلاتی از قبیل نصب پنهانی هرزنامه ها گرفته تا در اختیار گرفتن رایانه توسط نفوذگران می شود. قابل ذکر است که تعداد حمله های نرم افزاری که با استفاده از آسیب پذیری مرورگرها به وقوع می پیوندند، روز به روز در حال افزایش است. عوامل مختلفی در افزایش چشمگیر حمله های امنیتی از طریق مرورگرها دخیلند که برخی از مهمترین آنها در ذیل آورده شده است:
  • مدیرکل
عنصر اصلی در برنامه‌نویسی امن با زبان‌های مختلف برنامه‌نویسی، مستندسازی خوب و استفاده از استانداردهای قابل اجرا است. استانداردهای کدنویسی، برنامه نویسان را ترغیب به پیروی از مجموعه‌ای متحدالشکل از قوانین و راهنمایی‌ها می‌کند که بر اساس نیازمندی‌های پروژه و سازمان تعیین شده است، نه بر اساس سلایق و مهارت‌های مختلف برنامه‌نویسان. به محض تعیین استانداردهای مذکور، می توان از آن به عنوان معیاری برای ارزیابی کدهای منبع، چه به صورت دستی و چه به صورت اتوماتیک استفاده کرد.
از استانداردهای معروف در این زمینه می‌توان به استانداردCERT برای کدنویسی امن اشاره کرد که یک سری از قوانین و پیشنهادات را برای کدنویسی امن با زبان‌های برنامه‌نویسی C، C++ و جاوا ارائه می‌دهد. هدف از این قوانین و پیشنهادات، حذف عادت‌های کدنویسی ناامن و رفتارهای تعریف نشده است که منجر به آسیب‌پذیری‌های قابل سوءاستفاده می‌شود. به کارگیری استانداردهای مذکور منجر به تولید سیستم‌های با کیفیت بالاتر می‌شود که در برابر حملات بالقوه، پایدارتر و مقاوم‌تر هستند.
در مقاله "آشنایی با استاندارد CERT برای برنامه‌نویسی امن"، کلیات استاندارد CERT در زمینه مزبور را توضیح دادیم و در سری مقاله‌های برنامه‌نویسی امن به زبان C به صورت تخصصی‌تر شیوه برنامه‌نویسی امن با این زبان را مورد بررسی قرار می‌دهیم. قابل ذکر است که در این استاندارد 89 قانون و 134 پیشنهاد برای برنامه‌نویسی امن با زبان C ارائه شده است که در این سری مقالات، مهمترین آنها را که در سطح یک قرار دارند، شرح خواهیم داد. برای کسب اطلاعات بیشتر در مورد سطح‌بندی قوانین و پیشنهادات به مقاله "آشنایی با استاندارد CERT برای برنامه نویسی امن" مراجعه فرمایید. در مقاله حاضر به پیشنهادات و قوانین ارائه شده سطح اول در مورد ورودی - خروجی خواهیم پرداخت.
  • مدیرکل
تمام برنامه های کاربردی تحت وب از منطق خاص خود برای عملیاتی کردن وب سایت مربوطه استفاده می کنند. نوشتن کد با استفاده از یک زبان برنامه نویسی در اصل چیزی به جز شکستن پروسه های پیچیده به گام های منطقی کوچک، نیست. البته ترجمه یک عملیات کوچک که برای انسان معنادار است به ترتیبی از دستورات که برای کامپیوتر قابل اجرا باشند، کاری است که نیاز به تجربه و مهارت فراوانی دارد و از طرف دیگر نوشتن کد مذکور به صورتی که امن و قابل اعتماد باشد، نیز کاری به مراتب دشوارتر است. زمانی که تعداد زیادی طراح و برنامه نویس به صورت موازی بر روی یک برنامه کاربردی کار می کنند، به احتمال بسیار زیاد مشکلات امنیتی متعددی بروز خواهند کرد. حتی در ساده ترین برنامه های تحت وب نیز منطق گسترده ای در هر گام برنامه وجود دارد و این امر منجر به ایجاد سطح حمله ای می شود که اغلب از آن چشم پوشی می گردد. بسیاری از تست نفوذها و مرور کدها بر روی آسیب پذیری های اصلی همچون تزریق SQL و یا cross-site-scripting تمرکز می کنند، زیرا آسیب پذیری های مذکور دارای امضای قابل تشخیص بوده و در مورد بردارهای حمله آنها به اندازه کافی تحقیق شده و اطلاعات وجود دارد. در نقطه مقابل، شناسایی آسیب پذیری های موجود در منطق برنامه بسیار سخت است، زیرا هر نمونه آسیب پذیری ممکن است تنها یک بار و برای یک برنامه خاص اتفاق بیفتد که قابل تشخیص توسط ابزارهای اتوماتیک شناسایی آسیب پذیری ها نیست. به همین دلیل به آسیب پذیری های مذکور چندان توجه نشده و این امر موجب می شود علاقه هکرها به شدت جلب این دسته از نقص های امنیتی شود.
در مقاله قبل در مورد طبیعت نقص های امنیتی منطقی که اغلب از فرض های ناقص سرچشمه می گیرند صحبت کردیم و با چندین مثال واقعی این موضوع را روشن تر ساختیم. در این مقاله نیز به تکمیل مثال های مزبور می پردازیم.
 
محدودیت های عددی
 
در این مثال فرض ناقص در برنامه کاربردی یک کارخانه را مورد بررسی قرار می دهیم. در این برنامه کارمندان بخش مالی اجازه انتقال پول بین حساب های بانکی متعلق به کارخانه، مشتریان و تأمین کنندگان را دارا هستند. برای جلوگیری از هر گونه کلاهبرداری و یا اختلاس، اکثر کارمندان اجازه انتقال مبالغ بیش از 10 هزار دلار را دارا نبوده و برای این کار باید از مدیر بالاتر خود اجازه بگیرند. این احتیاط توسط کد زیر پیاده سازی شده است:
 
Bool CAuthCheck::RequiresApproval(int amount)
{
            If (amount <= m_apprTreshold)
                        Return false;
            Else return true;
}
 
برنامه نویسان در اینجا فرض کرده اند که با این برنامه هیچ کس نمی تواند مبالغی بیش از حد تعیین شده را بدون اجازه مدیر خود جابجا کند. فرض برنامه نویسان در اینجا ناقص است چون در نظر نگرفته اند که ممکن است فردی سعی کند تا مبالغ منفی را جابجا کند. در این صورت فرد نیازی به تأیید مدیر خود ندارد زیرا هر مقدار منفی کمتر از Trshold است. جالب است که در همین برنامه تابع مربوط به نقل و انتقالات بانکی مبالغ منفی را پذیرفته و آن را به عنوان انتقال معکوس در نظر می گیرد. برای مثال در صورتی که قرار است مبلغ X از حساب A به حساب B منتقل شود، می توان مبلغ –X را از حساب B به A منتقل کرد. با این حساب کاربر خرابکار می تواند هر مقداری را که بخواهد در قالب عددی منفی در بین حساب ها جابجا کند!
بسیاری از برنامه های کاربردی از محدودیت های عددی در برنامه های خود استفاده می کنند. برای مثال می توان به موارد زیر اشاره کرد:
 
  • یک برنامه کاربردی متعلق به یک فروشگاه ممکن است مانع از فروش کالا بیش از مقدار موجود در انبار شود.
  • یک برنامه کاربردی متعلق به بانک لازم است از برداشت پول بیش از مقدار موجود در حساب جلوگیری به عمل آورد.
  • یک برنامه کاربردی متعلق به شرکت بیمه ممکن است درخواست ها را بر مبنای حدی از تعداد سال ها تنظیم کند.
 
می توان مثال های مشابه زیاد دیگری را نیز مطرح کرد. در صورتی که یک کاربر خرابکار بتواند به نوعی در شرط های مذکور تقلب کند، ممکن است منجر به حملات مختلف و یا نشت اطلاعات شود. لذا برنامه نویسان لازم است در به کارگیری محدودیت های عددی نهایت دقت را به کار برند.
 
تقلب در تخفیف
 
این مثال مربوط به یک برنامه کاربردی متعلق به یک فروشگاه آنلاین محصولات نرم افزاری است. در این برنامه به کاربران اجازه داده می شود تا محصولات را به صورت عمده نیز خریداری کنند و در مقابل خرید عمده از تخفیف برخوردارد شوند.
زمانی که کاربر کالایی را به سبد خرید اضافه می کند، برنامه طبق پارامترهای مختلف مشخص می کند که آیا میزان خرید کاربر تا کنون مشمول تخفیف می شود یا خیر. در صورت مشمول تخفیف بودن، قیمت کالاهای مذکور در جا تغییر کرده و در سبد خرید، قیمت تخفیف خورده درج می شود. برنامه نویسان فرض کرده اند که کاربر سبد خرید انتخاب شده را خریداری خواهد کرد و در نتیجه موضوع تخفیف پابرجا است.
واضح است که فرض برنامه نویسان دارای نقص است و کاربر می تواند قبل از نهایی شدن خرید، کالاها را از سبد خرید خود حذف نماید. یک کاربر خرابکار می تواند با اضافه کردن تعداد زیاد کالاها از تخفیف برخوردار شده و سپس کالاهایی را که مورد نیاز او نیست، حذف نماید و به این ترتیب از تخفیفی برخوردار شود که حق او نیست.
به برنامه نویسان توصیه می شود همواره فرض کنند که کاربران ممکن است مسیر نرمال استفاده از یک ابزار را طی نکنند و در نتیجه لازم است همه احتمالات مورد بررسی قرار گیرد.
 
شرایط رقابتی در ورود به سیستم
 
این مثال مربوط به یک برنامه کاربردی تحت وب متعلق به یک بانک است. در این برنامه راهکارهای متعددی برای ورود و تأیید هویت افراد دیده شده است. از دیدگاه طراحان و برنامه نویسان این برنامه، افراد خرابکار به هیچ وجه نمی توانند وارد این سیستم شوند. با وجودی که آنها تمام نکات امنیتی و راهکارهای موجود برای تأیید هویت امن را رعایت کرده بودند، اما گاهی اوقات مواجه با اتفاقی عجیب می شدند؛ زمانی که کاربری وارد سیستم می شد می توانست به کنترل کامل حساب کاربری دیگری نیز دسترسی پیدا کند. ظاهراً این اتفاق به صورت تصادفی رخ می داد و حتی دسترسی به حساب کاربران دیگر نیز به صورت تصادفی بود. بعد از تحقیقات بسیار مشخص شد، زمانی که دو کاربر به صورت تقریباً همزمان وارد سیستم می شوند، کاربری که اول وارد شده است می تواند به حساب کاربری فردی که بلافاصله بعد از او وارد سیستم شده است دسترسی پیدا کند. در بررسی کد برنامه معلوم گشت که برنامه برای هر فرد که وارد سیستم می شود بعد از گذشتن از مراحل ورود به سیستم (login) یک کد تأیید هویت ایجاد می کند که با استفاده از آن کنترل حساب کاربری تا زمان خروج از سیستم (logout) در اختیار وی قرار می گیرد.  اشتباه آنها در این بود که از یک متغیر استاتیک برای نگهداری این کد استفاده کرده بودند و در مواقع نادری به علت استاتیک بودن متغیر، همان کدی که به شخص بعدی تخصیص داده شده بود به فرد قبلی نیز انتقال پیدا می کرد و وی می توانست به هر دو حساب به صورت همزمان دسترسی پیدا کند!
  • مدیرکل
مدیریت رخداد بسیار شبیه به اورژانس پزشکی است. در این وضعیت، فرد کمک رسان تحت فشار قرار داشته و اشتباهات وی می توانند بسیار گران تمام شوند. در اختیار داشتن یک روال ساده و از پیش تعریف شده، در این موارد بهترین راهکار است. به همین دلیل بزرگترین و با تجربه ترین متخصصین مدیریت رخدادهای امنیتی نیز از روال های از پیش تعریف شده و سیستماتیک برای پاسخگویی به رخدادهای مرتبط با امنیت استفاده می کنند. این افراد، شش مرحله ثابت و مشخص را همواره در ذهن خود دارند، از فرم های از پیش طراحی شده استفاده می کنند و در صورت نیاز، از دیگران کمک می گیرند. این شش مرحله به طور مختصر به شرح زیرند:
  • مدیرکل
تمام برنامه های کاربردی تحت وب از منطق خاص خود برای عملیاتی کردن وب سایت مربوطه استفاده می کنند. نوشتن کد با استفاده از یک زبان برنامه نویسی در اصل چیزی به جز شکستن پروسه های پیچیده به گام های منطقی کوچک، نیست. البته ترجمه یک عملیات کوچک که برای انسان معنادار است به ترتیبی از دستورات که برای کامپیوتر قابل اجرا باشند، کاری است که نیاز به تجربه و مهارت فراوانی دارد و از طرف دیگر نوشتن کد مذکور به صورتی که امن و قابل اعتماد باشد، نیز کاری به مراتب دشوارتر است. زمانی که تعداد زیادی طراح و برنامه نویس به صورت موازی بر روی یک برنامه کاربردی کار می کنند، به احتمال بسیار زیاد مشکلات امنیتی متعددی بروز خواهند کرد. حتی در ساده ترین برنامه های تحت وب نیز منطق گسترده ای در هر گام برنامه وجود دارد و این امر منجر به ایجاد سطح حمله ای می شود که اغلب از آن چشم پوشی می گردد. بسیاری از تست نفوذها و مرور کدها بر روی آسیب پذیری های اصلی همچون تزریق SQL و یا cross-site-scripting تمرکز می کنند، زیرا آسیب پذیری های مذکور دارای امضای قابل تشخیص بوده و در مورد بردارهای حمله آنها به اندازه کافی تحقیق شده و اطلاعات وجود دارد. در نقطه مقابل، شناسایی آسیب پذیری های موجود در منطق برنامه بسیار سخت است، زیرا هر نمونه آسیب پذیری ممکن است تنها یک بار و برای یک برنامه خاص اتفاق بیفتد که قابل تشخیص توسط ابزارهای اتوماتیک شناسایی آسیب پذیری ها نیست. به همین دلیل به آسیب پذیری های مذکور چندان توجه نشده و این امر موجب می شود علاقه هکرها به شدت جلب این دسته از نقص های امنیتی شود.
در این مقاله در مورد انواع نقص های منطقی که اغلب در برنامه های کاربردی تحت وب وجود دارند، صحبت خواهیم کرد.
  • مدیرکل