Ühest haavatavusest…

Aasta tagasi, 21. märtsil 2019, Mail.Ru bug bounty programmi HackerOne'ile tuli väga hea bugiraport alates maxarr. Ühe web-maili API-päringu POST-parameetritesse nullbaiti (ASCII 0) sisestades ilmnes HTTP-ümber suunamise andmetes mitte-initsialiseeritud mälu osi, milles sageli ilmusid teistele päringutele saadetud GET-parameetrite ja päiste killud, mis suundusid samale serverile.

See on kriitiline haavatavus, kuna päringud sisaldavad ka sessioonikuki. Mõne tunni pärast tehti ajutine lahendus, mis filtreeris nullbaiti (nagu hiljem selgus, oli seda ebapiisav, kuna jäi võimalus CRLF / ASCII 13, 10 sisestamiseks, mis võimaldab HTTP-pealkirjade ja vastuse andmete manipuleerimist, see on vähem kriitiline, kuid siiski ebameeldiv). Samal ajal edastati probleem turvaanalüütikutele ja arendajatele põhjuse väljaselgitamiseks ja vea kõrvaldamiseks.

Mail.ru post on väga keeruline rakendus, mille vastamise vormimisel võib osaleda suur hulk erinevaid frontend/backendi komponente, nii avatud lähtekoodiga (suur tänu kõikidele vabatahtlike arendajatele) kui ka omatooted. Õnnestus välja jätta kõik komponendid peale nginx ja openresty ning lokaliseerida probleem kuni väljakutse ngx.req.set_uri() OpenResty skriptis, mis ei käitunud ootuspäraselt (nullbaiti või reavahetuse sisestamine GET-parameetrite kaudu rewrite-s ngx_http_rewrite_module'i, mis vastavalt dokumentatsioonile kasutatakse ja peaks töötama täiesti samamoodi, ei õnnestu). Võimalikud tagajärjed kõrvaldati, kasutusele võeti võimalikult range filtreerimine ning kontrolliti, et filtreerimine kõrvaldab kõik võimalikud vektorid. Kuid mehanism, mis viis mälu sisu lekke tekkimiseni, jäi endiselt müsteeriumiks. Kuu aja pärast suleti viga lahendatuks ja vea tekkimise põhjuste analüüs lükati edasi paremate aegade tarbeks.

OpenResty on populaarne plugin, mis võimaldab kirjutada Lua skripte nginx-s, ja seda kasutatakse mitmes Mail.ru projektis, mistõttu probleemi ei peetud lahendatuks. Aja möödudes naaseti sellesse, et mõista tõelisi põhjuseid, võimalikud tagajärjed ja koostada soovitused arendajatele. Algkoodi uurimisse osalesid Denis Denisov ja Nikolai Ermiškin. Selgus, et:

• nginx-is, kui kasutatakse rewrite'i koos kohandatud andmetega, on võimalik directory traversal (võimalik, et ka SSRF) teatud konfigureerimiste korral, kuid see on tuntud fakt, ja seda peaksid avastama konfiguratsiooni staatilised analüsaatorid Nginx Amplify ja Gixy Yandexist (jah, me kasutame seda ka, aitäh). OpenResty kasutamisel on selline võimalus kergesti mööda lastav, kuid meie konfiguratsioon seda ei puudutanud.

  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'il on vigastus, mis põhjustab mälu lekkimist, kui rewrite rida sisaldab nullbaiti. Ümber suunamise korral eraldab nginx uue mälu puhversalviku, mis vastab kogu rea pikkusele, kuid kopeerib rea tühja funktsiooni kaudu, kus nullbitt on rea terminator, mistõttu rida kopeeritakse ainult nullbaiti kuni, ülejäänud puhver sisaldab mitteinihiseeritud andmeid. Üksikasjalik analüüs on saadaval siit.

  konfiguratsiooni näide (^@ nullbitt)

  
  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 sümbolite sisestamise eest ja võimaldab rewrite'is kasutada ainult GET parameetreid. Seetõttu ei saa kasutaja määratud parameetrite kaudu nginx'is sisestamist ära kasutada. POST parameetrid ei ole samas kaitstud. OpenResty võimaldab töötada nii GET kui ka POST parameetritega, mistõttu OpenResty kaudu POST parameetrite kasutamisel tekib võimalus sisestada spetsiaalseid sümboleid.

  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=salad" -vv
...
curl localhost:8337 -d "url=%00asdfasdfasdfasdfasdfasdfasdfasdf" -vv
...
Aadress: http://localhost:8337/{...võib sisaldada saladust...}
...


Edasi minev reaktsioon

Probleemi on teatanud Nginx'i ja OpenResty arendajad, kes ei pea seda probleemiks Nginx'is, kuna Nginx'is ei ole võimalust vea ära kasutamiseks spetsiaalsete märkide süstimise kaudu, lahendus mälu sisu avamine oli avaldatud 16. detsembril. Nelja kuu jooksul pärast raportit OpenResty's ei ole samuti tehtud mingeid muudatusi, kuigi oli arusaam, et vajalik on ohutum funktsiooni ngx.req.set_uri() variant. 18. märtsil 2020 avaldasime teabe, 21. märtsil avaldas OpenResty versiooni 1.15.8.3, mis lisab URI kontrolli.

Portswigger kirjutas hea artikkel, millele sai tagasisidet OpenResty ja Nginx'ilt (kuid väide, et avatakse vaid väike mälufragment, on vale ja eksitav, see sõltub nullbaiti järgnevast stringi pikkusest ja rikka piirangute puudumisel võib seda juhtida ründaja).

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

Kas viga oli Nginx'is? Jah, oli, kuna mälu sisu leke on igal juhul viga.

Kas viga oli OpenResty's? Jah, vähemalt ei ole uuritud ja dokumenteeritud avatud OpenResty funktsionaalsuse turvalisuse küsimus.

Kas OpenResty konfiguratsioonis või kasutamises oli viga? Jah, kuna selge viiteta tehti kontrollimata oletus kasutatava funktsionaalsuse turvalisuse kohta.

Milline neist vigadest on turvaaukus, mille pealt on $10000 preemia? Meie jaoks ei ole see põhimõtteliselt oluline. Igas tarkvaras, eriti seal, kus on mitu komponenti, mis on pakutud erinevate projektide ja arendajate poolt, ei saa keegi kunagi garanteerida, et kõik töövõtted on teada, dokumenteeritud ja et vigu ei esine. Seetõttu tekib iga turvavigastus seal, kus see mõjutab turvalisust.

Igatahes on hea praktika normaliseerida või võimalikult palju piirata/filtreerida sisendandmeid, mis suunduvad igasse välist moodulisse/API-sse, kui ei ole selgeid viiteid ja üheselt mõistetavat arusaamist, et seda ei ole vajalik teha.

Errata

Kogemuse põhjal eelmisest artiklist., keele puhtuse säilitamiseks:

bug bounty — vigade jahiks mõeldud võistlus
bugiraport — vea teatis
suunamine — ümbersuunamine
avatud lähtekoodiga — avatud koodiga
errata — vigade parandamine

Allikas: habr.com