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)