AWS-ൽ ക്യാപിറ്റൽ വൺ ബാങ്ക് ഹാക്കിന്റെ സാങ്കേതിക വിശദാംശങ്ങൾ

എല്ലാ ആധുനിക കമ്പനികളും ഭയപ്പെടുന്ന ഒരു സന്ദേശം 19 ജൂലൈ 2019-ന് ക്യാപിറ്റൽ വണ്ണിന് ലഭിച്ചു-ഒരു ഡാറ്റാ ലംഘനം സംഭവിച്ചു. ഇത് 106 ദശലക്ഷത്തിലധികം ആളുകളെ ബാധിച്ചു. 140 US സോഷ്യൽ സെക്യൂരിറ്റി നമ്പറുകൾ, ഒരു ദശലക്ഷം കനേഡിയൻ സോഷ്യൽ സെക്യൂരിറ്റി നമ്പറുകൾ. 000 ബാങ്ക് അക്കൗണ്ടുകൾ. അരോചകമാണ്, നിങ്ങൾ സമ്മതിക്കുന്നില്ലേ?

നിർഭാഗ്യവശാൽ, ഹാക്ക് ജൂലൈ 19 ന് സംഭവിച്ചില്ല. അത് മാറുന്നതുപോലെ, പൈജ് തോംസൺ, എ.കെ. തെറ്റായ, 22 മാർച്ച് 23 നും മാർച്ച് 2019 നും ഇടയിൽ ഇത് ചെയ്തു. അതാണ് ഏകദേശം നാല് മാസം മുമ്പ്. സത്യത്തിൽ, പുറത്തുള്ള കൺസൾട്ടന്റുമാരുടെ സഹായത്തോടെയാണ് ക്യാപിറ്റൽ വണ്ണിന് എന്തോ സംഭവിച്ചതായി കണ്ടെത്താൻ കഴിഞ്ഞത്.

ഒരു മുൻ ആമസോൺ ജീവനക്കാരൻ അറസ്റ്റിലാവുകയും $250 പിഴയും അഞ്ച് വർഷം തടവും നേരിടേണ്ടിവരികയും ചെയ്തു... എന്നാൽ ഇനിയും ഒരുപാട് നിഷേധാത്മകത അവശേഷിക്കുന്നു. എന്തുകൊണ്ട്? കാരണം ഹാക്കുകൾ നേരിട്ട പല കമ്പനികളും സൈബർ കുറ്റകൃത്യങ്ങളുടെ വർദ്ധനവിനിടയിൽ തങ്ങളുടെ അടിസ്ഥാന സൗകര്യങ്ങളും ആപ്ലിക്കേഷനുകളും ശക്തിപ്പെടുത്തുന്നതിനുള്ള ഉത്തരവാദിത്തത്തിൽ നിന്ന് ഒഴിഞ്ഞുമാറാൻ ശ്രമിക്കുന്നു.

എന്തായാലും, നിങ്ങൾക്ക് ഈ സ്റ്റോറി എളുപ്പത്തിൽ ഗൂഗിൾ ചെയ്യാം. ഞങ്ങൾ നാടകത്തിലേക്ക് പോകില്ല, പക്ഷേ അതിനെക്കുറിച്ച് സംസാരിക്കും സാങ്കേതികമായ കാര്യത്തിന്റെ വശം.

ഒന്നാമതായി, എന്താണ് സംഭവിച്ചത്?

ക്യാപിറ്റൽ വണ്ണിൽ ഏകദേശം 700 എസ് 3 ബക്കറ്റുകൾ ഓടിയിരുന്നു, അത് പൈജ് തോംസൺ പകർത്തി ചോർത്തി.

രണ്ടാമതായി, തെറ്റായി ക്രമീകരിച്ച S3 ബക്കറ്റ് നയത്തിന്റെ മറ്റൊരു സംഭവമാണോ ഇത്?

ഇല്ല, ഇത്തവണ വേണ്ട. ഇവിടെ അവൾ തെറ്റായി കോൺഫിഗർ ചെയ്‌ത ഫയർവാളുള്ള ഒരു സെർവറിലേക്ക് ആക്‌സസ് നേടുകയും അവിടെ നിന്ന് മുഴുവൻ പ്രവർത്തനവും നടത്തുകയും ചെയ്തു.

കാത്തിരിക്കൂ, അതെങ്ങനെ സാധ്യമാകും?

ശരി, നമുക്ക് കൂടുതൽ വിശദാംശങ്ങൾ ഇല്ലെങ്കിലും സെർവറിൽ ലോഗിൻ ചെയ്തുകൊണ്ട് ആരംഭിക്കാം. "തെറ്റായി ക്രമീകരിച്ച ഫയർവാൾ" വഴിയാണ് ഇത് സംഭവിച്ചതെന്ന് മാത്രമേ ഞങ്ങളോട് പറഞ്ഞിട്ടുള്ളൂ. അതിനാൽ, തെറ്റായ സുരക്ഷാ ഗ്രൂപ്പ് ക്രമീകരണങ്ങൾ അല്ലെങ്കിൽ വെബ് ആപ്ലിക്കേഷൻ ഫയർവാൾ (Imperva), അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ഫയർവാൾ (iptables, ufw, shorewall, മുതലായവ) കോൺഫിഗറേഷൻ പോലെ ലളിതമായ ഒന്ന്. ക്യാപിറ്റൽ വൺ അതിന്റെ കുറ്റം സമ്മതിക്കുകയും ദ്വാരം അടച്ചതായി പറയുകയും ചെയ്തു.

ഫയർവാൾ അപകടസാധ്യത ക്യാപിറ്റൽ വൺ ആദ്യം ശ്രദ്ധിച്ചിരുന്നില്ലെങ്കിലും അത് അറിഞ്ഞയുടൻ വേഗത്തിൽ പ്രവർത്തിച്ചുവെന്നും സ്റ്റോൺ പറഞ്ഞു. പൊതു ഡൊമെയ്‌നിൽ പ്രധാന തിരിച്ചറിയൽ വിവരങ്ങൾ ഹാക്കർ ഉപേക്ഷിച്ചുവെന്നത് ഇത് തീർച്ചയായും സഹായിച്ചു, സ്റ്റോൺ പറഞ്ഞു.

എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ ഭാഗത്തേക്ക് കൂടുതൽ ആഴത്തിൽ പോകുന്നില്ലെന്ന് നിങ്ങൾ ആശ്ചര്യപ്പെടുന്നെങ്കിൽ, പരിമിതമായ വിവരങ്ങൾ കാരണം ഞങ്ങൾക്ക് ഊഹിക്കാൻ മാത്രമേ കഴിയൂ എന്ന് മനസ്സിലാക്കുക. ക്യാപിറ്റൽ വൺ അവശേഷിപ്പിച്ച ഒരു ദ്വാരത്തെയാണ് ഹാക്ക് ആശ്രയിക്കുന്നത് എന്നതിനാൽ ഇത് അർത്ഥമാക്കുന്നില്ല. അവർ ഞങ്ങളോട് കൂടുതൽ പറയുന്നില്ലെങ്കിൽ, ഈ വ്യത്യസ്‌ത ഓപ്ഷനുകളിലൊന്ന് ആർക്കെങ്കിലും ഉപയോഗിക്കാൻ സാധ്യമായ എല്ലാ വഴികളും സംയോജിപ്പിച്ച് ക്യാപിറ്റൽ വൺ അവരുടെ സെർവർ തുറന്ന് വിട്ട സാധ്യമായ എല്ലാ വഴികളും ഞങ്ങൾ ലിസ്റ്റ് ചെയ്യും. ഈ പോരായ്മകളും സാങ്കേതികതകളും വന്യമായ മണ്ടത്തരങ്ങൾ മുതൽ അവിശ്വസനീയമാംവിധം സങ്കീർണ്ണമായ പാറ്റേണുകൾ വരെയാകാം. സാധ്യതകളുടെ വ്യാപ്തി കണക്കിലെടുക്കുമ്പോൾ, ഇത് യഥാർത്ഥ നിഗമനങ്ങളില്ലാത്ത ഒരു നീണ്ട കഥയായി മാറും. അതിനാൽ, നമുക്ക് വസ്തുതകൾ ഉള്ള ഭാഗം വിശകലനം ചെയ്യുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാം.

അതിനാൽ ആദ്യത്തെ ടേക്ക് എവേ ഇതാണ്: നിങ്ങളുടെ ഫയർവാളുകൾ എന്താണ് അനുവദിക്കുന്നതെന്ന് അറിയുക.

തുറക്കേണ്ടവ മാത്രം തുറന്നിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഒരു നയമോ ശരിയായ പ്രക്രിയയോ സ്ഥാപിക്കുക. സെക്യൂരിറ്റി ഗ്രൂപ്പുകൾ അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക് ACL-കൾ പോലുള്ള AWS ഉറവിടങ്ങളാണ് നിങ്ങൾ ഉപയോഗിക്കുന്നതെങ്കിൽ, ഓഡിറ്റ് ചെയ്യാനുള്ള ചെക്ക്‌ലിസ്റ്റ് ദൈർഘ്യമേറിയതായിരിക്കും... എന്നാൽ പല ഉറവിടങ്ങളും സ്വയമേവ സൃഷ്‌ടിക്കുന്നത് പോലെ (അതായത് CloudFormation), അവയുടെ ഓഡിറ്റിംഗ് ഓട്ടോമേറ്റ് ചെയ്യാനും സാധിക്കും. പുതിയ ഒബ്‌ജക്‌റ്റുകൾ പോരായ്മകൾക്കായി സ്‌കാൻ ചെയ്യുന്ന ഒരു ഹോം മെയ്ഡ് സ്‌ക്രിപ്‌റ്റായാലും, അല്ലെങ്കിൽ CI/CD പ്രോസസ്സിലെ സെക്യൂരിറ്റി ഓഡിറ്റ് പോലെയുള്ള മറ്റെന്തെങ്കിലും ആയാലും... ഇത് ഒഴിവാക്കാൻ നിരവധി എളുപ്പവഴികളുണ്ട്.

കാപ്പിറ്റൽ വൺ ആദ്യം ദ്വാരം അടച്ചിരുന്നെങ്കിൽ... ഒന്നും സംഭവിക്കില്ലായിരുന്നു എന്നതാണ് കഥയുടെ "തമാശ". അതിനാൽ, സത്യം പറഞ്ഞാൽ, എന്തെങ്കിലും ശരിക്കും എങ്ങനെയെന്ന് കാണുന്നത് എല്ലായ്പ്പോഴും ഞെട്ടിപ്പിക്കുന്നതാണ് വളരെ ലളിതമാണ് ഒരു കമ്പനി ഹാക്ക് ചെയ്യപ്പെടാനുള്ള ഒരേയൊരു കാരണമായി മാറുന്നു. പ്രത്യേകിച്ച് ക്യാപിറ്റൽ ഒന്നിന്റെ അത്രയും വലുത്.

അപ്പോൾ, അകത്ത് ഹാക്കർ - പിന്നീട് എന്ത് സംഭവിച്ചു?

ശരി, ഒരു EC2 ഉദാഹരണത്തിലേക്ക് കടന്നതിന് ശേഷം... ഒരുപാട് തെറ്റുകൾ സംഭവിക്കാം. നിങ്ങൾ ആരെയെങ്കിലും അത്രയും ദൂരം പോകാൻ അനുവദിച്ചാൽ നിങ്ങൾ പ്രായോഗികമായി കത്തിയുടെ അരികിൽ നടക്കുന്നു. എന്നാൽ അത് എങ്ങനെയാണ് എസ് 3 ബക്കറ്റുകളിൽ എത്തിയത്? ഇത് മനസിലാക്കാൻ, നമുക്ക് IAM റോളുകൾ ചർച്ച ചെയ്യാം.

അതിനാൽ, AWS സേവനങ്ങൾ ആക്സസ് ചെയ്യുന്നതിനുള്ള ഒരു മാർഗം ഒരു ഉപയോക്താവായിരിക്കുക എന്നതാണ്. ശരി, ഇത് വളരെ വ്യക്തമാണ്. എന്നാൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ സെർവറുകൾ പോലുള്ള മറ്റ് AWS സേവനങ്ങൾക്ക് നിങ്ങളുടെ S3 ബക്കറ്റുകളിലേക്ക് ആക്‌സസ് നൽകണമെങ്കിൽ എന്ത് ചെയ്യും? അതിനാണ് IAM റോളുകൾ. അവ രണ്ട് ഘടകങ്ങൾ ഉൾക്കൊള്ളുന്നു:

1. ട്രസ്റ്റ് പോളിസി - ഏതൊക്കെ സേവനങ്ങൾക്കോ ​​ആളുകൾക്കോ ​​ഈ റോൾ ഉപയോഗിക്കാനാകും?
2. അനുമതി നയം - ഈ റോൾ എന്താണ് അനുവദിക്കുന്നത്?

ഉദാഹരണത്തിന്, ഒരു S2 ബക്കറ്റ് ആക്‌സസ് ചെയ്യാൻ EC3 ഇൻസ്‌റ്റൻസുകളെ അനുവദിക്കുന്ന ഒരു IAM റോൾ സൃഷ്‌ടിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു: ആദ്യം, EC2 (മുഴുവൻ സേവനവും) അല്ലെങ്കിൽ നിർദ്ദിഷ്ട സംഭവങ്ങൾ റോൾ "ഏറ്റെടുക്കാൻ" കഴിയുന്ന ഒരു ട്രസ്റ്റ് നയം റോളിന് സജ്ജീകരിച്ചിരിക്കുന്നു. ഒരു റോൾ സ്വീകരിക്കുക എന്നതിനർത്ഥം അവർക്ക് പ്രവർത്തനങ്ങൾ നടത്താൻ റോളിന്റെ അനുമതികൾ ഉപയോഗിക്കാമെന്നാണ്. രണ്ടാമതായി, ക്യാപിറ്റൽ വണ്ണിന്റെ കാര്യത്തിലെന്നപോലെ, ഒരു നിർദ്ദിഷ്ട ബക്കറ്റ് ആക്‌സസ് ചെയ്യുകയോ... അല്ലെങ്കിൽ 3-ൽ കൂടുതലോ ആകട്ടെ, "റോൾ ഏറ്റെടുത്ത" സേവനം/വ്യക്തി/വിഭവം എന്നിവയെ S700-ൽ എന്തും ചെയ്യാൻ അനുമതി നയം അനുവദിക്കുന്നു.

ഐ‌എ‌എം റോളിനൊപ്പം നിങ്ങൾ ഒരു EC2 സംഭവത്തിലാണെങ്കിൽ, നിങ്ങൾക്ക് പല തരത്തിൽ ക്രെഡൻഷ്യലുകൾ നേടാനാകും:

1. നിങ്ങൾക്ക് ഇതിൽ ഉദാഹരണ മെറ്റാഡാറ്റ അഭ്യർത്ഥിക്കാം http://169.254.169.254/latest/meta-data

   മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, ഈ വിലാസത്തിലെ ഏതെങ്കിലും ആക്‌സസ് കീകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് IAM റോൾ കണ്ടെത്താനാകും. തീർച്ചയായും, നിങ്ങൾ ഒരു സംഭവത്തിലാണെങ്കിൽ മാത്രം.

2. AWS CLI ഉപയോഗിക്കുക...

   AWS CLI ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, IAM റോളുകളിൽ നിന്നുള്ള ക്രെഡൻഷ്യലുകൾ ഉണ്ടെങ്കിൽ, അത് ലോഡ് ചെയ്യും. ഉദാഹരണത്തിലൂടെ പ്രവർത്തിക്കുക എന്നതാണ് അവശേഷിക്കുന്നത്. തീർച്ചയായും, അവരുടെ ട്രസ്റ്റ് നയം തുറന്നിരുന്നെങ്കിൽ, പൈജിന് എല്ലാം നേരിട്ട് ചെയ്യാൻ കഴിയും.

അതിനാൽ IAM റോളുകളുടെ സാരാംശം, മറ്റ് വിഭവങ്ങളിൽ നിങ്ങളുടെ പേരിൽ പ്രവർത്തിക്കാൻ അവ ചില ഉറവിടങ്ങളെ അനുവദിക്കുന്നു എന്നതാണ്.

ഐ‌എ‌എമ്മിന്റെ റോളുകൾ നിങ്ങൾ ഇപ്പോൾ മനസ്സിലാക്കുന്നു, പൈജ് തോംസൺ ചെയ്ത കാര്യങ്ങളെക്കുറിച്ച് നമുക്ക് സംസാരിക്കാം:

1. ഫയർവാളിലെ ഒരു ദ്വാരത്തിലൂടെ അവൾ സെർവറിലേക്ക് (EC2 ഉദാഹരണം) പ്രവേശനം നേടി

   അത് സെക്യൂരിറ്റി ഗ്രൂപ്പുകളോ/ACLകളോ അല്ലെങ്കിൽ അവരുടെ സ്വന്തം വെബ് ആപ്ലിക്കേഷൻ ഫയർവാളുകളോ ആകട്ടെ, ഔദ്യോഗിക രേഖകളിൽ പറഞ്ഞിരിക്കുന്നതുപോലെ, ദ്വാരം പ്ലഗ് ചെയ്യാൻ വളരെ എളുപ്പമായിരുന്നു.

2. ഒരിക്കൽ സെർവറിൽ, അവൾ സ്വയം സെർവറായി പ്രവർത്തിക്കാൻ അവൾക്ക് കഴിഞ്ഞു
3. IAM സെർവർ റോൾ ഈ 3+ ബക്കറ്റുകളിലേക്ക് S700 ആക്‌സസ് അനുവദിച്ചതിനാൽ, അതിന് അവ ആക്‌സസ് ചെയ്യാൻ കഴിഞ്ഞു

ആ നിമിഷം മുതൽ, അവൾ ചെയ്യേണ്ടത് കമാൻഡ് പ്രവർത്തിപ്പിക്കുക മാത്രമാണ് List Bucketsതുടർന്ന് ആജ്ഞ Sync AWS CLI-ൽ നിന്ന്...

100 ഡോളറിനും 150 മില്യൺ ഡോളറിനും ഇടയിലാണ് ഹാക്ക് മൂലമുണ്ടായ നാശനഷ്ടം ക്യാപിറ്റൽ വൺ ബാങ്ക് കണക്കാക്കുന്നത്.. ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചർ പ്രൊട്ടക്ഷൻ, DevOps, സെക്യൂരിറ്റി വിദഗ്ധർ എന്നിവയിൽ കമ്പനികൾ ഇത്രയധികം നിക്ഷേപിക്കുന്നത് എന്തിനാണ് ഇത്തരം നാശനഷ്ടങ്ങൾ തടയുന്നത്. ക്ലൗഡിലേക്ക് നീങ്ങുന്നത് എത്ര വിലപ്പെട്ടതും ചെലവ് കുറഞ്ഞതുമാണ്? കൂടുതൽ കൂടുതൽ സൈബർ സുരക്ഷാ വെല്ലുവിളികൾ നേരിടുമ്പോൾ പോലും മൊത്തത്തിലുള്ള പൊതു ക്ലൗഡ് മാർക്കറ്റ് 42 ആദ്യ പാദത്തിൽ 2019% വളർന്നു!

കഥയുടെ ധാർമ്മികത: നിങ്ങളുടെ സുരക്ഷ പരിശോധിക്കുക; പതിവായി ഓഡിറ്റുകൾ നടത്തുക; സുരക്ഷാ നയങ്ങൾക്കായുള്ള ഏറ്റവും കുറഞ്ഞ പ്രത്യേകാവകാശം എന്ന തത്വത്തെ മാനിക്കുക.

(ഇത് നിങ്ങൾക്ക് മുഴുവൻ നിയമ റിപ്പോർട്ടും കാണാൻ കഴിയും).

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