DeepSeek Harness એ HTTP Host header ને માત્ર 127.0.0.1 માં બદલીને એક sandboxed attacker ને arbitrary commands ચલાવવાની મંજૂરી આપી દીધી, જે CVSS સ્કેલ પર 9.4 સ્કોર કરે છે. આ ખામી દર્શાવે છે કે કેવી રીતે વિશ્વાસનો એક ખોટો નિર્ણય સુરક્ષા સીમાને ખુલ્લા backdoor માં ફેરવી શકે છે.

આ બગ કેવી રીતે અંદર આવ્યો

આ vulnerable કોડ એક સિંગલ ફંક્શનમાં છે જે રિક્વેસ્ટના Host header ને વાંચે છે અને જો તેની કિંમત loopback address જેટલી હોય, તો તે રિક્વેસ્ટને લોકલ મશીન પરથી આવી હોય તેમ માની લે છે.

જે attacker sandbox ની અંદર કોડ એક્ઝિક્યુટ કરી શકે છે તેને કોઈ જટિલ payload ની જરૂર નથી. Host: 127.0.0.1 સાથે એક HTTP રિક્વેસ્ટ મોકલીને, backend એવું માની લે છે કે આ કોલ પોતે host પરથી જ આવ્યો છે અને તે તમામ security prompts, rate-limit ચેક્સ અને command-validation સ્ટેપ્સને સ્કીપ કરી દે છે. પરિણામ: કોઈપણ વધારાની ક્રિયા વગર unrestricted command execution.

હેડર્સ પર વિશ્વાસ કરવો શા માટે જોખમી છે

Headers એ કોલર દ્વારા આપવામાં આવતી plain-text સ્ટ્રિંગ્સ છે. ભલે તે ફિલ્ડનું નામ Host, X-Forwarded-For, અથવા કોઈપણ કસ્ટમ નામ હોય, ક્લાયન્ટ તેને તેની ઈચ્છા મુજબ કોઈપણ કિંમતમાં સેટ કરી શકે છે. કનેક્શન ખરેખર ક્યાંથી આવ્યું છે તે જાણવા માટેનો એકમાત્ર વિશ્વસનીય સ્ત્રોત transport layer છે – એટલે કે સોકેટનું source IP એડ્રેસ, જે ઓપરેટિંગ સિસ્ટમ TCP handshake પૂર્ણ થાય ત્યારે રેકોર્ડ કરે છે.

જ્યારે કોઈ એપ્લિકેશન એ વાતની ખાતરી કર્યા વગર કે કોઈ જાણીતા અને યોગ્ય રીતે કોન્ફિગર કરેલા proxy દ્વારા તે ઇન્જેક્ટ કરવામાં આવ્યું છે, ત્યારે હેડર પર વિશ્વાસ કરવાનું નક્કી કરે છે, ત્યારે તે attacker ને આખા સિસ્ટમની ચાવીઓ સોંપી દે છે. DeepSeek Harness બગ આ ભૂલનું એક ઉત્તમ ઉદાહરણ છે.

વાસ્તવિક દુનિયા પર અસર: shell.online નું ઉદાહરણ

ઓપન-સોર્સ shell.online પ્રોજેક્ટ, જે વેબ-આધારિત ટર્મિનલ ઓફર કરે છે, તેણે તાજેતરમાં આવી જ ખામી નોંધાવી છે. તે TRUST_PROXY નામના કોન્ફિગરેશન ફ્લેગનો ઉપયોગ કરે છે:

  • TRUST_PROXY = 0 – એપ્લિકેશન X-Forwarded-For હેડરને અવગણે છે અને સોકેટના remote address પર આધાર રાખે છે. આ ક્લાયન્ટને rate limits થી બચવા માટે અથવા વિશ્વાસુ યુઝર તરીકે દેખાવા માટે IP એડ્રેસ બનાવતા (forge કરતા) અટકાવે છે.
  • TRUST_PROXY = 1 – એપ્લિકેશન ક્લાયન્ટની ઓળખ તરીકે X-Forwarded-For હેડર પર વિશ્વાસ કરે છે. જો સર્વિસ કોઈ એવા વાસ્તવિક proxy પાછળ ન હોય જે આ હેડરને sanitize કરે, તો attacker દરેક રિક્વેસ્ટ પર નવું IP એડ્રેસ આપી શકે છે, જે અસરકારક રીતે કોઈપણ per-IP throttling ને રીસેટ કરી દે છે.

DeepSeek બગ આ જ પરિસ્થિતિનું પ્રતિબિંબ પાડે છે: કોડ એવું માની લે છે કે proxy એ Host સેટ કર્યું છે, છતાં સર્વિસને સીધી રીતે એક્સેસ કરી શકાતી હતી.

ડેવલપર્સને હવે શું કરવાની જરૂર છે

  1. તમે ક્લાયન્ટ દ્વારા આપવામાં આવેલા હેડર્સ વાંચતા હોવ તે દરેક જગ્યાનું ઓડિટ કરો. ઓળખો કે તમે કયા હેડર્સને authoritative માનો છો (દા.ત., Host, X-Forwarded-For, X-Real-IP) અને ખાતરી કરો કે તમારી એપ્લિકેશન સુધી પહોંચતા પહેલા કોઈ વિશ્વાસુ proxy તેને rewrite કરે તેની ખાતરી કરો.
  2. શક્ય હોય ત્યાં સુધી security નિર્ણયોને socket address સાથે જોડો. ઓથેન્ટિકેશન, rate-limiting અને access-control ચેક્સ માટે OS દ્વારા આપવામાં આવેલ source IP નો ઉપયોગ કરો.
  3. proxy-trust ફ્લેગ્સ ત્યારે જ સક્ષમ કરો જ્યારે સર્વિસની આગળ યોગ્ય રીતે કોન્ફિગર કરેલ reverse proxy હોય. જો તમે એપ્લિકેશન સીધી ચલાવતા હોવ, તો તે ફ્લેગ્સ ડિસેબલ રાખો.
  4. તમારા પ્રોજેક્ટના README અથવા deployment guide માં જરૂરી deployment topology નું દસ્તાવેજીકરણ કરો, જેથી જે યુઝર્સ સેલ્ફ-હોસ્ટ કરે છે તેઓ proxy-trust ની જરૂરિયાત વિશે જાણી શકે.
  5. static-analysis અથવા code-review ટૂલ્સ ચલાવો જે proxy-validation લોજિક વગર સુરક્ષા નિર્ણયો માટે હેડર્સના સીધા ઉપયોગને ફ્લેગ કરે.

આગળ શું ધ્યાન રાખવું

સેલ્ફ-હોસ્ટેડ વેબ સર્વિસિસ પૂરી પાડતા કોમ્યુનિટીઝ આ ઘટના પછી તેમની પોતાની proxy-trust સેટિંગ્સની ફરીથી તપાસ કરી શકે છે.

મુખ્ય પાઠ સ્પષ્ટ છે: ઇન્ટરનેટ પર કોઈપણ વ્યક્તિ લખી શકે તેવા ટેક્સ્ટના ટુકડાને તમારા સિસ્ટમની સુરક્ષા નક્કી કરવા ન દો. નેટવર્ક લેયર પર વિશ્વાસ કરો, રિક્વેસ્ટ લેયર પર નહીં.