SeerLight tərəfindən
İstənilən xidmətin qurulması mütləq təhlükəsizlik üzrə daimi işi əhatə edir. Təhlükəsizlik məhsul təhlükəsizliyinin daimi təhlili və təkmilləşdirilməsi, zəifliklər haqqında xəbərlərin monitorinqi və daha çox şeyləri əhatə edən davamlı bir prosesdir. Auditlər də daxil olmaqla. Auditlər həm şirkət daxilində, həm də kənar ekspertlər tərəfindən həyata keçirilir, onlar layihəyə batırılmadıqları və açıq düşüncəyə malik olduqları üçün təhlükəsizliyə köklü şəkildə kömək edə bilərlər.
Məqalə Mail.ru Cloud Solutions (MCS) komandasına bulud xidmətini sınaqdan keçirməyə kömək edən xarici ekspertlərin bu ən sadə baxışı və onların tapdıqları haqqındadır. MCS “xarici qüvvə” olaraq informasiya təhlükəsizliyi dairələrində yüksək təcrübəsi ilə tanınan Digital Security şirkətini seçdi. Və bu məqalədə biz xarici auditin bir hissəsi kimi aşkar edilmiş bəzi maraqlı boşluqları təhlil edəcəyik - beləliklə, siz öz bulud xidmətinizi yaratdığınız zaman eyni dırmıqdan qaçasınız.
Описание продукта
buludda virtual infrastrukturun qurulması üçün platformadır. Buraya IaaS, PaaS və tərtibatçılar üçün hazır tətbiq şəkilləri bazarı daxildir. MCS arxitekturasını nəzərə alaraq məhsulun təhlükəsizliyini aşağıdakı sahələrdə yoxlamaq lazım idi:
- virtualizasiya mühitinin infrastrukturunun qorunması: hipervizorlar, marşrutlaşdırma, firewalllar;
- müştərilərin virtual infrastrukturunun qorunması: bir-birindən, o cümlədən şəbəkə, SDN-də özəl şəbəkələr;
- OpenStack və onun açıq komponentləri;
- Öz dizaynımız olan S3;
- IAM: rol modeli olan çox kirayəçi layihələr;
- Vision (kompüter görmə): API-lər və şəkillərlə işləyərkən zəifliklər;
- veb interfeysi və klassik veb hücumları;
- PaaS komponentlərinin zəiflikləri;
- bütün komponentlərin API.
Bəlkə də gələcək tarix üçün vacib olan budur.
Hansı iş görüldü və nə üçün lazım idi?
Təhlükəsizlik auditi şəxsi məlumatların sızmasına, həssas məlumatların dəyişdirilməsinə və ya xidmətin əlçatanlığının pozulmasına səbəb ola biləcək zəiflikləri və konfiqurasiya xətalarını müəyyən etməyə yönəlib.
Orta hesabla 1-2 ay davam edən iş zamanı auditorlar potensial hücumçuların hərəkətlərini təkrarlayır və seçilmiş xidmətin müştəri və server hissələrində boşluqlar axtarırlar. MCS bulud platformasının auditi kontekstində aşağıdakı məqsədlər müəyyən edilmişdir:
- Xidmətdə autentifikasiyanın təhlili. Bu komponentdəki boşluqlar dərhal digər insanların hesablarına daxil olmağa kömək edəcəkdir.
- Rol modelinin öyrənilməsi və müxtəlif hesablar arasında giriş nəzarəti. Təcavüzkar üçün başqasının virtual maşınına giriş əldə etmək arzu olunan məqsəddir.
- Müştəri tərəfində zəifliklər. XSS/CSRF/CRLF/s. Zərərli linklər vasitəsilə digər istifadəçilərə hücum etmək mümkündürmü?
- Server tərəfində zəifliklər: RCE və bütün növ inyeksiyalar (SQL/XXE/SSRF və s.). Server zəifliklərini tapmaq ümumiyyətlə daha çətindir, lakin onlar eyni anda bir çox istifadəçinin güzəştə getməsinə səbəb olur.
- Şəbəkə səviyyəsində istifadəçi seqmentinin izolyasiyasının təhlili. Təcavüzkar üçün izolyasiyanın olmaması digər istifadəçilərə qarşı hücum səthini xeyli artırır.
- Biznes məntiqi təhlili. Müəssisələri aldatmaq və pulsuz virtual maşın yaratmaq mümkündürmü?
Bu layihədə iş “Gray-box” modelinə uyğun aparılıb: auditorlar xidmətlə adi istifadəçilərin imtiyazları ilə qarşılıqlı əlaqədə olublar, lakin qismən API-nin mənbə koduna malik olublar və tərtibatçılarla detalları dəqiqləşdirmək imkanı əldə ediblər. Bu, adətən ən əlverişli və eyni zamanda olduqca real iş modelidir: daxili məlumat hələ də təcavüzkar tərəfindən toplana bilər, bu, yalnız vaxt məsələsidir.
Zəifliklər tapıldı
Auditor müxtəlif faydalı yükləri (hücumun həyata keçirilməsi üçün istifadə olunan faydalı yükü) təsadüfi yerlərə göndərməyə başlamazdan əvvəl işlərin necə işlədiyini və hansı funksionallığın təmin olunduğunu anlamaq lazımdır. Bu, faydasız bir məşq kimi görünə bilər, çünki öyrənilən yerlərin əksəriyyətində heç bir zəiflik olmayacaqdır. Ancaq yalnız tətbiqin strukturunu və onun işinin məntiqini başa düşmək ən mürəkkəb hücum vektorlarını tapmağa imkan verəcəkdir.
Şübhəli görünən və ya müəyyən mənada digərlərindən çox fərqli olan yerləri tapmaq vacibdir. Və ilk təhlükəli zəiflik bu şəkildə tapıldı.
IDOR
IDOR (Təhlükəsiz Birbaşa Obyekt Referansı) zəiflikləri biznes məntiqində ən çox yayılmış boşluqlardan biridir və bu və ya digərinə girişə faktiki icazə verilməyən obyektlərə giriş əldə etməyə imkan verir. IDOR zəiflikləri müxtəlif dərəcədə kritik olan istifadəçi haqqında məlumat əldə etmək imkanı yaradır.
IDOR variantlarından biri sistem obyektləri (istifadəçilər, bank hesabları, alış-veriş səbətindəki əşyalar) ilə bu obyektlərə giriş identifikatorlarını manipulyasiya etməklə hərəkətləri yerinə yetirməkdir. Bu, ən gözlənilməz nəticələrə gətirib çıxarır. Məsələn, digər istifadəçilərdən oğurlaya biləcəyiniz pul göndərənin hesabını dəyişdirmək imkanı.
MCS vəziyyətində auditorlar indicə təhlükəsiz olmayan identifikatorlarla əlaqəli IDOR zəifliyini aşkar etdilər. İstifadəçinin şəxsi hesabında UUID identifikatorlarından, təhlükəsizlik mütəxəssislərinin dediyi kimi, təsirli dərəcədə etibarsız görünən (yəni kobud güc hücumlarından qorunan) hər hansı obyektlərə daxil olmaq üçün istifadə olunurdu. Ancaq müəyyən qurumlar üçün tətbiqin istifadəçiləri haqqında məlumat əldə etmək üçün müntəzəm proqnozlaşdırıla bilən nömrələrdən istifadə edildiyi aşkar edildi. Hesab edirəm ki, istifadəçi identifikatorunu bir dəfə dəyişmək, sorğunu yenidən göndərmək və bununla da ACL-dən (giriş nəzarəti siyahısı, proseslər və istifadəçilər üçün məlumat əldə etmək qaydaları) yan keçməklə məlumat əldə etmək mümkün olduğunu təxmin edə bilərsiniz.
Server tərəfində sorğu saxtakarlığı (SSRF)
OpenSource məhsullarının yaxşı tərəfi ondadır ki, onlar yaranan problemlərin ətraflı texniki təsviri və şanslısınızsa, həll yolunun təsviri olan çoxlu sayda foruma malikdirlər. Lakin bu sikkənin əks tərəfi var: məlum zəifliklər də ətraflı təsvir edilmişdir. Məsələn, OpenStack forumunda zəifliklərin gözəl təsvirləri var и , nədənsə heç kim düzəltməyə tələsmir.
Tətbiqlərin ümumi funksionallığı istifadəçinin serverin kliklədiyi serverə keçid göndərmək imkanıdır (məsələn, müəyyən mənbədən şəkil yükləmək). Təhlükəsizlik alətləri keçidlərin özlərini və ya serverdən istifadəçilərə qaytarılan cavabları filtrləmirsə, bu cür funksionallıq təcavüzkarlar tərəfindən asanlıqla istifadə edilə bilər.
SSRF zəiflikləri hücumun inkişafını əhəmiyyətli dərəcədə inkişaf etdirə bilər. Təcavüzkar əldə edə bilər:
- hücuma məruz qalan yerli şəbəkəyə məhdud giriş, məsələn, yalnız müəyyən şəbəkə seqmentləri vasitəsilə və müəyyən protokoldan istifadə etməklə;
- tətbiq səviyyəsindən nəqliyyat səviyyəsinə endirmə mümkün olarsa və nəticədə tətbiq səviyyəsində tam yükün idarə edilməsi mümkün olarsa, yerli şəbəkəyə tam çıxış;
- serverdə yerli faylları oxumaq imkanı (fayl: /// sxemi dəstəklənirsə);
- və daha çox.
OpenStack-də SSRF zəifliyi çoxdan məlumdur ki, bu da təbiətcə “kor”dur: serverlə əlaqə saxladığınız zaman siz ondan cavab almırsınız, lakin sorğunun nəticəsindən asılı olaraq müxtəlif növ xətalar/gecikmələr alırsınız. . Buna əsaslanaraq, daxili şəbəkədəki hostlarda bir port skanını həyata keçirə bilərsiniz, bundan sonra da qiymətləndirilməməsi lazım olan bütün nəticələr. Məsələn, məhsulun yalnız korporativ şəbəkədən əldə edilə bilən back-ofis API-si ola bilər. Sənədlərlə (insayderlər haqqında unutmayın) təcavüzkar daxili metodlara daxil olmaq üçün SSRF-dən istifadə edə bilər. Məsələn, bir şəkildə faydalı URL-lərin təxmini siyahısını əldə edə bilsəniz, SSRF-dən istifadə edərək onlardan keçib sorğunu yerinə yetirə bilərsiniz - nisbətən desək, hesabdan hesaba pul köçürə və ya limitləri dəyişdirə bilərsiniz.
Bu, OpenStack-də SSRF boşluğunun ilk aşkarlanması deyil. Əvvəllər VM ISO şəkillərini birbaşa keçiddən yükləmək mümkün idi ki, bu da oxşar nəticələrə səbəb olurdu. Bu funksiya indi OpenStack-dən silinib. Görünür, camaat bunu problemin ən sadə və etibarlı həlli hesab edirdi.
Və HackerOne xidmətinin (h1) ictimaiyyətə açıq hesabatı, nümunə metadatasını oxumaq imkanı ilə artıq kor olmayan SSRF-nin istismarı bütün Shopify infrastrukturuna Kök girişinə səbəb olur.
MCS-də SSRF boşluqları oxşar funksionallığı olan iki yerdə aşkar edildi, lakin firewall və digər qorunma vasitələrinə görə onlardan istifadə etmək demək olar ki, mümkün deyildi. Bu və ya digər şəkildə MCS komandası cəmiyyəti gözləmədən hər halda bu problemi həll etdi.
Qabıqları yükləmək əvəzinə XSS
Yazılan yüzlərlə araşdırmaya baxmayaraq, ildən-ilə XSS (saytlar arası skript) hücumu hələ də ən çox yayılmışdır veb zəifliyi (və ya ?).
Fayl yükləmələri hər hansı bir təhlükəsizlik tədqiqatçısı üçün sevimli yerdir. Tez-tez belə çıxır ki, ixtiyari bir skript (asp/jsp/php) yükləyə və OS əmrlərini, pentesters terminologiyasında - “yük qabığını” yerinə yetirə bilərsiniz. Ancaq bu cür zəifliklərin populyarlığı hər iki istiqamətdə işləyir: insanlar onları xatırlayır və onlara qarşı vasitələr hazırlayırlar ki, son vaxtlar "mərmi yükləmək" ehtimalı sıfıra enir.
Hücum edən komandanın (Digital Security ilə təmsil olunur) bəxti gətirdi. OK, server tərəfindəki MCS-də yüklənmiş faylların məzmunu yoxlanıldı, yalnız şəkillərə icazə verildi. Lakin SVG də bir şəkildir. SVG şəkilləri necə təhlükəli ola bilər? Çünki siz onlara JavaScript fraqmentlərini yerləşdirə bilərsiniz!
Məlum olub ki, yüklənmiş fayllar MCS xidmətinin bütün istifadəçiləri üçün əlçatandır və bu o deməkdir ki, digər bulud istifadəçilərinə, yəni administratorlara hücum etmək mümkündür.
Fişinq giriş formasına XSS hücumunun nümunəsi
XSS hücum istismarı nümunələri:
- Yüklənmiş skript dərhal API resursuna daxil ola bilirsə, niyə sessiyanı oğurlamağa çalışmalısınız (xüsusilə indi JS skriptlərindən istifadə edərək oğurluqdan qorunan HTTP-Yalnız kukilər hər yerdədir)? Bu halda, faydalı yük server konfiqurasiyasını dəyişdirmək üçün XHR sorğularından istifadə edə bilər, məsələn, təcavüzkarın ictimai SSH açarını əlavə edə və serverə SSH girişini əldə edə bilər.
- Əgər CSP siyasəti (məzmun mühafizəsi siyasəti) JavaScript-in yeridilməsini qadağan edirsə, təcavüzkar onsuz da keçə bilər. Saf HTML istifadə edərək, sayt üçün saxta giriş forması yaradın və bu qabaqcıl fişinq vasitəsilə administratorun parolunu oğurlayın: istifadəçi üçün fişinq səhifəsi eyni URL-də bitir və istifadəçi üçün onu aşkar etmək daha çətindir.
- Nəhayət, təcavüzkar təşkil edə bilər — 4 KB-dən böyük kukilər təyin edin. İstifadəçi yalnız bir dəfə linki açmalıdır və istifadəçi brauzeri xüsusi olaraq təmizləməyi düşünənə qədər bütün sayt əlçatmaz olur: əksər hallarda veb server belə bir müştərini qəbul etməkdən imtina edəcək.
Gəlin bu dəfə daha ağıllı bir istismarla aşkar edilmiş başqa bir XSS nümunəsinə baxaq. MCS xidməti sizə firewall parametrlərini qruplara birləşdirməyə imkan verir. Qrup adı XSS-nin aşkar edildiyi yer idi. Onun özəlliyi onda idi ki, vektor qaydalar siyahısına baxarkən deyil, qrupu silərkən dərhal işə salınmadı:
Yəni ssenari belə çıxdı: təcavüzkar adında “yük” olan bir firewall qaydası yaradır, administrator bir müddət sonra bunu fərq edir və silmə prosesinə başlayır. Və burada zərərli JS işləyir.
MCS tərtibatçıları üçün endirilmiş SVG şəkillərində XSS-dən qorunmaq üçün (əgər onları tərk etmək mümkün deyilsə) Rəqəmsal Təhlükəsizlik komandası tövsiyə edir:
- İstifadəçilər tərəfindən yüklənmiş faylları “kukilər”lə heç bir əlaqəsi olmayan ayrıca domenə yerləşdirin. Skript fərqli domen kontekstində icra olunacaq və MCS üçün təhlükə yaratmayacaq.
- Serverin HTTP cavabında "Content-disposition: attachment" başlığını göndərin. Sonra fayllar brauzer tərəfindən yüklənəcək və icra olunmayacaq.
Bundan əlavə, indi tərtibatçılar üçün XSS istismarının risklərini azaltmaq üçün bir çox yollar mövcuddur:
- "Yalnız HTTP" bayrağından istifadə edərək, "Cookies" seansının başlıqlarını zərərli JavaScript üçün əlçatmaz edə bilərsiniz;
- təcavüzkarın XSS-dən istifadə etməsini xeyli çətinləşdirəcək;
- Angular və ya React kimi müasir şablon mühərrikləri istifadəçi məlumatlarını istifadəçinin brauzerinə çıxarmazdan əvvəl avtomatik olaraq təmizləyir.
İki faktorlu autentifikasiya zəiflikləri
Hesab təhlükəsizliyini yaxşılaşdırmaq üçün istifadəçilərə həmişə 2FA (iki faktorlu autentifikasiya) aktivləşdirmələri tövsiyə olunur. Həqiqətən, bu, istifadəçinin etimadnaməsi pozulubsa, təcavüzkarın xidmətə girişinin qarşısını almaq üçün effektiv üsuldur.
Ancaq ikinci autentifikasiya faktorundan istifadə həmişə hesabın təhlükəsizliyinə zəmanət verirmi? 2FA-nın həyata keçirilməsində aşağıdakı təhlükəsizlik problemləri mövcuddur:
- OTP kodunun kobud axtarışı (birdəfəlik kodlar). Əməliyyatın sadəliyinə baxmayaraq, OTP kobud gücdən qorunma kimi səhvlərə böyük şirkətlər də rast gəlir: , .
- Zəif nəsil alqoritmi, məsələn, növbəti kodu proqnozlaşdırmaq imkanı.
- Bu kimi məntiqi səhvlər, məsələn, telefonunuzda başqasının OTP-sini tələb etmək imkanı Shopify-dan.
MCS vəziyyətində, 2FA Google Authenticator və əsasında həyata keçirilir . Protokolun özü artıq vaxt sınağından keçmişdir, lakin proqram tərəfində kod yoxlamasının həyata keçirilməsini yoxlamağa dəyər.
MCS 2FA bir neçə yerdə istifadə olunur:
- İstifadəçinin autentifikasiyası zamanı. Kobud gücdən qorunma var: istifadəçi yalnız birdəfəlik parol daxil etmək üçün bir neçə cəhd edir, sonra giriş bir müddət bloklanır. Bu, OTP-nin brute-force seçimi imkanını əngəlləyir.
- 2FA yerinə yetirmək üçün oflayn ehtiyat nüsxə kodları yaradarkən, həmçinin onu söndürərkən. Burada heç bir kobud gücdən qorunma həyata keçirilmədi ki, bu da hesab üçün parolunuz və aktiv seansınız varsa, ehtiyat kodlarını bərpa etməyə və ya 2FA-nı tamamilə söndürməyə imkan verdi.
Ehtiyat kodlarının OTP tətbiqi tərəfindən yaradılanlarla eyni sətir dəyərlərində yerləşdiyini nəzərə alsaq, kodu qısa müddətdə tapmaq şansı daha yüksək idi.
“Burp: Intruder” alətindən istifadə edərək 2FA-nı söndürmək üçün OTP seçmə prosesi
Nəticə
Ümumiyyətlə, MCS bir məhsul kimi təhlükəsiz görünür. Audit zamanı pentestinq qrupu müştəri VM-lərinə və onların məlumatlarına giriş əldə edə bilmədi və aşkar edilmiş boşluqlar MCS komandası tərəfindən tez bir zamanda düzəldildi.
Amma burada qeyd etmək lazımdır ki, təhlükəsizlik davamlı işdir. Xidmətlər statik deyil, onlar daim inkişaf edir. Və zəifliklər olmadan məhsulu tamamilə inkişaf etdirmək mümkün deyil. Ancaq onları vaxtında tapa bilərsiniz və onların təkrarlanma şansını minimuma endirə bilərsiniz.
İndi MCS-də qeyd olunan bütün zəifliklər artıq aradan qaldırılıb. Yenilərin sayını minimuma endirmək və onların ömrünü azaltmaq üçün platforma komandası bunu davam etdirir:
- mütəmadi olaraq kənar şirkətlər tərəfindən auditlər aparmaq;
- iştirakını dəstəkləmək və inkişaf etdirmək;
- təhlükəsizliklə məşğul olmaq. 🙂
Mənbə: www.habr.com