Shellshock on Bash-komentorivin komentorajapinnan komentokuoressa oleva virhe, joka on ollut olemassa jo 30 vuotta ja joka havaittiin merkittäväksi uhaksi vuonna 2014. Nykyään Shellshock on edelleen uhka yrityksille.

Uhka on varmasti vähemmän riskialtis kuin löytämisvuonna. Kuitenkin vuonna, jolloin tietoturvaprioriteetit on kalibroitu uudelleen kaoottisen maiseman myötä, on hyvä hetki tarkastella tätä uhkaa ja taustalla olevia tekijöitä, jotka pitävät nämä hyökkäykset elossa nykyäänkin.

Miksi Shellshock on merkityksellinen vuonna 2020?

Shellshock on kriittinen haavoittuvuus, koska se antaa hyökkääjille eskaloituneet oikeudet, joiden avulla he voivat vaarantaa järjestelmiä mielensä mukaan. Vaikka ShellShock-haavoittuvuus, CVE-2014-6271, löydettiin vuonna 2014, sen tiedetään olevan edelleen olemassa suuressa määrässä palvelimia maailmassa. Haavoittuvuutta päivitettiin (CVE-2014-7169) pian sen jälkeen, ja sitä on muokattu vuoteen 2018 asti.

Pääsyy siihen, että Shellshock on edelleen käytössä, ei ole mikään järkytys. Tämä haavoittuvuus on yksinkertainen ja edullinen hyökkäys, jota pahat toimijat voivat käyttää tietämätöntä kohdetta vastaan. Korjauksia on ollut saatavilla CVE-merkinnän jälkeen, mutta kaikki organisaatiot, joilla ei ole kunnollisia korjaustenhallintajärjestelmiä käytössä, voivat edelleen olla haavoittuvia.

Shellshock oli näkyvästi esillä vielä vuonna 2017. Kun hyökkääjät tarvitsevat vain perusohjelmointitaitoja, palvelimen ja pääsyn haittaohjelmaan, se ei ole yllättävää. Lisäksi hyökkäyksen toteuttaminen ei maksa paljon enempää kuin muutaman dollarin kuukaudessa. Matematiikka on hyökkääjien eduksi. Vähäinen tietämys, vähäinen vaivannäkö ja alhaiset kustannukset vastaavat yhtä helppoa hakkerointistrategiaa.

Kaikesta laajasta tietoverkkoturvallisuuden mediajulkisuudesta ja jopa sisäisen turvallisuuden ministeriön varoituksesta huolimatta jotkin järjestelmät ovat edelleen korjaamattomia. Eräässä esimerkissä Center for Election Systemsin virkamiehet jättivät soveltamatta korjausta, joka vaaransi Georgian vaalijärjestelmät.

Miten Shellshock toimii?

Maailman kielellä Shellshock on haavoittuvuus, jonka avulla haavoittuvaa Bash-versiota sisältäviä järjestelmiä voidaan käyttää hyväksi komentojen suorittamiseen suuremmilla etuoikeuksilla. Näin hyökkääjät voivat mahdollisesti ottaa kyseisen järjestelmän haltuunsa.

Syvemmälle teknisiin yksityiskohtiin mentäessä Shellshock on Bash-kuoressa (GNU Bash versioon 4.3 asti) oleva tietoturvaongelma, joka saa Bashin suorittamaan tahattomia bash-komentoja ympäristömuuttujista. Haavoittuvuutta hyväksikäyttävät uhkaajat voivat antaa komentoja etänä kohdeisännällä. Vaikka Bash ei ole luonnostaan yhteydessä Internetiin, monet sisäiset ja ulkoiset palvelut, kuten verkkopalvelimet, käyttävät ympäristömuuttujia kommunikoidakseen palvelimen käyttöjärjestelmän kanssa.

Jos näitä syötettyjä tietoja ei ole sanitoitu – koodausstandardin mukainen prosessi, jolla varmistetaan, että koodi ei ole osa syötettä – ennen niiden suorittamista, hyökkääjät voivat käynnistää HTTP-pyyntökomentoja, jotka suoritetaan Bash-kuorella.

Haavoittuvuus yksityiskohtaisesti

Web-palvelimet eivät ole ainoita haavoittuvia verkkoresursseja. Myös sähköpostipalvelimet ja DNS-palvelimet, jotka käyttävät BASHia kommunikoidakseen käyttöjärjestelmän kanssa, voivat olla alttiita. BASH löytyy yleensä Unix-pohjaisista järjestelmistä, mutta Windows-pohjaisia järjestelmiä käyttävät organisaatiot eivät ole immuuneja. Ne hyödyntävät todennäköisesti laitteita tai laitteistoja, jotka ovat haavoittuvia. Muista, että BASH voi olla osa kotireitittimiä, monia IoT-laitteita ja sulautettuja järjestelmiä.

Shellshockia voidaan käyttää jopa palvelunestohyökkäyksiin (Denial of Service, DOS).

Tässä on koodirivi (Bash-funktion julistus, jota seuraa puolipiste ja ’sleep’-komento, joka ajetaan kolmesta mahdollisesta polusta sen suorittamisen varmistamiseksi):

new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20

Tämä ”sleep”-komento pakottaa palvelimen odottamaan kaksikymmentä sekuntia ennen vastausta. Näin koneen resursseja pidetään käytännössä panttivankina, koska kone ei voi tehdä mitään muuta kahteenkymmeneen sekuntiin.

Yksi sleep-komento voi olla vaaraton, mutta hyökkääjä voi korvata sen haitallisella koodilla. Sitten tämä koodi voi kahlita palvelimen tai resurssin niin, ettei se pysty käsittelemään mitään pyyntöjä.

Riski siitä, että haitalliset Internet-käyttäjät voivat suorittaa haluamiaan komentoja etänä, on suuri. Aukon avulla pahantekijät voivat käynnistää järjestelmässä ohjelmia, luoda lähteviä yhteyksiä omiin järjestelmiinsä ja suorittaa haittaohjelmia.

Periaatteessa kriittisintä on, että haavoittuvuuden avulla voidaan varastaa järjestelmään tallennettuja luottamuksellisia tietoja ja informaatiota, kuten luottokorttitietoja, salasanoja ja henkilökohtaisesti tunnistettavia tietoja (PII).

Onko Shellshock yhä laajalle levinnyt?

Shellshock ei ole enää yhtä yleinen kuin silloin, kun se löydettiin vuonna 2014. Kuvittele haaste, kun joudut korjaamaan kaikki yrityksesi haavoittuvat palvelimet (ja niitä oli tuolloin paljon).

Sitä huolimatta Shellshock on edelleen ongelma.

On esimerkiksi meneillään ”Sea Turtle” -niminen kyberuhka- ja haavoittuvuuskampanja, joka hyödyntää DNS-tietueita päästäkseen käsiksi arkaluontoisiin järjestelmiin. Hyökkäysten onnistuminen edellyttää useita yleisiä laitteisto- ja ohjelmistohaavoittuvuuksia – Shellshock on yksi niistä.

Vaikka se ei ole läheskään yhtä yleinen kuin aiemmin, jokaisen yrityksen tulisi varmistaa, että kaikki laitteistot ja ohjelmistot on korjattu ja ajan tasalla.

Miten tietää, onko se vaikuttanut sinuun

Koska Shellshock on kuusi vuotta vanha, haavoittuvuusskannereita on saatavilla runsaasti. Jotkut niistä ovat ilmaisia. Yhden, bashcheckin, voi ladata Githubin kautta.

Teknisille ihmisille riittää myös yksinkertaisen komennon kirjoittaminen Bash-kehotteeseen:

env X=”() { :;} ; echo Bash is Infected” /bin/sh -c ”echo completed”

env X=”() { :;} ; echo Bash is Infected” `which bash` -c ”echo completed”

env VAR='() { :;}; echo Bash is Infected’ bash -c ”echo completed”

Jos kehote palauttaa ”Bash is Infected”-viestin, on aika päivittää ja korjata. Jos ulostulo ei palauta ”Bash is Infected”, se vastaa jotakuinkin näin:

bash: warning:

bash: error importing function definition for `VAR’

Bash Test

Jos haluat testata verkkosivustojen tai tiettyjen CGI-skriptien haavoittuvuutta, seuraava työkalu voi auttaa: ’ShellShock’ Bash-haavoittuvuus CVE-2014-6271 Testityökalu. Kirjoita jompaankumpaan syöttökenttään sen verkkosivuston tai CGI-skriptin URL-osoite, jonka haluat testata, ja napsauta sinisiä painikkeita.

Mitä voimme oppia kyberturvauhkista

Yrityksille tärkein oppi tästä on – ja se on syytä toistaa – järjestelmien korjaaminen.

Tiimit, jotka pystyvät lyhentämään korjaamiseen kuluvia aikoja, ovat paremmassa asemassa ja pystyvät siirtämään resursseja kiireellisempiin tietoturvaongelmiin. Vaikka jotkin yritykset pitävät korjausten hallintaa enemmän tietotekniikan kuin tietoturvan vastuualueena, tietoturvaosastojen on aina pidettävä korjausten hallinta etusijalla, sillä se on kriittinen osa yrityksen tietoturva-asennetta.

Jos järjestelmät ovat edelleen haavoittuvia, taustalla on luultavasti joitakin toiminnallisia ongelmia, jotka pitäisi ratkaista. Shellshock on hyvin vanha haavoittuvuus, johon on saatavilla korjauksia lähes kaikkiin järjestelmiin. Paras tapa suojautua tämäntyyppiseltä haavoittuvuudelta on pitää järjestelmät ajan tasalla ja soveltaa kaikkia tähän haavoittuvuuteen julkaistuja korjauksia.

Varallisuuden korjaamisessa, joka on tyypillisesti suoraviivainen prosessi, kannattaa omaksua strateginen lähestymistapa.

Perusteellisesti testatut korjaukset ovat loistava keino minimoida liiketoimintahaitat – kuten esimerkiksi vanhalla käyttöjärjestelmällä toimivan kriittisen tärkeän palvelimen. Jos järjestelmää ei voida korjata välittömästi, haavoittuvuuden potentiaalista riskiä on punnittava suhteessa liiketoimintavaikutuksiin.

Shellshock on vain yksi haavoittuvuuksien pitkässä luettelossa, jota yrityksen on käsiteltävä. Haavoittuvuuksien loputtomalta tuntuvan virran hallinta on ja tulee aina olemaan kriittinen strategia, joka on kyberturvallisuuden perusta.

Tarkistuslista turvalliseen organisaatioon

Haavoittuvuuksien hallinnan onnistumiseksi yrityksillä on oltava valmiudet onnistua näillä kolmella alueella:

  • Mahdollisesti vaikuttavien haavoittuvuuksien tunnistaminen nopeasti: Nopeus on tässä kaikki kaikessa. Kun kaikki ovat samalla sivulla vankan suunnitelman kanssa, reaktioaikojen pitäisi olla nopeampia.
  • Haavoittuvuuden vakavuustason määrittäminen: Organisaation riskinsietokyvyn tunteminen auttaa määrittämään, kuinka vakava haavoittuvuus voi olla. Verkkoinfrastruktuuristasi riippuen jotkin haavoittuvuudet ovat haitallisempia kuin toiset.
  • Toimintasuunnitelma, jossa tasapainotetaan turvallisuuden kiireellisyys ja mahdolliset vaikutukset tuotantoympäristöihin: Turvallisuuden, tuotannon ja tuottavuuden yhteensovittaminen on jatkuva este, mutta organisaatiot, joilla on tarkimmin määritellyt suunnitelmat haavoittuvuuksien hallintaan, löytävät yleensä parhaan tasapainon.

Riippumattomalle tietoturvatutkija Rod Sotolle Shellshockin suurin opetus oli, että internet perustuu moniin haavoittuvuusalttiisiin sovelluksiin, ja se sisältää aina potentiaalin vaarantaa suuren osan sen segmenteistä.

Tapa hallita näitä potentiaalisia haavoittuvuuksia tulevaisuudessa on pitää kommunikaatio avoinna ja läpinäkyvänä ohjelmistojen kehittäjien, ylläpitäjien ja tietoturva-asiantuntijoiden välillä, Soto sanoo. ”Jos näin laaja ja merkittävä haavoittuvuus löydetään, kaikkien asianomaisten osapuolten välistä koordinointia voidaan käyttää asianomaisten järjestelmien korjaamiseen tai lieventämiseen.”

Silloinkin, kun yrityksesi onnistuu lieventämään Shellshockin tai minkä tahansa muun haavoittuvuuden aiheuttamaa riskiä, et voi olettaa, että reagointisuunnitelmasi on täydellinen. Reagointisuunnitelman tulisi olla elävä, hengittävä asiakirja, ja sitä tulisi tarkistaa usein, jotta organisaatiosi voi reagoida uhkiin nopeasti.

Loppujen lopuksi, kuten missä tahansa hyökkäyksen jälkeisessä skenaariossa, sinun tulisi esittää kysymyksiä, kun tarkastelet suunnitelman jokaista vaihetta.

  • Mitkä suunnitelman osat onnistuivat?
  • Mitkä suunnitelman osat eivät onnistuneet?
  • Mitä sellaista emme tehneet, jonka nyt ymmärrämme, että meidän piti tehdä?
  • Mitä opimme, jonka avulla voimme olla paremmin valmistautuneita seuraavaan haavoittuvuuteen, joka tulee tiellemme?

Shellshock voi olla vanha hyökkäys, mutta hyökkääjän kannalta se täyttää kaikki laatikot sellaisten uhrien hyväksikäyttöön, joilla ei ole asianmukaista turvallisuushygieniaa.

Vastaa

Sähköpostiosoitettasi ei julkaista.