37C3 - SMTP Smuggling – Spoofing E-Mails Worldwide

Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)

[Musiikkia]

OK. Seuraavaksi puhuu Timo Longin,

joka tunnetaan myös nimellä Timo Login.

Hän tietoturvakonsultti ja tutkija. Hän tulee puhumaan uudesta tekniikasta

nimeltään SMTP Smuggling,

jolla voidaan väärentää sähköposteja

ja hyväksikäyttää eräitä eniten käytettyjä palveluita internetissä.

Kiitos. Annetaan Timolle applodit.

[Aplodeja]

Kiitos esittelystä.

Ensinnäkin, pulskat pahoittelut omasta ja SEC Consult:n puolesta

tämän katastrofaalisen haavoittuvuuden julkaisemisesta.

Erityisesti pahoittelut Wietselle ja Viktorille Postfixin korjaamisesta.

sekä kaikille järjestelmävalvojille ympäri maailman,

jotka ovat joutuneet asentamaan korjauksia joululoman aikana.

Ja lisäksi, joka tapauksessa,

suuret kiitokset Wietselle ja Viktorille

heidän sitoutumisestaan.

Ja lisäksi suuret kiitokset yhteisölle

tämän ongelman viemisestä julkaisujärjestelmiin ja niin edelleen.

Ja kaikille... Okei...

[Aplodeja]

Ja kaikille niille,

joilla ei ole mitään hajua tästä.

Joten minäpä autan teidät samalle sivulle.

Noin vuosi sitten olin juuri

lopettanut tutkimukseni DNS:n parissa.

ja etsin uutta tutkimuskohdetta,

kun löysin todennäköisesti helpoimman

tavan hakkeroida yrityksen

ja kaikki tämä vain yhdellä

yksinkertaisella Google-haulla.

[Yleisön naurua]

Ja tämä saattaa kuulostaa tyhmälle,

mutta tämä johdatti minut suuntaan,

jonka jo tiesin, mutta en ollut ymmärtänyt.

Ja se on, että tietojen kalastelu on edelleen

numero 1 ensipääsyvektori yritykseen

ja sitten minulla välähti:

Miksen tutkisi SMTP:tä,

simple mail transfer protocol:aa

jota käytetään miljardien sähköpostien

lähettämiseen joka päivä ympäri maailman

kuten on tehty viimeisen 40 vuoden ajan.

Joten matkani eteni DNS:stä SMTP:hen

ja tänään esittelen uuden

SMTP Smuggling -tekniikan

sähköpostien väärentämiseksi.

Kuka olenkaan? OIen Timo Longin

ja työskentelen tietoturvakonsulttina

SEC Consult -yhtiössä ja

päivisin teen penetraatiotestausta

ja öisin teen haavoittuvuustutkimusta.

Ja viimeisen kolmen vuoden aikana olen

tutkinut paljon DNS-haavoittuvuuksia.

Ja olen julkaissut paljon blogikirjoituksia ja työkaluja.

Ja minun täytyi siirtyä eteenpäin.

Edellisen kerran, kun joku SEC Consult:sta puhui CCC:ssä...

se oli... dildoista.

[Yleisön naurua]

Ja tiedän, että joudun tuottamaan osalle

teistä pettymyksen,

mutta tämä esitys ei kerro

ihmiseen penetroitumisesta.

Esitys kertoo tunkeutumisesta SMTP-protokollan muurien läpi.

Joten nähdäksemme miten tämä toimii

on meidän ensin ymmärrettävä

miten sähköpostien lähetys yleensäkin toimii.

Joten tässä meillä on melko yksinkertainen sähköposti-infrastuktuuri.

Meillä on sähköpostikäyttäjäagentti,

kuten Thunderbird, ja Thunderbird haluaa lähettää sähköpostin

esimerkiksi käyttäjänä [e-mail].

Joten jos haluamme lähettää sähköpostin tällä tavalla

meidän täytyy ensin tunnistautua

Outlook mail transfer agentille tai

ulospäin menevälle SMTP palvelimelle.

Ja kun olemme tunnistautuneet,

voimme lähettää sähköpostin käyttäjänä [e-mail].

Ja vain käyttäjänä [e-mail].

Tämän jälkeen viesti siirretään vastaanottajan

SMTP-palvelimelle ja tämä palvelin

tarkistaa viestin aitouden.

Ja kaikkein yleisen tapa tehdä tämä on SPF.

Vastaanottava SMTP-palvelin saa SPF-tietueen

DNS-palvelun kautta outlook.com osoitteelle.

Ja tarkistaa sen jälkeen, että tämä IP-osoite

ja IP-alue on sallittu lähettää sähköpostiviestejä

outlook.com osoitteelle.

Tässä tapauksessa todellinen Outlook SMTP-palvelin

tai ulospäin lähtevä SMTP-palvelin lähetti viestin,

vastaanottava SMTP-palvelin

hyväksyy viestin.

Ja nyt luonnollisesti tässä on erittäin

mielenkiintoinen kysymys.

Ja kysymys on: onko hyökkääjän mahdollista

lähettää sähköpostiviesti

esimerkiksi osoitteesta [e-mail] tai

väärennetystä sähköpostiosoitteesta?

Tätä me selvitämme tänään

ja se on enemmän tai vähemmän

tämän tutkimuksen tavoitteista.

En tiedä oletteko huomanneet,

mutta näiden palvelimien värit

muistuttavat minusta Paavo Pesusieneä

ja Patrik Tähtöstä.

Ja sen vuoksi kutsumme niitä niiksi.

Tutkimuksen yleinen tavoite ja

tutkimuksen peruste oli löytää

tapa väärentää sähköposteja.

Ja ajattelin, että miksi en ottaisi haavoittuvuuksia

muista tekstipohjaisista protokollista,

kuten HTTP:stä, ja soveltaisi niitä SMTP:hen.

Ja oli yksi HTTP haavoittuvuus, joka sopi kuvaan

ja se oli HTTP-pyynnön käpelöinti.

Tässä meillä on taas Paavo ja Patrik,

mutta tällä kertaa HTTP-maailmassa.

Joten, mitä tässä tapahtuu? Paavo Pesusieni saa
POST-tyyppisen pyynnön internetin yli

Mielenkiintoista tässä pyynnössä on se,
että siinä on kaksi otsikkoa

kuinka käsitellä POST-pyynnön data.

Siinä on Content-Length -otsikko, jonka arvona
on 43 tavua.

Ja siinä on myös Transfer-Encoding -otsikko.

Nyt Paavo Pesusienen täytyy päättää,
miten käsittelen pyynnön ja Paavo päättää

käyttää Content-Length otsikkoa, koska se on
43 tavua.

Joten kaikki punaisella kehystetty data
on välitetty Patrikille.

Patrikilla ei ole mitään hajua mitä tehdä - pitäisikö
minun tulkita Content-Lenth otsikkoa vai

Transfer-Encoding -otsikko? Patrik päättää
tulkita Transfer-Encoding otsikkoa ja

nyt meillä on eriävät tulkinnat:

Paavo Pesusieni käyttää Content-Length -otsikkoa
ja Patrik Tähtönen käyttää Transfer-Encoding -otsikkoa.

Ja koska Transfer-Encoding on määritetty "chunked" ("paloiteltu") ja
ja ensimmäinen pala on 0,

on loput Paavo Pesusienen lähettämästä datasta
tulkittu toiseksi pyynnöksi.

Itse asiassa tämä tarkoittaa, että Paavo näkee
yhden pyynnön ja Patrik kaksi pyyntöä.

Ja toinen pyyntö voidaan kohdistaa mielivaltaiseen
resurssipolkuun, kuten "Admin",

joka tässä esimerkissä on avoin vain sisäisesti
palvelimella.

Joka on tietenkin ongelma.

Joten ajattelin, että miksi en ottaisi
näitä tulkintaeroja

ja laittaisi niitä SMTP:hen.

Ymmärtääksemme... tai ainakin päästäksemme
lähemmäs ymmärrystä miten tämä toimii,

täytyy meidän katsoa ensin itse SMTP
protokollaa.

Joten, SMTP näyttää kuta kuinkin tältä.

Meillä on kaksi komponenttia: SMTP komennot
punaisella ja sinisellä viestin data.

Lähettääksemme viestin, meidän tulee ensin
lähettää SMTP komennot:

Meidän pitää esitellä itsemme, kertoa lähettäjän
osoite, yksi tai useampi vastaanottajan osoite ja

sitten lähetämme "data" komennon
kertoaksemme vastaanottavalle SMTP-palvelimelle

että olemme nyt vastaanottamassa varsinaista
viestin dataa.

Ja sitten lähetämme viestin datan: määrittelemme
lähettäjän osoitteen uudelleen, vastaanottajan osoitteen
ja viestin aiheen.

Ja sitten tulee viestin leipäteksti.

Ja kun jossain vaiheessa haluamme
lopettaa viestin datan lähettämisen,

meidän tulee lähettää jotain, jota kutsumme
datan lopetussekvensiksi.

Se on "<paluu rivin alkuun><rivinvaihto> piste <paluu rivin alkuun><rivinvaihto>"
[kääntäjän kommentti: jatkossa .]

Tässä vaiheessa ajattelin, että ehkä voisimme
hämätä tällä jotenkin SMTP-palvelinten toteutuksia.

Ajatus oli siis, että meillä on jälleen Paavo Pesusieni
ja lähetämme sähköpostin Paavo Pesusienelle [SIC].

Ja tämä sähköposti sisältää jotain
todella outoa, jotain joka näyttää

lopetussekvensille, mutta se ei ole sitä.

Koska se ei ole yhdenmukainen RFC:n kanssa, joku
voisi virheellisesti tulkita sen datan lopetussekvensiksi.

Joten Paavo Pesusieni katsoo tätä ja ajattelee
ettei tämä ole RFC:stä, en tulkitse tätä
"end-of-data" sekvensiksi

Ja seuraavaksi... tai viestin data siihen saakka,
kunnes varsinainen datan lopetussekvenssi tulee.

Sitten Paavo Pesusieni lähettää viestin Patrikille

Ja Patrik on "Jeah, en välitä mistään RFC:stä ja
ja tulkitsen väärän datan lopetussekvenssi

varsinaiseksi datan lopetusmerkiksi."

Ja ongelmaksi tässä tulee, että kaikki väärin
tulkitun lopetussekvenssin tulkitaan SMTP-komennoiksi

Ja nyt hyökkääjänä voimme luoda SMTP-komentoja,
jotka lähettävät toisen sähköpostiviestin.

Vaikka Paavo Pesusieni näki yhden ison
sähköpostiviestin, Patrik näkee kaksi pienempää viestiä.

Ja ongelma on se, että toinen viesti voi sisältää
mielivaltaisia SMTP-komentoja.

Kuten, että viesti tulee osoitteesta [e-mail]
tai mitä tahansa.

Näin ainakin teoriassa.

Nähdäkseni toimiiko tämä todella.

Tutkin muutamia SMTP-palvelinten
toteutuksia yksinkertaisesti

ottamalla niihin yhteyttä telnet:llä tai
netcat:lla.

Kun tein tämän, se näytti aluksi RFC:n mukaiselta.

Kun lähetät datakomennon, palvelin pyytää
lopettamaan datan lähettämisen . merkeillä.

Sitten löysin myös palvelimia, jotka sanoivat:
"lähetä minulla rivi, jossa on vain piste"

Ja tämä asia riippuu paljon käytettävästä
käyttöjärjestelmästä.

Windows:ssa tämä voi olla <CR><LF>.<CR><LF>
ja Linuxissa se voi olla .

Siinä kohtaa ajattelin, että tässä voisi
olla jotain.

Ja kokeilin jotain.

Ensimmäiseksi kokeilin työntää <CR>-, <LF>- ja piste-
merkkejä Paavo Pesusienen kautta.

Joten kirjoitin SMTP analyysisovelluksen, joka
lähettää sähköposteja, joissa on virheellisiä data lopetussekvenssejä,

kuten <LF>.<LF> Ja lähetin viestejä eri SMTP-
ohjelmistoilla,

sisältäen sähköpostipalveluita Gmail, Outlook, GMX

ja lisäksi sähköpostiohjelmistoja kuten Postfix,
Exim, Microsoft Exchange Server ja niin edelleen.

Vastaanottavalla puolella tutkin, että mitkä
vääristä sekvensseistä menee itse asiassa läpi.

Voinko lähettää komennon <LF>.<LF> lähtevän palvelimen
kautta?

Ja useimmissa tapauksissa se ei toiminut.

<LF>.<LF> on usein suodatettu tai poistettu
alkuperäisestä viestistä.

Mutta jossain tapauksissa se menee läpi muuttumattomana.

Tämä oli tilanne GMX:n kohdalla. Lähetin sähköpostin
GMX:stä analyysipalvelimelleni

ja <LF>.<CR><LF> merkkejä ei poistettu.

Seuraavaksi tein proof-of-concept:n, jossa on
ensin viesti

ja sitten väärennetty datan lopetussekvenssi

ja sen jälkeen SMTP komentoja ja data
toiselle sähköpostiviestille.

Jos tämä proof-of-concept toimii,

meidän pitäisi saada kaksi viestiä
vastaanottajan puolella.

Lähetin tämän kaiken Gmailiin.

Ja Gmail oli sitä mieltä,
että "tämä ei ei ole datan lopetussekvenssi".

Ja sen näkee siitä, että datan lopetussekvenssin
jälkeen kaikki on edelleen tulkittu viestin dataksi.

Mutta joissain tapauksissä tämä itse asiassa toimi.

Tämä oli ensimmäinen onnistunut
SMTP Smuggling tapaus, GMX:stä Fastmail:iin.

Me näemme, että se toimii. Meillä on ensin
viesti käyttäjältä [e-mail]

ja toinen viesti käyttäjältä [e-mail],

jotka läpäisevät SPF ja DMARC tarkistukset,
koska ne tulevat todelliselta GMX:n palvelimelta.

[Applodeja]

Minä olin, että "tämä on aivan sairasta!"

Ajattelin, että meillä on tämä toinen viesti
ja siinä voi olla mitä tahansa.

Kuten lähettäjän osoite voi olla mitä vaan.

Joten miksi en kokeilisi muita domaineja,
jotka osoittavat GMX:n palvelimeen?

Sitten analysoin SPF tietueen ja tajusin...

Tässä on GMX:n SPF-tietue, mutta se on hyvin
samankaltainen web.de:n tietueen, joka puolestaan

on hyvin samankaltainen Ionoksen tietueen kanssa.

Ja tilanne on nyt se, että tällä me voimme
väärentää 1.35 miljoonaa domainia tällä.

Jos ette tiedä mikä Ionos on, niin se on superiso
hosting- ja sähköpostipalveluiden tarjoaja.

Ja heillä on nämä 1.35 miljoonaa domainia
kytketty tähän.

Joten, minun täytyi tietenkin kokeilla tätä.

Tässä on sähköposti osoitteesta [e-mail]

Nyt kysymys on tietysti, että toimiiko
tämä kaikkialla?

Kuten sanoin, niin tämä toimii vain palvelimilla,
jotka tulkitsevat lopetussekvenssit

tavalla, joka ei ole RFC:n mukainen,
kuten .

Voimme siis väärentää 1.35 miljoonaa domainia.

Joten pohjimmiltaan meillä on 1.4 miljoonaa Postifix instansia
ja 150 tuhatta Sendmail instanssia.

Ja tämä toimii, koska ne tulkitsevat...

[puhuja sekoilee sanoissaan]

Ne tulkitsevat <LF>.<CR><LF>, sekoilen itsekin sanoissani,
lopetussekvensiksi.

Ja olin, että OK, tämä on aika vakavaa.

Mutta tässä on muutakin.

Katsoin outlook.comia myös ja Outlook
palautti todella oudon virheilmoituksen

koska siinä on, että pelkät rivinvaihdot
eivät ole sallittuja.

Olin siinä kohtaa, että pahus, ne tietää
mitä olen tekemässä.

[Yleisöän naurua]

Siksi analysoin sen tarkemmin, ette pysty
minua tuolla pelottelemaan.

Joten löysin, että <LF>.<CR><LF>
on mahdollinen täällä.

[Yleisön applodeja]

Jeah, pidetään vähän hauskaa.

Tässä kohtaa en ollut varma, että
olenko tulossa hulluksi

vai toimiiko tämä todella.

Joten tarvitsin jonkinlaisen tarkistuksen.

Ja niinpä lähetin sähköpostin
osoitteesta [e-mail]

muutamille kollegoilleni. Idea oli siinä,
että jos he reagoivat tähän,

se toimii.

Muutoin olen tullut hulluksi.

Joten....

[Yleisön naurua]

Ja ehkä nyt hieman kansainvälisempi esimerkki,
koska tämä on todella itävaltalainen, luulen.

Luulen, että ymmärrätte tämän, vaikka ette
puhu saksaa.

Ja nyt olette, okei, voimme lähettää
tekstipohjaisia, väärennettyjä sähköposteja

mutta ette pysty huijaamaan tällä ketään

Mutta juttu on siinä, että voimme ujuttaa
periaatteessa mitä tahansa,

HTML:ää mukaan luettuna

Tässä lähetin viestin, kalasteluviestin,
epätavallisesta kirjautumisesta

osoitteesta [e-mail]
todelliselta outlook.com palvelimelta

itselleni.

Ja se vain meni läpi.

Mutta jälleen, mitä tämä mahdollistaa?

Pohdiskelin, että voimme väärentää outlook.comin,

mutta mitä muuta voimme tehdä tällä?

Katsoin SPF tietuetta ja se oli outo,
oudosti tuttu.

Koska tämä ei ole pelkästään outlook.comin SPF tietue

vaan miljoonien muiden domainien SPF tietue.

Sen vuoksi, koska tämä Exchange Online
palvelun SPF tietue.

Outlook.com lähettää sähköpostit Exchange Online
infrastruktuurin kautta,

joten voimme itse asiassa väärentää ne kaikki.

Minun piti kokeilla tätä taas.

Tämä toimi ainoastaan teknisesti,
en saanut palkan korotusta.

Mikä vaikutus tällä on?

Voimme väärentää miljoonia domaineja,
mutta ketkä hyväksyvät nämä sähköpostit?

Jälleen Postfix ja Sendmail, mutta vain ne
instanssit, jotka eivät hyväksy BDAT komentoa.

BDAT on vaihtoehtoinen datakomennolle

ja jos sitä tuetaan, tämä ei toimi.

Se oli ulospäin SMTP suuntautuva ujutus,

joka on yksi osa tätä.

Sitten on myös sisäänpäin tuleva
SMTP ujutus.

Ulospäin suuntautuvassa ongelma oli
lähettävä palvelin

koska palvelin epäonnistui tai ei tehokkaasti
suodattanut väärennettyä datan lopetussekvenssiä

kuten <LF>.<CR><LF> Microsoftin ja
GMX palveluissa.

Sitten on lisäksi sisäänpäin tuleva SMTP ujutus.

Tämä tapahtuu, kun on vastaanottava palvelin,
joka tulkitsee sellaisen villin datan lopetussekvenssin,

josta lähettävällä palvelimella ei ole hajuakaan
suodattaa pois.

Löysin tällaisen Cisco Securesta, tietysti, Email Cloud Gateway:sta

Mitä he tekevät on se, että he siivoavat viestin ja <CR> merkki
korvataan merkeillä.

Joten itse asiassa, <CR>.<CR> merkkien tulkinta
palauttaa datan lopetussekvenssin.

[Yleisön applodeja]

Ongelma on nyt siis tietenkin se, että <CR>.<CR>
ei suodateta ollenkaan pois.

On palveluita, jotka sen tekevät, mutta meillä
on jälleen Exchange Online, iCloud, Sendmail, Postix

ja monia muita, jotka päästävät tämän läpi.

Tavallaan se käy järkeen, koska en hoksaisi
sitä itsekään.

Joten, minun täytyi kokeilla tätä jälleen.

Valitettavasti, tai teknisesti, se toimi jälleen,

mutta en saanut en saanut yhtään Applen laitetta.

Ei sillä, että olisin halunnut muutenkaan.

Mikä vaikutus tällä on?

Pohjimmiltaan voimme väärentään vielä
enemmän domaineja kuin edellä.

Meillä on Exchange Online, meillä on iCloud,

meillä on Postfix ja Sendmail.

Ja voimme väärentää yrityksiä, joilla on
vara tähän.

Aika isoja yrityksiä tässä.

Tämä pitää sisällää yli 40 tuhatta muuta domainia.

Ja se on vain ne, jotka on hostattu pilvessä.

Lisäksi on on-prem instanssit, mutta en pystynyt
käymään niitä läpi.

Ja nyt osuuteen, joka on luultavasti mielenkiintoisin teille,
tai ainakin osalle teistä.

Vastuullinen julkaisu.

Puhtaasti teknisesti, koskien lähettäviä ja
vastaanottavia palvelimia, kenen vika tämä on?

Meillä on vastaanottavia palvelimia, joiden ei
koskaan oleteta tulkitsevan mitään muita

datan lopetussekvenssejä kuin <CR><LF>.<CR><LF>,
ainakin RFC:n mukaan.

Sitten meillä on lähettäviä palvelimia, joiden
ei oleteta lähettävän ja merkkejä

toisistaan riippumatta.

Joten periaatteessa tämä on kaikkien vika.

Lähetimme tiedot GMX:lle.

He olivat superkiitollisia ja ilmoittivat
korjaavansa asian saman tien.

10 päivää myöhemmin he korjasivat tämän.

He pyysivät meitä tarkastamaan uudelleen ja
tarkastimme, että he todella korjasivat sen.

He maksoivat meille pienen palkkion.

Ha laittoivat meidät jopa heidän
Bug Bounty Hall of Fame:en.

Kaiken kaikkiaan se oli 10/10 kokemus.

[Applodeja]

Aion lähettää heille tallenteen teidän applodeista. Kiitos!

Tuntui melkein sille, että meidän olisi pitänyt
maksaa palkkio heille.

Tästä eteenpäin mennäänkin sitten alamäkeä.

Meillä on Microsoft. Microsoft oli sitä mieltä,
että tämä on kohtuullisen riskin haavoittuvuus.

En tiedä, ehkä heillä on suurempi kala kiikarissa,
mutta joka tapauksessa.

Lähetimme tiedot heille ja kolme kuukautta
myöhemmin he sulkivat tapauksen ja sanoivat,

että kaikki on korjattu, ei palkkiota ja niin edelleen.

Tässä kohtaa olin saanut jo mitä halusin.

Ja se on sähköpostin saaminen osoitteesta
[e-mail]

Ja sitten Ciscoon.

Ciscon mielestä tämä ei ollut haavoittuvuus,

vaan dokumentoitu ja konfiguroitava ominaisuus.

Me olimme sitä mieltä, että onpa outo
ominaisuus,

koska voimme väärentää sähköposteja sillä.

Sanoimme, että kertokaa edes asiakkaillenne
tästä ominaisuudesta,

joka ei välttämättä ole paras oletustoiminallisuus.

He sanoivat "Ei".

Me olimme siinä, että meillä on tämä
suuri SMTP Smuggling ongelma.

Ja Cisco ei halua tehdä mitään, Microsoft
oli haavoittuvainen siihen aikaan.

Me veimme tämän tapauksen CERT/CC:lle.

Niille, jotka eivät tiedä, CERT/CC koordinoi
ja käsittelee näitä suuria haavoittuvuuksia,

joilla voi olla maailmanlaajuisia vaikutuksia.

Me lähetimme tiedot heille ja he itse asiassa
hyväksyivät tapauksen.

Sitten olemme tässä Vince portaalissa.

Joka on periaatteessa iso chat-huone, jossa
on 14 toimittajaa.

Siellä on SendMail, Microsoft, Cisco, Google

Ja sitten voimme alkaa puhumaan haavoittuvuudesta

Ensimmäisessä keskustelussa Cisco sanoo
edelleen, että kyseessä ei ole haavoittuvuus.

Tiedättehän, se ei ole bugi, vaan ominaisuus.

Noh, joka tapauksessa se ei ole haavoittuvuus heidän
mielestään.

Ja sitten CERT/CC on sitä mieltä, että
kyseessä ei ole haavoittuvuus, jostain syystä.

OK. Entäs yleinen SMTP ujutusongelma?

Entäs Postfixin ja Sendmailin RFC:stä eriävät
tulkinnat datan lopetussekvenssistä?

Ensinnäkin, Sendmail oli tässä Vince portaalissa
alusta alkaen.

He saivat kaikki PoC:t, viestit, kaiken.

Ja he eivät sanoneet mitään.

Entäpä Postfix? He ovat 10 kertaa suurempi.

CERT/CC oli... en tiedä miksi he eivät
lisänneet heitä tapaukseen suoraan.

Mutta CERT/CC lähetti heille sähköpostin, mutta
unohti mainita SMTP ujutuksen.

Luulimme siis, että he kertoivat Postfixille.

Sendmailia ei nähtävästi kiinnostanut.

CERT/CC on Ciscon puolella asiassa.

Me olimme, että Cisco on taatusti haavoittuvainen,
olimme varmistaneet sen.

Joten haluaisimme julkistaa tämän blogissa.

Ja tästä ongelmat vasta alkoivatkin.

Kerroimme, että haluaisimme julkaista tästä
blogikirjoituksen

ja varoittaisimme Ciscon asiakkaita
tästä ominaisuudesta.

CERT/CC oli sitä mieltä, että "Antaa mennä vaan!
Lähettäkää meille linkki kirjoitukseen, kun se on julkaistu"

Päätimme edetä ja tulimme avanneeksi Pandoran
laatikon,

koska nyt 1.6 miljoonaan Postfix ja Sendmail

instanssia ovat haavoittuvina internetissä.

Ja se tarkoittaa, että jos tapahtuu ulospäin suuntautuva
SMTP ujuttelu,

niin voit hyväksikäyttää Postfixiä ja Sendmailia yhä.

Tarkoittaako tämä, ettei SEC Consultissa ole yhtään vikaa?

Totta kai SEC Consultissa on vikaa.

Julkaisimme blogikirjoituksen olettaen, että
vaikutus olisi pienempi kuin se todellisuudessa oli

perustuen keskesteluihin CERT/CC:n kanssa ja
VINCE:ssä muutenkin.

Ja jos olisimme vain tuplavarmistaneet Postfixin
kanssa, että julkaisu ei ole ongelma, tätä ei olisi tapahtunut,

koska he ovat järkkymättämiä, että tämä on ongelma.

Yhteenveto, mitä tämä tarkoittaa?

Korjatkaa Postfix palvelimenne! Löydätte lisätietoja
Postfixin nettisivuilta.

Lisäksi korjatkaa Cisco palvelimenne. Voitte löytää
lisätietoja siitä SEC Consult:n blogista.

[Yleisön naurua ja aplodit]

Lopuksi, tässäkin asiassa on jonkinlainen hopeareunus.

Nyt Postfix on suoraan mukana VINCE tapauksessa

ja he ovat jo antaneet suuren panoksen.

Emme työnnä päätämme pensaaseen ja yritä
aktiivisesti sulkea Pandoran lipasta jälleen.

Ja mitä se tarkoittaa? Lisää tutkimusta SMTP ujuttelusta

Tarkoitan, että pyysin CERT/CC:tä katsomaan tätä
tarkemmin, niin, se ei päättynyt kovin hyvin.

Lisää blogikirjoituksia, lisää tutkimusta ja
ennen kaikkea lisää toimijoita VINCE tapaukseen.

Yritämme saada kaiken korjattua ja olemme pahoillamme,
että tämä tapahtui ylipäätään.

Lopuksi jotain, jonka kaikki tiedätte. Älkää
luottako sähköposteihinn sokeasti, erityisesti tällä hetkellä.

Kiitos.

[Aplodeja]

Hienoa, kiitos. Mennään kysymyksiin.

Ole hyvä.

Hei, minulla on yksi lyhyt kysymys CERT/CC asiasta.

Oliko tämä kommunikoitu sähköpostilla?

Ja etkö olisi voinut lähettää viestin
Ciscon CDO:na?

Kyllä, olisimme voineet tehdä sen ja luoda
jonkinlaisen kolmiodraamaan

Bill Gatesin, Elon Muskin ja jonkun muun välille.

Mutta valitettavasti emme nähneet tätä sähköpostia.

Näimme sen jälkeen päin, mutta se oli valitettavasti
liian myöhäistä.

Hei, kiitos teille. Arvostan työtänne.

Voisitko kertoa hieman aikajanasta?

Koska löysitte tämän ensimmäisen kerran?

Aloitin tutkimuksen kesäkuussa kuluvana vuonna

Minulla oli 10 päivän projekti SEC Consultilla.

Olin sitä mieltä, että 10 päivää ei riitä, joten
aloitin 10 päivää aiemmin.

Sitten löysin SMTP ujuttelun kuudentena päivänä

Sitten asia eteni kertomalla GMX:lle, Outlookille
tai Microsoftille ja Ciscolle

koska heillä oli vakavat SMTP ujuttelutapaukset,
koskien sekä lähtevää ja saapuvaa.

Sitten jatkoimme ja kerroimme CERT/CC:lle, koska
tämä vaikutti olevan laajempi ongelma maailmanlaajuisesti.

Aikataulumielessä, minulla ei ole sitä tässä nyt,
mutta se on SEC Consultin blogikirjoituksessa.

Onko joku tietty päivämäärä, jonka haluat tietää?

Ei, ei. Käyn lukemassa blogikirjoituksen. Kiitos.

Hei, kiitos hyvästä puheesta täällä.

Haluaisin kysyä, että on mitään evidenssiä

tai epäilyksiä, että tätä olisi jo käytetty?

Tämä näyttää melko helpolta
haavoittuvuudelta hyödyntää.

Voisin kuvitella, että sitä on jo hyödynnetty.

Jeah, sain joitain kommentteja Reddit postaukseeni

että tämä on supervanha,
mutta asia on...

Kohtalainen haavoittuvuus

Jeah, todennäköisesti

Ei, en tosiaankaan tiedä.

Kävin läpi paljon tutkimuksia, mutta niissä
ei ollut mitään.

Siksi kutsun tätä uudeksi haavoittuvuudeksi.

Translated by Mikko Heikkinen (ITKST56 course assignment at JYU.FI)