Энэ нийтлэлийг Групп-IB-ийн мэргэжилтнүүд хэдэн жилийн өмнө явуулсан маш амжилттай туршилтын үндсэн дээр бичсэн: Болливудын кинонд дасан зохицож болох нэгэн түүх болсон. Одоо уншигчдын хариу үйлдэл дагах байх: "Өө, өөр PR нийтлэл, эдгээрийг дахин дүрсэлж байна, тэд ямар сайн вэ, пентест худалдаж авахаа бүү мартаарай." За, нэг талаараа тийм. Гэсэн хэдий ч, энэ нийтлэл яагаад гарч ирсэн өөр хэд хэдэн шалтгаан бий. Би пентестерүүд яг юу хийдэг, энэ ажил ямар сонирхолтой, өчүүхэн зүйл биш, төслүүдэд ямар инээдтэй нөхцөл байдал үүсч болохыг, хамгийн гол нь бодит жишээн дээр амьд материалыг харуулахыг хүссэн.
Дэлхий дээрх даруу байдлын тэнцвэрийг сэргээхийн тулд хэсэг хугацааны дараа бид сайн болоогүй пентестийн тухай бичих болно. Компанийн сайн боловсруулсан процессууд нь эдгээр процессууд байдаг бөгөөд бодитоор ажилладаг учраас сайн бэлтгэгдсэн ч гэсэн бүхэл бүтэн халдлагаас хэрхэн хамгаалж болохыг харуулах болно.
Энэ нийтлэл дэх үйлчлүүлэгчийн хувьд бүх зүйл ерөнхийдөө маш сайн байсан бөгөөд бидний бодлоор ОХУ-ын зах зээлийн 95% -иас ч илүү байсан боловч үйл явдлын урт гинжийг бүрдүүлсэн хэд хэдэн жижиг нюансууд байсан. ажлын талаар урт тайлан, дараа нь энэ нийтлэлд хүргэсэн.
Ингээд попкорноо нөөцөлцгөөе, мөрдөгч кинонд тавтай морил. Үг - Павел Супрунюк, Групп-IB-ийн “Аудит ба зөвлөх” хэлтсийн техникийн менежер.
1-р хэсэг. Почкин эмч
2018 он Худалдан авагч байдаг - өндөр технологийн мэдээллийн технологийн компани нь өөрөө олон үйлчлүүлэгчдэд үйлчилдэг. Асуултанд хариулт авахыг хүсч байна: анхны мэдлэг, хандалтгүйгээр интернетээр дамжуулан Active Directory домэйны администраторын эрхийг авах боломжтой юу? Би ямар ч нийгмийн инженерчлэл сонирхдоггүй (), тэд зориудаар ажилд саад учруулах бодолгүй байгаа ч санамсаргүйгээр байж магадгүй - жишээлбэл хачирхалтай ажиллаж байгаа серверийг дахин ачаалах. Нэмэлт зорилго бол гаднах периметрийн эсрэг аль болох олон довтолгооны векторуудыг тодорхойлох явдал юм. Тус компани ийм туршилтыг тогтмол хийдэг бөгөөд одоо шинэ туршилтын хугацаа иржээ. Нөхцөл байдал нь бараг ердийн, хангалттай, ойлгомжтой. Эхэлцгээе.
Үйлчлүүлэгчийн нэр байдаг - үүнийг үндсэн вэбсайттай "Компани" гэж хэлээрэй . Мэдээжийн хэрэг, үйлчлүүлэгч өөр өөрөөр дуудагддаг, гэхдээ энэ нийтлэлд бүх зүйл хувийн бус байх болно.
Би сүлжээний хайгуул хийдэг - үйлчлүүлэгчид ямар хаяг, домэйнууд бүртгэгдсэн, сүлжээний диаграммыг зурж, эдгээр хаягуудад үйлчилгээ хэрхэн хуваарилагдаж байгааг олж мэдээрэй. Би үр дүнд хүрсэн: 4000 гаруй амьд IP хаяг. Би эдгээр сүлжээн дэх домэйнүүдийг харж байна: аз болоход дийлэнх нь үйлчлүүлэгчийн үйлчлүүлэгчдэд зориулагдсан сүлжээнүүд бөгөөд бид тэднийг албан ёсоор сонирхдоггүй. Үйлчлүүлэгч ч мөн адил боддог.
256 хаягтай нэг сүлжээ хэвээр байгаа бөгөөд одоогоор домэйн болон дэд домайныг IP хаягаар хуваарилах талаар аль хэдийн ойлголттой болсон бөгөөд сканнердсан портуудын талаархи мэдээлэл байгаа бөгөөд энэ нь та сонирхолтой үйлчилгээг үзэх боломжтой гэсэн үг юм. Үүний зэрэгцээ бүх төрлийн сканнеруудыг боломжтой IP хаягууд болон вэбсайтууд дээр тусад нь ажиллуулдаг.
Маш олон үйлчилгээ байдаг. Ихэнхдээ энэ нь пентестерийн баяр баясгалан, хурдан ялалтыг хүлээх явдал юм, учир нь олон үйлчилгээ байх тусам довтолгооны талбар томорч, олдвор олоход хялбар байдаг. Вэбсайтуудыг хурдан харвал тэдгээрийн ихэнх нь дэлхийн томоохон компаниудын алдартай бүтээгдэхүүний вэб интерфэйсүүд бөгөөд тэдгээр нь танд таалагдахгүй байгааг харуулж байна. Тэд хэрэглэгчийн нэр, нууц үг асууж, хоёр дахь хүчин зүйлийг оруулах талбарыг сэгсэрч, TLS үйлчлүүлэгчийн гэрчилгээ авах эсвэл Microsoft ADFS руу илгээнэ. Зарим нь интернетээс нэвтрэх боломжгүй байдаг. Зарим хүмүүсийн хувьд та гурван цалинтай тусгай төлбөртэй үйлчлүүлэгчтэй байх эсвэл яг URL хаягаа оруулах хэрэгтэй. Програм хангамжийн хувилбаруудыг мэдэгдэж буй сул талуудыг арилгах, вэб зам дахь далд контент, LinkedIn гэх мэт гуравдагч талын үйлчилгээнүүдийн задруулсан акаунтуудыг хайж олох, тэдгээрийг ашиглан нууц үгээ таахыг оролдох явцдаа аажмаар цөхрөнгөө барсан ахин нэг долоо хоногийг алгасацгаая. Өөрөө бичдэг вэб сайтуудын эмзэг байдлыг судалснаар - дашрамд хэлэхэд, статистикийн дагуу энэ нь өнөөдөр гадны халдлагын хамгийн ирээдүйтэй вектор юм. Дараа нь буудсан киноны бууг би нэн даруй тэмдэглэх болно.
Тиймээс бид олон зуун үйлчилгээнээс ялгарах хоёр сайтыг олсон. Эдгээр сайтуудад нийтлэг нэг зүйл байсан: хэрэв та сүлжээний сүлжээг домэйнээр нарийн хайдаггүй, харин нээлттэй портуудыг хайж олох юм уу эсвэл мэдэгдэж буй IP мужийг ашиглан эмзэг байдлын сканнерыг онилдог бол эдгээр сайтууд сканнердсанаас мултрах болно. DNS нэрийг мэдэхгүйгээр харагдана. Тэдгээрийг ядаж эрт алдсан байж магадгүй бөгөөд манай автомат хэрэгслүүд шууд эх сурвалж руу илгээсэн байсан ч тэдэнтэй холбоотой ямар ч асуудал олсонгүй.
Дашрамд хэлэхэд, өмнө нь эхлүүлсэн сканнерууд ерөнхийдөө юу олж мэдсэн талаар. Би танд сануулъя: зарим хүмүүсийн хувьд "пентест" нь "автомат скан" -тай тэнцдэг. Гэхдээ энэ төслийн сканнерууд юу ч хэлээгүй. Хамгийн дээд тал нь Дунд зэргийн эмзэг байдлыг харуулсан (3-ын 5 нь ноцтой байдлын хувьд): зарим үйлчилгээнд TLS сертификат муу эсвэл хуучирсан шифрлэлтийн алгоритмууд, ихэнх сайтууд дээр Clickjacking. Гэхдээ энэ нь таныг зорилгодоо хүргэхгүй. Магадгүй энд сканнерууд илүү ашигтай байх болов уу, гэхдээ би танд сануулъя: үйлчлүүлэгч өөрөө ийм програм худалдаж авч, тэдэнтэй хамт өөрийгөө туршиж үзэх боломжтой бөгөөд харамсалтай үр дүнгээс харахад тэр аль хэдийн шалгасан байна.
"Аномаль" сайтууд руу буцаж орцгооё. Эхнийх нь стандарт бус хаяг дахь орон нутгийн Wiki шиг зүйл боловч энэ нийтлэлд үүнийг wiki.company[.]ru гэж үзье. Тэр даруй нэвтрэх болон нууц үгээ хүссэн боловч хөтөч дээрх NTLM-ээр дамжуулан асуув. Хэрэглэгчийн хувьд энэ нь хэрэглэгчийн нэр, нууц үг оруулахыг хүссэн даяанч цонх шиг харагдаж байна. Мөн энэ бол муу туршлага юм.
Жижигхэн тэмдэглэл. Периметрийн вэбсайт дахь NTLM нь хэд хэдэн шалтгааны улмаас муу байдаг. Эхний шалтгаан нь Active Directory домэйн нэр илэрсэн явдал юм. Бидний жишээн дээр энэ нь "гадаад" DNS нэртэй адил company.ru болж хувирсан. Үүнийг мэдсэнээр та ямар нэгэн хорлонтой зүйлийг сайтар бэлдэж, үүнийг зөвхөн байгууллагын домэйн машин дээр гүйцэтгэх боломжтой бөгөөд зарим хамгаалагдсан хязгаарлагдмал орчинд биш. Хоёрдугаарт, нэвтрэлт танилт нь NTLM-ээр дамжуулан домэйн хянагчаар шууд дамждаг (гайхах, тийм үү?), "дотоод" сүлжээний бодлогын бүх шинж чанарууд, тэр дундаа нууц үг оруулах оролдлогын тооноос хэтрэхийг хориглох дансуудыг хаадаг. Хэрэв халдагч нэвтэрч орохыг олж мэдвэл нууц үг хайх болно. Хэрэв та акаунтуудыг буруу нууц үг оруулахыг хориглох тохиргоотой бол энэ нь ажиллах бөгөөд бүртгэл хаагдах болно. Гуравдугаарт, ийм баталгаажуулалтад хоёр дахь хүчин зүйлийг нэмэх боломжгүй юм. Уншигчдын хэн нэгэн нь яаж гэдгийг мэдэж байгаа бол надад хэлээрэй, энэ үнэхээр сонирхолтой байна. Дөрөвдүгээрт, довтолгоонд өртөх эмзэг байдал. ADFS-ийг бусад зүйлсээс гадна энэ бүхнээс хамгаалах зорилгоор зохион бүтээсэн.
Майкрософт бүтээгдэхүүний нэг муу шинж чанар байдаг: та ийм NTLM-ийг тусгайлан нийтлээгүй байсан ч наад зах нь OWA болон Lync дээр анхдагчаар суулгасан байх болно.
Дашрамд дурдахад, энэ нийтлэлийн зохиогч нэг удаа нэг том банкны ажилчдын 1000 орчим дансыг нэг цагийн дотор санамсаргүй байдлаар хааж, дараа нь арай цайвар харагдаж байсан. Банкны мэдээллийн технологийн үйлчилгээ ч мөн адил бүдэг бадаг байсан ч бүх зүйл сайхан, хангалттай дуусч, бид энэ асуудлыг хамгийн түрүүнд олж, хурдан бөгөөд шийдэмгий засч залруулсан гэж магтсан.
Хоёр дахь сайт нь "мэдээж овог.company.ru" гэсэн хаягтай байв. Үүнийг 10-р хуудаснаас Google-ээр олсон. Дизайн нь XNUMX-аад оны эхэн үе байсан бөгөөд нэр хүндтэй хүн үүнийг үндсэн хуудаснаас харж байсан.
Энд би "Нохойн зүрх" киноны зураг авсан боловч надад итгээрэй, энэ нь тодорхойгүй төстэй байсан, тэр ч байтугай өнгөний загвар нь ижил төстэй өнгөтэй байсан. Сайтыг дуудъя preobrazhensky.company.ru.
Энэ бол урологийн эмчийн хувийн вэб сайт байсан. Өндөр технологийн компанийн дэд домайн дээр урологийн эмчийн вэбсайт юу хийж байгааг би гайхаж байлаа. Google-ийг хурдан судалж үзэхэд энэ эмч нь манай үйлчлүүлэгчийн нэг хуулийн этгээдийн үүсгэн байгуулагч байсан бөгөөд бүр дүрмийн санд 1000 орчим рублийн хувь нэмэр оруулсан болохыг харуулсан. Энэ сайтыг олон жилийн өмнө үүсгэсэн байх магадлалтай бөгөөд хэрэглэгчийн серверийн нөөцийг хостинг болгон ашиглаж байсан. Энэ сайт нь удаан хугацааны туршид хамааралгүй болсон боловч ямар нэг шалтгааны улмаас удаан хугацаагаар ажиллахаа больсон.
Эмзэг байдлын хувьд вэбсайт өөрөө аюулгүй байсан. Урагшаа харахад энэ нь статик мэдээллийн багц байсан гэж хэлэх болно - бөөр, давсагны хэлбэрээр оруулсан зураг бүхий энгийн html хуудас. Ийм сайтыг "эвдэх" нь дэмий юм.
Гэхдээ доорх вэб сервер илүү сонирхолтой байсан. HTTP серверийн толгой хэсгээс харахад энэ нь IIS 6.0 байсан бөгөөд энэ нь Windows 2003-ийг үйлдлийн систем болгон ашигласан гэсэн үг юм. Сканнер өмнө нь урологийн эмчийн вэбсайт нь ижил вэб сервер дээрх бусад виртуал хостуудаас ялгаатай нь PROPFIND тушаалд хариу үйлдэл үзүүлдэг бөгөөд энэ нь WebDAV ажиллуулж байна гэсэн үг юм. Дашрамд хэлэхэд сканнер нь энэ мэдээллийг Info гэсэн тэмдэглэгээгээр буцааж өгсөн (сканнерийн тайлангийн хэлээр энэ нь хамгийн бага аюул юм) - ийм зүйлийг ихэвчлэн алгасдаг. Энэ нь нэгэн зэрэг сонирхолтой нөлөө үзүүлсэн бөгөөд Google дээр дахин ухаж судалсны дараа л илэрсэн: Shadow Brokers багцтай холбоотой ховор буфер халих эмзэг байдал, тухайлбал CVE-2017-7269, аль хэдийн бэлэн мөлжлөгтэй байсан. Өөрөөр хэлбэл, хэрэв та Windows 2003 үйлдлийн системтэй, WebDAV IIS дээр ажиллаж байгаа бол асуудал гарах болно. Хэдийгээр 2003 онд үйлдвэрлэсэн Windows 2018-ийг ажиллуулах нь өөрөө асуудал юм.
Энэхүү эксплойт нь Metasploit дээр дуусч, DNS хүсэлтийг хяналттай үйлчилгээ рүү илгээсэн ачааллаар нэн даруй туршиж үзсэн - Burp Collaborator нь DNS хүсэлтийг барихад ашиглагддаг. Энэ нь анх удаа үр дүнтэй болсон нь миний гайхшралыг төрүүлэв: DNS нокаут хүлээн авлаа. Дараа нь 80-р портоор дамжуулан backconnect үүсгэх оролдлого байсан (өөрөөр хэлбэл серверээс халдагчид руу сүлжээний холболт, хохирогчийн хост дээрх cmd.exe руу нэвтрэх боломжтой), гэхдээ дараа нь тасалдал гарсан. Холболт хийгдээгүй бөгөөд сайтыг ашиглах гурав дахь оролдлогын дараа бүх сонирхолтой зургуудын хамт үүрд алга болжээ.
Ихэвчлэн үүний араас "үйлчлүүлэгч, сэр, бид бүгдийг хаясан" гэсэн хэв маягтай захидал ирдэг. Гэхдээ энэ сайт нь бизнесийн үйл явцтай ямар ч холбоогүй бөгөөд бүх сервер шиг ямар ч шалтгаангүйгээр ажилладаг бөгөөд бид энэ нөөцийг хүссэнээрээ ашиглах боломжтой гэж бидэнд хэлсэн.
Ойролцоогоор нэг өдрийн дараа сайт гэнэт өөрөө ажиллаж эхлэв. IIS 6.0 дээр WebDAV-аас вандан сандал байгуулсны дараа би анхдагч тохиргоо нь IIS-ийн ажилчдын процессыг 30 цаг тутамд дахин эхлүүлэх болохыг олж мэдсэн. Өөрөөр хэлбэл хяналт бүрхүүлийн кодоос гарахад IIS-ийн ажилчны процесс дуусч, дараа нь хэд хэдэн удаа дахин асч, дараа нь 30 цагийн турш амарна.
Эхний удаа tcp руу буцах холболт амжилтгүй болсон тул би энэ асуудлыг хаалттай порттой холбосон. Өөрөөр хэлбэл, тэр гарч буй холболтыг гадагш дамжуулахыг зөвшөөрдөггүй ямар нэгэн галт хана байгаа гэж таамагласан. Би олон tcp болон udp портуудаар хайсан бүрхүүлийн кодуудыг ажиллуулж эхэлсэн боловч ямар ч нөлөө үзүүлээгүй. Metasploit-ээс http(s)-ээр дамжуулан урвуу холболтын ачаалал ажиллахгүй байна - meterpreter/reverse_http(s). Гэнэт ижил порт 80-тай холболт үүссэн боловч тэр даруй тасарсан. Үүнийг би тоолуурын хөдөлгөөнд дургүй байсан төсөөлөлтэй IPS-ийн үйлдэлтэй холбон тайлбарлав. 80-р порт руу цэвэр tcp холболт дамжаагүй, харин http холболт дамждаг байсан тул би http прокси нь системд ямар нэгэн байдлаар тохируулагдсан гэж дүгнэсэн.
Би бүр DNS-ээр дамжуулан meterpreter ашиглаж үзсэн (баярлалаа Таны хүчин чармайлтын төлөө олон төслийг хадгалсан), анхны амжилтаа эргэн дурссан боловч индэр дээр ч ажиллаагүй - бүрхүүлийн код нь энэ эмзэг байдалд хэтэрхий том байсан.
Бодит байдал дээр энэ нь иймэрхүү харагдаж байв: 3 минутын дотор 4-5 удаа довтолж, дараа нь 30 цаг хүлээсэн. Гэх мэт гурван долоо хоног дараалан. Цаг алдахгүйн тулд санамж хүртэл тавьсан. Нэмж дурдахад туршилтын болон үйлдвэрлэлийн орчны үйл ажиллагааны ялгаа байсан: энэ эмзэг байдлын хувьд ижил төстэй хоёр мөлжлөг байсан бөгөөд нэг нь Metasploit, хоёр дахь нь Shadow Brokers хувилбараас хөрвүүлсэн интернет юм. Тиймээс зөвхөн Metasploit-ийг тулаанд туршиж, хоёр дахь нь л вандан сандал дээр туршиж үзсэн нь дибаг хийх ажлыг улам хүндрүүлж, тархи толгойгоо гашилгаж байв.
Эцэст нь http-ээр дамжуулан тухайн серверээс exe файлыг татаж аваад зорилтот систем дээр ажиллуулсан shellcode үр дүнтэй болох нь батлагдсан. Бүрхүүлийн код нь багтаахад хангалттай жижиг байсан ч ядаж л ажилласан. Сервер нь TCP урсгалд огт дургүй бөгөөд http(s)-д тоолуур байгаа эсэхийг шалгасан тул би хамгийн хурдан арга бол DNS-meterpreter агуулсан exe файлыг энэ бүрхүүлийн кодоор татаж авах гэж шийдсэн.
Энд дахин асуудал гарч ирэв: exe файлыг татаж авах үед аль нь ч хамаагүй татаж авах ажиллагаа тасалдсан. Дахин хэлэхэд, миний сервер болон урологич хоёрын хоорондох аюулгүй байдлын зарим төхөөрөмж дотор exe файлтай http урсгалд дургүй байсан. "Шуурхай" шийдэл нь бүрхүүлийн кодыг өөрчлөх бөгөөд ингэснээр http урсгалыг хурдан бүдгэрүүлж, exe-ийн оронд хийсвэр хоёртын өгөгдөл дамжуулах болно. Эцэст нь халдлага амжилттай болж, хяналтыг нимгэн DNS сувгаар хүлээн авав.
Надад юу ч хийх боломжгүй IIS ажлын урсгалын хамгийн энгийн эрхүүд байгаа нь тэр даруй тодорхой болсон. Metasploit консол дээр иймэрхүү харагдаж байв.
Пентестийн бүх арга зүй нь нэвтрэх эрхээ нэмэгдүүлэх шаардлагатайг хатуу санал болгодог. Би үүнийг ихэвчлэн дотооддоо хийдэггүй, учир нь хамгийн анхны хандалт нь зүгээр л сүлжээнд нэвтрэх цэг гэж үздэг бөгөөд нэг сүлжээнд өөр машиныг эвдэх нь одоо байгаа хост дээрх эрхийг нэмэгдүүлэхээс илүү хялбар бөгөөд хурдан байдаг. Гэхдээ энэ нь тийм биш, учир нь DNS суваг нь маш нарийн бөгөөд энэ нь урсгалыг арилгахыг зөвшөөрөхгүй.
Энэхүү Windows 2003 серверийг алдартай MS17-010-ийн эмзэг байдлын улмаас засаагүй гэж үзвэл би тоолуурын DNS туннелээр 445/TCP порт руу трафикийг localhost руу шилжүүлж (тиймээ, энэ нь бас боломжтой) бөгөөд өмнө нь татаж авсан exe-г ажиллуулахыг оролдоно. эмзэг байдал. Халдлага ажилладаг, би хоёр дахь холболтыг хүлээн авдаг, гэхдээ СИСТЕМ-ийн эрхтэй.
Тэд серверийг MS17-010-аас хамгаалахыг оролдсон хэвээр байгаа нь сонирхолтой юм - энэ нь гадаад интерфейс дээр эмзэг сүлжээний үйлчилгээг идэвхгүй болгосон. Энэ нь сүлжээгээр дамжих халдлагаас хамгаалдаг хэдий ч та localhost дээрх SMB-г хурдан унтрааж чадахгүй тул дотоодоосоо localhost-ын халдлага амжилттай болсон.
Дараа нь шинэ сонирхолтой нарийн ширийн зүйлийг тодрууллаа:
- СИСТЕМ-ийн эрхийг эзэмшсэнээр та TCP-ээр дамжуулан арын холболтыг хялбархан үүсгэж болно. Шууд TCP-ийг идэвхгүй болгох нь хязгаарлагдмал IIS хэрэглэгчдэд тулгамдсан асуудал болох нь ойлгомжтой. Спойлер: IIS хэрэглэгчийн траффик ямар нэгэн байдлаар орон нутгийн ISA проксид хоёр чиглэлд ороосон. Энэ нь яг яаж ажилладаг вэ, би хуулбарлаагүй байна.
- Би тодорхой "DMZ" -д байна (мөн энэ нь Active Directory домэйн биш, харин АЖЛЫН БҮЛЭГ) - энэ нь логик сонсогдож байна. Гэхдээ хүлээгдэж буй хувийн (“саарал”) IP хаягийн оронд би өмнө нь халдсантай яг адилхан “цагаан” IP хаягтай болсон. Энэ нь тус компани IPv4 хаяглалтын ертөнцөд маш өндөр настай тул 128 оны Cisco гарын авлагад дүрсэлсэн схемийн дагуу NAT-гүй 2005 "цагаан" хаягийн DMZ бүсийг хадгалах боломжтой гэсэн үг юм.
Сервер нь хуучирсан тул Mimikatz нь санах ойноос шууд ажиллах баталгаатай:
Би дотоод администраторын нууц үгийг авч, RDP урсгалыг TCP-ээр дамжуулж, тухтай ширээний компьютерт нэвтэрнэ. Сервертэй хүссэн бүхнээ хийх боломжтой байсан тул би вирусны эсрэг програмыг устгасан бөгөөд сервер нь зөвхөн TCP 80, 443 портуудаар интернетээс нэвтрэх боломжтой, 443 нь завгүй байгааг олж мэдэв. Би 443 дээр OpenVPN серверийг суулгаж, VPN траффикдаа NAT функцуудыг нэмж, OpenVPN-ээр дамжуулан DMZ сүлжээнд хязгааргүй хэлбэрээр шууд хандах боломжтой. ISA нь зарим идэвхгүй IPS функцуудтай байсан тул порт сканнерийн тусламжтайгаар миний траффикийг хааж, үүнийг илүү энгийн, илүү нийцтэй RRAS-ээр солих шаардлагатай болсон нь анхаарал татаж байна. Тиймээс пентестерүүд заримдаа бүх төрлийн зүйлийг удирдах шаардлагатай болдог.
Анхааралтай уншигч: "Хоёр дахь сайтын тухай - NTLM баталгаажуулалттай викигийн талаар юу гэж хэлэх вэ?" Гэж асуух болно. Энэ талаар дараа дэлгэрэнгүй.
2-р хэсэг. Шифрлээгүй хэвээр байна уу? Тэгвэл бид аль хэдийн энд тан дээр ирж байна
Тиймээс DMZ сүлжээний сегмент рүү нэвтрэх боломжтой. Та домэйн администратор руу очих хэрэгтэй. DMZ сегмент дэх үйлчилгээний аюулгүй байдлыг автоматаар шалгах нь хамгийн түрүүнд санаанд орж ирдэг, ялангуяа тэдний олонх нь судалгаанд нээлттэй байгаа тул. Нэвтрэх туршилтын үеийн ердийн зураг: гадаад периметр нь дотоод үйлчилгээнээс илүү сайн хамгаалагдсан бөгөөд том дэд бүтэц дотор ямар нэгэн хандалт хийх үед зөвхөн энэ домэйн нээгдэж эхэлснээр домэйнд өргөтгөсөн эрхийг олж авах нь илүү хялбар байдаг. хэрэгсэл ашиглах боломжтой, хоёрдугаарт, Хэдэн мянган хосттой дэд бүтцэд үргэлж хэд хэдэн чухал асуудал байх болно.
Би сканнеруудыг DMZ-ээр OpenVPN туннелээр цэнэглээд хүлээнэ үү. Би тайлангаа нээлээ - дахин ноцтой зүйл байхгүй, хэн нэгэн надаас өмнө ижил аргыг туулсан бололтой. Дараагийн алхам бол DMZ сүлжээн дэх хостууд хэрхэн харилцаж байгааг шалгах явдал юм. Үүнийг хийхийн тулд эхлээд ердийн Wireshark-ыг ажиллуулж, өргөн нэвтрүүлгийн хүсэлтийг, ялангуяа ARP-г сонсох хэрэгтэй. ARP пакетуудыг өдрийн турш цуглуулсан. Энэ сегментэд хэд хэдэн гарцыг ашиглаж байгаа нь харагдаж байна. Энэ нь дараа нь хэрэг болно. ARP хүсэлт, хариултын өгөгдөл, порт сканнерын өгөгдлийг нэгтгэснээр би вэб, шуудан гэх мэт өмнө нь мэдэгдэж байсан үйлчилгээнүүдээс гадна дотоод сүлжээнээс хэрэглэгчийн урсгалын гарах цэгүүдийг олсон.
Одоогийн байдлаар би бусад системд нэвтрэх эрхгүй, корпорацийн үйлчилгээнд зориулсан ганц дансгүй байсан тул ARP Хуурамч програмыг ашиглан замын хөдөлгөөнөөс ядаж тодорхой хэмжээний данс авахаар шийдсэн.
Cain&Abel-ийг urologist-ийн сервер дээр ажиллуулсан. Тодорхойлсон траффикийн урсгалыг харгалзан дунд хүн довтолгооны хамгийн ирээдүйтэй хосуудыг сонгож, дараа нь серверийг дахин ачаалах таймер бүхий 5-10 минутын турш богино хугацаанд ажиллуулах замаар зарим сүлжээний урсгалыг хүлээн авсан. хөлдөх тохиолдолд. Хошигнол дээрх шиг хоёр мэдээ байв.
- Сайн: маш олон итгэмжлэл баригдаж, халдлага бүхэлдээ үр дүнд хүрсэн.
- Муу нь: бүх итгэмжлэл нь үйлчлүүлэгчийн өөрийн үйлчлүүлэгчдээс ирсэн. Туслах үйлчилгээ үзүүлэх явцад үйлчлүүлэгчдийн мэргэжилтнүүд замын хөдөлгөөний шифрлэлтийг үргэлж тохируулдаггүй байсан үйлчлүүлэгчдийн үйлчилгээнд холбогддог.
Үүний үр дүнд би төслийн хүрээнд ашиггүй, гэхдээ халдлагын аюулыг харуулсан олон итгэмжлэлийг олж авсан. Томоохон компаниудын хилийн чиглүүлэгчид telnet, дибаг хийх http портуудыг бүх өгөгдөлтэй дотоод CRM руу дамжуулах, дотоод сүлжээн дэх Windows XP-ээс RDP руу шууд нэвтрэх болон бусад бүдэг бадаг. Энэ нь ийм болсон .
Би бас замын хөдөлгөөнөөс захидал цуглуулах инээдтэй боломж оллоо. Энэ бол манай үйлчлүүлэгчээс үйлчлүүлэгчийнхээ SMTP порт руу дахин шифрлэлтгүйгээр очсон бэлэн захидлын жишээ юм. Нэгэн Андрей өөрийн нэр бүхий хүнээс баримт бичгийг дахин илгээхийг хүссэн бөгөөд үүнийг нэг хариу захидалд нэвтрэх, нууц үг, холбоос бүхий үүлэн дискэнд байршуулав.
Энэ бол бүх үйлчилгээг шифрлэх өөр нэг сануулга юм. Үйлчилгээ үзүүлэгч, өөр компанийн системийн администратор эсвэл ийм пентестер таны өгөгдлийг хэн, хэзээ уншиж, ашиглах нь тодорхойгүй байна. Олон хүмүүс шифрлэгдээгүй траффикийг зүгээр л таслан зогсоож чадна гэдгийг би чимээгүй байна.
Хэдийгээр илэрхий амжилтанд хүрсэн ч энэ нь биднийг зорилгодоо ойртуулсангүй. Мэдээжийн хэрэг, удаан сууж, үнэ цэнэтэй мэдээллийг олж авах боломжтой байсан, гэхдээ энэ нь тэнд гарч ирэх нь үнэн биш бөгөөд сүлжээний бүрэн бүтэн байдлын хувьд халдлага нь өөрөө маш эрсдэлтэй юм.
Үйлчилгээг дахин ухаж үзсэний дараа нэгэн сонирхолтой санаа санаанд орж ирэв. Responder хэмээх ийм хэрэгсэл байдаг (энэ нэрээр ашиглах жишээг олоход хялбар) бөгөөд энэ нь өргөн нэвтрүүлгийн хүсэлтийг "хордуулах" замаар SMB, HTTP, LDAP гэх мэт олон төрлийн протоколоор дамжуулан холболт үүсгэдэг. янз бүрийн аргаар, дараа нь баталгаажуулалт хийхээр холбогдсон хүн бүрээс асууж, баталгаажуулалтыг NTLM-ээр дамжуулан хохирогчдод ил тод байдлаар хийхээр тохируулдаг. Ихэнхдээ халдагчид NetNTLMv2-ийн гар барилтуудыг ийм байдлаар цуглуулдаг бөгөөд тэдгээрээс толь бичиг ашиглан хэрэглэгчийн домэйны нууц үгийг хурдан сэргээдэг. Энд би үүнтэй төстэй зүйлийг хүсч байсан ч хэрэглэгчид "хананы ард" сууж, эс тэгвээс тэд галт ханаар тусгаарлагдсан бөгөөд Blue Coat прокси кластераар дамжуулан WEB-д хандсан.
Active Directory домэйн нэр нь "гадаад" домэйнтэй давхцаж байсан, өөрөөр хэлбэл company.ru байсан гэдгийг би санаж байна уу? Тиймээс, Windows, илүү нарийвчлалтай Internet Explorer (мөн Edge болон Chrome) нь тухайн сайтыг зарим "Дотоод сүлжээний бүсэд" байрладаг гэж үзвэл NTLM-ээр дамжуулан HTTP-д ил тод нэвтрэх боломжийг хэрэглэгчдэд олгоно. "Интранет"-ийн нэг шинж тэмдэг бол "саарал" IP хаяг эсвэл богино DNS нэр, өөрөөр хэлбэл цэггүй нэвтрэх явдал юм. Тэд "цагаан" IP болон DNS нэртэй preobrazhensky.company.ru нэртэй сервертэй байсан бөгөөд домэйн машинууд ихэвчлэн хялбаршуулсан нэр оруулахдаа DHCP-ээр дамжуулан Active Directory домайн дагаварыг хүлээн авдаг тул хаягийн мөрөнд URL-г бичихэд л хангалттай. , ингэснээр тэд эвдэрсэн урологчийн серверт хүрэх зөв замыг олохын тулд үүнийг одоо "Интранет" гэж нэрлэдэг гэдгийг мартаж болохгүй. Өөрөөр хэлбэл, нэгэн зэрэг надад хэрэглэгчийн NTLM-г өөрийн мэдэлгүй гар барих боломжийг олгож байна. Үйлчлүүлэгч хөтчүүдийг энэ сервертэй яаралтай холбоо барих шаардлагатай байгаа талаар бодоход хүргэх л үлдлээ.
Гайхамшигтай Intercepter-NG хэрэгсэл аврах ажилд ирэв (баярлалаа ). Энэ нь танд траффикийг шууд өөрчлөх боломжийг олгосон бөгөөд Windows 2003 дээр маш сайн ажилласан. Энэ нь замын хөдөлгөөний урсгалд зөвхөн JavaScript файлуудыг өөрчлөх тусдаа функцтэй байсан. Нэг төрлийн том сайт хоорондын скрипт хийхээр төлөвлөж байсан.
Хэрэглэгчид дэлхийн ВЭБ-д ханддаг Blue Coat прокси нь статик контентыг үе үе кэш болгодог. Замын хөдөлгөөнийг таслан зогсоосноор тэд өдрийн цагаар ажиллаж, оргил ачааллын үед контентыг харуулахыг хурдасгахын тулд байнга ашигладаг статикийг эцэс төгсгөлгүй хүсч байгаа нь тодорхой байв. Нэмж дурдахад BlueCoat нь тодорхой хэрэглэгч-агенттай байсан бөгөөд энэ нь түүнийг жинхэнэ хэрэглэгчээс тодорхой ялгаж өгдөг.
Javascript-ийг бэлтгэсэн бөгөөд Intercepter-NG ашиглан Blue Coat-д зориулсан JS файл бүхий хариулт бүрт шөнийн цагаар нэг цагийн турш хэрэгжүүлсэн. Скрипт нь дараахь зүйлийг хийсэн.
- Хэрэглэгчийн агентаар одоогийн хөтөчийг тодорхойлсон. Хэрэв энэ нь Internet Explorer, Edge эсвэл Chrome байсан бол үргэлжлүүлэн ажиллана.
- Би хуудасны DOM үүсэх хүртэл хүлээсэн.
- Маягтын src атрибут бүхий үл үзэгдэх дүрсийг DOM-д оруулсан :8080/NNNNNNNN.png, энд NNN нь дурын тоо бөгөөд BlueCoat үүнийг кэшлэхгүй.
- Тарилга дууссан бөгөөд цаашид зураг оруулах шаардлагагүй гэдгийг харуулахын тулд глобал тугийн хувьсагчийг тохируулна уу.
Хөтөч энэ зургийг ачаалах гэж оролдсон; эвдэрсэн серверийн 8080 порт дээр TCP туннель миний зөөврийн компьютерт үүнийг хүлээж байсан бөгөөд тэнд ижил Responder ажиллаж байгаа бөгөөд хөтчөөс NTLM-ээр нэвтрэхийг шаарддаг.
Хариулагчийн бүртгэлээс харахад хүмүүс өглөө ажилдаа ирж, ажлын байраа асааж, дараа нь NTLM-ийн гар барихаа марталгүй урологчийн серверт бөөнөөр, анзааралгүй зочилж эхлэв. Гар барилт өдөржин бороо асгарч, нууц үгээ сэргээх халдлага хийх нь тодорхой амжилттай болсон. Хариулагчийн бүртгэл иймэрхүү харагдаж байна:
Хэрэглэгчдийн урологийн серверт нууцаар зочилдог
Энэ түүх бүхэлдээ "бүх зүйл сайхан байсан, гэхдээ дараа нь уйтгар гунигтай байсан, дараа нь даван туулж, дараа нь бүх зүйл амжилтанд хүрсэн" гэсэн зарчим дээр бүтээгдсэнийг та аль хэдийн анзаарсан байх. Тэгэхээр энд нэг гай гамшиг байсан. Өвөрмөц тавин гар барилтаас ганц ч гараагүй. Энэ нь үхсэн процессортой зөөврийн компьютер дээр ч гэсэн эдгээр NTLMv2 гар барихыг секундэд хэдэн зуун сая оролдлогын хурдаар боловсруулдаг болохыг харгалзан үздэг.
Би нууц үг солих техник, видео карт, зузаан толь бичгээр зэвсэглээд хүлээх хэрэгтэй болсон. Удаан хугацааны дараа "Q11111111....1111111q" маягтын нууц үг бүхий хэд хэдэн данс илэрсэн нь бүх хэрэглэгчид нэг удаа өөр өөр тэмдэгт бүхий маш урт нууц үг гаргаж ирэхийг албадсан болохыг харуулж байна. нарийн төвөгтэй байх. Гэхдээ та туршлагатай хэрэглэгчийг хуурч чадахгүй бөгөөд энэ нь түүнийг санахад хялбар болгосон юм. Нийтдээ 5 орчим данс халдлагад өртсөн бөгөөд тэдгээрийн зөвхөн нэг нь үйлчилгээнд үнэ цэнэтэй эрхтэй байжээ.
3-р хэсэг. Роскомнадзор хариу цохилт өгдөг
Тиймээс анхны домэйн дансуудыг хүлээн авсан. Хэрэв та удаан уншсаны эцэст унтаагүй бол би баталгаажуулалтын хоёр дахь хүчин зүйл шаарддаггүй үйлчилгээг дурьдсаныг санаж байгаа байх: энэ бол NTLM баталгаажуулалттай вики юм. Мэдээжийн хэрэг, хамгийн түрүүнд хийх зүйл бол тийшээ орох явдал байв. Дотоод мэдлэгийн баазыг ухах нь үр дүнг хурдан авчирсан:
- Тус компани нь дотоод сүлжээнд нэвтрэх эрхтэй домэйн бүртгэлийг ашиглан баталгаажуулалт бүхий WiFi сүлжээтэй. Одоогийн мэдээллийн багцын хувьд энэ нь аль хэдийн ажиллаж байгаа халдлагын вектор боловч та хөлөөрөө оффис руу очиж, үйлчлүүлэгчийн оффисын нутаг дэвсгэрт байрлах хэрэгтэй.
- Хэрэв хэрэглэгч дотоод сүлжээнд байгаа бөгөөд өөрийн домэйн нэвтрэх болон нууц үгээ итгэлтэйгээр санаж байвал "хоёр дахь хүчин зүйл" баталгаажуулах төхөөрөмжийг бие даан бүртгүүлэх боломжийг олгодог үйлчилгээ байдаг зааврыг би олсон. Энэ тохиолдолд "дотор" ба "гадна" нь энэ үйлчилгээний портын хэрэглэгчдэд хүртээмжтэй байдлаар тодорхойлогддог. Порт нь интернетээс нэвтрэх боломжгүй байсан ч DMZ-ээр дамжуулан нэвтрэх боломжтой байв.
Мэдээжийн хэрэг, миний утсан дээрх програм хэлбэрээр нууцлагдсан дансанд "хоёр дахь хүчин зүйл" нэн даруй нэмэгдсэн. Үйлдлийг нь "зөвшөөрөх"/"зөвшөөрөхгүй" гэсэн товчлууруудаар утсанд чанга дуугаар түлхэх хүсэлт илгээх эсвэл цаашид бие даан оруулахын тулд OTP кодыг дэлгэцэн дээр чимээгүй харуулах програм байсан. Түүгээр ч барахгүй эхний арга нь зааврын дагуу цорын ганц зөв байх ёстой гэж үзсэн боловч OTP аргаас ялгаатай нь энэ нь ажиллахгүй байв.
"Хоёр дахь хүчин зүйл" эвдэрсэн тул би Outlook Web Access мэйл болон Citrix Netcaler Gateway-д алсаас хандах боломжтой болсон. Outlook дээр шуудангаар гэнэтийн зүйл ирсэн:
Энэхүү ховор зураг авалтаас та Роскомнадзор пентестерүүдэд хэрхэн тусалж байгааг харж болно
Эдгээр нь Telegram-ыг алдартай "фен"-ээр хааснаас хойшхи эхний сарууд бөгөөд олон мянган хаягтай бүхэл бүтэн сүлжээнүүд нэвтрэх боломжгүй болсон. Түлхэлт яагаад тэр дороо бүтэлгүйтсэн, миний "хохирогч" нээлттэй цагаар дансаа ашиглаж эхэлсэн тул яагаад дохиолол дуугаргаагүй нь тодорхой болов.
Citrix Netscaler-ийг мэддэг хэн бүхэн үүнийг ихэвчлэн хэрэглэгчдэд зөвхөн зургийн интерфейсээр дамжуулж болохуйц байдлаар хэрэгжүүлдэг гэж төсөөлж, түүнд гуравдагч этгээдийн програмуудыг ажиллуулах, өгөгдөл дамжуулах хэрэгслийг өгөхгүй байхыг хичээдэг бөгөөд үйлдлийг бүх талаар хязгаарладаг. стандарт хяналтын бүрхүүлээр дамжуулан. Миний "хохирогч" ажил мэргэжилийнхээ улмаас ердөө 1С авсан:
1С интерфэйсийг бага зэрэг алхсаны дараа би тэнд гадны боловсруулалтын модулиуд байгааг олж мэдэв. Тэдгээрийг интерфэйсээс ачаалж болох бөгөөд эрх, тохиргооноос хамааран үйлчлүүлэгч эсвэл сервер дээр ажиллах болно.
Би 1С програмист найзуудаасаа стринг хүлээн авч гүйцэтгэх процессыг бий болгохыг хүссэн. 1С хэл дээр процессыг эхлүүлэх нь иймэрхүү харагдаж байна (Интернэтээс авсан). 1С хэлний синтакс нь орос хэлээр ярьдаг хүмүүсийг аяндаа гайхшруулдаг гэдэгтэй та санал нийлж байна уу?
Боловсруулалтыг төгс гүйцэтгэсэн бөгөөд энэ нь пентестерүүдийн "бүрхүүл" гэж нэрлэдэг зүйл болж хувирсан - Internet Explorer-ийг түүгээр дамжуулан эхлүүлсэн.
Өмнө нь тухайн нутаг дэвсгэрт нэвтрэх тасалбар захиалах боломжийг олгодог системийн хаягийг шуудангаар олжээ. Би Wi-Fi халдлагын векторыг ашиглах шаардлагатай болсон тохиолдолд тасалбар захиалсан.
Үйлчлүүлэгчийн оффис дээр амттай үнэгүй хоолны газар байсаар байсан гэж интернетээр ярьдаг ч би халдлагыг алсаас хөгжүүлэхийг илүүд үзсэн, илүү тайван байна.
AppLocker нь Citrix дээр ажилладаг програмын сервер дээр идэвхжсэн боловч үүнийг алгассан. http(s) хувилбарууд холбогдохыг хүсээгүй тул тухайн үед би дотоод прокси хаягийг мэдэхгүй байсан тул ижил Meterpreter-ийг DNS-ээр ачаалж, эхлүүлсэн. Дашрамд хэлэхэд, энэ мөчөөс эхлэн гадаад pentest үндсэндээ дотоод болж хувирав.
4-р хэсэг. Хэрэглэгчийн админы эрх муу байна, за юу?
Домэйн хэрэглэгчийн сессийг удирдахдаа пентестерийн хамгийн эхний ажил бол домэйн дээрх эрхийн талаарх бүх мэдээллийг цуглуулах явдал юм. BloodHound хэрэгсэл байдаг бөгөөд энэ нь хэрэглэгч, компьютер, аюулгүй байдлын бүлгүүдийн талаарх мэдээллийг домэйн хянагчаас LDAP протоколоор дамжуулан автоматаар татаж авах, мөн SMB-ээр дамжуулан аль хэрэглэгч хаана нэвтэрсэн, локал администратор хэн болох тухай мэдээллийг автоматаар татаж авах боломжийг олгодог.
Домэйн администраторын эрхийг хураах ердийн арга нь нэгэн хэвийн үйлдлүүдийн цикл шиг хялбаршуулсан мэт харагдаж байна:
- Бид аль хэдийн баригдсан домэйн акаунтууд дээр үндэслэн локал администраторын эрх бүхий домэйн компьютерууд руу очдог.
- Бид Mimikatz-ийг ажиллуулж, энэ системд саяхан нэвтэрсэн домэйн бүртгэлүүдийн кэш нууц үг, Kerberos тасалбар болон NTLM хэшийг авдаг. Эсвэл бид lsass.exe процессын санах ойн дүрсийг устгаж, бидэнтэй ижил зүйлийг хийдэг. Энэ нь анхдагч тохиргоотой 2012R2/Windows 8.1-ээс бага хувилбартай Windows-д сайн ажилладаг.
- Нууцлагдсан акаунтууд локал администраторын эрхтэй хаана байгааг бид тодорхойлдог. Бид эхний цэгийг давтана. Зарим үе шатанд бид бүх домэйны администраторын эрхийг олж авдаг.
1С програмистууд энд бичдэг шиг "Циклийн төгсгөл;".
Тиймээс манай хэрэглэгч Windows 7 үйлдлийн системтэй, нэр нь "VDI" эсвэл "Виртуал ширээний дэд бүтэц", хувийн виртуал машин гэсэн үг агуулсан ганц хост дээр локал администратор болж хувирав. VDI үйлчилгээний зохион бүтээгч VDI нь хэрэглэгчийн хувийн үйлдлийн систем учраас хэрэглэгч програм хангамжийн орчныг хүссэнээрээ өөрчилсөн ч хостыг "дахин ачаалах" боломжтой гэсэн үг байх. Би бас ерөнхийдөө санаа сайхан байна гэж бодсон, би энэ хувийн VDI хост дээр очиж үүрээ зассан:
- Би тэнд OpenVPN клиент суулгасан бөгөөд энэ нь интернетээр дамжуулан миний сервер рүү хонгил хийсэн. Үйлчлүүлэгчийг домэйн баталгаажуулалттай ижил Цэнхэр цуваар нэвтрүүлэх шаардлагатай байсан ч OpenVPN үүнийг "хайрцагнаас нь гаргаж" хийсэн.
- VDI дээр OpenSSH суулгасан. За, үнэхээр SSH-гүй Windows 7 гэж юу вэ?
Амьдаар ингэж харагдсан. Энэ бүгдийг Citrix болон 1C-ээр дамжуулан хийх ёстой гэдгийг сануулъя.
Хөрш зэргэлдээх компьютерт хандах хандалтыг дэмжих нэг арга бол локал администраторын нууц үг таарч байгаа эсэхийг шалгах явдал юм. Энд тэр даруй аз хүлээж байв: анхдагч локал администраторын NTLM хэш (түүнийг гэнэт Администратор гэж нэрлэсэн) хөрш зэргэлдээх VDI хостууд руу хэш довтолгоогоор хандсан бөгөөд үүнээс хэдэн зуун байсан. Мэдээжийн хэрэг, дайралт тэднийг шууд цохив.
Энд VDI-ийн админууд хоёр удаа хөл рүүгээ бууджээ.
- Эхний удаад VDI машинуудыг LAPS-д оруулаагүй бөгөөд VDI-д их хэмжээгээр байршуулсан зураг дээрх локал администраторын нууц үгийг үндсэндээ хадгалсан.
- Өгөгдмөл администратор нь хэш дамжуулах халдлагад өртөмтгий цорын ганц дотоод бүртгэл юм. Ижил нууц үгтэй байсан ч гэсэн нарийн төвөгтэй санамсаргүй нууц үгээр хоёр дахь локал администраторын данс үүсгэж, анхдагч нууц үгийг блоклох замаар олон нийтийн эвдрэлээс зайлсхийх боломжтой.
Яагаад тэр Windows дээрх SSH үйлчилгээ вэ? Маш энгийн: одоо OpenSSH сервер нь хэрэглэгчийн ажилд саад учруулахгүйгээр тохиромжтой интерактив командын бүрхүүлээр хангаад зогсохгүй VDI дээрх socks5 прокси-г өгсөн. Энэ оймсоор дамжуулан би SMB-ээр холбогдож, эдгээр олон зуун VDI машинуудаас кэш дансуудыг цуглуулж, BloodHound графикаас тэдгээрийг ашиглан домэйн администратор руу орох замыг хайсан. Хэдэн зуун хостууд миний мэдэлд байгаа тул би энэ аргыг маш хурдан олсон. Домэйн администраторын эрхийг авсан.
Үүнтэй төстэй хайлтыг харуулсан интернетээс авсан зураг энд байна. Холболт нь администратор хаана байгааг, хэн хаана нэвтэрсэнийг харуулдаг.
Дашрамд хэлэхэд, төслийн эхнээс "нийгмийн инженерчлэлийг бүү ашигла" гэсэн нөхцөлийг санаарай. Тиймээс, хэрэв улиг болсон фишинг ашиглах боломжтой хэвээр байсан бол тусгай эффект бүхий Болливудыг хэр их таслах талаар бодохыг санал болгож байна. Гэхдээ би хувьдаа энэ бүхнийг хийх нь их сонирхолтой байсан. Та үүнийг уншихад таатай байсан гэж найдаж байна. Мэдээжийн хэрэг, төсөл бүр тийм ч сонирхолтой харагддаггүй, гэхдээ ажил бүхэлдээ маш хэцүү бөгөөд зогсонги байдалд орохыг зөвшөөрдөггүй.
Магадгүй хэн нэгэн асуулт асуух болно: өөрийгөө хэрхэн хамгаалах вэ? Энэ нийтлэлд хүртэл Windows-ын администраторууд мэддэггүй олон арга техникийг тайлбарласан болно. Гэсэн хэдий ч би эдгээрийг хакердсан зарчим, мэдээллийн аюулгүй байдлын арга хэмжээний үүднээс авч үзэхийг санал болгож байна.
- хуучирсан програм хангамжийг бүү ашигла (эхэндээ Windows 2003-ийг санаж байна уу?)
- Шаардлагагүй системийг бүү асаа (яагаад урологийн эмчийн вэбсайт байдаг вэ?)
- Хэрэглэгчийн нууц үгийг өөрөө шалгана уу (эсвэл цэрэг... пентестер үүнийг хийх болно)
- өөр өөр акаунтуудад ижил нууц үг байхгүй байх (VDI нууцлал)
- ба бусад
Мэдээжийн хэрэг, үүнийг хэрэгжүүлэхэд маш хэцүү боловч дараагийн өгүүллээр бид энэ нь бүрэн боломжтой гэдгийг практик дээр харуулах болно.
Эх сурвалж: www.habr.com