36C3 - Email authentication for penetration testers

Translated by Esa Lammi
(KYBS2001 course assignment at JYU.FI)

36c3 intromusiikki

Herald: Oletteko koskaan miettineet kuinka
kuinka väärentää sähköposti hyvin? Siinä

tapauksessa voitte olla oikealla luennolla.
Meillä on seuraava puhuja. Andrew, joka

työskentelee nykyisin kansallisessa CERTssa
Latviassa tietoturvatutkijana. Ja hän aikoo

puhua meille sähköpostin väärentämisestä
ja nykyaikaisista anti-spoofing strategioista.

Lava on sinun.

Aplodeja

Andrew: Tervehdys. Olen Andrew ja työs-
kentelen Latvian kansallisessa CERTssa.

Yksi tavoitteistamme on kehittää sähköpostin
turvallisuuden tilaa maassamme ja teemme

tätä enimmäkseen nostamalla tietoisuutta
asiasta ja tiedottamalla parhaista

toimintatavoista. Ja tietenkään emme ole
ainoa organisaatio joka tekee tätä.

On monia CERT yksiköitä lisää eri maissa
ja on myös useita vapaaehtois

järjestöjä jotka tekevät samaa.
Sekä kaupallisia tahoja.

Kuitenkin, toistaiseksi, suoraan sanoen,
menestyksemme on ollut melko

vaatimatonta. Esimerkiksi, tässä on yksi
tilasto, joka on käyttöaste yhdestä

tietystä teknologiasta, DMARCsta, joka
kuten opitte esityksessä on melko

tärkeä ja toivon, että kaikki alkavat
käyttämään sitä. Eli vasemmalla on

20 tuhatta domainia ympäri maailmaa,
jotka ovat tärkeitä domaineja tärkeille

organisaatioille, joiden pitäisi tosissaan
tietää paremmin. Ja oikealla puolella

näemme top 50, top 500 EU kaupallisia
domaineja ja näistä kaksi kolmasosaa

eivät ole konfiguroineet DMARCia vielä.
ja niistä jotka ovat näin tehneet, valtaosa

eivät ole määrittäneet tiukkaa politiikkaa.
Joten jos pitää poimia yksi asia tästä

puheesta, toivon että kaikkien pitäisi
alkaa käyttämään DMARCia. Sitä on tärkeää

käyttää myös domaineissa joiden ei pitäisi
lähettää sähköposteja ulos. Joten yksi

selitys matalalle käyttöasteelle, luulen
olevan, että on näennäisesti liian monta

kilpailevaa teknologiaa. Tämä on puheeni
sisältö. Ja tein todella parhaani

tiivistääkseni sitä. Mutta kuten voitte
nähdä, on kolme lyhennettä, no myös

SMTP ja näistä, SPF, DKIM ja DMARC.
Oikeastaan en muista mitkä ovat kahden

kokonaiset nimet. Mutta silti ne ovat
kaikki tärkeitä. Ja tietenkin, tämä ongelma

että on liikaa muotisanoja, liikaa
teknologioita, eikä ole selvää mitä kaikkia

mitä meidän tulisi käyttää, se ei koske
pelkästään sähköpostia. Meillä on sama

tilanne kaikkialla ja oh, tietoturvan
alueella, luulen että olemme nyt löytäneet

yhden tavan ratkaista asia ja se on
penetraatiotestaus. Eli kun penetraatio

testaus on tehty kunnolla ja tulokset
on julkaistu, me voimme alkaa

puhumaan. Voimme siirtää keskustelun pois
suosiiko

organisaatio teknologiaa A vai teknologiaa
B ja voimme sen sijaan alkaa puhumaan

kysymyksistä, joilla on merkitystä, kuten
onko mahdollista jollekin kolmennelle

osapuolelle väärentää organisaationne
sähköposteja ja lähettää sellaisia

sähköposteja esimerkiksi asiakkaille tai
kumppaneille ja media organisaatioille

siten, että he luulevat sähköpostien
tulleen todellisuudessa teidän

organisaatiolta? Tästä syystä penetraatio
testaajat ovat tämän luennon avainyleisöä.

Kuitenkin, toivon että kuka tahansa blue
teamilainen yleisössä kokee tämän puheen

kiinnostavaksi. Olen varma, että tunnette
jo perusteet sähköpostista ja näistä

teknologioista, mutta asian
tarkasteleminen toiselta puolelta,

hyökkääjän puolelta, voi joskus asettaa
asiat todella oikeaan perspektiiviin.

Se voi auttaa sinua ymmärtämään mihin
sinun pitäisi keskittyä ympäristöä

suojatessasi. Ja lopuksi SMTP protokolla.
Teknologia, joka kulkee meidän

sähköpostikeskustelujen alla on oikeasti
melko helppo ymmärtää.

Ja myös vanhat opetukset koko
SMTPn matkasta, kuinka se kehittyi

ja kuinka on mahdollista väärentää se
ja kuinka kaikki teknologiat koittavat

estää väärentämistä. Mielestäni se on
kiinnostava tapaus ja sen pitäisi olla

mielenkiintoista seurattavaksi jopa niille
joille email on uutta. Um, lopuksi. Uhka

ympäristö. Eli email turvallisuus on laaja
alue. Ja tänään keskityn vain sen yhteen

pieneen alueeseen, joka on onnistunut
sähköpostin väärentäminen. Tampering

attacks. Ja tiedän että monet, pentestaajat
jo nyt hyödyntävät osin phishingia tai

spearphishingia, emulointia heidän
toimeksiannoissaan ja. Mutta tietääkseni

he tekevät sitä enimmäkseen sosiaalisen
hakkeroinnin näkökulmasta käyttäen

social engineering toolkit:ia ja vastaavia
esimerkiksi. Ja se on, en halua kiistellä,

tärkeää demonstroida asiakkaalle

mitkä ovat riskit sosiaalisessa
hakkeroinnissa. Kuitenkin mielestäni teette

asiakkaalle karhunpalveluksen jos se on
ainoa asia mitä testaatte

sähköpostin näkökulmasta, koska asiakkaan,
managerin näkökulmasta joka lukee

raporttinne, jos siinä mainitaan vain
social engineering hyökkäykset, silloin

looginen johtopäätös on, että paras keino
mitigoida näitä uhkia on käyttäjien

kouluttaminen, erityisesti niiden jotka
ovat vähiten teknisiä, kuten näet tässä

esityksessä. On monia hyökkäyksiä ja
useat organisaatiot ovat niille

alttiita, jotka ovat paljon niitä parempia.
Mikään määrä käyttäjäkoulutusta ei auta

koska emme voi olettaa käyttäjien tutkivan
headereitä esimerkiksi käsin.

Joten meidän täytyy oikeasti parantaa
sähköposti infrastruktuuriamme. Tätä ei

voi kieltää. Ja lopuksi ennen siirtymistämme
oikeaan tekniseen asiaan, on pieni salaisuus

jonka uskon auttavan ihmisiä, jotka eivät
työskentele sähköpostin parissa,

ymmärtämään miksi meillä on näitä ongelmia
on, email admineille historiallisesti, um,

he arvostavat saatavuutta järjestelmässä
ja luotettavuutta paljon enemmän

kuin turvallisuutta. Ja koska tämä ei ole
ideologinen kysymys. Se on hyvin

käytännön läheinen. Joten, esimerkiksi,
jos olet email, email admin organisaatiossa

ja joltain käyttäjistäsi loppuu laskujen
vastaanottaminen, esimiehesi etsii

sinut, kertoo tilanteesta ja pyytää
sinua kauniisti korjaamaan tilanteen

niin pian kuin mahdollista, vaikka se ei
olisi sinun vikasi, jos sattuisi käymään

niin että vika on emailin toisessa päässä.
Ei sinun palvelimella. Ja esimerkiksi jos,

toinen esimerkki, jos sinä, jos joku sinun
työntekijöistä vastaanota sähköpostia

tarpeeksi nopeasti, esimerkiksi salasanan
palauttamiseksi tai varmentaakseen

sähköpostiosoitteen tai käyttääkseen usean
välineen tunnistautumista (MFA) ja he eivät

voi kirjautua johonkin tärkeään järjestelmään
he etsivät sinut ja sinun täytyy

ratkaista se. Mutta jos järjestelmässä on
joku tietuturva haavoittuvuus, jos se on

altis spoofaus hyökkäykselle ja niin
edelleen silloin, ei käyttäjä, ei esimies

normaalisti huomaa sitä. Sinä et välttämättä
huomaa, mutta olet. Sinulla on tämä

haavoittuvuus. Joten siksi toki penetraatio
testaajat ovat tärkeitä. Okei.

Nyt voimme viimein alkaa puhumaan teknisestä
asiasta. Ja me aloitamme lyhyellä

perehtymisellä SMTP protokollaan.
SMTP on protokolla joka on kaiken email

kommunikoinnin perusta ja sitä on oikeastaan
melko helpo seurata. Eli tässä on datavirta

mitä tapahtuu kun yksi henkilö lähettää
sähköpostin toiselle henkilölle.

Esimerkiksi Alice lähettää Bobille ja he
käyttävät eri, he työskentelevät

eri yrityksissä. He käyttävät eri
domaineja. Eli mitä tapahtuu tässä on,

että molemmat käyttävät, sanotaan, email
ohjelmaa kuten Outlook tai

Thunderbird. Ja Alice lähettää sähköpostia.
Se kulkee SMTP protokollan läpi Alicen

säkköpostipalvelimelle. Mutta on tärkeä
huomata että tämä on lähtevän postin palvelin.

Yleensä organisaatioilla on kahden tyypin
palvelimia, yksi sisään tulevalle

liikenteelle ja toinen lähtevälle. Pienillä
organisaatioilla se voi olla yksi palvelin

mutta taas, on tärkeää pentestaajan
ajatella niitä eri järjestelminä

koska niillä on, vaikka meillä olisi vain
yksi fyysinen palvelin, siinä on eri

konfiguraatio lähtevälle postille ja
sisään tulevalle postille. Joten penetraatio

testaajana sinun pitää tarkastaa molemmat.
Okei. Nyt, kun Alicen palvelin koittaa

lähettää postin Bobin palvelimelle, on
ongelmana, että palvelimen täytyy jotenkin

automaattisesti selvittää on se toinen
palvelin jolle lähettää se posti ja se

tehdään käyttäen blue box MXaa, joka on
tietty DNS merkintä tyyppi MX. Eli se on

jotain, jota ylläpitää Bob:in organisaatio.
Eli Bobon organisaatio, mikäli he haluavat

vastaanottaa sähköpostia, he luovat tämän
DNS merkinnän. Ja sanon että. Okei. Jos

haluatte lähettää sähköpostia meille,
käyttäkää tätä palvelinta. Eli sen pitäisi

osoittaa Bobin palvelimeen. Ja Alicen lähtettävä
palvelin tietää Bobin vastaanottavan palvelimen

osoitteen ja voi kommunikoida sille. Ja
myöhemmin Bob vastaanottaa sen postin.

Eli kohta jota me pentestaajina koitamme
murtaa on todellisuudessa

Alicen ja Bobin palvelimien välissä.
Ja meidän täytyy miettiä toista esimerkkiä

joka on päinvastainen tapaus. Ja voit
ajatella että siinä ei ole

mieltä, koska me periaatteessa
vain muutamme liikenteen suunnan.

Mutta tärkeä osa tässä meille
pentestaajina on ymmärtää, että

asiakas kontrolloi vain osaa tästä
transaktiosta. Jos asiakkaamme,

sanotaan vaikka loppuesityksen ajan on
Alice tai Alicen organisaatio,

niin toisena esimerkkinä kun lähetämme
postia Bobilta Alicelle

silloin lähetämme vain sähköpostia.
Periaatteessa, osa tästä liikenteestä

kulkisi Alicen palvelimien kautta. Ensim-
mäisessä esimerkissä jos lähetämme postia

Alicelta Bobille, se ei menisi niin. Eli jos
se tuntuu hämmentävälle, se on OK. Palaamme

tähän hieman myöhemmin. Ja lopuksi, on
kolmas esimerkki, joka näyttää samalta

mutta ei ihan. Ja se on jos Alice
kommunikoi. Alice on asiakkaamme.

Ja jos hän kommunikoi hänen työtoverien
kanssa, jotka ovat samassa organisaatiossa,

samassa email palvelimessa, samassa
domainissa. Siinä tapauksessa, jälleen,

on vähintään kaksi loogista email palvelinta,
lähtevä palvelin ja sisääntuleva palvelin.

Mutta molemmat kuuluvat asiakkaallemme.
Eli nyt, jos et ollut tuttu sähköpostin kanssa,

nyt olet. On todella mielenkiintoista
pohtia mitä näistä skenaarioista,

kolmesta skenaariosta, on helponta suojata.
ja myöhemmin

näemme miten se oikeasti tapahtuu.
Okei. Ja sitten meidän täytyy katsoa mitä

oikeasti lähetetään, kun sähköpostia ollaan
lähettämässä. Eli jälleen, se käyttää SMTP

protokollaa ja on tosi kiva protokolla
kuten. Kuten voit nähdä, se on vain tekstiä.

Eli se on puhdas tekstiprotokolla ja sen
kanssa on helppo leikkiä, koska

voit avata telnet yhteyden oikealle
palvelimelle ja voit koittaa kirjoittaa

komentoja käsin. Voit koittaa väännellä
jotain tai muokata tai koittaa erilaisia

erilaisia tyyppejä ja nähdä reaaliajassa
kuinka se menee. Eli vasemmalla

näemme tässä kaksi osaa jotka
määrittää SMTP. Eli ensinnäkin

siinä on SMTP kirjekuori, jonka periaatteessa
kytket palvelimeen. sanot hello,

ja sitten sanot mitä. Määritä sähköpostin
lähettäjä ja vastaanottaja. "mail from"

on lähettäjä. Vastaanottaja on Bob,
esimerkiksi. Ja sitten toinen osa alkaa

datalla ja loppuu quit. Ja sitä osaa
kutsutaan kontentiksi / viestiksi.

Jos haluat leikkiä sillä enemmän, tämän
määrittää eri standardi

joka ei ole tärkeä pentestaajalle, mutta
jos haluat katsoa

yksityiskohtia ja se voisi olla tärkeää.
Ja tämä sisäinen viesti, jota

kutsutaan joko sisällöksi tai SMTP
viestiksi, se taas, se sisältää kaksi osaa.

Yksi on headeri ja toinen on runko. Ja
luulen että jotkut eivät tunne emailia,

mutta varmaan kaikki yleisössä tuntevat
HTTPn ja tämä

näyttää melko, melko samalta. Eli helppoa
ymmärtää. Mutta mielenkiintoinen osa tässä

että saatoit huomata, että meillä on
Alicen ja Bobin osoitteet kahdesti.

Eli. Esimerkiksi, Alice on määritelty
toisella rivillä "mail from". Ja sitten

meillä on sama osoite. alice @ hänen
organisaatio "From" headerissa. Punaiset

ovat headereita. Ja sama tapahtuu Bobilla.
Miksi näin on? No, se johtuu siitä miten

me näemme sähköpostin. Minä tavallisena
henkilönä, joka on käyttänyt sähköpostia

jo aika paljon, näen ne yleensä kuten
vasemmalla, joka on kuin

jonkinlainen postikortti. Eli postikortissa
on joku joka sen on lähettänyt. Lähettäjä.

Siinä on vastaanottaja. Se olen yleensä minä.
Olen vastaanottaja. Ja sitten siinä on joku

viesti. Näin ainakin koin asiat
ennen kuin opin siitä hieman lisää.

Mutta email adminit ja standardointi
järjestöt, he näkevät asian näin

kuten tässä oikealla on. Siinä on
kirjekuori ja kuoren sisällä

siellä on viesti tai postikortti ehkä.
Eli sinulla on kaksi osoitetta

tässä skenaariossa. Sinä määrittelit
osoitteet keneltä ja kenelle olet

lähettämässä kuorta, joka on osa sitä mitä
postikonttori, esimerkiksi, katsoo.

Mutta postikonttori ei yleensä katso sinun
kuoren sisään. Ja sisällä kuoressa

on toinen viesti ja tämä sisäinen viesti
on todellisuudessa tarkoitettu

vastaanottajalle. Eli todellisuudessa,
voisit tehdä vielä enemmän ja jopa laittaa

koko kirjekuoren postikorttiviesteineen
toisen kirjekuoren sisään. Ja tämä voi

kuulostaa hullulta minulle tavallisena
henkilönä, mutta email sallii tämän.

Ja RFC dokumentissa, siinä on esimerkkejä
miksi tämä voi olla välttämätöntä.

Miksi, miksi, miksi moiset asiat on sallittu.
Mutta ne ovat hämäriä. Ja niin seurauksena

se on tässä ensimmäisessä esimerkissä,
näemme, että yleisesti määritämme

saman osoitteen kahdesti. Mutta kysymys
joka meidän pentestaajina tulisi

kysyä on: Vaaditaanko sitä, oikeasti?
Onko se oikeasti totta vai ainoastaan

toiveajattelua? Ja se on vain
toiveajattelua. Eli standardi

ei erityisesti sano, että sinun pitäisi
määrittää sama osoite vastaanottajalle

tai "From" lähettäjän osoitteelle kuoressa
ja viestin sisällä. Eli, voit virittää,

niitä ja lähettää erilaista, eri tavaraa.
Eli, oikeasti,

on monia headereita lisää kuin mitä juuri
näytin. Ne mitä näytin ovat, luulen, niitä

joista meillä kaikilla on kokemusta, koska
vaikka vain käyttäisit emailia, ne ovat

yleensä se juttu jonka näet tai näet
päiväyksen, näet otsikon. näet

kuka on lähettänyt sinulle jotain ja
kenelle se on lähetetty. Yleensä sinulle.

Ja siinä voi olla, toki, useita vastaanottajia.
Oh, yeah. Ja kysymys silloin, toinen kysymys

on: Mikä on oikeasti, jos olemme määritelleet
jostain syystä vahingossa tai erityisesti

jos olemme määritelleet eri osoitteen
tähän kirjekuoreen tässä viestissä

minkä käyttäjä näkee vastaanottajana,
se on oikeasti headeri.

Eli viestin sisällä on se, mikä on
tarkoitettu käyttäjälle. OK. Eli kuten

olin sanomassa, standardit sallivat vähän
enemmän headereita. Ja oikeasti

3 headeria "From", "Sender", "Reply to"
jotka ovat semanttisesti hyvin

lähekkäin ja standardi oikeasti selittää
Milloin sinun pitäisi käyttää mitäkin.

Ja hassu juttu minulle on, että esimerkiksi
"From" headeri, joka on yleensä se

minkä näemme mitä se voi sisältää. RFCta
lukiessa selviää ettei

niitä headereita pitäisi olla kuin yksi,
mutta headeri itsessään voi

sisältää useita osoitteita. Henkilökohtaisesti
en ole ikinä saanut postia usealta

eri lähettäjältä, mutta se on sallittua.
Tärkeä asia ymmärtää on tässä

jälleen on taaksepäin yhteensopivuus,
josta mainitsin aikaisemmin. Eli vaikka

standardi selittää kuinka sinun pitäisi
käyttää kutakin headeria ja ettei

sinun pitäisi käyttää kuin yhtä kappaletta
niistä, käytännössä voi lähettää

väärinmuotoillun sähköpostin. Voisit lähettää
emailin useilla headereilla, sama "From"

header useita kertoja tai voit lähettää
headerin joka ei sisällä "From" mutta

sisältää "Sender" headerin, RFCn mukaan
väärin. Todellisuudessa se toimii.

Useimmilla organisaatioilla, useimmat email
palvelut pyrkivät parhaansa mukaan välittämään

täysin vääristetyn emailin, koska ne oikeasti
haluavat alentaa ylläpitokustannuksia.

Eli jos joku ei toimi, silloin tulet heidän
luokseen. Joten on parempi

saada kaikki toimimaan suurimman osan
ajasta. Tietenkin pentestaajalle tämä

tarkoittaa, että voit leikkiä sillä
koska on

erilaisia implementointeja ja juuri mikä
headeri esimerkiksi, jos sinulla

on kaksi näytetään tai mitä käytetään
johinkin algoritmiin. Se riippuu kyseisestä

implementaatiosta. Eli koska on niin monta
implementaatiota, ne ovat kytkeytyneinä

toisiinsa erilaisilla tavoilla. Sinä voisit
ja sinun pitäisi pentestaajana yrittää

eri asioita, esimerkiksi, lisätä sama
headeri useaan kertaan. OK.

Nyt kun olemme läpikäyneet perusteet,
katsotaan miten oikeasti koittaisit

väärentää emailin, esimerkiksi, yeah. Ja
tässä taas, tulemme takaisin tähän

kuvaan jonka näimme aiemmin. Ja,
esimerkiksi, ensimmäisessä esimerkissä

Alice lähetti postia Bobille. Sanotaan, että
olemme Chuck. Eli olemme kolmas osapuoli.

Olemme lisensoituja pentestaajia, meillä
on sopimus että voimme tehdä näin

ja koitamme lähettää väärennetyn emailin
Bobille. Ja tässä esimerkissä koitamme

väärentää Alicen viestin. Eli aikeena on
että Bob haluaa, Bon vastaanottaa emailin.

Sen pitäisi näyttää heille, Bobille, että
emailin lähettäjä on Alice. Eli riski on tämä.

Okei, en käy läpi riskiä. Luulen, että
voitte kuvitella sen. Eli esimerkiksi,

voisit lähettää vääriä uutisia, se on yksi
ongelmista, joita olemme nähneet Latviassa.

Tätä on käytetty valtionhallintoa vastaan.
Ja kun joku lähettää valeuutisia sähköpostilla

toisille ihmisille ja niin edelleen, ja
koitamme matkia jotain valtiollista

henkilöä. Ja kuten voit kuvitella itse,
ei ole hyvä juttu

sinulle jos se on mahdollista. Mutta
mielenkiintoinen juttu on, että vaikka

Chuck tekee hyökkäystä, riippuu sinun
näkökulmasta. Se voi näyttää, että Alice

hyökkää Bobille. Mutta tässä tapauksessa
email ei mene Alicen järjestelmän läpi.

Kuten näette, Chuck lähettää emailin suoraan
Bobin sisääntulevalle palvelimelle.

Nyt, on olemassa toisen tyyppinen hyökkäys
jota katsotaan. Jos lähetämme emailia

toiseen suuntaan Bobilta Alicelle.
Ja asiakkaamme on Alice. Eli testaamme

Alicen palvelinta. Ja tässä tapauksessa,
koitamme, taas olemme Chuck.

Lähetämme emailia. Tässä tapauksessa, email
menee Alicen järjestelmän läpi.

Eli kiinnostava kysymys on, kumpaa on
helpompi suojata. Voi vaikuttaa, koska

toisessa esimerkissä, email oikeasti kulkee
Alicen järjestelmän läpi, se tarkoittaa,

että Alicella on voimaa tehdä jotain,
tehdä lisätarkastuksia, tutkia jne.

Mutta kuten näet jatkossa, on helpompaa
suojata ensimmäistä esimerkkiä.

Eli, vaikka asiakkaamme on Alice, me
koitamme suojata Alicea,

mutta se on helpompaa suojata käytännössä
tässä esimerkissä kun toinen on myy...

lähettämässä emailia, yrittämässä matkia
Alicea. Okei, Oh, Yeah. On myös kolmas

esimerkki, jossa Alice kommunikoi hänen
kollegoidensa kanssa saman

organisaation sisäisesti. Jälleen, olemme
Chuck. Taas, me vain lähetämme emailia

Alicen sisääntulevalle palvelimelle. Ei
lähtevälle. Oikein. Tärkeää huomata.

Ja taas, periaatteessa, tämä kolmas
esimerkki on helpoin huomata, koska

Alicen organisaatio oletettavasti tietää,
että hänen emailien pitäisi aina tulla

Tältä tietyltä lähtevien palvelimelta.
Just. Jos vaikka lähetetään emailia

Alicen kollegalta, silloin saapuvien
palvelimella pitäisi olla kaikki valta

Ilman mitään standardeja ja sellaisia.
Todellisuudessa, joskus, oikeastaan aika

usein, siinä on erityinen whitelist Alicen
omalle organisaatiolle. Joten joitain

tarkastuksia ei tapahdu jos Alicen saapuvien
palvelin ottaa emailin vastaan, joka tulee

taas, Alicelta. Ja muuten, meillä on tämä
esimerkki. Olemme nähneet sitä parina

viime vuonna. Luulen että se ei ole ainoastaan
Latviassa. Eli tässä, esimerkiksi, on Canada

ja muut, jos näette. Nämä ovat näitä
emaileja, jotka ovat fakeja, ransomwarea yms.

Periaatteessa ne kertovat, että he ovat
hakkeroineet tietokoneesi tai

sähköpostisi. Tässä tapauksessa, ja he ovat
järjestelleet kaikenlaisia talous juttuja tai

joku kiristää sinua. Ja pyytävät sinua
lähettämään heille rahaa. Sinun rahaasi.

Tarkoitan, rahaasi bitcoineina heidän
osoitteeseen. Eli nämä sähköpostit.

Kiinnostavaa näissä emaileissa on, että
yleensä todistaakseen sinulle että heillä

on pääsy sähköpostiisi. He lähettävät
sähköpostin sinun osoitteestasi sinun

osoitteeseen. Ja monelle ihmiselle, se
toimii. Eli he näkevät, että joku on

hakkeroinut heidän tilinsä, selkeästi,
koska he saivat sähköpostin itseltään.

Kuten näet hetken päästä, on oikeasti
helppoa väärentää sellainen email, jos

mitään suojauksia ei ole asetettu
paikoilleen. Eli tärkeä

asia. Toivon, että nyt kukaan yleisössä
ei sorru tällaiseen huijaukseen.

Mutta jos teillä on ystäviä tai kollegoja,
jotka ovat ottaneet yhteyttä ja kertoneet

sellaisista emaileista joita he ovat saaneet.
Mutta yksi asia sen lisäksi, että tarkastavat

salasanansa on alkaa käyttämään tehokkaampia
autentikointeja on, että ehkä voisit

pyytää heitä ottamaan yhteyttä
email admineihin tai

IT teamiin ja kysyä heiltä anti-spoofing
suojauksista, koska todella jos he voivat

vastaanottaa sellaisen emailin ja sitä
ei suodateta, jotain on vialla.

Okei, ja nyt katsotaanpa väärennettyä email
keskustelua, tämä esimerkki on vastaava

kuin edellinen. Mutta tässä olemme oikeasti
Chuck. Eli tämän on lähettänyt Chuck Bobille,

mutta esitämme olevamme Alice. Kysymys
on, voitko nähdä eron

kuinka tämä on erilainen kuin edellinen.
Ja on vaikeaa havaita

eroa, koska sitä ei ole.
Tämä on sama keskustelu.

Eli, juttu tässä on, että SMTP protokollassa
ei itsessään oikeasti ole mitään suojausta.

Eli, yeah, voisit vain esimerkiksi, jos
olet tuo tyyppi, joka lähettää fake

kiristyskirjeitä, voit vain kirjoittaa
tämän tekstin ja dumpata sen

telnetiin ja se toimii monelle
organisaatiolle. Ei kaikille tietenkään,

email adminit tietävät nämä jutut, tietävät
että SMTP ei ole luotettava tällä tavalla.

Se on helppo väärentää ja niin edelleen.
Ja on ollut useita yrityksiä lisätä jotain

suojausta, vähän ad hoc tapaisesti. Eli
ei standardeja, jotain kiristyksiin, lisää

filttereitä ja juttuja omaan mailiisi.
Ja jotkut näistä suojauksista rikkovat

oikeasti RFCta. Jos luet sitä, mutta ketä
kiinnostaa? RFC ei ole kuten pyhä teksti,

vai onko. Hyväksyn tämän täysin, esimerkiksi.
Yeah, jatketaan. Mutta ongelma on, ettei

ole tarpeeksi tietoa.
Eli, jos mietit täällä, jos olemme Bob

ja koitamme suojata järjestelmämme.
Eli olemme Bob, joku system admin varmaan

tai Bob on sys admin ja koitamme lisätä
joitain sääntöjä ja juttuja,

mitä voimme oikeasti tehdä. Eli yksi
esimerkki jonka listasin tähän on tehdä

tämä SMTP takaisinsoitto, ja se tarkoittaa
että juuri kun vastaanotamme emailin

Alicelta, me oikeasti tarkistamme että se
email on olemassa. Koska monet spammerit,

mitä ne tekevät, ne vain lähettävät emailia
olemattomista osoitteista se toimii

jos sinä ajat vain raakaa SMTP palvelinta.
Eli SMTP takaisinsoitossa, periaatteessa

kun olet vastaanottamassa emailia,
esimerkiksi Alicelta, koitat. Ajat,

käynnistät erillisen prosessin, joka
yrittää ottaa yhteyttä takaisin Aliceen, jne.

Ja se koittaa lähettää hänelle emailia, jos
palvelin sanoo Yeah, se on OK. Sellainen

sähköposti on olemassa jne. Sinä et ole,
Sinä oikeasti lopetat keskustelun.

Et jatka emailin lähetystä, mutta sinun
järjestelmä voi automaattisesti huomata

että tämä sähköposti on olemassa.
Toinen tapa tehdä tämä on tarkastamalla

tämä "Hello". Ja tämä on ensimmäinen rivi
ja ensimmäisellä rivillä, sen tavallisesti

pitäisi kertoa sinulle hostname
palvelimella joka lähettää emailia.

Kiinnostava osa. Eli RFCn mukaan jälleen,
sinun ei pitäisi tarkastaa että olet

varmentanut sen. Ja jos se ei onnistu, jos
se on satunnainen, sinun pitäisi hyväksyä

email silti. Mutta mitä monet palvelimet
tekevät, ne koittavat varmentaa sen.

Ensinnäkin, tällä hostnamella kerrot, että
sinulla on tämä hostname joka

oikeasti osoittaa samaan IP osoitteeseen
ja he tekevät päinvastoin. Eli he

ottavat IP osoitteen ja koittavat ajaa
käänteisen DNS PTR kyselyn ja koittavat

selvittää täsmääkö IP osoite oikeasti
tähän hostnameen. Eli jälleen,

pentestaajina meidän tulisi olla tietoisia
näistä suojauksista, ad hoc, suojauksista

koska jos et tunne niitä, koitat
ajaa jotain ja se ei toimi

sinulla. Mutta ne ovat helppoja jos
olet niistä tietoinen ja jos sinun täytyy

tunnistaa, että tämä organisaatio käyttää
niitä. Ne ovat helppoja ohittaa, eli ne eivät

tarjoa hyvää suojaa. Niiden tarkoitus on
suojata massa hyväksikäytöltä, spammilta.

OK, eli SMTP, kuten näimme, itsessään ei
tarjoa minkäänlaisia suojauksia.

Eli mitä lisäyksiä protokollaan voimme
oikeasti käyttää suojataksemme itseämme ?

Yksi sellainen protokolla on SPF. Ja mitä
SPF tekee, se koittaa olla kuten peili

MX järjestelmässä. MX järjestelmä on se,
jota periaatteessa Alica voi käyttää,

Jota Alicen palvelin voi käyttää löytämään
automaattisesti palvelimen joka kuuluu Bobille

ja sen saapuvien palvelimen. Eli SPF on sen
vastakohta. Eli sen idea tässä on

olla automaattisesti ajossa Bobin saapuvien
palvelimella. Ja nyt kun Bob

vastaanottaa emailin, ne voivat ajaa taas
DNS kyselyn ja selvittää minkä IP osoitteiden

oikeasti pitäisi kuulua Alicen lähtevien
palvelimelle. Just. Eli mielestäni se on

helppoa ymmärtää, se on merkityksellinen
tapa. Se kuulostaa merkittävälle

lisäykselle. Ja yksi asia, joka tarkastetaan
tässä esimerkissä on kirjekuoren

lähettäjä. OK. Ja tässä on esimerkki
minimi SPF syntaxista ja kuten voimme

nähdä. Mielestäni sitä on helppo ymmärtää,
vaikka et tietäisi mikä syntaxi on, se listaa

IP osoitteet, mikä on IP, pitäisi olla IP
osoite lähtevien palvelimelle, oikealle

lähtevien palvelimelle. Ja sitten se sanoo
tässä "-all", joka taas on helppo ymmärtää

Tässä tapauksessa, se tarkoittaa, että se
on ainoa. Eli jos vastaanotat viestin,

viesti tulee tästä IP osoitteesta. Se on
hyvä. Hyväksy se. Jos se on jotain muuta

sitten poista se. Ja on monia tapoja
määrittää IP osoite. Voisit vain

määrittää IP osoitteen, voisi määrittää
IP aliverkon, voisit määrittää DNS nimen

Eli se on ainoastaan admineille. Eli
periaatteessa pentestaajalle se ei tee

paljoa eroa, admineille se vain helpottaa
järjestelmien ylläpitoa. Ja sitten ovat

nämä määreet, määreet. Tämä on jotain
jotat laitat

ennen metodeja. Esimerkiksi, tässä
esimerkissä, IPv4:ssa ei ollut mitään

määreitä. Siinä ei ole plussaa tai miinus
tai jotain. Se johtuu siitä, että plus

on oletus vakiona. Eli vakiona, kaikki
mikä on listattu SPF määrityksissä pitäisi

täsmätä johinkin oikeaan SMTP palvelimeen,
lähtevien palvelimeen. Kuitenkin, on muita

vaihtoehtoja, voit käyttää miinusta joka
on fail. Ja se tarkoittaa että jos jokin

täsmää kirjaukseen, esimerkiksi, miinus
all, joka on eniten käytetty,

se tarkoittaa, että jos se täsmää tähän,
se on yleensä viimeinen, niin tuhoa

sähköposti. Se ei ole oikea. Se on fake
email. Ja sitten on kolmas vaihtoehto,

joka on soft fail, joka on tarkoitettu
testauksen ajaksi. Eli kun olet juuri

alkamassa implementoimaan SPFaa, siinä
voisi olla. Eli ongelma on, että saattaisit

unohtaa, esimerkiksi, lisätä joitain SMTP
palvelimia. Eli, koska et ole tehnyt sitä

ennen, ehkä luulit, että sinulla on vain
yksi oikea SMTP lähtevien palvelin, mutta

oikeasti sinulla on useita, tai useita
tapoja lähettää sähköpostia. Eli siinä

tapauksessa, jos alkaisit asettamaan SPF
asetuksia "fail" tiukalla politiikalla,

sinun käyttäjät eivät voisi lähettää enää
viestejä. Eli sen takia testaaminen on

hyvä. Kuitenkin. On myös muita esimerkkejä,
vähän monimutkaisempia, yksi niistä oli

include. Eli sen sijaan, että määrität
policyn itse, koska käytät kolmatta

osapuolta, esimerkiksi, Googlea tässä
tapauksessa, ja sitten vain

sisällytät mitä tahansa Google on
julkaissut. Ja kiinostava juttu tässä on

tämä SPFn käyttö. Jos me vain, jos vain
katsomme niiden domainien määrää

jolle olemme laittaneet jonkun policyn,
se näyttää hyvältä. Arvaan, että esimerkiksi

kaikkein suosituimmat domainit, se olisi
noin 70 prosenttia. Mutta ongelma on,

ettö valtaosa niistä on joko huonosti
konfiguroituja tai ne käyttävät ainoastaan

softail optiota. Ja soft fail ei käytännössä
tee mitään. Voit siitä huolimatta, että

policy on soft failissa, voit useimmissa
tapauksissa väärentää sähköpostisi

ja se menee läpi, koska vastaanttava puoli
ajattelee että se on vain testimoodissa.

Sinun pitäisi poistaa email automaattisesti.
Yeah. Eli. Oikeasti prosentit eivöt

ole kovin hyvät. Kuitenkin, tärkeintä
meille penetraatiotestaajina on

ymmärtää. Eli mitä teemme kun näemme
tämän SPFn. Se tarkoittaa että emme voi

väärentää postiaja. Ei, ei niin. Että se
olisi game over meille. Voimme tehdä

juttuja. Ensinnäkin, on tämä soft fail jonka
mainitsin. Ja siinä periaatteessa sinulla

on jotain sääntöjä, sääntöjä, sääntöjä, ja
lopuksi, laitat tavallisesti tämän

soft failin kaikille. Joten jos me
pentestaajina koitamme väärentää jostain

tuntemattomasta IP osoitteesta. jota ei ole
listattu edellisissä säännöissä. Älä tee

mitään. Tee mitään. Tarkoitan älä estä
emailia. Se on hyvä meille, eikös ?

Se tarkoittaa, että voimme väärentää aivan
vanhaan tapaan ja se yleensä toimii.

Yksi hyvä huomio tässä on, että jotkut
järjestelmät ovat, eivät käytä vain tätä

binääristä luokittelua, onko jokun hyvä
tai paha, vaan ne koittavat tehdä jotain

pisteytystä. Ja voi olla, että vaikka
olisikin tämä soft fail, he eivät

automaattisesti estä sinun emailia, vaan
ehkä he lisäävät jotain epäilyksen tasoa

siihen. Mutta tärkeä asia on, ettei se
ole automaattisesti game over.

Toinen juttu on tämä include. Eli include
on hyvin käytännöllinen jos käytät kolmansia

osapuolia. Mutta ongelma on, että se ei
ole sitä miltä kuulostaa joillekin, edes

standardissa, se mainitsee, että se oli
huonosti valittu nimi. Ja syy tähän

ettei se ole macro. Eli ymmärtääksesi
mitä tapahtuu kun tämä includataan,

sinun ei pitäisi vain leikata ja liimata
kaikkea rekursiivisesti ylätasolle.

Se ei ole miten se toimii. Se koittaa
ajaa kaikkia testejä tämän includen

sisäpuolella. Mutta jos se epäonnistuu, se
ai automaattisesti poista viestiä. Se menee

yhtä tasoa ylemmäs ja se koittaa ajaa
toisia sääntöjä. Ongelmana siinä

on, että kaksi tapausta jotka ovat
tavallisimipia ovat, että joko vain

unohdat lisätä miinuksen kaikkiin tai
se on sinun system admin joka on

unohtanut sen. Siitä tapauksessa, vaikka
he lisäävät miinuksen kaikkiin, se ei toimi

koska, tarkoitan, se toimisi kun vastaan-
ottaja tarkastaa sitä miinus kaikki

includen sisällä ei tarkoita samaa, kuin
mitä se tarkoittaa top levelillä. Ja

toinen olisi, että he ovat lisänneet kaiken,
mutta soft failanneet. Ja sitten adminit

miettivät. Mutta se in okei, koska sisällytän
GMailin ja GMailissa on tämä hard fail.

Se ei toimi niin. Ja lisäksi, tämä on
todellisuudessa mielestäni yleisin tapaus,

on, että usein kun näet oikeasti tämän
tyyppisen SPF listan, mutta siinä

listan sisällä on paljon juttuja IP
osoitteita. Siellä on A kirjauksia

siellä on MX kirjauksia, Siellä on pointer.
Periaatteessa, mitä vain admin voisi

kuvitella ja syy tähän yleensä on että
he eivät ole varmoja miten se toimii.

He eivät ole varmojja mitä sinne tulisi
laittaa. Eli esimerkiksi, yksi juttu

jonka osoittaa on, että jos siellä on MX
tietue SPF listan sisällä, yleensä useissa

organisaatioissa, elleivät ne ole hyvin
pieniä ja heillä on vain yksi palvelin

heillä on eri palvelimia, eri IP osoitteita
lähtevälle postille ja saapuvalle

postille. Tämä tarkoittaa,ettei ole
käytännön syytä tälle organisaatiolle

ei käytännön syytä lisätä MXaa SPFaan
koska ei, ei postia pitäisi lähteä läpi

heidän saapuvan postin palvelimesta. Ja
toinen juttu voi olla, että admin tietää

tietää miten se toimii, mutta heidän oma
arkkitehtuuri on tosi sekainen ja he

lähettävät postia ulos monesta, monesta eri
pisteestä, mikä on kiva pentestaajille.

Se tarkoittaa etteivät he ole hyvin
organisoituneita. OK ja on vielä yksi vika,

joka on, ettei hienojakoisuus sovi hyvin.
Eli ainoa juttu jota voit.

On useita näitä kirjaus tyyppejä. Mutta
ne kaikki varsinaisesti resolvaavat IP

osoitteen. Mutta kuten voit kuvitella,
usein IP ei ole yhdistetty vain email

palvelimeen. Eli yhdessä IPssa voi olla mail
palvelin ja web palvelin tai tietokanta tai

jotan muuta. Ja se tarkoittaa, että
pentestaajana, voit exploitata tämän

jonkun muun. EI mail serveriä itseään,
koska postipalvelin on yleensä aika pieni

kohde. Niissä ei ole paljon haavoittuvuuksia.
SInä vain päivität ne ja se siitä.

Mutta muissa järjestelmissä, esimerkiksi
web on helppo murtaa. Yleensä.

Sitten voit nostaa, kuten tavallaan nostaa
oikeustasoa saadessasi pääsyn jonkun

toisen palvelun kautta siinä IP osoitteessa
tai IP alueessa. Voit alkaa lähettämään

posteja. Ne läpäisevät kaikki SPF suodatukset.
OK. Eli yksi esimerkki ovat jaetut hostaukset

joka on hyvin tavallista ja ongelma jaetussa
hostauksessa on se. Tässä tapauksessa.

Okei. Sinulla on IP osoite SMTP palvelimelle.
Ehkä sitä palvelinta käytetään vain lähettämään

postia. Mutta palvelin itsessään ei tee
työtä vain sinulle. Se palvelee monia

domaineja, ehkä satoja tai tuhansia. Se
tarkoittaa, että hyökkääjänä, taas, voit

exploitata vain yhden niistä, tai jaetussa
hostauksessa voit vain ostaa. Voit tulla

asiakkaaksi siihen jaettuun hostaukseen.
Sinun ei tarvitse murtaa mitään.

Ja sitten voit ehkä alkaa lähettämään
emailia, joka näyttää hyvältä SPFaa

ajatellen, kuten heidän omaansa. Eli. Ja
toinen on että tarkastetaan väärä identifier.

Ja tämä on varmaankin pahin, pahin
ongelma SPFn kanssa. Se on, kuten

kerroin aiemmin, se että on ainakin
kaksi identifieria. Tyypillisesti kuoren

lähettäjä, ulompi, joka listaa lähettäjän
sitten on se sisempi,

joka on yleensä "from" headeri.
Mutta näistä kahdesta SPF tarkastaa,

jos SPF on ainoa teknologia jota käytät,
SPF tarkastaa vain ensimmäisen:

Kuoren lähettäjän. Kuten kerroin aiemmin,
useimmissa tapauksissa, oikeat käyttäjät

jotka saavat mailin, he eivät näe kuoren
lähettäjiä. He näkevät tämän toisen

"from" esimerkiksi, tai jonkun niistä
toisista headereista joita mainittiin.

Tämä käytös on oikeasti korjattu DMARCssa,
joka on teknologia jonka mainitsin. Mutta

valtaosassa SPF asennuksista, domaineissa,
joissa SPF käytössä ei ole DMARCia,

eli ne eivät ole suojassa tältä. Eli vaikka
heidän SPF olisi hienosti hyökkääjälle,

se tarkoittaa, että sinun tarvitsee vain,
sinun pitää vain ohittaa SPF asettaaksesi

kuoren lähettäjän joksikin toiseksi.
Esimerkiksi, sinun kontrolloima osoite,

joka läpäisee SPF tarkastuksen. Mutta sitten
"from" sisällä voit näyttää headerin, joka

täsmää organisaatioon, joka haluat matkia
olevasi. Okei. Sitten on toinen

teknologia, jonka pitäisi korjata tämä
ja se on DKIM. Kuten olemme nähneet

SPF ei ole riittävä. Eli DKIM. Anteeksi,
väärät kirjaimet, DomainKeys Identified Mail.

Se on DKIM ja sinun ei tarvitse muistaa
pitkää nimeä, vain lyhyt nimi.

Ja mitä se tekee, periaatteessa se käyttää
kryptografiaa, mikä on kiva, eikös? Se on

matikkaa. Se on hankalaa murtaa hyökkääjälle.
Ja mitä se tekee, se allekirjoittaa jokaisen

postin eli jokainen posti joka lähtee
DKIM käyttävältä palvelimelta saa

allekirjoitujsen, jonka voit, vastaanottajana,
kryptografisesti varmistaa. Joten kuten näet,

se vaikuttaa aika vaikealta nähdä, koska
sitä ei ole tarkoitettu ihmisten

prosessoitavaksi. Se on kryptografiaa.
se on tarkoitettu prosessoitavaksi tietokoneille.

Mutta tärkeä osa tässä on periaatteessa
keltainen osa joka on kryptografinen

allekirjoitus. Mutta vihreä osa on, mitä
kutsutaan domain tunnisteeksi. Ja punaista

osaa kutsutaan. En muista miksi sitä
sanotaan nauraa. Mutta periaatteessa sen

idea on, että sinulla voi olla useita avaimia
organisaatiollasi, esimerkiksi, organisaatiosi

voisi lähettää posteja sinun alkuperäiseltä
SMTP palvelimelta, sitten sinulla voisi olla

varalla yksi, tai voisi olla, voisit
lähettää joitain viestejä Googlesta tai

joku markkinointikampanja ja niin edelleen.
Ja jokaisella näistä voisi olla erilainen

"punainen" parametrina. Ongelma on ja
sitten vastaanottajan pitää ajaa DNS kysely,

joka on toinen esimerkki käyttäen tätä
yhdistelmää vihreä ja punainen.

Ja sitten ne hakevat julkisen avaimen ja
voivat käyttää sitä varmistamaan alle-

kirjoituksen. Eli se kuulostaa hyvälle.
Ongelma on, ei, toinen ongelma vielä.

Kuinka käyttää sitä? Luulen sitä helpoksi
jos osaat julkisen avaimen salausta. Eli

lähetys päässä, sinun pitää ensin luoda
julkinen ja salainen avainpari. Sitten

julkaiset julkisen osan DNSaan. Sitten
käytät salaista avainta allekirjoittamaan

viestit. Nyt vastaanottaja tekee tavallaan
päinvastoin. Kun he saavat emailin, he

päättelevät tästä punaisesta ja vihreästä
osasta he päättelevät oikean DNS tiedon

jonka ajaa, ajavat sen, saavat julkisen
avaimen ja vertaavat sitä täsmääkö tämä

julkinen avain viestin allekirjoitukseen.
Kuulostaa kivalta, eikös? Mikä on ongelma?

Eli asiakkaat. Selektorit, se on se nimi.
Eli ongelma siinä on se, että selektoreina

voi olla useita selektoreita DKIM:na
kun teet konfiguraatiota,

voit voit valita niin monta kustom
selektoria kuin haluat ja vastaanottaja

ei tiedä, olisiko sinun oikeasti pitänyt
käyttää selektoria ja mitä

selektoria sinun olisi pitänyt käyttää.
Eli ongelma on että kun, jos puhumme vain

vanilja DKIMsta, olemassa olevan alle-
kirjoituksen muokkaaminen on vaikeaa

penaajalle ja hyökkääjälle. Mutta on helppoa
vain poistaa se, koska jos olet poistanut

DKIMn kaikista headereista, vastaanottaja
ei tiedä, että sen olisi pitänyt olla

siinä, koska tarkistaakseen sen, se pitää
olla. Eli, esimerkiksi, tarkastaakseni

allekirjoituksen, minun pitää tietää tämä
vihreä osa. Tämä domain tunniste ja

selektori, jotka ovat osa headeria. Just.
Eli se on valtava ongelma. Ja se tarkoittaa

että. Yeah. Se tarkoittaa, että vaikka
me emme voi huijata DKIMaa itseään

voimme vain leikata DKIMn, lähettää viestin
ilman sitä. Ja jos DKIM oli ainoa asia joka

suojasi tätä järjestelmää, se toimii. Eli
se ei välttämättä saisi vihreää merkkiä

tai jotain, mutta se menisi vastaanottajalle.
Ja toinen juttu on tämä

domain selektor. Miksi meidän pitää edes
asettaa se? Koska parhaissa käytännöissä,

tietenkin, on että kuoren lähettäjä on sama
kuin "from" header ja tämä DKIM domain

selektori. Just. Eli jos olet jos minä
lähetän Alicelta, niin kaikkien kolmen

pitäisi olla Alice.org tai jotain. Ongelma
on ettei sitä ole mainittu RFCssa että

näin pitäisi olla. Eli mitä tapahtuu jos
asia ei ole näin ?

Erimerkiksi, oikealla on joku oikea domain
joka käyttää Gmailia, Google Appsia

Google suitea ja siinä tapauksessa vakiona
vakiona Google suite allekirjoittaa kaikki

viestit. Mutta jos et tee omaa
konfiguraatiota, se allekirjoittaa ne

domainilla jota hallinnoi, joka on tämä
"gappssmtp". Ja se tarkoittaa, että vaikka

teknisesti jotain on allekirjoitettu DKIMlla
sitä ei ollut allekirjoitettu siten, että

voisit jäljittää sen takaisin sinun
organisaatioon. Se on jotain aivan

muuta. Mitä vastaanottajan pitäisi tehdä
siinä tapauksessa? Pitäisikö jättää väliin?

Pitäisikö hylätä viesti tai jotain? Eli oikea
tapa ei olisi hylätä sitä,

mutta vaan arvioida, ettei se ole oikea,
ainakaan oikea DKIM, mutta oikeasti

se riippuu. Osa tarkastajista näkevät vain
jonkin DKIMn, tarkastavat sen ja

savovat että cool, se täsmää RFChen.
Eli, mutta nyt kiinostava osa. DKIM

muokkaaminen, johon minulla ei ole aikaa.
Mutta ajatus on, että joissain tapauksissa

ei aina, mutta joskus voit oikeasti muokata.
Helpoin osa muokata viestissä

ovat headerit koska DKIM, koska se laitetaan
headereihin itse, se ei automaattisesti

allekirjoita vanhoja headereita. On
tavallaan kana ja muna ongelma. Vakiona

se allekirjoittaa vain yhden tai kaksi headeria
ja voit määrittää lisää headereita joita pitää

allekirjoittaa, mutta se ei tapahdu auto-
maatisesti. Eli helppo osa hyökkääjälle

on lisätä headeri. Jos se jotenkin
auttaa sinua suunnitelmassasi, se on

helppo tehdä. Sinä vain lisäät toisen
headerin. Kiinnostava osa on, että

vaikka RFC, kuten mainitsin aiemmin,
mainitsee, että jotkut headerit kuten

"subject" tai "from" pitäisi olla paikalla
vain yhtenä kopiona. Oikeasti voit lisätä

enemmänkin, esimerkiksi "from" headerin ja
mitä tapahtuu siinä tapauksessa on aika

kiinnostavaa. DKIM täsmää jos olet kertonut
DKIMlle että "from" headerin pitäisi olla

esimerkiksi, allekirjoitettu, sitten se täsmää
ja allekirjoittaa ensimmäisen "from" headerin

alhaalta. Mutta monet ohjelmat meidän software
email ohjelmista todellisuudessa ainoastaan

näyttävät käyttättäjälle ensimmäisen toiselta
puolelta, ylhäältä. Eli se tarkoittaa, että

hyökkääjä voi muokkailla tai ylikirjoittaa
headereita vain lisäämällä uusia headereita

päälle. Ja tämä oikea ongelma on
mainittu DKIM RFCssa ja suojaus

jota he ehdottavat on tämä code
Over-Signing tai voit mennä ja lukea RFCn.

Mutta kaikki eivät tee sitä oikeasti. Ja
kuitenkin, se toimii vain headereille.

Eli joskus se on hyvä. Joskus ei niin hyvä.
Viestin rungon

muokkaaminen on oikeasti vaikeampi toteuttaa.
Periaatteessa naivi tapa tehdä se kryptauksen

kautta, jota emme halua tehdä. Ja toinen
tapa on tämän yhden parametrin

kautta, joka on body lenght, ja se on aikaa
kyseenalainen toiminnallisuus

DKIMssa. Joskus voit määrittää
että tiiviste vaikka. Allekirjoittamiseen,

meidän ei pitäisi ajatella koko runkoa,
vaan ensimmäisiä joitain tavuja.

Eli se on oikeasti käytännöllistä joissain
tapauksissa postituslistoissa, mutta yleensä

se ei ole kovin käytännöllistä. Ja käytännössä
valtaosa email ohjelmista ei tee sitä.

Jos se tekee, se on altis mahdollisesti
tälle koko

rungon ylikirjoittamiselle. Voit lisätä
uuden mime tyypin ja sitten muokata

headereita näyttääksesi eri mime tyypin
ja se ohittaa DKIMn. Eli tässä tapauksessa

se näyttää, esimerkiksi, vihreän painikkeen
tai mitä vaan, koska DKIM, se on oikein.

Eli nyt on kolman teknologia, jota
kutsutaan DMARCiksi. Ja taas,

siinä on koko nimi, joka on pitkä. Mutta
tässä tapauksessa se tarkoittaa jotain.

Siinä on kaksi avainsanaa: Reporting and
Conformance. Reporting on se

jonka suurin osa admineista tuntee, koska
sillä DMARC, luulen, usein myydään

heille. Raportointi tarkoittaa, että
kun sinulla on jotain ongelmia tässä

tapauksessa, sinä voit päästä kertomaan
toiselle puolelle mitä tehdä siinä tapauksessa.

Eli voit käskeä niitä lähettämään sinulle
raportteja kerran päivässä, tai joka kerta

ja niin edelleen. Eli pentestaajalle se ei
ole niin hyödyllistä. Mahdollisesti voisimme

käyttää sitä ymmästääksemme minkälainen
konfiguraatio toimii toisella puolella.

Mutta nykyisin tämä toiminnallisuus ei ole
kovin laajasti implementoitu.

Kuitenkin toinen osa, Conformance, se on
oikeasti todella, todella voimakas.

Mitä se tekee, se korjaa nämä suuret viat
joista mainitsin, SPFssa ja DKIMssa.

Ensinnäkin, DKIMssa oli tämä valtava ongelma
että jos poistit headerin, vastaanottajalla

ei ollut mahdollista tietää mikäli sinä,
mikäli siinä oli, olisi

pitänyt olla DKIM alunperin. Jos käytät
DKIMaa yhdessä DMARCin kanssa, se

korjaa ongelman, koska DMARC määrittää
että sinulla on DMARC itsensä.

Se tarkoittaa, että sinulla automaattiesti
toinen, joko SPF tai DKIM pitäisi mennä läpi.

Eli automaattisesti DKIM mittaus ongelma
ratkaistu. Toinen asia, joka muuttuu on,

se muuttaa semantiikkaa SPFaan. Nyt SPF,
jos sinulla on sekä SPF, että

DMARC, se tarkoittaa, ettö SPF pitäisi
tarkastaa "from" headerista. Ja kuten mainitsin,

se oli suuri vika SPFssa, koska jos käytit
SPFaa itseään, vaikka, se on hard fail

tilassa ja niin edelleen, se tarkoittaa
että hyökkääjä voi muokata "from"

headereita ja vastaanottaja ei tiedä sitä.
Pienin esimerkki DMARCsta on hyvin,

hyvin pieni. Ja mielestäni se on helppo
ymmärtää. Sinulla on vain DMARC hylkää.

Sinun pitää tavallaan löytää oikea paikka
määrittää, mutta se on helppoa ja kaikki

mitä sinun pitää tehdä, on luoda tämä DNS
merkintä. Ja kaikki hyödyt tähän ovat,

vaikka sinulla ei olisi DKIM ja DMARCia, jos
olet luonut. Anteeksi, jos sinulle ei ole SPF

ja DKIM, mutta olet luonut DMARCin, oikeasti
se tarkoittaa että tämän domainin ei

pitäisi lähettää yhtään postia, koska vastaan-
ottajan pitäessä mailia oikeana, pitäisi

SPF tai DKIM olla oikein myös. Jos ne
eivät ole, se ei oi olla oikea.

Eli oikeasti se tarkoittaa, että suurin osa
domaineista tuolla pitäisi harkita DMARC

enablointia. Se on oikea asia tehdä. OK.
Eli on lisää tageja. Eli luonnossa,

nämä DMARC kirjoukset voivat olla paljon
pidempiä, mutta niistä ei ole paljon hyötyä

pentestaajille. Eli tärkeä osa tässä jälleen,
on tämä policy jossa voi olla

kolme arvoa "none", "quarantine" ja
"reject". Ja jos se on "quarantine", se

tarkoittaa, että jos, jos ei onnistu,
viestin pitäisi mennä spam kansioon.

Jos se on "reject" se pitäisi hylätä heti.
Ja jos se on "none", se tarkoittaa, että

se on tutkinta moodi. Ja tämä on kuva
jonka näytin aikaisemmin, joka näyttää

että vaikkakin DMARC on oikeasti paras
teknologia näistä kolmesta,

sitä ei oikeasti käytetä laajalti, ikävää
puolustajien kannalta. Aika kiva seikka

kaikille penetraatio testaajille siellä.
Tämä tarkoittaa, että voit oikeasti

väärentää suurimman osan sähköposteista.
Okei, kuinka kierrämme sen? Anteeksi. No.

Mitä tapahtuu jos joku on oikeasti
implementoinut DMARCin? Tarkoittaako se

että pentestaajat eivät voi tehdä mitään?
Sinun ei tarvitse edes tutkia mitään ?

Ei, se ei tarkoita. Eli käytännössä, jos joku
on implementoinut DKIM ja DMARCin, mutta

ei SPFaa, eli nyt heillä on kaksi niistä.
Se on kiva yhdistelmä. DKIM on melko

voimakas ja sen merkittävän vian joka oli,
DMARC ratkaisi. Eli tämä yhdistelmä on

tosi hyvä teoriassa. Käytännössä, ongelma
on, että suojataksesi omat sähköpostisi,

vastaanottajan pitäisi tarkastaa molemmat
DKIM ja DMARC ja valitettavasti,

melko monet ohjelmat eivät edelleen
tee sitä. Yksi niistä ohjelmista on

Microsoft Exchange. Ja mikäli et käytä
Microsoft Exchangea, on hyvä todennäköisyys

että joku kumppeneista jonka kanssa
kommunikoit käyttää Microsoft

Exchangea ja vakiona siinä ei ole mitään
toimintoa DKIM parsimiseen.

Eli oikeasti, valtaosan järjestelmistä pitää
enabloida SPF ihan käytännön syistä, mikä

on hyvä pentestaajille, koska mikäli
SPF ja DMARC on enabloitu vakiona

yhdessä, silloin se korjaa yhden suuren
ongelman SPFn kanssa, mutta ei

automaattisesti korjaa muita ongelmia,
koska ei ole riittävää hienojakoisuutta ja

virhe konfiguraation mahdollisuutta. Eli.
Ja mielenkiintoinen fakta on, että DMARC

vaatii vain yhden toisen teknologian
SPFn tai DKIMn läpäisyn

Tulkitakseen emailin oikeaksi. Ei ole muuta
tapaa DMARCssa, vaikka on monia muitakin

selektoreja. Ei ole mahdollista määrittää,
että molempien niistä pitäisi olla oikein

tai, että DKIM pitäisi olla edellä SPFaa.
Käytännössä, se tarkoittaa että useimmissa

järjestelmissä, joissa on päällä kaikki
kolme niistä, mikä on hyvä käytännöllinen

ratkaisu pentestaajan puolelta, voimme vain
unohtaa DKIM heti ja keskittyä SPFaan

koska SPF on heikoin lenkki tässä tilanteessa.
Okei, vain yksi minuutti kertaukseen.

En ole varma, onko minulla enää aikaa.
Minulla ei ole paljoa aikaa. Okei. Eli,

anteeksi. Yeah. Eli yksi tärkeä asia huomata
on, että testatessasi järjestelmää, harkitse

molempia skenaarioita. Eli älä keskity vain
lähettämiseen. Jos olet, esimerkiksi,

testaamassa Alicea. Alice on organisaatio,
joka on asiakkaasi. Älä keskity vain testaamaan

sähköpostien lähettämistä teeskennellen Alicea,
mutta myös toista puolta. Koska tässä voit

nähdä, että on helppo implementoida,
esimerkiksi SPF ja DMARC, koska

molempiin niistä, sinä tarvitset vain DNS
konfiguraation. Vain yksi merkintä kumpaankin.

Kuitenkin niiden testaaminen, siis
todentaminen kunnolla on vaikeampaa.

Ensinnäkinen tarvitset ohjelmistotuen ja
sinun pitää konfiguroida se oikein myös.

Eli käytännössä voi olla, että useat
organisaatiot, jotka ovat enabloineet

DMARCin tai SPFn DNS puolella lähteville
posteille, he eivät ole oikeasti kunnolla

tarkastaneet sitä. Yeah. Okei. Anteeksi.
Minulla ei ole aikaa siihen. Eli varmaankin.

Se on siinä, anteeksi. Ehkä pari kysymystä.

aplodeja

Herald: Kiitos, Andrew, tästä hyvästä
esityksestä. Toki. Meillä on aikaa parille

kysymykselle. Eli tuolla näen jo yhden
henkilön, mikrofoni numero kaksi.

M2: Hei, kiitos paljon. Tesdätkö jotain
hyvää työkalua valvomaan DMARC raportteja

joita minulle lähettävät vastaanottajani.
A: Yeah. Tämä on todella hyvä kysymys.

Me CERTna, me todella suositamme kaikille
tämän työkalun käyttöönottoa, mutta

valitettavasti, tietääkseni, kaikki
työkalut, jotka ovat suosittuja netissä,

ne keräävät jotain dataa sinusta. Eli
ne käyttävät sitä markkinointitarkoituksiin,

ne eivät ole hyviä yksityisyyden kannalta,
jos olet siitä huolissaan.

Eli sinun pitää implementoida jotain itse
tai sinun pitää katsoa jotain, aloita

joku open source projekti ehkä.
Herald: OK. Mikrofoni numero yksi, kiitos.

M1: Kiitos hyvästä esityksestä. Minä itse,
pidän itseäni email pääkäyttäjänä.

Minua joskus ohjeistetaan lyhentämään
meidän SPF listaa, koska jos se on liian

pitkä, se poistetaan kuitenkin. Siksi
minua joskus neuvotaan pudottamaan

PTR kirjaus. Mutta esityksessäsi, sanot,
että PTR merkintä on hyödyllinen reverse

DNS tarkastuksessa, jonka koen myös hyödyl-
lisenä. Miten ajattelet SPF listan lyhentämisestä

ja mitä ajattelet PTR merkinnöistä yleensä.

A: No, se oikeastaan riippuu juuri sinun
tapauksesta. Eli voi olla tilanne, että

jotkut organisaatiot todella tarvitsevat
tämän pitkän SPF listan ja sitä ei voi

kiertää sinun toimesta. Mitä voisit tehdä
on sisällyttää tämä, sisällytä käytä includea

koska ne eivät ole, ne eivät ole makroja,
eli ne eivät tule laajennetuiksi. Ne eivät

kuten, sinun lista ei tule pidemmäksi jos
sisällytät ja käytät useita includeja. Mutta

ongelma, jota suosittelisin sinulle on,
harkitse tarvitsetko todella, todellako

tarvitset niin monta merkintää jos se
on silti niin pitkä, koska ne ovat hyvin

yleinen ongelma, on että ellet ole Google
tai jotain sellaista, et oikeasti tarvitse

niin pitkää SPF listaa. Se on varmaan
ongelma jossain. Yeah. Eli se on varmaan

virhe useimmissa organisaatioissa.
Herald: OK. Sopii, kyllä. Vain lyhyesti.

Numero 1
M1: PTR record kirjauksesta. Kuulin, että

se pudotetaan. Ei pudoteta standardeista,
mutta sitä ei ole standardeissa.

A: Se on standardeissa. Ei. PRT kirjaus
itsenään, jos se on todella sinun tapaus.

En tiedä, En ole tietoinen että sitä
automaattisesti pudotetaan jonnekin.

Ei pitäisi olla ongelma.
Herald: Meillä on pari

kysymystä lisää täällä. Eli numero
kuusi, siellä ihan takana.

M6: Kiitos, kiitos esityksestä. Tämä ei
suoraan liity, mutta vaikka sen pitäisi

liittyä. Jos postipalvelin hyväksyy, koska
DKIM, DMARC ja SPF, kaikki on hyvin,

mutta erityisesti Google, useille organi-
saatioille, posti toimitetaan mutta

luokitellaan spamiksi. Se tarkoittaa, että
vastaanottajan inboxissa, sitä ei näytetä.

Onko sinulla ratkaisua jolla ratkaistaan
tämä ongelma Googlea vastaan.

A: Yeah. OK. Eli minulla on erilaisia
mielipiteitä siitä, koska yksi asia joka

oikeasti saa meidät tekemään, mitä meidän
pitäisi tehdä. Kiitos Google. On, että he

ovat niin tiukkoja, että koska se on ainoa
syy miksi meillä edes on näin korkea

prosentti edes huonosti konfiguroituja SPFia.
Ainoa syy miksi 70 prosenttia web-sivuista

käyttää SPFaa on, koska heidän pitää
kommunikoida Googlelle.

Ja Google ei hyväksy postiasi, jos sillä ei
ole edes SPF perusteita. Eli minä

oikeastaan pidän työstä jota teen. Minä.
Minä suosisin, että Google tekee mitä tekee.

Mutta ymmärrän oikeita admineja, joilla
on tämä ongelma. Googlella on työkalu.

Te varmaan tiedätte siitä. Missä voit
tarkastaa mitä se ajattelee sinun domainista.

Eli sinun pitää harkita tätä ongelmaa
tapaus tapaukselta. Aika usein

mitä tapahtuu on, että vaikka sinulla on
tämä DKIM, DMARC ja niin edelleen, sitä ei

ole konfiguroitu oikein. Eli mistä esitys
oli. Siinä se on. Sinä varmaankin

ajattelet konfiguroineesi sen oikein,
mutta siinä on virheitä.

Herald: Okei, annetaan etusija
Internetille.

Signal Angel: Meillä on kysymys Internetistä.
No, Yrittäessä varmistaa ja päättää

miten käsitellä "älä vastaa" email
osoitteita.

A: Ei vastausta, anteeksi. Voitko lukea sen
uudelleen.

Signal Angel: Kun yrittäessä varmistaa
osoitetta, kuinka käsitellä No Reply

email osoitteita.
A: Ehkä se oli noreply headereista kyse?

Tai olemattomista IP osoitteista?
Signal Angel: Kuinka käsitellä emailia

"No Reply" email osoitteesta.
A: Koitan vastata kuten kuinka käsitän sen.

Eli mitä usein tapahtuu on, mitä usein
tapahtuu on, että sähköposti

lähetetään olemattomasta osoitteesta. Eli
ehkä siitä oli kysymys. Esimerkiksi

siinä on "no reply" ja se ei ole ongelma
itsessään. No Reply. Ongelma on, ettei

se ole oikea osoite. Ei ole olemassa sitä
osoitetta. Just. Ja niin minulle ei ole

vastausta tähän, koska RFCn mukaan, sinun
pitäisi, pitäisi silti hyväksyä se.

Käytännössä. kuten sanoin, useat sähköposti
järjestelmät jo hylkäävät tämän osoitteen

jos lähetät olemattomasta, ellet ole
Google tai jotain

suurta, jolloin sinut on laitettu whitelistalle.
Et vain voi tehdä sitä.

Et voi lähettää sähköpostia olemattomasta
osoitteesta. Eli jos se on sinun tilanteesi,

luo se osoite, laita se vaikka poistamaan
kaikki email joka sinne tulee,

mutta luo oikea osoite, joka sinun on
hyväksyttävä. Jos olet toisella puolella.

Eli jos saat tämän emailin. Se riippuu
siitä tietystä tapauksesta.

Eli katso mitä on meneillään. Jos voit ottaa
heihin yhteyttä, ota yhteyttä. Jos et voi

ottaa yhteyttä, sitten sinun pitää päättää
mikä on riski, jos hylkäät nämä osoitteet,

ovatko ne tärkeitä sinulle? Eli RFCn
mukaan sinun pitää ottaa vastaan ja

prosessoida tämä osoite.
Herald. Okei, Mikrofoni numero neljä,

ole hyvä.
M4: Hei, kiitos esityksestäsi. Tiedätkö

yrityksistä ratkaista ongelma suurten email
lähettäjien osalta kuten online kirjakauppojen,

jotka ovat kivoja, koska niillä ei näytä
olevan omia SPF kirjauksia, esimerkiksi

omassa hallinnassaan.
A: Yeah. Eli monessa tapauksessa voit vain

ottaa heihin yhteyttä. Eli kyse on vain
siitä, että he eivät ajatelleet sitä.

Tai ehkä kukaan ei ole kertonut mitä tehdä,
tai ehkä he eivät kuinka tehdä paremmin. Just.

Eli se on yksi asioista, joita CERTna me
olemme tekemässä. Jos teillä joillain on

tämä ongelma suuren yrityksen kanssa
jossain tietyssä maassa, suosittelen puhumaan

CERTlle. Vaikka se ei olisi valtiollinen
organisaatio, esimerkiksi, Latviassa,

jos se olisi Latvialainen yritys.
Me teemme triagen. Me yrittäisimme

puhua heille, selittää miksi he tarvitsevat
muutosta ja niin edelleen.

Eli se on yksi vaihtoehto sinulle. Mutta
käytännössä jos joku näyttää sinusta

kolmantena osapuolena väärältä
konfiguraatiolta, en voinut sitä mainita

tässä esityksessä. Jos joku ei ole täysin
turvallinen, se ei tarkoita, että se olisi

väärin. Voi olla oikeasti liiketoiminta
vaatimus miksi sen pitää olla niin.

Just. Koska esimerkiksi, jos se on iso,
en tiedä, Amazon ja joku tai

jotain sellaista. Ja jos he ovat testanneet
ja tietävät, että jos he kytkevät todella tiukan

konfiguraation, tietty prosentti heidän
emaileista vain jää saapumatta. Ei heidän

ongelman takia, vaan jonkun toisen
ongelman. Just. Mutta sitten on

ihan oikea bsiness case, jota he
eivät ole. Olisi heidän kannalta typerää

laittaa se päälle, tiedäthän, tiukka
konfiguraatio, tietäen että se

vahingoittaa heidän liiketoimintaa.
Siinä on järkeä, eikö vain?

Herald: Okei, Meillä on valitettavasti aika
loppumassa niille, jotka ovat mikrofoneilla.

Olkaa hyvä ja tulkaa vain jonoon puhujalle
pöydän viereen. Hän puhuu

teille. Varmastikin. Ja.

aplodeja

36c3 esityksen jälkimusiikki

Translated by Esa Lammi
(KYBS2001 course assignment at JYU.FI)