On-Premise Exchange szerverekben levő 0day biztonsági hibákat támadnak kínai hackerek

Érintett verziók:

  • Microsoft Exchange Server 2013  
  • Microsoft Exchange Server 2016  
  • Microsoft Exchange Server 2019 

Az Exchange Online nem érintett. A Microsoft soron kívüli javítást adott ki, amit érdemes mielőbb telepíteni az érintett Exchange verziókra.

Részletek itt.

Hozzászólások

Miert nem a japanok? Ok meg korabban kelnek, nem?

Valószínűleg a javításokat sem teszik majd fel a rendszergazdák, mert 

 

- túl hamar lett kész

- nem bízik a javításokban, nem ismerjük az 5-10 éves hosszútávú használatának eredményit

-nem bionyítottan véd a támadások ellen, engem nem támadtak meg

- csak az Unió által bevizsgált patch-t teszem fel, más patch nem jó

-a javításban  rejtett chipek lehetnek, ami Bill Gates műve és lehallgat.

-Orbán Viktor el akarja lopni az adatainkat, ami egyébként a BM-ben mindig benn van.

-Gyurcsány Ferenc patchellenes, emiatt én sem rakom fel a javítást

-Rakja fel más a javítást, én eddig sem pecseltem, ezután sem fogok. A nyájimmunizás elérése után majd nem támadnak annyira

A felhasználói bázis mérete és befolyása okozza a legnagyobb problémát. Valamint van egykét nemolcsó egyedi szoftverünk/megoldásunk ami erre a hibridre épül 5 éves szerződésekkel, amik mostanában újulnak meg már mind az azureAD és exchange online párosra épül így reményeim szerint 2-4 éven belül megszűnik a végfelhasználói igény az on-prem ADre és akkor dobhatjuk az on-prem exchange-t.

Nálunk ez annyira nem gáz, mert az átláthatóság miatt nagyon sok mindent publikálnunk kell (így egyszerűbb is lesz, mert  már kezd kicsit elegem lenni abból, hogy 8-10 különféle API van ami a különböző weboldalakra publikál és mindig van baj valamelyikkel). Ami annyira fontos az sose fogja elhagyni az épületet(kivéve az online exchange), de azokat a rendszereket eleve is csak egy másik felhasználói fiókból érik el azok akiknek kell, azokhoz a fiókokhoz meg nincs email így az on-prem exchange szükségtelen lesz. Én a Zoom miatt se féltem annyira, csak olyan helyen használtuk ahol kellett a sok arc egy képernyőn és amúgy is ment egyenes adásban a tv-ben úgyhogy nem sok értelme lett volna betörni hallgatózni, a host meg amúgy is némított mindenkit csak a napirendi pontok szerint ment a feloldás (mondjuk így is behallatszott egykét bazmeg)

Hát én tanultam a suliban 100 éve it biztonságot, akkor még volt olyan, hogy az it biztonság 10 parancsolata, és ez volt az első parancsolat:

1. Amelyik számítógéphez fizikailag hozzáférnek, az nem a te géped többé.

Manapság ez kínos ezért nem annyira foglalkozunk vele, mert a felhőben a legelső biztonsági szabály sérül. A felhőben minden csak ígéret! Egyszerűn nem lehet elég biztonságos. Talán csak egy kivétel van, a kliens oldali titkosítás, de tegye fel a kezét aki így futtat cloud exchange-t.

Zárójelben jegyzem meg, hogy látok egy olyan jelenséget, hogy alap rendszergazdai feladatokat állítunk be mission impossible dolgoknak (pl. levezőszerver üzemeltetés), olynaokat amiket néhány éve mindenki csinált és nem próbált megszabadulni tőle, mert "nehéz" csinálni.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Te abból indulsz ki, hogy az üzemeltető nem ért hozzá, én meg abból, hogy ért hozza. Ha béna és o365-öt használ akkor valóban üzembiztosabb lesz a rendszer, de ennek az ára a biztonság feláldozása. Gyakorlatilag elfogadod, hogy az Ms azt csinál az adataiddal amit akar, cserébe a bénaságodért.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Annyira ismerem, hogy a saját cégem KKV cégeket üzemeltet outsource-ban, de szvsz az üzemeltetés minősége nem függ össze azzal, hogy cloud-ban nem tudod kontrollálni az adataid, mert az tény. A cloud-ban ha a fejed tetejére állsz, akkor sincs nálad a gyeplő.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Igen, de ez a kérdés nem klasszikus IT biztonsági kérdés. Egyébként, helyi hálón üzemeltetve is megbízol vakon számtalan dologban:

  • op. rendszer gyártója
  • tűzfal gyártója
  • UTM eszköz gyártója
  • spamfilter gyártója
  • vírusirtó gyártója
  • mentőrendszer gyártója
  • stb.

Sorolhatnám a végtelenségig, hogy egy helyi Exchange üzemeltetése esetében mi mindenben bízol meg. Nem nagyon értem, mire ez a nagy magabiztosság.

trey @ gépház

Én nem bízom meg semmiben, pont ez a lényeg és elég nagy különbség van az esélyed sincs, és a vannak eszközeid között. Egyszerű példa, van network secirity partner aki fogott már meg bios kompromittált szervert, gagyi adatszivárogtató rouert, stb. A felhőben nem tudsz csinálni semmit, mert nem a tiéd a vas, mellesleg köztudott, hogy a nagyok (szvsz a kicsik is) ellopják az a adataid. Ez nekem különbséget jelent a kétféle üzemeltetés között. Ez nem a magabiztosságról szól, hanem a lehetőségekről.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Ez a szintű paranoia inkább már valahol a hit, vallás kategória. De akkor még mindig számos kérdés van, amit ki kell értékelni. Azt mondod, outsourcing-ben utazol. Akkor pont neked kellene értened, hogy mit nyersz azzal, hogy adott esetben nem a saját rendszered patchelgetésével és üzemeltetésével töltöd a drága időt: ügyfél felé értékesíthető időt. Mondjuk, ha adott esetben nincs kinek, akkor védhető a saját szarral foglalkozás. De ha többszörös pénzért eladható a szakértelmed a rezsi óradíjnál, amivel a sajátod tákolgatod, akkor azt kell tenni. Én ezt csinálom most. Azt az időt, amit eddig erre fordítottam, értékesítem ügyfelek felé.

Még mindig csak két olyan témát érintettünk, amit mondjuk egy SWOT-ba be lehet írni. Én kb. ízekre szedtem ezt és az jött ki, hogy nem lehetünk győztesek, semmilyen szinten, ha az onprem-nél maradunk. Persze, nekem speciális az esetem, mert Microsoft GOLD partnerként olyan árat kapok az O365 E3-ra (Teams kutyafasza included), hogy abból egy desktop PC sem jönne ki, nemhogy decens szerver(ek) az Exchange 2019 alá.

Stb. stb.

trey @ gépház

Üzemeltetek O365 Exchanget-is, sőt hivatalos Ms CSP vagyok. Az nálam is olcsóbb az ügyfélnek, ő dönt nem én. Viszont még mindig azt mondom, hogy ez független attól, hogy a cloud biztonságnak az alapjaiban van hiba. Ez nem gondolom paranoiának, ez csak egy tény. Te bezárod az ajtót amikor elmész otthonról? Az paranioia?

Az ügyfél is feláldozhatja a biztonságot a pénzért, az ő dolga.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Bezárom az O365-öt is. 2FA van rá kifelé. Értem mit mondasz. Az adat egy harmadik személynél van. Ha már a háznál vagyunk, az nem zavar, hogy van egy nálad nagyobb hatalom, amik akkor basz ki a házadból, amikor akar? Mondjuk azt hiszed, hogy tied a föld, amin a házad áll, mert papírod is van róla. Persze, amíg nem államosítják ...

A felhőben levő adatok kezelését nemzetközi szerződések szabályozzák. Azt mondani, hogy a Microsoft tetszése szerint bármit kezdhet vele, nem teljesen fair.

Természetesen, nekünk is van olyan ügyfelünk, aki nem hisz a felhőben. Nem is való a felhő mindenhova. Viszont, busásan ki is fizeti az árát annak, hogy ő akarja ugyanazt a szintet felépíteni. Hidd el, kurva sokba kerül. Megoldásszállítóként nem az a megoldás, hogy saját igényeinkre felhőt építünk. Sem hardver, sem időráfordítás nem térül meg.

Aki meg vérparanoid, az levelezzen titkosítva.

trey @ gépház

A nemzetközi szerződékkel kitörölheted a hátsód. Egy barátom Hiki kamerákkal foglakozik, most szopnak mint a torkosborz, mert a google kitette a szoftvereiket a play-ről, szerződés ide-vagy oda. Az összes ügyfélnél kézzel kell telepíteni a szoftvereket, gondolhatod mennyire boldogok.

Abban igazad van, hogy lehet vele pénzt keresni, és vannak esetek amikor igen hatékony, de ennek ára van amit nem pénzben mérnek.

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Abban igazad van, hogy lehet vele pénzt keresni, és vannak esetek amikor igen hatékony, de ennek ára van amit nem pénzben mérnek.

Viszont ha az, aki az egészre a pénzt adja, azt mondja, hogy NEM, akkor az NEM. Erre mondtam, hogy ez nem üzemeltetői kompetencia, kérdéskör. Ez máshol dől el. 

trey @ gépház

Erről csak az jut eszembe, mikor pár hónapja hajnali 4-5 körül  bement a NAV egy hazai gépterembe, nem tudták pontosan beazonosítani a kérdéses cég szerverét, ezért lebaszták a netről a teljes rack szerkrényt.

Ha saját telephelyeden vagy hazai co-locban  van a vas, és vélt vagy valós nézeteltérésbe kerülsz a hatalommal, akkor a NAV simán berúghatja az ajtót, és vihet mindent, ha azt látja jónak.  Te meg állsz letolt gatyával, és legjobb esetben is backupból rángatsz vissza mindent a frissen vett vasakra, hogy lehessen dolgozni

Ehhez képest, ha az adatok bármelyik cloud szolgáltatónál vannak, akkor egy hivatalos adatkikérés keretében kaphat csak az illetékes szerv MÁSOLATOT az adataidról.

Ennek jogi hátteréről írhatnál némi konkrétumot. Nem érvelni szeretnék valami mellett vagy ellen, de nem világos számomra, hogy "felhő szolgáltató" esetén ekkora erővel miért nem csinálhatja azt a NAV, hogy például az egész adatközpontot áramtalanítja (netán többet is), merthogy bárhol futhat a szolgáltatás. Illetve mi a jogi háttere annak, hogy "felhő szolgáltató" esetén miért csak másolatot kaphat? Mi áll a megkülönböztetés hátterében?

Félreértettél.  Magyarországi gépteremben levő  saját szerver esetén, vagy (magyarországi) telephelyi szerverszobában ezt bármikor megcsinálhatja. Az említett eset is ilyen volt.

Felhő esetén ezt nem tudja meglépni.
Google, MS, Amazon stb. felhő esetén  a megfelelő eljárás keretében adatkikérést kell igényelnie bármilyen hivatalos szervnek az érintett cégtől. Ez egy szabályozott folyamat. Nincs hajnali ajtórugdosás, meg fegyveres pszichikai nyomásgyakorlás.

Ez esetben azért csak másolatot kaphat, mert elég nehezen lenne értelmezhető az "adjátok ide a szervert, hogy elvihessük" kérés. ... és természetesen elég nehéz a NAV-nak meglepetésszerűen berúgni az ajtót egy USA vagy UK, esetleg Norvégia területén található adatközpontban.

Így már értem, de azért az eléggé durva szint, ha eddig fajul a hatalommal a viszony, ennek lehetnek előjelei. Arra kíváncsi lennék, hogy a teljes rack lehúzása miként áll össze jogilag, a többi sértettnek milyen lehetőségei vannak.

Ha egy cégnél esély van ilyenre, akkor külföldön is üzemeltethet szervereket (akár saját, akár bér), a hatóság ugyanúgy tehetetlen, ehhez nem kell felhőbe költöztetni minden vackot.

Nem olvastam a szál minden hozzászólását, meglehetősen parttalannak érzem ezt a felhő-nem felhő vitát, ennél sokkal árnyaltabb általánosságban is a kép, adott konkrét igényeket szemlélve akár még inkább.

Egyébként külföldön is lehet irodát bérelni stb. Olyan nyilván nincs, hogy valamiben ne kelljen megbízni.

Abszolute igazad van, a trollkodás azon megy, hogy a felhő egyesek szerint hatalmas biztonsági kockázat, és az egyetlen igazi biztonság az, ha saját vas, saját üzemeltetés.

Mások szerint ez fals biztonságérzet, és feleslegesen von el  erőforrást más  produktívabb és kifizetődőbb tevékenységektől.

Értem én a vita tárgyát, csak az érvelésekkel nem tudok egyet érteni, mert egymásnak feszülés és egymás melletti elbeszélés van ész érvek helyett. Én azt tapasztalom, hogy egy felhő/nem felhő döntésnél számos szempont fel tud merülni. Például egy új helyi Exchange rendszer kialakítása mellett nagyon nehéz 2021-ben érvelni (nem is szeretnék), ellenben egy SQL Server esetén sokkal árnyaltabb a kép.

Senki nem állította, hogy a felhő az egyetlen megoldás, és az onprem üldözendő.
Akik a felhő mellett érvelnek, azt mondják, hogy nem kevésbé biztonságos, mint az onprem.

Ez a szakmai érvelés indította ezt a threadet:

"...sokkal biztonságosabb mindenféle szutyok idegen felhőben megfuttatni a bizalmas, céges infókat."

 

Mindegy, köszönöm a lehetőséget egy kellemes pénteki trollkodásra, elfogyott a popcorn, megyek a dolgomra.

:-)

Én örülnék, ha végre olvashatnék egy objektív, árnyalt elemzést a felhő vs helyi infrastruktúrák biztonságáról (sajátosságok, kockázatok, ...), figyelembe véve, hogy helyi infrastruktúráknál hatalmas a szórás (ami nem feltétlenül baj, mert ahány ház, annyi igény). De ilyet még nem láttam, mert lényegében "nem-de" szintű diskurzusok vannak. :-)

Igen, ez így van (konkrétan nem is próbálom védeni a helyi exchange-et), csak a fórumokon sokszor néhány specifikus dolog el van mosva általánosra, illetve a felhő kapcsán sokszor csak a 10EUR/felhasználó/hó költségvonzat szokott megjelenni, mintha a felhő valóban csak annyiba kerülne tokkal-vonóval. Nekem az a tapasztalatom, hogy az ügyfelek nem akarják maguk nyomkodni az admin felületet, konkrétan sokszor jobb is, ha nem nyomkodják.

Ha a biztonságot tekintjük, számomra roppant érdekes például, hogy Exchange-et Microsoft hálózatból támadnak, ez azért felvet bizonyos kérdéseket, de ettől még nem fogja jobban megérni helyi Exchange-et telepíteni.

" azért az eléggé durva szint, ha eddig fajul a hatalommal a viszony ennek lehetnek előjelei"

teljesen átlagos okai lehetnek. Mondjuk e pár 10 millás áfa tartozás - amit akár önhibán kívül nem tudsz fizetni.

Vagy akár egy adócsalásba keveredett ügyfél, akinek mondjuk a levelezését te hostolod.

 

"Arra kíváncsi lennék, hogy a teljes rack lehúzása miként áll össze jogilag"

Kíváncsi lehetsz, de ilyen esetben ne nagyon  hangoztasd, mert a NAVosok at kísérő fegyveres rendőrök megkérnek, hogy kísérd be őket a vassal együtt.
Aztán pár óra után lehet, hogy kiderül, hogy nem volt rá joguk, és bocsánatot kérnek, de arra a pár órára te elég sokáig fogsz emlékezni.

 

"a többi sértettnek milyen lehetőségei vannak."

A szolgáltató elnézést kér a váratlan műszaki hibáért, amit kollégái SLA időn belül elhárították.

Pár 10 milliós ÁFA tartozás nem tudom, mennyire átlagos, elég jó eséllyel nem derült égből villámcsapás helyzet, de mindegy.

Arra vonatkozóan van közvetett tapasztalatom, hogy bizonyos hatóságnál meglehetősen jellemző a kettős mérce és úgymond vissza tudnak élni pozíciójukkal. De azt azért furcsának találnám, ha egy postafiók miatt leállíthatnának és leállítanának akár egy teljes rack-et. Ekkora erővel egy nagyobb hazai szolgáltató több rack-nyi infrastruktúráját is leállíthatnák. Ha lesz itthon Google/Microsoft stb. adatközpont, akkor azt is leállítanák egy postafiók miatt?

A dolog másik fele, hogy ilyen esetre lehet, hogy nem árt felkészülniük/felkészíteni az operátorokat/portásokat, hogy mire van jogosítványa a hatóságnak. Arra azért kis esélyt látok, hogy a helyszínen agyon lőnének valakit egy postafiók miatt.

Ami az SLA-t illeti: egy ilyen incidensnél súlyosabb és gyakoriebb leállások lehetnek akár nagy felhőkben is.

"De azt azért furcsának találnám, ha egy postafiók miatt leállíthatnának és leállítanának akár egy teljes rack-et"

Nem egy postafiók, hanem egy cég komplett levelezése miatt. És igen, ez volt. Az operátor nem tudta megmondani, melyik dobozban végződik az adott IP, ezért lebaszták a racket a netről, és felhívatták az operátorral a rendszerüzemeltetőt , hogy "valami hiba van, gyere be." (Mindezt reggel 5 kor)
 

"A dolog másik fele, hogy ilyen esetre lehet, hogy nem árt felkészülniük/felkészíteni az operátorokat/portásokat, hogy mire van jogosítványa a hatóságnak"
Az operátornak annyi jogosítványa van, hogy beengedje a hatóságot.

"Arra azért kis esélyt látok, hogy a helyszínen agyon lőnének valakit egy postafiók miatt."
Erről szó sincs. Elég nyomás az, ha berángatnak hajnalban műszaki hiba ürügyén,  és az elszállt switchport helyett fegyveres rendőrök fogadnak, akik nem akarják, hogy kérdezősködj.
Ha meg a jogaidat emlegeted, akkor megigazítják a pisztolytáskát, és közlik, hogy erre csak bent tudnak érdemben válaszolni, úgyhogy ha továbbra is érdekelnek a jogaid, fáradj velük.

Az operátor nem tudta megmondani, melyik dobozban végződik az adott IP

Ezek alapján elég lett volna egy normális nyilvántartás, hogy ne húzzák le az egész rack-et.

Azaz a kérdés elsősorban nem arról szól, hogy felhő vagy nem felhő, hanem arról, hogy a szolgáltatónak van nyilvántartása vagy nincs nyilvántartása.

Ezt eldönteni nem üzemeltetői kompetencia. Üzemeltetőként mondjuk pont leszarom, hogy egy felelős pozícióban levő eldöntötte, hogy mi az iránya a céges levelezésének. Kapott egy SWOT-elemzést, benne alaposan kielemezve, hogy mi az onprem, a saját felhő és az "idegen felhő" előnye, hátránya, lehetősége és veszélye. Az alapján döntött. Üzemeltetőként kb. 10-ed annyi macera van van az O365-tel, mint az onprem. Exchange-dzsel. Ez egy nyomós érv.

Tudom, hogy ez a hozzáállás valahol fura, de a vállalatok így működnek. Nem levelezőszerver admin szájíze szerint.

trey @ gépház

Teljesen egyetértek, de nekünk van egy kis beleszólásunk. Ezek nem normálisak érdeklik őket az üzemeltető/szaki véleménye is :-D  + nálunk megértették, hogy minél kevesebb ilyen szarral kell foglalkozni annál több idő marad arra, hogy a kritikus rendszerek mindig jól menjenek. + létszámstop is van úgyhogy könnyebben kiadják 5-6ember bérét egy rendszerre minthogy felvegyenek 5-6 embert egy rendszerhez(fejlesztők és üzemeltetők+support)

Szomorúnak tartom, ha bizonyos kényelmi kérdések előrébb vannak.

A kényelmi kérdésekkel az a baj, hogy borzasztó sokba kerül a kényelmetlen utat járni. :)

Egyébként nem gondolom, hogy az átlagos vállalat self-hosted emailezése biztonságosabb lenne, mint egy erre specializálódott szolgáltatótól készen megvenni. Legjobb esetben is csak máshogy szar. :)

De, hát pepkó, biztonsággal érvelsz és már a bejelentéskor kiderült, hogy az Online BIZONSÁGOSABB:

Érintett verziók:

  • Microsoft Exchange Server 2013  
  • Microsoft Exchange Server 2016  
  • Microsoft Exchange Server 2019 

Az Exchange Online nem érintett.

Nem igazán értem, hogy min erőlködsz. Ez ellen a prikezsia ellen az összes Online Exchange-t használó vállalat védett. Meg van (száz)ezerszámra, amelyiknek az on-premise telepítése jelen pillanatban is sérülékeny, némelyiket már fel is baszták, mialatt ezt a kommentet írom.

Mit szeretnél mondani?

trey @ gépház

Ez meredek kijelentés volt; semmi sem igazolja, hogy biztonságosabb. Most kiderült egy on-premise hiba. Ekkora böhöm rendszerekben bárhol, bármikor előfordulhat hasonló. Adatvédelmi szempontból örökké aggályos marad, ha eleve ismeretlen helyen tartja egy cég az adatait, még akkor is, ha azok titkosított szálakon titkosított állományok utaztatásával is jár.
Szerintem pontosan tudod, mennyivel nagyobb biztonságban van az adat, ha tűzfal mögött marad.

READY.
󠀠󠀠‎‏‏‎▓

Szerintem pontosan tudod, mennyivel nagyobb biztonságban van az adat, ha tűzfal mögött marad.

:D :D :D Exchange szervernél ha nyitva van az OWA az internet felé (márpedig szinte minden esetben nyitva van, különben nincs egyszerű mobil levelezés), akkor milyen szerepet játszik a tűzfal, ha egy portforward van a helyi hálón levő Exchange szerver 443-as portjára?

Semmi. Amennyi elesett helyi hálón levő szervert láttunk és raktunk rendbe, annak fényében különösen vicces ez a kijelentés.

trey @ gépház

Nem lesz kényelmesebb, de azzal tudok foglalkozni ami fontosabb. Inkább beáldozok egy félórás meetinget mint egy egész hétvégét mondjuk Exchange updatekre, mert hiába van kettő is amíg ment az update addig elhasalt a másik úgyhogy amíg levelezésre is volt használva addig kizárólag hétvégén lehetett frissíteni és azt is csak manuálisan (ez még bőven előttem volt), most viszont ha lehal az online exchange akkor a partnereinké is lehal (már ha ugye az is MS).

Ha annyira bizalmas infókról van szó, hogy egy szerződéses beszállító nem járhat el adatkezelői minőségben, akkor az email eleve felejtős. A túloldal simán lehet, hogy hazaküldi a gmailes postafiókjába, onnan kinyomtatja elolvasni, majd a papírt beviszi a gyereke rajzórára vagy mittudomén összefirkálni. Megtörtént eset alapján - szóval én biztos nem egy S&P500-as szolgáltató rosszhiszemű szerződésszegésétől félnék. :)

Nem az volt benne a lényeg, hanem hogy ha ennyire bizalmas dolgot akarsz küldözgetni, akkor eleve nem a plain-text email lesz a megoldás. Te elköltesz rengeteg pénzt a legtutibb, legbiztonságosabb on-prem levelezés kiépítésére, miközben simán lehet, hogy a túloldali ceo@valami.hu csak egy redirect egy gmailes címre. 

A tapasztalat visszajelzései alapján:

Eddig 4 Exchange szerverből 3-on csúnyán elhasalt a frissítés.

trey @ gépház

Szerkesztve: 2021. 03. 04., cs – 10:32

Today we are releasing several security updates for Microsoft Exchange Server to address vulnerabilities that have been used in limited targeted attacks

Bírom az ilyen "limited targeted" puhításokat. Tegnap több privát csatornából jött a "juj, gyorsan frissíteni" figyelmeztetés a Microsoft-tól.

Megkaptam mint

  • partner, belső levélben
  • megkapta az egyik legnagyobb magyar ipari vállalat IT részlege, mint partner, forró dróton

Elég nagy "bazmeg" lehet ebben, hogy így izzottak a drótok. Mondjuk erre utal az "out of band" patch kiadása is.

trey @ gépház

Hát igen, nem emlékszem hasonlóra.

És akkor az egyik napló bejegyzés (az alapján, amit kiadtak, mire kell keresni, hogy volt-e támadás):

021-03-03T15:45:40.877Z,ee276c2c-da80-4d3d-8e83-495050db3046,15,1,1415,2,,Ecp,a.b.c.d,/ecp/y.js,,FBA,false,,,ServerInfo~a]@mail.valami.hu:444/autodiscover/autodiscover.xml?#,ExchangeServicesClient/0.0.0.0,137.116.145.209,MAIL,200,200,,POST,Proxy,mail.valami.hu,15.00.0001.000,CrossRegion,X-BEResource-Cookie,,,,348,360,,,0,0,,0,,0,,0,0,,0,30,0,0,17,1,10,0,0,0,0,0,30,0,11,2,19,19,30,,,,BeginRequest=2021-03-03T15:45:40.846Z;CorrelationID=<empty>;ProxyState-Run=None;FEAuth=BEVersion-1941962753;NewConnection=fe80::2937:46a6:d71d:80bd%2&0;BeginGetRequestStream=2021-03-03T15:45:40.849Z;OnRequestStreamReady=2021-03-03T15:45:40.865Z;BeginGetResponse=2021-03-03T15:45:40.865Z;OnResponseReady=2021-03-03T15:45:40.876Z;EndGetResponse=2021-03-03T15:45:40.876Z;ProxyState-Complete=ProxyResponseData;SharedCacheGuard=0;EndRequest=2021-03-03T15:45:40.877Z;,,,,,,CafeV1

Amiben a Client IP Address: 137.116.145.209, https://db-ip.com/137.116.145.209

137.116.145.209 is an IPv4 address owned by Microsoft Corporation and located in Singapore, Singapore

Érdekes.

Arra vonatkozóan egyébként van információ, hogy például a fenti kéréshez tartozó AutoDiscover kérés járt-e valami féle sikerrel a próbálkozó számára?

2021-03-03T15:45:40.876Z,ee276c2c-da80-4d3d-8e83-495050db3046,15,1,1415,2,,Negotiate,true,NT AUTHORITY\SYSTEM,,ExchangeServicesClient/0.0.0.0,137.116.145.209,MAIL,MAIL.VALAMI.HU,POX/OutlookAutoDiscoverProvider,200,500,0,0,1,,,,,GlobalThrottlingPolicy_121d7937-7313-4684-8727-edcc118a7f7f,,,1,2,0,2,1,,10,ADSessionSettingsFromAddress=0;ADRecipientSessionFindBySid=3 0045;Caller=null;ResolveMethod=Unknown;RequestedRecipient=null;ErrorReason=Recipient was not found;RequestedUser=administrator@valami.hu;S:ServiceCommonMetadata.RequestSize=348;S:WLM.Bal=299999;S:WLM.BT=Ews;S:BudgetMetadata.MaxConn=27;S:BudgetMetadata.MaxBurst=300000;S:BudgetMetadata.BeginBalance=300000;S:BudgetMetadata.Cutoff=0;S:BudgetMetadata.RechargeRate=1800000;S:BudgetMetadata.IsServiceAct=False;S:BudgetMetadata.LiveTime=00:00:00;S:BudgetMetadata.EndBalance=299999;Dbl:WLM.TS=10;I32:ATE.C[dc.valami.hu]=1;F:ATE.AL[dc.valami.hu]=0;Dbl:BudgUse.T[]=2.00799989700317;I32:ADS.C[dc]=3;F:ADS.AL[dc]=1.856699,,message=The email address can't be found.;,,3556,1_63_64_61_62_62_62_4_65_67_61_59_6_12_22_15_33_34_38_2,2021-03-03T15:45:40.865Z,2,5,2,2,5,10

Nagyon nyomják. Ez tegnap éjjel jött:

https://note.microsoft.com/index.php/email/emailWebview?md_id=93853

Exchange Server patch alert

We are contacting you to alert you to Microsoft’s release of patches for multiple different on-premises Microsoft Exchange Server zero-day vulnerabilities that are being exploited by a nation-state affiliated group.

The vulnerabilities exist in on-premises Exchange Servers 2010, 2013, 2016, and 2019.  Exchange Online is not affected. We wanted to ensure you were aware of the situation and would ask that you help drive immediate remediation steps.

Specifically, to minimize or avoid impacts of this situation, Microsoft highly recommends that you take immediate action to apply the patches for any on-premises Exchange deployments you have or are managing for a customer or advise your customer of the steps they need to take. The first priority being servers which are accessible from the Internet (e.g., servers publishing Outlook on the web/OWA and ECP).

To patch these vulnerabilities, you should move to the latest Exchange Cumulative Updates and then install the relevant security updates on each Exchange Server.

  • You can use the Exchange Server Health Checker script, which can be downloaded from GitHub (use the latest release).
  • Running this script will tell you if you are behind on your on-premises Exchange Server updates (note that the script does not support Exchange Server 2010).
  • We also recommend that your security team assess whether or not the vulnerabilities were being exploited by using the Indicators of Compromise we shared here.

We are committed to working with you through this issue. For additional help, please open a ticket with our Partner Center or contact the help desk.

Resources and information about this issue for partners

  • Microsoft On the Issues blog
  • Microsoft Security Response Center (MSRC) release - Multiple Security Updates Released for Exchange Server
  • Exchange Team Blog
  • MSTIC Blog
  • MSRC Blog
  • Microsoft On the Issues Blog
  • Out of Band Exchange Release Customer Alert
  • Security Update Guide

Exchange patch information

Sincerely,

Microsoft Partner Network

Thanks for your partnership with Microsoft.
Microsoft

trey @ gépház

(Most én jöttem egy másik univerzumból, vagy tényleg arról van itt szó, hogy valaki szerveren Windows-t használ?)

https://www.hwsw.hu/hirek/63003/microsoft-exchange-server-bug-tamadas-b…
https://krebsonsecurity.com/2021/03/a-basic-timeline-of-the-exchange-ma…
Lehet, hogy az a jobb univerzum, ahol nincs domináns gyártó és nincs domináns termék, hanem szabványok vannak, amiket a gyártók kényük kedvük szerint megerőszakolnak követnek.

Ez a probléma megelőzhető lett volna, ha Layer 7 proxyt futtatnak az Exchange előtt? Akár egy NGINX reverse proxy módban? Vagy egy valid HTTPS requesten keresztül megy be az exploit?