ព័ត៌មានលម្អិតបច្ចេកទេសនៃការ hack Capital One លើ AWS

នៅថ្ងៃទី 19 ខែកក្កដា ឆ្នាំ 2019 ក្រុមហ៊ុន Capital One បានទទួលសារដែលគ្រប់ក្រុមហ៊ុនទំនើបៗភ័យខ្លាច ពោលគឺការបំពានទិន្នន័យបានកើតឡើង។ វាប៉ះពាល់ដល់មនុស្សជាង 106 លាននាក់។ លេខសន្តិសុខសង្គមអាមេរិកចំនួន 140 លេខសន្តិសុខសង្គមកាណាដា មួយលាន។ 000 គណនីធនាគារ។ អន់ចិត្ត អត់យល់ស្រប?

ជាអកុសល ការ Hack មិនបានកើតឡើងនៅថ្ងៃទី 19 ខែកក្កដា។ ដូចដែលវាប្រែចេញ Paige Thompson, a.k.a. ខុសប្រក្រតីប្រព្រឹត្តនៅចន្លោះថ្ងៃទី ២២ ដល់ ២៣ ខែមីនា ឆ្នាំ ២០១៩។ នោះគឺជា ជិតបួនខែមុន។. តាមពិតទៅ វាគ្រាន់តែជាជំនួយពីអ្នកប្រឹក្សាខាងក្រៅប៉ុណ្ណោះ ដែល Capital One អាចរកឃើញថាមានអ្វីមួយបានកើតឡើង។

អតីតបុគ្គលិក Amazon ត្រូវបានចាប់ខ្លួន និងប្រឈមមុខនឹងការផាកពិន័យ 250 ដុល្លារ និងជាប់ពន្ធនាគាររយៈពេល XNUMX ឆ្នាំ... ប៉ុន្តែនៅតែមានភាពអវិជ្ជមានជាច្រើន។ ហេតុអ្វី? ដោយសារតែក្រុមហ៊ុនជាច្រើនដែលបានរងគ្រោះពីការលួចចូលកំពុងព្យាយាមទម្លាក់ការទទួលខុសត្រូវសម្រាប់ការពង្រឹងហេដ្ឋារចនាសម្ព័ន្ធ និងកម្មវិធីរបស់ពួកគេចំពេលមានការកើនឡើងនៃឧក្រិដ្ឋកម្មតាមអ៊ីនធឺណិត។

យ៉ាង​ណា​ក៏​ដោយ អ្នក​អាច google រឿង​នេះ​បាន​យ៉ាង​ងាយ។ យើងនឹងមិនចូលទៅក្នុងរឿងទេ ប៉ុន្តែនិយាយអំពី បច្ចេកទេស ផ្នែកម្ខាងនៃបញ្ហា។

ជាបឋម តើមានអ្វីកើតឡើង?

Capital One មានធុងទឹក S700 ប្រហែល 3 ដែលកំពុងដំណើរការ ដែល Paige Thompson បានចម្លង និងដកយកចេញ។

ទីពីរ តើនេះជាករណីមួយផ្សេងទៀតនៃគោលការណ៍ដាក់ធុង S3 មិនត្រឹមត្រូវ?

ទេ​មិនមែន​ពេលនេះ​ទេ។ នៅទីនេះនាងទទួលបានសិទ្ធិចូលប្រើម៉ាស៊ីនមេដែលមានជញ្ជាំងភ្លើងដែលបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ ហើយអនុវត្តប្រតិបត្តិការទាំងមូលពីទីនោះ។

ចាំមើល តើវាអាចទៅរួចដោយរបៀបណា?

ជាការប្រសើរណាស់ ចូរចាប់ផ្តើមដោយការចូលទៅក្នុងម៉ាស៊ីនមេ ទោះបីជាយើងមិនមានព័ត៌មានលម្អិតច្រើនក៏ដោយ។ យើងត្រូវបានគេប្រាប់ថាវាបានកើតឡើងតាមរយៈ "ជញ្ជាំងភ្លើងដែលបានកំណត់រចនាសម្ព័ន្ធមិនត្រឹមត្រូវ"។ ដូច្នេះ អ្វីមួយដែលសាមញ្ញដូចជាការកំណត់ក្រុមសុវត្ថិភាពមិនត្រឹមត្រូវ ឬការកំណត់រចនាសម្ព័ន្ធជញ្ជាំងភ្លើងកម្មវិធីបណ្ដាញ (Imperva) ឬជញ្ជាំងភ្លើងបណ្តាញ (iptables, ufw, shorewall ។ល។)។ Capital One បានត្រឹមតែសារភាពកំហុសរបស់ខ្លួន ហើយបាននិយាយថា ខ្លួនបានបិទរន្ធ។

Stone បាននិយាយថា Capital One មិនបានកត់សម្គាល់ឃើញពីភាពងាយរងគ្រោះនៃជញ្ជាំងភ្លើងទេ ប៉ុន្តែបានធ្វើសកម្មភាពភ្លាមៗនៅពេលដែលវាដឹងអំពីវា។ Stone បាន​និយាយ​ថា នេះ​ពិត​ជា​ត្រូវ​បាន​ជួយ​ដោយ​ការ​ពិត​ដែល​ថា​ពួក Hacker បាន​បន្សល់​ទុក​ព័ត៌មាន​កំណត់​អត្តសញ្ញាណ​សំខាន់​នៅ​ក្នុង​ដែន​សាធារណៈ។

ប្រសិនបើអ្នកឆ្ងល់ថាហេតុអ្វីបានជាយើងមិនចូលទៅក្នុងផ្នែកនេះឱ្យកាន់តែស៊ីជម្រៅនោះ សូមយល់ថាដោយសារតែព័ត៌មានមានកំណត់ យើងអាចធ្វើការប៉ាន់ស្មានតែប៉ុណ្ណោះ។ នេះគ្មានន័យទេដែលថាការ hack ពឹងផ្អែកលើរន្ធដែលទុកដោយ Capital One ។ ហើយលុះត្រាតែពួកគេប្រាប់យើងបន្ថែម យើងនឹងរាយបញ្ជីវិធីដែលអាចធ្វើបានទាំងអស់ដែល Capital One ទុកឱ្យម៉ាស៊ីនមេរបស់ពួកគេបើកដោយរួមបញ្ចូលគ្នាជាមួយនឹងមធ្យោបាយដែលអាចធ្វើបានទាំងអស់ដែលនរណាម្នាក់អាចប្រើជម្រើសមួយក្នុងចំណោមជម្រើសផ្សេងគ្នាទាំងនេះ។ គុណវិបត្តិ និងបច្ចេកទេសទាំងនេះអាចមានចាប់ពីការត្រួតពិនិត្យដ៏ឆោតល្ងង់រហូតដល់គំរូស្មុគស្មាញមិនគួរឱ្យជឿ។ ដោយគិតពីលទ្ធភាព នេះនឹងក្លាយជារឿងដ៏វែងមួយ ដែលគ្មានការសន្និដ្ឋានពិតប្រាកដ។ ដូច្នេះហើយ ចូរយើងផ្តោតលើការវិភាគផ្នែកដែលយើងមានការពិត។

ដូច្នេះ​ការ​យក​ចេញ​ដំបូង​គឺ៖ ដឹង​ថា​ជញ្ជាំង​ភ្លើង​របស់​អ្នក​អនុញ្ញាត​អ្វី។

បង្កើតគោលនយោបាយ ឬដំណើរការត្រឹមត្រូវ ដើម្បីធានាថា មានតែអ្វីដែលត្រូវបើកប៉ុណ្ណោះត្រូវបានបើក។ ប្រសិនបើអ្នកកំពុងប្រើធនធាន AWS ដូចជា Security Groups ឬ Network ACLs ច្បាស់ណាស់បញ្ជីត្រួតពិនិត្យដើម្បីធ្វើសវនកម្មអាចមានរយៈពេលយូរ... ប៉ុន្តែដូចជាធនធានជាច្រើនត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ (ឧទាហរណ៍ CloudFormation) វាក៏អាចធ្វើសវនកម្មរបស់ពួកគេដោយស្វ័យប្រវត្តិផងដែរ។ ថាតើវាជាស្គ្រីបដែលផលិតនៅផ្ទះដែលស្កេនវត្ថុថ្មីសម្រាប់គុណវិបត្តិ ឬអ្វីមួយដូចជាសវនកម្មសុវត្ថិភាពនៅក្នុងដំណើរការ CI/CD... មានជម្រើសងាយស្រួលជាច្រើនដើម្បីជៀសវាងបញ្ហានេះ។

ផ្នែក "កំប្លែង" នៃរឿងគឺថាប្រសិនបើ Capital One បានដោតរន្ធនៅកន្លែងដំបូង ... គ្មានអ្វីនឹងកើតឡើងទេ។ ដូច្នេះហើយ និយាយឱ្យត្រង់ទៅ វាតែងតែភ្ញាក់ផ្អើលក្នុងការមើលថាតើមានអ្វីពិតប្រាកដ សាមញ្ញណាស់។ ក្លាយជាហេតុផលតែមួយគត់សម្រាប់ក្រុមហ៊ុនមួយដែលត្រូវបានលួចចូល។ ជាពិសេសមួយធំដូច Capital One។

ដូច្នេះ ហេកឃឺនៅខាងក្នុង - តើមានអ្វីកើតឡើងបន្ទាប់?

ជាការប្រសើរណាស់, បន្ទាប់ពីបំបែកចូលទៅក្នុងឧទាហរណ៍ EC2 ... ច្រើនអាចខុស។ អ្នក​កំពុង​តែ​ដើរ​លើ​គែម​កាំបិត បើ​អ្នក​ឲ្យ​អ្នក​ណា​ម្នាក់​ទៅ​ឆ្ងាយ។ ប៉ុន្តែតើវាចូលទៅក្នុងធុង S3 យ៉ាងដូចម្តេច? ដើម្បីយល់ពីរឿងនេះ សូមពិភាក្សាអំពីតួនាទី IAM ។

ដូច្នេះវិធីមួយដើម្បីចូលប្រើសេវាកម្ម AWS គឺដើម្បីក្លាយជាអ្នកប្រើប្រាស់។ អូខេ មួយនេះគឺច្បាស់ណាស់។ ប៉ុន្តែចុះយ៉ាងណាបើអ្នកចង់ផ្តល់សេវាកម្ម AWS ផ្សេងទៀត ដូចជាម៉ាស៊ីនមេកម្មវិធីរបស់អ្នក ចូលប្រើធុង S3 របស់អ្នក? នោះហើយជាអ្វីដែលតួនាទី IAM គឺសម្រាប់។ ពួកវាមានសមាសធាតុពីរ៖

1. គោលការណ៍ទុកចិត្ត - តើសេវាកម្មអ្វី ឬមនុស្សអាចប្រើតួនាទីនេះ?
2. គោលការណ៍អនុញ្ញាត - តើតួនាទីនេះអនុញ្ញាតអ្វីខ្លះ?

ឧទាហរណ៍ អ្នកចង់បង្កើតតួនាទី IAM ដែលនឹងអនុញ្ញាតឱ្យ EC2 instances ចូលប្រើធុង S3៖ ដំបូង តួនាទីត្រូវបានកំណត់ឱ្យមានគោលការណ៍ទុកចិត្តដែល EC2 (សេវាកម្មទាំងមូល) ឬករណីជាក់លាក់អាច "កាន់កាប់" តួនាទីនេះ។ ការទទួលយកតួនាទីមានន័យថាពួកគេអាចប្រើការអនុញ្ញាតរបស់តួនាទីដើម្បីអនុវត្តសកម្មភាព។ ទីពីរ គោលការណ៍អនុញ្ញាតអនុញ្ញាតឱ្យសេវាកម្ម/មនុស្ស/ធនធានដែលបាន "ទទួលតួនាទី" ធ្វើអ្វីៗនៅលើ S3 ថាតើវាចូលប្រើធុងជាក់លាក់មួយ... ឬលើសពី 700 ដូចក្នុងករណី Capital One ដែរ។

នៅពេលដែលអ្នកស្ថិតនៅក្នុងឧទាហរណ៍ EC2 ជាមួយនឹងតួនាទី IAM អ្នកអាចទទួលបានព័ត៌មានសម្ងាត់តាមវិធីជាច្រើន៖

1. អ្នកអាចស្នើសុំទិន្នន័យមេតាឧទាហរណ៍នៅ http://169.254.169.254/latest/meta-data

   ក្នុងចំណោមរបស់ផ្សេងទៀត អ្នកអាចស្វែងរកតួនាទី IAM ជាមួយនឹងសោចូលប្រើប្រាស់ណាមួយនៅអាសយដ្ឋាននេះ។ ជាការពិតណាស់លុះត្រាតែអ្នកស្ថិតនៅក្នុងឧទាហរណ៍មួយ។

2. ប្រើ AWS CLI...

   ប្រសិនបើ AWS CLI ត្រូវបានដំឡើង វាត្រូវបានផ្ទុកដោយលិខិតសម្គាល់ពីតួនាទី IAM ប្រសិនបើមានវត្តមាន។ អ្វីដែលនៅសេសសល់គឺត្រូវដំណើរការតាមរយៈឧទាហរណ៍។ ជាការពិតណាស់ ប្រសិនបើគោលការណ៍ទុកចិត្តរបស់ពួកគេបើកចំហ នោះ Paige អាចធ្វើអ្វីៗគ្រប់យ៉ាងដោយផ្ទាល់។

ដូច្នេះខ្លឹមសារនៃតួនាទី IAM គឺថាពួកគេអនុញ្ញាតឱ្យធនធានមួយចំនួនធ្វើសកម្មភាពជំនួសអ្នកលើធនធានផ្សេងទៀត។

ឥឡូវនេះអ្នកយល់ពីតួនាទីរបស់ IAM យើងអាចនិយាយអំពីអ្វីដែល Paige Thompson បានធ្វើ៖

1. នាងទទួលបានសិទ្ធិចូលប្រើម៉ាស៊ីនមេ (ឧទាហរណ៍ EC2) តាមរយៈរន្ធនៅក្នុងជញ្ជាំងភ្លើង

   មិនថាវាជាក្រុមសុវត្ថិភាព/ACLs ឬជញ្ជាំងភ្លើងកម្មវិធីបណ្ដាញផ្ទាល់ខ្លួនរបស់ពួកគេទេ រន្ធនេះប្រហែលជាងាយស្រួលក្នុងការដោត ដូចមានចែងក្នុងកំណត់ត្រាផ្លូវការ។

2. នៅពេលដែលនៅលើម៉ាស៊ីនមេ នាងអាចធ្វើសកម្មភាព "ដូចជាប្រសិនបើ" នាងជាម៉ាស៊ីនមេខ្លួនឯង
3. ដោយសារតួនាទីម៉ាស៊ីនមេ IAM អនុញ្ញាតឱ្យ S3 ចូលប្រើធុង 700+ ទាំងនេះ វាអាចចូលប្រើពួកវាបាន

ចាប់ពីពេលនោះមក អ្វីដែលនាងត្រូវធ្វើគឺរត់ពាក្យបញ្ជា List Bucketsហើយបន្ទាប់មកពាក្យបញ្ជា Sync ពី AWS CLI...

ធនាគារ Capital One បានប៉ាន់ប្រមាណថាការខូចខាតពីការលួចចូលមានចន្លោះពី 100 ទៅ 150 លានដុល្លារ. ការទប់ស្កាត់ការខូចខាតបែបនេះគឺជាមូលហេតុដែលក្រុមហ៊ុនវិនិយោគយ៉ាងច្រើននៅក្នុងការការពារហេដ្ឋារចនាសម្ព័ន្ធពពក DevOps និងអ្នកជំនាញសន្តិសុខ។ ហើយ​តើ​ការ​ផ្លាស់​ប្តូរ​ទៅ​ពពក​មាន​តម្លៃ​និង​ប្រសិទ្ធភាព​កម្រិត​ណា? ច្រើនដូច្នេះ សូម្បីតែប្រឈមមុខនឹងបញ្ហាប្រឈមផ្នែកសន្តិសុខតាមអ៊ីនធឺណិតកាន់តែច្រើនឡើងៗ ទីផ្សារពពកសាធារណៈទាំងមូលបានកើនឡើង 42% នៅក្នុងត្រីមាសទីមួយនៃឆ្នាំ 2019!

សីលធម៌នៃរឿង៖ ពិនិត្យមើលសុវត្ថិភាពរបស់អ្នក; ធ្វើសវនកម្មទៀងទាត់; គោរពគោលការណ៍នៃសិទ្ធិតិចតួចបំផុតសម្រាប់គោលនយោបាយសន្តិសុខ។

(វាគឺជាការ អ្នកអាចមើលរបាយការណ៍ច្បាប់ពេញលេញ)។

ប្រភព: www.habr.com