Ühe haavatavuse kohta ...

Aasta tagasi, 21. märtsil 2019, Mail.Ru bug bounty programm saabus HackerOne'ile väga hea veateade alates maxarr. Kui ühte POST-parameetrit, mis kuulus veebiposti API-päringule, mis tagastas HTTP-ümbersuunamise, sisestati nullbyte (ASCII 0), ilmus ümbersuunamise andmetes nähtavale die-iniitiialiseeritud mälu fragmente, kus tihti paljastusid fragmendid sama serveri teiste päringute GET-parameetritest ja päistest.

See on kriitiline haavatavus, kuna päringud sisaldavad ka sessiooniküpsiseid. Mõne tunni pärast tehti ajutine parandamine, mis filtreeris nullbyte'i (kui hiljem selgus, et see ei olnud piisav, kuna CRLF / ASCII 13, 10 süstimise võimalus jäi alles, mis võimaldab manipuleerida HTTP-vastuse päiste ja andmetega; see on vähem kriitiline, kuid siiski ebameeldiv). Samal ajal anti probleem turvaanalüütikutele ja arendajatele, et leida ja kõrvaldada vea tekkimise põhjused.

Mail.ru post on väga keeruline rakendus, mille vastuse koostamisel võib osaleda palju erinevaid frontend / backend komponente, nii avatud lähtekoodiga (suur tänu kõigile avatud tarkvara arendajatele) kui ka oma arendusega. Õnnestus välja jätta kõik komponendid peale nginx'i ja openresty ning lokaliseerida probleem üleskutse juurde ngx.req.set_uri() OpenResty skripti, mis ei käitunud nii, nagu oodati (nullbyte'i või reavahetuse sisestamine läbi GET-parameetrite, kasutades rewrite ngx_http_rewrite_module'is, mis, dokumentatsiooni kohaselt, on kasutusel ja peaks töötama täpselt samamoodi, ei olnud võimalik). Kõik võimalikud tagajärjed kõrvaldatud, rakendatud maksimaalselt range filtreerimine ja kontrollitud, et filtreerimine suudab kõrvaldada kõik võimalikud vektorid. Kuid mehhanism, mis põhjustas mälu sisu lekke, jäi siiski mõistatuseks. Kuu aja pärast suleti vea raport lahendatuks, kuid vea tekkimise põhjuse analüüs lükati edasi paremate aegade poole.

OpenResty on väga populaarne plugin, mis võimaldab kirjutada Lua skripte nginx'i sees, ning seda kasutatakse mitmetes Mail.ru projektides, seetõttu ei peetud probleemi lahendatuks. Ja mõne aja pärast naasid nad selle juurde, et mõista tõelisi põhjuseid, võimalikke tagajärgi ja koostada soovitusi arendajatele. Algse koodi uurimisel osalesid Denis Denisov ja Nikolai ErmiškinSelgus, et:

• Nginx-i kasutamisel on rewrite ja kasutajaandmete puhul teatud konfiguratsioonides võimalik directory traversal (ja tõenäoliselt ka SSRF), kuid see on tuntud probleem ja see peaks olema avastatud konfiguratsioonide staatiliste analüsaatorite abil. Nginx Amplify ja Gixy Yandexilt (jah, me kasutame seda ka, aitäh). OpenResty kasutamisel on selline võimalus kergesti tähelepanuta jäetud, kuid meie konfiguratsioon ei puudutanud seda.

  konfiguratsiooni näide:

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

  tulemus

  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-is on viga, mis põhjustab mälu sisu leket, kui rewrite string sisaldab nullbaiti. Ümbersuunamise korral eraldab Nginx uue mälupuhvri, mis vastab kogu stringi pikkusele, kuid kopeerib sinna stringi läbi stringifunktsiooni, kus nullbait on stringi terminaator, seetõttu kopeeritakse string ainult kuni nullbaitini, puhvri ülejäänud osa sisaldab algatamata andmeid. Üksikasjalikku analüüsi saab leida siin.

  konfiguratsiooni näide (^@ nullbait)

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

  tulemus
  curl localhost:8337/secret -vv
...
curl localhost:8337/memleak -vv
...
Asukoht: http://localhost:8337/secret
...


• Nginx kaitseb GET parameetreid spetsiaalsete märkide süstimise eest ning võimaldab rewrite'is kasutada ainult GET parameetreid. Seetõttu ei ole Nginx-is võimalik ära kasutada süstimist, mis toimub kasutaja kontrollitavate parameetrite kaudu. POST parameetrid ei ole seevastu kaitstud. OpenResty võimaldab töötada nii GET kui ka POST parameetritega, seetõttu tekib OpenResty kasutamisel POST parameetrite kaudu võimalus spetsiaalsete märkide süstimiseks.

  konfiguratsiooni näide:

  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;
  }
  

  tulemus:

  curl localhost:8337 -d "url=secret" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Asukoht: http://localhost:8337/{...võib sisaldada secret...}
...


Edasine reaktsioon

Probleemist teavitati Nginx ja OpenResty arendajaid, arendajad ei pea probleemi Nginx-is turvaveaks, kuna Nginx-is ei ole võimalik ekspluateerida viga spetsiaalsete märkide süstimise kaudu, parandamine mälu sisu leke avaldati 16. detsembril. 4 kuu jooksul alates raporteerimist ei ole OpenRestys samuti tehtud mingeid muudatusi, kuigi oli arusaam, et vajalik on ohutu variant funktsioonile ngx.req.set_uri(). 18. märtsil 2020 avaldasime teabe, 21. märtsil vabastas OpenResty versiooni 1.15.8.3, mis lisas URI kontrollimise.

Portswigger kirjutas hea hea artikkel ja võttis kommentaarid OpenResty ja Nginxi kohta (kuigi kommentaar, et paljastatakse ainult väike mälufragmente, on vale ja eksitav, see sõltub nullbaiti järgnevast stringist ja, kui puuduvad selged pikkusepiirangud, võib seda rünnakute eest kontrollida).

Mis oli viga ja mida teha, et seda vältida?

Kas viga oli nginxis? Jah, see oli, kuna mälu sisu lekke on igal juhul viga.

Kas oli viga OpenRestys? Jah, vähemalt ei uuritud ega dokumenteeritud pakutava OpenResty funktsionaalsuse turvaküsimusi.

Kas oli konfiguratsiooni/väärkasutuse viga OpenRestys? Jah, kuna selgeid juhiseid puudumisel tehti kontrollimata eeldus kasutatud funktsionaalsuse turvalisuse kohta.

Milline neist vigadest on turvaaugu, mille baunti väärtus on $10000? Meie jaoks pole see põhimõtteliselt oluline. Igas tarkvaras, eriti erinevate komponentide ristumiskohas, eriti erinevate projektide ja arendajate poolt pakutavas, ei saa keegi kunagi garanteerida, et kõik selle töö omadused on tuntud ja dokumenteeritud ning vigu ei ole. Seega tekib iga turvaauk seal, kus see mõjutab turvalisust.

Igal juhul on hea tava normaliseerida või maksimaalselt piirata/filtreerida sisendeid, mis suunduvad igasse välimisse moodulisse/API-sse, kui puuduvad selged juhised ja üheselt mõistetav arusaam, et seda ei nõuta.

Errata

Kogemuse põhjal eelnevas artiklis, et säilitada keele puhtus:

bug bounty — vigade jahimise konkurss
veateade — vea teatis
redirect — ümbersuunamine
avaldatud — avatud koodiga
errata — vigade parandamine

Allikas: habr.com