GTFOBins

• Unix बाइनरी सूची को कार्यों के अनुसार व्यवस्थित किया गया है, और हर बाइनरी में संभव क्रियाओं को विस्तृत पेज और anchor links से सीधे जोड़ा गया है
• बार-बार दिखने वाली श्रेणियाँ हैं Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load, Privilege escalation और कुछ आइटम में Bind shell भी शामिल है
• File read और Shell बहुत व्यापक रूप से फैले हुए हैं, और dd·sed·sqlite3 जैसे टूल पढ़ने और लिखने दोनों को साथ रखते हैं, जिससे साधारण read-only टूल्स के साथ उनकी सीमा धुंधली हो जाती है
• apt·git·journalctl·systemctl जैसे टूल्स में अक्सर Command और Inherit शामिल होते हैं, और bee·pipx·sqlmap·vim परिवार जैसे network transfer और shell operations दोनों रखने वाले multifunction binaries भी बार-बार दिखाई देते हैं
• Privilege escalation अलग लिंक वाले कुछ बाइनरी तक सीमित दिखाई देता है, जबकि 7z से zypper तक फैली विस्तृत सूची सामान्य टूल्स के व्यवहारिक संयोजनों के फर्क को एक नज़र में दिखाती है

---

प्रमुख फीचर वितरण

• फ़ाइल पढ़ने वाले केवल या पढ़ने-केंद्रित आइटम बहुत व्यापक रूप से फैले हुए हैं
  • 7z, cat, grep, jq, od, tail, wc, zcat आदि File read केंद्रित रूप से जुड़े हैं
• Shell चलाने वाले आइटम भी बहुत अधिक हैं
  • bash, awk, find, less, python, ruby, tar, vi, zsh आदि में Shell मौजूद है
• फ़ाइल लिखने और पढ़ने दोनों वाले आइटम बहुत हैं, जिससे साधारण read-only टूल्स के साथ इनकी सीमा धुंधली हो जाती है
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd आदि इसमें आते हैं
• Command execution या privilege inheritance पैकेज मैनेजर, सिस्टम टूल्स और interactive programs में अक्सर दिखाई देते हैं
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless इसके प्रमुख उदाहरण हैं

multifunction binaries

• कई क्रियाएँ एक साथ रखने वाले multifunction binaries बार-बार सामने आते हैं

• Inherit आधारित multifunction आइटम

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve में Inherit के साथ Shell, Command, File read, File write जुड़े हुए हैं

• network और file transfer तक शामिल करने वाले आइटम

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility में Reverse shell, Upload, Download, Library load भी साथ मौजूद हैं

• editor और debugger परिवार

  • gdb, nvim, rvim, view, vim, vimdiff में Inherit के साथ Shell, Reverse shell, Bind shell या File read/write, Upload, Download, Library load को जोड़ा गया है

• package managers और runtime परिवार

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum में अक्सर shell, file access और network operations साथ जुड़े होते हैं

network, shell, library load

• Upload/Download फीचर सिर्फ network tools में नहीं, बल्कि shell और language runtimes में भी जुड़े हुए हैं

• transfer-केंद्रित टूल्स

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois में Upload या Download मौजूद है

• Reverse shell और Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh आदि इसमें शामिल हैं

• Library load वाले आइटम

  • bash, byebug, curl, ffmpeg, gdb, gem, gimp, irb, knife, ldconfig, mysql, nginx, nvim, openssl, pip, python, rake, ruby, ssh-keygen, tclsh, vim, volatility, wish, yum आदि इसमें शामिल हैं

privilege escalation आइटम

• Privilege escalation केवल उन बाइनरी में दिखाई देता है जिनमें यह अलग आइटम के रूप में जोड़ा गया है

• privilege escalation links सूची

  • chattr
  • chmod
  • chown
  • cp
  • getent
  • install
  • ln
  • mount
  • mv
  • passwd
  • setcap
  • setfacl
  • unsquashfs
  • unzip

[GN⁺]

Hacker News की राय

• लगता है कि टिप्पणियों में लोग थोड़ा भ्रमित हैं, इसलिए security/CTF context में यह कब इस्तेमाल होता है, उसका एक उदाहरण ऐसा है
  restricted shell या ऐसे environment में जहाँ सिर्फ कुछ commands/binaries ही चल सकती हैं, आम तौर पर arguments काफी आज़ादी से दिए जा सकते हैं
  ऐसे में GTFOBins का इस्तेमाल करके file read/write या command execution तक पहुँचा जा सकता है, और उस restricted context से निकलकर shell हासिल की जा सकती है
  अगर किसी ने sudo खुला छोड़ दिया हो या किसी GTFOBin पर SUID bit लगा दिया हो, तो उस व्यक्ति की जानकारी के बिना भी sensitive files पढ़ी या लिखी जा सकती हैं और privileged commands चलाई जा सकती हैं

  • यह बात claude-code जैसे tools पर भी काफी लागू होती है
    इसकी permission handling block-list और allow-list केंद्रित है, इसलिए काफी primitive है
    एक session में मैंने गलती से Claude को powershell permission दे दी थी, और उसके बाद जब git जैसे tools block हुए, तो वह वही काम करने वाली powershell scripts लिखकर blocked permissions को bypass करते हुए उन्हें चलाने लगा
    किसी सामान्य system में powershell को सामान्य allow-list में नहीं रखा जाएगा, लेकिन अगर tool-specific permission levels में gaps हों, तो लगता है इस पेज की techniques से काफी कुछ किया जा सकता है
  • कुछ enterprise security software, जो privilege escalation mediation करने का दावा करते हैं, वे भी इसी तरह risky हो सकते हैं
    एक कंपनी में मैंने ऐसा deployment देखा था जहाँ admin की allowlist में मौजूद programs को बिना password के sudo से चलाया जा सकता था, और शुरुआत से ही उसमें vim, bash जैसे general-purpose tools शामिल थे
    remote work करने वाले की नज़र से यह उल्टा राहत जैसा लगा, क्योंकि मेरे computer को "protect" करने वाला यह software, अगर मैं थोड़ी देर के लिए उठ जाऊँ और screen lock करना भूल जाऊँ, तो किसी के लिए आकर कुछ चलाना कहीं आसान बना देता था
  • आखिरकार यह इस बात की काफी व्यापक guide जैसा लगता है कि restricted shell वास्तव में कितनी आसानी से bypass हो सकती है
  • एक ठोस example भी है
    कुछ साल पहले support team को tcpdump से network capture करना था, इसलिए जल्दी काम निपटाने के लिए एक sudo rule बनाया गया जिसमें arguments को कुछ हद तक खुला छोड़ दिया गया
    ports या NIC बदल सकते थे, इसलिए उस समय यह स्वाभाविक लगा, लेकिन असल में tcpdump के -z option से compression command निर्दिष्ट की जा सकती है, और वहाँ कोई "विशेष" command डाल दी जाए तो server पर पूरा control लिया जा सकता है
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    देखने में मामूली लगता है, लेकिन ऐसी चीज़ें सच में आसानी से छूट जाती हैं
    आजकल apparmor जैसी layers इस risk को कम कर सकती हैं, लेकिन उतनी ही दूसरी परेशानियाँ भी लाती हैं और फिर भी misconfiguration आसान रहता है
  • यह देखते हुए ऐसा भी लगता है जैसे AI को sandbox escape methods सिखाने के लिए व्यवस्थित की गई सूची हो

• आख़िरी बार मैंने ऐसा कुछ 1995 के आसपास Windows 3.11 वाले एक मिडिल स्कूल के computer पर इस्तेमाल किया था
  वहाँ सिर्फ कुछ approved apps ही चलने दिए गए थे, और उनमें से एक Word था
  Word में macros का इस्तेमाल करके shell से दूसरी apps चलाई जा सकती थीं
  इसलिए वह locked computer, जिस पर बस कुछ apps दिखती थीं, असल में लगभग कुछ भी चलाने लायक बन गया था
  उस समय यह काफी रोमांचक लगा था, और उसके बाद मैंने ऐसा बहुत कम देखा
  कभी-कभी दुकानों या malls की touch information displays में kiosk mode escape की बात सुनने को मिलती है, वह भी शायद इसी तरह की चीज़ है

• restic - Shell, Command, Upload देखकर लगता है कि backup को root के रूप में न चलाने के लिए जो बदलाव किया गया, वह कुछ हद तक सही था
  उसकी जगह उसे सामान्य user के रूप में चलाया गया, सिर्फ read-all-files capability दी गई और login shell हटा दी गई
  बेशक desktop पर यह ज़रूरत से ज़्यादा हो सकता है, और अगर attacker वहाँ तक पहुँच गया है तो वैसे भी लगभग सारी files पढ़ सकता है और backups में backdoor भी डाल सकता है
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • constraints देखकर ऐसा लगता है कि LLM की यह प्रवृत्ति — "तो फिर किसी bypass helper का इस्तेमाल करके घूमकर काम कर लो" — पुराने दौर की कई धारणाओं को तोड़ रही है
    remote human attackers, remote bot attackers, और कुछ हद तक local human attackers तक के लिए तो बचाव के तरीके हैं, लेकिन ऐसे local bot attackers जो खुद code लिखते हैं, वे अब पहले से कहीं ज्यादा गंभीर चिंता का विषय बन गए हैं
    यह malware के बिल्कुल वही category भी नहीं है
    मैंने भी कभी containers को एक relevant boundary मानकर अंदर की सारी processes को root के रूप में चलाया है, लेकिन LLM के आने के बाद समझ नहीं आता कि OS-level security अचानक ज्यादा महत्वपूर्ण हो गई है, या उल्टा लगभग बेमानी

• थोड़ा भ्रम है, क्या इसका मतलब यह है कि जब cat न हो तो cat /path/to/input-file की जगह base64 /path/to/input-file | base64 --decode इस्तेमाल करना चाहिए?
  या फिर base64 /path/to/input-file | base64 --decode file read permission को ही bypass कर देता है?

  • पहला वाला मतलब सही है
    called process आम तौर पर उसे चलाने वाले user की वही permissions inherit करता है, और अपवाद सिर्फ तब होता है जब setuid bit हो
    बात यह है कि standard Unix tools हटाकर attacker की lateral movement रोकने की कोशिश करने वाले environments में, वही काम दूसरे tools से भी किया जा सकता है
  • मतलब यह कि blacklist-based command restrictions से permissions रोकने का तरीका पहले भी ठीक से काम नहीं करता था और आज भी नहीं करता
  • दूसरा नहीं, पहला है
    यह permissions तोड़ने की बात नहीं, बल्कि ऐसे restricted shell की बात है जहाँ सिर्फ कुछ commands allowed हों, और उसी परिणाम तक किसी दूसरी binary से पहुँचा जाए
    CTF में यह सच में बहुत आम है
  • लेकिन अगर कोई file सामान्य रूप से पढ़ी नहीं जा सकती, और बदले में root के रूप में base64 चलाना संभव हो, तो बात बदल जाती है
    root permissions के साथ base64 चलाकर file contents को base64 में encode किया जा सकता है, और फिर उस output को किसी दूसरे base64 process से decode करके आखिरकार file contents देखी जा सकती हैं
    नतीजे में यह बस कुछ अतिरिक्त steps वाला cat ही है
  • अगर ऐसा है, तो tar pipe शायद और हल्का विकल्प होगा

• मैं पहले ऐसे एक tool का maintainer था, और किसी को उससे shell हासिल करते देखना मज़ेदार था
  रचनात्मक भी है, दिलचस्प भी, और reference material के रूप में भी अच्छा है

• hackthebox.eu करते समय मैंने इसका बहुत ज़्यादा इस्तेमाल किया था

• GTFOBins काफी समय से मौजूद है, और AI से पहले भी उपयोगी reference था

  • इसलिए आगे की चिंता और बढ़ जाती है
    AI उपयोगी होने का एक कारण यही है कि वह पहले से मौजूद ऐसे materials को ऊपर खींचकर सामने ला सकता है

• सूची में base64 देखकर बात पूरी तरह समझ नहीं आती
  मेरे हिसाब से वह सिर्फ उन्हीं files को पढ़ सकता है जिन तक user की पहले से पहुँच है; क्या मैं कुछ गलत समझ रहा हूँ?
  या misconfigured systems की local security restrictions bypass वाली व्याख्या का मतलब कुछ और है?

  • मुख्य बात यह है कि गलत तरीके से configured restricted shells या command-only access वाले setups में भी, उस सूची के tools की मदद से user उस access का कुछ हिस्सा वापस पा सकता है जो उसे मूल non-restricted environment में मिला होता
    सबसे आसान उदाहरण यह है कि अगर default shell को rbash कर दिया गया हो, लेकिन user बस bash चलाकर सामान्य shell में जा सके, तो फिर उस restriction का कोई मतलब नहीं रह जाता
  • उदाहरण के लिए sudoers शायद base64 को root के रूप में चलाने की अनुमति देता हो
    क्यों, यह पता नहीं, लेकिन ऐसी स्थिति में intended permission restrictions bypass हो सकती हैं और system की कोई भी file पढ़ी जा सकती है
    या अगर Claude Code में base64 चलाने की अनुमति बिना review के दे दी जाए, तो वह .env जैसी secret files तक पढ़ने का रास्ता खोल सकता है
  • आम स्थिति यह होती है कि कुछ tools root permissions के साथ चलाए जा सकते हैं
    कभी sudo -l में स्पष्ट रूप से अनुमति होती है, या कोई दूसरी चीज़ उस tool को root के रूप में invoke कर रही होती है

• अच्छा होता अगर ऐसे bypasses के लिए mitigations भी साथ में दिखाए जाते
  जैसे अगर more से shell हासिल की जा सकती है, तो
  more चलाने से पहले SHELL को /bin/false पर सेट करना
  secure mode वाले less पर स्विच करना
  sudo से more इस्तेमाल हो रहा हो तो NOEXEC flag लगाना, वगैरह

  • सबसे अच्छा mitigation यह है कि जिन files को user को पढ़ना या लिखना नहीं चाहिए, उनकी वास्तविक permissions सही तरह से सेट की जाएँ
    बाकी तरीके आखिरकार कुछ हद तक किस्मत पर निर्भर रहते हैं

• काफी शानदार है, और कुछ जगहों पर अप्रत्याशित रूप से रचनात्मक approaches भी दिखती हैं
  जैसे yt-dlp वाला तो मैंने सोचा भी नहीं था
  अब उसे बस यूँ ही install करके रखने पर फिर से सोचना पड़ेगा