37C3 - Writing secure software

[Translated by Santeri Koivisto (ITKST56 course assignment at JYU.FI)]
Musiikkia

Siitä on kirjoitettu oppikirjoja,

on pidetty lukematon määrä esitelmiä, jotka

ovat valistaneet meitä kaikista

tekemistämme virheistä, ja silti kaikenlaisia huonoja

ohjelmistoja on yhä olemassa, mutta

Fefe, täällä näin, sankarimme,

on ottanut huomioon kaikki parhaat

käytännöt, tiedättehän, työskennellessään

tehdäkseen turvallisen verkkosivun, hän

nyt seuraavaksi näyttää meille miten se tehdään, jotta

voimme kaikki nukkua yömme rauhassa ja

ottaa mallia, miten voimme

tehdä omat ohjelmistomme turvallisiksi.

Siispä annan puheenvuoron nyt

Fefelle, antakaa hänelle aplodit!

Suosionosoituksia

Kiitos, minun täytyy aloittaa

anteeksipyynnöllä, sillä ehdotin esitelmää,

mutta se hylättiin, joten

diat eivät ole ihan niin valmiita, kuin

niiden pitäisi olla.

Nämä diat on tehty esitelmän edellistä versiota varten, jotka pitävät

sisällään kaiken materiaalin, yritin päivittää niitä, mutta

se tuhosi sulavuuden, joten

joudumme pärjäämään tämän version kanssa.

Suurin ero on yleisö, sillä

odotan tällä kertaa paikalla olevan enemmän ohjelmistokehittäjiä,

toisessa yleisössä olisi ollut enemmän hakkereita ja

bisnesmiehiä, joten yritän auttaa heitä

nykyisestä tilanteestaan eteenpäin, ja pääkysymys

on yleensä: "Onko jo valmista?", eikö niin?

Joten, hieman minusta, olette varmaankin

nähneet tämän jo aiemmin, olen koodin tarkastaja

ammatiltani, omistan pienen yrityksen ja

yritykset näyttävät meille koodia, ja minä puolestani

näytän heille bugeja, jotka löydän, melko helppoa.

Mutta ennen kuin aloitamme, minulla on

himan syytä juhlaan, tämä oikeastaan tapahtui

vain päivää ennen kuin

puhuin siitä ensi kertaa, siis tämä viesti Kasperskyltä,

he löysivät haittaohjelman

liittyen libc:hen,

jota olen ollut kirjoittamassa, joten

tämä on...

Suosionosoituksia

Haittaohjelmaporukalla on

selvästi hyvä maku.

Niin, oikeastaan suurin kysymys, joka tulee vastaan kun

keskustelen asiakkaiden kanssa on: "käytämme todella paljon

rahaa tähän, miksei se toimi"?

Ja vastaus on, että "te toimitte väärin".

Yritän nyt siis näyttää, että mitä tarkalleen menee väärin

ja tässä on pieni johdanto: yleensä sanotaan,

ettei ole aikaa tehdä asioita

kunnolla, eikä se pidä paikkaansa lainkaan.

Aikaa päivässä on tasan yhtä paljon kuin kaikilla niillä,,

jotka ovat pystyneet suuriin saavutuksiin, joten

jokainen varmasti pystyy moneen, kunhan ryhtyy hommiin.

Pelataan sitten pientä lämmittelypeliä,

sen nimi on "miten se alkoi ja

miten nyt menee", aloitetaan siis harjoittelukierroksella:

"IBM:n Watson mullistaa

kymmenen toimialaa", ja nyt menee näin:

"Mitä kävi IBM:n Watsonille?". Kyseessä on

tyypillinen kuvio tietoturva-alalla.

Okei, tässä seuraava, näin se alkoi:

"Mullista tietoturva tekoälyllä",

no niin, emmeköhän kaikki tiedä, mihin tämä on menossa...

Naurua

Niin, sehän se kuvio on.

Pelataan IT-turvallisuuden miinaharavaa,

siis, kaikki täällä varmaankin

tuntevat Gartnerin, se julkaisee

suosituksia ja sillä on jopa

äänestysosio, jossa ihmiset voivat sanoa, että

"Tämä on paras tuote tähän tarkoitukseen",

joten vilkaistaanhan muutamaa ja

katsotaan, miten kävi niille, jotka luottivat Gartneriin.

Ensimmäisenä aiheena ovat palomuurit, siis:

näin se alkoi: ykkössijan suositus on

Fortinet, ja heillä on paljon

markkinointi- siansaksaa

Naurua

Ja jos taas katsotaan, miten nyt menee, niin

ei kovin hyvin.

Siis, jatketaan kuviota hiukan:

Mitä kävi minulle tämän suhteen?

En tarvitse palomuuria, koska

minulla ei ole yhtään porttia, jolle pääsy pitäisi estää, niinhän.

Joten sitä ei tarvita,

tarkasti ottaen sitä ei tarvita.

Seuraava ala: päätepisteiden suojaus,

se alkoi siis Trellix:llä, se on

Gartnerin ykkössuositus.

En ollut kuullu siitä,

joku yhteishanke tai jotain sellaista,

ketä kiinnostaa.

Heilläkin on hienoa markkinointi- siansaksaa

Ja jos katsotaan, mitä tapahtui:

se pahensi vain asiaa.

Okei, tämäkään ei vaikuta minuun,

koska en käytä humpuukkituotteita.

Katsotaanhan, kolmanneksi salasananhallintaohjelmistot,

myöskin hyvin suosittuja,

miten se alkoi: suositeltiin LastPassia,

tiedätte varmaan mihin tämä on menossa...

Naurua

Jep, se hakkeroitiin

ja monet joutuivat ongelmiin.

Voitte siis huomata kuvion:

tämäkään ei vaikuttanut minuun, koska

poistin käytöstä salasanatunnistautumisen ja

käytän julkisen avaimen menetelmiä, jotka ovat

olleet jo vuosikymmeniä saatavilla. Pieni bonus,

viimeinen näistä: kaksivaiheinen tunnistautuminen,

Gartner suosittelee Duoa, jonka

Cisco on ostantut tosin omakseen, mutta sillä ei ole väliä.

Katsotaan siis, mitä Duo tekee:

palvelimesi pyytää pilvipalvelusta

lupaa, pilvipalvelin näyttää

puhelimella ilmoituksen, josta painetaan "kyllä",

ja pilvipalvelu kertoo palvelimelle:

"okei, voit päästä sen sisään". Jos katsot

oikein tarkkaan, huomaat, ettei pilvipalvelun

ole pakko näyttää ilmoitusta ollenkaan, se voi vain

sanoa suoraan "kyllä". Se on siis valmiiksi

ongelmainen, mitään ei tarvitse edes hakkeroida.

Naurua

ja harva tajuaa, että

kaksivaiheista tunnistautumista ei tarvita,

jos käyttää julkista avainta, se on jo itsessään toinen vaihe.

Selvä, niin,

jep. Vilkaistaan tämä nopeasti.

Splunk on suositeltu vaihtoehto

ja se tekee organisaatiosta

kestävämmän, kunhan sitä ei asenna.

Naurua

Suosionosoituksia

Okei, tämä aihe on lähellä sydäntäni,

sillä usein väitellään siitä,

pitäisikö paikkauksia asentaa ja

mitkä paikkaukset asentaa ensimmäiseksi ja aiemmin

tämä oli yksinkertaista, etsittiin ongelmia

ja asennettiin paikkauksia, mutta sitten

asioista tuli monimutkaisempia ja

tulos oli tämä -

kuuluisa podcasti Saksassa,

joka kertoo kunnasta, joka joutui

kiristysohjelmahyökkäyksen uhriksi ja joutui kutsumaan

armeijan apuun

Epäselvää puhetta yleisössä

Ja mitä pitäisi tehdä, sanon tämän

täydellisyyden vuoksi, asentaa kaikki paikkaukset

välittömästi, mutta se jääköön toisen esitelmän aiheeksi.

Saatatte siis huomata kuvion:

IT-turvallisuusala

suosittelee jotakin

ja jos suositukseen uskoo, on pian kusessa, joten ei kannata.

Jos ette näe kunnolla, tässä lukee "käärme-

karkoterakeet", ja sen vieressä

nukkuu käärme.

Naurua

Yskäisy

Niin, jos emme voi luottaa

alan suosituksiin, niin mitä pitäisi tehdä?

Ja minulla oli paljon

aikaa, koska minun ei tarvinnut

siivota kehnojen IT-turvallisuusalan

suositustuotteiden jälkiä, joten

mihin kulutin aikaani?

Päätin, että tarvitsen blogin

jo jonkin aikaa sitten, ja aloin

miettimään, mitä tarvitsen,

itse asiassa ei kovin paljoa, koska olisin

voinut vain tarjota staattista sisältöä ja pieni

hakutoimintokin olisi hyväksi, muttei kuitenkaan

pakollinen. En tarvinnut kommentteja

laillisista syistä, koska ihmiset tapaavat

lähetellä linkkejä haittaohjelmiin ja

mitä lie, mitä en halua,

joten ensimmäinen versio oli

oikeastaan hyvin helppo toteuttaa, se oli pieni

tavanomainen verkkopalvelin ja

blogin julkaisut olivat staattisia HTML-tiedostoja,

yksi tiedosto kuukautta kohden. Se oli oikeastaan

helppoa, jos haluaa hakea joitain voi vain

kysyä Googlelta rajoittaen haun kyseiseen verkkosivuun.

Julkaiseminenkin oli helppoa, minulla oli pieni

skripti, jonka pystyin ajamaan palvelimella

ja kirjauduin SSH:lla, ja SSH:n luotan

autentikaation suhteen, joten uutta

pintaa hyökkäyksille ei ole, käytin sitä muutenkin. Tämä on

mahtava kokonaisuus, se on turvallinen ja yksinkertainen,

riskit ovat pieniä ja se on suorituskyvyltään

erinomainen, mutta sitä ei voisi pitää esitelmää

CCC:ssä, koska

se on liian tylsä, joten aloin lisäämään

riskejä kokoonpanoon.

Naurua

Joten ensimmäinen ideani oli, että

olin kirjoittanut pienen web-palvelimen ja voisin

vain käyttää blogia vareten kyseistä palvelinta,

koska sehän on minun koodiani joka tapauksessa,

mutta siinä on huonoja puolia. Jos blogi

pyörii web-palvelimella, sillä on

pääsy kaikkeen web-palvelimen muistiin,

erityisesti se pääsee käsiksi TLS:n salaiseen

avaimeen, enkä halua, että sitä saataisiin

vietyä, joten se ei voi olla

web-palvelimen moduuli

ja ilmiselvä ratkaisu on, että

sen täytyy pyöriä toisella käyttäjä-ID:llä

Linuxilla, käytän siis Linuxia, mutta minkä tahansa

Unixin tai Windowsin suhteen asia olisi sama.

Se siis pyörii eri käyttäjällä,

ja jos sitten kaappaa

blogin prosessin jonkin

bugin avulla, TLS-avaimeen ei pääse käsiksi.

Ja samaan aikaan kun tein sitä,

ala teki tätä.

Puheensorinaa

Sehän on tämän esitelmän virsi,

näytän kaikenlaista kiinnostavaa,

mitä ala tekee, ja sitten näytän,

mitä itse tein siinä samalla.

Seuraava kysymys:

Missä sisältöä säilytetään? Voisin vain pitää

tiedostoja levyllä staattisena HTML:nä kuten aiemminkin,

mutta uskon, ettei se ole riittävän ammattimainen ratkaisu.

Hyvää CCC-esitelmää varten täytyy

olla ammattimaisempi.

Olin myös toista

projektia varten kirjoittanut LDAP-palvelimen,

joten päätin uudelleenkäyttää sitä, ja

samalla kuin tein sitä, ala teki tätä.

Otin tämän kuvan Jerusalemin

lentokentällä, tämä on siis oikea mainos

eikä photoshopattu. Sen omistaa

Northrop Grumman, joka on

armeijatavarantoimittaja ja se kertoo koko

spektrin kyberistä, kattaen kaikki alueet.

Puheensorinaa

Siis, miksi kirjoittaisin oman LDAP-palvelimeni?

Pääasiassa siksi, että se on pieni ja

koska olen ammatiltani tarkastaja, ja tiedän,

että jos haluaa mahdollisuuden oikeasti

tarkastaa koodia, sen täytyy olla vähäistä,

sillä rajallinen resurssi on

aika, jota voi käyttää koodin tarkastamiseen.

SIis, Postgres on yleinen SQL-

tietokanta. Slapd on palvelimen

avoin LDAP-toteutus ja tinyldap on

omani ja näette, että se on paljon hitaampi

ja paljon pienempi.

Niin, mainoskapanja oli laajempi

keräsin tähän muutamia hauskoja kuvia.

Siis, jos joku onnistuu

hakkeroimaan blogin CGI:n tai mitä hyvänsä moduulia

käytänkään yhdistääkseni blogin

verkkopalvelimeen, hän pystyy avaaman minkä tahansa tiedoston, jonka

blogi itsessään pystyy lukemaan, jonka sen UID pystyy lukemaan,

joten minun pitäisi varmaankin tehdä

asialle jotakin, se oli seuraava vaihe.

Ala puolestaa alkoi miettimään

haavoittuvuuksien hallintaa.

Unixilla, Linuxilla on mekanismi,

josta pidin erillisen esitelmän

viime Kongressissa,

se on nimeltään seccomp ja seccom on kuin

palomuuri järjestelmäkutsuille, joten voin käyttää

seccompia estääkseni open-järjestelmäkutsun, jota käytetään

tiedostojen avaamiseen, mutta jos minun täytyy

itse käyttää open-funktiota,

en voi estää sitä, joten mitä

tehdä sen suhteen? Esimerkiksi blogini

kutsuu localtime-funktiota, joka muuttaa Unix-ajan

paikallisen aikavyöhykkeen ajaksi ja sitä

varten se avaa tiedoston, joka sisältää

kuvauksen järjestelmän aikavyöhykkeestä,

ja se kutsuu openia. Siis,

jos ottaisin vain open-järjestelmäkutsun pois käytöstä

blogistani, niin se ei voisi tehdä

tarvittavaa aikamuunnosta, mikä on

oikeastaan vanha ongelma, joka pätee myös

setuid-ohjelmiin ja on pätenyt niihin jo

vuosikymmeniä, joten voi tehdä niin, että

koodi järjestetään uudelleen siten, että ennen kuin

estää tai, yleisesti ottaen, pudottaa oikeuksia,

ensin tehdään open-kutsut,

tässä esimerkissä, ja

sitten poistetaan open käytöstä ja sitten katsotaan

hyökkääjän tarjoamaa dataa,

koska jos hyökkääjä tai mikä tahansa lähde,

johon ei luoteta, yrittää hakkeroida palveluasi, se tapahtuu

palvelullesi annetun datan avulla,

ympäristö on vaarannettu, joten katsotaan,

minkälaiset elementit ympäristössä

hyökkääjä voi määrätä ja

enne kuin koskee yhteenkään tavuun niistä, täytyy

tehdä kaikki vaaralliset toimenpiteet, jos vain voi.

Siis, tässä tapauksessa, kutsun localtime-funktiota

kerran ennen kuin pudotan pois open-järjestelmäkutsun,

ja libc tallentaa välimuistiin

aikavyöhykedatan ja ensi kerralla, kun kutsun sitä

sen jälkeen, kun olen käsitellyt hyökkääjän

määrittelemää koodia, ei ole enää tarvetta käyttää

open-funktiota. Tämä on suuri etu

seccomp:n hyödyksi ja muita vastaavia teknologioita,

kuten SELinuxia, vastaan, sillä ne asettavat

estot järjestelmäkutsuille

koko prosessin tasolla, joten tämä

olkoon esimerkkinä siitä, mitä

pitäisi tehdä: Pitäisi katsoa

prosessia ja, ainakin jos on

pääsy lähdekoodiin, pitää katsoa, mitä

kaikkea täytyy tehdä ennen kuin voin

luopua oikeuksista, ja siirtää niitä aiempiin vaiheisiin.

Näin siis tein.

Tämä tässä on malli

Viron kyberturvallisuuskeskukselta,

tämäkin on siis aito.

Okei, siis,

seuraava aihe. Sanotaan, että

joku hakkeri blogimoduulin, ja

että joku toinen käyttää samaa moduulia, mutta

omaa salasanaansa.

Tämä on yleinen ongelma verkkosivuilla,

joilla on jonkinlainen kirjautumistoiminto,

josta saa jonkinlaisen istuntotunnisteen tai

jonkin vastaavan, ja jos joku onnistuu

kaappaamaan väliohjelmiston

tai palvelinkomponentin,

hän pystyy näkemään kaikki muutkin yhteydet,

jos sama prosessi käsittelee niitä.

Se on siis merkittävä ongelma,

jonka voi korjata, mikä

on meille varsin hyvä asia.

Ja minun esimerkissäni tämä sai minut käyttämään CGI:tä

FastCGI:n sijaan, FastCGI on siis

uudempi versio CGI:stä,

ja sen idea on, ettei

uutta prosessia käynnistetä jokaista

pyyntöä varten, vaan käytetään Unix domain

socketia, tai muuta pistoketta FastCGI-prosessiin,

joka avaa ehkä yhden säikeen

pyyntöä kohden tai jotain sellaista, mutta yleensä

FastCGI:n kanssa yritetään käsitellä

pyynnöt samassa prosessissa, jotta

voidaan käyttää kyseistä prosessia välimuistin ylläpitoon,

joten FastCGI on suorituskyvyn kannalta edullinen valinta,

mutta tietoturvasyistä en

käytä FastCGI:tä, joten en voi käyttää

välimuistia, mikä on merkittävä haittapuoli

ja blogista tulee lopulta luultavasti

todella, todella hidas. Siis,

ensiksi, minun täytyy käyttää CGI:tä

FastCGI:n sijaan ja toiseksi, on yhä mahdollista

käyttää debuggaukseen tarkoitettuja API:ta. Siis, jos käyttää GDB:tä tai

jotain muuta debuggeria toisen

prosessin seurantaan, se käyttää ptrace-API:ta,

mutta se on pohjimmiltaan järjestelmäkutsu, joten voin käyttää seccompia

ptracen kieltämiseksi. Jos noudatan näitä kahta taktiikkaa, ja

hyökkääjä kaappaa blogin prosessin, kaikki

mitä hän voi nähdä, on hänen itse lähettämänsä data.

Kysessä on siis suuri etu.

Okei, ENISA on itse asiassa EU:n virasto,

mikä on mielestäni hyvin häiritsevää,

sillä se kuluttaa paljon veronmaksajien rahoja,

mutta ei siitä sen enempää. Oletataan, että hyökkääjä

pystyy hakkeroimaan blogini. Silloin tämä pystyy kiertämään

kaiken pääsynhallinnan, jota blogissani käytetään.

Siis esimerkiksi, jos minulla on ylläpitosivu tai

jokin kirjautumista vaativa osa verkkosivusta,

ja sitä hallitsee sama ohjelma, ja

pääsynhallintaa tehdään siis blogin

CGI:ssä, ja joku onnistuu

hakkeroimaan blogini CGI:n, hän voi

halutessaan vain ohittaa hallinnan, joten on

hyvin haastavaa tehdä pääsynhallintatoimenpiteitä, joita ei ole

mahdollista kiertää, jos ne toteuttaa omassa

koodissaan. Ratkaisu on siis olla tekemättä sitä

omassa koodissasi. En rajoita mitenkään

pääsyä omassa blogissani, vaan teen sen

LDAP-palvelimen puolella. Jos siis yhdistää blogiini

ja antaa salasanan, blogi itse ei tiedä,

onko salasana oikein

vaiko väärin. Esimerkiksi, jos

on käyttöliittymä, jonka avulla voi lisätä

uusi blogijulkaisuja tai muokata vanhoja

sellaisia ja sitä varten täytyy tunnistautua,

mutta blogin CGI ei tiedä, ovatko tunnukset

oikein vai väärin ja avaa

yhteyden LDAP-palvelimeen käyttäen

annettuja tunnuksia ja vasta LDAP-palvelin

sanoo kyllä tai ei. Koska estimme pääsyn

ptrace-järjestelmäkutsu ja prosessit

on eristetty toisistaan, se tarkoittaa,

ettei mitään jää kierrettäväksi.

Siis, jos joku hakkeroi blogini,

hän ei juuri hyödy, koska

hän voi käytännössä tehdä vain samoja asioita

kuin jo valmiiksi. Hän voi vain kommunikoida

LDAP-palvelimen kanssa.

Jes, nyt aletaan jo puhua

James Bond -tason jutuista

hyökkäyksien monimutkaistuessa entisestään.

Samalla IT-turvallisuusala innostui

uhkatiedustelufiideistä, jotka

ovat täysin turhia. Älkää käyttäkö niihin rahaa.

Sanotaan siis, että hyökkääjä hakkeroi

blohini ja siirtyi tinyldapin pariin ja

nyt siis hyökkää tinyldapiin. Silloin hän pystyykin

pääsemään käsiksi toisiin tileihin, koska tinyldap

käsittelee myös yhteyksiä toisiin blogin ilmentymiin,

joten ongelma on sama kuin aiemminkin,

maaliviivaa on vain siirretty

hieman eteenpäin. Tämä täytyy estää,

ja itsestäänselvä ratkaisu on

tehdä sama homma kuin blogin kanssa

ja käyttää yhtä LDAP-palvelimen prosessia

pyyntöä kohden, ja sitten vain kiellämme

ptracen käytön. Siis, enää ei ole mahdollista

nähdä, vaikka pystyisikin ajamaan mielivaltaista koodia

LDAP-palvelimen sisällä, ei olisi siis mahdollista nähdä,

mitä salasanoja toiset käyttäjät käyttävät.

On siis yhä mahdollista nähdä-
Okei, ala tekee

taas jotain hevonpaskaa. On yhä mahdollista nähdä

salasana LDAP:n muistista, koska

LDAP-palvelimella täytyy olla tallessa versio

salasanasta, jota vastaan salasanoja voi tarkistaa ja

alan käytäntö, paras käytäntö, on

käyttää suolattuja (salted) tiivisteitä, joten itse salasanaa

ei olekaan muistissa ollenkaan.

Silti, jos joku onnistuu hyökkäyksessä

tinyldapia kohtaan blogin kautta, hän pystyy

varastamaan tiivisteet ja yrittämään niiden murtamista,

mutta koska olen ainoa, joka lisää käyttäjiä,

voin vapaasti hallita salasanojen turvallisuusvaatimuksia,

joten onnea vaan väsytyshyökkäyksen kanssa.

Okei, tämä on oikeastaan aito ongelma,

ei kuitenkaan nimenomaan blogini suhteen

vaan toisten verkkopalvelujen tai siis

kaikkien palvelujen, joihin voi yhdistää internetin kautta:

Mitä jos hyökkääjä ei haluakaan varastaa

dataa, vaan salata sen?

Kyseessä on siis kiristysohjelma. Mitä sille voi

siis tehdä? Minun ideani oli tallentaa

data lukumuistiin, siis

LDAP-palvelimella on muisti, joka sisältää

kaikki blogimerkinnät ja se on saatavilla vain luettavaksi

LDAP-prosessille. Sitä voi vain lukea,

ja jos siihen haluaa kirjoittaa,

jos esimerkiksi pitää lisätä uusi merkintä,

se lisätäänkin toiseen tiedostoon, jota

kutsun journaliksi. SQL-tietokannoille on käytössä

vastaava idea, ja sitä käytetään transaktioiden

kumoamiseen. Voin tehdä samoin,

kyseessä on periaatteessa lokitiedosto,

mikä tarkoittaa, että kaikki muutokset

viime kerrasta, kun muisti,

lukumuisti, luotiin, kaikki eroavaisuudet

tallennetaan peräkkäin lokitiedostoon,

eli journaliin. Suorituskyky

huononee sitä mukaa, kun journal kasvaa,

joten silloin tällöin täytyy yhdistää

lukumuistiosio ja journal

uudeksi, isommaksi lukumuistiosioksi ja

sen teen itse manuaalisesti,

koska tinyldap ei pystyisi siihen,

koska siltä on kielletty muistiin kirjoittaminen.

Sehän oli osa turvallisuusmekanismia.

Käyttäen seccompia voin vain poistaa käytöstä

järjestelmäkutsuja, voin asentaa suodattimia, joten

voin siis sanoa, että open on sallittu toimenpide, mutta vain, jos

käyttää O_APPENDia. O_APPEND Unixin open-järjestelmäkutsun

yhteydessä tarkoittaa, että jokainen muutos, jonka

tiedostonkuvaukseen tekee, tallentuu automaattisesti

aina loppuun. Siis, jos tiedän, että jos joku

onnistuu pääsemään käsiksi tinyldapin

binaaritiedostoon ja pystyy sen avulla kirjoittamaan journaliin, niin

ainoa paikka, johon muutoksia voi tehdä,

on aivan tiedoston lopussa, mikä on oikeastaan

todella hyvä asia, sillä se tarkoittaa, että

jos joku saattu hakkeroimaan minut ja lisää roskaa

blogiini, voin vain poistaa palan lopusta ja

tilanne on sillä selvä. Jos tätä verrataan

tavanomaiseen SQL-tietokantaa, jos silloin joku kirjoittaa

tietokantaan, muutosten kumoamiseksi täytyy ladata

varmuuskopio, koska mikä tahansa

on saattanut muuttua missä tahansa.

Tinyldapilla ei kuitenkaan ole edes

pääsyä tiedostojärjestelmään eikä se siis pysty

muuttamaan mitään muistin sisältöä, joten

voin palata rauhassa nukkumaan.

IT-turvallisuusala tuhlasi rahaa

kyberturvallisuusverkostoarkkitehtuuriin.

Jep. Journalin päivitys on asia,

joka minun täytyy manuaalisesti tehdä kaistan ulkopuolisesti.

Se ei siis ole mikään automaattinen prosessi,

koska teen sen manuaalisesti ja

kun teen sen,

dataahan ei ole paljoa, vain viikon

tai parin ajalta, voin vain lukea sen

läpi ja tarkistaa, että kaikki näyttää

siltä, miltä pitäisi. Tämä ei välttämättä ole vaihtoehto

kaikissa muissa skenaarioissa, mutta on tärkeää

ymmärtää, että vaikka dataa on enemmän,

kaikkea dataa ei yleensä olekaan paljoa enempää.

Suurin osa sisällöstä on muuttumatonta lukusisältöä,

ja lisäksi on joitain lokitiedostoja, joihin

lisätään jatkuvasti dataa ja jotka kasvavat kasvamistaan,

mutta yleensä on olemassa osa datasta,

osa, johon siis...

henkilötiedot kuuluvat, kuten myös

laskutustiedot ja tämä data on yleensä

määrältään vähäistä ja siihen voidaan

soveltaa samaa strategiaa.

Jaa, no niin.

Hyökkääjä voi siis yhä kirjoittaa roskaa

blogiini, mikä ei ole ideaalinen tilanne,

mutta koska kaikki, mitä tämä voi tehdä, on lisätä

dataa journalin loppuun, voin käyttää tekstieditoria

ja avata journalin sekä rajata sen sisällön johonkin kohtaan.

Saan siis datan palautettua

tilanteseen, jossa blogia alettiin saastuttamaan.

Tilanne ei ole ideallinen,

mutta kuitenkin hyvä hätätapauksien kannalta,

koska on mahdollista

tutkia tilannetta ensin rauhassa.

Ensin poistetaan käytöstä kirjoitusoikeudet,

sitten vandalismi poistetaan journalista,

ja tässä kohtaa voidaan olla varmoja, ettei mitään ole menetetty,

koska jos blogista haluaa poistaa merkinnän,

sekin on mahdollista, mutta se tarkoittaa käytännössä,

että journalin loppuun lisätään

merkintä, joka sanoo "tämä tieto

poistetaan", ja tämän merkinnän voi vain poistaa,

jolloin poistettu tieto saadaan takaisin. Ei siis ole

mahdollista vandalisoida mitään blogin

dataa, joka oli siellä ennen vandalisointia.

On mahdollista ainostaan lisätä loppuun roskaa,

ja tämän mahdollisuuden kanssa jo pärjätään.

Pitäisi olla johtavana ajatuksena

kaiken turvallisuuden lomassa, että

jos joutuu hakkeroinnin uhriksi, tilanne on

hyvin stressaava, pomo tulee olemaan

olan takana hengittelemässä niskaasi kyselemässä, että

"Onko jo valmista?" ja että "Onko se nyt korjattu?", ja sillä hetkellä

tulisi olla mahdollisimman vähän asioita, joista huolehtia.

Kaikki stressi kannattaa siirtää

hakkerointia edeltävälle ajalle, koska

silloin aikaa on enemmän.

Okei, ala teki taas kaikenlaista.

Siis, entä jos hyökkääjä ei kirjoitakaan

roskaa journaliin, vaan kirjoittaa jotain

haitallista journaliin, joka aiheuttaa sen,

että kun jokin tinyldap-ilmentymä lukee sitä

seuraavan kerran, ilmentymä joutuukin vaarannetuksi.

Se on mahdollisuus, joka on

meille hyvin epäedullinen,

mutta on tajuttava, kuinka uskomaton skenaario

on kyseessä. Nyt puhutaan hyökkääjästä,

joka on löytänyt vakaan nollapäivähaavoittuvuuden blogista,

ja käyttänyt sitä sekä toista

vakaata nollapäivähaavoittuvuutta tinyldapissa kirjoittaakseen journaliin,

ja käyttänyt vielä

kolmatta nollapäivähaavoittuvuutta journalin

lukukoodia vastaan. No,

kyllä, kyseessä on yhä ongelma, mutta

riskiä on vähennetty merkittävästi.

Tämä on juuri sitä,

mitä yritän sanoa:

kyseessä ei ole kaikki tai ei mitään -tilanne. Riittää,

että riski saadaan puolitettua, se on jo hyvin

tärkeää ja sitä pitäisi tehdä aina,

kun on mahdollista: Mitä enemmän riskiä saa kavennettua,

sitä paremmassa tilanteessa ollaan,

kun käy huonosti.

Koska mitä pienempi määrä koodia,

jota kohtaaan voi yhä hyökätä, on,

sitä paremmin tätä koodia voi tarkastaa ja varmistua,

että koodi on kunnossa. Koodia voi näyttää ystäville ja

hekin voivat tarkastaa sitä. On ehdottoman tarpeellista,

että tätä aikaa säästetään, koska

silloin tällöin käy niin, että pääsen

näkemään koko koodikannan, ja

tavanomainen koodikanta kaupallisille

tuotteille koostuu gigatavuista lähdekoodia.

Kukaan ei pysty lukemaan sitä kokonaisuudessaan.

Olen hyvä työssäni, mutten aivan niin hyvä.

Siis, tämä on hyvä tilanne.

IT-turvallisuusala taisi myydä suojausta

hajautettuja palvelunestohyökkäyksiä kohtaan, juu, niinpä niin.

Mitä siis tapahtuu, jos joku hyökkää verkkopalvelinta kohtaan?

Kyseessä on edelleen suuri ongelma.

Pahinta on siis

täydellinen vahinko, eikö niin?

Se on pahin mahdollinen asia, mitä voi tapahtua

jos joku onnistuu hyökkäyksessä verkkopalvelinta kohtaan.

Hyökkääjä näkee kaiken kulkevan verkkoliikenteen,

hän pystyy vakoilemaan TLS-suojattuja

yhteyksiä ja nuuskimaan sieltä

salasanoja, mikä on todella huono homma.

Valitettavasti ei ole paljoakaan,

jota asialle voisi tehdä.

Olisi mahdollista tehdä jako,

mikä on asia, josta on puhuttu

jo hetken aikaa OpenSSL:n suhteen. Se tarkoittaisi, että

OpenSSL tekee kaiken riskialttiin kryptografian

toisessa prosessissa, ja käyttää

hiekkalaatikkoa kyseisen prosessin rajoittamiseen.

Se olisi mahdollista, mutta kukaan ei ole toteuttanut sitä vielä

OpenSSL:lle, OpenSSL ei siis

tue sitä. Verkkopalvelimeni

tukee myös Mbed TLS:ää, mitä OpenSSL ei tue.

Voisin käyttää tähän aikaa,

ja itse asiassa olenkin

jo käyttänyt siihen aikaa, mutta

se ei ole vielä valmista. Se olisi

hyvä tapa vähentää riskiä. Saatatte

huomata, että työkalut, joita käytän

riskin vähentämiseen ovat vain muutamia samoja.

Se ei ole mitään noituutta.

En keksi uusia tapoja tarkastella asioita.

Teen vain samoja asioita

uudelleen ja uudelleen. Tunnistan sen osan koodista,

joka on vaarallinen, ja sen jälkeen

mietin, miten voisin pienentää kyseistä

osaa koodista tai ehkä siirtää sen toiseen

prosessiin, jota rajoitetaan. Sama täytyy

tehdä myös verkkopalvelimelle,

tietenkin, mutta prosessi on kesken.

Jep, jälleen, niinpä niin.

Miksen ole siis tehnyt sitä vielä?

Verkkopalvelimessani on koodia kääntäessä tehtävä

päätös, halutaanko SSL-tukea vaiko ei.

Näemme, että binaaritiedosto on

huomattavasti suurempi SSL:n ollessa käytössä.

Näytän tämän, koska se merkitsee,

että hyökkäyspinnasta suurin osa on SSL-koodissa,

ei siis minun koodissani. Jos siis voin

siirtää SSL-koodin toiseen prosessiin,

salaisen avaimen tulee silti olla näkyvillä,

koska sitähän TLS tarvitsee,

salaista avainta siis, muutoin se ei pysty

tarvittavaan kryprografiaan. Suurimmalla osalla

hyökkäyspinnasta olisi siis yhä pääsy avaimiin,

voisin tehdä sen silti, koska

omassa kodissani saattaa olla bugeja

SSL-koodin sijaan, mutta se on vain 5%

koko hyökkäyspinnasta, joten

teen sen luultavasti jossain vaiheessa, mutta

on turhaa odottaa mitään ihmeitä.

Bugit OpenSSL:ssä koituvat vielä kuolemakseni,

sille en voi oikeastaan mitään.

Naurua

Okei, tiedän siis mitä ajattelette:

Voimakasta naurua

entä bugit käyttöjärjestelmän ytimessä?

Katsoin siis muutamia viime aikaisia

ytimen bugeja ja kävi ilmi, että

ne yleensä tapahtuvat järjestelmäkutsuissa, joita

harvoin käytetään tavallisissa ohjelmissa. Koska rajoitan

kaikki järjestelmäkutsut, joita en oikeasti

tarvitse, yksikään bugeista ei koske minua.

Tämähän on yleinen kuvio

ytimen bugien suhteen.

On olemassa projekti nimeltä Sandstorm,

joka käyttää ptracea ja seccomp-seurantaa

järjestelmäkutsujen hyökkäyspinnan

vähentämiseksi ja laittaa tavalliset palvelut

verkkopalveluille tarkoitettuun hiekkalaatikkoon, ja tämä

auttaa kiertämään kaikenlaisia ytimen bugeja

itsessään, kyseessähän on siis

asia, jota varten ei tarvitse paljoa työskennellä,

tietenkin, jos käytössä on lista järjestelmäkutsuista,

niin käytetään valkoista listaa,

pidetään yllä listaa asioista,

jotka ovat erikseen sallittuja,

eikä toisin päin.

Yksikään tavanomainen ytimen bugi ei siis kosketa

minua, koska hyödynnän seccompia.

Ytimen bugit eivät ole yhtä iso

ongelma kuin olettaisi. Ne ovat yhtä

ongelmassa, ellen ole paikannut niitä,

mutta blogin kautta niihin ei pääse käsiksi.

Minulla on pieni tunnustus:

Olen pieni trolli ja se vaikutti

myös tähän projektiin, käytin siis

huonointa ohjelmointikieltä, C:tä.

Trollaan siis turvallisuusporukkaa

ja trollaan myös Java-porukkaa,

joka väittää, että tulisi käyttää

monisäikeistystä parantamaan suorituskykyä eikä

yhtä prosessia pyyntöä kohden,

käytän siis kahta fork- ja exec-kutsua

jokaista pyyntöä kohden.

Trollaan tietokantaporukkaa,

en käytä välimuistia,

en käytä connection poolia

ja myös suorituskykyporukkaa, koska

ratkaisuni on kaikesta huolimatta nopeampi kuin suurin osa

tavanomaisista ratkaisuista, joten ohjelmiston

suunnittelemisessa tällä tavoin ei ole juuri

huonoja puolia,

ratkaisu on muita vaihtoehtoja hitaampi,

mutta suurin osa muista ohjelmistoista ei kuitenkaan

ole yhtä nopeita, joten etumatkaa on riittävästi,

jotta voi keskittyä turvallisuuteen

suorituskyvyn sijaan ollen silti nopeampi.

Kerrataan vielä käyttämäni metodologia.

Ensimmäiseksi teen listan kaikistä hyökkäyksistä,

joita voin kuvitella, ja tällä tarkoitan

konkreettisia hyökkäyksiä, jotka voisivat tapahtua,

ja ongelmista,

jotka niistä seuraisi.

Jokaista listan kohtaa kohden

mietin: "miten tämän voisi estää?",

"voinko estää tämän?" ja "mitä estämiseksi on tehtävä?".

Sen jälkeen teen, mitä pitää, helppoa.

Tämä muistuttaa Feynmanin ongelmanratkaisualgoritmia

hengeltään. Tätä prosessia kutsutaan

uhkamallinnukseksi.

Se on kuin kirosana, koska kuulostaa

siltä, että siinä on kova työ

eikä kukaan halua tehdä sitä, mutta tosiasiassa

se on helppoa, pitää vain noudattaa näitä askelia.

Ohjelmistoa tutkitaan ja

mietitään, millä kaikilla tavoilla sitä kohtaan voisi hyökätä.

Sitten harkitaan, miten

hyökkäys voitaisiin estää tai toisinaan,

voitaisiinko sitä estää ollenkaan

ja jos ei, riskin kanssa on selviydyttävä.

Tätä kutsutaan siis uhkamallinnukseksi,

sitä kannattaa kokeilla, se on mahtavaa.

Näitte, että yritin

optimoida jotain tiettyä,

tavoittelin jotain, tässä tapauksessa

mahdollisimman vähäistä määrää koodia.

Mitä enemmän koodia on, sitä enemmän bugeja

siinä on. Kyseessä on vanha

oivallus, muistaakseni alun perin

IBM:n tutkimuksesta, jossa saatiin selville,

että koodissa olevien bugien määrä on

koodirivien määrän funktio.

Asia ei oikeasti ole aivan näin simppeli,

mutta pohjimmiltaan tämä on totta. Ei puhuta

mistä tahansa koodista, jonka määrä halutaan minmoida,

jos koodi on vaarallista, haluan erityisesti

vähentää sen määrää ja tärkein

kategoria, jota pienentää, on

turvallisustakuita yllä pitävä koodi.

Turvallisuustakuu on

esimerkiksi se, että on mahdotonta kirjautua

ilman oikeaa salasanaa.

Haluan tällaisia asioita tarkastavaa koodia

olevan niin vähän kuin mahdollista, ehkä yksi tai kaksi

riviä koodia, jos vain mahdollista,

jolloin on selkeää, onko koodi tehty oikein vai

väärin. Mitä monimutkaisempi ohjelmakoodi on,

sitä vaikeampaa on varmistua,

onko se tehty oikein vai ei. Sehän on

haluttu lopputulos, varmuus sitä, että

koodi on oikein. Kuinka pitkälle siis pääsin?

Tulokset ovat mielestäni melko hienot.

LDAP-palvelimen voi kirjoittaa 5000 koodirivillä,

itse blogi koostuu 3500 koodirivistä,

plus LDAP-asiakaskirjasto,

plus zlib,

mutta käytän zlib:tä vain pakkaamiseen enkä

purkamiseen, joten suurin osa hyökkäysskenaarioista

ei koske minun zlib-käyttöäni.

Verkkopalvelin on melko hidas,

jos keskitytään pelkkään HTTP-koodiin,

se valitettavasti sisältää myös

SSL-kirjaston, joka on useita suuruusluokkia

omaa koodiani isompi, ja tämähän on haluttu tilanne.

Suurimman riskin ei tulisi olla

uudessa koodissa, vaan vanhassa koodissa,

jonka joku muu on jo tarkastanut,

mikäli vain mahdollista. Tämä on

siis optimisaatiostrategia, yritä minimoida

vaarallisen koodin määrä, mikä kuulostaa

helpolta jutulta, mutta kun katsoo tarkemmin

modernia ohjelmistokehitystä, huomaa,

että todellisuus on päinvastainen: käytetään

mahdollisimman monia ohjelmistokehyksiä.

Strategian nimi on TCB-minimointi,

sitä kannattaa kokeilla,

olen pitänyt aiheesta jo esitelmän ja

se on oikeastaan melko helppoa.

Kerroin jo, mitä tein

blogille vähentääkseni

vahinkoa, joka voi aiheutua,

jos joku onnistuu kaappaamaan sen,

mikä on oikeastaan oisa TCB-minimointiprosessia.

Blogi oli varsin

riskialtis, mutta vähensin

oikeuksia ja poistin ylimääräisiä tarkastuksia.

Lopulta, vaikka antaisin jokaiselle

mahdollisuuden suorittaa koodia blogin sisällä,

ei silti olisi mahdollista tehdä mitään, mitä ei olisi jo valmiiksi voinut.

Se ei enää kuulu TCB:hen,

TCB on osio, joka pitää yllä

turvallisuustakuita, joita blogin CGI

ei enää pidä.

Tämä on siis tavoite.

TCB pitää saada niin pieneksi,

kuin vain mitenkään mahdollista ja matkan

joka askel on tärkeä. Yksikään askel

ei ole liian pieni. Jos pienenkin

ylimääräisen osan voi poistaa, se kannattaa.

Tämä on se minimointi

TCB-minimoinnissa. Onnistuin poistamaan

blogin TCB:stä. tinyldap:ssa

on yhä riskejä, näitte riskimallin:

jos joku onnistuu kaappaamaan

tinyldap:n, hän pystyy lukemaan

tiivisteet ja yrittämään niiden murtamista.

Se on silti huono homma, mutta sen kanssa selviydytään.

Jos blogia vandalisoidaan, vahinko

voidaan perua käymättä

nauha-arkistossa, hyvä.

Jos tätä verrataan nykyisiin teknisiin standardeihin.

voidaan huomata, että lähestymistapani on

paljon parempi. Alalla näkee

usein alustavalintoja,

jotka tekee johto, eikä tekniikan tuntija.

Alaa ei häiritse asiantuntemus eikä

riskianalyysi, vaan usein vastuu

usein leviää, koska vaikka

yritettäisiin selvittää, kuka

on vastuussa jostakin, saadaan selville,

että vastuussa oli tämä ja tuo tiimi,

mutta emme ole aivan varmoja,

ja tiimi itse asiassa lakkautettiin viime viikolla,

tilanne on siis kamala. Ja hiljattain

saataville tulleet tekoälytyökalut johtavat myös

vastuun leviämiseen.

[Translated by Santeri Koivisto (ITKST56 course assignment at JYU.FI)]
Musiikkia