ທ່ານ ໝໍ ຢູ່ໃນເສັ້ນທາງຂອງລາວ, ຢູ່ໃນເສັ້ນທາງຂອງລາວ

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

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

Дисклеймер: вся информация ниже публикуется исключительно в образовательных целях. Автор не получал доступа к персональным данным третьих лиц и компаний. Информация взята либо из открытых источников, либо была предоставлена автору анонимными доброжелателями.

ເຄື່ອງແມ່ຂ່າຍທີ່ມີຖານຂໍ້ມູນທີ່ເອີ້ນວ່າ "ssmp", ຕັ້ງຢູ່ໃນເວັບໄຊຂອງຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງທີ່ມີຊື່ສຽງ Hetzner ໃນເຢຍລະມັນ.

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

ໃນຫນ້າ ci-systems.com/solutions/programs-smp/, ບໍລິສັດບອກພວກເຮົາວ່າ:

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

• ຮັບສາຍ;
• ການລົງທະບຽນການໂທແລະການປ່ຽນເສັ້ນທາງ;
• ການສ້າງ, ຕິດຕາມກວດກາແລະການຄຸ້ມຄອງທີມງານໂທລະສັບມືຖືຂອງສະຖານີ EMS;
• ການມອບໝາຍໃໝ່ຂອງໜ່ວຍບໍລິການການແພດສຸກເສີນໃນໄລຍະການຕອບສະໜອງສຸກເສີນ;
• ການດໍາເນີນງານຂອງສູນປະມວນຜົນການໂທ EMS ດຽວ;
• ການແລກປ່ຽນຂໍ້ມູນກັບລະບົບຂໍ້ມູນຂ່າວສານພາຍນອກ.

ຖານຂໍ້ມູນມີຂະຫນາດ 17.3 GB ແລະປະກອບດ້ວຍ:

• ວັນທີ/ເວລາໂທສຸກເສີນ
• ຊື່ເຕັມຂອງສະມາຊິກລູກເຮືອຂົນສົ່ງຄົນເຈັບ (ລວມທັງຄົນຂັບລົດ)
• ປ້າຍທະບຽນລົດຂົນສົ່ງຄົນເຈັບ
• ສະຖານະລົດຂົນສົ່ງຄົນເຈັບ (ຕົວຢ່າງ: "ມາຮອດການໂທ")
• ໂທຫາທີ່ຢູ່
• ຊື່ເຕັມ, ວັນເດືອນປີເກີດ, ເພດຂອງຄົນເຈັບ
• ລາຍ​ລະ​ອຽດ​ຂອງ​ສະ​ພາບ​ການ​ຂອງ​ຄົນ​ເຈັບ (ສໍາ​ລັບ​ການ​ຍົກ​ຕົວ​ຢ່າງ​, "ອຸນ​ຫະ​ພູມ​>39​, ຫຼຸດ​ລົງ​ບໍ່​ດີ​, ຜູ້​ໃຫຍ່​"​)
• ຊື່ເຕັມຂອງບຸກຄົນທີ່ໂທຫາລົດສຸກເສີນ
• ເບີຕິດຕໍ່
• имнодоедругое…

ຂໍ້​ມູນ​ໃນ​ຖານ​ຂໍ້​ມູນ​ແມ່ນ​ຄ້າຍ​ຄື​ກັບ​ບັນ​ທຶກ​ຂອງ​ບາງ​ປະ​ເພດ​ຂອງ​ລະ​ບົບ​ຕິດ​ຕາມ​ກວດ​ກາ / ການ​ຕິດ​ຕາມ​ສໍາ​ລັບ​ຂະ​ບວນ​ການ​ສໍາ​ເລັດ​ວຽກ​ງານ​ໃດ​ຫນຶ່ງ​. ຄວາມສົນໃຈແມ່ນພາກສະຫນາມ "ຂໍ້ມູນ"ຢູ່ໃນຕາຕະລາງ"assign_data_history".

(ແນ່ນອນ, ໃນຮູບຂ້າງເທິງຂ້າພະເຈົ້າໄດ້ພະຍາຍາມເຊື່ອງຂໍ້ມູນສ່ວນຕົວທັງຫມົດ.)

ດັ່ງທີ່ໄດ້ຂຽນໄວ້ໃນຕອນຕົ້ນ, ການຂາດການພິສູດຢືນຢັນບໍ່ແມ່ນບັນຫາດຽວໃນເວລານີ້.

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

“ຖືກແຮັກໂດຍ THack3forU! Chanel.nPutin ເປັນ dick, nMeddvédeva ເປັນ schmuck, nStrelkov ເປັນ bastard, n ລັດເຊຍແມ່ນ BOTTOM!”

ແລະແນ່ນອນຄວາມຈິງທີ່ວ່າ, ມີການດາວໂຫຼດທັງຫມົດ 17 GB, ພວກເຂົາເຈົ້າໄດ້ຈັດພີມມາໃຫ້ເຂົາເຈົ້າໃນຮູບແບບ CSV ໃນ hosting ໄຟລ໌ mega.nz. ກ່ຽວກັບວິທີການເປີດຖານຂໍ້ມູນ MongoDB ຖືກກວດພົບ - ທີ່ນີ້.

ທັນທີທີ່ເຈົ້າຂອງຖານຂໍ້ມູນໄດ້ຖືກກໍານົດ, ຂ້າພະເຈົ້າໄດ້ສົ່ງແຈ້ງການໃຫ້ລາວພ້ອມກັບການສະເຫນີທີ່ຈະຍັງປິດການເຂົ້າເຖິງຖານຂໍ້ມູນ, ເຖິງແມ່ນວ່າມັນຊ້າເກີນໄປ - ຂໍ້ມູນແມ່ນ "ຫມົດໄປ."

ເຄື່ອງຈັກຊອກຫາຄັ້ງທໍາອິດ ໂຊດາ ບັນທຶກຖານຂໍ້ມູນນີ້ໃນວັນທີ 28.06.2018/08.04.2019/17, ແລະສຸດທ້າຍໄດ້ປິດການເຂົ້າເຖິງໃນວັນທີ 20/18/05, ຢູ່ບ່ອນໃດບ່ອນໜຶ່ງລະຫວ່າງ 6:XNUMX-XNUMX:XNUMX ໂມງ (ຕາມເວລາ Moscow). ໜ້ອຍກວ່າ XNUMX ຊົ່ວໂມງໄດ້ຜ່ານໄປຕັ້ງແຕ່ການແຈ້ງເຕືອນ.

ຂ່າວກ່ຽວກັບການຮົ່ວໄຫລຂອງຂໍ້ມູນຂ່າວສານແລະພາຍໃນສາມາດພົບໄດ້ຕະຫຼອດເວລາຢູ່ໃນຊ່ອງທາງ Telegram ຂອງຂ້ອຍ "ຂໍ້ມູນຮົ່ວໄຫຼ".

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