ការវាយប្រហារប្រភព Trojan ដើម្បីណែនាំការផ្លាស់ប្តូរកូដដែលមើលមិនឃើញសម្រាប់អ្នកអភិវឌ្ឍន៍

អ្នកស្រាវជ្រាវមកពីសាកលវិទ្យាល័យ Cambridge បានបោះពុម្ពផ្សាយបច្ចេកទេសមួយសម្រាប់ការបញ្ចូលកូដព្យាបាទដោយស្ងៀមស្ងាត់ទៅក្នុងប្រភពកូដដែលបានពិនិត្យដោយមិត្តភ័ក្តិ។ វិធីសាស្ត្រវាយប្រហារដែលបានរៀបចំ (CVE-2021-42574) ត្រូវបានបង្ហាញក្រោមឈ្មោះ Trojan Source ហើយផ្អែកលើការបង្កើតអត្ថបទដែលមើលទៅខុសគ្នាសម្រាប់អ្នកចងក្រង/អ្នកបកប្រែ និងអ្នកដែលមើលកូដ។ ឧទាហរណ៍នៃវិធីសាស្ត្រត្រូវបានបង្ហាញសម្រាប់អ្នកចងក្រង និងអ្នកបកប្រែផ្សេងៗដែលផ្គត់ផ្គង់សម្រាប់ C, C++ (gcc និង clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go និង Python ។

វិធីសាស្រ្តគឺផ្អែកលើការប្រើប្រាស់តួអក្សរយូនីកូដពិសេសនៅក្នុងមតិយោបល់កូដដែលផ្លាស់ប្តូរលំដាប់បង្ហាញនៃអត្ថបទទ្វេទិស។ ដោយមានជំនួយពីតួអក្សរបញ្ជាបែបនេះ ផ្នែកខ្លះនៃអត្ថបទអាចត្រូវបានបង្ហាញពីឆ្វេងទៅស្តាំ ចំណែកខ្លះទៀត - ពីស្តាំទៅឆ្វេង។ នៅក្នុងការអនុវត្តប្រចាំថ្ងៃ តួអក្សរត្រួតពិនិត្យបែបនេះអាចត្រូវបានប្រើ ឧទាហរណ៍ ដើម្បីបញ្ចូលបន្ទាត់កូដជាភាសាហេព្រើរ ឬភាសាអារ៉ាប់ទៅក្នុងឯកសារ។ ប៉ុន្តែប្រសិនបើអ្នកបញ្ចូលគ្នានូវបន្ទាត់ដែលមានទិសដៅអត្ថបទផ្សេងៗគ្នាក្នុងបន្ទាត់មួយ ដោយប្រើតួអក្សរដែលបានបញ្ជាក់ អត្ថបទដែលបង្ហាញពីស្តាំទៅឆ្វេងអាចត្រួតលើគ្នាលើអត្ថបទធម្មតាដែលមានស្រាប់ដែលបង្ហាញពីឆ្វេងទៅស្តាំ។

ដោយប្រើវិធីសាស្រ្តនេះ អ្នកអាចបន្ថែមការស្ថាបនាព្យាបាទទៅកូដ ប៉ុន្តែបន្ទាប់មកធ្វើឱ្យអត្ថបទជាមួយនឹងសំណង់នេះមើលមិនឃើញនៅពេលមើលកូដ ដោយបន្ថែមនៅក្នុងមតិយោបល់ខាងក្រោម ឬនៅខាងក្នុងតួអក្សរដែលបង្ហាញពីស្តាំទៅឆ្វេង ដែលនឹងនាំទៅដល់ទាំងស្រុង។ តួអក្សរផ្សេងគ្នាត្រូវបានដាក់លើការបញ្ចូលព្យាបាទ។ កូដបែបនេះនឹងនៅតែត្រឹមត្រូវតាមន័យធៀប ប៉ុន្តែនឹងត្រូវបានបកស្រាយ និងបង្ហាញខុសគ្នា។

នៅពេលពិនិត្យមើលកូដ អ្នកអភិវឌ្ឍន៍នឹងត្រូវប្រឈមមុខនឹងលំដាប់ដែលមើលឃើញនៃតួអក្សរ ហើយនឹងឃើញមតិយោបល់ដែលមិនគួរឱ្យសង្ស័យនៅក្នុងកម្មវិធីនិពន្ធអត្ថបទទំនើប ចំណុចប្រទាក់គេហទំព័រ ឬ IDE ប៉ុន្តែអ្នកចងក្រង និងអ្នកបកប្រែនឹងប្រើលំដាប់ឡូជីខលនៃតួអក្សរ ហើយនឹង ដំណើរការ​ការ​បញ្ចូល​ព្យាបាទ​ដូច​ដែល​មាន​ដោយ​មិន​បាន​យក​ចិត្ត​ទុក​ដាក់​ចំពោះ​អត្ថបទ​ពីរ​ទិស​ក្នុង​មតិយោបល់។ បញ្ហានេះប៉ះពាល់ដល់កម្មវិធីកែកូដដ៏ពេញនិយមជាច្រើន (VS Code, Emacs, Atom) ក៏ដូចជាចំណុចប្រទាក់សម្រាប់មើលកូដនៅក្នុងឃ្លាំង (GitHub, Gitlab, BitBucket និងផលិតផល Atlassian ទាំងអស់)។

មានវិធីជាច្រើនក្នុងការប្រើវិធីសាស្ត្រដើម្បីអនុវត្តសកម្មភាពព្យាបាទ៖ ការបន្ថែមកន្សោម "ត្រឡប់" ដែលលាក់ ដែលនាំទៅដល់ការបញ្ចប់មុខងារមុនពេលវេលា។ ការបញ្ចេញមតិដែលជាធម្មតាអាចមើលឃើញថាជាការសាងសង់ត្រឹមត្រូវ (ឧទាហរណ៍ ដើម្បីបិទការត្រួតពិនិត្យសំខាន់ៗ); ផ្តល់តម្លៃខ្សែអក្សរផ្សេងទៀតដែលនាំទៅដល់ការបរាជ័យក្នុងសុពលភាពខ្សែអក្សរ។

ឧទាហរណ៍ អ្នកវាយប្រហារអាចស្នើការផ្លាស់ប្តូរដែលរួមបញ្ចូលបន្ទាត់៖ if access_level != "អ្នកប្រើប្រាស់{U+202E} {U+2066}// ពិនិត្យមើលថាតើអ្នកគ្រប់គ្រង{U+2069} {U+2066}" {

ដែលនឹងត្រូវបានបង្ហាញនៅក្នុងចំណុចប្រទាក់ពិនិត្យឡើងវិញដូចជាប្រសិនបើ access_level != "អ្នកប្រើប្រាស់" { // ពិនិត្យមើលថាតើអ្នកគ្រប់គ្រង

លើសពីនេះ វ៉ារ្យ៉ង់នៃការវាយប្រហារមួយផ្សេងទៀតត្រូវបានស្នើឡើង (CVE-2021-42694) ដែលទាក់ទងនឹងការប្រើប្រាស់ពាក្យ homoglyphs តួអក្សរដែលមានលក្ខណៈស្រដៀងគ្នា ប៉ុន្តែមានអត្ថន័យខុសៗគ្នា និងមានលេខកូដយូនីកូដផ្សេងៗគ្នា (ឧទាហរណ៍ តួអក្សរ “ɑ” ស្រដៀងនឹង “ a", "ɡ" - "g", "ɩ" - "l") ។ តួអក្សរស្រដៀងគ្នាអាចត្រូវបានប្រើជាភាសាមួយចំនួននៅក្នុងឈ្មោះមុខងារ និងអថេរដើម្បីបំភាន់អ្នកអភិវឌ្ឍន៍។ ឧទាហរណ៍ មុខងារពីរដែលមានឈ្មោះមិនអាចបែងចែកបានអាចត្រូវបានកំណត់ដែលអនុវត្តសកម្មភាពផ្សេងគ្នា។ បើគ្មានការវិភាគលម្អិតទេ វាមិនច្បាស់ភ្លាមៗថាតើមុខងារទាំងពីរនេះមួយណាត្រូវបានហៅនៅកន្លែងជាក់លាក់មួយ។

ជាវិធានការសុវត្ថិភាព វាត្រូវបានណែនាំឱ្យអ្នកចងក្រង អ្នកបកប្រែ និងឧបករណ៍ផ្គុំដែលគាំទ្រតួអក្សរយូនីកូដបង្ហាញកំហុស ឬការព្រមានប្រសិនបើមានតួអក្សរគ្រប់គ្រងដែលមិនផ្គូផ្គងនៅក្នុងមតិយោបល់ អក្សរអក្សរ ឬឧបករណ៍កំណត់ដែលផ្លាស់ប្តូរទិសដៅនៃលទ្ធផល (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E និង U+200F)។ តួអក្សរបែបនេះក៏គួរតែត្រូវបានហាមឃាត់យ៉ាងច្បាស់លាស់នៅក្នុងការកំណត់ភាសាសរសេរកម្មវិធី ហើយគួរតែត្រូវបានគោរពនៅក្នុងកម្មវិធីនិពន្ធកូដ និងចំណុចប្រទាក់ឃ្លាំង។

ឧបសម្ព័ន្ធទី 1៖ បំណះភាពងាយរងគ្រោះត្រូវបានរៀបចំសម្រាប់ GCC, LLVM/Clang, Rust, Go, Python និង binutils ។ GitHub, Bitbucket និង Jira ក៏បានដោះស្រាយបញ្ហានេះផងដែរ។ ការជួសជុលសម្រាប់ GitLab កំពុងដំណើរការ។ ដើម្បីកំណត់អត្តសញ្ញាណកូដដែលមានបញ្ហា វាត្រូវបានស្នើឱ្យប្រើពាក្យបញ្ជា៖ grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/'] ប្រភព

ឧបសម្ព័ន្ធទី 2៖ Russ Cox ដែលជាអ្នកបង្កើត Plan 9 OS និងភាសាកម្មវិធី Go បានរិះគន់ការយកចិត្តទុកដាក់ហួសហេតុចំពោះវិធីសាស្ត្រវាយប្រហារដែលបានពិពណ៌នា ដែលត្រូវបានគេស្គាល់ជាយូរមកហើយ (Go, Rust, C++, Ruby) ហើយមិនត្រូវបានគេយកចិត្តទុកដាក់ខ្លាំងនោះទេ។ . យោងតាមលោក Cox បញ្ហាចម្បងទាក់ទងនឹងការបង្ហាញត្រឹមត្រូវនៃព័ត៌មាននៅក្នុងកម្មវិធីនិពន្ធកូដ និងចំណុចប្រទាក់គេហទំព័រ ដែលអាចដោះស្រាយបានដោយប្រើឧបករណ៍ត្រឹមត្រូវ និងឧបករណ៍វិភាគកូដអំឡុងពេលពិនិត្យ។ ដូច្នេះ ជំនួសឱ្យការទាក់ទាញការយកចិត្តទុកដាក់ចំពោះការវាយប្រហារតាមការប៉ាន់ស្មាន វាជាការសមស្របជាងក្នុងការផ្តោតលើការកែលម្អដំណើរការពិនិត្យកូដ និងការពឹងផ្អែក។

Ras Cox ក៏ជឿថាអ្នកចងក្រងមិនមែនជាកន្លែងត្រឹមត្រូវដើម្បីដោះស្រាយបញ្ហានោះទេ ព្រោះដោយការហាមឃាត់និមិត្តសញ្ញាគ្រោះថ្នាក់នៅកម្រិតអ្នកចងក្រង វានៅមានស្រទាប់ដ៏ធំនៃឧបករណ៍ដែលការប្រើប្រាស់និមិត្តសញ្ញាទាំងនេះនៅតែអាចទទួលយកបាន ដូចជាប្រព័ន្ធសាងសង់ ឧបករណ៍ដំឡើងជាដើម។ កម្មវិធីគ្រប់គ្រងកញ្ចប់ និងឧបករណ៍ញែកការកំណត់រចនាសម្ព័ន្ធផ្សេងៗ និងទិន្នន័យ។ ជាឧទាហរណ៍ គម្រោង Rust ត្រូវបានផ្តល់ឱ្យ ដែលហាមឃាត់ដំណើរការនៃកូដ LTR/RTL នៅក្នុងកម្មវិធីចងក្រង ប៉ុន្តែមិនបានបន្ថែមការជួសជុលទៅកាន់កម្មវិធីគ្រប់គ្រងកញ្ចប់ទំនិញ ដែលអនុញ្ញាតឱ្យមានការវាយប្រហារស្រដៀងគ្នាតាមរយៈឯកសារ Cargo.toml ។ ដូចគ្នាដែរ ឯកសារដូចជា BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml និង require.txt អាចក្លាយជាប្រភពនៃការវាយប្រហារ។

ប្រភព: opennet.ru