0:00:00.000,0:00:01.000
Translated by Esa Lammi[br](KYBS2001 course assignment at JYU.FI)

0:00:01.000,0:00:21.180
<i>36c3 intromusiikki</i>

0:00:22.180,0:00:28.540
Herald: Oletteko koskaan miettineet kuinka[br]kuinka väärentää sähköposti hyvin? Siinä

0:00:28.540,0:00:33.369
tapauksessa voitte olla oikealla luennolla.[br]Meillä on seuraava puhuja. Andrew, joka

0:00:33.369,0:00:41.180
työskentelee nykyisin kansallisessa CERTssa[br]Latviassa tietoturvatutkijana. Ja hän aikoo

0:00:41.180,0:00:50.120
puhua meille sähköpostin väärentämisestä[br]ja nykyaikaisista anti-spoofing strategioista.

0:00:50.120,0:00:53.356
Lava on sinun.

0:00:53.356,0:01:04.460
<i>Aplodeja</i>

0:01:04.460,0:01:14.490
Andrew: Tervehdys. Olen Andrew ja työs-[br]kentelen Latvian kansallisessa CERTssa.

0:01:14.490,0:01:21.440
Yksi tavoitteistamme on kehittää sähköpostin[br]turvallisuuden tilaa maassamme ja teemme

0:01:21.440,0:01:26.400
tätä enimmäkseen nostamalla tietoisuutta[br]asiasta ja tiedottamalla parhaista

0:01:26.400,0:01:30.770
toimintatavoista. Ja tietenkään emme ole[br]ainoa organisaatio joka tekee tätä.

0:01:30.770,0:01:34.420
On monia CERT yksiköitä lisää eri maissa[br]ja on myös useita vapaaehtois

0:01:34.420,0:01:39.299
järjestöjä jotka tekevät samaa.[br]Sekä kaupallisia tahoja.

0:01:39.299,0:01:46.060
Kuitenkin, toistaiseksi, suoraan sanoen,[br]menestyksemme on ollut melko

0:01:46.060,0:01:54.100
vaatimatonta. Esimerkiksi, tässä on yksi[br]tilasto, joka on käyttöaste yhdestä

0:01:54.100,0:01:59.770
tietystä teknologiasta, DMARCsta, joka [br]kuten opitte esityksessä on melko

0:01:59.770,0:02:06.770
tärkeä ja toivon, että kaikki alkavat[br]käyttämään sitä. Eli vasemmalla on

0:02:06.770,0:02:11.060
20 tuhatta domainia ympäri maailmaa,[br]jotka ovat tärkeitä domaineja tärkeille

0:02:11.060,0:02:15.880
organisaatioille, joiden pitäisi tosissaan[br]tietää paremmin. Ja oikealla puolella

0:02:15.880,0:02:24.799
näemme top 50, top 500 EU kaupallisia[br]domaineja ja näistä kaksi kolmasosaa

0:02:24.799,0:02:29.799
eivät ole konfiguroineet DMARCia vielä.[br]ja niistä jotka ovat näin tehneet, valtaosa

0:02:29.799,0:02:36.350
eivät ole määrittäneet tiukkaa politiikkaa.[br]Joten jos pitää poimia yksi asia tästä

0:02:36.350,0:02:41.459
puheesta, toivon että kaikkien pitäisi[br]alkaa käyttämään DMARCia. Sitä on tärkeää

0:02:41.459,0:02:49.120
käyttää myös domaineissa joiden ei pitäisi[br]lähettää sähköposteja ulos. Joten yksi

0:02:49.120,0:02:56.760
selitys matalalle käyttöasteelle, luulen[br]olevan, että on näennäisesti liian monta

0:02:56.760,0:03:04.310
kilpailevaa teknologiaa. Tämä on puheeni[br]sisältö. Ja tein todella parhaani

0:03:04.310,0:03:12.449
tiivistääkseni sitä. Mutta kuten voitte[br]nähdä, on kolme lyhennettä, no myös

0:03:12.449,0:03:18.739
SMTP ja näistä, SPF, DKIM ja DMARC.[br]Oikeastaan en muista mitkä ovat kahden

0:03:18.739,0:03:25.570
kokonaiset nimet. Mutta silti ne ovat[br]kaikki tärkeitä. Ja tietenkin, tämä ongelma

0:03:25.570,0:03:28.949
että on liikaa muotisanoja, liikaa[br]teknologioita, eikä ole selvää mitä kaikkia

0:03:28.949,0:03:34.590
mitä meidän tulisi käyttää, se ei koske[br]pelkästään sähköpostia. Meillä on sama

0:03:34.590,0:03:39.760
tilanne kaikkialla ja oh, tietoturvan[br]alueella, luulen että olemme nyt löytäneet

0:03:39.760,0:03:47.880
yhden tavan ratkaista asia ja se on[br]penetraatiotestaus. Eli kun penetraatio

0:03:47.880,0:03:53.370
testaus on tehty kunnolla ja tulokset[br]on julkaistu, me voimme alkaa

0:03:53.370,0:03:58.190
puhumaan. Voimme siirtää keskustelun pois[br]suosiiko

0:03:58.190,0:04:03.510
organisaatio teknologiaa A vai teknologiaa[br]B ja voimme sen sijaan alkaa puhumaan

0:04:03.510,0:04:09.620
kysymyksistä, joilla on merkitystä, kuten[br]onko mahdollista jollekin kolmennelle

0:04:09.620,0:04:15.310
osapuolelle väärentää organisaationne[br]sähköposteja ja lähettää sellaisia

0:04:15.310,0:04:20.989
sähköposteja esimerkiksi asiakkaille tai[br]kumppaneille ja media organisaatioille

0:04:20.989,0:04:24.970
siten, että he luulevat sähköpostien [br]tulleen todellisuudessa teidän

0:04:24.970,0:04:31.810
organisaatiolta? Tästä syystä penetraatio[br]testaajat ovat tämän luennon avainyleisöä.

0:04:31.810,0:04:36.020
Kuitenkin, toivon että kuka tahansa blue[br]teamilainen yleisössä kokee tämän puheen

0:04:36.020,0:04:40.650
kiinnostavaksi. Olen varma, että tunnette[br]jo perusteet sähköpostista ja näistä

0:04:40.650,0:04:43.620
teknologioista, mutta asian[br]tarkasteleminen toiselta puolelta,

0:04:43.620,0:04:50.440
hyökkääjän puolelta, voi joskus asettaa[br]asiat todella oikeaan perspektiiviin.

0:04:50.440,0:04:54.819
Se voi auttaa sinua ymmärtämään mihin[br]sinun pitäisi keskittyä ympäristöä

0:04:54.819,0:05:01.009
suojatessasi. Ja lopuksi SMTP protokolla.[br]Teknologia, joka kulkee meidän

0:05:01.009,0:05:07.720
sähköpostikeskustelujen alla on oikeasti[br]melko helppo ymmärtää.

0:05:07.720,0:05:14.061
Ja myös vanhat opetukset koko[br]SMTPn matkasta, kuinka se kehittyi

0:05:14.061,0:05:20.979
ja kuinka on mahdollista väärentää se[br]ja kuinka kaikki teknologiat koittavat

0:05:20.979,0:05:27.530
estää väärentämistä. Mielestäni se on[br]kiinnostava tapaus ja sen pitäisi olla

0:05:27.530,0:05:33.719
mielenkiintoista seurattavaksi jopa niille[br]joille email on uutta. Um, lopuksi. Uhka

0:05:33.719,0:05:41.400
ympäristö. Eli email turvallisuus on laaja[br]alue. Ja tänään keskityn vain sen yhteen

0:05:41.400,0:05:47.650
pieneen alueeseen, joka on onnistunut[br]sähköpostin väärentäminen. Tampering

0:05:47.650,0:05:54.689
attacks. Ja tiedän että monet, pentestaajat[br]jo nyt hyödyntävät osin phishingia tai

0:05:54.689,0:06:01.250
spearphishingia, emulointia heidän[br]toimeksiannoissaan ja. Mutta tietääkseni

0:06:01.250,0:06:07.070
he tekevät sitä enimmäkseen sosiaalisen[br]hakkeroinnin näkökulmasta käyttäen

0:06:07.070,0:06:13.090
social engineering toolkit:ia ja vastaavia[br]esimerkiksi. Ja se on, en halua kiistellä,

0:06:13.090,0:06:16.949
tärkeää demonstroida asiakkaalle

0:06:16.949,0:06:23.860
mitkä ovat riskit sosiaalisessa[br]hakkeroinnissa. Kuitenkin mielestäni teette

0:06:23.860,0:06:28.099
asiakkaalle karhunpalveluksen jos se on[br]ainoa asia mitä testaatte

0:06:28.099,0:06:32.650
sähköpostin näkökulmasta, koska asiakkaan,[br]managerin näkökulmasta joka lukee

0:06:32.650,0:06:38.870
raporttinne, jos siinä mainitaan vain [br]social engineering hyökkäykset, silloin

0:06:38.870,0:06:44.650
looginen johtopäätös on, että paras keino[br]mitigoida näitä uhkia on käyttäjien

0:06:44.650,0:06:51.590
kouluttaminen, erityisesti niiden jotka[br]ovat vähiten teknisiä, kuten näet tässä

0:06:51.590,0:06:55.379
esityksessä. On monia hyökkäyksiä ja[br]useat organisaatiot ovat niille

0:06:55.379,0:07:00.230
alttiita, jotka ovat paljon niitä parempia.[br]Mikään määrä käyttäjäkoulutusta ei auta

0:07:00.230,0:07:03.889
koska emme voi olettaa käyttäjien tutkivan[br]headereitä esimerkiksi käsin.

0:07:03.889,0:07:10.699
Joten meidän täytyy oikeasti parantaa[br]sähköposti infrastruktuuriamme. Tätä ei

0:07:10.699,0:07:17.009
voi kieltää. Ja lopuksi ennen siirtymistämme[br]oikeaan tekniseen asiaan, on pieni salaisuus

0:07:17.009,0:07:21.889
jonka uskon auttavan ihmisiä, jotka eivät[br]työskentele sähköpostin parissa,

0:07:21.889,0:07:28.159
ymmärtämään miksi meillä on näitä ongelmia[br]on, email admineille historiallisesti, um,

0:07:28.159,0:07:38.040
he arvostavat saatavuutta järjestelmässä[br]ja luotettavuutta paljon enemmän

0:07:38.040,0:07:44.680
kuin turvallisuutta. Ja koska tämä ei ole[br]ideologinen kysymys. Se on hyvin

0:07:44.680,0:07:50.469
käytännön läheinen. Joten, esimerkiksi, [br]jos olet email, email admin organisaatiossa

0:07:50.469,0:07:56.090
ja joltain käyttäjistäsi loppuu laskujen[br]vastaanottaminen, esimiehesi etsii

0:07:56.090,0:08:01.470
sinut, kertoo tilanteesta ja pyytää[br]sinua kauniisti korjaamaan tilanteen

0:08:01.470,0:08:06.210
niin pian kuin mahdollista, vaikka se ei[br]olisi sinun vikasi, jos sattuisi käymään

0:08:06.210,0:08:13.509
niin että vika on emailin toisessa päässä.[br]Ei sinun palvelimella. Ja esimerkiksi jos,

0:08:13.509,0:08:20.449
toinen esimerkki, jos sinä, jos joku sinun[br]työntekijöistä vastaanota sähköpostia

0:08:20.449,0:08:24.969
tarpeeksi nopeasti, esimerkiksi salasanan[br]palauttamiseksi tai varmentaakseen

0:08:24.969,0:08:30.190
sähköpostiosoitteen tai käyttääkseen usean[br]välineen tunnistautumista (MFA) ja he eivät

0:08:30.190,0:08:33.969
voi kirjautua johonkin tärkeään järjestelmään[br]he etsivät sinut ja sinun täytyy

0:08:33.969,0:08:39.539
ratkaista se. Mutta jos järjestelmässä on[br]joku tietuturva haavoittuvuus, jos se on

0:08:39.539,0:08:45.540
altis spoofaus hyökkäykselle ja niin[br]edelleen silloin, ei käyttäjä, ei esimies

0:08:45.540,0:08:50.670
normaalisti huomaa sitä. Sinä et välttämättä[br]huomaa, mutta olet. Sinulla on tämä

0:08:50.670,0:08:55.930
haavoittuvuus. Joten siksi toki penetraatio[br]testaajat ovat tärkeitä. Okei.

0:08:55.930,0:09:01.250
Nyt voimme viimein alkaa puhumaan teknisestä[br]asiasta. Ja me aloitamme lyhyellä

0:09:01.250,0:09:07.190
perehtymisellä SMTP protokollaan.[br]SMTP on protokolla joka on kaiken email

0:09:07.190,0:09:12.360
kommunikoinnin perusta ja sitä on oikeastaan[br]melko helpo seurata. Eli tässä on datavirta

0:09:12.360,0:09:18.370
mitä tapahtuu kun yksi henkilö lähettää[br]sähköpostin toiselle henkilölle.

0:09:18.370,0:09:21.269
Esimerkiksi Alice lähettää Bobille ja he[br]käyttävät eri, he työskentelevät

0:09:21.269,0:09:24.970
eri yrityksissä. He käyttävät eri[br]domaineja. Eli mitä tapahtuu tässä on,

0:09:24.970,0:09:29.290
että molemmat käyttävät, sanotaan, email[br]ohjelmaa kuten Outlook tai

0:09:29.290,0:09:34.580
Thunderbird. Ja Alice lähettää sähköpostia.[br]Se kulkee SMTP protokollan läpi Alicen

0:09:34.580,0:09:41.740
säkköpostipalvelimelle. Mutta on tärkeä[br]huomata että tämä on lähtevän postin palvelin.

0:09:41.740,0:09:44.790
Yleensä organisaatioilla on kahden tyypin[br]palvelimia, yksi sisään tulevalle

0:09:44.790,0:09:48.680
liikenteelle ja toinen lähtevälle. Pienillä[br]organisaatioilla se voi olla yksi palvelin

0:09:48.680,0:09:52.470
mutta taas, on tärkeää pentestaajan[br]ajatella niitä eri järjestelminä

0:09:52.470,0:09:56.680
koska niillä on, vaikka meillä olisi vain[br]yksi fyysinen palvelin, siinä on eri

0:09:56.680,0:10:00.620
konfiguraatio lähtevälle postille ja [br]sisään tulevalle postille. Joten penetraatio

0:10:00.620,0:10:04.899
testaajana sinun pitää tarkastaa molemmat.[br]Okei. Nyt, kun Alicen palvelin koittaa

0:10:04.899,0:10:11.940
lähettää postin Bobin palvelimelle, on [br]ongelmana, että palvelimen täytyy jotenkin

0:10:11.940,0:10:16.480
automaattisesti selvittää on se toinen[br]palvelin jolle lähettää se posti ja se

0:10:16.480,0:10:25.220
tehdään käyttäen blue box MXaa, joka on[br]tietty DNS merkintä tyyppi MX. Eli se on

0:10:25.220,0:10:29.680
jotain, jota ylläpitää Bob:in organisaatio.[br]Eli Bobon organisaatio, mikäli he haluavat

0:10:29.680,0:10:35.360
vastaanottaa sähköpostia, he luovat tämän[br]DNS merkinnän. Ja sanon että. Okei. Jos

0:10:35.360,0:10:38.830
haluatte lähettää sähköpostia meille, [br]käyttäkää tätä palvelinta. Eli sen pitäisi

0:10:38.830,0:10:44.290
osoittaa Bobin palvelimeen. Ja Alicen lähtettävä[br]palvelin tietää Bobin vastaanottavan palvelimen

0:10:44.290,0:10:50.670
osoitteen ja voi kommunikoida sille. Ja[br]myöhemmin Bob vastaanottaa sen postin.

0:10:50.670,0:10:54.970
Eli kohta jota me pentestaajina koitamme[br]murtaa on todellisuudessa

0:10:54.970,0:10:59.839
Alicen ja Bobin palvelimien välissä. [br]Ja meidän täytyy miettiä toista esimerkkiä

0:10:59.839,0:11:03.511
joka on päinvastainen tapaus. Ja voit[br]ajatella että siinä ei ole

0:11:03.511,0:11:07.110
mieltä, koska me periaatteessa[br]vain muutamme liikenteen suunnan.

0:11:07.110,0:11:11.449
Mutta tärkeä osa tässä meille[br]pentestaajina on ymmärtää, että

0:11:11.449,0:11:17.220
asiakas kontrolloi vain osaa tästä[br]transaktiosta. Jos asiakkaamme,

0:11:17.220,0:11:20.760
sanotaan vaikka loppuesityksen ajan on[br]Alice tai Alicen organisaatio,

0:11:20.760,0:11:26.750
niin toisena esimerkkinä kun lähetämme[br]postia Bobilta Alicelle

0:11:26.750,0:11:34.600
silloin lähetämme vain sähköpostia.[br]Periaatteessa, osa tästä liikenteestä

0:11:34.600,0:11:40.980
kulkisi Alicen palvelimien kautta. Ensim-[br]mäisessä esimerkissä jos lähetämme postia

0:11:40.980,0:11:45.940
Alicelta Bobille, se ei menisi niin. Eli jos[br]se tuntuu hämmentävälle, se on OK. Palaamme

0:11:45.940,0:11:51.600
tähän hieman myöhemmin. Ja lopuksi, on[br]kolmas esimerkki, joka näyttää samalta

0:11:51.600,0:11:56.260
mutta ei ihan. Ja se on jos Alice[br]kommunikoi. Alice on asiakkaamme.

0:11:56.260,0:12:01.070
Ja jos hän kommunikoi hänen työtoverien[br]kanssa, jotka ovat samassa organisaatiossa,

0:12:01.070,0:12:04.320
samassa email palvelimessa, samassa[br]domainissa. Siinä tapauksessa, jälleen,

0:12:04.320,0:12:09.000
on vähintään kaksi loogista email palvelinta,[br]lähtevä palvelin ja sisääntuleva palvelin.

0:12:09.000,0:12:15.850
Mutta molemmat kuuluvat asiakkaallemme.[br]Eli nyt, jos et ollut tuttu sähköpostin kanssa,

0:12:15.850,0:12:20.149
nyt olet. On todella mielenkiintoista[br]pohtia mitä näistä skenaarioista,

0:12:20.149,0:12:27.740
kolmesta skenaariosta, on helponta suojata.[br]ja myöhemmin

0:12:27.740,0:12:31.769
näemme miten se oikeasti tapahtuu.[br]Okei. Ja sitten meidän täytyy katsoa mitä

0:12:31.769,0:12:38.410
oikeasti lähetetään, kun sähköpostia ollaan[br]lähettämässä. Eli jälleen, se käyttää SMTP

0:12:38.410,0:12:44.790
protokollaa ja on tosi kiva protokolla[br]kuten. Kuten voit nähdä, se on vain tekstiä.

0:12:44.790,0:12:48.029
Eli se on puhdas tekstiprotokolla ja sen [br]kanssa on helppo leikkiä, koska

0:12:48.029,0:12:54.410
voit avata telnet yhteyden oikealle[br]palvelimelle ja voit koittaa kirjoittaa

0:12:54.410,0:12:58.680
komentoja käsin. Voit koittaa väännellä[br]jotain tai muokata tai koittaa erilaisia

0:12:58.680,0:13:05.149
erilaisia tyyppejä ja nähdä reaaliajassa[br]kuinka se menee. Eli vasemmalla

0:13:05.149,0:13:11.209
näemme tässä kaksi osaa jotka[br]määrittää SMTP. Eli ensinnäkin

0:13:11.209,0:13:14.720
siinä on SMTP kirjekuori, jonka periaatteessa[br]kytket palvelimeen. sanot hello,

0:13:14.720,0:13:22.070
ja sitten sanot mitä. Määritä sähköpostin[br]lähettäjä ja vastaanottaja. "mail from"

0:13:22.070,0:13:26.980
on lähettäjä. Vastaanottaja on Bob, [br]esimerkiksi. Ja sitten toinen osa alkaa

0:13:26.980,0:13:32.160
datalla ja loppuu quit. Ja sitä osaa[br]kutsutaan kontentiksi / viestiksi.

0:13:32.160,0:13:35.480
Jos haluat leikkiä sillä enemmän, tämän[br]määrittää eri standardi

0:13:35.480,0:13:38.029
joka ei ole tärkeä pentestaajalle, mutta[br]jos haluat katsoa

0:13:38.029,0:13:43.890
yksityiskohtia ja se voisi olla tärkeää.[br]Ja tämä sisäinen viesti, jota

0:13:43.890,0:13:49.069
kutsutaan joko sisällöksi tai SMTP[br]viestiksi, se taas, se sisältää kaksi osaa.

0:13:49.069,0:13:53.300
Yksi on headeri ja toinen on runko. Ja [br]luulen että jotkut eivät tunne emailia,

0:13:53.300,0:13:57.569
mutta varmaan kaikki yleisössä tuntevat[br]HTTPn ja tämä

0:13:57.569,0:14:02.600
näyttää melko, melko samalta. Eli helppoa[br]ymmärtää. Mutta mielenkiintoinen osa tässä

0:14:02.600,0:14:08.550
että saatoit huomata, että meillä on [br]Alicen ja Bobin osoitteet kahdesti.

0:14:08.550,0:14:14.350
Eli. Esimerkiksi, Alice on määritelty[br]toisella rivillä "mail from". Ja sitten

0:14:14.350,0:14:19.709
meillä on sama osoite. alice @ hänen[br]organisaatio "From" headerissa. Punaiset

0:14:19.709,0:14:26.810
ovat headereita. Ja sama tapahtuu Bobilla.[br]Miksi näin on? No, se johtuu siitä miten

0:14:26.810,0:14:33.471
me näemme sähköpostin. Minä tavallisena [br]henkilönä, joka on käyttänyt sähköpostia

0:14:33.471,0:14:39.139
jo aika paljon, näen ne yleensä kuten[br]vasemmalla, joka on kuin

0:14:39.139,0:14:44.980
jonkinlainen postikortti. Eli postikortissa[br]on joku joka sen on lähettänyt. Lähettäjä.

0:14:44.980,0:14:48.980
Siinä on vastaanottaja. Se olen yleensä minä.[br]Olen vastaanottaja. Ja sitten siinä on joku

0:14:48.980,0:14:53.569
viesti. Näin ainakin koin asiat[br]ennen kuin opin siitä hieman lisää.

0:14:53.569,0:14:58.670
Mutta email adminit ja standardointi[br]järjestöt, he näkevät asian näin

0:14:58.670,0:15:04.610
kuten tässä oikealla on. Siinä on[br]kirjekuori ja kuoren sisällä

0:15:04.610,0:15:10.480
siellä on viesti tai postikortti ehkä.[br]Eli sinulla on kaksi osoitetta

0:15:10.480,0:15:15.350
tässä skenaariossa. Sinä määrittelit[br]osoitteet keneltä ja kenelle olet

0:15:15.350,0:15:20.730
lähettämässä kuorta, joka on osa sitä mitä[br]postikonttori, esimerkiksi, katsoo.

0:15:20.730,0:15:24.589
Mutta postikonttori ei yleensä katso sinun[br]kuoren sisään. Ja sisällä kuoressa

0:15:24.589,0:15:28.880
on toinen viesti ja tämä sisäinen viesti[br]on todellisuudessa tarkoitettu

0:15:28.880,0:15:33.889
vastaanottajalle. Eli todellisuudessa, [br]voisit tehdä vielä enemmän ja jopa laittaa

0:15:33.889,0:15:40.060
koko kirjekuoren postikorttiviesteineen[br]toisen kirjekuoren sisään. Ja tämä voi

0:15:40.060,0:15:46.500
kuulostaa hullulta minulle tavallisena[br]henkilönä, mutta email sallii tämän.

0:15:46.500,0:15:50.029
Ja RFC dokumentissa, siinä on esimerkkejä[br]miksi tämä voi olla välttämätöntä.

0:15:50.029,0:15:56.939
Miksi, miksi, miksi moiset asiat on sallittu.[br]Mutta ne ovat hämäriä. Ja niin seurauksena

0:15:56.939,0:16:03.009
se on tässä ensimmäisessä esimerkissä,[br]näemme, että yleisesti määritämme

0:16:03.009,0:16:07.940
saman osoitteen kahdesti. Mutta kysymys[br]joka meidän pentestaajina tulisi

0:16:07.940,0:16:12.170
kysyä on: Vaaditaanko sitä, oikeasti?[br]Onko se oikeasti totta vai ainoastaan

0:16:12.170,0:16:17.120
toiveajattelua? Ja se on vain[br]toiveajattelua. Eli standardi

0:16:17.120,0:16:20.870
ei erityisesti sano, että sinun pitäisi[br]määrittää sama osoite vastaanottajalle

0:16:20.870,0:16:27.140
tai "From" lähettäjän osoitteelle kuoressa[br]ja viestin sisällä. Eli, voit virittää,

0:16:27.140,0:16:32.300
niitä ja lähettää erilaista, eri tavaraa.[br]Eli, oikeasti,

0:16:32.300,0:16:38.519
on monia headereita lisää kuin mitä juuri[br]näytin. Ne mitä näytin ovat, luulen, niitä

0:16:38.519,0:16:42.850
joista meillä kaikilla on kokemusta, koska[br]vaikka vain käyttäisit emailia, ne ovat

0:16:42.850,0:16:45.920
yleensä se juttu jonka näet tai näet[br]päiväyksen, näet otsikon. näet

0:16:45.920,0:16:52.680
kuka on lähettänyt sinulle jotain ja[br]kenelle se on lähetetty. Yleensä sinulle.

0:16:52.680,0:16:57.800
Ja siinä voi olla, toki, useita vastaanottajia.[br]Oh, yeah. Ja kysymys silloin, toinen kysymys

0:16:57.800,0:17:03.769
on: Mikä on oikeasti, jos olemme määritelleet[br]jostain syystä vahingossa tai erityisesti

0:17:03.769,0:17:07.300
jos olemme määritelleet eri osoitteen[br]tähän kirjekuoreen tässä viestissä

0:17:07.300,0:17:11.890
minkä käyttäjä näkee vastaanottajana,[br]se on oikeasti headeri.

0:17:11.890,0:17:18.010
Eli viestin sisällä on se, mikä on[br]tarkoitettu käyttäjälle. OK. Eli kuten

0:17:18.010,0:17:22.510
olin sanomassa, standardit sallivat vähän[br]enemmän headereita. Ja oikeasti

0:17:22.510,0:17:25.880
3 headeria "From", "Sender", "Reply to"[br]jotka ovat semanttisesti hyvin

0:17:25.880,0:17:31.080
lähekkäin ja standardi oikeasti selittää[br]Milloin sinun pitäisi käyttää mitäkin.

0:17:31.080,0:17:34.040
Ja hassu juttu minulle on, että esimerkiksi[br]"From" headeri, joka on yleensä se

0:17:34.040,0:17:39.310
minkä näemme mitä se voi sisältää. RFCta[br]lukiessa selviää ettei

0:17:39.310,0:17:44.450
niitä headereita pitäisi olla kuin yksi,[br]mutta headeri itsessään voi

0:17:44.450,0:17:48.020
sisältää useita osoitteita. Henkilökohtaisesti[br]en ole ikinä saanut postia usealta

0:17:48.020,0:17:53.110
eri lähettäjältä, mutta se on sallittua.[br]Tärkeä asia ymmärtää on tässä

0:17:53.110,0:17:57.530
jälleen on taaksepäin yhteensopivuus,[br]josta mainitsin aikaisemmin. Eli vaikka

0:17:57.530,0:18:02.480
standardi selittää kuinka sinun pitäisi [br]käyttää kutakin headeria ja ettei

0:18:02.480,0:18:07.130
sinun pitäisi käyttää kuin yhtä kappaletta[br]niistä, käytännössä voi lähettää

0:18:07.130,0:18:12.480
väärinmuotoillun sähköpostin. Voisit lähettää[br]emailin useilla headereilla, sama "From"

0:18:12.480,0:18:17.040
header useita kertoja tai voit lähettää[br]headerin joka ei sisällä "From" mutta

0:18:17.040,0:18:21.240
sisältää "Sender" headerin, RFCn mukaan[br]väärin. Todellisuudessa se toimii.

0:18:21.240,0:18:27.550
Useimmilla organisaatioilla, useimmat email[br]palvelut pyrkivät parhaansa mukaan välittämään

0:18:27.550,0:18:33.720
täysin vääristetyn emailin, koska ne oikeasti[br]haluavat alentaa ylläpitokustannuksia.

0:18:33.720,0:18:37.580
Eli jos joku ei toimi, silloin tulet heidän[br]luokseen. Joten on parempi

0:18:37.580,0:18:42.160
saada kaikki toimimaan suurimman osan[br]ajasta. Tietenkin pentestaajalle tämä

0:18:42.160,0:18:45.670
tarkoittaa, että voit leikkiä sillä[br]koska on

0:18:45.670,0:18:49.480
erilaisia implementointeja ja juuri mikä[br]headeri esimerkiksi, jos sinulla

0:18:49.480,0:18:53.830
on kaksi näytetään tai mitä käytetään[br]johinkin algoritmiin. Se riippuu kyseisestä

0:18:53.830,0:18:59.150
implementaatiosta. Eli koska on niin monta[br]implementaatiota, ne ovat kytkeytyneinä

0:18:59.150,0:19:03.720
toisiinsa erilaisilla tavoilla. Sinä voisit[br]ja sinun pitäisi pentestaajana yrittää

0:19:03.720,0:19:09.270
eri asioita, esimerkiksi, lisätä sama[br]headeri useaan kertaan. OK.

0:19:09.270,0:19:13.990
Nyt kun olemme läpikäyneet perusteet,[br]katsotaan miten oikeasti koittaisit

0:19:13.990,0:19:18.360
väärentää emailin, esimerkiksi, yeah. Ja [br]tässä taas, tulemme takaisin tähän

0:19:18.360,0:19:23.930
kuvaan jonka näimme aiemmin. Ja,[br]esimerkiksi, ensimmäisessä esimerkissä

0:19:23.930,0:19:29.960
Alice lähetti postia Bobille. Sanotaan, että[br]olemme Chuck. Eli olemme kolmas osapuoli.

0:19:29.960,0:19:33.700
Olemme lisensoituja pentestaajia, meillä[br]on sopimus että voimme tehdä näin

0:19:33.700,0:19:38.920
ja koitamme lähettää väärennetyn emailin[br]Bobille. Ja tässä esimerkissä koitamme

0:19:38.920,0:19:44.440
väärentää Alicen viestin. Eli aikeena on[br]että Bob haluaa, Bon vastaanottaa emailin.

0:19:44.440,0:19:52.580
Sen pitäisi näyttää heille, Bobille, että[br]emailin lähettäjä on Alice. Eli riski on tämä.

0:19:52.580,0:19:57.580
Okei, en käy läpi riskiä. Luulen, että[br]voitte kuvitella sen. Eli esimerkiksi,

0:19:57.580,0:20:01.430
voisit lähettää vääriä uutisia, se on yksi[br]ongelmista, joita olemme nähneet Latviassa.

0:20:01.430,0:20:06.330
Tätä on käytetty valtionhallintoa vastaan.[br]Ja kun joku lähettää valeuutisia sähköpostilla

0:20:06.330,0:20:13.660
toisille ihmisille ja niin edelleen, ja[br]koitamme matkia jotain valtiollista

0:20:13.660,0:20:19.510
henkilöä. Ja kuten voit kuvitella itse,[br]ei ole hyvä juttu

0:20:19.510,0:20:23.710
sinulle jos se on mahdollista. Mutta[br]mielenkiintoinen juttu on, että vaikka

0:20:23.710,0:20:28.450
Chuck tekee hyökkäystä, riippuu sinun [br]näkökulmasta. Se voi näyttää, että Alice

0:20:28.450,0:20:32.480
hyökkää Bobille. Mutta tässä tapauksessa[br]email ei mene Alicen järjestelmän läpi.

0:20:32.480,0:20:37.590
Kuten näette, Chuck lähettää emailin suoraan[br]Bobin sisääntulevalle palvelimelle.

0:20:37.590,0:20:44.490
Nyt, on olemassa toisen tyyppinen hyökkäys[br]jota katsotaan. Jos lähetämme emailia

0:20:44.490,0:20:48.540
toiseen suuntaan Bobilta Alicelle.[br]Ja asiakkaamme on Alice. Eli testaamme

0:20:48.540,0:20:52.900
Alicen palvelinta. Ja tässä tapauksessa,[br]koitamme, taas olemme Chuck.

0:20:52.900,0:20:58.570
Lähetämme emailia. Tässä tapauksessa, email[br]menee Alicen järjestelmän läpi.

0:20:58.570,0:21:03.790
Eli kiinnostava kysymys on, kumpaa on[br]helpompi suojata. Voi vaikuttaa, koska

0:21:03.790,0:21:07.270
toisessa esimerkissä, email oikeasti kulkee[br]Alicen järjestelmän läpi, se tarkoittaa,

0:21:07.270,0:21:11.880
että Alicella on voimaa tehdä jotain, [br]tehdä lisätarkastuksia, tutkia jne.

0:21:11.880,0:21:16.190
Mutta kuten näet jatkossa, on helpompaa[br]suojata ensimmäistä esimerkkiä.

0:21:16.190,0:21:21.710
Eli, vaikka asiakkaamme on Alice, me[br]koitamme suojata Alicea,

0:21:21.710,0:21:26.540
mutta se on helpompaa suojata käytännössä[br]tässä esimerkissä kun toinen on myy...

0:21:26.540,0:21:32.800
lähettämässä emailia, yrittämässä matkia[br]Alicea. Okei, Oh, Yeah. On myös kolmas

0:21:32.800,0:21:37.690
esimerkki, jossa Alice kommunikoi hänen[br]kollegoidensa kanssa saman

0:21:37.690,0:21:41.821
organisaation sisäisesti. Jälleen, olemme [br]Chuck. Taas, me vain lähetämme emailia

0:21:41.821,0:21:47.590
Alicen sisääntulevalle palvelimelle. Ei [br]lähtevälle. Oikein. Tärkeää huomata.

0:21:47.590,0:21:54.460
Ja taas, periaatteessa, tämä kolmas[br]esimerkki on helpoin huomata, koska

0:21:54.460,0:21:59.790
Alicen organisaatio oletettavasti tietää,[br]että hänen emailien pitäisi aina tulla

0:21:59.790,0:22:03.790
Tältä tietyltä lähtevien palvelimelta.[br]Just. Jos vaikka lähetetään emailia

0:22:03.790,0:22:08.780
Alicen kollegalta, silloin saapuvien [br]palvelimella pitäisi olla kaikki valta

0:22:08.780,0:22:15.610
Ilman mitään standardeja ja sellaisia.[br]Todellisuudessa, joskus, oikeastaan aika

0:22:15.610,0:22:24.140
usein, siinä on erityinen whitelist Alicen[br]omalle organisaatiolle. Joten joitain

0:22:24.140,0:22:28.880
tarkastuksia ei tapahdu jos Alicen saapuvien[br]palvelin ottaa emailin vastaan, joka tulee

0:22:28.880,0:22:34.610
taas, Alicelta. Ja muuten, meillä on tämä[br]esimerkki. Olemme nähneet sitä parina

0:22:34.610,0:22:38.730
viime vuonna. Luulen että se ei ole ainoastaan[br]Latviassa. Eli tässä, esimerkiksi, on Canada

0:22:38.730,0:22:43.590
ja muut, jos näette. Nämä ovat näitä[br]emaileja, jotka ovat fakeja, ransomwarea yms.

0:22:43.590,0:22:48.290
Periaatteessa ne kertovat, että he ovat[br]hakkeroineet tietokoneesi tai

0:22:48.290,0:22:53.820
sähköpostisi. Tässä tapauksessa, ja he ovat[br]järjestelleet kaikenlaisia talous juttuja tai

0:22:53.820,0:22:59.160
joku kiristää sinua. Ja pyytävät sinua[br]lähettämään heille rahaa. Sinun rahaasi.

0:22:59.160,0:23:04.520
Tarkoitan, rahaasi bitcoineina heidän[br]osoitteeseen. Eli nämä sähköpostit.

0:23:04.520,0:23:08.920
Kiinnostavaa näissä emaileissa on, että[br]yleensä todistaakseen sinulle että heillä

0:23:08.920,0:23:13.210
on pääsy sähköpostiisi. He lähettävät[br]sähköpostin sinun osoitteestasi sinun

0:23:13.210,0:23:20.100
osoitteeseen. Ja monelle ihmiselle, se[br]toimii. Eli he näkevät, että joku on

0:23:20.100,0:23:22.730
hakkeroinut heidän tilinsä, selkeästi,[br]koska he saivat sähköpostin itseltään.

0:23:22.730,0:23:28.620
Kuten näet hetken päästä, on oikeasti[br]helppoa väärentää sellainen email, jos

0:23:28.620,0:23:34.100
mitään suojauksia ei ole asetettu[br]paikoilleen. Eli tärkeä

0:23:34.100,0:23:38.120
asia. Toivon, että nyt kukaan yleisössä[br]ei sorru tällaiseen huijaukseen.

0:23:38.120,0:23:43.910
Mutta jos teillä on ystäviä tai kollegoja,[br]jotka ovat ottaneet yhteyttä ja kertoneet

0:23:43.910,0:23:48.230
sellaisista emaileista joita he ovat saaneet.[br]Mutta yksi asia sen lisäksi, että tarkastavat

0:23:48.230,0:23:53.110
salasanansa on alkaa käyttämään tehokkaampia[br]autentikointeja on, että ehkä voisit

0:23:53.110,0:23:57.770
pyytää heitä ottamaan yhteyttä [br]email admineihin tai

0:23:57.770,0:24:03.470
IT teamiin ja kysyä heiltä anti-spoofing[br]suojauksista, koska todella jos he voivat

0:24:03.470,0:24:09.020
vastaanottaa sellaisen emailin ja sitä[br]ei suodateta, jotain on vialla.

0:24:09.020,0:24:16.990
Okei, ja nyt katsotaanpa väärennettyä email[br]keskustelua, tämä esimerkki on vastaava

0:24:16.990,0:24:22.090
kuin edellinen. Mutta tässä olemme oikeasti[br]Chuck. Eli tämän on lähettänyt Chuck Bobille,

0:24:22.090,0:24:25.920
mutta esitämme olevamme Alice. Kysymys[br]on, voitko nähdä eron

0:24:25.920,0:24:30.110
kuinka tämä on erilainen kuin edellinen.[br]Ja on vaikeaa havaita

0:24:30.110,0:24:33.230
eroa, koska sitä ei ole.[br]Tämä on sama keskustelu.

0:24:33.230,0:24:39.540
Eli, juttu tässä on, että SMTP protokollassa[br]ei itsessään oikeasti ole mitään suojausta.

0:24:39.540,0:24:43.640
Eli, yeah, voisit vain esimerkiksi, jos [br]olet tuo tyyppi, joka lähettää fake

0:24:43.640,0:24:49.580
kiristyskirjeitä, voit vain kirjoittaa[br]tämän tekstin ja dumpata sen

0:24:49.580,0:24:55.830
telnetiin ja se toimii monelle [br]organisaatiolle. Ei kaikille tietenkään,

0:24:55.830,0:25:01.210
email adminit tietävät nämä jutut, tietävät[br]että SMTP ei ole luotettava tällä tavalla.

0:25:01.210,0:25:05.070
Se on helppo väärentää ja niin edelleen.[br]Ja on ollut useita yrityksiä lisätä jotain

0:25:05.070,0:25:11.520
suojausta, vähän ad hoc tapaisesti. Eli[br]ei standardeja, jotain kiristyksiin, lisää

0:25:11.520,0:25:15.950
filttereitä ja juttuja omaan mailiisi.[br]Ja jotkut näistä suojauksista rikkovat

0:25:15.950,0:25:20.640
oikeasti RFCta. Jos luet sitä, mutta ketä[br]kiinnostaa? RFC ei ole kuten pyhä teksti,

0:25:20.640,0:25:26.260
vai onko. Hyväksyn tämän täysin, esimerkiksi.[br]Yeah, jatketaan. Mutta ongelma on, ettei

0:25:26.260,0:25:31.640
ole tarpeeksi tietoa.[br]Eli, jos mietit täällä, jos olemme Bob

0:25:31.640,0:25:35.100
ja koitamme suojata järjestelmämme.[br]Eli olemme Bob, joku system admin varmaan

0:25:35.100,0:25:39.730
tai Bob on sys admin ja koitamme lisätä[br]joitain sääntöjä ja juttuja,

0:25:39.730,0:25:44.590
mitä voimme oikeasti tehdä. Eli yksi[br]esimerkki jonka listasin tähän on tehdä

0:25:44.590,0:25:49.980
tämä SMTP takaisinsoitto, ja se tarkoittaa[br]että juuri kun vastaanotamme emailin

0:25:49.980,0:25:56.970
Alicelta, me oikeasti tarkistamme että se[br]email on olemassa. Koska monet spammerit,

0:25:56.970,0:26:02.000
mitä ne tekevät, ne vain lähettävät emailia[br]olemattomista osoitteista se toimii

0:26:02.000,0:26:08.640
jos sinä ajat vain raakaa SMTP palvelinta.[br]Eli SMTP takaisinsoitossa, periaatteessa

0:26:08.640,0:26:13.300
kun olet vastaanottamassa emailia,[br]esimerkiksi Alicelta, koitat. Ajat,

0:26:13.300,0:26:17.220
käynnistät erillisen prosessin, joka [br]yrittää ottaa yhteyttä takaisin Aliceen, jne.

0:26:17.220,0:26:24.500
Ja se koittaa lähettää hänelle emailia, jos[br]palvelin sanoo Yeah, se on OK. Sellainen

0:26:24.500,0:26:27.540
sähköposti on olemassa jne. Sinä et ole,[br]Sinä oikeasti lopetat keskustelun.

0:26:27.540,0:26:31.290
Et jatka emailin lähetystä, mutta sinun[br]järjestelmä voi automaattisesti huomata

0:26:31.290,0:26:36.570
että tämä sähköposti on olemassa.[br]Toinen tapa tehdä tämä on tarkastamalla

0:26:36.570,0:26:42.030
tämä "Hello". Ja tämä on ensimmäinen rivi[br]ja ensimmäisellä rivillä, sen tavallisesti

0:26:42.030,0:26:48.000
pitäisi kertoa sinulle hostname[br]palvelimella joka lähettää emailia.

0:26:48.000,0:26:52.580
Kiinnostava osa. Eli RFCn mukaan jälleen,[br]sinun ei pitäisi tarkastaa että olet

0:26:52.580,0:26:56.540
varmentanut sen. Ja jos se ei onnistu, jos[br]se on satunnainen, sinun pitäisi hyväksyä

0:26:56.540,0:27:04.520
email silti. Mutta mitä monet palvelimet[br]tekevät, ne koittavat varmentaa sen.

0:27:04.520,0:27:07.800
Ensinnäkin, tällä hostnamella kerrot, että[br]sinulla on tämä hostname joka

0:27:07.800,0:27:12.800
oikeasti osoittaa samaan IP osoitteeseen[br]ja he tekevät päinvastoin. Eli he

0:27:12.800,0:27:18.880
ottavat IP osoitteen ja koittavat ajaa[br]käänteisen DNS PTR kyselyn ja koittavat

0:27:18.880,0:27:23.150
selvittää täsmääkö IP osoite oikeasti[br]tähän hostnameen. Eli jälleen,

0:27:23.150,0:27:26.520
pentestaajina meidän tulisi olla tietoisia[br]näistä suojauksista, ad hoc, suojauksista

0:27:26.520,0:27:31.040
koska jos et tunne niitä, koitat[br]ajaa jotain ja se ei toimi

0:27:31.040,0:27:34.700
sinulla. Mutta ne ovat helppoja jos[br]olet niistä tietoinen ja jos sinun täytyy

0:27:34.700,0:27:40.470
tunnistaa, että tämä organisaatio käyttää[br]niitä. Ne ovat helppoja ohittaa, eli ne eivät

0:27:40.470,0:27:44.530
tarjoa hyvää suojaa. Niiden tarkoitus on [br]suojata massa hyväksikäytöltä, spammilta.

0:27:44.530,0:27:52.910
OK, eli SMTP, kuten näimme, itsessään ei[br]tarjoa minkäänlaisia suojauksia.

0:27:52.910,0:27:59.380
Eli mitä lisäyksiä protokollaan voimme[br]oikeasti käyttää suojataksemme itseämme ?

0:27:59.380,0:28:06.860
Yksi sellainen protokolla on SPF. Ja mitä[br]SPF tekee, se koittaa olla kuten peili

0:28:06.860,0:28:12.870
MX järjestelmässä. MX järjestelmä on se,[br]jota periaatteessa Alica voi käyttää,

0:28:12.870,0:28:18.150
Jota Alicen palvelin voi käyttää löytämään[br]automaattisesti palvelimen joka kuuluu Bobille

0:28:18.150,0:28:24.580
ja sen saapuvien palvelimen. Eli SPF on sen[br]vastakohta. Eli sen idea tässä on

0:28:24.580,0:28:30.270
olla automaattisesti ajossa Bobin saapuvien[br]palvelimella. Ja nyt kun Bob

0:28:30.270,0:28:35.720
vastaanottaa emailin, ne voivat ajaa taas[br]DNS kyselyn ja selvittää minkä IP osoitteiden

0:28:35.720,0:28:41.820
oikeasti pitäisi kuulua Alicen lähtevien[br]palvelimelle. Just. Eli mielestäni se on

0:28:41.820,0:28:45.780
helppoa ymmärtää, se on merkityksellinen[br]tapa. Se kuulostaa merkittävälle

0:28:45.780,0:28:52.570
lisäykselle. Ja yksi asia, joka tarkastetaan[br]tässä esimerkissä on kirjekuoren

0:28:52.570,0:28:59.360
lähettäjä. OK. Ja tässä on esimerkki[br]minimi SPF syntaxista ja kuten voimme

0:28:59.360,0:29:04.610
nähdä. Mielestäni sitä on helppo ymmärtää,[br]vaikka et tietäisi mikä syntaxi on, se listaa

0:29:04.610,0:29:08.470
IP osoitteet, mikä on IP, pitäisi olla IP[br]osoite lähtevien palvelimelle, oikealle

0:29:08.470,0:29:12.780
lähtevien palvelimelle. Ja sitten se sanoo[br]tässä "-all", joka taas on helppo ymmärtää

0:29:12.780,0:29:18.700
Tässä tapauksessa, se tarkoittaa, että se[br]on ainoa. Eli jos vastaanotat viestin,

0:29:18.700,0:29:22.980
viesti tulee tästä IP osoitteesta. Se on[br]hyvä. Hyväksy se. Jos se on jotain muuta

0:29:22.980,0:29:27.190
sitten poista se. Ja on monia tapoja[br]määrittää IP osoite. Voisit vain

0:29:27.190,0:29:31.610
määrittää IP osoitteen, voisi määrittää[br]IP aliverkon, voisit määrittää DNS nimen

0:29:31.610,0:29:37.070
Eli se on ainoastaan admineille. Eli[br]periaatteessa pentestaajalle se ei tee

0:29:37.070,0:29:44.750
paljoa eroa, admineille se vain helpottaa[br]järjestelmien ylläpitoa. Ja sitten ovat

0:29:44.750,0:29:49.620
nämä määreet, määreet. Tämä on jotain[br]jotat laitat

0:29:49.620,0:29:56.160
ennen metodeja. Esimerkiksi, tässä[br]esimerkissä, IPv4:ssa ei ollut mitään

0:29:56.160,0:30:00.100
määreitä. Siinä ei ole plussaa tai miinus[br]tai jotain. Se johtuu siitä, että plus

0:30:00.100,0:30:03.910
on oletus vakiona. Eli vakiona, kaikki[br]mikä on listattu SPF määrityksissä pitäisi

0:30:03.910,0:30:12.600
täsmätä johinkin oikeaan SMTP palvelimeen,[br]lähtevien palvelimeen. Kuitenkin, on muita

0:30:12.600,0:30:15.850
vaihtoehtoja, voit käyttää miinusta joka[br]on fail. Ja se tarkoittaa että jos jokin

0:30:15.850,0:30:20.380
täsmää kirjaukseen, esimerkiksi, miinus[br]all, joka on eniten käytetty,

0:30:20.380,0:30:26.710
se tarkoittaa, että jos se täsmää tähän,[br]se on yleensä viimeinen, niin tuhoa

0:30:26.710,0:30:32.090
sähköposti. Se ei ole oikea. Se on fake[br]email. Ja sitten on kolmas vaihtoehto,

0:30:32.090,0:30:37.150
joka on soft fail, joka on tarkoitettu [br]testauksen ajaksi. Eli kun olet juuri

0:30:37.150,0:30:42.690
alkamassa implementoimaan SPFaa, siinä[br]voisi olla. Eli ongelma on, että saattaisit

0:30:42.690,0:30:47.730
unohtaa, esimerkiksi, lisätä joitain SMTP[br]palvelimia. Eli, koska et ole tehnyt sitä

0:30:47.730,0:30:52.750
ennen, ehkä luulit, että sinulla on vain[br]yksi oikea SMTP lähtevien palvelin, mutta

0:30:52.750,0:30:56.360
oikeasti sinulla on useita, tai useita [br]tapoja lähettää sähköpostia. Eli siinä

0:30:56.360,0:31:03.600
tapauksessa, jos alkaisit asettamaan SPF[br]asetuksia "fail" tiukalla politiikalla,

0:31:03.600,0:31:07.230
sinun käyttäjät eivät voisi lähettää enää[br]viestejä. Eli sen takia testaaminen on

0:31:07.230,0:31:13.460
hyvä. Kuitenkin. On myös muita esimerkkejä,[br]vähän monimutkaisempia, yksi niistä oli

0:31:13.460,0:31:16.400
include. Eli sen sijaan, että määrität[br]policyn itse, koska käytät kolmatta

0:31:16.400,0:31:19.270
osapuolta, esimerkiksi, Googlea tässä[br]tapauksessa, ja sitten vain

0:31:19.270,0:31:24.720
sisällytät mitä tahansa Google on [br]julkaissut. Ja kiinostava juttu tässä on

0:31:24.720,0:31:31.530
tämä SPFn käyttö. Jos me vain, jos vain[br]katsomme niiden domainien määrää

0:31:31.530,0:31:36.890
jolle olemme laittaneet jonkun policyn,[br]se näyttää hyvältä. Arvaan, että esimerkiksi

0:31:36.890,0:31:42.290
kaikkein suosituimmat domainit, se olisi[br]noin 70 prosenttia. Mutta ongelma on,

0:31:42.290,0:31:45.710
ettö valtaosa niistä on joko huonosti[br]konfiguroituja tai ne käyttävät ainoastaan

0:31:45.710,0:31:51.790
softail optiota. Ja soft fail ei käytännössä[br]tee mitään. Voit siitä huolimatta, että

0:31:51.790,0:31:56.700
policy on soft failissa, voit useimmissa[br]tapauksissa väärentää sähköpostisi

0:31:56.700,0:32:00.720
ja se menee läpi, koska vastaanttava puoli[br]ajattelee että se on vain testimoodissa.

0:32:00.720,0:32:07.940
Sinun pitäisi poistaa email automaattisesti.[br]Yeah. Eli. Oikeasti prosentit eivöt

0:32:07.940,0:32:13.910
ole kovin hyvät. Kuitenkin, tärkeintä [br]meille penetraatiotestaajina on

0:32:13.910,0:32:18.420
ymmärtää. Eli mitä teemme kun näemme[br]tämän SPFn. Se tarkoittaa että emme voi

0:32:18.420,0:32:24.670
väärentää postiaja. Ei, ei niin. Että se[br]olisi game over meille. Voimme tehdä

0:32:24.670,0:32:30.060
juttuja. Ensinnäkin, on tämä soft fail jonka[br]mainitsin. Ja siinä periaatteessa sinulla

0:32:30.060,0:32:33.830
on jotain sääntöjä, sääntöjä, sääntöjä, ja[br]lopuksi, laitat tavallisesti tämän

0:32:33.830,0:32:41.460
soft failin kaikille. Joten jos me[br]pentestaajina koitamme väärentää jostain

0:32:41.460,0:32:46.330
tuntemattomasta IP osoitteesta. jota ei ole[br]listattu edellisissä säännöissä. Älä tee

0:32:46.330,0:32:51.520
mitään. Tee mitään. Tarkoitan älä estä[br]emailia. Se on hyvä meille, eikös ?

0:32:51.520,0:32:56.720
Se tarkoittaa, että voimme väärentää aivan[br]vanhaan tapaan ja se yleensä toimii.

0:32:56.720,0:33:02.250
Yksi hyvä huomio tässä on, että jotkut[br]järjestelmät ovat, eivät käytä vain tätä

0:33:02.250,0:33:06.590
binääristä luokittelua, onko jokun hyvä[br]tai paha, vaan ne koittavat tehdä jotain

0:33:06.590,0:33:11.320
pisteytystä. Ja voi olla, että vaikka [br]olisikin tämä soft fail, he eivät

0:33:11.320,0:33:16.370
automaattisesti estä sinun emailia, vaan[br]ehkä he lisäävät jotain epäilyksen tasoa

0:33:16.370,0:33:22.540
siihen. Mutta tärkeä asia on, ettei se[br]ole automaattisesti game over.

0:33:22.540,0:33:29.970
Toinen juttu on tämä include. Eli include[br]on hyvin käytännöllinen jos käytät kolmansia

0:33:29.970,0:33:36.330
osapuolia. Mutta ongelma on, että se ei[br]ole sitä miltä kuulostaa joillekin, edes

0:33:36.330,0:33:43.100
standardissa, se mainitsee, että se oli[br]huonosti valittu nimi. Ja syy tähän

0:33:43.100,0:33:48.110
ettei se ole macro. Eli ymmärtääksesi[br]mitä tapahtuu kun tämä includataan,

0:33:48.110,0:33:52.720
sinun ei pitäisi vain leikata ja liimata[br]kaikkea rekursiivisesti ylätasolle.

0:33:52.720,0:33:58.340
Se ei ole miten se toimii. Se koittaa[br]ajaa kaikkia testejä tämän includen

0:33:58.340,0:34:05.480
sisäpuolella. Mutta jos se epäonnistuu, se[br]ai automaattisesti poista viestiä. Se menee

0:34:05.480,0:34:10.250
yhtä tasoa ylemmäs ja se koittaa ajaa[br]toisia sääntöjä. Ongelmana siinä

0:34:10.250,0:34:14.510
on, että kaksi tapausta jotka ovat[br]tavallisimipia ovat, että joko vain

0:34:14.510,0:34:20.570
unohdat lisätä miinuksen kaikkiin tai[br]se on sinun system admin joka on

0:34:20.570,0:34:26.470
unohtanut sen. Siitä tapauksessa, vaikka[br]he lisäävät miinuksen kaikkiin, se ei toimi

0:34:26.470,0:34:34.089
koska, tarkoitan, se toimisi kun vastaan-[br]ottaja tarkastaa sitä miinus kaikki

0:34:34.089,0:34:39.569
includen sisällä ei tarkoita samaa, kuin[br]mitä se tarkoittaa top levelillä. Ja

0:34:39.569,0:34:43.799
toinen olisi, että he ovat lisänneet kaiken,[br]mutta soft failanneet. Ja sitten adminit

0:34:43.799,0:34:47.809
miettivät. Mutta se in okei, koska sisällytän[br]GMailin ja GMailissa on tämä hard fail.

0:34:47.809,0:34:54.409
Se ei toimi niin. Ja lisäksi, tämä on[br]todellisuudessa mielestäni yleisin tapaus,

0:34:54.409,0:35:00.000
on, että usein kun näet oikeasti tämän [br]tyyppisen SPF listan, mutta siinä

0:35:00.000,0:35:03.569
listan sisällä on paljon juttuja IP[br]osoitteita. Siellä on A kirjauksia

0:35:03.569,0:35:07.890
siellä on MX kirjauksia, Siellä on pointer.[br]Periaatteessa, mitä vain admin voisi

0:35:07.890,0:35:12.990
kuvitella ja syy tähän yleensä on että[br]he eivät ole varmoja miten se toimii.

0:35:12.990,0:35:17.100
He eivät ole varmojja mitä sinne tulisi [br]laittaa. Eli esimerkiksi, yksi juttu

0:35:17.100,0:35:24.840
jonka osoittaa on, että jos siellä on MX[br]tietue SPF listan sisällä, yleensä useissa

0:35:24.840,0:35:27.930
organisaatioissa, elleivät ne ole hyvin[br]pieniä ja heillä on vain yksi palvelin

0:35:27.930,0:35:31.059
heillä on eri palvelimia, eri IP osoitteita[br]lähtevälle postille ja saapuvalle

0:35:31.059,0:35:34.500
postille. Tämä tarkoittaa,ettei ole [br]käytännön syytä tälle organisaatiolle

0:35:34.500,0:35:41.109
ei käytännön syytä lisätä MXaa SPFaan[br]koska ei, ei postia pitäisi lähteä läpi

0:35:41.109,0:35:45.900
heidän saapuvan postin palvelimesta. Ja [br]toinen juttu voi olla, että admin tietää

0:35:45.900,0:35:51.470
tietää miten se toimii, mutta heidän oma[br]arkkitehtuuri on tosi sekainen ja he

0:35:51.470,0:35:55.730
lähettävät postia ulos monesta, monesta eri[br]pisteestä, mikä on kiva pentestaajille.

0:35:55.730,0:36:03.359
Se tarkoittaa etteivät he ole hyvin [br]organisoituneita. OK ja on vielä yksi vika,

0:36:03.359,0:36:09.220
joka on, ettei hienojakoisuus sovi hyvin.[br]Eli ainoa juttu jota voit.

0:36:09.220,0:36:13.799
On useita näitä kirjaus tyyppejä. Mutta[br]ne kaikki varsinaisesti resolvaavat IP

0:36:13.799,0:36:19.650
osoitteen. Mutta kuten voit kuvitella,[br]usein IP ei ole yhdistetty vain email

0:36:19.650,0:36:24.230
palvelimeen. Eli yhdessä IPssa voi olla mail[br]palvelin ja web palvelin tai tietokanta tai

0:36:24.230,0:36:28.069
jotan muuta. Ja se tarkoittaa, että[br]pentestaajana, voit exploitata tämän

0:36:28.069,0:36:32.339
jonkun muun. EI mail serveriä itseään,[br]koska postipalvelin on yleensä aika pieni

0:36:32.339,0:36:36.740
kohde. Niissä ei ole paljon haavoittuvuuksia.[br]SInä vain päivität ne ja se siitä.

0:36:36.740,0:36:42.740
Mutta muissa järjestelmissä, esimerkiksi[br]web on helppo murtaa. Yleensä.

0:36:42.740,0:36:46.680
Sitten voit nostaa, kuten tavallaan nostaa[br]oikeustasoa saadessasi pääsyn jonkun

0:36:46.680,0:36:50.809
toisen palvelun kautta siinä IP osoitteessa[br]tai IP alueessa. Voit alkaa lähettämään

0:36:50.809,0:36:59.859
posteja. Ne läpäisevät kaikki SPF suodatukset.[br]OK. Eli yksi esimerkki ovat jaetut hostaukset

0:36:59.859,0:37:04.950
joka on hyvin tavallista ja ongelma jaetussa[br]hostauksessa on se. Tässä tapauksessa.

0:37:04.950,0:37:10.359
Okei. Sinulla on IP osoite SMTP palvelimelle.[br]Ehkä sitä palvelinta käytetään vain lähettämään

0:37:10.359,0:37:15.900
postia. Mutta palvelin itsessään ei tee[br]työtä vain sinulle. Se palvelee monia

0:37:15.900,0:37:18.849
domaineja, ehkä satoja tai tuhansia. Se[br]tarkoittaa, että hyökkääjänä, taas, voit

0:37:18.849,0:37:24.289
exploitata vain yhden niistä, tai jaetussa[br]hostauksessa voit vain ostaa. Voit tulla

0:37:24.289,0:37:26.940
asiakkaaksi siihen jaettuun hostaukseen.[br]Sinun ei tarvitse murtaa mitään.

0:37:26.940,0:37:31.750
Ja sitten voit ehkä alkaa lähettämään[br]emailia, joka näyttää hyvältä SPFaa

0:37:31.750,0:37:38.140
ajatellen, kuten heidän omaansa. Eli. Ja[br]toinen on että tarkastetaan väärä identifier.

0:37:38.140,0:37:44.960
Ja tämä on varmaankin pahin, pahin [br]ongelma SPFn kanssa. Se on, kuten

0:37:44.960,0:37:49.640
kerroin aiemmin, se että on ainakin[br]kaksi identifieria. Tyypillisesti kuoren

0:37:49.640,0:37:53.740
lähettäjä, ulompi, joka listaa lähettäjän[br]sitten on se sisempi,

0:37:53.740,0:37:58.589
joka on yleensä "from" headeri.[br]Mutta näistä kahdesta SPF tarkastaa,

0:37:58.589,0:38:03.140
jos SPF on ainoa teknologia jota käytät,[br]SPF tarkastaa vain ensimmäisen:

0:38:03.140,0:38:09.059
Kuoren lähettäjän. Kuten kerroin aiemmin,[br]useimmissa tapauksissa, oikeat käyttäjät

0:38:09.059,0:38:13.279
jotka saavat mailin, he eivät näe kuoren[br]lähettäjiä. He näkevät tämän toisen

0:38:13.279,0:38:17.559
"from" esimerkiksi, tai jonkun niistä[br]toisista headereista joita mainittiin.

0:38:17.559,0:38:22.830
Tämä käytös on oikeasti korjattu DMARCssa,[br]joka on teknologia jonka mainitsin. Mutta

0:38:22.830,0:38:27.319
valtaosassa SPF asennuksista, domaineissa,[br]joissa SPF käytössä ei ole DMARCia,

0:38:27.319,0:38:31.329
eli ne eivät ole suojassa tältä. Eli vaikka[br]heidän SPF olisi hienosti hyökkääjälle,

0:38:31.329,0:38:36.630
se tarkoittaa, että sinun tarvitsee vain,[br]sinun pitää vain ohittaa SPF asettaaksesi

0:38:36.630,0:38:40.430
kuoren lähettäjän joksikin toiseksi. [br]Esimerkiksi, sinun kontrolloima osoite,

0:38:40.430,0:38:49.010
joka läpäisee SPF tarkastuksen. Mutta sitten[br]"from" sisällä voit näyttää headerin, joka

0:38:49.010,0:38:56.776
täsmää organisaatioon, joka haluat matkia[br]olevasi. Okei. Sitten on toinen

0:38:56.776,0:39:02.309
teknologia, jonka pitäisi korjata tämä[br]ja se on DKIM. Kuten olemme nähneet

0:39:02.309,0:39:11.450
SPF ei ole riittävä. Eli DKIM. Anteeksi,[br]väärät kirjaimet, DomainKeys Identified Mail.

0:39:11.450,0:39:15.099
Se on DKIM ja sinun ei tarvitse muistaa [br]pitkää nimeä, vain lyhyt nimi.

0:39:15.099,0:39:20.223
Ja mitä se tekee, periaatteessa se käyttää[br]kryptografiaa, mikä on kiva, eikös? Se on

0:39:20.223,0:39:24.640
matikkaa. Se on hankalaa murtaa hyökkääjälle.[br]Ja mitä se tekee, se allekirjoittaa jokaisen

0:39:24.640,0:39:29.870
postin eli jokainen posti joka lähtee [br]DKIM käyttävältä palvelimelta saa

0:39:29.870,0:39:35.059
allekirjoitujsen, jonka voit, vastaanottajana,[br]kryptografisesti varmistaa. Joten kuten näet,

0:39:35.059,0:39:39.940
se vaikuttaa aika vaikealta nähdä, koska[br]sitä ei ole tarkoitettu ihmisten

0:39:39.940,0:39:44.160
prosessoitavaksi. Se on kryptografiaa.[br]se on tarkoitettu prosessoitavaksi tietokoneille.

0:39:44.160,0:39:48.300
Mutta tärkeä osa tässä on periaatteessa[br]keltainen osa joka on kryptografinen

0:39:48.300,0:39:55.880
allekirjoitus. Mutta vihreä osa on, mitä[br]kutsutaan domain tunnisteeksi. Ja punaista

0:39:55.880,0:40:02.269
osaa kutsutaan. En muista miksi sitä[br]sanotaan <i>nauraa</i>. Mutta periaatteessa sen

0:40:02.269,0:40:07.160
idea on, että sinulla voi olla useita avaimia[br]organisaatiollasi, esimerkiksi, organisaatiosi

0:40:07.160,0:40:12.390
voisi lähettää posteja sinun alkuperäiseltä[br]SMTP palvelimelta, sitten sinulla voisi olla

0:40:12.390,0:40:17.650
varalla yksi, tai voisi olla, voisit [br]lähettää joitain viestejä Googlesta tai

0:40:17.650,0:40:21.759
joku markkinointikampanja ja niin edelleen.[br]Ja jokaisella näistä voisi olla erilainen

0:40:21.759,0:40:26.970
"punainen" parametrina. Ongelma on ja[br]sitten vastaanottajan pitää ajaa DNS kysely,

0:40:26.970,0:40:32.532
joka on toinen esimerkki käyttäen tätä[br]yhdistelmää vihreä ja punainen.

0:40:32.532,0:40:36.993
Ja sitten ne hakevat julkisen avaimen ja[br]voivat käyttää sitä varmistamaan alle-

0:40:36.993,0:40:43.799
kirjoituksen. Eli se kuulostaa hyvälle.[br]Ongelma on, ei, toinen ongelma vielä.

0:40:43.799,0:40:48.730
Kuinka käyttää sitä? Luulen sitä helpoksi [br]jos osaat julkisen avaimen salausta. Eli

0:40:48.730,0:40:52.440
lähetys päässä, sinun pitää ensin luoda[br]julkinen ja salainen avainpari. Sitten

0:40:52.440,0:40:56.270
julkaiset julkisen osan DNSaan. Sitten[br]käytät salaista avainta allekirjoittamaan

0:40:56.270,0:41:00.480
viestit. Nyt vastaanottaja tekee tavallaan[br]päinvastoin. Kun he saavat emailin, he

0:41:00.480,0:41:04.380
päättelevät tästä punaisesta ja vihreästä[br]osasta he päättelevät oikean DNS tiedon

0:41:04.380,0:41:09.000
jonka ajaa, ajavat sen, saavat julkisen [br]avaimen ja vertaavat sitä täsmääkö tämä

0:41:09.000,0:41:12.526
julkinen avain viestin allekirjoitukseen.[br]Kuulostaa kivalta, eikös? Mikä on ongelma?

0:41:12.526,0:41:19.170
Eli asiakkaat. Selektorit, se on se nimi.[br]Eli ongelma siinä on se, että selektoreina

0:41:19.170,0:41:27.309
voi olla useita selektoreita DKIM:na[br]kun teet konfiguraatiota,

0:41:27.309,0:41:31.670
voit voit valita niin monta kustom[br]selektoria kuin haluat ja vastaanottaja

0:41:31.670,0:41:37.170
ei tiedä, olisiko sinun oikeasti pitänyt[br]käyttää selektoria ja mitä

0:41:37.170,0:41:41.599
selektoria sinun olisi pitänyt käyttää.[br]Eli ongelma on että kun, jos puhumme vain

0:41:41.599,0:41:48.690
vanilja DKIMsta, olemassa olevan alle-[br]kirjoituksen muokkaaminen on vaikeaa

0:41:48.690,0:41:52.630
penaajalle ja hyökkääjälle. Mutta on helppoa[br]vain poistaa se, koska jos olet poistanut

0:41:52.630,0:41:57.619
DKIMn kaikista headereista, vastaanottaja[br]ei tiedä, että sen olisi pitänyt olla

0:41:57.619,0:42:03.550
siinä, koska tarkistaakseen sen, se pitää[br]olla. Eli, esimerkiksi, tarkastaakseni

0:42:03.550,0:42:08.640
allekirjoituksen, minun pitää tietää tämä[br]vihreä osa. Tämä domain tunniste ja

0:42:08.640,0:42:14.712
selektori, jotka ovat osa headeria. Just.[br]Eli se on valtava ongelma. Ja se tarkoittaa

0:42:14.712,0:42:20.818
että. Yeah. Se tarkoittaa, että vaikka [br]me emme voi huijata DKIMaa itseään

0:42:20.818,0:42:26.700
voimme vain leikata DKIMn, lähettää viestin[br]ilman sitä. Ja jos DKIM oli ainoa asia joka

0:42:26.700,0:42:31.499
suojasi tätä järjestelmää, se toimii. Eli[br]se ei välttämättä saisi vihreää merkkiä

0:42:31.499,0:42:37.310
tai jotain, mutta se menisi vastaanottajalle.[br]Ja toinen juttu on tämä

0:42:37.310,0:42:43.040
domain selektor. Miksi meidän pitää edes[br]asettaa se? Koska parhaissa käytännöissä,

0:42:43.040,0:42:48.280
tietenkin, on että kuoren lähettäjä on sama[br]kuin "from" header ja tämä DKIM domain

0:42:48.280,0:42:52.430
selektori. Just. Eli jos olet jos minä [br]lähetän Alicelta, niin kaikkien kolmen

0:42:52.430,0:42:59.029
pitäisi olla Alice.org tai jotain. Ongelma[br]on ettei sitä ole mainittu RFCssa että

0:42:59.029,0:43:04.029
näin pitäisi olla. Eli mitä tapahtuu jos[br]asia ei ole näin ?

0:43:04.029,0:43:09.619
Erimerkiksi, oikealla on joku oikea domain[br]joka käyttää Gmailia, Google Appsia

0:43:09.619,0:43:17.470
Google suitea ja siinä tapauksessa vakiona[br]vakiona Google suite allekirjoittaa kaikki

0:43:17.470,0:43:22.430
viestit. Mutta jos et tee omaa[br]konfiguraatiota, se allekirjoittaa ne

0:43:22.430,0:43:28.369
domainilla jota hallinnoi, joka on tämä[br]"gappssmtp". Ja se tarkoittaa, että vaikka

0:43:28.369,0:43:32.579
teknisesti jotain on allekirjoitettu DKIMlla[br]sitä ei ollut allekirjoitettu siten, että

0:43:32.579,0:43:36.406
voisit jäljittää sen takaisin sinun [br]organisaatioon. Se on jotain aivan

0:43:36.406,0:43:40.069
muuta. Mitä vastaanottajan pitäisi tehdä[br]siinä tapauksessa? Pitäisikö jättää väliin?

0:43:40.069,0:43:43.859
Pitäisikö hylätä viesti tai jotain? Eli oikea[br]tapa ei olisi hylätä sitä,

0:43:43.859,0:43:49.380
mutta vaan arvioida, ettei se ole oikea,[br]ainakaan oikea DKIM, mutta oikeasti

0:43:49.380,0:43:53.829
se riippuu. Osa tarkastajista näkevät vain[br]jonkin DKIMn, tarkastavat sen ja

0:43:53.829,0:44:01.228
savovat että cool, se täsmää RFChen.[br]Eli, mutta nyt kiinostava osa. DKIM

0:44:01.228,0:44:06.710
muokkaaminen, johon minulla ei ole aikaa.[br]Mutta ajatus on, että joissain tapauksissa

0:44:06.710,0:44:11.339
ei aina, mutta joskus voit oikeasti muokata.[br]Helpoin osa muokata viestissä

0:44:11.339,0:44:17.190
ovat headerit koska DKIM, koska se laitetaan[br]headereihin itse, se ei automaattisesti

0:44:17.190,0:44:21.304
allekirjoita vanhoja headereita. On [br]tavallaan kana ja muna ongelma. Vakiona

0:44:21.304,0:44:26.170
se allekirjoittaa vain yhden tai kaksi headeria[br]ja voit määrittää lisää headereita joita pitää

0:44:26.170,0:44:30.910
allekirjoittaa, mutta se ei tapahdu auto-[br]maatisesti. Eli helppo osa hyökkääjälle

0:44:30.910,0:44:35.569
on lisätä headeri. Jos se jotenkin[br]auttaa sinua suunnitelmassasi, se on

0:44:35.569,0:44:40.400
helppo tehdä. Sinä vain lisäät toisen[br]headerin. Kiinnostava osa on, että

0:44:40.400,0:44:43.940
vaikka RFC, kuten mainitsin aiemmin, [br]mainitsee, että jotkut headerit kuten

0:44:43.940,0:44:49.180
"subject" tai "from" pitäisi olla paikalla[br]vain yhtenä kopiona. Oikeasti voit lisätä

0:44:49.180,0:44:53.093
enemmänkin, esimerkiksi "from" headerin ja[br]mitä tapahtuu siinä tapauksessa on aika

0:44:53.093,0:44:59.367
kiinnostavaa. DKIM täsmää jos olet kertonut[br]DKIMlle että "from" headerin pitäisi olla

0:44:59.367,0:45:04.150
esimerkiksi, allekirjoitettu, sitten se täsmää[br]ja allekirjoittaa ensimmäisen "from" headerin

0:45:04.150,0:45:11.279
alhaalta. Mutta monet ohjelmat meidän software[br]email ohjelmista todellisuudessa ainoastaan

0:45:11.279,0:45:16.807
näyttävät käyttättäjälle ensimmäisen toiselta[br]puolelta, ylhäältä. Eli se tarkoittaa, että

0:45:16.807,0:45:23.940
hyökkääjä voi muokkailla tai ylikirjoittaa[br]headereita vain lisäämällä uusia headereita

0:45:23.940,0:45:29.546
päälle. Ja tämä oikea ongelma on [br]mainittu DKIM RFCssa ja suojaus

0:45:29.546,0:45:33.089
jota he ehdottavat on tämä code[br]Over-Signing tai voit mennä ja lukea RFCn.

0:45:33.089,0:45:38.885
Mutta kaikki eivät tee sitä oikeasti. Ja[br]kuitenkin, se toimii vain headereille.

0:45:38.885,0:45:44.919
Eli joskus se on hyvä. Joskus ei niin hyvä.[br]Viestin rungon

0:45:44.919,0:45:49.499
muokkaaminen on oikeasti vaikeampi toteuttaa.[br]Periaatteessa naivi tapa tehdä se kryptauksen

0:45:49.499,0:45:54.069
kautta, jota emme halua tehdä. Ja toinen[br]tapa on tämän yhden parametrin

0:45:54.069,0:45:58.140
kautta, joka on body lenght, ja se on aikaa[br]kyseenalainen toiminnallisuus

0:45:58.140,0:46:05.118
DKIMssa. Joskus voit määrittää[br]että tiiviste vaikka. Allekirjoittamiseen,

0:46:05.118,0:46:08.789
meidän ei pitäisi ajatella koko runkoa,[br]vaan ensimmäisiä joitain tavuja.

0:46:08.789,0:46:13.790
Eli se on oikeasti käytännöllistä joissain[br]tapauksissa postituslistoissa, mutta yleensä

0:46:13.790,0:46:18.866
se ei ole kovin käytännöllistä. Ja käytännössä[br]valtaosa email ohjelmista ei tee sitä.

0:46:18.866,0:46:24.500
Jos se tekee, se on altis mahdollisesti[br]tälle koko

0:46:24.500,0:46:28.869
rungon ylikirjoittamiselle. Voit lisätä [br]uuden mime tyypin ja sitten muokata

0:46:28.869,0:46:34.245
headereita näyttääksesi eri mime tyypin[br]ja se ohittaa DKIMn. Eli tässä tapauksessa

0:46:34.245,0:46:37.569
se näyttää, esimerkiksi, vihreän painikkeen[br]tai mitä vaan, koska DKIM, se on oikein.

0:46:37.569,0:46:42.634
Eli nyt on kolman teknologia, jota [br]kutsutaan DMARCiksi. Ja taas,

0:46:42.634,0:46:47.640
siinä on koko nimi, joka on pitkä. Mutta[br]tässä tapauksessa se tarkoittaa jotain.

0:46:47.640,0:46:52.424
Siinä on kaksi avainsanaa: Reporting and[br]Conformance. Reporting on se

0:46:52.424,0:46:56.660
jonka suurin osa admineista tuntee, koska[br]sillä DMARC, luulen, usein myydään

0:46:56.660,0:47:01.619
heille. Raportointi tarkoittaa, että[br]kun sinulla on jotain ongelmia tässä

0:47:01.619,0:47:08.390
tapauksessa, sinä voit päästä kertomaan[br]toiselle puolelle mitä tehdä siinä tapauksessa.

0:47:08.390,0:47:13.309
Eli voit käskeä niitä lähettämään sinulle[br]raportteja kerran päivässä, tai joka kerta

0:47:13.309,0:47:16.886
ja niin edelleen. Eli pentestaajalle se ei[br]ole niin hyödyllistä. Mahdollisesti voisimme

0:47:16.886,0:47:20.509
käyttää sitä ymmästääksemme minkälainen[br]konfiguraatio toimii toisella puolella.

0:47:20.509,0:47:25.000
Mutta nykyisin tämä toiminnallisuus ei ole[br]kovin laajasti implementoitu.

0:47:25.000,0:47:30.309
Kuitenkin toinen osa, Conformance, se on[br]oikeasti todella, todella voimakas.

0:47:30.309,0:47:35.251
Mitä se tekee, se korjaa nämä suuret viat[br]joista mainitsin, SPFssa ja DKIMssa.

0:47:35.251,0:47:39.381
Ensinnäkin, DKIMssa oli tämä valtava ongelma[br]että jos poistit headerin, vastaanottajalla

0:47:39.381,0:47:43.109
ei ollut mahdollista tietää mikäli sinä,[br]mikäli siinä oli, olisi

0:47:43.109,0:47:49.377
pitänyt olla DKIM alunperin. Jos käytät[br]DKIMaa yhdessä DMARCin kanssa, se

0:47:49.377,0:47:55.269
korjaa ongelman, koska DMARC määrittää[br]että sinulla on DMARC itsensä.

0:47:55.269,0:47:59.220
Se tarkoittaa, että sinulla automaattiesti[br]toinen, joko SPF tai DKIM pitäisi mennä läpi.

0:47:59.220,0:48:03.576
Eli automaattisesti DKIM mittaus ongelma [br]ratkaistu. Toinen asia, joka muuttuu on,

0:48:03.576,0:48:08.599
se muuttaa semantiikkaa SPFaan. Nyt SPF,[br]jos sinulla on sekä SPF, että

0:48:08.599,0:48:13.150
DMARC, se tarkoittaa, ettö SPF pitäisi [br]tarkastaa "from" headerista. Ja kuten mainitsin,

0:48:13.150,0:48:17.319
se oli suuri vika SPFssa, koska jos käytit[br]SPFaa itseään, vaikka, se on hard fail

0:48:17.319,0:48:21.440
tilassa ja niin edelleen, se tarkoittaa [br]että hyökkääjä voi muokata "from"

0:48:21.442,0:48:26.710
headereita ja vastaanottaja ei tiedä sitä.[br]Pienin esimerkki DMARCsta on hyvin,

0:48:26.710,0:48:31.210
hyvin pieni. Ja mielestäni se on helppo[br]ymmärtää. Sinulla on vain DMARC hylkää.

0:48:31.210,0:48:36.890
Sinun pitää tavallaan löytää oikea paikka[br]määrittää, mutta se on helppoa ja kaikki

0:48:36.890,0:48:40.740
mitä sinun pitää tehdä, on luoda tämä DNS[br]merkintä. Ja kaikki hyödyt tähän ovat,

0:48:40.740,0:48:46.190
vaikka sinulla ei olisi DKIM ja DMARCia, jos[br]olet luonut. Anteeksi, jos sinulle ei ole SPF

0:48:46.190,0:48:50.680
ja DKIM, mutta olet luonut DMARCin, oikeasti[br]se tarkoittaa että tämän domainin ei

0:48:50.680,0:48:57.550
pitäisi lähettää yhtään postia, koska vastaan-[br]ottajan pitäessä mailia oikeana, pitäisi

0:48:57.550,0:49:02.279
SPF tai DKIM olla oikein myös. Jos ne[br]eivät ole, se ei oi olla oikea.

0:49:02.279,0:49:07.480
Eli oikeasti se tarkoittaa, että suurin osa[br]domaineista tuolla pitäisi harkita DMARC

0:49:07.480,0:49:15.471
enablointia. Se on oikea asia tehdä. OK.[br]Eli on lisää tageja. Eli luonnossa,

0:49:15.471,0:49:22.019
nämä DMARC kirjoukset voivat olla paljon[br]pidempiä, mutta niistä ei ole paljon hyötyä

0:49:22.019,0:49:26.009
pentestaajille. Eli tärkeä osa tässä jälleen,[br]on tämä policy jossa voi olla

0:49:26.009,0:49:31.184
kolme arvoa "none", "quarantine" ja [br]"reject". Ja jos se on "quarantine", se

0:49:31.184,0:49:39.109
tarkoittaa, että jos, jos ei onnistu,[br]viestin pitäisi mennä spam kansioon.

0:49:39.109,0:49:42.619
Jos se on "reject" se pitäisi hylätä heti.[br]Ja jos se on "none", se tarkoittaa, että

0:49:42.619,0:49:47.960
se on tutkinta moodi. Ja tämä on kuva[br]jonka näytin aikaisemmin, joka näyttää

0:49:47.960,0:49:52.400
että vaikkakin DMARC on oikeasti paras[br]teknologia näistä kolmesta,

0:49:52.400,0:49:59.655
sitä ei oikeasti käytetä laajalti, ikävää[br]puolustajien kannalta. Aika kiva seikka

0:49:59.655,0:50:05.070
kaikille penetraatio testaajille siellä.[br]Tämä tarkoittaa, että voit oikeasti

0:50:05.070,0:50:14.550
väärentää suurimman osan sähköposteista.[br]Okei, kuinka kierrämme sen? Anteeksi. No.

0:50:14.550,0:50:18.480
Mitä tapahtuu jos joku on oikeasti [br]implementoinut DMARCin? Tarkoittaako se

0:50:18.480,0:50:23.526
että pentestaajat eivät voi tehdä mitään?[br]Sinun ei tarvitse edes tutkia mitään ?

0:50:23.526,0:50:29.039
Ei, se ei tarkoita. Eli käytännössä, jos joku[br]on implementoinut DKIM ja DMARCin, mutta

0:50:29.039,0:50:33.859
ei SPFaa, eli nyt heillä on kaksi niistä.[br]Se on kiva yhdistelmä. DKIM on melko

0:50:33.859,0:50:38.470
voimakas ja sen merkittävän vian joka oli,[br]DMARC ratkaisi. Eli tämä yhdistelmä on

0:50:38.470,0:50:44.680
tosi hyvä teoriassa. Käytännössä, ongelma[br]on, että suojataksesi omat sähköpostisi,

0:50:44.680,0:50:49.751
vastaanottajan pitäisi tarkastaa molemmat[br]DKIM ja DMARC ja valitettavasti,

0:50:49.751,0:50:53.932
melko monet ohjelmat eivät edelleen[br]tee sitä. Yksi niistä ohjelmista on

0:50:53.932,0:50:57.920
Microsoft Exchange. Ja mikäli et käytä[br]Microsoft Exchangea, on hyvä todennäköisyys

0:50:57.920,0:51:02.049
että joku kumppeneista jonka kanssa[br]kommunikoit käyttää Microsoft

0:51:02.049,0:51:05.700
Exchangea ja vakiona siinä ei ole mitään[br]toimintoa DKIM parsimiseen.

0:51:05.700,0:51:12.619
Eli oikeasti, valtaosan järjestelmistä pitää[br]enabloida SPF ihan käytännön syistä, mikä

0:51:12.619,0:51:16.609
on hyvä pentestaajille, koska mikäli[br]SPF ja DMARC on enabloitu vakiona

0:51:16.609,0:51:21.502
yhdessä, silloin se korjaa yhden suuren [br]ongelman SPFn kanssa, mutta ei

0:51:21.502,0:51:25.864
automaattisesti korjaa muita ongelmia,[br]koska ei ole riittävää hienojakoisuutta ja

0:51:25.864,0:51:32.119
virhe konfiguraation mahdollisuutta. Eli.[br]Ja mielenkiintoinen fakta on, että DMARC

0:51:32.119,0:51:37.970
vaatii vain yhden toisen teknologian[br]SPFn tai DKIMn läpäisyn

0:51:37.970,0:51:42.749
Tulkitakseen emailin oikeaksi. Ei ole muuta[br]tapaa DMARCssa, vaikka on monia muitakin

0:51:42.749,0:51:45.680
selektoreja. Ei ole mahdollista määrittää,[br]että molempien niistä pitäisi olla oikein

0:51:45.680,0:51:50.019
tai, että DKIM pitäisi olla edellä SPFaa.[br]Käytännössä, se tarkoittaa että useimmissa

0:51:50.019,0:51:54.950
järjestelmissä, joissa on päällä kaikki[br]kolme niistä, mikä on hyvä käytännöllinen

0:51:54.950,0:51:59.849
ratkaisu pentestaajan puolelta, voimme vain[br]unohtaa DKIM heti ja keskittyä SPFaan

0:51:59.849,0:52:05.170
koska SPF on heikoin lenkki tässä tilanteessa.[br]Okei, vain yksi minuutti kertaukseen.

0:52:05.170,0:52:11.559
En ole varma, onko minulla enää aikaa.[br]Minulla ei ole paljoa aikaa. Okei. Eli,

0:52:11.559,0:52:17.140
anteeksi. Yeah. Eli yksi tärkeä asia huomata[br]on, että testatessasi järjestelmää, harkitse

0:52:17.140,0:52:22.270
molempia skenaarioita. Eli älä keskity vain[br]lähettämiseen. Jos olet, esimerkiksi,

0:52:22.270,0:52:27.599
testaamassa Alicea. Alice on organisaatio,[br]joka on asiakkaasi. Älä keskity vain testaamaan

0:52:27.599,0:52:33.569
sähköpostien lähettämistä teeskennellen Alicea,[br]mutta myös toista puolta. Koska tässä voit

0:52:33.569,0:52:38.670
nähdä, että on helppo implementoida,[br]esimerkiksi SPF ja DMARC, koska

0:52:38.670,0:52:43.961
molempiin niistä, sinä tarvitset vain DNS[br]konfiguraation. Vain yksi merkintä kumpaankin.

0:52:43.961,0:52:48.779
Kuitenkin niiden testaaminen, siis [br]todentaminen kunnolla on vaikeampaa.

0:52:48.779,0:52:52.643
Ensinnäkinen tarvitset ohjelmistotuen ja[br]sinun pitää konfiguroida se oikein myös.

0:52:52.643,0:52:56.585
Eli käytännössä voi olla, että useat[br]organisaatiot, jotka ovat enabloineet

0:52:56.585,0:53:01.500
DMARCin tai SPFn DNS puolella lähteville[br]posteille, he eivät ole oikeasti kunnolla

0:53:01.500,0:53:07.960
tarkastaneet sitä. Yeah. Okei. Anteeksi.[br]Minulla ei ole aikaa siihen. Eli varmaankin.

0:53:07.960,0:53:16.009
Se on siinä, anteeksi. Ehkä pari kysymystä.

0:53:16.009,0:53:24.601
<i>aplodeja</i>

0:53:24.601,0:53:29.719
Herald: Kiitos, Andrew, tästä hyvästä[br]esityksestä. Toki. Meillä on aikaa parille

0:53:29.719,0:53:33.839
kysymykselle. Eli tuolla näen jo yhden[br]henkilön, mikrofoni numero kaksi.

0:53:33.839,0:53:40.150
M2: Hei, kiitos paljon. Tesdätkö jotain[br]hyvää työkalua valvomaan DMARC raportteja

0:53:40.150,0:53:44.339
joita minulle lähettävät vastaanottajani.[br]A: Yeah. Tämä on todella hyvä kysymys.

0:53:44.339,0:53:49.940
Me CERTna, me todella suositamme kaikille[br]tämän työkalun käyttöönottoa, mutta

0:53:49.940,0:53:55.190
valitettavasti, tietääkseni, kaikki[br]työkalut, jotka ovat suosittuja netissä,

0:53:55.190,0:53:59.670
ne keräävät jotain dataa sinusta. Eli[br]ne käyttävät sitä markkinointitarkoituksiin,

0:53:59.670,0:54:04.412
ne eivät ole hyviä yksityisyyden kannalta,[br]jos olet siitä huolissaan.

0:54:04.412,0:54:07.880
Eli sinun pitää implementoida jotain itse[br]tai sinun pitää katsoa jotain, aloita

0:54:07.880,0:54:12.180
joku open source projekti ehkä.[br]Herald: OK. Mikrofoni numero yksi, kiitos.

0:54:12.180,0:54:16.428
M1: Kiitos hyvästä esityksestä. Minä itse,[br]pidän itseäni email pääkäyttäjänä.

0:54:16.428,0:54:23.609
Minua joskus ohjeistetaan lyhentämään [br]meidän SPF listaa, koska jos se on liian

0:54:23.609,0:54:28.859
pitkä, se poistetaan kuitenkin. Siksi[br]minua joskus neuvotaan pudottamaan

0:54:28.859,0:54:34.930
PTR kirjaus. Mutta esityksessäsi, sanot,[br]että PTR merkintä on hyödyllinen reverse

0:54:34.930,0:54:39.549
DNS tarkastuksessa, jonka koen myös hyödyl-[br]lisenä. Miten ajattelet SPF listan lyhentämisestä

0:54:39.549,0:54:42.920
ja mitä ajattelet PTR merkinnöistä yleensä.

0:54:42.920,0:54:47.530
A: No, se oikeastaan riippuu juuri sinun[br]tapauksesta. Eli voi olla tilanne, että

0:54:47.530,0:54:51.230
jotkut organisaatiot todella tarvitsevat [br]tämän pitkän SPF listan ja sitä ei voi

0:54:51.230,0:54:55.799
kiertää sinun toimesta. Mitä voisit tehdä[br]on sisällyttää tämä, sisällytä käytä includea

0:54:55.799,0:55:01.479
koska ne eivät ole, ne eivät ole makroja,[br]eli ne eivät tule laajennetuiksi. Ne eivät

0:55:01.479,0:55:07.755
kuten, sinun lista ei tule pidemmäksi jos [br]sisällytät ja käytät useita includeja. Mutta

0:55:07.755,0:55:12.119
ongelma, jota suosittelisin sinulle on,[br]harkitse tarvitsetko todella, todellako

0:55:12.119,0:55:16.970
tarvitset niin monta merkintää jos se[br]on silti niin pitkä, koska ne ovat hyvin

0:55:16.970,0:55:20.499
yleinen ongelma, on että ellet ole Google[br]tai jotain sellaista, et oikeasti tarvitse

0:55:20.499,0:55:26.660
niin pitkää SPF listaa. Se on varmaan [br]ongelma jossain. Yeah. Eli se on varmaan

0:55:26.660,0:55:36.489
virhe useimmissa organisaatioissa.[br]Herald: OK. Sopii, kyllä. Vain lyhyesti.

0:55:36.489,0:55:40.496
Numero 1[br]M1: PTR record kirjauksesta. Kuulin, että

0:55:40.496,0:55:43.489
se pudotetaan. Ei pudoteta standardeista,[br]mutta sitä ei ole standardeissa.

0:55:43.489,0:55:48.859
A: Se on standardeissa. Ei. PRT kirjaus[br]itsenään, jos se on todella sinun tapaus.

0:55:48.859,0:55:53.599
En tiedä, En ole tietoinen että sitä[br]automaattisesti pudotetaan jonnekin.

0:55:53.599,0:55:56.380
Ei pitäisi olla ongelma.[br]Herald: Meillä on pari

0:55:56.380,0:55:59.349
kysymystä lisää täällä. Eli numero[br]kuusi, siellä ihan takana.

0:55:59.349,0:56:07.420
M6: Kiitos, kiitos esityksestä. Tämä ei [br]suoraan liity, mutta vaikka sen pitäisi

0:56:07.420,0:56:13.800
liittyä. Jos postipalvelin hyväksyy, koska[br]DKIM, DMARC ja SPF, kaikki on hyvin,

0:56:13.800,0:56:18.779
mutta erityisesti Google, useille organi-[br]saatioille, posti toimitetaan mutta

0:56:18.779,0:56:24.089
luokitellaan spamiksi. Se tarkoittaa, että[br]vastaanottajan inboxissa, sitä ei näytetä.

0:56:24.089,0:56:28.069
Onko sinulla ratkaisua jolla ratkaistaan [br]tämä ongelma Googlea vastaan.

0:56:28.069,0:56:33.630
A: Yeah. OK. Eli minulla on erilaisia[br]mielipiteitä siitä, koska yksi asia joka

0:56:33.630,0:56:38.787
oikeasti saa meidät tekemään, mitä meidän[br]pitäisi tehdä. Kiitos Google. On, että he

0:56:38.787,0:56:42.859
ovat niin tiukkoja, että koska se on ainoa[br]syy miksi meillä edes on näin korkea

0:56:42.859,0:56:47.879
prosentti edes huonosti konfiguroituja SPFia.[br]Ainoa syy miksi 70 prosenttia web-sivuista

0:56:47.879,0:56:52.829
käyttää SPFaa on, koska heidän pitää[br]kommunikoida Googlelle.

0:56:52.829,0:56:56.690
Ja Google ei hyväksy postiasi, jos sillä ei[br]ole edes SPF perusteita. Eli minä

0:56:56.690,0:57:04.269
oikeastaan pidän työstä jota teen. Minä.[br]Minä suosisin, että Google tekee mitä tekee.

0:57:04.269,0:57:09.527
Mutta ymmärrän oikeita admineja, joilla[br]on tämä ongelma. Googlella on työkalu.

0:57:09.527,0:57:15.239
Te varmaan tiedätte siitä. Missä voit[br]tarkastaa mitä se ajattelee sinun domainista.

0:57:15.239,0:57:19.323
Eli sinun pitää harkita tätä ongelmaa [br]tapaus tapaukselta. Aika usein

0:57:19.323,0:57:23.559
mitä tapahtuu on, että vaikka sinulla on[br]tämä DKIM, DMARC ja niin edelleen, sitä ei

0:57:23.559,0:57:28.576
ole konfiguroitu oikein. Eli mistä esitys[br]oli. Siinä se on. Sinä varmaankin

0:57:28.576,0:57:31.259
ajattelet konfiguroineesi sen oikein,[br]mutta siinä on virheitä.

0:57:31.259,0:57:35.249
Herald: Okei, annetaan etusija[br]Internetille.

0:57:35.249,0:57:40.170
Signal Angel: Meillä on kysymys Internetistä.[br]No, Yrittäessä varmistaa ja päättää

0:57:40.170,0:57:43.819
miten käsitellä "älä vastaa" email[br]osoitteita.

0:57:43.819,0:57:49.999
A: Ei vastausta, anteeksi. Voitko lukea sen[br]uudelleen.

0:57:49.999,0:57:55.170
Signal Angel: Kun yrittäessä varmistaa[br]osoitetta, kuinka käsitellä No Reply

0:57:55.170,0:58:04.529
email osoitteita.[br]A: Ehkä se oli noreply headereista kyse?

0:58:04.529,0:58:10.650
Tai olemattomista IP osoitteista?[br]Signal Angel: Kuinka käsitellä emailia

0:58:10.650,0:58:14.809
"No Reply" email osoitteesta.[br]A: Koitan vastata kuten kuinka käsitän sen.

0:58:14.809,0:58:21.532
Eli mitä usein tapahtuu on, mitä usein[br]tapahtuu on, että sähköposti

0:58:21.532,0:58:25.294
lähetetään olemattomasta osoitteesta. Eli[br]ehkä siitä oli kysymys. Esimerkiksi

0:58:25.294,0:58:29.789
siinä on "no reply" ja se ei ole ongelma[br]itsessään. No Reply. Ongelma on, ettei

0:58:29.789,0:58:34.339
se ole oikea osoite. Ei ole olemassa sitä[br]osoitetta. Just. Ja niin minulle ei ole

0:58:34.339,0:58:38.816
vastausta tähän, koska RFCn mukaan, sinun[br]pitäisi, pitäisi silti hyväksyä se.

0:58:38.816,0:58:43.627
Käytännössä. kuten sanoin, useat sähköposti[br]järjestelmät jo hylkäävät tämän osoitteen

0:58:43.627,0:58:46.420
jos lähetät olemattomasta, ellet ole[br]Google tai jotain

0:58:46.420,0:58:50.150
suurta, jolloin sinut on laitettu whitelistalle. [br]Et vain voi tehdä sitä.

0:58:50.150,0:58:54.779
Et voi lähettää sähköpostia olemattomasta[br]osoitteesta. Eli jos se on sinun tilanteesi,

0:58:54.779,0:59:00.309
luo se osoite, laita se vaikka poistamaan[br]kaikki email joka sinne tulee,

0:59:00.309,0:59:03.640
mutta luo oikea osoite, joka sinun on[br]hyväksyttävä. Jos olet toisella puolella.

0:59:03.640,0:59:08.269
Eli jos saat tämän emailin. Se riippuu[br]siitä tietystä tapauksesta.

0:59:08.269,0:59:12.099
Eli katso mitä on meneillään. Jos voit ottaa[br]heihin yhteyttä, ota yhteyttä. Jos et voi

0:59:12.099,0:59:16.220
ottaa yhteyttä, sitten sinun pitää päättää[br]mikä on riski, jos hylkäät nämä osoitteet,

0:59:16.220,0:59:23.920
ovatko ne tärkeitä sinulle? Eli RFCn [br]mukaan sinun pitää ottaa vastaan ja

0:59:23.920,0:59:28.660
prosessoida tämä osoite.[br]Herald. Okei, Mikrofoni numero neljä,

0:59:28.660,0:59:33.040
ole hyvä.[br]M4: Hei, kiitos esityksestäsi. Tiedätkö

0:59:33.040,0:59:40.630
yrityksistä ratkaista ongelma suurten email [br]lähettäjien osalta kuten online kirjakauppojen,

0:59:40.630,0:59:47.450
jotka ovat kivoja, koska niillä ei näytä[br]olevan omia SPF kirjauksia, esimerkiksi

0:59:47.450,0:59:53.253
omassa hallinnassaan.[br]A: Yeah. Eli monessa tapauksessa voit vain

0:59:53.253,0:59:56.711
ottaa heihin yhteyttä. Eli kyse on vain [br]siitä, että he eivät ajatelleet sitä.

0:59:56.711,1:00:01.770
Tai ehkä kukaan ei ole kertonut mitä tehdä,[br]tai ehkä he eivät kuinka tehdä paremmin. Just.

1:00:01.770,1:00:05.249
Eli se on yksi asioista, joita CERTna me[br]olemme tekemässä. Jos teillä joillain on

1:00:05.249,1:00:10.619
tämä ongelma suuren yrityksen kanssa [br]jossain tietyssä maassa, suosittelen puhumaan

1:00:10.619,1:00:14.470
CERTlle. Vaikka se ei olisi valtiollinen[br]organisaatio, esimerkiksi, Latviassa,

1:00:14.470,1:00:18.700
jos se olisi Latvialainen yritys.[br]Me teemme triagen. Me yrittäisimme

1:00:18.700,1:00:21.892
puhua heille, selittää miksi he tarvitsevat[br]muutosta ja niin edelleen.

1:00:21.892,1:00:26.289
Eli se on yksi vaihtoehto sinulle. Mutta[br]käytännössä jos joku näyttää sinusta

1:00:26.289,1:00:30.060
kolmantena osapuolena väärältä [br]konfiguraatiolta, en voinut sitä mainita

1:00:30.060,1:00:34.400
tässä esityksessä. Jos joku ei ole täysin[br]turvallinen, se ei tarkoita, että se olisi

1:00:34.400,1:00:39.460
väärin. Voi olla oikeasti liiketoiminta[br]vaatimus miksi sen pitää olla niin.

1:00:39.460,1:00:42.229
Just. Koska esimerkiksi, jos se on iso,[br]en tiedä, Amazon ja joku tai

1:00:42.229,1:00:46.700
jotain sellaista. Ja jos he ovat testanneet[br]ja tietävät, että jos he kytkevät todella tiukan

1:00:46.700,1:00:51.697
konfiguraation, tietty prosentti heidän[br]emaileista vain jää saapumatta. Ei heidän

1:00:51.697,1:00:55.762
ongelman takia, vaan jonkun toisen[br]ongelman. Just. Mutta sitten on

1:00:55.762,1:00:59.759
ihan oikea bsiness case, jota he [br]eivät ole. Olisi heidän kannalta typerää

1:00:59.759,1:01:04.489
laittaa se päälle, tiedäthän, tiukka[br]konfiguraatio, tietäen että se

1:01:04.489,1:01:08.970
vahingoittaa heidän liiketoimintaa.[br]Siinä on järkeä, eikö vain?

1:01:08.970,1:01:13.479
Herald: Okei, Meillä on valitettavasti aika[br]loppumassa niille, jotka ovat mikrofoneilla.

1:01:13.479,1:01:17.755
Olkaa hyvä ja tulkaa vain jonoon puhujalle[br]pöydän viereen. Hän puhuu

1:01:17.755,1:01:21.195
teille. Varmastikin. Ja.

1:01:21.195,1:01:25.159
<i>aplodeja</i>

1:01:25.159,1:01:40.959
<i>36c3 esityksen jälkimusiikki</i>

1:01:40.959,1:01:53.000
Translated by Esa Lammi[br](KYBS2001 course assignment at JYU.FI)