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)