ഒരു അപകടസാധ്യതയെക്കുറിച്ച്...

ഒരു വർഷം മുമ്പ്, മാർച്ച് 21, 2019, at ബഗ് ബൗണ്ടി പ്രോഗ്രാം Mail.Ru വളരെ നല്ല ഒന്ന് HackerOne-ൽ വന്നു ബഗ് റിപ്പോർട്ട് от maxarr. ഒരു എച്ച്ടിടിപി റീഡയറക്‌ട് നൽകിയ വെബ്‌മെയിൽ API അഭ്യർത്ഥനകളിലൊന്നിന്റെ POST പാരാമീറ്ററിലേക്ക് ഒരു സീറോ ബൈറ്റ് (ASCII 0) അവതരിപ്പിക്കുമ്പോൾ, റീഡയറക്‌ട് ഡാറ്റയിൽ ആരംഭിക്കാത്ത മെമ്മറിയുടെ ഭാഗങ്ങൾ ദൃശ്യമാണ്, അതിൽ GET പാരാമീറ്ററുകളിൽ നിന്നുള്ള ശകലങ്ങളും മറ്റ് അഭ്യർത്ഥനകളുടെ തലക്കെട്ടുകളും ഒരേ സെർവർ.

ഇതൊരു നിർണായകമായ അപകടമാണ്, കാരണം... അഭ്യർത്ഥനകളിൽ സെഷൻ കുക്കികളും അടങ്ങിയിരിക്കുന്നു. കുറച്ച് മണിക്കൂറുകൾക്ക് ശേഷം, സീറോ ബൈറ്റ് ഫിൽട്ടർ ചെയ്യുന്ന ഒരു താൽക്കാലിക പരിഹാരം ഉണ്ടാക്കി (പിന്നീട് ഇത് പര്യാപ്തമല്ല, കാരണം CRLF / ASCII 13, 10 കുത്തിവയ്ക്കാനുള്ള സാധ്യതയുണ്ട്, ഇത് തലക്കെട്ടുകൾ കൈകാര്യം ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു. HTTP പ്രതികരണത്തിന്റെ ഡാറ്റ, ഇത് നിർണായകമല്ല, പക്ഷേ ഇപ്പോഴും അസുഖകരമാണ്). അതേസമയം, ബഗിന്റെ കാരണങ്ങൾ കണ്ടെത്തുന്നതിനും ഇല്ലാതാക്കുന്നതിനും പ്രശ്നം സുരക്ഷാ വിശകലന വിദഗ്ധർക്കും ഡവലപ്പർമാർക്കും കൈമാറി.

Mail.ru മെയിൽ വളരെ സങ്കീർണ്ണമായ ഒരു ആപ്ലിക്കേഷനാണ്; ഓപ്പൺ സോഴ്‌സും (എല്ലാ സ്വതന്ത്ര സോഫ്റ്റ്‌വെയർ ഡെവലപ്പർമാർക്കും നന്ദി) ഇൻ-ഹൌസ് വികസിപ്പിച്ചതുമായ നിരവധി ഫ്രണ്ട്-എൻഡ്/ബാക്ക്-എൻഡ് ഘടകങ്ങൾ, പ്രതികരണം സൃഷ്ടിക്കുന്നതിൽ പങ്കാളികളാകാം. വിളിക്കുന്നതിന് മുമ്പ് nginx, openresty എന്നിവ ഒഴികെയുള്ള എല്ലാ ഘടകങ്ങളും ഒഴിവാക്കാനും പ്രശ്നം പ്രാദേശികവൽക്കരിക്കാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു ngx.req.set_uri() പ്രതീക്ഷിച്ച പോലെ പ്രവർത്തിക്കാത്ത ഒരു OpenResty സ്ക്രിപ്റ്റിൽ (ngx_http_rewrite_module-ൽ റീറൈറ്റുചെയ്യുന്ന GET പാരാമീറ്ററുകൾ വഴി ഒരു നൾ ബൈറ്റ് അല്ലെങ്കിൽ ലൈൻ ഫീഡ് ചേർക്കുന്നു, ഇത് ഡോക്യുമെന്റേഷൻ അനുസരിച്ച് ഉപയോഗിക്കുന്നു, അത് അതേ രീതിയിൽ തന്നെ പ്രവർത്തിക്കുമെന്ന് തോന്നുന്നു. പ്രവർത്തിക്കുന്നില്ല). സാധ്യമായ പ്രത്യാഘാതങ്ങൾ ഇല്ലാതാക്കി, ഫിൽട്ടറിംഗ് കഴിയുന്നത്ര കർശനമായി ചേർത്തു, സാധ്യമായ എല്ലാ വെക്റ്ററുകളും ഇല്ലാതാക്കാൻ ഫിൽട്ടറിംഗ് പരിശോധിച്ചു. എന്നാൽ മെമ്മറി ഉള്ളടക്കങ്ങളുടെ ചോർച്ചയിലേക്ക് നയിച്ച സംവിധാനം ഒരു രഹസ്യമായി തുടർന്നു. ഒരു മാസത്തിനുശേഷം, ബഗ് റിപ്പോർട്ട് പരിഹരിച്ചു, ബഗിന്റെ കാരണങ്ങളെക്കുറിച്ചുള്ള വിശകലനം മികച്ച സമയത്തേക്ക് മാറ്റിവച്ചു.

nginx-നുള്ളിൽ Lua സ്ക്രിപ്റ്റുകൾ എഴുതാൻ നിങ്ങളെ അനുവദിക്കുന്ന വളരെ ജനപ്രിയമായ ഒരു പ്ലഗിൻ ആണ് OpenResty, കൂടാതെ ഇത് നിരവധി Mail.ru പ്രോജക്റ്റുകളിൽ ഉപയോഗിക്കുന്നു, അതിനാൽ പ്രശ്നം പരിഹരിച്ചതായി കണക്കാക്കപ്പെട്ടില്ല. കുറച്ച് സമയത്തിന് ശേഷം, യഥാർത്ഥ കാരണങ്ങളും സാധ്യമായ അനന്തരഫലങ്ങളും മനസിലാക്കാനും ഡവലപ്പർമാർക്കായി ശുപാർശകൾ നൽകാനും അവർ ഒടുവിൽ അതിലേക്ക് മടങ്ങി. സോഴ്സ് കോഡിന്റെ ഉത്ഖനനത്തിൽ പങ്കെടുത്തു ഡെനിസ് ഡെനിസോവ് и നിക്കോളായ് എർമിഷ്കിൻ. അത് മാറി:

• nginx-ൽ, ഉപയോക്തൃ ഡാറ്റ ഉപയോഗിച്ച് റീറൈറ്റുചെയ്യുമ്പോൾ, ചില കോൺഫിഗറേഷനുകളിൽ ഡയറക്‌ടറി ട്രാവെർസലിനുള്ള (ഒരുപക്ഷേ SSRF) സാധ്യതയുണ്ട്, എന്നാൽ ഇത് അറിയപ്പെടുന്ന ഒരു വസ്തുതയാണ്, ഇത് സ്റ്റാറ്റിക് കോൺഫിഗറേഷൻ അനലൈസറുകൾ വഴി കണ്ടെത്തേണ്ടതാണ്. Nginx ആംപ്ലിഫൈ и ജിക്സി Yandex-ൽ നിന്ന് (അതെ, ഞങ്ങൾ അതും ഉപയോഗിക്കുന്നു, നന്ദി). OpenResty ഉപയോഗിക്കുമ്പോൾ, ഈ സവിശേഷത നഷ്‌ടമാകുന്നത് എളുപ്പമാണ്, പക്ഷേ ഇത് ഞങ്ങളുടെ കോൺഫിഗറേഷനെ ബാധിച്ചില്ല.

  കോൺഫിഗറേഷൻ ഉദാഹരണം:

  location ~ /rewrite {
      rewrite ^.*$ $arg_x;
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  ഇഫക്ട്

  curl localhost:8337/rewrite?x=/../../../../../../../etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

• Nginx-ന് ഒരു ബഗ് ഉണ്ട്, അത് റീറൈറ്റിംഗ് ലൈനിൽ ഒരു നൾ ബൈറ്റ് അടങ്ങിയിട്ടുണ്ടെങ്കിൽ മെമ്മറി ലീക്ക് ചെയ്യും. ഒരു റീഡയറക്‌ട് ഇഷ്യൂ ചെയ്യുമ്പോൾ, ലൈനിന്റെ മുഴുവൻ നീളവുമായി പൊരുത്തപ്പെടുന്ന ഒരു പുതിയ മെമ്മറി ബഫർ nginx അനുവദിക്കും, എന്നാൽ സീറോ ബൈറ്റ് ഒരു ലൈൻ ടെർമിനേറ്ററായ ഒരു ലൈൻ ഫംഗ്‌ഷനിലൂടെ ലൈൻ അവിടെ പകർത്തുന്നു, അതിനാൽ ലൈൻ പൂജ്യം വരെ മാത്രമേ പകർത്തൂ. ബൈറ്റ്; ബാക്കിയുള്ള ബഫറിൽ ആരംഭിക്കാത്ത ഡാറ്റ അടങ്ങിയിരിക്കുന്നു. വിശദമായ വിശകലനം കണ്ടെത്താം ഇവിടെ.

  കോൺഫിഗറേഷൻ ഉദാഹരണം (^@ സീറോ ബൈറ്റ്)

  
  location ~ /memleak {
      rewrite ^.*$ "^@asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdasdf";
  }
  
  location / {
      root html;
      index index.html index.htm;
  }

  ഇഫക്ട്
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Location: http://localhost:8337/secret
...


• സേവന പ്രതീകങ്ങൾ കുത്തിവയ്ക്കുന്നതിൽ നിന്ന് GET പാരാമീറ്ററുകളെ Nginx പരിരക്ഷിക്കുകയും റീറൈറ്റുചെയ്യുമ്പോൾ GET പാരാമീറ്ററുകൾ മാത്രം ഉപയോഗിക്കുന്നത് സാധ്യമാക്കുകയും ചെയ്യുന്നു. അതിനാൽ, nginx-ലെ ഉപയോക്തൃ നിയന്ത്രിത പാരാമീറ്ററുകൾ വഴി കുത്തിവയ്പ്പ് ചൂഷണം ചെയ്യുന്നത് സാധ്യമല്ല. POST പാരാമീറ്ററുകൾ പരിരക്ഷിച്ചിട്ടില്ല. GET, POST പാരാമീറ്ററുകൾക്കൊപ്പം പ്രവർത്തിക്കാൻ OpenResty നിങ്ങളെ അനുവദിക്കുന്നു, അതിനാൽ OpenResty വഴി POST പാരാമീറ്ററുകൾ ഉപയോഗിക്കുമ്പോൾ, പ്രത്യേക പ്രതീകങ്ങൾ കുത്തിവയ്ക്കുന്നത് സാധ്യമാകും.

  കോൺഫിഗറേഷൻ ഉദാഹരണം:

  location ~ /memleak {
      rewrite_by_lua_block {
          ngx.req.read_body();
          local args, err = ngx.req.get_post_args();
          ngx.req.set_uri( args["url"], true );
      }
  }
  
  location / {
      root html;
      index index.html index.htm;
  }
  

  ഫലമായി:

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Location: http://localhost:8337/{...может содержать secret...}
...


കൂടുതൽ പ്രതികരണം

പ്രശ്നം nginx, OpenResty എന്നിവയുടെ ഡവലപ്പർമാരോട് റിപ്പോർട്ട് ചെയ്തു, ഡവലപ്പർമാർ ഈ പ്രശ്നം nginx-ലെ ഒരു സുരക്ഷാ ബഗ് ആയി കണക്കാക്കുന്നില്ല, കാരണം nginx-ൽ തന്നെ പ്രത്യേക പ്രതീകങ്ങൾ കുത്തിവയ്ക്കുന്നതിലൂടെ പിശക് ചൂഷണം ചെയ്യാൻ ഒരു മാർഗവുമില്ല, പരിഹരിക്കുക മെമ്മറി വെളിപ്പെടുത്തൽ ഡിസംബർ 16-ന് പ്രസിദ്ധീകരിച്ചു. ngx.req.set_uri() ഫംഗ്‌ഷന്റെ ഒരു സുരക്ഷിത പതിപ്പ് ആവശ്യമാണെന്ന് ധാരണയുണ്ടെങ്കിലും, റിപ്പോർട്ടിന് ശേഷമുള്ള 4 മാസങ്ങളിൽ, OpenResty-യിൽ മാറ്റങ്ങളൊന്നും വരുത്തിയിട്ടില്ല. 18 മാർച്ച് 2020-ന് ഞങ്ങൾ വിവരങ്ങൾ പ്രസിദ്ധീകരിച്ചു, മാർച്ച് 21-ന് OpenResty പുറത്തിറക്കി പതിപ്പ് 1.15.8.3, ഇത് URI മൂല്യനിർണ്ണയം ചേർക്കുന്നു.

പോർട്ട്സ്വിഗർ എഴുതി നല്ല ലേഖനം കൂടാതെ OpenResty, Nginx എന്നിവയിൽ നിന്നും അഭിപ്രായങ്ങൾ എടുത്തു (മെമ്മറിയുടെ ഒരു ചെറിയ ശകലം മാത്രമേ തുറന്നുകാട്ടപ്പെടുന്നുള്ളൂ എന്ന അഭിപ്രായം തെറ്റും തെറ്റിദ്ധരിപ്പിക്കുന്നതുമാണ്, ഇത് നിർണ്ണയിച്ചിരിക്കുന്നത് നൾ ബൈറ്റിന് ശേഷമുള്ള വരിയുടെ ദൈർഘ്യവും, വ്യക്തമായ നിയന്ത്രണങ്ങളുടെ അഭാവത്തിൽ നീളം, ആക്രമണകാരിക്ക് നിയന്ത്രിക്കാനാകും).

അപ്പോൾ എന്താണ് തെറ്റ്, അത് തടയാൻ എന്താണ് ചെയ്യേണ്ടത്?

nginx-ൽ ഒരു ബഗ് ഉണ്ടായിരുന്നോ? അതെ, കാരണം, മെമ്മറി ഉള്ളടക്കങ്ങൾ ചോർത്തുന്നത് ഏത് സാഹചര്യത്തിലും ഒരു പിശകാണ്.

ഓപ്പൺ റെസ്റ്റിയിൽ ഒരു ബഗ് ഉണ്ടായിരുന്നോ? അതെ, OpenResty വാഗ്ദാനം ചെയ്യുന്ന പ്രവർത്തനത്തിന്റെ സുരക്ഷയുടെ പ്രശ്നമെങ്കിലും അന്വേഷിക്കുകയും രേഖപ്പെടുത്തുകയും ചെയ്തിട്ടില്ല.

ഓപ്പൺ റെസ്റ്റിയിൽ ഒരു കോൺഫിഗറേഷൻ/ഉപയോഗ പിശക് ഉണ്ടായിരുന്നോ? അതെ, കാരണം വ്യക്തമായ ഒരു പ്രസ്താവനയുടെ അഭാവത്തിൽ, ഉപയോഗിക്കുന്ന പ്രവർത്തനത്തിന്റെ സുരക്ഷയെക്കുറിച്ച് സ്ഥിരീകരിക്കാത്ത ഒരു അനുമാനം ഉണ്ടായി.

$10000 ബൗണ്ടിയുള്ള സുരക്ഷാ അപകടസാധ്യതയുള്ള ഈ ബഗുകളിൽ ഏതാണ്? ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം ഇത് പൊതുവെ പ്രധാനമല്ല. ഏതൊരു സോഫ്‌റ്റ്‌വെയറിലും, പ്രത്യേകിച്ച് വിവിധ പ്രോജക്‌ടുകളും ഡവലപ്പർമാരും നൽകുന്ന നിരവധി ഘടകങ്ങളുടെ കവലയിൽ, അവരുടെ ജോലിയുടെ എല്ലാ സവിശേഷതകളും അറിയുകയും രേഖപ്പെടുത്തുകയും ചെയ്‌തിട്ടുണ്ടെന്നും പിശകുകളൊന്നുമില്ലെന്നും ആർക്കും ഉറപ്പുനൽകാൻ കഴിയില്ല. അതിനാൽ, സുരക്ഷയെ ബാധിക്കുന്നിടത്ത് ഏത് സുരക്ഷാ തകരാറും സംഭവിക്കുന്നു.

ഏത് സാഹചര്യത്തിലും, വ്യക്തമായ നിർദ്ദേശങ്ങളും ഇത് ആവശ്യമില്ലെന്ന വ്യക്തമായ ധാരണയും ഇല്ലെങ്കിൽ, ഏതെങ്കിലും ബാഹ്യ മൊഡ്യൂളിലേക്ക്/എപിഐയിലേക്ക് പോകുന്ന ഇൻപുട്ട് ഡാറ്റ കഴിയുന്നത്ര നോർമലൈസ് ചെയ്യുകയോ പരിമിതപ്പെടുത്തുകയോ / ഫിൽട്ടർ ചെയ്യുകയോ ചെയ്യുന്നതാണ് നല്ലത്.

എറാറ്റ

അനുഭവത്തിലൂടെ മുൻ ലേഖനം, ഭാഷയുടെ പരിശുദ്ധി കാത്തുസൂക്ഷിക്കുന്നതിനായി:

ബഗ് ഔദാര്യം - ബഗ് വേട്ട മത്സരം
ബഗ് റിപ്പോർട്ട് - പിശക് അറിയിപ്പ്
തിരിച്ചുവിടുക - തിരിച്ചുവിടൽ
തുറന്ന ഉറവിടം - ഓപ്പൺ സോഴ്സ്
പിശക് - തെറ്റുകളിൽ പ്രവർത്തിക്കുക

അവലംബം: www.habr.com