DeepSeek Harness-ൽ ഒരു സാൻഡ്‌ബോക്സിലുള്ള അറ്റാക്കർക്ക് HTTP Host ഹെഡർ 127.0.0.1 എന്ന് മാറ്റുന്നതിലൂടെ ഏത് കമാൻഡും പ്രവർത്തിപ്പിക്കാൻ സാധിക്കും. ഇതിന് CVSS സ്കെയിലിൽ 9.4 ആണ് ലഭിച്ചിരിക്കുന്നത്. ഒരു തെറ്റായ വിശ്വാസം എങ്ങനെ ഒരു സുരക്ഷാ അതിർവരമ്പുകളെ തുറന്ന ബാക്ക്‌ഡോർ ആക്കി മാറ്റുന്നു എന്നതിന്റെ ഉദാഹരണമാണിത്.

ഈ ബഗ് എങ്ങനെ സംഭവിച്ചു

ദുർബലമായ കോഡ് ഒരു ഫംഗ്ഷനിലാണ് ഉള്ളത്. ഇത് റിക്വസ്റ്റിലെ Host ഹെഡർ വായിക്കുകയും, അതിന്റെ മൂല്യം ലൂപ്പ്‌ബാക്ക് അഡ്രസ് (loopback address) ആണെങ്കിൽ, റിക്വസ്റ്റ് ലോക്കൽ മെഷീനിൽ നിന്നാണെന്ന് കണക്കാക്കുകയും ചെയ്യുന്നു.

സാൻഡ്‌ബോക്സിനുള്ളിൽ കോഡ് പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന ഒരു അറ്റാക്കർക്ക് സങ്കീർണ്ണമായ പേലോഡുകൾ ആവശ്യമില്ല. Host: 127.0.0.1 എന്നൊരു HTTP റിക്വസ്റ്റ് അയക്കുന്നതിലൂടെ, ബാക്കെൻഡ് ഈ കോൾ ഹോസ്റ്റിൽ നിന്ന് തന്നെ വന്നതാണെന്ന് വിശ്വസിക്കുകയും എല്ലാ സുരക്ഷാ പ്രോംപ്റ്റുകളും (security prompts), റേറ്റ്-ലിമിറ്റ് പരിശോധനകളും, കമാൻഡ്-വാലിഡേഷൻ ഘട്ടങ്ങളും ഒഴിവാക്കുകയും ചെയ്യുന്നു. ഫലം: കൂടുതൽ ഇടപെടലുകൾ ആവശ്യമില്ലാതെ നിയന്ത്രണരഹിതമായ കമാൻഡ് എക്സിക്യൂഷൻ.

ഹെഡറുകളെ വിശ്വസിക്കുന്നത് എന്തുകൊണ്ട് അപകടകരമാണ്

ഹെഡറുകൾ എന്നത് കോളർ നൽകുന്ന പ്ലെയിൻ-ടെക്സ്റ്റ് സ്ട്രിംഗുകളാണ്. ഫീൽഡിന്റെ പേര് Host, X-Forwarded-For, അല്ലെങ്കിൽ മറ്റേതെങ്കിലും പേരായാലും, ക്ലയന്റിന് ഇഷ്ടമുള്ള മൂല്യം നൽകാൻ കഴിയും. ഒരു കണക്ഷൻ യഥാർത്ഥത്തിൽ എവിടെ നിന്ന് വന്നുവെന്നതിനെക്കുറിച്ചുള്ള ഏക വിശ്വസനീയമായ ഉറവിടം ട്രാൻസ്‌പോർട്ട് ലെയർ (transport layer) ആണ് - അതായത് TCP ഹാൻഡ്‌ഷേക്ക് പൂർത്തിയാകുമ്പോൾ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം രേഖപ്പെടുത്തുന്ന സോക്കറ്റിന്റെ സോഴ്‌സ് ഐപി അഡ്രസ്.

ഒരു പ്രോക്സി ഇത് നൽകിയതാണെന്ന് ഉറപ്പുവരുത്താതെ ഒരു ആപ്ലിക്കേഷൻ ഹെഡറുകളെ വിശ്വസിക്കാൻ തീരുമാനിച്ചാൽ, അത് അറ്റാക്കർക്ക് സിസ്റ്റത്തിന്റെ നിയന്ത്രണം കൈമാറുന്നതിന് തുല്യമാണ്. DeepSeek Harness ബഗ് ഇതിന് ഒരു മികച്ച ഉദാഹരണമാണ്.

യഥാർത്ഥ ലോകത്തെ പ്രത്യാഘാതം: shell.online ഉദാഹരണം

വെബ് അധിഷ്ഠിത ടെർമിനൽ നൽകുന്ന ഓപ്പൺ സോഴ്‌സ് shell.online പ്രോജക്റ്റ് അടുത്തിടെ ഇതേ പ്രശ്നം രേഖപ്പെടുത്തിയിട്ടുണ്ട്. ഇത് TRUST_PROXY എന്നൊരു കോൺഫിഗറേഷൻ ഫ്ലാഗ് ഉപയോഗിക്കുന്നു:

  • TRUST_PROXY = 0 – ആപ്ലിക്കേഷൻ X-Forwarded-For ഹെഡർ അവഗണിക്കുകയും സോക്കറ്റിന്റെ റിമോട്ട് അഡ്രസ് ഉപയോഗിക്കുകയും ചെയ്യുന്നു. ഇത് റേറ്റ് ലിമിറ്റുകളിൽ നിന്ന് രക്ഷപ്പെടാനോ വിശ്വസനീയമായ ഒരു ഉപയോക്താവായി വേഷം മാറാനോ വേണ്ടി ഐപി അഡ്രസ് വ്യാജമായി നിർമ്മിക്കുന്നത് തടയുന്നു.
  • TRUST_PROXY = 1 – ആപ്ലിക്കേഷൻ X-Forwarded-For ഹെഡറിനെ ക്ലയന്റിന്റെ ഐഡന്റിറ്റിയായി വിശ്വസിക്കുന്നു. ഈ ഹെഡർ ശുദ്ധീകരിക്കുന്ന (sanitise) ഒരു പ്രോക്സി സർവീസിന് പിന്നിലല്ലെങ്കിൽ, ഓരോ റിക്വസ്റ്റിലും അറ്റാക്കർക്ക് പുതിയ ഐപി അഡ്രസ് നൽകാൻ കഴിയും, ഇത് ഐപി അടിസ്ഥാനമാക്കിയുള്ള നിയന്ത്രണങ്ങളെ (throttling) ഇല്ലാതാക്കുന്നു.

DeepSeek ബഗ് ഈ സാഹചര്യത്തെപ്പോലെയാണ്: ഒരു പ്രോക്സി ഇത് സെറ്റ് ചെയ്തതാണെന്ന് കരുതി കോഡ് Host ഹെഡറിനെ വിശ്വസിച്ചു, എന്നാൽ സർവീസിലേക്ക് നേരിട്ട് പ്രവേശിക്കാൻ സാധിക്കുമായിരുന്നു.

ഡെവലപ്പർമാർ ഇപ്പോൾ എന്തുചെയ്യണം

  1. ക്ലയന്റ് നൽകുന്ന ഹെഡറുകൾ വായിക്കുന്ന എല്ലാ ഇടങ്ങളും പരിശോധിക്കുക (Audit). ഏതെല്ലാം ഹെഡറുകളാണ് നിങ്ങൾ വിശ്വസനീയമായി കണക്കാക്കുന്നത് (ഉദാഹരണത്തിന് Host, X-Forwarded-For, X-Real-IP) എന്ന് തിരിച്ചറിയുക, അവ നിങ്ങളുടെ ആപ്ലിക്കേഷനിൽ എത്തുന്നതിന് മുമ്പ് ഒരു വിശ്വസനീയമായ പ്രോക്സി അവ മാറ്റുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
  2. സാധ്യമാകുമ്പോഴെല്ലാം സുരക്ഷാ തീരുമാനങ്ങളെ സോക്കറ്റ് അഡ്രസുമായി ബന്ധിപ്പിക്കുക. ഓതന്റിക്കേഷൻ, റേറ്റ്-ലിമിറ്റിംഗ്, ആക്സസ്-കൺട്രോൾ പരിശോധനകൾ എന്നിവയ്ക്കായി OS നൽകുന്ന സോഴ്‌സ് ഐപി ഉപയോഗിക്കുക.
  3. സർവീസിന് മുന്നിൽ ശരിയായി കോൺഫിഗർ ചെയ്ത ഒരു റിവേഴ്സ് പ്രോക്സി ഉണ്ടെങ്കിൽ മാത്രം പ്രോക്സി-ട്രസ്റ്റ് ഫ്ലാഗുകൾ പ്രവർത്തനക്ഷമമാക്കുക. നിങ്ങൾ ആപ്ലിക്കേഷൻ നേരിട്ടാണ് പ്രവർത്തിപ്പിക്കുന്നതെങ്കിൽ, ഈ ഫ്ലാഗുകൾ ഡിസേബിൾ ആയി വെക്കുക.
  4. നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ README അല്ലെങ്കിൽ ഡിപ്ലോയ്‌മെന്റ് ഗൈഡിൽ ആവശ്യമായ ഡിപ്ലോയ്‌മെന്റ് ടോപ്പോളജി രേഖപ്പെടുത്തുക, അതുവഴി സെൽഫ്-ഹോസ്റ്റ് ചെയ്യുന്ന ഉപയോക്താക്കൾക്ക് പ്രോക്സി-ട്രസ്റ്റ് ആവശ്യകതയെക്കുറിച്ച് അറിയാൻ സാധിക്കും.
  5. സ്റ്റാറ്റിക് അനാലിസിസ് (static-analysis) അല്ലെങ്കിൽ കോഡ്-റിവ്യൂ ടൂളുകൾ ഉപയോഗിക്കുക, പ്രോക്സി-വാലിഡേഷൻ ലോജിക് ഇല്ലാതെ സുരക്ഷാ തീരുമാനങ്ങൾക്കായി ഹെഡറുകൾ നേരിട്ട് ഉപയോഗിക്കുന്നത് ഇവ കണ്ടെത്തും.

ഇനി ശ്രദ്ധിക്കേണ്ടത്

സെൽഫ്-ഹോസ്റ്റ്ഡ് വെബ് സർവീസുകൾ നൽകുന്ന കമ്മ്യൂണിറ്റികൾ ഈ സംഭവത്തിന് ശേഷം അവരുടെ പ്രോക്സി-ട്രസ്റ്റ് ക്രമീകരണങ്ങൾ വീണ്ടും പരിശോധിക്കാൻ സാധ്യതയുണ്ട്.

അടിസ്ഥാന പാഠം ഇതാണ്: ഇന്റർനെറ്റിലുള്ള ആർക്കും എഴുതാൻ കഴിയുന്ന ഒരു ടെക്സ്റ്റ് നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ സുരക്ഷാ നിലവാരം നിശ്ചയിക്കാൻ അനുവദിക്കരുത്. റിക്വസ്റ്റ് ലെയറിനെയല്ല, നെറ്റ്‌വർക്ക് ലെയറിനെ വിശ്വസിക്കുക.