ກ່ຽວກັບຊ່ອງໂຫວ່ນຶ່ງໃນ...

ໜຶ່ງປີກ່ອນ, ວັນທີ 21 ມີນາ 2019, in ໂຄງການ bug bounty Mail.Ru ອັນທີ່ດີຫຼາຍມາຫາ HackerOne ບົດ​ລາຍ​ງານ bug​ ຈາກ maxarr. ເມື່ອແນະນໍາ zero byte (ASCII 0) ເຂົ້າໄປໃນ POST ພາລາມິເຕີຂອງຫນຶ່ງຂອງການຮ້ອງຂໍ webmail API ທີ່ສົ່ງຄືນ HTTP redirect, ຕ່ອນຂອງຫນ່ວຍຄວາມຈໍາ uninitialized ໄດ້ຖືກສັງເກດເຫັນໃນຂໍ້ມູນການປ່ຽນເສັ້ນທາງ, ເຊິ່ງ fragments ຈາກ GET parameters ແລະ headers ຂອງຄໍາຮ້ອງຂໍອື່ນໆໄປຫາ ເຊີບເວີດຽວກັນ.

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

Mail.ru mail ເປັນແອັບພລິເຄຊັນທີ່ສັບສົນຫຼາຍ; ພວກເຮົາໄດ້ຈັດການເພື່ອຍົກເວັ້ນອົງປະກອບທັງຫມົດຍົກເວັ້ນ nginx ແລະ openresty ແລະ localize ບັນຫາກ່ອນທີ່ຈະໂທຫາ ngx.req.set_uri() ໃນສະຄຣິບ OpenResty ທີ່ບໍ່ປະຕິບັດຕົວຕາມທີ່ຄາດໄວ້ (ການໃສ່ null byte ຫຼື line feed ຜ່ານພາລາມິເຕີ GET ດ້ວຍການຂຽນຄືນໃຫມ່ໃນ ngx_http_rewrite_module, ເຊິ່ງ, ອີງຕາມເອກະສານ, ຖືກນໍາໃຊ້ແລະ, ມັນເບິ່ງຄືວ່າ, ຄວນເຮັດວຽກໃນແບບດຽວກັນ, ຈະ. ບໍ່ເຮັດວຽກ). ຜົນສະທ້ອນທີ່ເປັນໄປໄດ້ໄດ້ຖືກລົບລ້າງ, ການກັ່ນຕອງໄດ້ຖືກເພີ່ມຢ່າງເຂັ້ມງວດເທົ່າທີ່ເປັນໄປໄດ້, ແລະການກັ່ນຕອງໄດ້ຖືກກວດສອບເພື່ອລົບລ້າງ vectors ທີ່ເປັນໄປໄດ້ທັງຫມົດ. ແຕ່ກົນໄກທີ່ນໍາໄປສູ່ການຮົ່ວໄຫລຂອງເນື້ອໃນຄວາມຊົງຈໍາຍັງຄົງເປັນຄວາມລຶກລັບ. ນຶ່ງເດືອນຕໍ່ມາ, ບົດລາຍງານຂອງແມງໄມ້ໄດ້ຖືກປິດລົງຕາມການແກ້ໄຂ, ແລະການວິເຄາະສາເຫດຂອງແມງໄມ້ໄດ້ຖືກເລື່ອນອອກໄປຈົນກ່ວາເວລາທີ່ດີຂຶ້ນ.

OpenResty ເປັນ plugin ທີ່ນິຍົມຫຼາຍທີ່ຊ່ວຍໃຫ້ທ່ານຂຽນຕົວອັກສອນ Lua ພາຍໃນ nginx, ແລະມັນຖືກນໍາໃຊ້ໃນໂຄງການ Mail.ru ຫຼາຍ, ດັ່ງນັ້ນບັນຫາບໍ່ໄດ້ຖືກພິຈາລະນາແກ້ໄຂ. ແລະຫຼັງຈາກເວລາໃດຫນຶ່ງ, ໃນທີ່ສຸດພວກເຂົາໄດ້ກັບຄືນໄປຫາມັນເພື່ອເຂົ້າໃຈເຫດຜົນທີ່ແທ້ຈິງ, ຜົນສະທ້ອນທີ່ເປັນໄປໄດ້ແລະເຮັດໃຫ້ຄໍາແນະນໍາສໍາລັບນັກພັດທະນາ. ເຂົ້າຮ່ວມໃນການຂຸດຄົ້ນລະຫັດແຫຼ່ງ Denis Denisov и Nikolay Ermishkin. ມັນ​ໄດ້​ຫັນ​ອອກ​ວ່າ​:

• ໃນ nginx, ເມື່ອໃຊ້ rewrite ກັບຂໍ້ມູນຜູ້ໃຊ້, ມີຄວາມເປັນໄປໄດ້ຂອງ traversal ໄດເລກະທໍລີ (ແລະອາດຈະເປັນ SSRF) ໃນບາງການຕັ້ງຄ່າ, ແຕ່ນີ້ແມ່ນຄວາມຈິງທີ່ຮູ້ຈັກແລະຄວນຈະຖືກກວດພົບໂດຍການວິເຄາະການຕັ້ງຄ່າຄົງທີ່ໃນ. Nginx Amplify и ຈີຊີ ຈາກ Yandex (ແມ່ນແລ້ວ, ພວກເຮົາໃຊ້ມັນຄືກັນ, ຂອບໃຈ). ເມື່ອໃຊ້ OpenResty, ຄຸນສົມບັດນີ້ງ່າຍທີ່ຈະພາດ, ແຕ່ນີ້ບໍ່ໄດ້ສົ່ງຜົນກະທົບຕໍ່ການຕັ້ງຄ່າຂອງພວກເຮົາ.

  ຕົວ​ຢ່າງ​ການ​ຕັ້ງ​ຄ່າ​:

  location ~ /rewrite {
      rewrite ^.*$ $arg_x;
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  ຜົນກະທົບ

  curl localhost:8337/rewrite?x=/../../../../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

• Nginx ມີ bug ທີ່ເຮັດໃຫ້ຫນ່ວຍຄວາມຈໍາຮົ່ວໄຫຼຖ້າເສັ້ນ rewrite ມີ byte null. ເມື່ອການປ່ຽນເສັ້ນທາງຖືກອອກ, nginx ຈັດສັນ buffer ຫນ່ວຍຄວາມຈໍາໃຫມ່ທີ່ສອດຄ້ອງກັບຄວາມຍາວເຕັມຂອງເສັ້ນ, ແຕ່ຄັດລອກເສັ້ນຢູ່ທີ່ນັ້ນໂດຍຜ່ານຫນ້າທີ່ເສັ້ນທີ່ສູນ byte ເປັນຕົວສິ້ນສຸດຂອງເສັ້ນ, ດັ່ງນັ້ນເສັ້ນຈະຖືກຄັດລອກພຽງແຕ່ເຖິງສູນເທົ່ານັ້ນ. byte; ສ່ວນທີ່ເຫລືອຂອງ buffer ມີຂໍ້ມູນ uninitialized. ການວິເຄາະລາຍລະອຽດສາມາດພົບໄດ້ ທີ່ນີ້.

  ຕົວຢ່າງການຕັ້ງຄ່າ (^@ zero byte)

  
  location ~ /memleak {
      rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  ຜົນກະທົບ
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...


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

  ຕົວ​ຢ່າງ​ການ​ຕັ້ງ​ຄ່າ​:

  location ~ /memleak {
      rewrite_by_lua_block {
          ngx.req.read_body();
          local args, err = ngx.req.get_post_args();
          ngx.req.set_uri( args["url"], true );
      }
  }
  
  location / {
      root html;
      index index.html index.htm;
  }
  

  ຜົນໄດ້ຮັບ:

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Location: http://localhost:8337/{...может содержать secret...}
...


ຕິກິຣິຍາເພີ່ມເຕີມ

ບັນຫາໄດ້ຖືກລາຍງານໃຫ້ນັກພັດທະນາຂອງ nginx ແລະ OpenResty, ນັກພັດທະນາບໍ່ໄດ້ພິຈາລະນາບັນຫາດັ່ງກ່າວເປັນບັນຫາຄວາມປອດໄພໃນ nginx, ເພາະວ່າ. ໃນ nginx ຕົວຂອງມັນເອງບໍ່ມີວິທີການຂຸດຄົ້ນຄວາມຜິດພາດໂດຍຜ່ານການສີດຂອງລັກສະນະພິເສດ, ແກ້ໄຂ ການເປີດເຜີຍຄວາມຊົງຈໍາ ຈັດພີມມາໃນວັນທີ 16 ເດືອນທັນວາ. ໃນໄລຍະ 4 ເດືອນນັບຕັ້ງແຕ່ການລາຍງານ, ບໍ່ມີການປ່ຽນແປງໃດໆຕໍ່ OpenResty, ເຖິງແມ່ນວ່າມີຄວາມເຂົ້າໃຈວ່າຕ້ອງໃຊ້ຟັງຊັນ ngx.req.set_uri() ສະບັບທີ່ປອດໄພ. ໃນວັນທີ 18 ມີນາ 2020 ພວກເຮົາໄດ້ເຜີຍແຜ່ຂໍ້ມູນ, ໃນວັນທີ 21 ມີນາ OpenResty ເປີດເຜີຍ ເວີຊັ່ນ 1.15.8.3, ເຊິ່ງເພີ່ມການກວດສອບ URI.

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

ດັ່ງນັ້ນຄວາມຜິດພາດແມ່ນຫຍັງແລະສິ່ງທີ່ສາມາດປ້ອງກັນມັນໄດ້?

ມີຂໍ້ຜິດພາດໃນ nginx ບໍ? ແມ່ນແລ້ວ, ມັນແມ່ນ, ເພາະວ່າຄວາມຊົງຈໍາຮົ່ວໄຫຼແມ່ນຄວາມຜິດພາດໃນກໍລະນີໃດກໍ່ຕາມ.

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

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

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

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

ອີຣານຕາ

ຈາກປະສົບການ ບົດຄວາມທີ່ຜ່ານມາ, ສໍາລັບ sake ຂອງການຮັກສາຄວາມບໍລິສຸດຂອງພາສາ:

bug bounty - ການ​ແຂ່ງ​ຂັນ​ການ​ລ່າ​ສັດ​ແມງ​ໄມ້​
ບົດ​ລາຍ​ງານ bug​ - ແຈ້ງ​ການ​ຄວາມ​ຜິດ​ພາດ​
ປ່ຽນເສັ້ນທາງ - ການປ່ຽນເສັ້ນທາງ
ແຫຼ່ງເປີດ - ແຫຼ່ງເປີດ
ຜິດພາດ - ເຮັດວຽກກ່ຽວກັບຄວາມຜິດພາດ

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