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äpyyntö, 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äpyyntöön 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