ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ ਇੱਕ LLM-driven pentest agent ਨੂੰ ਸਿਰਫ਼ ਦਾਅਵਾ ਕਰਨ ਦੀ ਬਜਾਏ ਉਲੰਘਣਾ (breach) ਨੂੰ ਸਾਬਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ challenge-response nonces ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ false positives ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ। HALO framework ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਇਹ ਤਕਨੀਕੀ ਤਰੀਕਾ “looks like we got a shell” ਨੂੰ “we actually have a shell” ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਗਲਤ-ਪੋਜ਼ੀਟਿਵ (false-positive) ਉਲੰਘਣਾਵਾਂ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹਨ

Large language models 'ਤੇ ਬਣੇ ਆਟੋਮੇਟਿਡ ਐਕਸਪਲੋਇਟੇਸ਼ਨ ਇੰਜਣ ਇੱਕੋ ਵਾਰ ਚਲਾਉਣ 'ਤੇ ਦਰਜਨਾਂ "ਸਫਲ" ਪੋਰਟ ਕੰਪ੍ਰੋਮਾਈਜ਼ (port compromises) ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਕਈ ਸੇਵਾਵਾਂ ਬੈਨਰਾਂ ਵਿੱਚ “uid=0” ਵਰਗੇ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਟਾਰਗੇਟ ਅਟੈਕਰ ਦੇ ਕੋਡ ਨੂੰ ਚਲਾਏ ਬਿਨਾਂ ਹੀ ਉਹਨਾਂ ਆਉਟਪੁੱਟ ਦੀ ਨਕਲ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ agent ਉਹਨਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਹਰ ਅਗਲਾ ਫੈਸਲਾ—ਚਾਹੇ ਉਹ pivot ਕਰਨਾ ਹੋਵੇ, ਡਾਟਾ exfiltrate ਕਰਨਾ ਹੋਵੇ, ਜਾਂ laterally ਵਧਣਾ ਹੋਵੇ—ਇੱਕ ਝੂਠ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਟੀਮਾਂ ਕਲਪਨਾਤਮਕ footholds ਦੇ ਪਿੱਛੇ ਘੰਟਿਆਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ incident responders ਅਸਲ ਖਤਰਿਆਂ ਨੂੰ ਗਲਤ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹਨ।

ਇੱਕ ਦਾਅਵੇ ਨੂੰ ਸਬੂਤ ਵਿੱਚ ਬਦਲਣਾ

ਇਹ ਹੱਲ ਕਲਾਸਿਕ ਅਥੈਂਟੀਕੇਸ਼ਨ ਤਰੀਕਿਆਂ ਤੋਂ ਪ੍ਰੇਰਿਤ ਹੈ। ਇੱਕ exploit ਲਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਟੈਕਰ ਦਾ ਸਿਸਟਮ ਇੱਕ ਵਿਲੱਖਣ ਟੋਕਨ, ਜਾਂ nonce, ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ payload ਵਿੱਚ ਸ਼ਾਮਲ ਕਰ ਦਿੰਦਾ ਹੈ। ਕੰਟਰੋਲਰ ਦੁਆਰਾ ਨਤੀਜੇ ਨੂੰ ਅਸਲ ਉਲੰਘਣਾ ਵਜੋਂ ਸਵੀਕਾਰ ਕਰਨ ਲਈ exploit ਨੂੰ ਸਹੀ ਟੋਕਨ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਫੇਕ ਬੈਨਰ nonce ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ; ਇਸਨੂੰ ਰਿਸਪਾਂਸ ਵਿੱਚ ਟੋਕਨ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਅਟੈਕਰ ਦੇ ਕੋਡ ਨੂੰ ਚਲਾਉਣਾ ਹੀ ਪਵੇਗਾ। ਜੇਕਰ ਵਾਪਸ ਕੀਤੇ ਗਏ ਡਾਟਾ ਵਿੱਚ ਮੇਲ ਖਾਂਦਾ nonce ਨਹੀਂ ਹੈ, ਤਾਂ ਉਸ ਕੋਸ਼ਿਸ਼ ਨੂੰ false positive ਮੰਨ ਕੇ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਤਬਦੀਲੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਮਾਡਲ ਨੂੰ “the output looks right” ਤੋਂ ਬਦਲ ਕੇ “the output proves execution” ਕਰ ਦਿੰਦੀ ਹੈ। ਇਹ ਉਸ optimism bias ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ ਜੋ ਆਟੋਨੋਮਸ ਅਫੈਂਸ ਟੂਲਜ਼ (autonomous offense tools) ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਇੱਕ ਭਰੋਸੇਯੋਗ ਡਿਲੀਵਰੀ ਲੈਂਡਰ (delivery ladder) ਬਣਾਉਣਾ

Payload ਨੂੰ ਟਾਰਗੇਟ ਤੱਕ ਪਹੁੰਚਾਉਣ ਲਈ ਅਜੇ ਵੀ ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਲੀਵਰੀ ਚੇਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। HALO ਤਿੰਨ ਆਮ ਰਸਤਿਆਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦਾ ਹੈ:

  • Reverse shells – ਕੰਪ੍ਰੋਮਾਈਜ਼ ਹੋਇਆ ਹੋਸਟ ਅਟੈਕਰ ਦੁਆਰਾ ਕੰਟਰੋਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ listener ਨੂੰ ਵਾਪਸ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਇਹ ਉਦੋਂ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ inbound traffic ਰੋਕਿਆ ਹੋਵੇ।
  • Bind shells – ਅਟੈਕਰ ਸਿੱਧਾ ਟਾਰਗੇਟ 'ਤੇ ਇੱਕ listening service ਨਾਲ ਜੁੜਦਾ ਹੈ। ਇਹ ਉਦੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ outbound filters ਢਿੱਲੇ ਹੋਣ।
  • Blind callbacks – ਇੱਕ ਇੱਕ-ਤਰਫਾ ਸਿਗਨਲ (ਜਿਵੇਂ ਕਿ DNS request) ਜੋ ਬਹੁਤ ਹੀ ਸੀਮਤ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ execution ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਸਿੱਧਾ ਚੈਨਲ ਨਹੀਂ ਖੋਲ੍ਹਿਆ ਜਾ ਸਕਦਾ।

ਲੈਂਡਰ ਦੇ ਹਰ ਕਦਮ ਵਿੱਚ nonce ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ proof step ਅੱਗੇ ਫੇਲ ਹੋ ਜਾਵੇਗਾ।

ਸੈਲਫ-ਕੰਟੇਂਡ (self-contained) exploits ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ

ਗਲਤ ਭਰੋਸੇ ਦਾ ਇੱਕ ਹੋਰ ਸਰੋਤ ਬਾਹਰੀ ਲਾਇਬ੍ਰੇਰੀਆਂ 'ਤੇ ਨਿਰਭਰਤਾ ਹੈ ਜੋ ਟਾਰਗੇਟ 'ਤੇ ਗਾਇਬ ਹੋ ਸਕਦੀਆਂ ਹਨ। HALO ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਲੋੜੀਂਦੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਫਾਈਲ ਵਿੱਚ ਬੰਨ들 (bundle) ਕਰ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਇਸ ਬੰਡਲ ਦਾ ਟੈਸਟ ਇੱਕ sandbox ਵਿੱਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ ਅਸਲ dependencies ਨਹੀਂ ਹੁੰਦੀਆਂ। ਜੇਕਰ exploit ਅਜੇ ਵੀ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਉਹ artifact ਸੱਚਮੁੱਚ self-contained ਹੈ ਅਤੇ ਇੱਕ locked-down ਸਿਸਟਮ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਡਿਵੈਲਪਮੈਂਟ ਟ੍ਰੇਲ (development trail) ਨੂੰ ਸਾਫ਼ ਕਰਨਾ

ਜਨਤਕ ਰਿਲੀਜ਼ ਦੀ ਤਿਆਰੀ ਕਰਦੇ ਸਮੇਂ, ਲੇਖਕ ਨੇ Git history ਵਿੱਚ ਅਸਲ IP ਐਡਰੈੱਸ ਪਾਏ। ਇੱਕ ਸਾਫ਼ working tree ਉਹਨਾਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਨਹੀਂ ਮਿਟਾਉਂਦੀ; Git ਹਰ commit ਨੂੰ ਰੱਖਦਾ ਹੈ। ਲੇਖਕ ਨੇ repository ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸਾਫ਼ commit ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ ਅਤੇ ਲੀਕ ਹੋਏ ਐਡਰੈੱਸਾਂ ਨੂੰ RFC 5737 ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ documentation-only ਰੇਂਜਾਂ (ਉਦਾਹਰਨ ਲਈ, 192.0.2.0/24) ਨਾਲ ਬਦਲ ਦਿੱਤਾ। ਇਹ ਟੂਲ ਸਾਂਝਾ ਕਰਨ ਵੇਲੇ production infrastructure ਦੇ ਅਚਾਨਕ ਪ੍ਰਗਟ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਟੂਲਿੰਗ (security tooling) ਲਈ ਵਿਵਹਾਰਕ ਨਿਯਮ

  • ਹਰ test fixture ਵਿੱਚ documentation-only IP ਰੇਂਜਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
  • ਸ਼ੁਰੂਆਤੀ commit ਤੋਂ secrets ਅਤੇ scope ਫਾਈਲਾਂ ਨੂੰ ਹਟਾ ਦਿਓ।
  • ਕਿਸੇ ਵੀ ਦਾਅਵਾ ਕੀਤੇ ਗਏ breach ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ challenge-response nonces ਲਾਗੂ ਕਰੋ।
  • ਉਸ ਸਹੀ ਫਾਈਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜੋ ਭੇਜੀ ਜਾਵੇਗੀ, ਨਾ ਕਿ ਕਿਸੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਕ੍ਰਿਪਟ ਦੀ।

ਸਬੂਤ ਉਤਸ਼ਾਹ (optimism) ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। ਇੱਕ ਆਟੋਨੋਮਸ pentest agent ਨੂੰ ਇੱਕ ਵੈਰੀਫਿਏਬਲ ਟੋਕਨ ਪੇਸ਼ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਕੇ, HALO ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਲੰਘਣਾ (breach) ਉਦੋਂ ਹੀ ਉਲੰਘਣਾ ਹੈ ਜਦੋਂ ਟਾਰਗੇਟ ਇਹ ਸਾਬਤ ਕਰ ਸਕੇ ਕਿ ਉਸਨੇ ਅਟੈਕਰ ਦਾ ਕੋਡ ਚਲਾਇਆ ਹੈ। ਪਹਿਲਾਂ ਗੇਟ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ; ਬਾਕੀ ਸਭ ਕੁਝ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਂਦਾ ਹੈ।