DeepSeek Harness లోని లోపం వల్ల, ఒక sandboxed అటాకర్ HTTP Host header ని 127.0.0.1 గా మార్చడం ద్వారా ఏవైనా ఆదేశాలను (arbitrary commands) అమలు చేయగలుగుతున్నారు. దీని CVSS స్కేల్ స్కోరు 9.4. ఒక చిన్న తప్పుడు నిర్ణయం, రక్షణ కవచాన్ని ఎలా ఒక తెరిచిన బ్యాక్డోర్గా (backdoor) మారుస్తుందో ఈ లోపం చూపిస్తుంది.
ఈ బగ్ ఎలా చోటు చేసుకుంది
అసలు లోపం ఉన్న కోడ్ ఒకే ఒక ఫంక్షన్లో ఉంది. ఇది రిక్వెస్ట్ యొక్క Host header ని చదువుతుంది మరియు ఒకవేళ ఆ విలువ loopback address కి సమానమైతే, ఆ రిక్వెస్ట్ లోకల్ మెషీన్ నుండి వస్తున్నట్లుగా పరిగణిస్తుంది.
సాండ్బాక్స్ లోపల కోడ్ను అమలు చేయగల అటాకర్కు క్లిష్టమైన payload అవసరం లేదు. Host: 127.0.0.1 తో ఒక HTTP రిక్వెస్ట్ను పంపడం ద్వారా, బ్యాకెండ్ ఆ కాల్ స్వయంగా హోస్ట్ నుండి వస్తుందని నమ్ముతుంది మరియు అన్ని security prompts, rate-limit తనిఖీలు మరియు command-validation దశలను దాటవేస్తుంది. ఫలితం: ఎటువంటి అదనపు ఇంటరాక్షన్ లేకుండానే అపరిమితమైన కమాండ్ ఎగ్జిక్యూషన్ సాధ్యమవుతుంది.
హెడర్లను నమ్మడం ఎందుకు ప్రమాదకరం
హెడర్లు అనేవి కాల్ చేసే వ్యక్తి (caller) అందించే ప్లెయిన్-టెక్స్ట్ స్ట్రింగ్స్. ఆ ఫీల్డ్ పేరు Host, X-Forwarded-For లేదా ఏదైనా కస్టమ్ పేరు అయినా, క్లయింట్ తనకు నచ్చిన విలువను సెట్ చేయవచ్చు. ఒక కనెక్షన్ నిజంగా ఎక్కడి నుండి వచ్చిందో తెలుసుకోవడానికి ఉన్న ఏకైక నమ్మదగిన మూలం transport layer మాత్రమే – అంటే TCP handshake పూర్తయినప్పుడు ఆపరేటింగ్ సిస్టమ్ రికార్డ్ చేసే socket యొక్క source IP address.
ఒక అప్లికేషన్, ఒక తెలిసిన మరియు సరిగ్గా కాన్ఫిగర్ చేయబడిన proxy ద్వారా అది పంపబడిందని నిర్ధారించుకోకుండా హెడర్ను నమ్మాలని నిర్ణయించుకున్నప్పుడు, అది అటాకర్కు వ్యవస్థ యొక్క తాళాలు అందిస్తున్నట్లే. DeepSeek Harness లోని ఈ లోపం ఇటువంటి తప్పుకు ఒక పాఠ్యపుస్తక ఉదాహరణ.
వాస్తవ ప్రపంచ ప్రభావం: shell.online ఉదాహరణ
వెబ్ ఆధారిత టెర్మినల్ను అందించే ఓపెన్-సోర్స్ shell.online ప్రాజెక్ట్, ఇటీవల ఇదే రకమైన లోపాన్ని డాక్యుమెంట్ చేసింది. ఇది TRUST_PROXY అనే కాన్ఫిగరేషన్ ఫ్లాగ్ను ఉపయోగిస్తుంది:
- TRUST_PROXY = 0 – అప్లికేషన్ X-Forwarded-For హెడర్ను విస్మరించి, socket యొక్క remote address పై ఆధారపడుతుంది. ఇది క్లయింట్ రేట్ లిమిట్లను తప్పించుకోవడానికి లేదా నమ్మదగిన యూజర్గా నటిస్తూ IP అడ్రస్ను సృష్టించకుండా నిరోధిస్తుంది.
- TRUST_PROXY = 1 – అప్లికేషన్ X-Forwarded-For హెడర్ను క్లయింట్ యొక్క గుర్తింపుగా నమ్ముతుంది. ఒకవేళ ఈ హెడర్ను క్లీన్ చేసే (sanitise) అసలైన proxy వెనుక ఈ సర్వీస్ లేకపోతే, అటాకర్ ప్రతి రిక్వెస్ట్కు కొత్త IP అడ్రస్ను పంపవచ్చు, తద్వారా per-IP throttling ని సులభంగా రీసెట్ చేయవచ్చు.
DeepSeek లోని లోపం కూడా ఇదే పరిస్థితిని ప్రతిబింబిస్తుంది: కోడ్ ఒక proxy సెట్ చేసినట్లుగా Host ను నమ్మింది, కానీ సర్వీస్ను నేరుగా యాక్సెస్ చేయవచ్చు.
డెవలపర్లు ఇప్పుడు ఏమి చేయాలి
- క్లయింట్ అందించే హెడర్లను మీరు చదివే ప్రతి చోట ఆడిట్ చేయండి. మీరు ఏ హెడర్లను అధికారికమైనవిగా (ఉదాహరణకు: Host, X-Forwarded-For, X-Real-IP) పరిగణిస్తున్నారో గుర్తించండి మరియు అవి మీ అప్లికేషన్కు చేరుకోకముందే ఒక నమ్మదగిన proxy వాటిని మారుస్తుందని (rewrite) నిర్ధారించుకోండి.
- వీలైనప్పుడల్లా సెక్యూరిటీ నిర్ణయాలను socket address తో అనుసంధానించండి. అథెంటికేషన్, రేట్-లిమిటింగ్ మరియు యాక్సెస్-కంట్రోల్ తనిఖీల కోసం OS అందించే source IPని ఉపయోగించండి.
- సర్వీస్ ముందు సరిగ్గా కాన్ఫిగర్ చేయబడిన reverse proxy ఉన్నప్పుడు మాత్రమే proxy-trust ఫ్లాగ్లను ఎనేబుల్ చేయండి. మీరు అప్లికేషన్ను నేరుగా రన్ చేస్తున్నట్లయితే, ఆ ఫ్లాగ్లను డిసేబుల్ చేయండి.
- మీ ప్రాజెక్ట్ యొక్క README లేదా డిప్లాయ్మెంట్ గైడ్లో అవసరమైన deployment topologyని డాక్యుమెంట్ చేయండి, తద్వారా సెల్ఫ్-హోస్ట్ చేసే వినియోగదారులకు proxy-trust అవసరత గురించి తెలుస్తుంది.
- స్టాటిక్-అనాలిసిస్ లేదా కోడ్-రివ్యూ టూల్స్ను ఉపయోగించండి, ఇవి proxy-validation లాజిక్ లేకుండా సెక్యూరిటీ నిర్ణయాల కోసం హెడర్లను నేరుగా ఉపయోగించడాన్ని గుర్తించగలవు.
తదుపరి ఏమి గమనించాలి
ఈ సంఘటన తర్వాత, సెల్ఫ్-హోస్ట్డ్ వెబ్ సర్వీసులను అందించే కమ్యూనిటీలు తమ స్వంత proxy-trust సెట్టింగ్లను మళ్ళీ సమీక్షించే అవకాశం ఉంది.
దీని నుండి నేర్చుకోవాల్సిన ప్రధాన పాఠం స్పష్టంగా ఉంది: ఇంటర్నెట్లో ఎవరైనా వ్రాయగల ఒక టెక్స్ట్ ముక్క మీ సిస్టమ్ యొక్క సెక్యూరిటీని నిర్ణయించనివ్వకండి. రిక్వెస్ట్ లేయర్ను కాకుండా, నెట్వర్క్ లేయర్ను నమ్మండి.