Remote code execution (RCE), selitetty: mitä se on ja miten estää se

Remote code execution (RCE) on ohjelmistojen tietoturva-aukkojen/haavoittuvuuksien Luokka. RCE-haavoittuvuudet sallivat haitallisen toimijan suorittaa minkä tahansa valitsemansa koodin etäkoneella LAN -, WAN-tai internet-kautta. RCE kuuluu laajempaan mielivaltaisen koodin suorittamisen (ACE) haavoittuvuuksien luokkaan. Internetin yleistyessä RCE-haavoittuvuuksien vaikutus kasvaa kuitenkin nopeasti. Niin, RCEs ovat nyt luultavasti tärkein eräänlainen ACE haavoittuvuus.

koska näin on, halusimme tarkastella tarkemmin erilaisia RCE-haavoittuvuuksia ja mahdollisia vastatoimia.

RCE-luokitus alkuperän mukaan

useimmilla, ellei kaikilla, tunnetuilla RCE-haavoittuvuuksilla on pieni määrä taustalla olevia syitä.

dynaaminen koodin suoritus

dynaaminen koodin suoritus on yleensä yleisin RCE: hen johtava hyökkäysvektori. Useimmissa ohjelmointikielissä on jokin tapa luoda koodia koodilla ja suorittaa se paikan päällä. Tämä on erittäin tehokas käsite, joka auttaa ratkaisemaan monia monimutkaisia ongelmia. Ilkeä kolmas osapuoli voi kuitenkin helposti käyttää sitä väärin saadakseen RCE-ominaisuuksia.

usein suorituksen aikana luotu koodi perustuu johonkin käyttäjän syötteeseen. Useimmiten koodi sisältää kyseisen syötteen jossain muodossa. Haitallinen toimija, joka ymmärtää, että dynaaminen koodinluonti käyttää tiettyä syöttöä, voisi tarjota kelvollista koodia syötteenä sovellukseesi hyökkäämistä varten. Jos käyttäjän syötteitä ei tarkisteta, kyseinen koodi suoritetaan kohdekoneessa.

yleisesti ottaen dynaaminen koodin toteutus aiheuttaa RCE: n haavoittuvuuksien kahta pääluokkaa: suoraa ja epäsuoraa.

suora

suoran dynaamisen koodin suorittamisen tapauksessa haitallinen toimija on tietoinen siitä, että heidän syötteitään käytettäisiin koodin generoinnissa.

epäsuora

epäsuora tapaus taas tarkoittaa dynaamista koodintuotantoa, johon sisältyy käyttäjän syötteitä. Käyttäjän syöte kuitenkin kulkee yhden tai useamman kerroksen läpi. Osa kerroksista saattaa jopa muuttaa tätä syöttöä ennen kuin se päätyy dynaamiseen koodin luomiseen. Myös dynaaminen koodinluonti saattaa olla sivuvaikutus eikä syötön ensisijainen käyttö. Sellaisenaan, se ei ole todella selvää käyttäjälle, joka tarjoaa syötteen, että syötettä käytetään rakennuspalikka koodinpätkä voidaan suorittaa etäkoneella.

autioituminen

autioituminen on erittäin hyvä esimerkki tästä skenaariosta. Näyttää siltä, että mitään dynaamista koodin luomista ei pitäisi tapahtua autioitumisen yhteydessä. Näin on itse asiassa silloin, kun sarjallistettu objekti sisältää vain alkeellisten tyyppien tai muiden vastaavien objektien tietokenttiä. Asiat mutkistuvat kuitenkin, kun objektin menetelmät/toiminnot sarjallistetaan. Deserialization sitten yleensä sisältää jonkinlaisen dynaamisen koodin luominen.

voisi ajatella, että dynaamiset kielet ovat ainoa paikka, jossa funktiosarjainti on järkevää. Ongelma on silloin rajattu. Mutta se on hyödyllinen skenaario staattisissa kielissäkin. Se on hieman vaikeampi saavuttaa staattisella kielellä, mutta ei mitenkään mahdotonta.

melko usein toteutus koostuu deserialisaation synnyttämistä välitysobjekteista / funktioista. Objektien/toimintojen tuottaminen suorituksen aikana on dynaamisen koodin tuottamista. Jos siis deserialisoitavat tiedot ovat peräisin etäkoneen tekemästä pyynnöstä, haitallinen toimija voisi muokata niitä. Huolellisesti muotoillun serialized koodinpätkiä voidaan ruiskuttaa, että temppu dynaaminen koodin sukupolven suorittaa ne, kun vedotaan osana deserialization.

muistin turvallisuus

toinen syy RCE-haavoittuvuuksiin liittyy muistin turvallisuuteen. Muistiturvallisuus tarkoittaa koodin pääsyn estämistä sellaisiin muistin osiin, joita se ei alustanut tai saanut syötteenä. Intuitiivisesti, saatat odottaa puute muistin turvallisuus johtaa luvattoman tietojen käyttö. Käyttöjärjestelmä ja taustalla oleva laitteisto käyttävät kuitenkin muistia varsinaisen suoritettavan koodin tallentamiseen. Myös metatiedot koodin suorittamisesta tallennetaan muistiin. Tällaisen muistin saaminen voi johtaa ACE: hen ja mahdollisesti RCE: hen. Joten mitkä ovat tärkeimmät syyt muistin Turvallisuus kysymyksiä?

ohjelmiston suunnitteluvirheet

ohjelmiston suunnitteluvirheet ovat eräänlainen muistiturvallisuushaavoittuvuus, jossa jossain taustalla olevassa komponentissa on suunnitteluvirhe. Useimmiten se olisi kääntäjä, tulkki tai virtuaalikone tai mahdollisesti käyttöjärjestelmän ydin tai kirjastot. On olemassa useita erilaisia puutteita, jotka kuuluvat tähän luokkaan. Käymme tarkemmin läpi, mikä on todennäköisesti yleisin.

puskurin ylivuotoalue tai puskurin ylivuotoalue

puskurin ylivuotoalue (tunnetaan myös nimellä puskurin ylitys) on melko yksinkertainen ja tunnettu tekniikka muistin turvallisuuden loukkaamiseksi. Se käyttää hyväkseen suunnitteluvirhettä tai bugia kirjoittaakseen muistisoluihin, jotka seuraavat muistipuskurin todellista loppua. Itse puskuri palautuu laillisesta puhelusta julkiselle API: lle. Puskuri toimii kuitenkin vain lähtöpisteenä jonkin objektin tai ohjelman laskurin yksityisen kentän/jäsenarvojen fyysisten muistiosoitteiden laskemiseksi. Niiden suhteellinen asema puskuriin on joko hyvin tiedossa tai voidaan arvata. Koodin tutkiminen, jos se on käytettävissä, tai ohjelman suorituksen virheenkorjaus suorituksen aikana saattaa auttaa haitallista toimijaa saamaan suhteellisia kantoja.

puskurin ylivuoto mahdollistaa siis muistin muokkaamisen, jonka pitäisi olla suunnittelultaan saavuttamattomissa. Kyseinen puskuri saattaa sijaita toisen koneen osoiteavaruudessa ja sitä voidaan muokata kutsumalla ETÄRAJAPINTAA. Se mahdollistaa pääsyn koneen etämuistiin. On selvää, että on olemassa useita tapoja käyttää tällaista pääsyä RCE: n instrumentoinnissa. Yleinen oletus on, että jos puskurin ylivuotohaavoittuvuus on olemassa, RCE on mahdollinen. Joten, koodin omistajien pitäisi korjata puskurin ylivuotoja ASAP, hyvissä ajoin ennen varsinaisen RCE hyökkäys ilmaantuu.

Scope

useimmiten puskurin ylivuoto kohdistuu C/C++ – koodiin, koska näille kielille ei ole rakennettu puskurin koon tarkistuksia. Monet muut suositut kehykset ja teknologiat päätyvät käyttämään C / C++ – kirjastoja syvällä pinnan alla, mikä tekee niistä automaattisesti alttiita tällaiselle hyökkäykselle.

solmu.js on tästä hyvä esimerkki, sillä C/C++ – pohjaisuuden lisäksi JavaScript runtime mahdollistaa myös natiivit c / c++ – lisäosat. Tämän vuoksi hyökkääjä voi askarrella pyynnöt huolellisesti solmuun.js server aiheuttaa puskurin ylivuodon ja siten muuttaa järjestelmän muistia kyseisellä koneella aiheuttaen mielivaltaisen koodin suorittamisen.

Laitteistosuunnitteluvirheet

mielenkiintoista kyllä, muistiturvallisuusrikkomuksia voi esiintyä myös laitteistosuunnitteluvirheiden vuoksi. Vaikka tällaiset haavoittuvuudet ovat harvinaisempia ja vaikeampia löytää, niillä on yleensä erittäin suuri vaikutus.

torjuvat RCE-hyökkäykset

vaikka jokaisen RCE-hyökkäyksen tulos on sama koodin suorittavan hyökkääjän kannalta, hyökkäysvektorit ovat luonteeltaan hyvin erilaisia. Niiden kaikkien estäminen vaatii merkittäviä ponnisteluja. Lisäksi ponnistus kasvaa yhdessä teknologiapinon kanssa. Kaikki tässä viestissä kuvatut hyökkäysvektorit ovat teknologia-agnostisia. Kaikki toteutukset ovat kuitenkin teknologiakohtaisia, samoin puolustusmekanismit.

perinteinen aikaa säästävä lähestymistapa on siis seurata verkkoliikennettä epäilyttävän sisällön varalta sen sijaan, että jokaista päätepistettä seurattaisiin sen erikoistekniikalla. Web application firewall (WAF) tyypillisesti suorittaa tämän työn. Vaikka tämä säästää aikaa, sillä on myös hintansa—WAF on verkon suorituskyvyn pullonkaula, ja siitä puuttuvat kaikki käytettävissä olevat taustatiedot varsinaisessa päätepisteessä tai sovellus-ja käyttäjätasolla. Näin ollen WAF: n liikenneanalyysi ei voisi koskaan olla täydellinen. Heuristiikka on väistämätöntä ilman täyttä tietoa, joten joko kaikkia uhkia ei synny tai vääriä positiivisia syntyy, tai useimmiten molempia.

liikkuminen sovelluksen sisällä: Sqreenin lähestymistapa

sqreen korjaa nämä WAF-puutteet lisäämättä loppukäyttäjälle aiheutuvia kehityskustannuksia siirtämällä näkyvyyttä sovelluksen sisällä, mikä tuo täydellisemmän suojan teknologiakohtaisella raspilla ja Sovelluksen sisäisellä WAF-toiminnolla. Sqreenin RASP ja WAF toimivat varsinaisen verkkosovelluksen, API: n tai verkkoliikennettä vastaanottavan microservice-palvelun sisällä. Se ei vaadi koodin muuttamista, vaikka. Se käyttää kullekin teknologialle ominaisia instrumentointipisteitä (esim.JVM API Javalle, V8 API solmulle.js jne.) muuttaa koodia ennen suoritusta suoritettaessa. Siten se pystyy seuraamaan ja muokkaamaan järjestelmän ja verkon tapahtumia samalla kun sillä on täysi konteksti kaikesta, mitä tapahtuu sovelluksen sisällä.

näin Sqreen voi havaita, että sovellus käyttää komponentteja, joilla on tunnettuja muistiturvallisuusongelmia. Se voi myös tunnistaa todellisen käyttäjän syötteet, jotka tekevät sen dynaamisen koodin suoritustapahtumiin. Tämä on luonnollisesti ylivertainen lähestymistapa RCEs: n havaitsemiseen ja ehkäisemiseen verrattuna perinteiseen WAF: hen, jolla on pääsy vain verkkoliikenteeseen.

paketointi

selvästi RCE on erittäin voimakas hyökkäysvektori. Mutta onneksi on mahdollista puolustautua myös RCE: n hyökkäyksiä vastaan. Yllä olevat tiedot voivat todella auttaa rakentamaan puolustusstrategiaa. Jos olet kiinnostunut muista hyökkäysvektoreista ja yksityiskohdista, tutustu aiempiin julkaisuihimme SQL injection, XXE ja LFI.