એકવાર પેન્ટેસ્ટ પર, અથવા યુરોલોજિસ્ટ અને રોસ્કોમનાડઝોરની મદદથી બધું કેવી રીતે તોડવું

આ લેખ એક ખૂબ જ સફળ પેન્ટેસ્ટના આધારે લખવામાં આવ્યો હતો જે ગ્રુપ-આઈબીના નિષ્ણાતોએ થોડા વર્ષો પહેલા હાથ ધર્યો હતો: એક વાર્તા બની હતી જેને બોલીવુડમાં ફિલ્મ માટે સ્વીકારી શકાય. હવે, સંભવતઃ, વાચકની પ્રતિક્રિયા અનુસરશે: "ઓહ, અન્ય PR લેખ, ફરીથી આનું ચિત્રણ કરવામાં આવી રહ્યું છે, તે કેટલા સારા છે, પેન્ટેસ્ટ ખરીદવાનું ભૂલશો નહીં." સારું, એક તરફ, તે છે. જો કે, આ લેખ શા માટે દેખાયો તેના અન્ય ઘણા કારણો છે. હું બતાવવા માંગતો હતો કે પેન્ટેસ્ટર્સ બરાબર શું કરે છે, આ કાર્ય કેટલું રસપ્રદ અને બિન-તુચ્છ હોઈ શકે છે, પ્રોજેક્ટ્સમાં કયા રમુજી સંજોગો ઉભા થઈ શકે છે અને સૌથી અગત્યનું, વાસ્તવિક ઉદાહરણો સાથે જીવંત સામગ્રી બતાવો.

વિશ્વમાં નમ્રતાના સંતુલનને પુનઃસ્થાપિત કરવા માટે, થોડા સમય પછી અમે એક પેન્ટેસ્ટ વિશે લખીશું જે સારું ન થયું. અમે બતાવીશું કે કંપનીમાં કેવી રીતે સારી રીતે ડિઝાઇન કરેલી પ્રક્રિયાઓ હુમલાઓની સંપૂર્ણ શ્રેણી સામે રક્ષણ આપી શકે છે, તે પણ સારી રીતે તૈયાર છે, ફક્ત એટલા માટે કે આ પ્રક્રિયાઓ અસ્તિત્વમાં છે અને વાસ્તવમાં કાર્ય કરે છે.

આ લેખમાં ગ્રાહક માટે, બધું પણ સામાન્ય રીતે ઉત્તમ હતું, અમારી લાગણીઓ અનુસાર, રશિયન ફેડરેશનમાં ઓછામાં ઓછું 95% બજાર કરતાં વધુ સારું, પરંતુ ત્યાં ઘણી નાની ઘોંઘાટ હતી જેણે ઘટનાઓની લાંબી સાંકળ રચી હતી, જે પ્રથમ કામ પર લાંબા અહેવાલ તરફ દોરી , અને પછી આ લેખ.

તો, ચાલો પોપકોર્નનો સ્ટોક કરીએ, અને ડિટેક્ટીવ સ્ટોરીમાં આપનું સ્વાગત છે. શબ્દ - પાવેલ સુપ્રુન્યુક, ગ્રુપ-આઈબીના "ઓડિટ અને કન્સલ્ટિંગ" વિભાગના ટેકનિકલ મેનેજર.

ભાગ 1. Pochkin ડૉક્ટર

2018 એક ગ્રાહક છે - એક હાઇ-ટેક આઇટી કંપની, જે પોતે ઘણા ગ્રાહકોને સેવા આપે છે. પ્રશ્નનો જવાબ મેળવવા માંગે છે: શું ઈન્ટરનેટ દ્વારા કામ કરતી વખતે કોઈપણ પ્રારંભિક જાણકારી અને ઍક્સેસ વગર એક્ટિવ ડિરેક્ટરી ડોમેન એડમિનિસ્ટ્રેટર અધિકારો મેળવવાનું શક્ય છે? મને કોઈ સોશિયલ એન્જિનિયરિંગમાં રસ નથી (ઓહ, પરંતુ નિરર્થક), તેઓ હેતુસરના કાર્યમાં દખલ કરવાનો ઇરાદો ધરાવતા નથી, પરંતુ તેઓ આકસ્મિક રીતે - ઉદાહરણ તરીકે, વિચિત્ર રીતે કાર્યરત સર્વરને ફરીથી લોડ કરી શકે છે. એક વધારાનો ધ્યેય બાહ્ય પરિમિતિ સામે શક્ય તેટલા અન્ય હુમલા વેક્ટર્સને ઓળખવાનો છે. કંપની નિયમિતપણે આવા પરીક્ષણો કરે છે, અને હવે નવા પરીક્ષણની અંતિમ તારીખ આવી ગઈ છે. શરતો લગભગ લાક્ષણિક, પર્યાપ્ત, સમજી શકાય તેવી છે. ચાલો, શરુ કરીએ.

ગ્રાહકનું નામ છે - તેને મુખ્ય વેબસાઇટ સાથે “કંપની” રહેવા દો www.company.ru. અલબત્ત, ગ્રાહકને અલગ રીતે કહેવામાં આવે છે, પરંતુ આ લેખમાં બધું નૈતિક હશે.
હું નેટવર્ક રિકોનિસન્સનું સંચાલન કરું છું - ગ્રાહક સાથે કયા સરનામાં અને ડોમેન્સ નોંધાયેલા છે તે શોધો, નેટવર્ક ડાયાગ્રામ દોરો, આ સરનામાં પર સેવાઓ કેવી રીતે વિતરિત કરવામાં આવે છે. મને પરિણામ મળ્યું: 4000 થી વધુ જીવંત IP સરનામાં. હું આ નેટવર્ક્સમાં ડોમેન્સ જોઉં છું: સદભાગ્યે, મોટા ભાગના નેટવર્ક્સ ગ્રાહકના ક્લાયન્ટ્સ માટે બનાવાયેલ છે, અને અમને ઔપચારિક રીતે તેમાં રસ નથી. ગ્રાહક પણ એવું જ વિચારે છે.

256 સરનામાંઓ સાથેનું એક નેટવર્ક બાકી છે, જેના માટે આ ક્ષણ સુધીમાં IP સરનામાંઓ દ્વારા ડોમેન્સ અને સબડોમેન્સનાં વિતરણની સમજણ છે, ત્યાં સ્કેન કરેલા પોર્ટ્સ વિશેની માહિતી છે, જેનો અર્થ છે કે તમે રસપ્રદ લોકો માટેની સેવાઓ જોઈ શકો છો. સમાંતરમાં, તમામ પ્રકારના સ્કેનર્સ ઉપલબ્ધ IP એડ્રેસ પર અને વેબસાઇટ્સ પર અલગથી લૉન્ચ કરવામાં આવે છે.

ત્યાં ઘણી બધી સેવાઓ છે. સામાન્ય રીતે પેન્ટેસ્ટર માટે આ આનંદ અને ઝડપી વિજયની અપેક્ષા છે, કારણ કે ત્યાં વધુ સેવાઓ છે, હુમલા માટેનું ક્ષેત્ર મોટું છે અને આર્ટિફેક્ટ શોધવાનું સરળ છે. વેબસાઈટો પર એક ઝડપી નજર બતાવે છે કે તેમાંના મોટા ભાગની મોટી વૈશ્વિક કંપનીઓના જાણીતા ઉત્પાદનોના વેબ ઈન્ટરફેસ છે, જે તમામ દેખાવ દ્વારા તમને જણાવે છે કે તેઓ આવકાર્ય નથી. તેઓ વપરાશકર્તાનામ અને પાસવર્ડ માટે પૂછે છે, બીજું પરિબળ દાખલ કરવા માટે ક્ષેત્રને હલાવો, TLS ક્લાયંટ પ્રમાણપત્ર માટે પૂછો અથવા તેને Microsoft ADFS ને મોકલો. કેટલાક ઇન્ટરનેટથી અગમ્ય છે. કેટલાક માટે, તમારે દેખીતી રીતે ત્રણ પગાર માટે વિશિષ્ટ પેઇડ ક્લાયંટ હોવું જરૂરી છે અથવા દાખલ કરવા માટે ચોક્કસ URL જાણવું જોઈએ. ચાલો જાણીતી નબળાઈઓ માટે સોફ્ટવેર વર્ઝનને "બ્રેક થ્રુ" કરવાનો પ્રયાસ કરવાની પ્રક્રિયામાં, વેબ પાથમાં છુપાયેલ સામગ્રી શોધવા અને LinkedIn જેવી તૃતીય-પક્ષ સેવાઓમાંથી લીક થયેલા એકાઉન્ટ્સ, તેનો ઉપયોગ કરીને પાસવર્ડ્સનું અનુમાન કરવાનો પ્રયાસ કરવાની પ્રક્રિયામાં ધીમે ધીમે નિરાશાના બીજા અઠવાડિયાને છોડી દઈએ. સ્વ-લેખિત વેબસાઇટ્સમાં ખોદકામ કરતી નબળાઈઓ તરીકે — માર્ગ દ્વારા, આંકડા અનુસાર, આ આજે બાહ્ય હુમલાનું સૌથી આશાસ્પદ વેક્ટર છે. હું તરત જ મૂવી બંદૂકની નોંધ લઈશ જેણે પછીથી ફાયરિંગ કર્યું.

તેથી, અમને બે સાઇટ્સ મળી જે સેંકડો સેવાઓમાંથી અલગ હતી. આ સાઇટ્સમાં એક વસ્તુ સામાન્ય હતી: જો તમે ડોમેન દ્વારા ઝીણવટભરી નેટવર્ક રિકોનિસન્સમાં જોડાશો નહીં, પરંતુ ખુલ્લા બંદરો માટે આગળ જુઓ અથવા જાણીતી IP રેન્જનો ઉપયોગ કરીને નબળાઈ સ્કેનરને લક્ષ્ય બનાવશો, તો આ સાઇટ્સ સ્કેનીંગમાંથી છટકી જશે અને સરળ રીતે નહીં. DNS નામ જાણ્યા વિના દૃશ્યમાન. કદાચ તેઓ અગાઉ ચૂકી ગયા હતા, ઓછામાં ઓછા, અને અમારા સ્વચાલિત ટૂલ્સને તેમની સાથે કોઈ સમસ્યા મળી નથી, ભલે તેઓ સીધા સંસાધન પર મોકલવામાં આવ્યા હોય.

માર્ગ દ્વારા, સામાન્ય રીતે અગાઉ લૉન્ચ કરાયેલા સ્કેનર્સ વિશે. ચાલો હું તમને યાદ કરાવું: કેટલાક લોકો માટે, "પેન્ટેસ્ટ" એ "ઓટોમેટેડ સ્કેન" ની સમકક્ષ છે. પરંતુ આ પ્રોજેક્ટ પરના સ્કેનરોએ કંઈ કહ્યું નથી. સારું, મહત્તમ મધ્યમ નબળાઈઓ (ગંભીરતાના સંદર્ભમાં 3 માંથી 5) દ્વારા દર્શાવવામાં આવ્યું હતું: કેટલીક સેવા પર ખરાબ TLS પ્રમાણપત્ર અથવા જૂના એન્ક્રિપ્શન અલ્ગોરિધમ્સ અને મોટાભાગની સાઇટ્સ પર ક્લિકજેકિંગ. પરંતુ આ તમને તમારા લક્ષ્ય સુધી પહોંચાડશે નહીં. કદાચ સ્કેનર્સ અહીં વધુ ઉપયોગી થશે, પરંતુ હું તમને યાદ અપાવીશ: ગ્રાહક પોતે આવા પ્રોગ્રામ્સ ખરીદી શકે છે અને તેની સાથે પોતાની જાતને ચકાસી શકે છે, અને, નિરાશાજનક પરિણામોને ધ્યાનમાં રાખીને, તેણે પહેલેથી જ તપાસ કરી છે.

ચાલો "અસંગત" સાઇટ્સ પર પાછા આવીએ. પ્રથમ બિન-માનક સરનામાં પર સ્થાનિક વિકી જેવું કંઈક છે, પરંતુ આ લેખમાં તેને wiki.company[.]ru રહેવા દો. તેણીએ તરત જ લોગિન અને પાસવર્ડ પણ પૂછ્યો, પરંતુ બ્રાઉઝરમાં એનટીએલએમ દ્વારા. વપરાશકર્તા માટે, આ એક સન્યાસી વિન્ડો જેવું લાગે છે જે વપરાશકર્તા નામ અને પાસવર્ડ દાખલ કરવાનું કહે છે. અને આ ખરાબ પ્રથા છે.

એક નાની નોંધ. પરિમિતિ વેબસાઇટ્સમાં NTLM ઘણા કારણોસર ખરાબ છે. પહેલું કારણ એ છે કે એક્ટિવ ડિરેક્ટરી ડોમેન નેમ જાહેર કરવામાં આવ્યું છે. અમારા ઉદાહરણમાં, તે "બાહ્ય" DNS નામની જેમ company.ru પણ બન્યું. આ જાણીને, તમે કાળજીપૂર્વક કંઈક દૂષિત તૈયાર કરી શકો છો જેથી કરીને તે ફક્ત સંસ્થાના ડોમેન મશીન પર જ ચલાવવામાં આવે, અને કેટલાક સેન્ડબોક્સમાં નહીં. બીજું, પ્રમાણીકરણ સીધું NTLM (આશ્ચર્ય, ખરું?) મારફતે ડોમેન નિયંત્રક દ્વારા જાય છે, જેમાં "આંતરિક" નેટવર્ક નીતિઓની તમામ વિશેષતાઓ છે, જેમાં એકાઉન્ટને પાસવર્ડ એન્ટ્રીના પ્રયાસોની સંખ્યાને વટાવતા અટકાવવા સહિતનો સમાવેશ થાય છે. જો કોઈ હુમલાખોરને લૉગિન મળી જાય, તો તે તેમના માટે પાસવર્ડ અજમાવશે. જો તમે એકાઉન્ટ્સને ખોટા પાસવર્ડ્સ દાખલ કરવાથી અવરોધિત કરવા માટે ગોઠવેલા છો, તો તે કાર્ય કરશે અને એકાઉન્ટ અવરોધિત થઈ જશે. ત્રીજું, આવા પ્રમાણીકરણમાં બીજું પરિબળ ઉમેરવું અશક્ય છે. જો કોઈ વાચકો હજુ પણ કેવી રીતે જાણતા હોય, તો કૃપા કરીને મને જણાવો, તે ખરેખર રસપ્રદ છે. ચોથું, પાસ-ધ-હેશ હુમલાઓ માટે નબળાઈ. આ બધા સામે રક્ષણ આપવા માટે અન્ય વસ્તુઓની સાથે ADFS ની શોધ કરવામાં આવી હતી.

Microsoft ઉત્પાદનોની એક ખરાબ મિલકત છે: જો તમે આવા NTLM ને ખાસ પ્રકાશિત ન કર્યું હોય તો પણ, તે ઓછામાં ઓછું OWA અને Lync માં ડિફોલ્ટ રૂપે ઇન્સ્ટોલ થશે.

માર્ગ દ્વારા, આ લેખના લેખકે એકવાર આકસ્મિક રીતે એક જ પદ્ધતિનો ઉપયોગ કરીને માત્ર એક કલાકમાં એક મોટી બેંકના કર્મચારીઓના અંદાજે 1000 એકાઉન્ટ્સને અવરોધિત કર્યા અને પછી તે કંઈક અંશે નિસ્તેજ દેખાયા. બેંકની IT સેવાઓ પણ નિસ્તેજ હતી, પરંતુ બધું સારી રીતે અને પર્યાપ્ત રીતે સમાપ્ત થયું, આ સમસ્યાને શોધવામાં અને ઝડપી અને નિર્ણાયક ઉકેલ માટે ઉશ્કેરવામાં પ્રથમ હોવા બદલ અમારી પ્રશંસા પણ થઈ.

બીજી સાઇટનું સરનામું "દેખીતી રીતે અમુક પ્રકારનું છેલ્લું name.company.ru" હતું. તે Google દ્વારા મળ્યું, પૃષ્ઠ 10 પર કંઈક આના જેવું. આ ડિઝાઇન XNUMX ના દાયકાની શરૂઆતના મધ્યભાગની હતી, અને એક આદરણીય વ્યક્તિ તેને મુખ્ય પૃષ્ઠથી જોઈ રહી હતી, કંઈક આના જેવું:

અહીં મેં "હાર્ટ ઓફ એ ડોગ" માંથી સ્ટેલ લીધો, પરંતુ મારા પર વિશ્વાસ કરો, તે અસ્પષ્ટ રીતે સમાન હતું, રંગ ડિઝાઇન પણ સમાન ટોનમાં હતી. સાઇટને બોલાવવા દો preobrazhensky.company.ru.

તે યુરોલોજિસ્ટ માટે વ્યક્તિગત વેબસાઇટ હતી. મને આશ્ચર્ય થયું કે યુરોલોજિસ્ટની વેબસાઇટ હાઇ-ટેક કંપનીના સબડોમેઇન પર શું કરી રહી છે. Google માં એક ઝડપી તપાસ દર્શાવે છે કે આ ડૉક્ટર અમારા ગ્રાહકની કાનૂની સંસ્થાઓમાંથી એકના સહ-સ્થાપક હતા અને અધિકૃત મૂડીમાં લગભગ 1000 રુબેલ્સનું યોગદાન પણ આપ્યું હતું. આ સાઇટ કદાચ ઘણા વર્ષો પહેલા બનાવવામાં આવી હતી, અને ગ્રાહકના સર્વર સંસાધનોનો ઉપયોગ હોસ્ટિંગ તરીકે કરવામાં આવ્યો હતો. સાઇટે લાંબા સમયથી તેની સુસંગતતા ગુમાવી દીધી છે, પરંતુ કેટલાક કારણોસર તે લાંબા સમય સુધી કામ કરવાનું છોડી દીધું હતું.

નબળાઈઓના સંદર્ભમાં, વેબસાઇટ પોતે સુરક્ષિત હતી. આગળ જોતાં, હું કહીશ કે તે સ્થિર માહિતીનો સમૂહ હતો - કિડની અને મૂત્રાશયના સ્વરૂપમાં દાખલ કરેલા ચિત્રો સાથે સરળ HTML પૃષ્ઠો. આવી સાઇટને "તોડવું" નકામું છે.

પરંતુ તેની નીચેનું વેબ સર્વર વધુ રસપ્રદ હતું. HTTP સર્વર હેડર દ્વારા નક્કી કરવામાં આવે તો, તે IIS 6.0 ચલાવી રહ્યું હતું, જેનો અર્થ એ થયો કે તેનો ઉપયોગ થઈ રહ્યો હતો. Windows 2003 ઓપરેટિંગ સિસ્ટમ તરીકે. સ્કેનરે અગાઉ શોધી કાઢ્યું હતું કે આ ચોક્કસ યુરોલોજિસ્ટની વેબસાઇટ, સમાન વેબ સર્વર પરના અન્ય વર્ચ્યુઅલ હોસ્ટથી વિપરીત, PROPFIND આદેશનો જવાબ આપે છે, જેનો અર્થ છે કે WebDAV સક્ષમ હતું. આકસ્મિક રીતે, સ્કેનરે આ માહિતીને ઇન્ફો ફ્લેગ સાથે રિપોર્ટ કરી હતી (સ્કેનર રિપોર્ટિંગ ભાષામાં, આ સૌથી ઓછું જોખમ છે) - આવી બાબતોને સામાન્ય રીતે અવગણવામાં આવે છે. સંયુક્ત રીતે, આણે એક રસપ્રદ અસર ઉત્પન્ન કરી જે ફક્ત થોડી વધુ ગુગલિંગ પછી જ શોધી કાઢવામાં આવી હતી: શેડો બ્રોકર્સ કીટ સાથે સંકળાયેલ એક દુર્લભ બફર ઓવરફ્લો નબળાઈ, ખાસ કરીને CVE-2017-7269, જેમાં પહેલાથી જ તૈયાર શોષણ હતું. બીજા શબ્દોમાં કહીએ તો, તે એક આપત્તિ છે જો તમે... Windows 2003 અને WebDAV IIS પર ચાલી રહ્યું છે. જોકે તે ઉત્પાદનમાં કામ કરે છે Windows ૨૦૧૮ માં ૨૦૦૩ એ પોતાનામાં એક આપત્તિ છે.

શોષણ મેટાસ્પ્લોઈટમાં સમાપ્ત થયું અને તરત જ લોડ સાથે પરીક્ષણ કરવામાં આવ્યું જેણે નિયંત્રિત સેવાને DNS વિનંતી મોકલી - બર્પ કોલાબોરેટર પરંપરાગત રીતે DNS વિનંતીઓને પકડવા માટે વપરાય છે. મારા આશ્ચર્ય માટે, તે પ્રથમ વખત કામ કર્યું: DNS નોકઆઉટ પ્રાપ્ત થયું. આગળ, પોર્ટ 80 દ્વારા બેકકનેક્ટ બનાવવાનો પ્રયાસ કરવામાં આવ્યો હતો (એટલે ​​કે, સર્વરથી હુમલાખોર સુધીનું નેટવર્ક કનેક્શન, પીડિત હોસ્ટ પર cmd.exe ની ઍક્સેસ સાથે), પરંતુ પછી એક ફિયાસ્કો થયો. કનેક્શન આવ્યું ન હતું, અને સાઇટનો ઉપયોગ કરવાના ત્રીજા પ્રયાસ પછી, તમામ રસપ્રદ ચિત્રો સાથે, કાયમ માટે અદૃશ્ય થઈ ગયું.

સામાન્ય રીતે આ પછી "ગ્રાહક, જાગો, અમે બધું છોડી દીધું" ની શૈલીમાં એક પત્ર આવે છે. પરંતુ અમને કહેવામાં આવ્યું હતું કે આ સાઇટને વ્યવસાયિક પ્રક્રિયાઓ સાથે કોઈ લેવાદેવા નથી અને આખા સર્વરની જેમ, કોઈ કારણ વગર ત્યાં કામ કરે છે, અને અમે આ સંસાધનનો અમારી ઈચ્છા મુજબ ઉપયોગ કરી શકીએ છીએ.
લગભગ એક દિવસ પછી સાઇટે અચાનક પોતાની રીતે કામ કરવાનું શરૂ કર્યું. IIS 6.0 પર WebDAV માંથી બેન્ચ બનાવ્યા પછી, મને જાણવા મળ્યું કે ડિફોલ્ટ સેટિંગ દર 30 કલાકે IIS વર્કર પ્રક્રિયાઓને પુનઃપ્રારંભ કરવાની છે. એટલે કે, જ્યારે કંટ્રોલ શેલકોડમાંથી બહાર નીકળે છે, ત્યારે IIS કાર્યકર પ્રક્રિયા સમાપ્ત થઈ જાય છે, પછી તે પોતાની જાતને બે વખત પુનઃપ્રારંભ કરે છે અને પછી 30 કલાક માટે આરામ કરે છે.

tcp સાથે બેકકનેક્ટ પ્રથમ વખત નિષ્ફળ થયું હોવાથી, મેં આ સમસ્યાને બંધ પોર્ટને આભારી છે. એટલે કે, તેણે અમુક પ્રકારની ફાયરવોલની હાજરી માની હતી જે આઉટગોઇંગ કનેક્શનને બહારથી પસાર થવા દેતી નથી. મેં શેલકોડ્સ ચલાવવાનું શરૂ કર્યું જે ઘણા tcp અને udp પોર્ટ દ્વારા શોધ્યું, ત્યાં કોઈ અસર થઈ ન હતી. Metasploit માંથી http(s) દ્વારા રિવર્સ કનેક્શન લોડ્સ કામ કરતું નથી - meterpreter/reverse_http(s). અચાનક, તે જ પોર્ટ 80 સાથે જોડાણ સ્થાપિત થયું, પરંતુ તરત જ ઘટી ગયું. મેં આનો શ્રેય હજુ પણ કાલ્પનિક IPS ની ક્રિયાને આપ્યો, જેને મીટરપ્રીટર ટ્રાફિક પસંદ ન હતો. હકીકત એ છે કે પોર્ટ 80 સાથેનું શુદ્ધ tcp કનેક્શન પસાર થયું ન હતું, પરંતુ HTTP કનેક્શન થયું હતું, મેં તારણ કાઢ્યું કે સિસ્ટમમાં HTTP પ્રોક્સી કોઈક રીતે ગોઠવવામાં આવી હતી.

મેં DNS દ્વારા મીટરપ્રીટરનો પણ પ્રયાસ કર્યો (આભાર d00kie તમારા પ્રયત્નો માટે, ઘણા પ્રોજેક્ટ્સ સાચવ્યા), પ્રથમ સફળતાને યાદ કરીને, પરંતુ તે સ્ટેન્ડ પર પણ કામ કરતું ન હતું - આ નબળાઈ માટે શેલકોડ ખૂબ પ્રચંડ હતો.

વાસ્તવમાં, તે આના જેવું દેખાતું હતું: 3 મિનિટમાં હુમલાના 4-5 પ્રયાસો, પછી 30 કલાકની રાહ જુઓ. અને તેથી સતત ત્રણ અઠવાડિયા સુધી. મેં એક રીમાઇન્ડર પણ સેટ કર્યું છે જેથી સમયનો બગાડ ન થાય. વધુમાં, પરીક્ષણ અને ઉત્પાદન વાતાવરણની વર્તણૂકમાં તફાવત હતો: આ નબળાઈ માટે બે સમાન શોષણ હતા, એક મેટાસ્પ્લોઈટમાંથી, બીજો ઈન્ટરનેટમાંથી, શેડો બ્રોકર્સ સંસ્કરણમાંથી રૂપાંતરિત. તેથી, લડાઇમાં ફક્ત મેટાસ્પ્લોઇટનું પરીક્ષણ કરવામાં આવ્યું હતું, અને બેન્ચ પર ફક્ત બીજાનું પરીક્ષણ કરવામાં આવ્યું હતું, જેણે ડિબગિંગને વધુ મુશ્કેલ બનાવ્યું હતું અને મગજ-બસ્ટિંગ હતું.

અંતે, એક શેલકોડ કે જેણે આપેલ સર્વરમાંથી HTTP મારફતે exe ફાઇલ ડાઉનલોડ કરી અને તેને લક્ષ્ય સિસ્ટમ પર લોન્ચ કરી તે અસરકારક સાબિત થયું. શેલકોડ ફિટ થવા માટે પૂરતો નાનો હતો, પરંતુ ઓછામાં ઓછું તે કામ કરતું હતું. સર્વરને TCP ટ્રાફિક બિલકુલ પસંદ ન હોવાથી અને મીટરપ્રેટરની હાજરી માટે http(s) ની તપાસ કરવામાં આવી હતી, તેથી મેં નક્કી કર્યું કે આ શેલકોડ દ્વારા DNS-meterpreter ધરાવતી exe ફાઇલ ડાઉનલોડ કરવાનો સૌથી ઝડપી રસ્તો છે.

અહીં ફરીથી એક સમસ્યા ઊભી થઈ: exe ફાઇલ ડાઉનલોડ કરતી વખતે અને, પ્રયત્નો બતાવ્યા પ્રમાણે, પછી ભલે તે કોઈ પણ હોય, ડાઉનલોડમાં વિક્ષેપ પડ્યો હતો. ફરીથી, મારા સર્વર અને યુરોલોજિસ્ટ વચ્ચેના કેટલાક સુરક્ષા ઉપકરણને અંદર એક exe સાથે http ટ્રાફિક પસંદ ન હતો. "ઝડપી" સોલ્યુશન શેલકોડને બદલવાનું હોય તેવું લાગતું હતું જેથી તે ફ્લાય પર HTTP ટ્રાફિકને અસ્પષ્ટ કરે, જેથી exe ને બદલે અમૂર્ત દ્વિસંગી ડેટા સ્થાનાંતરિત થાય. અંતે, હુમલો સફળ થયો, પાતળા DNS ચેનલ દ્વારા નિયંત્રણ પ્રાપ્ત થયું:

તે તરત જ સ્પષ્ટ થઈ ગયું કે મારી પાસે સૌથી મૂળભૂત IIS વર્કફ્લો અધિકારો છે, જે મને કંઈ કરવાની મંજૂરી આપતા નથી. મેટાસ્પ્લોઈટ કન્સોલ પર તે આના જેવું દેખાતું હતું:

તમામ પેન્ટેસ્ટ પદ્ધતિઓ ભારપૂર્વક સૂચવે છે કે ઍક્સેસ મેળવતી વખતે તમારે અધિકારો વધારવાની જરૂર છે. હું સામાન્ય રીતે આ સ્થાનિક રીતે કરતો નથી, કારણ કે ખૂબ જ પ્રથમ ઍક્સેસને ફક્ત નેટવર્ક એન્ટ્રી પોઈન્ટ તરીકે જોવામાં આવે છે, અને તે જ નેટવર્ક પર અન્ય મશીન સાથે સમાધાન કરવું એ હાલના હોસ્ટ પર વિશેષાધિકારો વધારવા કરતાં સામાન્ય રીતે સરળ અને ઝડપી છે. પરંતુ અહીં એવું નથી, કારણ કે DNS ચેનલ ખૂબ જ સાંકડી છે અને તે ટ્રાફિકને સાફ થવા દેતી નથી.

ધારો કે આ સર્વર છે Windows ૨૦૦૩ માં કુખ્યાત MS17-010 નબળાઈ માટે પેચ કરવામાં આવ્યો ન હતો. મેં મીટરપ્રીટર DNS ટનલ દ્વારા પોર્ટ ૪૪૫/TCP પર ટ્રાફિકને લોકલહોસ્ટમાં ટનલ કર્યો (હા, તે શક્ય છે) અને નબળાઈ દ્વારા અગાઉ ડાઉનલોડ કરેલ .exe ચલાવવાનો પ્રયાસ કર્યો. હુમલો કામ કરી ગયો, અને મને બીજું કનેક્શન મળ્યું, પરંતુ આ વખતે SYSTEM વિશેષાધિકારો સાથે.

તે રસપ્રદ છે કે તેઓએ હજી પણ MS17-010 થી સર્વરને સુરક્ષિત કરવાનો પ્રયાસ કર્યો હતો - તેમાં બાહ્ય ઇન્ટરફેસ પર નબળા નેટવર્ક સેવાઓ અક્ષમ હતી. આ નેટવર્ક પરના હુમલાઓ સામે રક્ષણ આપે છે, પરંતુ લોકલહોસ્ટ પર અંદરથી હુમલો કામ કરે છે, કારણ કે તમે લોકલહોસ્ટ પર SMBને ઝડપથી બંધ કરી શકતા નથી.

આગળ, નવી રસપ્રદ વિગતો જાહેર કરવામાં આવી છે:

1. સિસ્ટમ અધિકારો ધરાવતાં, તમે TCP દ્વારા સરળતાથી બેકકનેક્શન સ્થાપિત કરી શકો છો. દેખીતી રીતે, સીમિત IIS વપરાશકર્તા માટે ડાયરેક્ટ TCP ને અક્ષમ કરવું એ સખત સમસ્યા છે. સ્પોઈલર: IIS વપરાશકર્તા ટ્રાફિક કોઈક રીતે સ્થાનિક ISA પ્રોક્સીમાં બંને દિશામાં લપેટાયેલો હતો. તે બરાબર કેવી રીતે કાર્ય કરે છે, મેં પુનઃઉત્પાદન કર્યું નથી.
2. હું ચોક્કસ "DMZ" માં છું (અને આ એક એક્ટિવ ડિરેક્ટરી ડોમેન નથી, પરંતુ વર્કગ્રુપ છે) - તે તાર્કિક લાગે છે. પરંતુ અપેક્ષિત ખાનગી ("ગ્રે") IP સરનામાંને બદલે, મારી પાસે સંપૂર્ણ "સફેદ" IP સરનામું છે, જે મેં અગાઉ હુમલો કર્યો હતો તેના જેવું જ છે. આનો અર્થ એ થયો કે કંપની IPv4 એડ્રેસિંગની દુનિયામાં એટલી જૂની છે કે તે 128 થી સિસ્કો મેન્યુઅલમાં દર્શાવ્યા મુજબ, NAT વગર 2005 “વ્હાઈટ” એડ્રેસ માટે DMZ ઝોન જાળવવાનું પરવડે છે.

સર્વર જૂનું હોવાથી, Mimikatz ને મેમરીમાંથી સીધા જ કામ કરવાની ખાતરી આપવામાં આવે છે:

મને સ્થાનિક એડમિનિસ્ટ્રેટર પાસવર્ડ મળે છે, TCP પર RDP ટ્રાફિક ટનલ થાય છે, અને હું આરામદાયક ડેસ્કટોપમાં લોગ ઇન કરું છું. હું સર્વર સાથે કંઈપણ કરી શકતો હોવાથી, મેં એન્ટીવાયરસ અનઇન્સ્ટોલ કર્યું અને જોયું કે સર્વર ફક્ત TCP પોર્ટ 80 અને 443 દ્વારા જ ઇન્ટરનેટ પરથી ઍક્સેસ કરી શકાય છે, જેમાં 443 ખાલી છે. મેં સર્વરને 443 પર લાવ્યું. OpenVPN, હું મારા VPN ટ્રાફિક માટે NAT ફંક્શન્સ ઉમેરું છું અને મારા દ્વારા અમર્યાદિત સ્વરૂપમાં DMZ નેટવર્કની સીધી ઍક્સેસ મેળવું છું OpenVPNએ નોંધવું યોગ્ય છે કે ISA, કેટલીક બિન-નિષ્ક્રિય IPS સુવિધાઓ હોવા છતાં, મારા પોતાના પોર્ટ-સ્કેનિંગ ટ્રાફિકને અવરોધિત કરે છે, જેના કારણે મને તેને સરળ અને વધુ સુસંગત RRAS સાથે બદલવાની ફરજ પડી છે. તેથી, પેન્ટેસ્ટર્સને હજુ પણ ક્યારેક વસ્તુઓનું સંચાલન કરવું પડે છે.

એક સચેત વાચક પૂછશે: "બીજી સાઇટ વિશે શું - NTLM પ્રમાણીકરણ સાથેની વિકી, જેના વિશે ઘણું બધું લખવામાં આવ્યું છે?" આ વિશે પછીથી વધુ.

ભાગ 2: હજુ પણ એન્ક્રિપ્ટ નથી? તો પછી અમે તમારી પાસે પહેલેથી જ અહીં આવી રહ્યા છીએ

તેથી, DMZ નેટવર્ક સેગમેન્ટની ઍક્સેસ છે. તમારે ડોમેન એડમિનિસ્ટ્રેટર પર જવાની જરૂર છે. પ્રથમ વસ્તુ જે ધ્યાનમાં આવે છે તે DMZ સેગમેન્ટમાં સેવાઓની સુરક્ષાને આપમેળે તપાસવાની છે, ખાસ કરીને કારણ કે તેમાંથી ઘણી વધુ હવે સંશોધન માટે ખુલ્લી છે. ઘૂંસપેંઠ પરીક્ષણ દરમિયાન એક લાક્ષણિક ચિત્ર: બાહ્ય પરિમિતિ આંતરિક સેવાઓ કરતાં વધુ સારી રીતે સુરક્ષિત છે, અને જ્યારે મોટા ઈન્ફ્રાસ્ટ્રક્ચરની અંદર કોઈપણ ઍક્સેસ મેળવે છે, ત્યારે ડોમેનમાં વિસ્તૃત અધિકારો મેળવવાનું ખૂબ સરળ છે કારણ કે આ ડોમેન બનવાનું શરૂ થાય છે. ટૂલ્સ માટે સુલભ, અને બીજું, હજારો યજમાનો સાથેના ઈન્ફ્રાસ્ટ્રક્ચરમાં, હંમેશા કેટલીક જટિલ સમસ્યાઓ હશે.

હું DMZ દ્વારા સ્કેનર્સ ચાર્જ કરું છું OpenVPNટનલ, હું રાહ જોઈ રહ્યો છું. હું રિપોર્ટ ખોલું છું - ફરીથી, કંઈ ગંભીર નથી; દેખીતી રીતે કોઈ બીજાએ પહેલાં પણ આવું જ કર્યું છે. આગળનું પગલું એ તપાસવાનું છે કે DMZ નેટવર્કમાં હોસ્ટ કેવી રીતે વાતચીત કરે છે. આ કરવા માટે, હું પહેલા Wireshark લોન્ચ કરું છું અને બ્રોડકાસ્ટ વિનંતીઓ સાંભળું છું, મુખ્યત્વે ARP. ARP પેકેટો આખા દિવસ માટે એકત્રિત કરવામાં આવ્યા હતા. તે તારણ આપે છે કે આ સેગમેન્ટમાં બહુવિધ ગેટવેનો ઉપયોગ થાય છે. આ પછી ઉપયોગી થશે. ARP વિનંતી-પ્રતિભાવ ડેટાને પોર્ટ સ્કેન ડેટા સાથે મર્જ કરીને, મને સ્થાનિક નેટવર્કમાંથી વપરાશકર્તા ટ્રાફિક માટે એક્ઝિટ પોઇન્ટ મળ્યા, અગાઉ જાણીતી સેવાઓ ઉપરાંત, જેમ કે વેબ અને મેઇલ.

આ ક્ષણે મારી પાસે અન્ય સિસ્ટમ્સની કોઈ ઍક્સેસ ન હોવાથી અને કોર્પોરેટ સેવાઓ માટે એક પણ ખાતું ન હોવાથી, એઆરપી સ્પૂફિંગનો ઉપયોગ કરીને ટ્રાફિકમાંથી ઓછામાં ઓછું અમુક એકાઉન્ટ બહાર કાઢવાનું નક્કી કરવામાં આવ્યું હતું.

Cain&Abel ને યુરોલોજિસ્ટના સર્વર પર લોન્ચ કરવામાં આવ્યું હતું. ઓળખાયેલ ટ્રાફિક પ્રવાહોને ધ્યાનમાં લેતા, મેન-ઇન-ધ-મિડલ એટેક માટે સૌથી વધુ આશાસ્પદ જોડી પસંદ કરવામાં આવી હતી, અને પછી સર્વર રીબૂટ કરવા માટે ટાઈમર સાથે, 5-10 મિનિટ માટે ટૂંકા ગાળાના લોન્ચ દ્વારા કેટલાક નેટવર્ક ટ્રાફિક પ્રાપ્ત થયા હતા. ઠંડું થવાના કિસ્સામાં. મજાકની જેમ, ત્યાં બે સમાચાર હતા:

1. સારું: ઘણા બધા ઓળખપત્રો પકડાયા હતા અને સમગ્ર હુમલાએ કામ કર્યું હતું.
2. ખરાબ: તમામ ઓળખપત્રો ગ્રાહકના પોતાના ગ્રાહકોના હતા. સપોર્ટ સેવાઓ પ્રદાન કરતી વખતે, ગ્રાહક નિષ્ણાતો ગ્રાહકોની સેવાઓ સાથે જોડાયેલા હોય છે જેમણે હંમેશા ટ્રાફિક એન્ક્રિપ્શન ગોઠવેલું ન હોય.

પરિણામે, મેં ઘણા બધા ઓળખપત્રો મેળવ્યા જે પ્રોજેક્ટના સંદર્ભમાં નકામા હતા, પરંતુ હુમલાના જોખમોના પ્રદર્શન તરીકે ચોક્કસપણે રસપ્રદ હતા. ટેલનેટ સાથે મોટી કંપનીઓના બોર્ડર રાઉટર્સ, બધા ડેટા સાથે આંતરિક CRM સિસ્ટમ્સમાં ડિબગ HTTP પોર્ટ ફોરવર્ડ કર્યા, ડાયરેક્ટ RDP એક્સેસ Windows સ્થાનિક નેટવર્ક પર XP અને અન્ય અસ્પષ્ટતા. તે કંઈક આના જેવું બહાર આવ્યું MITER મેટ્રિક્સ અનુસાર સપ્લાય ચેઇન કોમ્પ્રોમાઇઝ.

મને ટ્રાફિકમાંથી પત્રો એકત્રિત કરવાની એક રમુજી તક પણ મળી, કંઈક આના જેવું. આ એક તૈયાર પત્રનું ઉદાહરણ છે જે અમારા ગ્રાહક પાસેથી તેના ક્લાયન્ટના SMTP પોર્ટ પર ફરીથી એન્ક્રિપ્શન વિના ગયા. ચોક્કસ આન્દ્રે તેના નામના દસ્તાવેજને ફરીથી મોકલવા માટે પૂછે છે, અને તે એક પ્રતિભાવ પત્રમાં લોગિન, પાસવર્ડ અને લિંક સાથે ક્લાઉડ ડિસ્ક પર અપલોડ કરવામાં આવે છે:

બધી સેવાઓને એન્ક્રિપ્ટ કરવા માટે આ બીજું રીમાઇન્ડર છે. તે અજ્ઞાત છે કે કોણ અને ક્યારે તમારો ડેટા ખાસ વાંચશે અને તેનો ઉપયોગ કરશે - પ્રદાતા, અન્ય કંપનીના સિસ્ટમ એડમિનિસ્ટ્રેટર અથવા આવા પેન્ટેસ્ટર. હું એ હકીકત વિશે મૌન છું કે ઘણા લોકો ફક્ત એનક્રિપ્ટેડ ટ્રાફિકને અટકાવી શકે છે.

દેખીતી સફળતા છતાં, આ અમને લક્ષ્યની નજીક લાવી શક્યું નથી. અલબત્ત, લાંબા સમય સુધી બેસીને મૂલ્યવાન માહિતી મેળવવાનું શક્ય હતું, પરંતુ તે હકીકત નથી કે તે ત્યાં દેખાશે, અને હુમલો પોતે જ નેટવર્કની અખંડિતતાના સંદર્ભમાં ખૂબ જોખમી છે.

સેવાઓમાં બીજા ખોદ્યા પછી, એક રસપ્રદ વિચાર મનમાં આવ્યો. રિસ્પોન્ડર નામની આવી ઉપયોગિતા છે (આ નામ દ્વારા ઉપયોગના ઉદાહરણો શોધવાનું સરળ છે), જે "ઝેર" બ્રોડકાસ્ટ વિનંતીઓ દ્વારા, SMB, HTTP, LDAP, વગેરે જેવા વિવિધ પ્રોટોકોલ દ્વારા જોડાણોને ઉશ્કેરે છે. અલગ અલગ રીતે, પછી દરેકને પૂછે છે કે જેઓ પ્રમાણીકરણ સાથે જોડાય છે અને તેને સેટ કરે છે જેથી પ્રમાણીકરણ NTLM દ્વારા થાય છે અને પીડિત માટે પારદર્શક મોડમાં થાય છે. મોટેભાગે, હુમલાખોર આ રીતે NetNTLMv2 હેન્ડશેક એકત્રિત કરે છે અને તેમાંથી, શબ્દકોશનો ઉપયોગ કરીને, ઝડપથી વપરાશકર્તા ડોમેન પાસવર્ડ પુનઃપ્રાપ્ત કરે છે. અહીં મને કંઈક એવું જ જોઈતું હતું, પરંતુ વપરાશકર્તાઓ "દીવાલની પાછળ" બેઠા હતા, અથવા તેના બદલે, તેઓ ફાયરવોલ દ્વારા અલગ થયા હતા, અને બ્લુ કોટ પ્રોક્સી ક્લસ્ટર દ્વારા WEB ને ઍક્સેસ કર્યું હતું.

યાદ છે કે મેં કેવી રીતે સ્પષ્ટ કર્યું હતું કે એક્ટિવ ડિરેક્ટરી ડોમેન નામ "બાહ્ય" ડોમેન, એટલે કે, company.ru જેવું જ છે? સારું, Windows, અથવા વધુ સ્પષ્ટ રીતે કહીએ તો, ઇન્ટરનેટ એક્સપ્લોરર (એજ અને ક્રોમ બંને), વપરાશકર્તાઓને NTLM દ્વારા HTTP ને પારદર્શક રીતે પ્રમાણિત કરવાની મંજૂરી આપે છે જો તેઓ માને છે કે સાઇટ "ઇન્ટ્રાનેટ ઝોન" માં છે. "ઇન્ટ્રાનેટ" ના ચિહ્નોમાંનું એક "ગ્રે" IP સરનામું અથવા ટૂંકા DNS નામ દ્વારા ઍક્સેસ છે, એટલે કે, પીરિયડ્સ વિના. સર્વરમાં "સફેદ" IP અને DNS નામ preobrazhensky.company.ru હોવાથી, અને ડોમેન મશીનો સામાન્ય રીતે સરળ નામ એન્ટ્રી માટે DHCP દ્વારા સક્રિય ડિરેક્ટરી ડોમેન સફિક્સ મેળવે છે, તેમને ફક્ત સરનામાં બારમાં URL લખવાની જરૂર હતી. preobrazhensky, જેથી તેઓ સમાધાન કરેલ યુરોલોજિસ્ટના સર્વરનો સાચો માર્ગ શોધી શકે, તે ભૂલી ન જાય કે આને હવે "ઇન્ટ્રાનેટ" કહેવામાં આવે છે. એટલે કે, તે જ સમયે મને વપરાશકર્તાના NTLM-હેન્ડશેક તેની જાણ વગર આપવો. આ સર્વરનો સંપર્ક કરવાની તાત્કાલિક જરૂરિયાત વિશે વિચારવા માટે ક્લાયંટ બ્રાઉઝર્સને દબાણ કરવાનું બાકી છે.

અદ્ભુત ઇન્ટરસેપ્ટર-એનજી ઉપયોગિતા બચાવમાં આવી (આભાર ઇન્ટરસેપ્ટર). તે ફ્લાય પર ટ્રાફિક બદલવાની મંજૂરી આપે છે અને સંપૂર્ણ રીતે કામ કરે છે Windows ૨૦૦૩. ટ્રાફિક ફ્લોમાં ફક્ત જાવાસ્ક્રિપ્ટ ફાઇલોને સંશોધિત કરવા માટે એક અલગ સુવિધા પણ હતી. એક પ્રકારની માસ ક્રોસ-સાઇટ સ્ક્રિપ્ટીંગનું આયોજન કરવામાં આવ્યું હતું.

બ્લુ કોટ પ્રોક્સીઓ, જેના દ્વારા વપરાશકર્તાઓ વૈશ્વિક WEB ને ઍક્સેસ કરે છે, સમયાંતરે સ્થિર સામગ્રી કેશ કરે છે. ટ્રાફિકને અટકાવીને, તે સ્પષ્ટ હતું કે તેઓ ચોવીસ કલાક કામ કરી રહ્યા હતા, પીક અવર્સ દરમિયાન સામગ્રીના પ્રદર્શનને ઝડપી બનાવવા માટે વારંવાર ઉપયોગમાં લેવાતા સ્ટેટિકની અવિરત વિનંતી કરી રહ્યા હતા. વધુમાં, બ્લુકોટ પાસે ચોક્કસ વપરાશકર્તા-એજન્ટ હતું, જે તેને વાસ્તવિક વપરાશકર્તાથી સ્પષ્ટ રીતે અલગ પાડે છે.

જાવાસ્ક્રિપ્ટ તૈયાર કરવામાં આવી હતી, જે, ઇન્ટરસેપ્ટર-એનજીનો ઉપયોગ કરીને, બ્લુ કોટ માટે JS ફાઇલો સાથેના દરેક પ્રતિભાવ માટે રાત્રે એક કલાક માટે અમલમાં મૂકવામાં આવી હતી. સ્ક્રિપ્ટે નીચે મુજબ કર્યું:

• વપરાશકર્તા-એજન્ટ દ્વારા વર્તમાન બ્રાઉઝર નિર્ધારિત. જો તે ઇન્ટરનેટ એક્સપ્લોરર, એજ અથવા ક્રોમ હતું, તો તે કામ કરવાનું ચાલુ રાખશે.
• પૃષ્ઠનો DOM બને ત્યાં સુધી મેં રાહ જોઈ.
• ફોર્મના src લક્ષણ સાથે DOM માં અદ્રશ્ય છબી શામેલ કરી preobrazhensky:8080/NNNNNN.png, જ્યાં NNN એ મનસ્વી નંબરો છે જેથી બ્લુકોટ તેને કેશ ન કરે.
• ઈન્જેક્શન પૂર્ણ થયું હોવાનું દર્શાવવા માટે વૈશ્વિક ફ્લેગ વેરીએબલ સેટ કરો અને હવે ઈમેજો દાખલ કરવાની કોઈ જરૂર નથી.

બ્રાઉઝે આ ઈમેજ લોડ કરવાનો પ્રયાસ કર્યો; ચેડા થયેલા સર્વરના પોર્ટ 8080 પર, એક TCP ટનલ મારા લેપટોપ પર તેની રાહ જોઈ રહી હતી, જ્યાં તે જ રિસ્પોન્ડર ચાલી રહ્યું હતું, બ્રાઉઝરને NTLM દ્વારા લોગ ઇન કરવાની જરૂર હતી.

પ્રતિસાદકર્તા લોગ દ્વારા અભિપ્રાય આપતા, લોકો સવારે કામ પર આવ્યા, તેમના વર્કસ્ટેશનો ચાલુ કર્યા, પછી એકસાથે અને અજાણ્યા લોકોએ યુરોલોજિસ્ટના સર્વરની મુલાકાત લેવાનું શરૂ કર્યું, NTLM હેન્ડશેક "ડ્રેન" કરવાનું ભૂલ્યા નહીં. આખો દિવસ હેન્ડશેકનો વરસાદ થયો અને પાસવર્ડ પુનઃપ્રાપ્ત કરવા માટે દેખીતી રીતે સફળ હુમલા માટે સામગ્રી સ્પષ્ટપણે એકઠી થઈ. પ્રતિસાદકર્તા લૉગ્સ આના જેવા દેખાતા હતા:

વપરાશકર્તાઓ દ્વારા યુરોલોજિસ્ટ સર્વરની સામૂહિક ગુપ્ત મુલાકાતો

તમે કદાચ પહેલેથી જ નોંધ્યું હશે કે આ આખી વાર્તા સિદ્ધાંત પર બનેલી છે "બધું સારું હતું, પરંતુ પછી ત્યાં એક બમર હતો, પછી ત્યાં એક કાબુ હતો, અને પછી બધું સફળ થયું." તેથી, અહીં એક બમર હતો. પચાસ અનન્ય હેન્ડશેક્સમાંથી, એક પણ જાહેર કરવામાં આવ્યું ન હતું. અને આ એ હકીકતને ધ્યાનમાં લે છે કે ડેડ પ્રોસેસરવાળા લેપટોપ પર પણ, આ NTLMv2 હેન્ડશેક પ્રતિ સેકન્ડમાં કેટલાક સો મિલિયન પ્રયાસોની ઝડપે પ્રક્રિયા કરવામાં આવે છે.

મારે મારી જાતને પાસવર્ડ મ્યુટેશન ટેકનિક, વિડીયો કાર્ડ, એક ગાઢ શબ્દકોશ અને રાહ જોવી પડી. લાંબા સમય પછી, "Q11111111....1111111q" ફોર્મના પાસવર્ડ્સ સાથેના કેટલાક એકાઉન્ટ્સ જાહેર થયા, જે સૂચવે છે કે બધા વપરાશકર્તાઓને એક સમયે અક્ષરોના વિવિધ કેસ સાથે ખૂબ લાંબો પાસવર્ડ સાથે આવવાની ફરજ પડી હતી, જે પણ માનવામાં આવતું હતું. જટિલ બનો. પરંતુ તમે અનુભવી વપરાશકર્તાને મૂર્ખ બનાવી શકતા નથી, અને આ રીતે તેણે પોતાને યાદ રાખવાનું સરળ બનાવ્યું. કુલ મળીને, લગભગ 5 એકાઉન્ટ્સ સાથે ચેડાં કરવામાં આવ્યાં હતાં, અને તેમાંથી માત્ર એક પાસે જ સેવાઓના કોઈપણ મૂલ્યવાન અધિકારો હતા.

ભાગ 3. Roskomnadzor પાછા પ્રહારો

તેથી, પ્રથમ ડોમેન એકાઉન્ટ્સ પ્રાપ્ત થયા હતા. જો તમે લાંબા સમય સુધી વાંચીને આ બિંદુએ ઊંઘી ન ગયા હો, તો તમને કદાચ યાદ હશે કે મેં એવી સેવાનો ઉલ્લેખ કર્યો છે જેને પ્રમાણીકરણના બીજા પરિબળની જરૂર નથી: તે NTLM પ્રમાણીકરણ સાથેનું વિકિ છે. અલબત્ત, પ્રથમ વસ્તુ ત્યાં દાખલ થઈ. આંતરિક જ્ઞાન આધારમાં ખોદવાથી ઝડપથી પરિણામો આવ્યા:

• કંપની પાસે સ્થાનિક નેટવર્કની ઍક્સેસ સાથે ડોમેન એકાઉન્ટ્સનો ઉપયોગ કરીને પ્રમાણીકરણ સાથેનું WiFi નેટવર્ક છે. ડેટાના વર્તમાન સેટ સાથે, આ પહેલેથી જ કાર્યકારી હુમલો વેક્ટર છે, પરંતુ તમારે તમારા પગ સાથે ઑફિસમાં જવું પડશે અને ગ્રાહકની ઑફિસના પ્રદેશ પર ક્યાંક સ્થિત હોવું જોઈએ.
• મને એક સૂચના મળી જે મુજબ એક સેવા હતી જે... સ્વતંત્ર રીતે "બીજા પરિબળ" પ્રમાણીકરણ ઉપકરણની નોંધણી કરવાની મંજૂરી આપે છે જો વપરાશકર્તા સ્થાનિક નેટવર્કની અંદર હોય અને વિશ્વાસપૂર્વક તેનું ડોમેન લોગિન અને પાસવર્ડ યાદ રાખે. આ કિસ્સામાં, "અંદર" અને "બહાર" વપરાશકર્તા માટે આ સેવાના પોર્ટની સુલભતા દ્વારા નિર્ધારિત કરવામાં આવ્યા હતા. પોર્ટ ઈન્ટરનેટથી સુલભ ન હતું, પરંતુ DMZ દ્વારા તદ્દન સુલભ હતું.

અલબત્ત, મારા ફોન પર એપ્લિકેશનના રૂપમાં ચેડા થયેલા ખાતામાં તરત જ "બીજો પરિબળ" ઉમેરવામાં આવ્યો હતો. ત્યાં એક પ્રોગ્રામ હતો જે કાં તો ક્રિયા માટે "મંજૂર"/"અસ્વીકાર" બટનો સાથે ફોન પર પુશ વિનંતી મોકલી શકે છે અથવા વધુ સ્વતંત્ર પ્રવેશ માટે સ્ક્રીન પર શાંતિપૂર્વક OTP કોડ બતાવી શકે છે. તદુપરાંત, સૂચનાઓ દ્વારા પ્રથમ પદ્ધતિ એકમાત્ર સાચી હોવાનું માનવામાં આવતું હતું, પરંતુ તે OTP પદ્ધતિથી વિપરીત કામ કરતું ન હતું.

"બીજા પરિબળ" તૂટવા સાથે, હું સિટ્રિક્સ નેટસ્કેલર ગેટવેમાં આઉટલુક વેબ એક્સેસ મેઇલ અને રિમોટ એક્સેસને ઍક્સેસ કરવામાં સક્ષમ હતો. આઉટલુકમાં મેઇલમાં એક આશ્ચર્યજનક હતું:

આ દુર્લભ શોટમાં તમે જોઈ શકો છો કે રોસ્કોમનાડઝોર પેન્ટેસ્ટરને કેવી રીતે મદદ કરે છે

ટેલિગ્રામના પ્રખ્યાત "ચાહક" અવરોધિત થયા પછીના આ પ્રથમ મહિનાઓ હતા, જ્યારે હજારો સરનામાંઓ સાથેના સમગ્ર નેટવર્ક્સ ઍક્સેસમાંથી અદૃશ્યપણે અદૃશ્ય થઈ ગયા હતા. તે સ્પષ્ટ થઈ ગયું કે શા માટે દબાણ તરત જ કામ કરતું નથી અને શા માટે મારી "પીડિત" એ એલાર્મ નથી વગાડ્યું કારણ કે તેઓએ ખુલ્લા કલાકો દરમિયાન તેના એકાઉન્ટનો ઉપયોગ કરવાનું શરૂ કર્યું.

Citrix Netscaler સાથે પરિચિત કોઈપણ કલ્પના કરે છે કે તે સામાન્ય રીતે એવી રીતે લાગુ કરવામાં આવે છે કે માત્ર એક ચિત્ર ઈન્ટરફેસ વપરાશકર્તાને પહોંચાડી શકાય, તેને તૃતીય-પક્ષ એપ્લિકેશનો શરૂ કરવા અને ડેટા ટ્રાન્સફર કરવા માટેના સાધનો ન આપવાનો પ્રયાસ કરે છે, દરેક સંભવિત રીતે ક્રિયાઓને મર્યાદિત કરે છે. પ્રમાણભૂત નિયંત્રણ શેલો દ્વારા. મારા "પીડિત", તેના વ્યવસાયને કારણે, માત્ર 1C મેળવ્યો:

1C ઇન્ટરફેસની આસપાસ થોડું ચાલ્યા પછી, મને જાણવા મળ્યું કે ત્યાં બાહ્ય પ્રોસેસિંગ મોડ્યુલો છે. તેઓ ઈન્ટરફેસમાંથી લોડ થઈ શકે છે, અને તેઓ અધિકારો અને સેટિંગ્સના આધારે ક્લાયંટ અથવા સર્વર પર ચલાવવામાં આવશે.

મેં મારા 1C પ્રોગ્રામર મિત્રોને એક પ્રોસેસિંગ બનાવવા માટે કહ્યું જે સ્ટ્રિંગને સ્વીકારે અને તેને એક્ઝિક્યુટ કરે. 1C ભાષામાં, પ્રક્રિયા શરૂ કરવી કંઈક આના જેવી લાગે છે (ઈન્ટરનેટ પરથી લેવામાં આવી છે). શું તમે સંમત થાઓ છો કે 1C ભાષાનું વાક્યરચના રશિયન બોલતા લોકોને તેની સ્વયંસ્ફુરિતતાથી આશ્ચર્યચકિત કરે છે?

પ્રક્રિયા સંપૂર્ણ રીતે ચલાવવામાં આવી હતી; તે બહાર આવ્યું કે પેન્ટેસ્ટર જેને "શેલ" કહે છે - ઇન્ટરનેટ એક્સપ્લોરર તેના દ્વારા શરૂ કરવામાં આવ્યું હતું.

અગાઉ, એક સિસ્ટમનું સરનામું જે તમને પ્રદેશમાં પાસ ઓર્ડર કરવાની મંજૂરી આપે છે તે મેલમાં મળી આવ્યું હતું. જો મારે WiFi એટેક વેક્ટરનો ઉપયોગ કરવો હોય તો મેં પાસનો ઓર્ડર આપ્યો.

ઇન્ટરનેટ પર એવી ચર્ચા છે કે ગ્રાહકની ઑફિસમાં હજી પણ સ્વાદિષ્ટ મફત કેટરિંગ હતું, પરંતુ મેં હજી પણ એટેકને દૂરથી વિકસાવવાનું પસંદ કર્યું, તે વધુ શાંત છે.

AppLocker Citrix ચલાવતા એપ્લિકેશન સર્વર પર સક્રિય કરવામાં આવ્યું હતું, પરંતુ તે બાયપાસ કરવામાં આવ્યું હતું. સમાન મીટરપ્રીટર લોડ કરવામાં આવ્યું હતું અને DNS મારફત લોન્ચ કરવામાં આવ્યું હતું, કારણ કે http(s) સંસ્કરણો કનેક્ટ થવા માંગતા ન હતા, અને મને તે સમયે આંતરિક પ્રોક્સી સરનામું ખબર ન હતી. માર્ગ દ્વારા, આ ક્ષણથી, બાહ્ય પેન્ટેસ્ટ આવશ્યકપણે સંપૂર્ણપણે આંતરિકમાં ફેરવાઈ ગયું.

ભાગ 4. વપરાશકર્તાઓ માટે એડમિન અધિકારો ખરાબ છે, ઠીક છે?

ડોમેન વપરાશકર્તા સત્ર પર નિયંત્રણ મેળવતી વખતે પેન્ટેસ્ટરનું પ્રથમ કાર્ય ડોમેનમાં અધિકારો વિશેની તમામ માહિતી એકત્રિત કરવાનું છે. બ્લડહાઉન્ડ યુટિલિટી છે જે તમને ડોમેન કંટ્રોલરમાંથી LDAP પ્રોટોકોલ દ્વારા વપરાશકર્તાઓ, કમ્પ્યુટર્સ, સુરક્ષા જૂથો વિશેની માહિતી અને SMB દ્વારા આપમેળે ડાઉનલોડ કરવાની મંજૂરી આપે છે - તાજેતરમાં કયા વપરાશકર્તાએ ક્યાં અને કોણ સ્થાનિક એડમિનિસ્ટ્રેટર છે તે વિશેની માહિતી.

ડોમેન એડમિનિસ્ટ્રેટર અધિકારો જપ્ત કરવા માટેની એક લાક્ષણિક તકનીક એકવિધ ક્રિયાઓના ચક્ર તરીકે સરળ લાગે છે:

• અમે ડોમેન કોમ્પ્યુટર પર જઈએ છીએ જ્યાં પહેલાથી જ કેપ્ચર કરેલા ડોમેન એકાઉન્ટ્સના આધારે સ્થાનિક એડમિનિસ્ટ્રેટર અધિકારો હોય છે.
• અમે Mimikatz ચલાવીએ છીએ અને તાજેતરમાં આ સિસ્ટમમાં લોગ ઇન થયેલા ડોમેન એકાઉન્ટ્સના કેશ્ડ પાસવર્ડ્સ, Kerberos ટિકિટો અને NTLM હેશ મેળવીએ છીએ. વૈકલ્પિક રીતે, અમે lsass.exe પ્રક્રિયાની મેમરી છબી લઈએ છીએ અને અમારી બાજુએ પણ તે જ કરીએ છીએ. આ સારી રીતે કાર્ય કરે છે Windows 2012R2 કરતાં નાની ઉંમર/Windows ૮.૧ ડિફોલ્ટ સેટિંગ્સ સાથે.
• અમે નક્કી કરીએ છીએ કે ચેડાં થયેલા એકાઉન્ટમાં સ્થાનિક વ્યવસ્થાપક અધિકારો ક્યાં છે. અમે પ્રથમ બિંદુ પુનરાવર્તન. અમુક તબક્કે અમે સમગ્ર ડોમેન માટે એડમિનિસ્ટ્રેટર અધિકારો મેળવીએ છીએ.

"સાયકલનો અંત;", જેમ કે 1C પ્રોગ્રામરો અહીં લખશે.

તો, અમારો વપરાશકર્તા ફક્ત એક જ હોસ્ટ પર સ્થાનિક એડમિનિસ્ટ્રેટર બન્યો જેમાં Windows 7, જેના નામમાં "VDI" અથવા "વર્ચ્યુઅલ ડેસ્કટોપ ઇન્ફ્રાસ્ટ્રક્ચર" શબ્દ હતો - વ્યક્તિગત વર્ચ્યુઅલ મશીનો. VDI સર્વિસ ડિઝાઇનરનો કદાચ હેતુ હતો કે VDI એ વપરાશકર્તાની વ્યક્તિગત ઓપરેટિંગ સિસ્ટમ હોવાથી, તેઓ સોફ્ટવેર વાતાવરણને તેમની ઇચ્છા મુજબ બદલી શકે છે, જ્યાં સુધી હોસ્ટ હજુ પણ "રીલોડ" થઈ શકે છે. મને પણ લાગ્યું કે તે એક સારો વિચાર છે, તેથી મેં આ વ્યક્તિગત VDI હોસ્ટમાં લૉગ ઇન કર્યું અને ત્યાં મારું પોતાનું માળખું બનાવ્યું:

• તેને ત્યાં સ્થાપિત કર્યું OpenVPN- એક ક્લાયન્ટ જેણે મારા સર્વર સુધી ઇન્ટરનેટ દ્વારા એક ટનલ બનાવી. ક્લાયન્ટને તે જ બ્લુ કોટ ડોમેન પ્રમાણીકરણમાંથી પસાર થવું પડ્યું, પરંતુ OpenVPN મેં તે મેનેજ કર્યું, જેમ તેઓ કહે છે, "આઉટ ઓફ ધ બોક્સ".
• મેં VDI પર OpenSSH ઇન્સ્ટોલ કર્યું છે. ખરેખર, આ શું છે? Windows 7 SSH વગર?

આ તે લાઇવ જેવું લાગતું હતું. ચાલો હું તમને યાદ કરાવું કે આ બધું Citrix અને 1C દ્વારા થવું જોઈએ:

પડોશી કમ્પ્યુટર્સની ઍક્સેસને પ્રોત્સાહન આપવા માટેની એક તકનીક એ છે કે મેચ માટે સ્થાનિક એડમિનિસ્ટ્રેટર પાસવર્ડ્સ તપાસો. અહીં નસીબ તરત જ રાહ જોઈ રહ્યું હતું: ડિફોલ્ટ સ્થાનિક એડમિનિસ્ટ્રેટર (જેને અચાનક એડમિનિસ્ટ્રેટર કહેવામાં આવતું હતું) ના NTLM હેશનો નજીકના VDI યજમાનોને પાસ-ધ-હેશ હુમલા દ્વારા સંપર્ક કરવામાં આવ્યો હતો, જેમાંથી ઘણા સો હતા. અલબત્ત, હુમલો તરત જ તેમને થયો.

આ તે છે જ્યાં VDI સંચાલકોએ પોતાને પગમાં બે વાર ગોળી મારી હતી:

• પ્રથમ વખત જ્યારે VDI મશીનોને LAPS હેઠળ લાવવામાં આવ્યા ન હતા, આવશ્યકપણે તે જ સ્થાનિક એડમિનિસ્ટ્રેટર પાસવર્ડને ઇમેજમાંથી જાળવી રાખતા હતા જે VDI પર મોટા પાયે તૈનાત કરવામાં આવ્યા હતા.
• ડિફોલ્ટ એડમિનિસ્ટ્રેટર એ એકમાત્ર સ્થાનિક એકાઉન્ટ છે જે પાસ-ધ-હેશ હુમલાઓ માટે સંવેદનશીલ છે. સમાન પાસવર્ડ સાથે પણ, જટિલ રેન્ડમ પાસવર્ડ સાથે બીજું લોકલ એડમિનિસ્ટ્રેટર એકાઉન્ટ બનાવીને અને ડિફોલ્ટને બ્લોક કરીને સામૂહિક સમાધાન ટાળવું શક્ય બનશે.

તેના પર SSH સેવા શા માટે છે? Windowsતે ખૂબ જ સરળ છે: હવે OpenSSH સર્વર વપરાશકર્તાના કાર્યમાં ખલેલ પહોંચાડ્યા વિના માત્ર એક અનુકૂળ ઇન્ટરેક્ટિવ કમાન્ડ શેલ જ નહીં, પણ VDI પર socks5 પ્રોક્સી પણ પ્રદાન કરે છે. આ socks દ્વારા, મેં SMB દ્વારા કનેક્ટ કર્યું અને તે બધા સેંકડો VDI મશીનોમાંથી કેશ્ડ ઓળખપત્રો એકત્રિત કર્યા, પછી ડોમેન એડમિનિસ્ટ્રેટરનો પાથ શોધવા માટે બ્લડહાઉન્ડ ગ્રાફ શોધ્યા. મારી પાસે સેંકડો હોસ્ટ હોવાથી, મને આવો પાથ ખૂબ જ ઝડપથી મળી ગયો. ડોમેન એડમિનિસ્ટ્રેટર અધિકારો મેળવવામાં આવ્યા.

અહીં ઈન્ટરનેટ પરથી એક ચિત્ર છે જે સમાન શોધ દર્શાવે છે. કનેક્શન્સ બતાવે છે કે એડમિનિસ્ટ્રેટર કોણ છે અને કોણ ક્યાંથી લૉગ ઇન છે.

માર્ગ દ્વારા, પ્રોજેક્ટની શરૂઆતથી શરત યાદ રાખો - "સોશિયલ એન્જિનિયરિંગનો ઉપયોગ કરશો નહીં." તેથી, જો મામૂલી ફિશિંગનો ઉપયોગ કરવો હજી પણ શક્ય હોત તો સ્પેશિયલ ઇફેક્ટ્સ સાથેનું આ બૉલીવુડ કેટલું કપાઈ જશે તે વિશે હું વિચારવાનો પ્રસ્તાવ મૂકું છું. પરંતુ વ્યક્તિગત રીતે, મારા માટે આ બધું કરવું ખૂબ જ રસપ્રદ હતું. હું આશા રાખું છું કે તમે આ વાંચીને આનંદ માણ્યો હશે. અલબત્ત, દરેક પ્રોજેક્ટ એટલો રસપ્રદ લાગતો નથી, પરંતુ એકંદરે કામ ખૂબ જ પડકારજનક છે અને તેને સ્થિર થવા દેતું નથી.

કોઈને આશ્ચર્ય થશે કે: હું મારી જાતને કેવી રીતે સુરક્ષિત રાખી શકું? આ લેખમાં પણ ઘણી તકનીકોનું વર્ણન કરવામાં આવ્યું છે, જેમાંથી ઘણી તકનીકો સંચાલકો દ્વારા આવરી લેવામાં આવી છે. Windows તેમને ખબર પણ નથી. જોકે, હું તેમને માહિતી સુરક્ષાના જાણીતા સિદ્ધાંતો અને માપદંડોના દ્રષ્ટિકોણથી જોવાનું સૂચન કરું છું:

• જૂના સોફ્ટવેરનો ઉપયોગ કરશો નહીં (યાદ રાખો) Windows 2003 શરૂઆતમાં?)
• બિનજરૂરી સિસ્ટમ ચાલુ ન રાખો (યુરોલોજિસ્ટની વેબસાઇટ શા માટે હતી?)
• જાતે શક્તિ માટે વપરાશકર્તા પાસવર્ડ તપાસો (નહીંતર સૈનિકો... પેન્ટેસ્ટર આ કરશે)
• જુદા જુદા એકાઉન્ટ્સ માટે સમાન પાસવર્ડ્સ નથી (VDI સમાધાન)
• અને અન્ય

અલબત્ત, આનો અમલ કરવો ખૂબ જ મુશ્કેલ છે, પરંતુ હવે પછીના લેખમાં આપણે વ્યવહારમાં બતાવીશું કે તે તદ્દન શક્ય છે.

સોર્સ: www.habr.com