એક નવો અભિગમ LLM-સંચાલિત પેન્ટસ્ટ એજન્ટને માત્ર બ્રીચનો દાવો કરવાને બદલે તેને સાબિત કરવા માટે મજબૂર કરે છે, જેમાં ચૅલેન્જ-રિસ્પોન્સ નોન્સ (challenge-response nonces) નો ઉપયોગ કરીને ખોટા પોઝિટિવ્સ (false positives) દૂર કરવામાં આવે છે. HALO ફ્રેમવર્કમાં પ્રદર્શિત આ તકનીક, “એવું લાગે છે કે આપણને શેલ મળી ગયો છે” ને “આપણી પાસે ખરેખર શેલ છે” માં બદલી નાખે છે.

ખોટા પોઝિટિવ બ્રીચ્સ શા માટે મહત્વના છે

લાર્જ લેંગ્વેજ મોડલ્સ પર આધારિત ઓટોમેટેડ એક્સપ્લોઇટેશન એન્જિન એક જ રનમાં ડઝનબંધ “સફળ” પોર્ટ કોમ્પ્રોમાઇઝ કરી શકે છે. ઘણી સેવાઓ બૅનર્સમાં “uid=0” જેવા સ્ટ્રિંગ્સ દર્શાવે છે, અને એક તૈયાર કરેલ ટાર્ગેટ હુમલાખોરના કોડને એક્ઝિક્યુટ કર્યા વગર જ તે આઉટપુટની નકલ કરી શકે છે. જ્યારે એજન્ટ તે આઉટપુટ પર વિશ્વાસ કરે છે, ત્યારે પછીનો દરેક નિર્ણય—પિવટ કરવો હોય, ડેટા એક્સફિલ્ટરેટ કરવો હોય, અથવા લેટરલી મૂવ કરવું હોય—એ એક જૂઠ પર આધારિત હોય છે. સુરક્ષા ટીમો કાલ્પનિક Footholds પાછળ કલાકો બગાડે છે, અને ઇન્સિડન્ટ રિસ્પોન્ડર્સ વાસ્તવિક જોખમોને ખોટી રીતે પ્રાથમિકતા આપી શકે છે.

દાવાને પુરાવામાં બદલવો

આ ઉકેલ ક્લાસિક ઓથેન્ટિકેશન ટ્રિક્સમાંથી લેવામાં આવ્યો છે. એક્સપ્લોઇટ શરૂ કરતા પહેલા, હુમલાખોરની સિસ્ટમ એક યુનિક ટોકન અથવા નોન્સ (nonce) જનરેટ કરે છે અને તેને પેલોડમાં એમ્બેડ કરે છે. કંટ્રોલર પરિણામને વાસ્તવિક બ્રીચ તરીકે સ્વીકારે તે માટે એક્સપ્લોઇટે ચોક્કસ ટોકન પરત કરવું આવશ્યક છે. એક નકલી બૅનર નોન્સનો અંદાજ લગાવી શકતું નથી; પ્રતિસાદમાં ટોકન એમ્બેડ કરવા માટે તેણે હુમલાખોરના કોડને એક્ઝિક્યુટ કરવો જ પડશે. જો પરત કરેલા ડેટામાં મેચિંગ નોન્સ ન હોય, તો તે પ્રયાસને ખોટા પોઝિટિવ તરીકે રદ કરવામાં આવે છે.

આ ફેરફાર વેરિફિકેશન મોડેલને “આઉટપુટ સાચું લાગે છે” થી બદલીને “આઉટપુટ એક્ઝિક્યુશન સાબિત કરે છે” માં ફેરવે છે. તે સ્વાયત્ત ઓફન્સ ટૂલ્સમાં જોવા મળતા ઓપ્ટિમીઝમ બાયસને દૂર કરે છે.

વિશ્વસનીય ડિલિવરી લેડર બનાવવો

પેલોડને ટાર્ગેટ સુધી પહોંચાડવા માટે હજુ પણ મજબૂત ડિલિવરી ચેઇનની જરૂર છે. HALO ત્રણ સામાન્ય માર્ગોનું વર્ગીકરણ કરે છે:

  • Reverse shells – કોમ્પ્રોમાઇઝ થયેલ હોસ્ટ હુમલાખોરના નિયંત્રણ હેઠળના લિસનર સાથે કનેક્શન શરૂ કરે છે. જ્યારે ઇનબાઉન્ડ ટ્રાફિક બ્લોક હોય ત્યારે તે ઉપયોગી છે.
  • Bind shells – હુમલાખોર સીધા ટાર્ગેટ પરની લિસનિંગ સર્વિસ સાથે કનેક્ટ થાય છે. જ્યારે આઉટબાઉન્ડ ફિલ્ટર્સ ઢીલા હોય ત્યારે તે કામ કરે છે.
  • Blind callbacks – એકતરફી સિગ્નલ (દા.ત., DNS રિક્વેસ્ટ) જે અત્યંત પ્રતિબંધિત વાતાવરણમાં એક્ઝિક્યુશનની પુષ્ટિ કરે છે જ્યાં કોઈ સીધું ચેનલ ખોલી શકાતું નથી.

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

સેલ્ફ-કન્ટેઈન્ડ એક્સપ્લોઇટ્સની ખાતરી કરવી

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

ડેવલપમેન્ટ ટ્રેલ સાફ કરવો

પબ્લિક રિલીઝ માટે તૈયારી કરતી વખતે, લેખકે Git હિસ્ટ્રીમાં વાસ્તવિક IP એડ્રેસ જોવા મળ્યા હતા. ક્લીન વર્કિંગ ટ્રી તે રેકોર્ડ્સને ભૂંસી શકતું નથી; Git દરેક કમીટને સાચવી રાખે છે. લેખકે રિપોઝિટરીને સિંગલ ક્લીન કમીટમાં ફરીથી લખી અને લીક થયેલા એડ્રેસને RFC 5737 દ્વારા વ્યાખ્યાયિત ડોક્યુમેન્ટેશન-ઓન્લી રેન્જ (દા.ત., 192.0.2.0/24) સાથે બદલી નાખ્યા. આનાથી જ્યારે ટૂલ શેર કરવામાં આવે ત્યારે પ્રોડક્શન ઇન્ફ્રાસ્ટ્રક્ચરના અકસ્માતે એક્સપોઝરને અટકાવવામાં આવે છે.

સિક્યુરિટી ટૂલિંગ માટે વ્યવહારુ નિયમો

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

પુરાવો આશાવાદ કરતાં વધુ શક્તિશાળી છે. એક સ્વાયત્ત પેન્ટસ્ટ એજન્ટને વેરિફાઇએબલ ટોકન રજૂ કરવા માટે મજબૂર કરીને, HALO બતાવે છે કે બ્રીચ ત્યારે જ બ્રીચ છે જ્યારે ટાર્ગેટ સાબિત કરી શકે કે તેણે હુમલાખોરનો કોડ ચલાવ્યો છે. પહેલા દરવાજો બનાવવામાં આવે છે; બાકી બધું પછી આવે છે.