ການກວດສອບຄວາມປອດໄພຂອງເວທີຄລາວ MCS

SkyShip Dusk ໂດຍ SeeerLight

ການກໍ່ສ້າງການບໍລິການໃດໆທີ່ຈໍາເປັນປະກອບມີການເຮັດວຽກຢ່າງຕໍ່ເນື່ອງກ່ຽວກັບຄວາມປອດໄພ. ຄວາມປອດໄພແມ່ນຂະບວນການຢ່າງຕໍ່ເນື່ອງເຊິ່ງປະກອບມີການວິເຄາະຢ່າງຕໍ່ເນື່ອງແລະການປັບປຸງຄວາມປອດໄພຂອງຜະລິດຕະພັນ, ການຕິດຕາມຂ່າວກ່ຽວກັບຄວາມອ່ອນແອແລະອື່ນໆ. ລວມທັງການກວດສອບ. ການກວດສອບແມ່ນດໍາເນີນການທັງພາຍໃນແລະພາຍໃນໂດຍຜູ້ຊ່ຽວຊານພາຍນອກ, ຜູ້ທີ່ສາມາດຊ່ວຍຄວາມປອດໄພຢ່າງຫຼວງຫຼາຍຍ້ອນວ່າພວກເຂົາບໍ່ໄດ້ເຂົ້າໄປໃນໂຄງການແລະມີຈິດໃຈເປີດ.

ບົດຄວາມແມ່ນກ່ຽວກັບທັດສະນະທີ່ກົງໄປກົງມານີ້ຂອງຜູ້ຊ່ຽວຊານພາຍນອກທີ່ຊ່ວຍທີມງານ Mail.ru Cloud Solutions (MCS) ທົດສອບການບໍລິການຟັງ, ແລະກ່ຽວກັບສິ່ງທີ່ພວກເຂົາພົບ. ໃນຖານະເປັນ "ກໍາລັງພາຍນອກ," MCS ໄດ້ເລືອກບໍລິສັດຄວາມປອດໄພດິຈິຕອນ, ເປັນທີ່ຮູ້ຈັກສໍາລັບຄວາມຊໍານານສູງໃນວົງການຄວາມປອດໄພຂໍ້ມູນຂ່າວສານ. ແລະໃນບົດຄວາມນີ້ພວກເຮົາຈະວິເຄາະບາງຊ່ອງໂຫວ່ທີ່ຫນ້າສົນໃຈທີ່ພົບເຫັນເປັນສ່ວນຫນຶ່ງຂອງການກວດສອບພາຍນອກ - ດັ່ງນັ້ນທ່ານຫຼີກເວັ້ນການ rake ດຽວກັນໃນເວລາທີ່ທ່ານສ້າງບໍລິການຟັງຂອງທ່ານເອງ.

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

Mail.ru Cloud Solutions (MCS) ເປັນເວທີສໍາລັບການກໍ່ສ້າງໂຄງສ້າງພື້ນຖານ virtual ໃນຄລາວ. ມັນປະກອບມີ IaaS, PaaS, ແລະຕະຫຼາດຂອງຮູບພາບຄໍາຮ້ອງສະຫມັກທີ່ກຽມພ້ອມສໍາລັບນັກພັດທະນາ. ຄໍານຶງເຖິງສະຖາປັດຕະຍະກໍາ MCS, ມັນຈໍາເປັນຕ້ອງໄດ້ກວດກາຄວາມປອດໄພຂອງຜະລິດຕະພັນໃນຂົງເຂດດັ່ງຕໍ່ໄປນີ້:

• ການປົກປ້ອງໂຄງສ້າງພື້ນຖານຂອງສະພາບແວດລ້ອມ virtualization: hypervisors, routing, firewalls;
• ການປົກປ້ອງພື້ນຖານໂຄງລ່າງ virtual ຂອງລູກຄ້າ: ການໂດດດ່ຽວຈາກກັນແລະກັນ, ລວມທັງເຄືອຂ່າຍ, ເຄືອຂ່າຍເອກະຊົນໃນ SDN;
• OpenStack ແລະອົງປະກອບເປີດຂອງມັນ;
• S3 ຂອງການອອກແບບຂອງພວກເຮົາເອງ;
• IAM: ໂຄງການຫຼາຍຜູ້ເຊົ່າທີ່ມີຕົວແບບ;
• ວິໄສທັດ (ວິໄສທັດຄອມພິວເຕີ): APIs ແລະຈຸດອ່ອນໃນເວລາທີ່ເຮັດວຽກກັບຮູບພາບ;
• ການໂຕ້ຕອບເວັບໄຊຕ໌ແລະການໂຈມຕີເວັບໄຊຕ໌ຄລາສສິກ;
• ຄວາມອ່ອນແອຂອງອົງປະກອບ PaaS;
• API ຂອງອົງປະກອບທັງໝົດ.

ບາງທີນັ້ນແມ່ນສິ່ງທີ່ຈໍາເປັນສໍາລັບປະຫວັດສາດຕໍ່ໄປ.

ປະເພດໃດແດ່ທີ່ໄດ້ປະຕິບັດແລະເປັນຫຍັງມັນຈໍາເປັນຕ້ອງ?

ການກວດສອບຄວາມປອດໄພແມ່ນແນໃສ່ການກໍານົດຈຸດອ່ອນ ແລະຄວາມຜິດພາດໃນການຕັ້ງຄ່າທີ່ອາດນໍາໄປສູ່ການຮົ່ວໄຫຼຂອງຂໍ້ມູນສ່ວນຕົວ, ການແກ້ໄຂຂໍ້ມູນທີ່ລະອຽດອ່ອນ, ຫຼືການຂັດຂວາງການໃຫ້ບໍລິການ.

ໃນລະຫວ່າງການເຮັດວຽກ, ເຊິ່ງໃຊ້ເວລາໂດຍສະເລ່ຍ 1-2 ເດືອນ, ຜູ້ກວດສອບໄດ້ເຮັດຊ້ໍາຄືນການປະຕິບັດຂອງຜູ້ໂຈມຕີທີ່ມີທ່າແຮງແລະຊອກຫາຈຸດອ່ອນໃນພາກສ່ວນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍຂອງການບໍລິການທີ່ເລືອກ. ໃນສະພາບການຂອງການກວດສອບເວທີຄລາວຂອງ MCS, ເປົ້າໝາຍຕໍ່ໄປນີ້ໄດ້ຖືກລະບຸ:

1. ການວິເຄາະການກວດສອບຄວາມຖືກຕ້ອງໃນການບໍລິການ. ຊ່ອງໂຫວ່ໃນອົງປະກອບນີ້ຈະຊ່ວຍໃຫ້ເຂົ້າໄປໃນບັນຊີຂອງຄົນອື່ນໄດ້ທັນທີ.
2. ການສຶກສາຮູບແບບພາລະບົດບາດແລະການຄວບຄຸມການເຂົ້າເຖິງລະຫວ່າງບັນຊີທີ່ແຕກຕ່າງກັນ. ສໍາລັບຜູ້ໂຈມຕີ, ຄວາມສາມາດໃນການເຂົ້າເຖິງເຄື່ອງ virtual ຂອງຄົນອື່ນແມ່ນເປົ້າຫມາຍທີ່ຕ້ອງການ.
3. ຄວາມອ່ອນແອຂອງຝ່າຍລູກຄ້າ. XSS/CSRF/CRLF/ແລະອື່ນໆ. ມັນເປັນໄປໄດ້ທີ່ຈະໂຈມຕີຜູ້ໃຊ້ອື່ນໆໂດຍຜ່ານການເຊື່ອມຕໍ່ທີ່ເປັນອັນຕະລາຍບໍ?
4. ຊ່ອງໂຫວ່ຂອງເຊີບເວີ: RCE ແລະການສັກຢາທຸກປະເພດ (SQL/XXE/SSRF ແລະອື່ນໆ). ຄວາມອ່ອນແອຂອງເຄື່ອງແມ່ຂ່າຍໂດຍທົ່ວໄປແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະຊອກຫາ, ແຕ່ພວກມັນນໍາໄປສູ່ການປະນີປະນອມຂອງຜູ້ໃຊ້ຈໍານວນຫຼາຍໃນເວລາດຽວກັນ.
5. ການວິເຄາະການແຍກສ່ວນຜູ້ໃຊ້ໃນລະດັບເຄືອຂ່າຍ. ສໍາລັບຜູ້ໂຈມຕີ, ການຂາດການໂດດດ່ຽວເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍຕໍ່ຫນ້າການໂຈມຕີຕໍ່ກັບຜູ້ໃຊ້ອື່ນໆ.
6. ການວິເຄາະເຫດຜົນທາງທຸລະກິດ. ມັນເປັນໄປໄດ້ທີ່ຈະຫລອກລວງທຸລະກິດແລະສ້າງເຄື່ອງຈັກ virtual ຟຣີບໍ?

ໃນໂຄງການນີ້, ວຽກງານໄດ້ຖືກປະຕິບັດຕາມແບບຈໍາລອງ "Grey-box": ຜູ້ກວດສອບໄດ້ພົວພັນກັບການບໍລິການທີ່ມີສິດທິພິເສດຂອງຜູ້ໃຊ້ທົ່ວໄປ, ແຕ່ບາງສ່ວນມີລະຫັດແຫຼ່ງຂອງ API ແລະມີໂອກາດທີ່ຈະຊີ້ແຈງລາຍລະອຽດກັບຜູ້ພັດທະນາ. ນີ້ປົກກະຕິແລ້ວແມ່ນສະດວກທີ່ສຸດ, ແລະໃນເວລາດຽວກັນເປັນຕົວແບບທີ່ແທ້ຈິງຂອງການເຮັດວຽກ: ຂໍ້ມູນພາຍໃນຍັງສາມາດເກັບກໍາໂດຍຜູ້ໂຈມຕີ, ມັນເປັນພຽງແຕ່ເວລາ.

ພົບຊ່ອງໂຫວ່

ກ່ອນທີ່ຜູ້ກວດສອບເລີ່ມສົ່ງ payloads ຕ່າງໆ (payload ທີ່ໃຊ້ໃນການໂຈມຕີ) ໄປຫາສະຖານທີ່ແບບສຸ່ມ, ມັນຈໍາເປັນຕ້ອງເຂົ້າໃຈວິທີການເຮັດວຽກແລະຫນ້າທີ່ສະຫນອງໃຫ້. ມັນອາດຈະເບິ່ງຄືວ່ານີ້ແມ່ນການອອກກໍາລັງກາຍທີ່ບໍ່ມີປະໂຫຍດ, ເພາະວ່າໃນສະຖານທີ່ສຶກສາສ່ວນໃຫຍ່ຈະບໍ່ມີຄວາມສ່ຽງ. ແຕ່ພຽງແຕ່ຄວາມເຂົ້າໃຈໂຄງສ້າງຂອງຄໍາຮ້ອງສະຫມັກແລະເຫດຜົນຂອງການດໍາເນີນງານຂອງມັນຈະເຮັດໃຫ້ສາມາດຊອກຫາ vectors ການໂຈມຕີທີ່ສັບສົນທີ່ສຸດ.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຊອກຫາສະຖານທີ່ທີ່ເບິ່ງຄືວ່າສົງໃສຫຼືມີຄວາມແຕກຕ່າງກັນຫຼາຍຈາກຄົນອື່ນໃນບາງທາງ. ແລະຈຸດອ່ອນທີ່ເປັນອັນຕະລາຍທໍາອິດໄດ້ຖືກພົບເຫັນໃນທາງນີ້.

IDOR

ຊ່ອງໂຫວ່ IDOR (Insecure Direct Object Reference) ແມ່ນໜຶ່ງໃນຊ່ອງໂຫວ່ທີ່ພົບເລື້ອຍທີ່ສຸດໃນເຫດຜົນທາງທຸລະກິດ, ເຊິ່ງອະນຸຍາດໃຫ້ໜຶ່ງ ຫຼືອີກອັນໜຶ່ງເຂົ້າເຖິງວັດຖຸທີ່ການເຂົ້າເຖິງບໍ່ໄດ້ອະນຸຍາດໃຫ້ຕົວຈິງ. ຊ່ອງໂຫວ່ຂອງ IDOR ສ້າງຄວາມເປັນໄປໄດ້ຂອງການໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ທີ່ມີລະດັບຄວາມວິຈານທີ່ແຕກຕ່າງກັນ.

ຫນຶ່ງໃນທາງເລືອກ IDOR ແມ່ນການດໍາເນີນການກັບວັດຖຸລະບົບ (ຜູ້ໃຊ້, ບັນຊີທະນາຄານ, ລາຍການໃນກະຕ່າຊື້ເຄື່ອງ) ໂດຍການຈັດການຕົວລະບຸການເຂົ້າເຖິງຂອງວັດຖຸເຫຼົ່ານີ້. ນີ້ນໍາໄປສູ່ຜົນສະທ້ອນທີ່ບໍ່ສາມາດຄາດເດົາໄດ້ຫຼາຍທີ່ສຸດ. ຕົວຢ່າງ, ຄວາມເປັນໄປໄດ້ຂອງການປ່ຽນບັນຊີຂອງຜູ້ສົ່ງເງິນ, ໂດຍຜ່ານທີ່ທ່ານສາມາດລັກພວກເຂົາຈາກຜູ້ໃຊ້ອື່ນໆ.

ໃນກໍລະນີຂອງ MCS, ຜູ້ກວດສອບພຽງແຕ່ຄົ້ນພົບຈຸດອ່ອນຂອງ IDOR ທີ່ກ່ຽວຂ້ອງກັບຕົວລະບຸທີ່ບໍ່ປອດໄພ. ໃນບັນຊີສ່ວນຕົວຂອງຜູ້ໃຊ້, ຕົວລະບຸ UUID ໄດ້ຖືກນໍາໃຊ້ເພື່ອເຂົ້າເຖິງວັດຖຸໃດໆ, ເຊິ່ງເບິ່ງຄືວ່າ, ດັ່ງທີ່ຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພເວົ້າວ່າ, ມີຄວາມປະທັບໃຈທີ່ບໍ່ປອດໄພ (ນັ້ນແມ່ນ, ໄດ້ຮັບການປົກປ້ອງຈາກການໂຈມຕີໂດຍບັງເອີນ). ແຕ່ສໍາລັບບາງຫນ່ວຍງານ, ມັນໄດ້ຖືກຄົ້ນພົບວ່າຕົວເລກທີ່ຄາດເດົາໄດ້ປົກກະຕິແມ່ນໃຊ້ເພື່ອໃຫ້ໄດ້ຂໍ້ມູນກ່ຽວກັບຜູ້ໃຊ້ຂອງແອັບພລິເຄຊັນ. ຂ້າພະເຈົ້າຄິດວ່າທ່ານສາມາດເດົາໄດ້ວ່າມັນເປັນໄປໄດ້ທີ່ຈະປ່ຽນ ID ຜູ້ໃຊ້ໂດຍຫນຶ່ງ, ສົ່ງຄໍາຮ້ອງຂໍອີກເທື່ອຫນຶ່ງແລະດັ່ງນັ້ນຈຶ່ງໄດ້ຮັບຂໍ້ມູນຜ່ານ ACL (ບັນຊີການຄວບຄຸມການເຂົ້າເຖິງ, ກົດລະບຽບການເຂົ້າເຖິງຂໍ້ມູນສໍາລັບຂະບວນການແລະຜູ້ໃຊ້).

ການປອມແປງການຮ້ອງຂໍດ້ານເຊີບເວີ (SSRF)

ຜະລິດຕະພັນ OpenSource ແມ່ນດີເພາະວ່າພວກເຂົາມີເວທີປາໄສຈໍານວນຫລາຍທີ່ມີລາຍລະອຽດດ້ານວິຊາການກ່ຽວກັບບັນຫາທີ່ເກີດຂື້ນແລະຖ້າທ່ານໂຊກດີ, ຄໍາອະທິບາຍກ່ຽວກັບການແກ້ໄຂ. ແຕ່ຫຼຽນນີ້ມີຈຸດອ່ອນ: ຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກແມ່ນຍັງຖືກອະທິບາຍຢ່າງລະອຽດ. ຕົວຢ່າງ, ມີຄໍາອະທິບາຍທີ່ປະເສີດກ່ຽວກັບຊ່ອງໂຫວ່ຢູ່ໃນເວທີ OpenStack [XSS] и [SSRF], ເຊິ່ງສໍາລັບບາງເຫດຜົນບໍ່ມີໃຜຢູ່ໃນ hurry ທີ່ຈະແກ້ໄຂ.

ການເຮັດວຽກທົ່ວໄປຂອງແອັບພລິເຄຊັນແມ່ນຄວາມສາມາດສໍາລັບຜູ້ໃຊ້ທີ່ຈະສົ່ງການເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ, ເຊິ່ງເຄື່ອງແມ່ຂ່າຍຄລິກໃສ່ (ຕົວຢ່າງ, ເພື່ອດາວໂຫລດຮູບພາບຈາກແຫຼ່ງທີ່ລະບຸ). ຖ້າເຄື່ອງມືຄວາມປອດໄພບໍ່ໄດ້ກັ່ນຕອງການເຊື່ອມຕໍ່ດ້ວຍຕົນເອງຫຼືຄໍາຕອບທີ່ສົ່ງຄືນຈາກເຄື່ອງແມ່ຂ່າຍໄປຫາຜູ້ໃຊ້, ຫນ້າທີ່ດັ່ງກ່າວສາມາດຖືກນໍາໃຊ້ໂດຍຜູ້ໂຈມຕີໄດ້ງ່າຍ.

ຄວາມອ່ອນແອຂອງ SSRF ສາມາດພັດທະນາການໂຈມຕີໄດ້ຢ່າງຫຼວງຫຼາຍ. ຜູ້ໂຈມຕີສາມາດໄດ້ຮັບ:

• ການຈໍາກັດການເຂົ້າເຖິງເຄືອຂ່າຍທ້ອງຖິ່ນທີ່ຖືກໂຈມຕີ, ຕົວຢ່າງ, ພຽງແຕ່ຜ່ານບາງສ່ວນເຄືອຂ່າຍແລະການນໍາໃຊ້ໂປໂຕຄອນທີ່ແນ່ນອນ;
• ການເຂົ້າເຖິງເຄືອຂ່າຍທ້ອງຖິ່ນຢ່າງເຕັມທີ່, ຖ້າການຫຼຸດລົງຈາກລະດັບຄໍາຮ້ອງສະຫມັກໄປສູ່ລະດັບການຂົນສົ່ງແມ່ນເປັນໄປໄດ້ແລະ, ດັ່ງນັ້ນ, ການຄຸ້ມຄອງການໂຫຼດຢ່າງເຕັມທີ່ໃນລະດັບຄໍາຮ້ອງສະຫມັກ;
• ການ​ເຂົ້າ​ເຖິງ​ການ​ອ່ານ​ໄຟລ​໌​ທ້ອງ​ຖິ່ນ​ໃນ​ເຄື່ອງ​ແມ່​ຂ່າຍ (ຖ້າ​ຫາກ​ວ່າ file:/// ໂຄງ​ການ​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​)​;
• ແລະຫຼາຍ.

ຊ່ອງໂຫວ່ຂອງ SSRF ເປັນທີ່ຮູ້ກັນມາດົນແລ້ວໃນ OpenStack, ເຊິ່ງແມ່ນ "ຕາບອດ" ໃນລັກສະນະ: ເມື່ອທ່ານຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ, ທ່ານບໍ່ໄດ້ຮັບການຕອບສະຫນອງຈາກມັນ, ແຕ່ທ່ານໄດ້ຮັບປະເພດຕ່າງໆຂອງຄວາມຜິດພາດ / ການຊັກຊ້າ, ອີງຕາມຜົນຂອງການຮ້ອງຂໍ. . ອີງຕາມການນີ້, ທ່ານສາມາດປະຕິບັດການສະແກນພອດໃນໂຮດຢູ່ໃນເຄືອຂ່າຍພາຍໃນ, ໂດຍມີຜົນສະທ້ອນທີ່ເກີດຂື້ນທັງຫມົດທີ່ບໍ່ຄວນຄາດເດົາ. ຕົວຢ່າງ, ຜະລິດຕະພັນອາດມີ back-office API ທີ່ສາມາດເຂົ້າເຖິງໄດ້ຈາກເຄືອຂ່າຍອົງກອນເທົ່ານັ້ນ. ດ້ວຍເອກະສານ (ຢ່າລືມກ່ຽວກັບພາຍໃນ), ຜູ້ໂຈມຕີສາມາດໃຊ້ SSRF ເພື່ອເຂົ້າເຖິງວິທີການພາຍໃນ. ຕົວຢ່າງ, ຖ້າທ່ານສາມາດໄດ້ຮັບບັນຊີລາຍຊື່ປະມານຂອງ URLs ທີ່ເປັນປະໂຫຍດ, ຫຼັງຈາກນັ້ນການນໍາໃຊ້ SSRF ທ່ານສາມາດຜ່ານພວກມັນແລະປະຕິບັດຄໍາຮ້ອງຂໍ - ເວົ້າຂ້ອນຂ້າງ, ໂອນເງິນຈາກບັນຊີໄປຫາບັນຊີຫຼືການປ່ຽນແປງຂອບເຂດຈໍາກັດ.

ນີ້ບໍ່ແມ່ນຄັ້ງທຳອິດທີ່ພົບຊ່ອງໂຫວ່ SSRF ໃນ OpenStack. ໃນໄລຍະຜ່ານມາ, ມັນສາມາດດາວໂຫລດຮູບພາບ VM ISO ຈາກການເຊື່ອມຕໍ່ໂດຍກົງ, ເຊິ່ງຍັງນໍາໄປສູ່ຜົນສະທ້ອນທີ່ຄ້າຍຄືກັນ. ຕອນນີ້ຄຸນສົມບັດນີ້ຖືກລຶບອອກຈາກ OpenStack ແລ້ວ. ປາກົດຂື້ນ, ຊຸມຊົນພິຈາລະນານີ້ເປັນການແກ້ໄຂທີ່ງ່າຍດາຍທີ່ສຸດແລະເຊື່ອຖືໄດ້ທີ່ສຸດຕໍ່ບັນຫາ.

ແລະໃນ ນີ້ ບົດລາຍງານທີ່ເປີດເຜີຍສາທາລະນະຈາກການບໍລິການ HackerOne (h1), ການຂຸດຄົ້ນ SSRF ທີ່ບໍ່ມີຕາບອດອີກຕໍ່ໄປດ້ວຍຄວາມສາມາດໃນການອ່ານ metadata ຂອງຕົວຢ່າງເຮັດໃຫ້ການເຂົ້າເຖິງຮາກຂອງໂຄງສ້າງພື້ນຖານຂອງ Shopify ທັງຫມົດ.

ໃນ MCS, ຊ່ອງໂຫວ່ SSRF ໄດ້ຖືກຄົ້ນພົບຢູ່ໃນສອງບ່ອນທີ່ມີຫນ້າທີ່ຄ້າຍຄືກັນ, ແຕ່ພວກມັນເກືອບເປັນໄປບໍ່ໄດ້ທີ່ຈະຂູດຮີດເນື່ອງຈາກໄຟວໍແລະການປົກປ້ອງອື່ນໆ. ບໍ່ທາງໃດທາງໜຶ່ງ, ທີມງານ MCS ໄດ້ແກ້ໄຂບັນຫານີ້ຢ່າງໃດກໍ່ຕາມ, ໂດຍບໍ່ຕ້ອງລໍຖ້າຊຸມຊົນ.

XSS ແທນການໂຫຼດແກະ

ເຖິງວ່າຈະມີການສຶກສາຫຼາຍຮ້ອຍບົດ, ການໂຈມຕີ XSS (ຂ້າມເວັບໄຊທ໌) ໃນແຕ່ລະປີແມ່ນຍັງມີຫຼາຍທີ່ສຸດ ພົບເລື້ອຍໆ ຄວາມອ່ອນແອຂອງເວັບ (ຫຼື ໂຈມຕີ?)

ການອັບໂຫລດໄຟລ໌ແມ່ນສະຖານທີ່ທີ່ມັກທີ່ສຸດສໍາລັບນັກຄົ້ນຄວ້າຄວາມປອດໄພໃດໆ. ມັນມັກຈະປາກົດວ່າທ່ານສາມາດໂຫລດ script arbitrary (asp / jsp / php) ແລະປະຕິບັດຄໍາສັ່ງ OS, ໃນຄໍາສັບຂອງ pentesters - "load shell". ແຕ່ຄວາມນິຍົມຂອງຊ່ອງໂຫວ່ດັ່ງກ່າວເຮັດວຽກຢູ່ໃນທັງສອງທິດທາງ: ພວກມັນຖືກຈື່ຈໍາແລະການແກ້ໄຂໄດ້ຖືກພັດທະນາຕໍ່ກັບພວກມັນ, ດັ່ງນັ້ນ, ບໍ່ດົນມານີ້, ຄວາມເປັນໄປໄດ້ຂອງ "ການໂຫຼດແກະ" ມີແນວໂນ້ມທີ່ຈະສູນ.

ທີມງານໂຈມຕີ (ສະແດງໂດຍ Digital Security) ໂຊກດີ. ຕົກລົງ, ໃນ MCS ຢູ່ຂ້າງເຊີບເວີ, ເນື້ອໃນຂອງໄຟລ໌ທີ່ດາວໂຫຼດມາໄດ້ຖືກກວດສອບ, ມີພຽງແຕ່ຮູບພາບເທົ່ານັ້ນ. ແຕ່ SVG ຍັງເປັນຮູບ. ຮູບພາບ SVG ເປັນອັນຕະລາຍແນວໃດ? ເພາະວ່າທ່ານສາມາດຝັງ snippets JavaScript ເຂົ້າໄປໃນພວກມັນໄດ້!

ມັນໄດ້ຫັນອອກວ່າໄຟລ໌ທີ່ດາວໂຫລດມີໃຫ້ກັບຜູ້ໃຊ້ບໍລິການ MCS ທັງຫມົດ, ຊຶ່ງຫມາຍຄວາມວ່າມັນເປັນໄປໄດ້ທີ່ຈະໂຈມຕີຜູ້ໃຊ້ຟັງອື່ນໆ, ຄືຜູ້ບໍລິຫານ.

ຕົວຢ່າງຂອງການໂຈມຕີ XSS ໃນແບບຟອມເຂົ້າສູ່ລະບົບ phishing

ຕົວຢ່າງຂອງການໂຈມຕີ XSS:

• ເປັນຫຍັງພະຍາຍາມລັກເອົາເຊດຊັນ (ໂດຍສະເພາະໃນປັດຈຸບັນ HTTP-Only cookies ມີຢູ່ທົ່ວທຸກແຫ່ງ, ປ້ອງກັນການລັກໂດຍໃຊ້ js scripts), ຖ້າສະຄິບທີ່ໂຫລດສາມາດເຂົ້າຫາ API ຊັບພະຍາກອນໄດ້ທັນທີ? ໃນກໍລະນີນີ້, payload ສາມາດໃຊ້ການຮ້ອງຂໍ XHR ເພື່ອປ່ຽນການຕັ້ງຄ່າເຊີບເວີ, ຕົວຢ່າງ, ເພີ່ມລະຫັດ SSH ສາທາລະນະຂອງຜູ້ໂຈມຕີແລະໄດ້ຮັບການເຂົ້າເຖິງ SSH ກັບເຄື່ອງແມ່ຂ່າຍ.
• ຖ້ານະໂຍບາຍ CSP (ນະໂຍບາຍການປົກປ້ອງເນື້ອຫາ) ຫ້າມ JavaScript ຈາກການຖືກໃສ່, ຜູ້ໂຈມຕີສາມາດຜ່ານໄດ້ໂດຍບໍ່ມີມັນ. ການນໍາໃຊ້ HTML ບໍລິສຸດ, ສ້າງແບບຟອມການເຂົ້າສູ່ລະບົບປອມສໍາລັບເວັບໄຊທ໌ແລະລັກລະຫັດຜ່ານຂອງຜູ້ເບິ່ງແຍງລະບົບຜ່ານ phishing ຂັ້ນສູງນີ້: ຫນ້າ phishing ສໍາລັບຜູ້ໃຊ້ສິ້ນສຸດລົງຢູ່ URL ດຽວກັນ, ແລະມັນມີຄວາມຫຍຸ້ງຍາກຫຼາຍສໍາລັບຜູ້ໃຊ້ທີ່ຈະກວດພົບມັນ.
• ສຸດທ້າຍ, ຜູ້ໂຈມຕີສາມາດຈັດແຈງ ລູກຄ້າ DoS — ຕັ້ງ Cookies ໃຫຍ່ກວ່າ 4 KB. ຜູ້ໃຊ້ພຽງແຕ່ຕ້ອງການເປີດການເຊື່ອມຕໍ່ຄັ້ງດຽວ, ແລະເວັບໄຊທ໌ທັງຫມົດຈະກາຍເປັນທີ່ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຈົນກ່ວາຜູ້ໃຊ້ຄິດວ່າຈະເຮັດຄວາມສະອາດຕົວທ່ອງເວັບໂດຍສະເພາະ: ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເຄື່ອງແມ່ຂ່າຍເວັບຈະປະຕິເສດການຍອມຮັບລູກຄ້າດັ່ງກ່າວ.

ໃຫ້ເບິ່ງຕົວຢ່າງຂອງ XSS ອື່ນທີ່ກວດພົບ, ເວລານີ້ດ້ວຍການຂຸດຄົ້ນທີ່ສະຫລາດກວ່າ. ການບໍລິການ MCS ອະນຸຍາດໃຫ້ທ່ານລວມການຕັ້ງຄ່າໄຟວໍເປັນກຸ່ມ. ຊື່ກຸ່ມແມ່ນບ່ອນທີ່ XSS ຖືກກວດພົບ. ລັກສະນະພິເສດຂອງມັນແມ່ນວ່າ vector ບໍ່ໄດ້ຖືກກະຕຸ້ນທັນທີ, ບໍ່ແມ່ນໃນເວລາທີ່ເບິ່ງບັນຊີລາຍຊື່ຂອງກົດລະບຽບ, ແຕ່ເມື່ອລຶບກຸ່ມ:

ນັ້ນແມ່ນ, ສະຖານະການໄດ້ກາຍມາເປັນດັ່ງຕໍ່ໄປນີ້: ຜູ້ໂຈມຕີສ້າງກົດລະບຽບໄຟວໍດ້ວຍ "ໂຫຼດ" ໃນຊື່, ຜູ້ບໍລິຫານສັງເກດເຫັນມັນຫຼັງຈາກເວລາໃດຫນຶ່ງແລະເລີ່ມຕົ້ນຂະບວນການລຶບ. ແລະນີ້ແມ່ນບ່ອນທີ່ JS malicious ເຮັດວຽກ.

ສໍາລັບຜູ້ພັດທະນາ MCS, ເພື່ອປ້ອງກັນ XSS ໃນຮູບພາບ SVG ທີ່ດາວໂຫຼດແລ້ວ (ຖ້າພວກເຂົາບໍ່ສາມາດປະຖິ້ມໄດ້), ທີມງານຄວາມປອດໄພດິຈິຕອນແນະນໍາ:

• ວາງໄຟລ໌ທີ່ອັບໂຫລດໂດຍຜູ້ໃຊ້ຢູ່ໃນໂດເມນແຍກຕ່າງຫາກທີ່ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບ "ຄຸກກີ". ສະຄຣິບຈະຖືກປະຕິບັດໃນບໍລິບົດຂອງໂດເມນອື່ນ ແລະຈະບໍ່ເປັນໄພຂົ່ມຂູ່ຕໍ່ MCS.
• ໃນການຕອບ HTTP ຂອງເຊີບເວີ, ສົ່ງສ່ວນຫົວ "Content-disposition: attachment". ຫຼັງຈາກນັ້ນ, ໄຟລ໌ຈະຖືກດາວໂຫຼດໂດຍຕົວທ່ອງເວັບແລະບໍ່ຖືກປະຕິບັດ.

ນອກຈາກນັ້ນ, ໃນປັດຈຸບັນມີຫຼາຍວິທີທີ່ມີຢູ່ກັບນັກພັດທະນາເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການຂຸດຄົ້ນ XSS:

• ໂດຍໃຊ້ທຸງ “HTTP ເທົ່ານັ້ນ”, ທ່ານສາມາດເຮັດໃຫ້ເຊດຊັນ “ຄຸກກີ້” ສ່ວນຫົວບໍ່ສາມາດເຂົ້າຫາ JavaScript ທີ່ເປັນອັນຕະລາຍໄດ້;
• ປະຕິບັດນະໂຍບາຍ CSP ຢ່າງຖືກຕ້ອງ ຈະເຮັດໃຫ້ມັນຍາກຫຼາຍສໍາລັບຜູ້ໂຈມຕີທີ່ຈະຂູດຮີດ XSS;
• ເຄື່ອງຈັກແມ່ແບບທີ່ທັນສະໄຫມເຊັ່ນ Angular ຫຼື React ອັດຕະໂນມັດ sanitize ຂໍ້ມູນຜູ້ໃຊ້ກ່ອນທີ່ຈະສົ່ງມັນໄປຫາຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້.

ຊ່ອງໂຫວ່ການພິສູດຢືນຢັນສອງປັດໃຈ

ເພື່ອປັບປຸງຄວາມປອດໄພບັນຊີ, ຜູ້ໃຊ້ໄດ້ຖືກແນະນໍາສະເຫມີເພື່ອເປີດໃຊ້ 2FA (ການກວດສອບສອງປັດໃຈ). ແທ້ຈິງແລ້ວ, ນີ້ແມ່ນວິທີທີ່ມີປະສິດທິຜົນທີ່ຈະປ້ອງກັນບໍ່ໃຫ້ຜູ້ໂຈມຕີເຂົ້າເຖິງການບໍລິການຖ້າຂໍ້ມູນປະຈໍາຕົວຂອງຜູ້ໃຊ້ຖືກທໍາລາຍ.

ແຕ່ການໃຊ້ປັດໄຈການພິສູດຢືນຢັນທີສອງຮັບປະກັນຄວາມປອດໄພຂອງບັນຊີສະເໝີບໍ? ມີບັນຫາຄວາມປອດໄພຕໍ່ໄປນີ້ໃນການຈັດຕັ້ງປະຕິບັດ 2FA:

• ການຄົ້ນຫາແບບ Brute-force ຂອງລະຫັດ OTP (ລະຫັດຄັ້ງດຽວ). ເຖິງວ່າຈະມີຄວາມງ່າຍດາຍຂອງການດໍາເນີນງານ, ຄວາມຜິດພາດເຊັ່ນການຂາດການປົກປ້ອງ OTP brute force ຍັງພົບໂດຍບໍລິສັດຂະຫນາດໃຫຍ່: ກໍລະນີ Slack, ກໍລະນີເຟສບຸກ.
• ຂັ້ນຕອນການຜະລິດທີ່ອ່ອນແອ, ສໍາລັບຕົວຢ່າງ, ຄວາມສາມາດໃນການຄາດຄະເນລະຫັດຕໍ່ໄປ.
• ຄວາມຜິດພາດທາງເຫດຜົນ, ເຊັ່ນ: ຄວາມສາມາດໃນການຮ້ອງຂໍ OTP ຂອງຄົນອື່ນໃນໂທລະສັບຂອງທ່ານ, ແບບນີ້ ມັນແມ່ນ ຈາກ Shopify.

ໃນກໍລະນີຂອງ MCS, 2FA ຖືກປະຕິບັດໂດຍອີງໃສ່ Google Authenticator ແລະ Duo. ໂປໂຕຄອນຕົວມັນເອງໄດ້ຮັບການທົດສອບເວລາແລ້ວ, ແຕ່ການປະຕິບັດການກວດສອບລະຫັດໃນດ້ານຄໍາຮ້ອງສະຫມັກແມ່ນມີມູນຄ່າການກວດສອບ.

MCS 2FA ຖືກໃຊ້ໃນຫຼາຍບ່ອນ:

• ເມື່ອຢືນຢັນຜູ້ໃຊ້. ມີການປ້ອງກັນຈາກ brute force: ຜູ້ໃຊ້ພຽງແຕ່ພະຍາຍາມບໍ່ຫຼາຍປານໃດທີ່ຈະໃສ່ລະຫັດຜ່ານຄັ້ງດຽວ, ຫຼັງຈາກນັ້ນການປ້ອນຂໍ້ມູນຖືກສະກັດສໍາລັບໃນຂະນະທີ່. ນີ້ຂັດຂວາງຄວາມເປັນໄປໄດ້ຂອງການຄັດເລືອກ brute-force ຂອງ OTP.
• ເມື່ອສ້າງລະຫັດສໍາຮອງແບບອອບໄລນ໌ເພື່ອປະຕິບັດ 2FA, ເຊັ່ນດຽວກັນກັບການປິດມັນ. ໃນທີ່ນີ້, ບໍ່ມີການປ້ອງກັນຜົນບັງຄັບໃຊ້ brute ໄດ້ຖືກປະຕິບັດ, ເຊິ່ງເຮັດໃຫ້ມັນເປັນໄປໄດ້, ຖ້າທ່ານມີລະຫັດຜ່ານສໍາລັບບັນຊີແລະກອງປະຊຸມທີ່ມີການເຄື່ອນໄຫວ, ການສ້າງລະຫັດສໍາຮອງຂໍ້ມູນຫຼືປິດການໃຊ້ງານ 2FA ຢ່າງສົມບູນ.

ພິຈາລະນາວ່າລະຫັດສໍາຮອງຂໍ້ມູນໄດ້ຖືກຕັ້ງຢູ່ໃນຂອບເຂດດຽວກັນຂອງຄ່າສະຕຣິງທີ່ສ້າງຂຶ້ນໂດຍຄໍາຮ້ອງສະຫມັກ OTP, ໂອກາດທີ່ຈະຊອກຫາລະຫັດໃນເວລາສັ້ນໆແມ່ນສູງກວ່າຫຼາຍ.

ຂະບວນການເລືອກ OTP ເພື່ອປິດການໃຊ້ງານ 2FA ໂດຍໃຊ້ເຄື່ອງມື "Burp: Intruder".

ຜົນ

ໂດຍລວມແລ້ວ, MCS ເບິ່ງຄືວ່າມີຄວາມປອດໄພເປັນຜະລິດຕະພັນ. ໃນລະຫວ່າງການກວດສອບ, ທີມງານ pentesting ບໍ່ສາມາດເຂົ້າເຖິງ VMs ລູກຄ້າແລະຂໍ້ມູນຂອງເຂົາເຈົ້າ, ແລະຈຸດອ່ອນທີ່ພົບເຫັນໄດ້ຖືກແກ້ໄຂຢ່າງໄວວາໂດຍທີມງານ MCS.

ແຕ່ໃນທີ່ນີ້ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສັງເກດວ່າຄວາມປອດໄພແມ່ນການເຮັດວຽກຢ່າງຕໍ່ເນື່ອງ. ການບໍລິການບໍ່ຄົງທີ່, ພວກມັນພັດທະນາຢ່າງຕໍ່ເນື່ອງ. ແລະມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະພັດທະນາຜະລິດຕະພັນຢ່າງສົມບູນໂດຍບໍ່ມີຄວາມອ່ອນແອ. ແຕ່ເຈົ້າສາມາດຊອກຫາພວກມັນໄດ້ໃນເວລາແລະຫຼຸດຜ່ອນໂອກາດຂອງການເກີດໃຫມ່ຂອງເຂົາເຈົ້າ.

ຕອນນີ້ຊ່ອງໂຫວ່ທັງໝົດທີ່ໄດ້ກ່າວມາໃນ MCS ໄດ້ຖືກແກ້ໄຂແລ້ວ. ແລະເພື່ອຮັກສາຈໍານວນອັນໃຫມ່ໃຫ້ຫນ້ອຍລົງແລະຫຼຸດຜ່ອນອາຍຸຂອງພວກເຂົາ, ທີມງານເວທີຍັງສືບຕໍ່ເຮັດເຊັ່ນນີ້:

• ດໍາເນີນການກວດສອບໂດຍບໍລິສັດພາຍນອກເປັນປະຈໍາ;
• ສະ​ຫນັບ​ສະ​ຫນູນ​ແລະ​ພັດ​ທະ​ນາ​ການ​ມີ​ສ່ວນ​ຮ່ວມ​ ໃນໂຄງການ Mail.ru Group Bug Bounty;
• ມີສ່ວນຮ່ວມໃນຄວາມປອດໄພ. 🙂

ແຫຼ່ງຂໍ້ມູນ: www.habr.com