MCS ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ സുരക്ഷാ ഓഡിറ്റ്

സ്കൈഷിപ്പ് സന്ധ്യ സീർലൈറ്റ് വഴി

ഏതൊരു സേവനവും കെട്ടിപ്പടുക്കുന്നതിൽ സുരക്ഷയെക്കുറിച്ചുള്ള നിരന്തരമായ പ്രവർത്തനം ഉൾപ്പെടുന്നു. ഉൽപ്പന്ന സുരക്ഷയുടെ നിരന്തരമായ വിശകലനവും മെച്ചപ്പെടുത്തലും, കേടുപാടുകൾ സംബന്ധിച്ച വാർത്തകളുടെ നിരീക്ഷണവും മറ്റും ഉൾപ്പെടുന്ന ഒരു തുടർച്ചയായ പ്രക്രിയയാണ് സുരക്ഷ. ഓഡിറ്റുകൾ ഉൾപ്പെടെ. പ്രോജക്റ്റിൽ മുഴുകിയിട്ടില്ലാത്തതിനാലും തുറന്ന മനസ്സുള്ളവരായതിനാലും സുരക്ഷിതത്വത്തെ സമൂലമായി സഹായിക്കാൻ കഴിയുന്ന, വീടിനകത്തും പുറത്തുമുള്ള വിദഗ്ധർ മുഖേനയാണ് ഓഡിറ്റുകൾ നടത്തുന്നത്.

ക്ലൗഡ് സേവനം പരീക്ഷിക്കാൻ Mail.ru ക്ലൗഡ് സൊല്യൂഷൻസ് (എംസിഎസ്) ടീമിനെ സഹായിച്ച ബാഹ്യ വിദഗ്ധരുടെ ഏറ്റവും നേരായ കാഴ്ചയെ കുറിച്ചും അവർ കണ്ടെത്തിയതിനെ കുറിച്ചുമാണ് ലേഖനം. ഒരു "ബാഹ്യ ശക്തി" എന്ന നിലയിൽ, വിവര സുരക്ഷാ സർക്കിളുകളിൽ ഉയർന്ന വൈദഗ്ധ്യത്തിന് പേരുകേട്ട ഡിജിറ്റൽ സെക്യൂരിറ്റി കമ്പനിയെ MCS തിരഞ്ഞെടുത്തു. ഈ ലേഖനത്തിൽ, ഒരു ബാഹ്യ ഓഡിറ്റിന്റെ ഭാഗമായി കണ്ടെത്തിയ ചില രസകരമായ കേടുപാടുകൾ ഞങ്ങൾ വിശകലനം ചെയ്യും - അതുവഴി നിങ്ങൾ നിങ്ങളുടെ സ്വന്തം ക്ലൗഡ് സേവനം സൃഷ്ടിക്കുമ്പോൾ അതേ റേക്ക് ഒഴിവാക്കും.

Описание продукта

Mail.ru ക്ലൗഡ് സൊല്യൂഷൻസ് (MCS) ക്ലൗഡിൽ വെർച്വൽ ഇൻഫ്രാസ്ട്രക്ചർ നിർമ്മിക്കുന്നതിനുള്ള ഒരു പ്ലാറ്റ്ഫോമാണ്. ഇതിൽ IaaS, PaaS, ഡെവലപ്പർമാർക്കുള്ള റെഡിമെയ്ഡ് ആപ്ലിക്കേഷൻ ഇമേജുകളുടെ ഒരു മാർക്കറ്റ് എന്നിവ ഉൾപ്പെടുന്നു. MCS ആർക്കിടെക്ചർ കണക്കിലെടുക്കുമ്പോൾ, ഇനിപ്പറയുന്ന മേഖലകളിൽ ഉൽപ്പന്നത്തിന്റെ സുരക്ഷ പരിശോധിക്കേണ്ടത് ആവശ്യമാണ്:

• വിർച്ച്വലൈസേഷൻ പരിതസ്ഥിതിയുടെ ഇൻഫ്രാസ്ട്രക്ചർ സംരക്ഷിക്കുന്നു: ഹൈപ്പർവൈസറുകൾ, റൂട്ടിംഗ്, ഫയർവാളുകൾ;
• ഉപഭോക്താക്കളുടെ വെർച്വൽ ഇൻഫ്രാസ്ട്രക്ചറിന്റെ സംരക്ഷണം: നെറ്റ്‌വർക്ക് ഉൾപ്പെടെ, SDN-ലെ സ്വകാര്യ നെറ്റ്‌വർക്കുകൾ ഉൾപ്പെടെ പരസ്പരം ഒറ്റപ്പെടൽ;
• ഓപ്പൺസ്റ്റാക്കും അതിന്റെ തുറന്ന ഘടകങ്ങളും;
• ഞങ്ങളുടെ സ്വന്തം രൂപകൽപ്പനയുടെ S3;
• IAM: ഒരു റോൾ മോഡലുള്ള മൾട്ടി-ടെനന്റ് പ്രോജക്റ്റുകൾ;
• വിഷൻ (കമ്പ്യൂട്ടർ വിഷൻ): ചിത്രങ്ങളുമായി പ്രവർത്തിക്കുമ്പോൾ എപിഐകളും കേടുപാടുകളും;
• വെബ് ഇന്റർഫേസും ക്ലാസിക് വെബ് ആക്രമണങ്ങളും;
• PaaS ഘടകങ്ങളുടെ കേടുപാടുകൾ;
• എല്ലാ ഘടകങ്ങളുടെയും API.

ഒരുപക്ഷെ, ഇനിയുള്ള ചരിത്രത്തിന് അത് അനിവാര്യമാണ്.

ഏത് തരത്തിലുള്ള ജോലിയാണ് നടത്തിയത്, എന്തുകൊണ്ട് അത് ആവശ്യമായിരുന്നു?

വ്യക്തിഗത ഡാറ്റയുടെ ചോർച്ച, സെൻസിറ്റീവ് വിവരങ്ങളുടെ പരിഷ്ക്കരണം അല്ലെങ്കിൽ സേവന ലഭ്യത തടസ്സപ്പെടുത്തൽ എന്നിവയിലേക്ക് നയിച്ചേക്കാവുന്ന കേടുപാടുകളും കോൺഫിഗറേഷൻ പിശകുകളും തിരിച്ചറിയുന്നതിനാണ് സുരക്ഷാ ഓഡിറ്റ് ലക്ഷ്യമിടുന്നത്.

ശരാശരി 1-2 മാസം നീണ്ടുനിൽക്കുന്ന ജോലി സമയത്ത്, ഓഡിറ്റർമാർ സാധ്യതയുള്ള ആക്രമണകാരികളുടെ പ്രവർത്തനങ്ങൾ ആവർത്തിക്കുകയും തിരഞ്ഞെടുത്ത സേവനത്തിന്റെ ക്ലയന്റിലും സെർവർ ഭാഗങ്ങളിലും കേടുപാടുകൾ കണ്ടെത്തുകയും ചെയ്യുന്നു. MCS ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിന്റെ ഓഡിറ്റിന്റെ പശ്ചാത്തലത്തിൽ, ഇനിപ്പറയുന്ന ലക്ഷ്യങ്ങൾ തിരിച്ചറിഞ്ഞു:

1. സേവനത്തിലെ പ്രാമാണീകരണത്തിന്റെ വിശകലനം. ഈ ഘടകത്തിലെ കേടുപാടുകൾ മറ്റുള്ളവരുടെ അക്കൗണ്ടുകളിലേക്ക് ഉടനടി എത്താൻ സഹായിക്കും.
2. വ്യത്യസ്ത അക്കൗണ്ടുകൾ തമ്മിലുള്ള റോൾ മോഡലും ആക്സസ് നിയന്ത്രണവും പഠിക്കുന്നു. ഒരു ആക്രമണകാരിക്ക്, മറ്റൊരാളുടെ വെർച്വൽ മെഷീനിലേക്ക് പ്രവേശനം നേടാനുള്ള കഴിവ് അഭിലഷണീയമായ ഒരു ലക്ഷ്യമാണ്.
3. ഉപഭോക്തൃ വശത്തെ കേടുപാടുകൾ. XSS/CSRF/CRLF/ etc. ക്ഷുദ്ര ലിങ്കുകൾ വഴി മറ്റ് ഉപയോക്താക്കളെ ആക്രമിക്കാൻ കഴിയുമോ?
4. സെർവർ സൈഡ് കേടുപാടുകൾ: RCE കൂടാതെ എല്ലാത്തരം കുത്തിവയ്പ്പുകളും (SQL/XXE/SSRF മുതലായവ). സെർവർ കേടുപാടുകൾ കണ്ടെത്താൻ പൊതുവെ ബുദ്ധിമുട്ടാണ്, എന്നാൽ അവ ഒരേസമയം നിരവധി ഉപയോക്താക്കളുടെ വിട്ടുവീഴ്ചയിലേക്ക് നയിക്കുന്നു.
5. നെറ്റ്‌വർക്ക് തലത്തിൽ ഉപയോക്തൃ സെഗ്‌മെന്റ് ഒറ്റപ്പെടലിന്റെ വിശകലനം. ഒരു ആക്രമണകാരിയെ സംബന്ധിച്ചിടത്തോളം, ഒറ്റപ്പെടലിന്റെ അഭാവം മറ്റ് ഉപയോക്താക്കൾക്കെതിരായ ആക്രമണ പ്രതലത്തെ വളരെയധികം വർദ്ധിപ്പിക്കുന്നു.
6. ബിസിനസ് ലോജിക് വിശകലനം. ബിസിനസ്സുകളെ കബളിപ്പിച്ച് സൗജന്യമായി വെർച്വൽ മെഷീനുകൾ സൃഷ്ടിക്കാൻ കഴിയുമോ?

ഈ പ്രോജക്റ്റിൽ, "ഗ്രേ-ബോക്സ്" മോഡൽ അനുസരിച്ചാണ് പ്രവർത്തനം നടത്തിയത്: ഓഡിറ്റർമാർ സാധാരണ ഉപയോക്താക്കളുടെ പ്രത്യേകാവകാശങ്ങളുമായി സേവനവുമായി ഇടപഴകിയിരുന്നു, എന്നാൽ ഭാഗികമായി API- യുടെ സോഴ്സ് കോഡ് കൈവശം വയ്ക്കുകയും ഡവലപ്പർമാരുമായി വിശദാംശങ്ങൾ വ്യക്തമാക്കാനുള്ള അവസരം ലഭിക്കുകയും ചെയ്തു. ഇത് സാധാരണയായി ഏറ്റവും സൗകര്യപ്രദവും അതേ സമയം തികച്ചും യാഥാർത്ഥ്യബോധമുള്ളതുമായ പ്രവർത്തന മാതൃകയാണ്: ആന്തരിക വിവരങ്ങൾ ഇപ്പോഴും ആക്രമണകാരിക്ക് ശേഖരിക്കാൻ കഴിയും, ഇത് സമയത്തിന്റെ കാര്യം മാത്രമാണ്.

കേടുപാടുകൾ കണ്ടെത്തി

ഓഡിറ്റർ വിവിധ പേലോഡുകൾ (ആക്രമണം നടത്താൻ ഉപയോഗിക്കുന്ന പേലോഡ്) ക്രമരഹിതമായ സ്ഥലങ്ങളിലേക്ക് അയയ്‌ക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ്, കാര്യങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ഏത് പ്രവർത്തനമാണ് നൽകിയതെന്നും മനസ്സിലാക്കേണ്ടത് ആവശ്യമാണ്. ഇത് ഉപയോഗശൂന്യമായ ഒരു വ്യായാമമാണെന്ന് തോന്നിയേക്കാം, കാരണം പഠിച്ച മിക്ക സ്ഥലങ്ങളിലും കേടുപാടുകൾ ഉണ്ടാകില്ല. എന്നാൽ ആപ്ലിക്കേഷന്റെ ഘടനയും അതിന്റെ പ്രവർത്തനത്തിന്റെ യുക്തിയും മനസ്സിലാക്കിയാൽ മാത്രമേ ഏറ്റവും സങ്കീർണ്ണമായ ആക്രമണ വെക്റ്ററുകൾ കണ്ടെത്താൻ സാധിക്കൂ.

സംശയാസ്പദമായി തോന്നുന്നതോ ഏതെങ്കിലും വിധത്തിൽ മറ്റുള്ളവരിൽ നിന്ന് വളരെ വ്യത്യസ്തമായതോ ആയ സ്ഥലങ്ങൾ കണ്ടെത്തേണ്ടത് പ്രധാനമാണ്. ആദ്യത്തെ അപകടകരമായ ദുർബലത ഈ രീതിയിൽ കണ്ടെത്തി.

IDOR

IDOR (ഇൻസെക്യുർ ഡയറക്ട് ഒബ്‌ജക്റ്റ് റഫറൻസ്) കേടുപാടുകൾ ബിസിനസ്സ് ലോജിക്കിലെ ഏറ്റവും സാധാരണമായ കേടുപാടുകളിലൊന്നാണ്, ഇത് ആക്‌സസ്സ് യഥാർത്ഥത്തിൽ അനുവദനീയമല്ലാത്ത ഒബ്‌ജക്റ്റുകളിലേക്ക് ആക്‌സസ് നേടാൻ ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരാളെ അനുവദിക്കുന്നു. IDOR കേടുപാടുകൾ ഒരു ഉപയോക്താവിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ നേടാനുള്ള സാധ്യത സൃഷ്ടിക്കുന്നു.

ഈ ഒബ്‌ജക്‌സുകളിലേക്കുള്ള ആക്‌സസ് ഐഡന്റിഫയറുകൾ കൃത്രിമമായി ഉപയോഗിച്ച് സിസ്റ്റം ഒബ്‌ജക്‌റ്റുകൾ (ഉപയോക്താക്കൾ, ബാങ്ക് അക്കൗണ്ടുകൾ, ഷോപ്പിംഗ് കാർട്ടിലെ ഇനങ്ങൾ) ഉപയോഗിച്ച് പ്രവർത്തനങ്ങൾ നടത്തുക എന്നതാണ് IDOR ഓപ്ഷനുകളിലൊന്ന്. ഇത് ഏറ്റവും പ്രവചനാതീതമായ പ്രത്യാഘാതങ്ങളിലേക്ക് നയിക്കുന്നു. ഉദാഹരണത്തിന്, ഫണ്ടുകൾ അയച്ചയാളുടെ അക്കൗണ്ട് മാറ്റിസ്ഥാപിക്കാനുള്ള സാധ്യത, അതിലൂടെ നിങ്ങൾക്ക് മറ്റ് ഉപയോക്താക്കളിൽ നിന്ന് അവ മോഷ്ടിക്കാൻ കഴിയും.

MCS-ന്റെ കാര്യത്തിൽ, സുരക്ഷിതമല്ലാത്ത ഐഡന്റിഫയറുകളുമായി ബന്ധപ്പെട്ട ഒരു IDOR കേടുപാടുകൾ ഓഡിറ്റർമാർ ഇപ്പോൾ കണ്ടെത്തി. ഉപയോക്താവിന്റെ സ്വകാര്യ അക്കൗണ്ടിൽ, UUID ഐഡന്റിഫയറുകൾ ഏതെങ്കിലും ഒബ്‌ജക്‌റ്റുകൾ ആക്‌സസ് ചെയ്യാൻ ഉപയോഗിച്ചു, അത് സുരക്ഷാ വിദഗ്ധർ പറയുന്നതുപോലെ, വളരെ സുരക്ഷിതമല്ല (അതായത്, ബ്രൂട്ട് ഫോഴ്‌സ് ആക്രമണങ്ങളിൽ നിന്ന് സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു). എന്നാൽ ചില പ്രത്യേക സ്ഥാപനങ്ങൾക്ക്, ആപ്ലിക്കേഷന്റെ ഉപയോക്താക്കളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുന്നതിന് സാധാരണ പ്രവചിക്കാവുന്ന സംഖ്യകൾ ഉപയോഗിക്കുന്നതായി കണ്ടെത്തി. ഉപയോക്തൃ ഐഡി ഒന്നായി മാറ്റാനും അഭ്യർത്ഥന വീണ്ടും അയയ്‌ക്കാനും അങ്ങനെ ACL (ആക്‌സസ് കൺട്രോൾ ലിസ്റ്റ്, പ്രോസസ്സുകൾക്കും ഉപയോക്താക്കൾക്കുമുള്ള ഡാറ്റ ആക്‌സസ്സ് നിയമങ്ങൾ) മറികടന്ന് വിവരങ്ങൾ നേടാനും കഴിയുമെന്ന് നിങ്ങൾക്ക് ഊഹിക്കാൻ കഴിയുമെന്ന് ഞാൻ കരുതുന്നു.

സെർവർ സൈഡ് അഭ്യർത്ഥന വ്യാജം (SSRF)

ഓപ്പൺസോഴ്സ് ഉൽപ്പന്നങ്ങളുടെ നല്ല കാര്യം, ഉയർന്നുവരുന്ന പ്രശ്നങ്ങളുടെ വിശദമായ സാങ്കേതിക വിവരണങ്ങളും നിങ്ങൾ ഭാഗ്യവാനാണെങ്കിൽ, പരിഹാരത്തിന്റെ വിവരണവും ഉള്ള ധാരാളം ഫോറങ്ങൾ ഉണ്ട് എന്നതാണ്. എന്നാൽ ഈ നാണയത്തിന് ഒരു മറുവശമുണ്ട്: അറിയപ്പെടുന്ന കേടുപാടുകൾ വിശദമായി വിവരിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, ഓപ്പൺസ്റ്റാക്ക് ഫോറത്തിൽ കേടുപാടുകളുടെ അതിശയകരമായ വിവരണങ്ങളുണ്ട് [XSS] и [എസ്എസ്ആർഎഫ്], ചില കാരണങ്ങളാൽ ആരും ശരിയാക്കാൻ തിടുക്കം കാട്ടുന്നില്ല.

സെർവറിലേക്ക് ഒരു ലിങ്ക് അയയ്‌ക്കാനുള്ള ഉപയോക്താവിനുള്ള കഴിവാണ് ആപ്ലിക്കേഷനുകളുടെ ഒരു പൊതു പ്രവർത്തനം, അതിൽ സെർവർ ക്ലിക്ക് ചെയ്യുന്നു (ഉദാഹരണത്തിന്, ഒരു നിർദ്ദിഷ്ട ഉറവിടത്തിൽ നിന്ന് ഒരു ചിത്രം ഡൗൺലോഡ് ചെയ്യാൻ). സുരക്ഷാ ഉപകരണങ്ങൾ ലിങ്കുകളോ സെർവറിൽ നിന്ന് ഉപയോക്താക്കൾക്ക് നൽകുന്ന പ്രതികരണങ്ങളോ ഫിൽട്ടർ ചെയ്യുന്നില്ലെങ്കിൽ, അത്തരം പ്രവർത്തനം ആക്രമണകാരികൾക്ക് എളുപ്പത്തിൽ ഉപയോഗിക്കാനാകും.

SSRF കേടുപാടുകൾ ഒരു ആക്രമണത്തിന്റെ വികാസത്തെ വളരെയധികം മുന്നോട്ട് കൊണ്ടുപോകും. ഒരു ആക്രമണകാരിക്ക് ലഭിക്കും:

• ആക്രമിക്കപ്പെട്ട പ്രാദേശിക നെറ്റ്‌വർക്കിലേക്കുള്ള പരിമിതമായ ആക്‌സസ്, ഉദാഹരണത്തിന്, ചില നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റുകളിലൂടെയും ഒരു പ്രത്യേക പ്രോട്ടോക്കോൾ ഉപയോഗിച്ചും മാത്രം;
• ആപ്ലിക്കേഷൻ ലെവലിൽ നിന്ന് ട്രാൻസ്പോർട്ട് ലെവലിലേക്ക് തരംതാഴ്ത്തുന്നത് സാധ്യമാണെങ്കിൽ ലോക്കൽ നെറ്റ്‌വർക്കിലേക്കുള്ള പൂർണ്ണ ആക്‌സസ്സ്, അതിന്റെ ഫലമായി, ആപ്ലിക്കേഷൻ തലത്തിൽ പൂർണ്ണ ലോഡ് മാനേജ്മെന്റ്;
• സെർവറിലെ പ്രാദേശിക ഫയലുകൾ വായിക്കുന്നതിനുള്ള ആക്സസ് (ഫയൽ:/// സ്കീം പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിൽ);
• ഒപ്പം അതിലും കൂടുതലും.

ഓപ്പൺസ്റ്റാക്കിൽ ഒരു SSRF കേടുപാടുകൾ വളരെക്കാലമായി അറിയപ്പെടുന്നു, അത് "അന്ധമായ" സ്വഭാവമാണ്: നിങ്ങൾ സെർവറുമായി ബന്ധപ്പെടുമ്പോൾ, അതിൽ നിന്ന് നിങ്ങൾക്ക് ഒരു പ്രതികരണം ലഭിക്കില്ല, എന്നാൽ അഭ്യർത്ഥനയുടെ ഫലത്തെ ആശ്രയിച്ച് നിങ്ങൾക്ക് വ്യത്യസ്ത തരത്തിലുള്ള പിശകുകൾ/കാലതാമസങ്ങൾ ലഭിക്കും. . ഇതിനെ അടിസ്ഥാനമാക്കി, ആന്തരിക നെറ്റ്‌വർക്കിലെ ഹോസ്റ്റുകളിൽ നിങ്ങൾക്ക് ഒരു പോർട്ട് സ്കാൻ നടത്താം, തുടർന്നുള്ള എല്ലാ അനന്തരഫലങ്ങളും കുറച്ചുകാണരുത്. ഉദാഹരണത്തിന്, ഒരു ഉൽപ്പന്നത്തിന് കോർപ്പറേറ്റ് നെറ്റ്‌വർക്കിൽ നിന്ന് മാത്രം ആക്‌സസ് ചെയ്യാനാകുന്ന ഒരു ബാക്ക്-ഓഫീസ് API ഉണ്ടായിരിക്കാം. ഡോക്യുമെന്റേഷൻ ഉപയോഗിച്ച് (ഇൻസൈഡർമാരെ കുറിച്ച് മറക്കരുത്), ഒരു ആക്രമണകാരിക്ക് ആന്തരിക രീതികൾ ആക്സസ് ചെയ്യാൻ SSRF ഉപയോഗിക്കാം. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് എങ്ങനെയെങ്കിലും ഉപയോഗപ്രദമായ URL-കളുടെ ഏകദേശ ലിസ്റ്റ് നേടാൻ കഴിഞ്ഞെങ്കിൽ, SSRF ഉപയോഗിച്ച് നിങ്ങൾക്ക് അവയിലൂടെ പോയി ഒരു അഭ്യർത്ഥന നടപ്പിലാക്കാം - താരതമ്യേന പറഞ്ഞാൽ, അക്കൗണ്ടിൽ നിന്ന് അക്കൗണ്ടിലേക്ക് പണം മാറ്റുകയോ പരിധികൾ മാറ്റുകയോ ചെയ്യുക.

OpenStack-ൽ SSRF കേടുപാടുകൾ കണ്ടെത്തുന്നത് ഇതാദ്യമല്ല. മുൻകാലങ്ങളിൽ, ഒരു നേരിട്ടുള്ള ലിങ്കിൽ നിന്ന് VM ISO ഇമേജുകൾ ഡൗൺലോഡ് ചെയ്യുന്നത് സാധ്യമായിരുന്നു, ഇത് സമാനമായ പ്രത്യാഘാതങ്ങൾക്ക് കാരണമായി. ഈ സവിശേഷത ഇപ്പോൾ OpenStack-ൽ നിന്ന് നീക്കം ചെയ്‌തു. പ്രത്യക്ഷത്തിൽ, പ്രശ്നത്തിനുള്ള ഏറ്റവും ലളിതവും വിശ്വസനീയവുമായ പരിഹാരമായി സമൂഹം ഇതിനെ കണക്കാക്കി.

ഒപ്പം ഇത് HackerOne സേവനത്തിൽ നിന്ന് പൊതുവായി ലഭ്യമായ റിപ്പോർട്ട് (h1), ഇൻസ്‌റ്റൻസ് മെറ്റാഡാറ്റ വായിക്കാനുള്ള കഴിവുള്ള ഒരു അന്ധതയില്ലാത്ത എസ്എസ്ആർഎഫിന്റെ ചൂഷണം മുഴുവൻ Shopify ഇൻഫ്രാസ്ട്രക്ചറിലേക്കും റൂട്ട് ആക്‌സസിലേക്ക് നയിക്കുന്നു.

MCS-ൽ, SSRF കേടുപാടുകൾ സമാനമായ പ്രവർത്തനക്ഷമതയുള്ള രണ്ട് സ്ഥലങ്ങളിൽ കണ്ടെത്തി, പക്ഷേ ഫയർവാളുകളും മറ്റ് പരിരക്ഷകളും കാരണം അവ ചൂഷണം ചെയ്യുന്നത് മിക്കവാറും അസാധ്യമായിരുന്നു. ഒരു വിധത്തിലല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ, കമ്മ്യൂണിറ്റിയെ കാത്തുനിൽക്കാതെ, MCS ടീം എന്തായാലും ഈ പ്രശ്നം പരിഹരിച്ചു.

ഷെല്ലുകൾ ലോഡുചെയ്യുന്നതിന് പകരം XSS

നൂറുകണക്കിന് പഠനങ്ങൾ എഴുതിയിട്ടുണ്ടെങ്കിലും, വർഷാവർഷം XSS (ക്രോസ്-സൈറ്റ് സ്ക്രിപ്റ്റിംഗ്) ആക്രമണമാണ് ഇപ്പോഴും ഏറ്റവും കൂടുതൽ പലപ്പോഴും കണ്ടുമുട്ടുന്നു വെബ് ദുർബലത (അല്ലെങ്കിൽ ആക്രമണം?).

ഫയൽ അപ്‌ലോഡുകൾ ഏതൊരു സുരക്ഷാ ഗവേഷകർക്കും പ്രിയപ്പെട്ട സ്ഥലമാണ്. പെന്റസ്റ്ററുകളുടെ പദാവലിയിൽ നിങ്ങൾക്ക് ഒരു അനിയന്ത്രിതമായ സ്ക്രിപ്റ്റ് (asp/jsp/php) ലോഡ് ചെയ്യാനും OS കമാൻഡുകൾ എക്സിക്യൂട്ട് ചെയ്യാനും കഴിയുമെന്ന് ഇത് പലപ്പോഴും മാറുന്നു - "ലോഡ് ഷെൽ". എന്നാൽ അത്തരം കേടുപാടുകളുടെ ജനപ്രീതി രണ്ട് ദിശകളിലും പ്രവർത്തിക്കുന്നു: അവ ഓർമ്മിക്കുകയും അവയ്‌ക്കെതിരെ പ്രതിവിധികൾ വികസിപ്പിക്കുകയും ചെയ്യുന്നു, അതിനാൽ അടുത്തിടെ “ഒരു ഷെൽ ലോഡുചെയ്യാനുള്ള” സാധ്യത പൂജ്യമായി മാറുന്നു.

ആക്രമണം നടത്തിയ ടീം (ഡിജിറ്റൽ സെക്യൂരിറ്റി പ്രതിനിധീകരിക്കുന്നത്) ഭാഗ്യവാനായിരുന്നു. ശരി, സെർവർ വശത്തുള്ള MCS-ൽ ഡൗൺലോഡ് ചെയ്‌ത ഫയലുകളുടെ ഉള്ളടക്കം പരിശോധിച്ചു, ചിത്രങ്ങൾ മാത്രം അനുവദിച്ചു. എന്നാൽ എസ്.വി.ജി.യും ഒരു ചിത്രമാണ്. SVG ചിത്രങ്ങൾ എങ്ങനെയാണ് അപകടകരമാകുന്നത്? കാരണം നിങ്ങൾക്ക് അവയിൽ JavaScript സ്‌നിപ്പെറ്റുകൾ ഉൾച്ചേർക്കാനാകും!

ഡൗൺലോഡ് ചെയ്‌ത ഫയലുകൾ MCS സേവനത്തിന്റെ എല്ലാ ഉപയോക്താക്കൾക്കും ലഭ്യമാണെന്ന് തെളിഞ്ഞു, അതായത് മറ്റ് ക്ലൗഡ് ഉപയോക്താക്കളെ, അതായത് അഡ്മിനിസ്ട്രേറ്റർമാരെ ആക്രമിക്കാൻ സാധ്യതയുണ്ട്.

ഒരു ഫിഷിംഗ് ലോഗിൻ ഫോമിൽ ഒരു XSS ആക്രമണത്തിന്റെ ഉദാഹരണം

XSS ആക്രമണ ചൂഷണത്തിന്റെ ഉദാഹരണങ്ങൾ:

• ഒരു സെഷൻ മോഷ്ടിക്കാൻ ശ്രമിക്കുന്നത് എന്തുകൊണ്ട് (പ്രത്യേകിച്ച് ഇപ്പോൾ മുതൽ HTTP-മാത്രം കുക്കികൾ എല്ലായിടത്തും ഉണ്ട്, js സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ച് മോഷണത്തിൽ നിന്ന് സംരക്ഷിക്കപ്പെടുന്നു), ലോഡ് ചെയ്ത സ്ക്രിപ്റ്റിന് ഉടൻ തന്നെ റിസോഴ്സ് API ആക്സസ് ചെയ്യാൻ കഴിയുമെങ്കിൽ? ഈ സാഹചര്യത്തിൽ, സെർവർ കോൺഫിഗറേഷൻ മാറ്റാൻ പേലോഡിന് XHR അഭ്യർത്ഥനകൾ ഉപയോഗിക്കാം, ഉദാഹരണത്തിന്, ആക്രമണകാരിയുടെ പൊതു SSH കീ ചേർത്ത് സെർവറിലേക്ക് SSH ആക്സസ് നേടുക.
• CSP നയം (ഉള്ളടക്ക സംരക്ഷണ നയം) JavaScript കുത്തിവയ്ക്കുന്നത് വിലക്കുകയാണെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് അതില്ലാതെ തന്നെ കടന്നുപോകാൻ കഴിയും. ശുദ്ധമായ HTML ഉപയോഗിച്ച്, സൈറ്റിനായി ഒരു വ്യാജ ലോഗിൻ ഫോം സൃഷ്ടിച്ച്, ഈ വിപുലമായ ഫിഷിംഗ് വഴി അഡ്മിനിസ്ട്രേറ്ററുടെ പാസ്‌വേഡ് മോഷ്ടിക്കുക: ഉപയോക്താവിനുള്ള ഫിഷിംഗ് പേജ് അതേ URL-ൽ അവസാനിക്കുന്നു, മാത്രമല്ല ഉപയോക്താവിന് അത് കണ്ടെത്തുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്.
• അവസാനമായി, ആക്രമണകാരിക്ക് ക്രമീകരിക്കാൻ കഴിയും ക്ലയന്റ് ഡോസ് - 4 കെബിയിൽ കൂടുതൽ വലിപ്പമുള്ള കുക്കികൾ സജ്ജമാക്കുക. ഉപയോക്താവിന് ഒരിക്കൽ മാത്രം ലിങ്ക് തുറന്നാൽ മതിയാകും, കൂടാതെ ബ്രൗസർ പ്രത്യേകമായി വൃത്തിയാക്കാൻ ഉപയോക്താവ് ചിന്തിക്കുന്നത് വരെ മുഴുവൻ സൈറ്റും അപ്രാപ്യമാകും: ബഹുഭൂരിപക്ഷം കേസുകളിലും, അത്തരം ഒരു ക്ലയന്റ് സ്വീകരിക്കാൻ വെബ് സെർവർ വിസമ്മതിക്കും.

കണ്ടെത്തിയ മറ്റൊരു XSS-ന്റെ ഒരു ഉദാഹരണം നോക്കാം, ഇത്തവണ കൂടുതൽ സമർത്ഥമായ ചൂഷണം. ഫയർവാൾ ക്രമീകരണങ്ങൾ ഗ്രൂപ്പുകളായി സംയോജിപ്പിക്കാൻ MCS സേവനം നിങ്ങളെ അനുവദിക്കുന്നു. XSS കണ്ടെത്തിയ സ്ഥലമായിരുന്നു ഗ്രൂപ്പിന്റെ പേര്. നിയമങ്ങളുടെ പട്ടിക കാണുമ്പോഴല്ല, ഒരു ഗ്രൂപ്പ് ഇല്ലാതാക്കുമ്പോൾ വെക്റ്റർ ഉടനടി പ്രവർത്തനക്ഷമമായില്ല എന്നതാണ് ഇതിന്റെ പ്രത്യേകത.

അതായത്, രംഗം ഇനിപ്പറയുന്നതായി മാറി: ഒരു ആക്രമണകാരി പേരിൽ “ലോഡ്” ഉള്ള ഒരു ഫയർവാൾ നിയമം സൃഷ്ടിക്കുന്നു, കുറച്ച് സമയത്തിന് ശേഷം അഡ്മിനിസ്ട്രേറ്റർ അത് ശ്രദ്ധിക്കുകയും ഇല്ലാതാക്കൽ പ്രക്രിയ ആരംഭിക്കുകയും ചെയ്യുന്നു. ഇവിടെയാണ് ക്ഷുദ്രകരമായ JS പ്രവർത്തിക്കുന്നത്.

അപ്‌ലോഡ് ചെയ്ത SVG ചിത്രങ്ങളിൽ XSS-ൽ നിന്ന് പരിരക്ഷിക്കുന്നതിന് MCS ഡെവലപ്പർമാർക്ക് (അവ ഒഴിവാക്കാനാവില്ലെങ്കിൽ), ഡിജിറ്റൽ സുരക്ഷാ ടീം ശുപാർശ ചെയ്യുന്നത്:

• ഉപയോക്താക്കൾ അപ്‌ലോഡ് ചെയ്‌ത ഫയലുകൾ "കുക്കികളുമായി" ബന്ധമില്ലാത്ത ഒരു പ്രത്യേക ഡൊമെയ്‌നിൽ സ്ഥാപിക്കുക. മറ്റൊരു ഡൊമെയ്‌നിന്റെ പശ്ചാത്തലത്തിൽ സ്‌ക്രിപ്റ്റ് എക്‌സിക്യൂട്ട് ചെയ്യപ്പെടും, അത് MCS-ന് ഒരു ഭീഷണിയുമല്ല.
• സെർവറിന്റെ HTTP പ്രതികരണത്തിൽ, "ഉള്ളടക്ക-വ്യവഹാരം: അറ്റാച്ച്മെന്റ്" എന്ന തലക്കെട്ട് അയയ്ക്കുക. അപ്പോൾ ഫയലുകൾ ബ്രൗസർ ഡൗൺലോഡ് ചെയ്യും, എക്സിക്യൂട്ട് ചെയ്യില്ല.

കൂടാതെ, XSS ചൂഷണത്തിന്റെ അപകടസാധ്യതകൾ ലഘൂകരിക്കാൻ ഡവലപ്പർമാർക്ക് ഇപ്പോൾ നിരവധി മാർഗങ്ങളുണ്ട്:

• "HTTP മാത്രം" ഫ്ലാഗ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് "കുക്കികൾ" എന്ന സെഷൻ ഹെഡറുകൾ ക്ഷുദ്രകരമായ JavaScript-ന് ആക്സസ് ചെയ്യാൻ കഴിയില്ല;
• ശരിയായി നടപ്പിലാക്കിയ CSP നയം ഒരു ആക്രമണകാരിക്ക് XSS ചൂഷണം ചെയ്യുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കും;
• ആംഗുലാർ അല്ലെങ്കിൽ റിയാക്റ്റ് പോലുള്ള ആധുനിക ടെംപ്ലേറ്റ് എഞ്ചിനുകൾ ഉപയോക്താവിന്റെ ബ്രൗസറിലേക്ക് ഔട്ട്പുട്ട് ചെയ്യുന്നതിന് മുമ്പ് ഉപയോക്തൃ ഡാറ്റ സ്വയമേവ അണുവിമുക്തമാക്കുന്നു.

രണ്ട്-ഘടക പ്രാമാണീകരണ കേടുപാടുകൾ

അക്കൗണ്ട് സുരക്ഷ മെച്ചപ്പെടുത്തുന്നതിന്, ഉപയോക്താക്കൾക്ക് എല്ലായ്പ്പോഴും 2FA (ടു-ഫാക്ടർ പ്രാമാണീകരണം) പ്രവർത്തനക്ഷമമാക്കാൻ നിർദ്ദേശിക്കുന്നു. തീർച്ചയായും, ഉപയോക്താവിന്റെ ക്രെഡൻഷ്യലുകൾ അപഹരിക്കപ്പെട്ടിട്ടുണ്ടെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് ഒരു സേവനത്തിലേക്ക് ആക്സസ് ലഭിക്കുന്നത് തടയുന്നതിനുള്ള ഫലപ്രദമായ മാർഗമാണിത്.

എന്നാൽ രണ്ടാമത്തെ പ്രാമാണീകരണ ഘടകം ഉപയോഗിക്കുന്നത് എപ്പോഴും അക്കൗണ്ട് സുരക്ഷ ഉറപ്പുനൽകുന്നുണ്ടോ? 2FA നടപ്പിലാക്കുന്നതിൽ ഇനിപ്പറയുന്ന സുരക്ഷാ പ്രശ്നങ്ങളുണ്ട്:

• OTP കോഡിന്റെ (ഒറ്റത്തവണ കോഡുകൾ) ബ്രൂട്ട്-ഫോഴ്‌സ് തിരയൽ. പ്രവർത്തനത്തിന്റെ ലാളിത്യം ഉണ്ടായിരുന്നിട്ടും, OTP ബ്രൂട്ട് ഫോഴ്‌സിനെതിരായ സംരക്ഷണത്തിന്റെ അഭാവം പോലുള്ള പിശകുകളും വലിയ കമ്പനികൾ നേരിടുന്നു: സ്ലാക്ക് കേസ്, ഫേസ്ബുക്ക് കേസ്.
• ദുർബലമായ ജനറേഷൻ അൽഗോരിതം, ഉദാഹരണത്തിന് അടുത്ത കോഡ് പ്രവചിക്കാനുള്ള കഴിവ്.
• നിങ്ങളുടെ ഫോണിൽ മറ്റൊരാളുടെ OTP അഭ്യർത്ഥിക്കാനുള്ള കഴിവ് പോലെയുള്ള ലോജിക്കൽ പിശകുകൾ ആയിരുന്നു Shopify ൽ നിന്ന്.

MCS-ന്റെ കാര്യത്തിൽ, 2FA നടപ്പിലാക്കുന്നത് Google Authenticator അടിസ്ഥാനമാക്കിയാണ് ഡ്യുയോ. പ്രോട്ടോക്കോൾ ഇതിനകം തന്നെ സമയപരിശോധന നടത്തിയിട്ടുണ്ട്, എന്നാൽ ആപ്ലിക്കേഷൻ ഭാഗത്ത് കോഡ് പരിശോധന നടപ്പിലാക്കുന്നത് പരിശോധിക്കേണ്ടതാണ്.

MCS 2FA പല സ്ഥലങ്ങളിലും ഉപയോഗിക്കുന്നു:

• ഉപയോക്താവിനെ ആധികാരികമാക്കുമ്പോൾ. ബ്രൂട്ട് ഫോഴ്‌സിനെതിരെ പരിരക്ഷയുണ്ട്: ഒറ്റത്തവണ പാസ്‌വേഡ് നൽകാൻ ഉപയോക്താവിന് കുറച്ച് ശ്രമങ്ങൾ മാത്രമേ ഉള്ളൂ, തുടർന്ന് ഇൻപുട്ട് കുറച്ച് സമയത്തേക്ക് തടഞ്ഞു. ഇത് ഒടിപിയുടെ ബ്രൂട്ട് ഫോഴ്‌സ് തിരഞ്ഞെടുക്കാനുള്ള സാധ്യതയെ തടയുന്നു.
• 2FA നിർവഹിക്കുന്നതിന് ഓഫ്‌ലൈൻ ബാക്കപ്പ് കോഡുകൾ സൃഷ്ടിക്കുമ്പോൾ, അതുപോലെ അത് പ്രവർത്തനരഹിതമാക്കുന്നു. ഇവിടെ, ഒരു ബ്രൂട്ട് ഫോഴ്‌സ് പരിരക്ഷയും നടപ്പിലാക്കിയിട്ടില്ല, ഇത് നിങ്ങൾക്ക് അക്കൗണ്ടിനായി ഒരു പാസ്‌വേഡും സജീവമായ ഒരു സെഷനും ഉണ്ടെങ്കിൽ, ബാക്കപ്പ് കോഡുകൾ പുനഃസൃഷ്ടിക്കാനോ 2FA പൂർണ്ണമായും പ്രവർത്തനരഹിതമാക്കാനോ സാധ്യമാക്കി.

OTP ആപ്ലിക്കേഷൻ സൃഷ്ടിച്ച അതേ ശ്രേണിയിലുള്ള സ്ട്രിംഗ് മൂല്യങ്ങളിലാണ് ബാക്കപ്പ് കോഡുകൾ സ്ഥിതിചെയ്യുന്നത് എന്നത് കണക്കിലെടുക്കുമ്പോൾ, ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ കോഡ് കണ്ടെത്താനുള്ള സാധ്യത വളരെ കൂടുതലാണ്.

"Burp: Intruder" ടൂൾ ഉപയോഗിച്ച് 2FA പ്രവർത്തനരഹിതമാക്കാൻ OTP തിരഞ്ഞെടുക്കുന്ന പ്രക്രിയ

ഫലം

മൊത്തത്തിൽ, MCS ഒരു ഉൽപ്പന്നമെന്ന നിലയിൽ സുരക്ഷിതമാണെന്ന് തോന്നുന്നു. ഓഡിറ്റ് സമയത്ത്, പെന്റസ്റ്റിംഗ് ടീമിന് ക്ലയന്റ് VM-കളിലേക്കും അവയുടെ ഡാറ്റയിലേക്കും പ്രവേശനം നേടാനായില്ല, കൂടാതെ കണ്ടെത്തിയ കേടുപാടുകൾ MCS ടീം വേഗത്തിൽ ശരിയാക്കി.

എന്നാൽ ഇവിടെ ശ്രദ്ധിക്കേണ്ട കാര്യം, സുരക്ഷ ഒരു തുടർച്ചയായ ജോലിയാണ്. സേവനങ്ങൾ സ്ഥിരമല്ല, അവ നിരന്തരം വികസിച്ചുകൊണ്ടിരിക്കുന്നു. കേടുപാടുകൾ കൂടാതെ ഒരു ഉൽപ്പന്നം പൂർണ്ണമായും വികസിപ്പിക്കുക അസാധ്യമാണ്. എന്നാൽ നിങ്ങൾക്ക് അവ കൃത്യസമയത്ത് കണ്ടെത്താനും അവ ആവർത്തിക്കാനുള്ള സാധ്യത കുറയ്ക്കാനും കഴിയും.

ഇപ്പോൾ MCS-ൽ സൂചിപ്പിച്ച എല്ലാ കേടുപാടുകളും ഇതിനകം പരിഹരിച്ചു. പുതിയവയുടെ എണ്ണം കുറയ്ക്കുന്നതിനും അവരുടെ ആയുസ്സ് കുറയ്ക്കുന്നതിനും, പ്ലാറ്റ്ഫോം ടീം ഇത് ചെയ്യുന്നത് തുടരുന്നു:

• ബാഹ്യ കമ്പനികൾ പതിവായി ഓഡിറ്റുകൾ നടത്തുക;
• പങ്കാളിത്തത്തെ പിന്തുണയ്ക്കുകയും വികസിപ്പിക്കുകയും ചെയ്യുക Mail.ru ഗ്രൂപ്പ് ബഗ് ബൗണ്ടി പ്രോഗ്രാമിൽ;
• സുരക്ഷയിൽ ഏർപ്പെടുക. 🙂

അവലംബം: www.habr.com