SMBv3 Null Pointer Dereference vulnerability (CVE-2018-0833)

 ( trey | 2018. március 2., péntek - 16:15 )

Részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Pedig biz' isten, jó ötletnek tűnik pure SMB-t/RDP-t kitenni a zinternetre. :)

Most ezt értsem úgy, hogy azokat a 20 éves buta mantrákat büfögöd, hogy az ilyeneknek a helye VPN-es / tűzfalazott hálózatban van?!?! :D

--
trey @ gépház

LOL, az ugye megvan, hogy itt a támadó SMB szervere van az interneten, nem az áldozaté? :))
És az áldozatnak kell akarattal meghívja a támadó SMB szerverét, hogy elszálljon? (ráadásul "csak" újraindul a kliens, feltörni nem lehet vele)

Mindez egy majd 6 éves, nemsokára EOL termékben...

De tudom, már le is állt az azure többmillió szervere, hiszen az ilyeneknek a VPN mögött a helye :)

Igen, megvan. Megvan a ":D" a végén?

(Meg az is, hogy ha fordítva lesz, akkor majd Imo megy, rohan, hogy patchelje az internetre kiszórt ramatyait, hogy utolérje magát. Akinek meg tűzfal mögött van, az megvonja a vállát, aztán szép kényelmesen megoldja.)

--
trey @ gépház

Ja, hogy nem "úgy"... De ha "úgy" lenne, akkor naugye, hogy megmondtam. LOL.

Ez a buta microsoft is futhat patchelni a pármillió "ramaty" szerverét, amik szintén kint lógnak smb-n. Ja, meg RDP-n is. De hülyék. Ők is. Trey az okos.

Ja, meg az okos Microsoft, ami kirugdossa a production gépeket az ügyfelek alól a felhőjében ha biztonsági probléma van, mer' ő most rebootol, mer' ő most eldöntötte, hogy a) most kell patchelni (fogalom nélkül) b) az ő patche biztos jó (fogalom nélkül)

Majd pont ez lesz mérvadó, amikor hálózatot és szolgáltatást tervezünk.

Pontosan ezt fogja csinálni, ha probléma lesz a saját részéről. Neked meg lófasz a seggedbe, eddig sem vállalt felelősséget a szoftverére, ezután sem fug. Olvasgass szerződést, hogy mi van akkor, ha rommá törik, vagy szarrá DOS-olják a gépedet ilyen esetben. Mehetsz panaszra a sóhivatalba.

Majd azért arra valamit nyögjél, hogy mi lesz akkor, ha mondjuk elmentél nyaralni két hétre, eltörött a kezed-lábad stb., az internetre kilógatott szervereiden RDP/SMB akármi sebezhetőség lesz, az ügyfeleid gépeit szarrá dosolják vagy törik, mert te basztál minimális védelemmel ellátni őket.

Mit fogsz ilyen esetben mondani? Ki lesz a hibás? Rajtad kívül mindenki?

--
trey @ gépház

Tudtam én, hogy szar az azure. Nem tudnak ők hálózatot tervezni, majd trey megmondja ezt is jól. LOL.

"eddig sem vállalt felelősséget a szoftverére, ezután sem fug."

Melyik cég melyik oprendszerére vállal felelősséget, ha megtörnek vele?

"ha mondjuk elmentél nyaralni két hétre"

Ugyanaz, mint ami veled lesz, amikor az openvpn-ben, az apache-ban, a dovecot-ban vagy bármelyik ezer másik opensource vacakban amit vpn nélkül publikálsz és lyukat találnak. Gondolom felkötöd magad, mert basztál "minimális védelemmel" ellátni őket. És gondolom téged is halálra törnek naponta ezeken a nyitott portokon, mint engem. Persze fel nem fogtad múltkor sem, igy most sem fogod, hogy természetesen van olyan környezet és helyzet ahol vpn mögé teszem én is ezeket. Máshol meg nem.

Nem nagyon hivatkoznék olyan cégre biztonság tekintetében, amelyiknek a bugkövető rendszerét szarrá törték.

"Ugyanaz, mint ami veled lesz, amikor az openvpn-ben, az apache-ban, a dovecot-ban vagy bármelyik ezer másik opensource vacakban amit vpn nélkül publikálsz és lyukat találnak."

Válasszuk külön azokat a szolgáltatásokat, amiket mindenkinek tesznek ki, pl. egy hírportált a 443-on, meg azokat, amiket egy zárt csoportnak (mondjuk rendszergazdáknak, bizonyos cég bizonyos dolgozóinak) pl. RDP.

Előbbit nem célszerű forráscímre tűzfalazni mert a cél, hogy lehetőleg a világ minden pontján elérhető legyen anonymous felhasználók számára (mondjuk ettől még lehet alkalmazástűzfalazni, proxyzni stb.)

A másikat meg kurvára lehet tűzfalazni, mert nem kell az egész világnak elérni. Lehet nevesíteni a felhasználót, meg lehet oldani, hogy az csak bizonyos forráscímekről jöjjön stb.

--
trey @ gépház

"Nem nagyon hivatkoznék olyan cégre biztonság tekintetében, amelyiknek a bugkövető rendszerét szarrá törték. "

Bullshit. Akkor gondolom olyan linux-ot se használsz sehol, aminek a honlapját már megtörték valaha. Hiszen az akkor szar.
Egyébként ne hivatkozzál rá, max kiröhögnek, nagy változás nem lesz. (de nyilván az amazon is hülye, az is kirakja az RDP-t közvetlen)

"Lehet nevesíteni a felhasználót"

Jó reggelt, 10 éve van NLA az RDP-ben pl. Amig nem authentikál a user, addig nincs RDP forgalom.

"meg lehet oldani, hogy az csak bizonyos forráscímekről jöjjön stb. "

Van ahol meg lehet, van ahol nem. Továbbra sem birod felfogni, hogy nem minden helyzetben működik amit a piciny világodban kitaláltál.

"Bullshit. Akkor gondolom olyan linux-ot se használsz sehol, aminek a honlapját már megtörték valaha. Hiszen az akkor szar."

Ne terelj, nem a használatról volt szó.

"Egyébként ne hivatkozzál rá, max kiröhögnek, nagy változás nem lesz."

Kiröhögnek, mert további biztonsági layer-t teszek az RDP elé. Nyugodtan. A visszaröhögés sem fog elmaradni.

"Jó reggelt, 10 éve van NLA az RDP-ben pl. Amig nem authentikál a user, addig nincs RDP forgalom."

Mindezt az olcsóság/lustaság jegyében internetre kihányt RDP-s egyszem' szervereden. Gondolom én.

"Van ahol meg lehet, van ahol nem. Továbbra sem birod felfogni, hogy nem minden helyzetben működik amit a piciny világodban kitaláltál."

Továbbra is érdekel, hogy miért nincs kinn minden szervered RDP portja az interneten. Hiszen sokkal kényelmesebb lenne így az elérésük, a biztonság meg úgysem kérdés (szerinted).

--
trey @ gépház

"Ne terelj, nem a használatról volt szó."

Jaj ne csináld már a hülyét jobban. Nem nagyon vagy olyan cég, olyan megoldás, amit még nem törtek meg valamilyen szinten. Ilyenre hivatkozni nagyon lámaság.

"Kiröhögnek, mert további biztonsági layer-t teszek az RDP elé."

Kiröhögnek, ha azt mondod a microsoft nem tudja hogyan kell biztonságos hálózatokat, rendszereket üzemeltetni.

"Mindezt az olcsóság/lustaság jegyében internetre kihányt RDP-s egyszem' szervereden."

Igen. Bedobtad, hogy előbb authentikálni kéne az adminnak fenttartott szervizt. Leirom, hogy igen, előbb authentikálva van. Erre bedobod ezt a blődséget. Ez egyre röhejesebb.

"Továbbra is érdekel, hogy miért nincs kinn minden szervered RDP portja az interneten. "

Leirtam már. Egyszem szerver, egyszem publikált port esetén kint van. Semmi probléma nincs vele.
Máshol 10 féle szerver, 20 féle szolgáltatása, 300 usernek. VPN mögött van.

Harmadik helyen, ismeretlen usereknek demóalkalmazás egy lezárt VM-ben. Közvetlenül RDP-n. Minek tenném VPN mögé? Fel se tudja konfigurálni a user, nem is akarja. Kap levélben egy RDP file-t, nevet jelszót, rányom és használja. Ráadásul remote app, azaz úgy néz ki mintha a saját gépén futna, meg se tudja különböztetni a local programjaitól.

Tehát, akkor összefoglalva: ahol a biztonság nem fontos, ha megtörik ott rohadjon meg, lusta is vagyok, az user is hülye, ott ki van téve neked az RDP közvetlenül.

De azért a céges címtár DC-inek nem teszed ki a távoli asztal portját, mert ugyan kényelmes lenne VPN nélkül bárhonnan - pl. Kínából is - elérni, ha fel kell venni egy usert, de ... mi is?

--
trey @ gépház

Próbáld meg felfogni az utolsó két bekezdés 3 db példáját, hátha sikerül megfogni a lényeget. (bár erősem kétlem, ha eddig sem sikerült)

Szó nem volt egyik példában sem arról, hogy a biztonság nem fontos.

Jaj azt el is felejtettem megkérdezni a hálózati biztonság elismert szakértőjétől, hogy mondjuk egy amazonban (ami ugye közismerten nem akkora butus, mint a microsoft az azure-ral) futtatott linux-os vm (ami szintén by design rettentően biztonságos) ssh porjának vpn nélküli közvetlen publikálása esetén is kell-e hasonlóan örjöngeni, lámerezni, kutyaütőzni, vagy ott rendben van a dolog, mert izé, az nem mégse grafikus konzol (alapból), meg a belső hálózathoz is csak alig ad hozzáférést, meg különbenis rdpsmbnekvpnmögöttahelyemerthülyevagyésnemtudszvpntkonfigurálni.

LOL.

Nem válaszoltál a kérdésre, ami nem lepett meg.

Én a magam nevében tudok beszélni. Ha rajtam múlik, én nem teszek ki SSH portot az internetre úgy, hogy az bárhonnan elérhető (párszor leírtam már ezt itt, ezen az oldalon). Más nevében én nem fogok nyilatkozni. Mindenki úgy baszik ki magával, ahogy szeretné. További kérdés?

Nem értem, hogy mit példálózol nekem az Amazonnal. Életemben nem volt vele dolgom.

--
trey @ gépház

Tartsd is távol magad,mert ezek az ódivatúak IP restriction-öket ajánlanak mindenféle management portokra:

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html

Ez fantasztikus. Akárcsak a microsoft az azure-nál. És? Az egész téma onnan indult, hogy - állitólag - öngyilkosság rdp-t vagy smb-t vpn nélkül publikálni. Aztán miután bemutattam, hogy az összes nagy cég ezt teszi, finomodott oda, hogy ja, de le kell szűrni a szükséges tartományokra. Hurrá, én a https-t is leszűröm a tűzfalon a szükséges tartományokra, ahol csak lehet.

Nem emlékszem, hogy igy pörögtél volna a hátadon bármikor, amikor ssh publikáció szóba került volna, mintha most is picit finomabban fogalmaztál volna. Pedig az aztán igazán egykutya az rdp-vel. De sebaj, akkor ezt is tudjuk, hogy a kettő ugyanolyan veszélyes.

Amazont azért emlegettem, mert a elképsztő hozzáértésednek megfelelően köpködted a microsoft-ot és az azure-t, igy gondoltam akkor hasonlitsuk össze a gyakorlatot más komoly cégekkel. És rettentően meglepő módon ők is vpn nélkül, közvetlenül publikálják az rdp-t, sőt az ssh-t is.

A kérdésedre pedig ott volt a válasz az előző hozzászólásomban.

Semmit sem finomodott a dolog. Elmondtam a véleményem, RDP-t nem bölcs dolog internetre kitenni. Ezután sem fogom. Te azt csinálsz amit akarsz. A nagy pofád ellenére, neked sincs kinn semmi olyan, ami fontos lenne. SSH-t sem teszek ki, sosem szoktam. Az erről leírt véleményemet kibingelheted nyugodtan az oldalról.

Nyugodtan példálózz a vállalatokkal továbbra is, amelyik tét nélkül teszi ki a portokat. Én is kibaszkodnám, ha olyan papír lenne a kezemben, hogy semmiért sem vagyok felelős.

"A kérdésedre pedig ott volt a válasz az előző hozzászólásomban."

"természetesen van olyan környezet és helyzet ahol vpn mögé teszem én is ezeket. Máshol meg nem."

Ez lenne az? Mitől is függ, hogy VPN mögé teszed vagy sem?

--
trey @ gépház

NLA baromira nem változtat azon, hogy a credential megszerzésével ugyanúgy konzolt kapsz, mint nélküle.

Innen indult a vita: azt állítjuk, hogy ezzel eleve magasabb privilégiumszintet kapsz, mint önmagában egy VPN (hálózati autentikáció) felnyomásával.

Hogy szerzed meg azt a credentialt? Ahogy azt megszerezted jó eséllyel a vpn authentikációt is megszerzed. (mondjuk egy user gépét feltörve)
(mondjuk smart card hitelesités esetén sok sikert kivánnék én annak az RDP credential-nak megszerzéséhez, de mindegy)

Azon is lehetne vitatkozni, hogy melyik a nagyobb baj, egy lekorlátozott terminal serveren user konzolt szerezni (ill. remote app esetén, még azt sem, csak a kipublikált alkalmazáshoz kapsz hozzáférést) vagy a teljes hálózati hozzáférést kapni.

Szokás szerint környezetfüggő a dolog. Van ahol az egyik nagyobb baj, máshol a másik. Fel kéne már fogni, hogy sokféle igény, sokféle környezet van.

2022 végén jár le a Server 2012 R2 támogatása.

Azure-ban mi akadályozz meg, hogy a Virtual Network külső elérését VPN-el korlátozd? Vagy láttál olyat, hogy ennek az ellenkezőjét propagálja a Microsoft?

Hol állitottam, hogy az azure vagy microsoft megakadályoz, hogy vpn mögé rakjam a szolgáltatásokat? Azt állitottam, hogy hozzá nem értők 20 éves butaságaival ellentétben, nincs komoly kockázata sem az RDP, sem az SMB közvetlen kipublikálásának. Ennek egyik bizonyitékaként hoztam, hogy maga a microsoft a fél azure-t publikálja közvetlenül SMB-n (azure storage) és RDP-n (VM). (de emlithetném a VPS szolgáltatók bármelyikét is, aki szintén közvetlen RDP hozzáférést ad a VM-ekhez)

Az azure storage smb-t nem is tudod vpn mögé tenni, a VM-et teheted, ha akarod. Nagyon rég megdőlt már ez a marhaság, hogy öngyilkosság RDP-t, SMB-t közvetlenül publikálni.

Azt vonod kétségbe, hogy magasabb privilégiumszintet jelent egy konzol-hozzáférés, mint egy hálózati?

Attól, hogy valami az Azure-ban úgy működik, ahogy, még nem feltétlenül a legjobb vagy legszerencsésebb.
Van egy csomó elmaradásuk és feature request-jük.

Egyszerű példa: kizárólag a VSTS hosted agent-jeire számára szeretnék elérhetővé tenni egy Azure-os VM-en futó service-t, azonban konkrét IP tartományt nem publikál ezekre a Microsoft.

"nem feltétlenül a legjobb vagy legszerencsésebb. "

Akkor ismét visszakérdeznék: hol állitottam, hogy ez a legjobb felállás?

Azt állitom, hogy a lámer, 20 éves butaságok büfögése helyett, ma egyáltalán nem öngyilkosság RDP-t vagy SMB-t VPN nélkül publikálni. Bizonyitja ezt sok-sok millió szerver, komoly cégektől publikálva.

"Van egy csomó elmaradásuk és feature request-jük. "

Jó ég. Ez hogy jön ide?

Az, hogy valamilyen megfontolásból (pénz, technológiai kötöttség, tökömtudja) publikálnak ilyen szolgáltatásokat, adott esetben tömegesen, még ne jelentsen best practice-t.
Dőreség ez alapján kijelenteni, hogy ez egy biztonságos gyakorlat.

Best practice? Ez most már a harmadik számba adott hülyeség. Harmadjára is megkérdezem: hol állitottam, hogy ez best practice?
Tényleg ennyire nehéz megérteni amit irok? Nem azt mondtam, hogy mindenhol közvetlenül ki kell, vagy hogy ez a legbiztonságosabb megoldás.
Azt mondtam, hogy a buta közvélekedéssel szemben, ma már messze nem veszélyes kipublikálni, ha értesz hozzá és normálisan bekonfigurálod.

"Dőreség ez alapján kijelenteni, hogy ez egy biztonságos gyakorlat."

Azért, ha milliószámra van igy kipublikálva, profi cégek esetén is, sőt cloud-VPS estén ez a teljesen normális gyakorlat, akkor azért nehéz volna kijelenteni, hogy ez nem biztonságos gyakorlat. (jó tudom trey előadta, hogy biztos nem is ugyanaz fut a VM-ben, mint amit megveszel. Az azure-ban (és minden más cloudban) nagyonbiztonságos RDP és SMB fut, a boltban megvett windows-on pedig a lyukas RDP és SMB fut :))

Ha nem volna biztonságos, akkor nem publikálnák milliószámra, hiszen folyamatosan feltörnék ezeket a VM-eket. Mégsem hallani ilyesmiről valamiért.

LOL

Ja a Microsoft eddig is remek példakép volt, a mintaszerü biztonsági szemléletével és remek, időtálló megoldásaival... oh wait.

--
Microsoft, mert megérdemled!

Ja, az azure, mint a legtöbb szervert használó cloud többmilliós szerverparkkal. Nap mint nap szanaszét törik a script kiddiek, annyira szar a biztonsági szemlélet és nem is értenek hozzá.
Óvoda. /o\

Szerencsétlenek. Mire befoltozzák a korábbi sérülékenységeket, jönnek az újabbak.

--
robyboy

Ilyenkor mindig felmerül bennem, hogy az m$, apple, stb. nem azért védik foggal-körömmel a forráskódjaikat, mert jaj az az ő szellemi termékük, hanem el akarják kerülni a totális blamázst a kódjuk rettenetes minősége miatt.

Azért majd nézzél már körül, hogy mondjuk a manyeyeball-os samba-ban (vagy kb. akármelyik opensource termékben) mennyi biztonsági hiba van. Nem biztos, hogy a MS-nak volna szégyenkeznivalója.

Mondjuk egy 2-3 évre visszamenőleges apache-IIS összehasonlitás is megérne egy misét, hogy melyik is a bughalmaz.

(arra már ki se térjünk, hogy több mint 10 éve olvashatják emberek ezrei a ms termékek forráskódját. Kutatók, egyetemek, országok nemzetbiztonsági szervei stb-stb. De az ilyemi már nem illik bele az opensource mantrába)

Itt meg is ragadnám az alkalmat, hogy rendet tegyünk egy picit a kérdés körül. :)

Szívesen megmutatjuk a source code-ot egy csomó embernek, persze nyilván nem úgy, hogy itt a git repo, klónozd le névtelenül, de teljesen világos, elfogadható, és nem is túl szigorú feltételeknek kell csak megfelelni.

Errefelé le van írva minden: https://www.microsoft.com/en-us/sharedsource/default.aspx

-- a Microsoftnál dolgozom

te belenéztél már? :)

Nem. Illetve ez nem pontos, hozzáférésem nincs (főleg mert nem kértem), de kódrészleteket láttam belsős előadásokon.

csomó ember = "qualified customers, enterprises, governments, and partners"

ez azért így gondolom erős szűrő. ezek közül akar valamelyik hibát találni, vagy csak ránéznek, mert lehet? illetve van olyan statisztika hányan kérték? esetleg hányan találtak bármit is benne? csak kíváncsi vagyok mennyire használt, vagy eredményes ez a megoldás.


"I'd rather be hated for who I am, than loved for who I am not."

én meg épp ésszel fel nem tudom fogni, minek használnak még Windowst... 30 éve foltozgassák, és csak egyre szarabb. Nekem is hoztak egy laptopot, ahol végtelen ciklusba került a frissítés-hiba-javítás-frissítés-hiba-javítás...

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba