37C3 - Writing secure software

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

Siitä on kirjoitettu oppikirjoja ja siitä

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 työskennellessään

tehdäkseen turvallisen verkkosivun. Hän

seuraavaksi näyttää meille, miten sellainen tehdään, jotta

voimme kaikki nukkua yömme rauhassa ja

ottaa mallia, jonka avulla 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 aivan siinä kunnossa,

kuin niiden pitäisi olla.

Nämä diat on tehty esitelmän edellistä versiota varten. Ne pitävät

sisällään kaiken materiaalin. Yritin päivittää niitä, mutta

se tuhosi esitelmän sulavuuden, joten

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

Suurin ero on yleisössä, sillä

tällä kertaa paikalle tulee enemmän ohjelmistokehittäjiä.

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

bisnesmiehiä, joita yritän auttaa heidän

nykyisestä tilanteestaan eteenpäin, ja pääkysymyshän

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

Siis, hieman minusta, olette varmaankin

nähneet tämän jo aiemmin, olen ammatiltani

koodin tarkastaja, omistan pienen yrityksen.

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

näytän heille bugeja, joita siitä löydän, melko yksinkertaista.

Mutta ennen kuin aloitamme, minulla on

hieman 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

joka käyttää dietlibc:tä,

jonka olen kirjoittanut, 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ä "toimitte itse väärin".

Yritän nyt siis näyttää, että mitä tarkalleen menee vikaan

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

ettei ole aikaa tehdä asioita

kunnolla, eikä se pidä paikkaansa lainkaan.

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

jotka ovat pystyneet suuriin saavutuksiin, joten

jokainen varmasti pääsee pitkälle, 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 avointa porttia, jolle pääsy pitäisi estää.

Joten sitä ei tarvita,

periaatteessa sitä ei tarvita ollenkaan.

Seuraava ala: päätepisteiden suojaus,

se alkoi siis Trellix:llä, joka on

Gartnerin ykkössuositus.

En ollut kuullut siitä,

joku yhteishanke tai joku sellainen,

ketä kiinnostaa.

Heilläkin on hienoa markkinointi- siansaksaa

Ja jos katsotaan, mitä tapahtui:

se vain pahensi tilannetta.

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

koska en käytä humpuukituotteita.

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 jo ostatut, mutta ei sillä väliä.

Katsotaan siis, mitä Duo tekee:

palvelimesi pyytää pilvipalvelusta

lupaa, pilvipalvelu näyttää

puhelimella ilmoituksen, josta painetaan "kyllä",

ja pilvipalvelu kertoo palvelimelle:

"okei, voit päästää 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 sen mukaan paikkauksia, mutta sitten

asioista tuli monimutkaisempia ja

tulos oli tämä:

kuuluisa podcast Saksassa,

joka kertoo kunnasta, joka joutui

kiristysohjelman uhriksi ja joutui kutsumaan

armeijan apuun

Epäselvää puhetta yleisössä

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

täydellisyyden vuoksi, täytyy 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 niiden 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 en kovin paljoa, koska olisin

voinut vain tarjota staattista sisältöä ja pieni

hakutoimintokin olisi hyväksi, muttei kuitenkaan

pakollinen. En tarvinnut kommenttikenttää

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

hyvin helppoa, sillä jos haluaa hakea joitain voi vain

kysyä Googlelta rajoittaen haun verkkosivulle.

Julkaiseminenkin oli helppoa, minulla oli pieni

skripti, jonka pystyin ajamaan palvelimella,

jolle 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 siitä ei voisi pitää esitelmää

CCC:ssä, koska

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

riskejä kokoonpanoon.

Naurua

Ensimmäinen ideani oli, että

olin kirjoittanut pienen web-palvelimen ja voisin

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

koska sehän on minun koodiani joka tapauksessa,

mutta siinä on huonojakin puolia. Jos blogi

pyörii verkkopalvelimella, sillä on

pääsy kaikkeen verkkopalvelimen muistiin,

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

avaimeen, enkä halua, että sitä saataisiin

vietyä, joten se ei voi olla

verkkopalvelimen 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 Windowsinkin suhteen asia olisi sama.

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

ja jos sitten joku 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 vitsinä,

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 säilyttää

tiedostoja levyllä staattisena HTML:nä kuten aiemminkin,

mutta uskon, ettei se olisi 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

puolustusvälineteollisuusyritys, 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 määrältään 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,

tosin paljon pienempi.

Niin, mainoskampanja 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 puolestaan alkoi miettimään

haavoittuvuuksien hallintaa.

Unixilla, Linuxilla on mekanismi,

josta pidin erillisen esitelmän

viime kongressissa,

se on nimeltään seccomp ja seccomp 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ä

blogissani, 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ä, voidaankin siis tehdä niin, että

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

estää tai, yleisesti ottaen, pudottaa oikeuksia,

ensin tehdään open-kutsut,

otetaan ne esimerkiksi, 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 saastunut, joten katsotaan,

minkälaiset elementit ympäristössä

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

ennen kuin koskee niiden yhteenkään tavuun, 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 hyväksi 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 voi

luopua oikeuksista, ja siirtää kaikki sellainen aiemmaksi.

Näin siis tein.

Tämä tässä on mallikuva

Viron kyberturvallisuuskeskukselta,

tämäkin on siis aito.

Okei, siis, jatketaan

seuraavaan ajatukseen. Sanotaan, että

joku hakkeroi 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 kyllä korjata, mikä

on meille varsin hyvä asia.

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

FastCGI:n sijaan, FastCGI on siis

uudempi versio CGI:stä,

ja sen ideana 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 voisi arvella, että blogista tulee lopulta

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 sekin 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ää. Oletetaan, että hyökkääjä

pystyy hakkeroimaan blogini. Silloin hän 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 koodissa. 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ä

uusia blogijulkaisuja tai muokata vanhoja

sellaisia, jota 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äkutsuun 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 ala innostui

uhkatiedustelufiideistä, jotka

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

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

blogini, ja siirtyi tinyldapin pariin, ja

nyt siis hyökkää tinyldapia kohtaan. 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 jokaista

pyyntöä kohden, ja sitten vain kiellämme

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

nähdä, vaikka pystyisikin ajamaan koodia

LDAP-palvelimen sisällä, ei olisi 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 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-tietokannoilla 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 poistaa käytöstä

järjestelmäkutsuja, voin myös asentaa suodattimia, joten

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

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

yhteydessä tarkoittaa, että jokainen kirjoitus, 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 hakkeroi palveluni ja lisää roskaa

blogiini, voin vain poistaa palan tiedoston 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.

Ala käytti 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ä

vähäistä sekä lähes muuttumatonta ja siihen voidaan

soveltaa samaa strategiaa.

Jaa, no niin. Okei.

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

blogiini, mikä ei ole ideaalinen tilanne,

mutta koska kaikki, mitä hän 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

tilanteeseen, jossa blogia alettiin saastuttamaan.

Tilanne ei ole ideallinen,

mutta kuitenkin todella 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 ainoastaan 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ä saastuu?

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 mahdollista: Mitä enemmän riskiä saa kavennettua,

sitä paremmassa tilanteessa ollaan,

kun käy huonosti.

Koska mitä pienempi määrä koodia,

jota kohtaan 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.

Ala 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 mahdollisuus, joka voi toteutua,

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 jonkin aikaa ja OpenSSH tekee niin.

Se tekee kaiken riskialttiin kryptografian

toisessa prosessissa, ja käyttää

hiekkalaatikkoa kyseisen prosessin rajoittamiseen.

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

OpenSSL:ssä, 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ä valmis. Se olisi

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

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

riskin vähentämiseen ovat vain muutamia samoja.

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, haluaako SSL-tukea käyttää 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 kryptografiaan. 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:

Äänekästä naurua

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

Katsoin siis läpi 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 joka laittaa tavalliset palvelut

verkkopalveluille tarkoitettuun hiekkalaatikkoon, ja tämä

auttaa kiertämään kaikenlaisia ytimen bugeja

jo 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,

loput on kielletty, 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 yhä

olemassa, ellen ole paikannut niitä,

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

Minulla on pieni tunnustus:

Olen tavallaan 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 tarkoitan nyt

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

ja ongelmista,

jotka niistä seuraisivat.

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ä koodimäärää.

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 minimoida,

vaan jos koodi on vaarallista, haluan erityisesti

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

kategoria, jota pienentää, on

turvallisuustakuita 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 optimointistrategia, 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 osa 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, mitä minimoidaan

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 yhä huono homma, mutta sen kanssa selviydytään.

Jos blogia vandalisoidaan, vahinko

voidaan perua käymättä

nauha-arkistossa, hyvä.

Jos tätä verrataan nykyisiin alan standardeihin,

voidaan huomata, että lähestymistapani on

paljon parempi. Alalla näkee

usein alustavalintoja,

jotka tekee johto, eikä tekniikan tuntija.

Johtoa ei kiinnosta asiantuntemus eikä

riskianalyysi, vaan vastuu

usein vain leviää, koska vaikka

yritettäisiin selvittää, kuka

on vastuussa jostakin osasta, saadaan selville,

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

mutta emme ole siitäkään 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.

Jotkut taas puolestaan

väittävät, että tilanne on niin huono, ettei

se voi muuttua huonommaksi; siirrytään siis pilveen,

ja silloin tilanne tietenkin huononee

välittömästi. Pidän enemmän omasta ratkaisustani.

Loppujen lopuksi on tärkeää

tajuta, että tietoturvan puute,

jota projekteissasi ehkä tällä hetkellä on,

on itse aiheutettu ongelma. Kukaan ei seiso

haulikon kanssa takanasi

uhkailemassa. On mahdollista tarttua toimeen,

täytyy vain aloittaa. Ongelmana on itse aiheutettu avuttomuus.

Voit oikeasti auttaa

itseäsi, mutta se täytyy aloittaa.

Niin, miten tähän tilanteeseen päästiin?

Tilanne ei selvästi ole hyvä.

Ohjelmistot ovat huonoja ja

sen takana on muitakin syitä kuin se,

että ihmiset ovat tyhmiä. Syitä on muutamia.

Aiemmin käytettiin

mittatilausohjelmistoja, jotka tehtiin

tiettyä tarkoitusta varten ja käytettiin

vesiputousmallia. Oli

vaatimusspesifikaatioita ja paljon

byrokratiaa, eikä elämä ollut helppoa,

mutta se tarkoitti myös, että tiedettiin tasan,

mitä ohjelmiston pitää pystyä tekemään.

Tällöin voitiin varmistaa, että

kaikki muu on kiellettyä. Jos tietää,

mitä sovelluksen täytyy pystyä tekemään,

voidaan varmistaa, ettei se tee mitään muuta.

Se on turvallisuutta, jos asiaa tarkemmin

ajattelee. Estetään kaikki,

mitä sovelluksen ei pitäisi tehdä,

mikä olisi sitä, mitä hyökkääjä tekisi,

jos saisi koneen kaapattua, eikö?

Jos siis tietää etukäteen, mitä

tavoittelee, on mahdollista

toteuttaa oikeudenhallinta arkkitehtuuritasolla,

kuten olen näyttänyt.

Nykyään käytössä on enemmänkin Ikea-malli:

ostetaan osia, joita on suunnittelemassa

omat tiiminsä, eivätkä osia suunnittelevat tiimit

tiedä, millainen lopputuote tulee olemaan.

Joissain tapauksissa

kukaan ei tiedä, millainen

lopputuote on, mutta pahinta on,

jos tiimi, joka rakentaa

jotakin ohjelmiston osaa,

ei tiedä, miten sitä tullaan käyttämään,

jolloin siitä tehdään niin yleispätevä,

kuin mahdollista. Mitä enemmän sillä

voidaan saada aikaan, sitä parempi.

Se on turvallisuuden vastakohta. Turvallisuus

tarkoittaa sitä, että tiedetään, mitä pitää tehdä,

ja että kaikki muu estetään.

Tämä tarkoittaa, että ollaan niin geneerisiä, kuin mahdollista,

osat optimoidaan ajatellen geneerisyyttä... Mikä se sana nyt

on? Generismiä? En tiedä. Ne siis

optimoidaan joustavuutta ajatellen,

ne valitaan joustavuuden mukaan.

Osan kehittäjällä ei yleensä

ole aavistustakaan, mihin sitä käytetään,

ja se tarkoittaa, ettei vähimpien oikeuksien

periaatetta voida noudattaa, koska ei tiedetä, mitkä

nämä vähimmät tarvittavat oikeudet ovat.

Seuraa suuri sotku. Jos käyttää

toisten ohjelmoimia osia,

täytyy tehdä lisätyötä sen eteen,

että saadaan selville, mitä kaikkea

osalta voidaan estää, koska se varmasti pystyy

tekemään enemmän kuin sen tarvitsisi. Mitä enemmän

toimintaa rajoitetaan, sitä parempi

turvallisuus on. Tilanne on

vielä pahempi, jos käytetään ketterää kehitystä,

koska silloin, jo määritelmän mukaan,

lopputulos ei ole tiedossa ja

jos sitä ei tiedä, ei ole mahdollista

tehdä tietoturvaeristystä.

Toinen argumentti, jonka vuoksi nykytilanteeseen jouduttiin,

on suurtuotannon edut. Aiemmin oli niin,

että jos rakentaa jotain laitetta,

jonka täytyy tehdä jokin tietty asia,

sanotaan vaikka mikroaaltouuni,

etsitään osia ja

yhdistetään ne, juotetaan

ne yhteen ja ratkaistaan sitten ongelma.

Nykyään osia ei enää

juoteta yhteen, vaan kasaamiseen käytetään

valmisosia, jotka ovat yleensä

ohjelmoitavia. Pieni ARM-siru

maksaa sentin kymmenyksen, joten miksi käyttää

erikoistuneita osia, kun voi vain käyttää ARM-sirua

ja ohjelmoida sen. Se kuitenkin tarkoittaa,

että ongelma täytyy ratkaista ohjelmistolla.

Rauta on yleispätevää, mikä

tarkoittaa, että rautaa

voidaan hakkeroida. On hiljattain huomattu,

että se on ongelma.

20 vuotta sitten pystyi olemaan varma, että jarru jarruttaa,

mutta nykyään jarru onkin ohjelmoitava,

ja harva on tajunnut,

kuinka huono homma se on, mutta haitta on todellinen.

Se tulee vielä puremaan meitä kaikkia

persuksille. Hups.

Alan vastaus on

toistaiseksi ollut strutsimetodi.

Asennetaan siis asioita, jotka ovat

varmasti epäluotettavia, ja sitten

asennetaan niiden päälle lisää tavaraa,

joka on myös epäluotettavaa. Sitten puhutaan

telemetriasta tai big datasta ja käytetään jotakin

riskilokkausanalyysiohjelmaa,

ja yhtäkkiä hyökkäyspinta on

kasvanut kuin ydinräjähdyksen sienipilvi.

Ongelma on itse aiheutettu.

Kukaan ei ole pakottanut nykytilanteeseen.

Teidän ei tarvitse tehdä näin omissa

projekteissanne. Se olkoon tämän esitelmän

positiivinen viesti. Yhteenvetona, jos esitelmästä

ei jää mitään muuta päähän, muistakaa, että

uhkamallinnus on olemassa ja että sitä

kannattaa kokeilla, TCB-minimointi oikeasti

auttaa, vähimpien oikeuksien periaate on sama asia,

mutta eri näkökulmasta. Jos voitte käyttää

loppuun lisäävää tallennusta, sitä

kannattaa harkita. Hm?

- Lohkoketju?
- Ei lohkoketjua.

Vain lisäävä tallennus.

Ei siis lohkoketju.

Naurua

Suosionosoituksia

- Vielä kaksi, enää kaksi

- Enää kaksi diaa?

- Niin, enää kaksi diaa.

- Anteeksi, olen toiseksi tekeytyjä.

- Ei se mitään.

Siis, muistisääntönä pitäisi

olla, jos jonkun pesemättömän

harrastelijan netissä blogi

noudattaa sinua parempaa IT-turvallisuutta,

sinun täytyy parantaa IT-turvallisuuttasi.

Sen ei pitäisi olla mahdollista.

No niin, siinä oli koko esitelmä.

Meillä taitaa olla vielä aikaa kysymyksille, eikö?

- On.
- Okei, hienoa.

- Nyt on oikea hetki lyödä käsiä yhteen.

Suosionosoituksia

- Jos haluat esittää kysymyksen,

meillä on huoneessa neljä mikrofonia,

1, 2, 3, 4, ja otan ensimmäiseksi esiin

kysymyksen internetistä.

Joku netissä sanoo, että sinut

oikeasti hakkeroitiin. Voitko selventää,

mitä tapahtui?

- Niin, itse asiassa oli kyllä

tapaus, jossa joku pystyi julkaisemaan

tavaraa blogiini, ja koska käytin vain lisäävää

tallennusta, sivuutin sen oikeastaan

olankohautuksella. Käyttäkää siis vain lisäävää tallennusta.

Se pelastaa vielä nahkanne jonakin päivänä.

Ongelma oli bugi

pääsynhallintalistoissani, olin käyttänyt

LDAP-palvelimessani pääsynhallintalistaa,

jossa oli rivi, joka olisi

pitänyt poistaa, mutta unohdin

poistaa sen ja se tarkoitti, että oli mahdollista

tehdä julkaisuja ilman tunnistautumista.

Näin siis tapahtui, mutta mitään katastrofia ei käynyt,

koska arkkitehtuurini esti vahinkojen syntymisen.

- Huoneesta poistuville: Voisitteko poistua

hyvin hiljaisesti, kiitos?

Mikrofoni numero yksi.

- Jes, onko olemassa vaihtoehtoa

Windowsille ja MacOS:lle?

- Turvallista vaihtoehtoa? No,

periaatteessa on mahdollista noudattaa

periaatteita, jotka näytin esitelmässäni,

voitte noudattaa niitä kahta. Yleensä

hakkeroiduiksi ei tulla, koska MacOS:ssä

tai Windowsissa oli bugi, sitäkin tapahtuu, mutta

isompia ongelmia ovat bugit itse kirjoitetuissa

ohjelmistoissa tai käytetyissä ohjelmistoissa.

Yritän siis sanoa,

ettei Linux oikeasti ole

varsinaisesti turvallisempi kuin Windows,

pohjimmiltaan on mahdollista kirjoittaa

turvallisia ja turvattomia ohjelmistoja

millä tahansa käyttöjärjestelmällä. Silti kannattaa

käyttää Linuxia, koska se tarjoaa joitakin etuja, mutta

jos ottaa nämä tekniikat käyttöön omissa

ohjelmistoissa, ne ovat turvallisia myös

MacOS- ja Windows-laitteilla. Tämä

ei siis koske loppukäyttäjiä, jotka valitsevat

ohjelmistoja. Jos valitsee valmiin ohjelmiston,

täytyy luottaa sen valmistajaan.

Siitä ei pääse yli eikä ympäri. Jos taas

kirjoittaa omat ohjelmistonsa, on mahdollista

vähentää riskiä sellaiseen pisteeseen,

että sen kanssa selviytyy ja että voi itse nukkua rauhassa.

- Vai niin. Onko olemassa teknistä vaihtoehtoa

tai vastaavaa ominaisuutta kuin seccomp

Windowsille tai MacOS:lle, voiko siis pudottaa

oikeudet sen jälkeen, kun on avannut tiedoston,

näin esimerkiksi ottaen?

- MacOS:n suhteen en ole varma, mutta tiedän,

että FreeBSD:llä, NetBSD:llä ja OpenBSD:llä on vastaava

ominaisuus, luulen, että sama pätee MacOS:n kanssa, mutta

en ole siitä varma. Windowsilla on

hiekkalaatikkomenetelmiä, voit katsoa

esimerkiksi Chromen lähdekoodia,

se käyttää hiekkalaatikkoa ja lähdekoodi on avointa.

Sellaista voi käyttää

tällaisiin asioihin.

- Okei, kiitos.

- Seuraavaksi mikrofoni numero kaksi... Paitsi että

se meni jo. Siinä tapauksessa

taidan valita mikrofonin numero kolme.

- Tämä on numero neljä.
- Anteeksi, numero neljä tosiaan.

- Kertooko seuraava esitelmäsi turvallisten

ohjelmistojen kirjoittamisesta Windowsille ja

jos ei, paljonko omaisuutta vaadit

korvaukseksi siitä aiheutuvasta tuskasta?

- Ei.

Naurua

Kysymys ei ole rahasta.

Naurua

- Selvä, mikrofoni numero yksi.

- Oletko kokeillut tarpeettomien

ominaisuuksien poistamista OpenSSL:stä?

- Kyllä, itse asiassa olen kokeillut sitä

jo melko ajoissa, mutta se on silti

paljon isompi kuin oma koodini.

Siis, esimerkiksi, OpenSSL tukee

UDP-pohjaista TLS:ää, mutta

jaettuja kryptografisia koodeja on paljon. Niistä

voi poistaa niitä, joita ei tarvitse, ja se auttaa

hieman, mutta silti jäljelle jää

verkkopalvelimen selkeästi suurin osa.

- Taisi tulla internet-kysymys?

Tuliko? Ei näytä siltä.

Ei? Kyllä? Ei? Ei? Kyllä? Okei.

- Sitten mikrofoni numero neljä.

- Ihmisenä, joka on tekemisissä

tai on ollut tekemisissä alan, johon kuuluu

ohjelmointi-
Ohjelmoitavia jarruja,

mikä on mielipiteesi sellaisista asioista,

kuten MISRA?

- No siis, on olemassa standardeja,

esimerkiksi autoalalla, kuten

juuri MISRA, joiden tarkoituksena on varmistaa

paremman koodin kirjoittaminen, ja kyseessä

on pääasiassa sääntöjen noudattaminen. Annetaan sääntöjä,

kuten että rekursiota ei tulisi käyttää koodissa,

esimerkiksi, ja että

funktioiden pitäisi olla näin ja noin isoja

enimmillään, ja uskon, että

se auttaa hieman, mutta on paljon

parempi vaihtoehto investoida

arkkitehtuuriin. Saatoitte huomata, että

sanoin kirjoittaneeni koodia C:llä, mutta

en sanonut mitään siitä, miten varmistin,

että koodista tuli laadukasta.

Se on kokonaan eri ulottuvuus,

kohtisuoraan eri akselilla, siis,

noudattakaa standardeja, sillä tavalla

koodista tulee hieman parempaa,

luultavasti, mutta se ei ratkaise

kaikkia ongelmia ja itse uskon, että

pitäisi tehdä molemmat: Varmistaa,

tai ainakin yrittää varmistaa, että koodissa

on mahdollisimman vähän bugeja,

on tapoja, joilla se onnistuu, pidin siitäkin esitelmän,

mutta sen lisäksi pitäisi noudattaa

vastaavan laisia

arkkitehtuuririllisiä suojakaiteita,

jotka pitävät asiat raiteillaan, vaikka joku

onnistuisikin kaappaamaan prosessin.

- Nyt uskon, että saimme

internet-kysymyksen.

- Kyllä. Joku internetissä kysyy, miten

onnistuisi tämän todella vaikuttavan turvallisuusarkkitehtuurin

skaalaaminen suurempaan kokoluokkaan,

eri käyttötarkoituksiin,

suurempiin tarkoituksiin vai pilaisiko

projektin hallitsematon laajeneminen kaiken?

- Niin, siis...

- Haloo, haloo.

- Voi ei!

Naurua

- No, olen pahoillani.

Suosionosoituksia

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